KI Coding Agent: Die Engpass-Verschiebung verstehen

Unsere Support-Warteschlange verarbeitete Tickets in neun Minuten, dann warteten sie vier Stunden, bis ein Agent sie anfasste. Dieselbe Geschichte zeigt sich gerade in Engineering-Teams mit einem KI Coding Agent: Der Code wird in Minuten geschrieben, dann staut er sich. Wenn der Durchsatz Ihres Teams nach der Einführung eines KI Coding Agents kaum gestiegen ist, haben Sie kein schlechtes Werkzeug gefunden. Sie haben Ihren echten Engpass gefunden – und er ist nicht dort, wo Sie gesucht haben.

Das ist die nützliche Art, zu verstehen, was 2026 in Engineering-Organisationen passiert. Ein KI Coding Agent – Software, die Code-Änderungen plant, schreibt und oft testet mit minimalem menschlichen Input, im Gegensatz zu Autocomplete-Assistenten – entfernt Reibung beim Schreiben. Aber Schreiben war selten der Engpass auf einer Software-Pipeline. Review, CI und Deployment waren es. Wenn Sie einen Nicht-Engpass beschleunigen, bekommen Sie nicht mehr fertige Arbeit. Sie bekommen eine längere Warteschlange vor dem, was danach kommt.

Wohin verschwindet der Engpass nach einem KI Coding Agent?

Zwei Industrie-Daten aus 2026 zeigen in dieselbe Richtung. In CircleCI's State of Software Delivery Report stieg der Durchsatz von Feature-Branches im Median um 15% Jahr für Jahr, aber der Durchsatz von Main-Branches – die Anzahl der Änderungen, die tatsächlich in Production gehen – fiel im selben Zeitraum um 7% (CircleCI, 2026 State of Software Delivery). Mehr Arbeit kommt vorne rein, weniger kommt hinten raus.

Parallel dazu zeigen GitLabs Developer Research, die von InfoQ zitiert werden, dass 85% der Befragten zustimmen, dass KI den Engpass vom Code-Schreiben zur Review und Validierung verschoben hat, und 79% sagen, dass der Delivery-Prozess nicht mit der Code-Schreibgeschwindigkeit Schritt gehalten hat (InfoQ, AI coding outpaces governance). Das ist keine Tool-Lücke. Das ist ein Engpass, der sich verschoben hat, und niemand hat die Linie neu gemessen.

Little's Law kümmert sich nicht darum, dass Code schneller geschrieben wird

Little's Law erklärt, warum das passiert – und es ist nicht spezifisch für Software. Es ist die gleiche Mathematik hinter einer Erfüllungs-Warteschlange oder einem Krankenhausentlassungsprozess:

``` WIP = Durchsatz × Zykluszeit ```

`WIP` ist Work-in-Process, alles was gerade in Ihrer Pipeline sitzt (offene PRs, Tickets in Review, Bestellungen gepickt aber nicht gepackt). `Durchsatz` ist vollendete Einheiten pro Zeiteinheit. `Zykluszeit` ist wie lange eine Einheit vom Start bis zum Finish braucht.

Wenn Sie Code-Generierung beschleunigen, ohne Review-Kapazität zu erhöhen, drücken Sie mehr Einheiten pro Stunde in eine Phase, deren Durchsatz sich nicht geändert hat. WIP muss irgendwohin. Es staut sich als offene-PR-Rückstand, eine wachsende Merge-Queue oder Reviewer, die Diffs schneller überfliegen und mehr übersehen. Keines davon ist kostenlos. Ein Pull Request, der drei extra Tage sitzt, kostet nichts – es kostet Kontext: der Autor hat sich weiterbewegt, der Reviewer muss die ganze Änderung neu laden, und Nacharbeit wird teurer, je länger sie wartet.

Der Code-Schritt ist nicht der einzige Ort, wo „KI Agent" auftaucht

Es lohnt sich, zwei Dinge zu trennen, die unter „KI Coding Agent" vermischt werden. Manche Tools sind eng gebaut, um Quellcode in einem Repo zu schreiben und zu ändern. Andere sind General-Purpose-Agenten, die zufällig einen Code-Writing-Modus neben Research, Browsing und Dokument-Generierung haben.

Genspark ist die zweite Art: ein No-Code-„Super Agent", der das Web durchsuchen kann, Slides oder Dokumente generieren und Code aus einem einzigen Prompt schreiben und ausführen kann. Diese Breite ist nützlich für einen Generalisten, aber es ist ein anderes Werkzeug für einen anderen Job als etwas, das speziell dafür gebaut ist, in Ihrer CI-Pipeline zu leben und Pull Requests gegen Ihre echte Codebase zu öffnen. Passen Sie das Werkzeug-Design an die Pipeline-Phase an, die Sie entsperren wollen, nicht umgekehrt.

Manus geht noch weiter und läuft in einem vollständigen virtuellen Computer (Browser, Terminal, Dateisystem), um Multi-Step-Aufgaben end-to-end zu planen und auszuführen und ein fertiges Deliverable zurückzugeben. Für ein Ops-Team ist das ein nützliches mentales Modell, auch außerhalb von Code: Ein Agent, der eine ganze Arbeit fertigstellt, nicht nur den schnellsten Sub-Schritt, ist derjenige, der tatsächlich Durchsatz bewegt.

PCE: die eine Zahl, die dir sagt, ob der Agent hilft

Prozesseffizienz (PCE) ist das Verhältnis von wertschöpfender Zeit zur Gesamtzykluszeit, und es ist die ehrlichste Art zu prüfen, ob ein KI Coding Agent Ihre Pipeline verbessert oder den Engpass nur verschoben hat:

``` PCE = Wertschöpfende Zeit / Gesamtzykluszeit ```

Bevor Sie einen KI Coding Agent einführen, messen Sie die aktuelle Aufteilung: Wie viel des typischen Lebenszyklus einer Änderung, vom ersten Commit bis zur Zusammenführung in Production, wird tatsächlich damit verbracht, Code zu schreiben oder zu überprüfen, versus in einer Warteschlange zu warten? Die meisten Teams haben diese Zahl noch nie gezogen und sind überrascht davon. PCE unter 25% ist auf Software-Pipelines üblich, was bedeutet, dass drei Viertel der Gesamtlebensdauer einer Änderung wartet, nicht bearbeitet wird.

Führen Sie die gleiche Messung 30 bis 60 Tage nach dem Rollout durch. Wenn PCE gestiegen ist, hat der Agent echte Kapazität freigegeben und Ihr Team nutzt sie. Wenn PCE gleich blieb oder sank, hat der Agent einen bereits schnellen Schritt beschleunigt und die zusätzliche Ausgabe sitzt in der Warteschlange, unsichtbar, bis jemand am Freitag offene PRs zählt. Das ist genau die Art von Messung, wo eine KI-Analyse-Schicht ihren Platz verdient: Es reicht nicht zu wissen, dass PCE sich bewegt, Sie brauchen den Verdict, welche Phase die Differenz aufgenommen hat, und das liest sich schneller von einer automatisierten Aufschlüsselung als von jemandem, der ein Kanban-Board anstarrt.

Drei Zeichen, dass Review, nicht der Agent, Ihr Engpass ist

Ein paar Muster zeigen sich konsistent, sobald Teams messen statt zu vermuten:

• Die Anzahl offener PRs steigt, während die Merge-Anzahl gleich bleibt. Mehr Einheiten kommen vorne rein, gleich viele kommen hinten raus. Klassischer WIP-Aufbau vor einem unveränderten Engpass.

• Die durchschnittliche PR-Größe wächst. Ein KI Coding Agent, der ein ganzes Feature auf einmal generiert, erzeugt größere Diffs als ein Mensch, der inkrementell tippt. Größere Diffs dauern länger pro PR zu überprüfen, was den Reviewer-Durchsatz schrumpft, selbst wenn Kopfzahl und Review-Geschwindigkeit pro Zeile konstant bleiben.

• Die Zeit bis zur ersten Review steigt schneller als die Zeit bis zur Zusammenführung nach Genehmigung. Wenn die Wartezeit hauptsächlich bevor jemand anfängt zu schauen ist, das ist ein Queueing-Problem (nicht genug Review-Kapazität, oder Reviews sind nicht priorisiert), nicht ein Review-Qualitäts-Problem.

Keines dieser Muster braucht exotische Tools zum Tracking. Ein wöchentlicher Pull aus dem API Ihres Git-Hosts, gegen die Woche geplottet, in der Sie den Agent ausgerollt haben, reicht aus, um die Form der Verschiebung zu sehen.

Was eine Support-Warteschlange richtig macht, die Engineering-Pipelines meistens nicht

Support- und Erfüllungs-Operationen kämpfen schon länger gegen genau dieses Problem, als KI Coding Agents existieren, und die Lösung verallgemeinert sich sauber. Eine Warteschlange, die First-Contact-Tickets in neun Minuten beantwortet, aber vier Stunden braucht, um ein Specialist-Tier zu erreichen, ist keine Story über Spezialist-Ressourcing, das langsam ist. Es ist ein Signal, dass das schnelle Tier über-ressourciert ist gegenüber dem, was dahinter kommt, und dass mehr Tickets an die Front zu ziehen nicht hilft, bis die Back-Tier-Kapazität sich ändert.

Engineering-Teams überspringen diesen Schritt ständig, weil Code Review auf einem Dashboard nicht wie eine Warteschlange aussieht. Es sind PRs, die ruhig in einem „warten auf Review"-Zustand sitzen, leicht zu übersehen, bis jemand fragt, warum ein zwei-Wochen-altes Feature noch nicht deployed ist. Theory of Constraints (die Idee, dass ein System's Gesamtausgabe durch seinen einzelnen Engpass limitiert ist, nicht durch die Summe jedes Schritt's individueller Geschwindigkeit) sagt, die Lösung ist nie „den schnellen Teil schneller machen". Es ist den echten Engpass finden, seine Kapazität schützen, und nur dann entscheiden, ob der schnelle Teil überhaupt mehr Geschwindigkeit braucht.

Es gibt einen zweiten, stillen Engpass, der ein paar Monate nach einem KI Coding Agent-Rollout auftaucht, der mehr Code schneller shipped: Dokumentations-Drift. Niemand bemerkt es, bis ein neuer Engineer's Onboarding doppelt so lange dauert, weil die Docs ein System beschreiben, das sich drei Sprints vor änderte. Eine Docs-as-Code-Plattform wie GitBook, die gegen das gleiche Repo synct, in das der Agent committet, hält zumindest die Papierfolge nicht weiter hinter dem Code selbst zurück. Es repariert den Review-Engpass nicht, aber es stoppt einen zweiten, der sich im Dunkeln bildet.

Sollten Sie Ihren KI Coding Agent absichtlich verlangsamen?

Manchmal ja, und das ist nicht populär, es über ein Werkzeug zu sagen, über das alle aufgeregt sind. Wenn Ihre Review-Kapazität die nächsten zwei Quartale fest ist (Kopfzahl gefroren, Reviewer bereits am Limit), einen Agent tripling die Rate von eingehenden PRs zu lassen, schafft nicht mehr fertige, deployed Features. Es schafft eine längere Warteschlange und, pro CircleCI-Daten oben, eine niedrigere Main-Branch-Erfolgsquote, weil Reviewer unter Volumen-Druck weniger fangen.

Der ehrliche Zug in dieser Situation ist, wie viel ein Agent pro Zyklus generiert, zu deckeln, oder seine Ausgabe hinter einem Pre-Review-Pass zu gaten (Linting, automatisierte Test-Coverage-Checks, eine Kleinere-Diff-Politik), bevor es je einen menschlichen Reviewer erreicht. Das ist keine Anti-KI-Position. Es ist die gleiche Logik wie nicht mehr Einheiten auf eine Linie zu planen als Ihre langsamste Station absorbieren kann.

Wenn der echte Engpass sich als Reviewer Aufmerksamkeit statt Reviewer Kopfzahl herausstellt, können Workflow-Agenten, die für Triage und Routing gebaut sind, wie Lindy AI, die Inbox und Notification-Overhead um den Tag eines Teams handhabt, echte Review-Stunden freigeben, ohne Ihre Codebase direkt zu berühren. Es lohnt sich, zu testen, bevor man annimmt, die Lösung muss „mehr Reviewer einstellen" oder „mehr Agent-Sitze kaufen" sein.

Wo Sie wirklich weiter investieren sollten

Führen Sie die PCE-Berechnung durch, bevor Sie die Agent-Nutzung weiter expandieren, nicht danach. Wenn die wertschöpfende Zeit als Anteil der Gesamtzykluszeit sich seit dem Rollout nicht bewegt hat, kaufen Sie noch nicht mehr Agent-Sitze. Legen Sie die nächste Budget-Linie in Review-Kapazität, CI-Durchsatz oder Merge-Queue-Automatisierung statt, welche die Daten zeigen, und führen Sie die Zahl in 30 Tagen neu aus.

Wenn PCE sich verbessert hat und Review mithalten kann, das ist das Signal, den Agent's Umfang zu erweitern, nicht vorher. Messen Sie zuerst. Die Teams, die echte Durchsatz-Gewinne von einem KI Coding Agent bekommen, sind nicht die, die ihn am schnellsten eingeführt haben. Sie sind die, die ihren echten Engpass gefunden haben und Kapazität dort repariert haben, bevor sie den schnellen Schritt noch schneller laufen ließen.