Ihre KI-Coding-Tools sind schnell. Ihre Pipeline nicht. Das ist das eigentliche Problem.

Zwei Dinge sind diese Woche passiert, die zusammen alles erklären, was Sie über die Zukunft der Softwareentwicklung im Jahr 2026 wissen müssen.

Erstens: Der „State of DevOps Modernization 2026"-Bericht wurde am 11. März veröffentlicht, basierend auf einer Umfrage unter 700 Ingenieuren aus den USA, Großbritannien, Deutschland, Frankreich und Indien. Das zentrale Ergebnis: Teams, die KI-Coding-Tools mehrmals täglich nutzen, deployen schneller in Produktion – doch 69 % dieser intensiven Nutzer geben an, „immer", „fast immer" oder „häufig" Deployment-Probleme zu erleben, wenn KI-generierter Code im Spiel ist. 51 % berichten zudem von mehr Codequalitätsproblemen und 53 % von mehr Sicherheitsvorfällen seit der Einführung dieser Tools.

Zwei Tage zuvor hatte Anthropic Code Review für Claude Code gelauncht – ein Multi-Agent-System, das Pull Requests automatisch auf Logikfehler prüft. Die internen Zahlen von Anthropic erklären, warum sie es gebaut haben: Der Code-Output pro Ingenieur bei Anthropic wuchs im letzten Jahr um 200 %, und der Anteil der PRs mit substanziellen Review-Kommentaren stieg nach der internen Einführung des Review-Systems von 16 % auf 54 %.

Erkennen Sie das Muster? KI macht Codeproduktion billig und schnell. Alles danach – das Testing, das Security-Scanning, das Deployment, das Review – ist jetzt der Flaschenhals. Der Harness-Bericht nennt das das „AI Velocity Paradox". Wir nennen es schlicht Alltag.

Wir beobachten das in Echtzeit

Aus unserer PHP- und Docker-Arbeit mit Enterprise-Kunden – insbesondere in regulierten Branchen wie dem Schweizer Finanzsektor – kennen wir dieses Problem seit Monaten. Teams führen KI-Coding-Assistenten ein, der Output steigt, und dann beginnt die CI/CD-Pipeline, die für das Commit-Volumen von 2022 ausgelegt war, zu würgen. Builds stauen sich. Tests dauern länger, weil schlicht mehr Code getestet werden muss. Security-Scans, die früher eine kleine Unannehmlichkeit waren, werden zur 45-minütigen Mauer zwischen einem Entwickler und seinem Deploy.

Die Harness-Daten bestätigen das: 73 % der Engineering-Leads sagen, „kaum" Teams hätten standardisierte Templates oder Golden Paths für ihre Pipelines. Nur 21 % können in unter zwei Stunden eine funktionsfähige Build-und-Deploy-Pipeline aufsetzen. Entwickler verbringen rund 36 % ihrer Zeit mit manuellen Aufgaben wie dem Einholen von Freigaben und dem Neustarten fehlgeschlagener Jobs.

Diese letzte Zahl sollte Sie aufhorchen lassen. Ein Drittel Ihrer Engineering-Kapazität, verbrannt für Routinearbeit. Nicht für neue Features. Nicht für Bugfixes. Nur um eine Pipeline zu beaufsichtigen, die für diesen Durchsatz nicht gebaut wurde.

Der Code-Review-Flaschenhals ist real – und ein Sicherheitsproblem

Hier wird es aus Sicherheitsperspektive unangenehm. Bei unseren Penetrationstests finden wir regelmäßig Bugs, die im Review hätten auffallen sollen. Edge Cases bei der Authentifizierung, Autorisierungslogik, die fast stimmt, aber eben nicht ganz, Input-Validierung, die 90 % der Fälle abdeckt und genau die 10 % übersieht, auf die ein Angreifer es abgesehen hat.

Multiplizieren Sie das nun mit dem Volumen an KI-generiertem Code, der in Pull Requests strömt. Der Anthropic-Blogbeitrag ist erfrischend ehrlich darüber: Vor ihrem Code-Review-Tool wurden die meisten PRs überflogen, nicht gelesen. Engineers sind dünn gesät. Sie sehen einen 400-Zeilen-PR, überfliegen ihn nach offensichtlichen Problemen, geben ihn frei und machen weiter. Das ist kein Charaktermangel. Es ist ein Kapazitätsproblem.

Das Tool von Anthropic ist interessant, weil es sich auf Logikfehler konzentriert, nicht auf stilistische Kleinigkeiten. Bei großen PRs (über 1.000 Zeilen) liefern 84 % der Reviews Befunde, im Schnitt 7,5 Issues. Bei kleinen PRs unter 50 Zeilen sinkt das auf 31 %. Intern haben sie auch eine Änderung abgefangen, die die Authentifizierung gebrochen hätte – eine einzelne, harmlos aussehende Bearbeitung, die ihr eigenes Auth-System gestört hätte.

Ich muss immer wieder daran denken. Eine einzige Zeile. In einem Auth-Service. Gefunden von einem automatisierten Reviewer. Genau solche Bugs finden wir bei Pentests – Wochen oder Monate nachdem sie live gegangen sind. Sie im PR zu erwischen ist um Größenordnungen günstiger.

Was Sie jetzt konkret tun sollten

Wir werden Ihnen nicht empfehlen, die Plattform eines bestimmten Anbieters zu kaufen. Aber basierend auf dem, was wir in unseren Web- und Mobilprojekten beobachten, funktioniert Folgendes:

Auditieren Sie Ihre Post-Code-Pipeline diese Woche. Ernsthaft: Machen Sie einfach eine Bestandsaufnahme. Wie lange dauert es von Merge bis Produktion? Wo sind die manuellen Übergaben? Wo stauen sich die Dinge? Die meisten Teams, mit denen wir sprechen, haben das noch nie von Ende zu Ende gemessen. Sie wissen, dass ihr Build 8 Minuten dauert, ahnen aber nicht, dass sie 3 Stunden an Freigabeketten und Environment-Provisionierung verlieren. Das ist Ihr Ausgangspunkt.

Automatisieren Sie Security-Scanning früher, nicht später. Wenn wir WAF- und DDoS-Schutz für Reiseplattformen konfigurieren, drängen wir immer darauf, Sicherheitsprüfungen so nah wie möglich an den Entwickler zu rücken. Dasselbe Prinzip gilt für Ihre Pipeline. Statische Analyse, Dependency-Scanning und Secret Detection sollten bei jedem PR automatisch laufen – bevor ein menschlicher Reviewer ihn überhaupt zu Gesicht bekommt. Wenn Sie Security-Scans noch immer nur im Staging oder – noch schlimmer – als Gate vor der Produktion ausführen, finden Sie Probleme zu spät, um sie günstig zu beheben.

Überspringen Sie das menschliche Review nicht, nur weil Sie KI-Review hinzugefügt haben. Das Tool von Anthropic wird keine PRs genehmigen. Das ist eine bewusste Designentscheidung – und die richtige. In unseren nativen iOS- und Android-Projekten haben wir gesehen, dass KI-Tools andere Fehlerklassen finden als Menschen. Die KI ist gut darin, Logikinkonsistenzen über einen großen Diff hinweg zu erkennen. Menschen sind besser darin zu fragen: „Moment, warum machen wir das überhaupt?" Sie brauchen beides.

Standardisieren Sie Ihre Deployment-Pfade. Die Harness-Daten sagen: 73 % der Teams haben keine Golden Paths. Wenn jeder Service anders deployt, können Sie die nachgelagerten Checks nicht automatisieren – und jedes Deployment ist ein individuelles Risiko. Aus unserer Arbeit beim Aufbau cloud-nativer Apps auf AWS ist die Investition mit dem höchsten Return, die wir bei Teams gesehen haben, ein gepflegtes Deployment-Template, das jeder neue Service standardmäßig erbt.

Die unbequeme Wahrheit

Die eigentliche Geschichte dieser Woche ist nicht, dass KI Entwickler schneller macht. Das wussten wir bereits. Die eigentliche Geschichte ist, dass die meisten Organisationen ihre Delivery-Infrastruktur für eine langsamere Welt gebaut haben – und KI-Coding-Tools diese Systeme bis an ihre Grenzen belasten.

Der Harness-Bericht stellt fest, dass 77 % der Teams bei routinemäßigen Delivery-Aufgaben regelmäßig auf andere Teams warten müssen. Das ist kein Tool-Problem. Das ist ein Architektur- und Prozess-Problem. Kein noch so viel KI-generierter Code wird das beheben.

Wenn Ihr Team 2× schneller Code schreibt, aber mit 2× mehr Incidents deployt, haben Sie keine Velocity gewonnen. Sie haben Chaos mit besserer Syntax gewonnen.

Bringen Sie Ihre Pipeline in Ordnung. Dann lassen Sie die KI laufen.

Wenn sich das nach Ihrer Woche anhört, sprechen Sie mit uns. Wir helfen Startups und Enterprise-Teams dabei, genau diese Art von Wachstumsschmerzen zu bewältigen – in den Bereichen Web, Mobile und Security.