Der Flaschenhals im KI Coding Loop

Benjamin Font Pera hat in Loop, Harness, Context Engineering: was bedeutet was? den Coding Loop als innersten Kreis beschrieben. Der Agent generiert Code, verifiziert ihn und passt ihn an. Diese Runde wiederholt sich, bis er sein Ergebnis für fertig hält.

Der lokale Build in unserem letzten Projekt brauchte acht Minuten, inklusive kompletter Test-Suite. Die Agents riefen den Build in jeder Runde auf. So oft, wie das in einer Session vorkam, summierten sich die Buildzeiten spürbar.

Code zu schreiben war in diesem Projekt der billige Teil. Den Takt gab die Verifikation vor. Wie lange sie braucht und wie verlässlich ihr Ergebnis ist, entscheidet darüber, wie viel in einer Session herauskommt.

Der Coding Loop ist dabei nur ein Glied in einer längeren Kette. Hinter ihm liegen Review, Freigabe und Deployment, davor Abstimmung und Priorisierung. Kai Lichtenberg hat in Vom Coding-Loop zum Business-Loop: KI Engineering ganzheitlich denken beschrieben, was passiert, wenn man nur an diesem einen Glied dreht:

Wer nur den Coding-Loop beschleunigt, optimiert lokal und verliert global, weil der Wert am langsamsten Glied der Kette entsteht, nicht am schnellsten.

Wer den Build halbiert, während eine fertige Änderung drei Wochen auf ihre Freigabe wartet, hat eine Mikro-Optimierung vorgenommen. Bei uns lag der Flaschenhals wirklich im inneren Loop, weil die Agenten so viele Runden fuhren, dass die acht Minuten dutzende Male am Tag anfielen.

Ein langsamer Sensor bremst den Coding Loop

Um den Loop herum liegt der Harness, der aus Guides und Sensors besteht. Guides wirken vor der Generierung und geben Richtung. Sensors wirken danach und melden zurück, ob das Ergebnis taugt. Build, Compiler und Tests sind Sensors.

Ein langsamer Sensor bremst den Coding Loop, weil der Agent vor dem nächsten Schritt auf das Ergebnis warten muss. Armin Ronacher hält das für den Kern seines Speed-Arguments in den Agentic Coding Recommendations:

There is a big difference in the quality and speed of the flow, if that tool takes 3ms to run vs it compiles for 5 seconds and then needs another minute to boot and connect to database and kafka broker and 100 lines of nonsensical log output.

Ronacher nennt Go als Beispiel, weil das Testcaching dort dafür sorgt, dass unveränderte Pakete gar nicht erst neu laufen. Der Agent bekommt das Signal in Millisekunden und macht weiter.

Der Flaschenhals im Coding Loop ist damit der langsamste Sensor, den der Agent in jeder Runde braucht. Bei uns war das die Test-Suite.

Ist die vollständige Prüfung zu teuer, um sie bei jedem Zwischenstand laufen zu lassen, wandert sie aus dem inneren Loop heraus, in die Pipeline nach dem Commit oder in einen nächtlichen Lauf. Der Agent arbeitet dann mit einem schwächeren Signal oder ganz ohne eines. Anthropic beschreibt in den Best Practices zu Claude Code, was in diesem Fall passiert:

Claude stops when the work looks done. Without a check it can run, "looks done" is the only signal available, and you become the verification loop.

Der Agent hört auf, sobald die Arbeit fertig aussieht. Ob sie es ist, fällt dann erst dem Menschen auf, der den Code liest.

Back Pressure

Geoffrey Huntley hat einen Text von Moss über Back Pressure kommentiert und dabei ein Bild geprägt, das mir seither im Kopf hängt. Back Pressure ist alles, was eine ungültige Generierung zurückweist, also Compiler, Tests, Linter, statische Analyse, Security-Scanner. Sein Punkt betrifft die Dosierung:

Back-pressure is part art, part engineering [...] you need "just enough" to reject invalid generations (aka "hallucinations") but if the wheel spins too slow ("tests take a long time to run or for the application to compile") then it's too much resistance.

Das Rad in diesem Bild dreht sich gegen einen Widerstand. Dieser Widerstand lässt sich in beide Richtungen falsch einstellen. Bei zu wenig Widerstand rutschen Halluzinationen durch. Zu viel Widerstand bringt das Rad zum Stehen. Eine lange Test-Suite gehört in diese zweite Kategorie. Teams kennen die Werkzeuge seit Jahren. Fehlen sie im Coding Loop, übernimmt der Mensch ihre Arbeit.

Moss argumentiert in seinem Originaltext genau darüber, nämlich über die Zeit des Menschen. Er geht vom Extremfall aus. Ein Agent, der nur Dateien schreiben darf und weder kompilieren noch testen kann, muss den Menschen fragen, ob seine Änderung trägt:

This means you spend your back pressure (the time you spend giving feedback to agents) on typing a message telling the agent it missed an import. This scales poorly and limits you to working on simple problems.

Wer seine Zeit damit verbringt, einem Agenten Import-Fehler zu melden, gibt Rückmeldung, die Compiler und Linter in Millisekunden liefern würden.

Schnell reicht nicht

Verifikation hat zwei Eigenschaften, die beide stimmen müssen. Wie schnell kommt das Signal zurück? Wie verlässlich ist es? Huntley schreibt das in seinem Text über den Ralph-Wiggum-Loop selbst mit:

It's the speed of the wheel turning that matters, balanced against the axis of correctness.

Ein schneller Check, der nichts prüft, beschleunigt das Bauen von Mist. Er ist gefährlicher als ein langsamer, aussagekräftiger Check, weil er Vertrauen vortäuscht. KI-Output sieht ohnehin besser aus, als er ist. Code kann kompilieren und grüne Tests haben und fachlich trotzdem das Falsche tun. Daniel Toews hat in Agentic Engineering: Wo Loops in der Praxis scheitern das Muster beschrieben, bei dem der Agent seine eigenen Tests entschärft, um grün zu werden.

Erst muss die Verifikation aussagekräftig sein, dann lohnt es sich, sie schnell zu machen. In der umgekehrten Reihenfolge bekommt man einen Loop, der in Rekordzeit ein grünes Ergebnis liefert, das nichts bedeutet.

Was schnell sein kann und was nicht

Birgitta Boeckeler unterscheidet in ihrem Artikel zu Harness Engineering computational und inferential. Computational meint deterministische Prüfungen, die auf der CPU laufen und in Millisekunden bis Sekunden antworten. Inferential meint semantische Bewertung, etwa durch ein Modell, langsamer und nicht deterministisch. Für den inneren Loop ist diese Achse eine brauchbare Sortierung:

• Millisekunden bis Sekunden: LSP-Feedback, Formatter, Linter, Compiler und Typechecker, ArchUnit-Regeln, gezielte Unit-Tests auf der betroffenen Einheit, Pre-Commit-Hooks.
• Sekunden bis Minuten: komplette Unit-Suite, Coverage-Gates, Security-Scans, statische Analyse, Integrationstests mit schmalem Scope.
• Minuten und mehr: Browser-Feedback, LLM-as-a-Judge, E2E-Tests, Mutation Testing, manuelles Review.

Die dritte Gruppe gehört nicht in jeden Build. Boeckeler fasst das unter "Keep quality left" zusammen und fordert Prüfungen so weit links im Weg zur Produktion, wie es geht. Ein Fehler, der im Compiler auffällt, kostet den Agenten drei Sekunden. Derselbe Fehler in einem E2E-Test kostet ihn zehn Minuten. Die Testpyramide sortiert nach demselben Kriterium, weil ein Test umso länger braucht, je mehr Anwendung er hochfahren muss. In unserem Projekt lag das Gewicht der Suite oben.

Von acht auf unter zwei Minuten

Der lokale Build mit kompletter Test-Suite lag bei rund acht Minuten. Die Suite enthielt viele Tests, die eher den Scope eines E2E-Tests hatten. Diese Tests haben ihren Wert, nur liefen zu viele davon in jedem Build mit. Sie laufen jetzt nachts.

Vorher mussten die Unit-Tests darunter dichter werden. Wo sie Lücken hatten, hat Mutation Testing gezeigt, also absichtlich in den Code eingebaute Fehler, bei denen sich zeigt, ob ein Test darauf anspringt. Der Lauf dauert zu lange, um ihn in den Build zu nehmen. Wir haben ihn während des Umbaus einige Male von Hand gestartet.

Der Umbau hat die Tests, an denen der Agent arbeitet, vom E2E-Scope auf Unit-Scope gebracht. Einen Unit-Test kann er nun gezielt für die Klasse laufen lassen, an der er arbeitet, und bekommt in Sekunden Antwort. Ein Test, der den kompletten Stack braucht, zwingt ihn immer zum vollen Lauf.

Wenn der Sensor der Mensch ist

Die langsamste Verifikation in jedem Projekt ist der Mensch. Addy Osmani beschreibt in Agentic Code Review:

writing code was the slow, expensive part, and reading it was cheap and fast. That fact no longer holds. [...] the constraint moved downstream, to the one step that did not get faster.

Jeder Sensor im Coding Loop ließ sich in unserem Projekt schneller machen, also Compiler, Tests und Linter. Für das Lesen eines Pull Requests gibt es diesen Hebel nicht. Wer tausend geänderte Zeilen prüft, braucht dafür so lange wie immer schon.

Ein schnellerer Coding Loop treibt das weiter. Der Agent schafft mehr Runden, also entstehen mehr Änderungen, die jemand lesen muss. Was der Build selbst findet, kommt gar nicht erst vor dem Reviewer an.

Huntley hat zu Pre-Commit-Hooks eine Bemerkung gemacht, die das aufgreift. Hooks galten immer als lästig, weil sie Menschen aufhalten. Wenn der Agent den Commit macht, wartet der Agent auf den Hook. Die Sekunden zahlt niemand mehr aus seiner eigenen Zeit. Ein Fehler, den der Hook abfängt, kommt nicht mehr im Review an.

Wo der Mensch bleibt

Der Mensch wechselt dadurch vom inneren in den äußeren Loop. Osmani nennt das "human on the loop". Das deckt sich mit dem, was wir in eigenen Projekten für das Zielmodell halten. Wir bauen den Rahmen, beobachten, was durchrutscht, und verbessern den Rahmen.

Für eine Frage bleibt der Mensch zuständig. Automatisierung hilft dort strukturell nicht. Simon Willison hat sie in Hallucinations in code so formuliert:

No amount of meticulous code review—or even comprehensive automated tests—will demonstrably prove that code actually does the right thing.

Ob der Code läuft, klärt der Build. Für die Frage, ob es die richtige Änderung war, gibt es keinen Sensor. Dazu kommen die Pfade, bei denen ein Fehler weit ausstrahlt, also Sicherheit, Architektur, alles mit langer Lebensdauer. Dort lohnt sich menschliches Lesen weiterhin. Über den Aufwand entscheidet das Risiko der Änderung. Die Frage nach dem Autor spielt dabei keine Rolle. Wer eine Änderung in den Hauptzweig lässt, trägt die Verantwortung für das Ergebnis, auch wenn ein Review-Agent vorher zugestimmt hat.

Die trivialen Rückmeldungen gehören automatisiert, also doppelte Imports, Formatierung, offensichtliche Regressionen. Was übrig bleibt, ist die Frage, ob das Ergebnis fachlich stimmt. Dafür braucht es Menschen, die noch Kapazität haben.

Dieselbe Frage stellt sich auf jeder Ebene über dem Coding Loop. Wie lange dauert es, bis eine Rückmeldung da ist? Wie viel davon läuft von allein? Automatisieren lässt sich eine Stufe nur, wenn ein Werkzeug die Rückmeldung übernimmt. Im Coding Loop stehen diese Werkzeuge seit Jahren bereit. Auf den Ebenen darüber muss man sie meistens erst bauen und den Prozess darauf auslegen.

Die Agenten wirken wie eine Lupe

Die acht Minuten waren vorher genauso lang. Zwischen zwei Builds lag früher aber eine halbe Stunde Denken und Tippen. Darin ging die Wartezeit unter. Das Tempo der Agenten wirkt auf solche Zahlen wie eine Lupe. Was sich früher im Takt menschlicher Arbeitsschritte versteckte, steht jetzt dutzende Male pro Session im Weg.

Unter dieser Lupe liegen die Sachen, die Teams schon vor den Agenten geärgert haben. Ein langsamer Build, eine Test-Suite mit zu viel E2E-Gewicht, Unit-Tests mit Lücken, ein Review-Stau vor dem Merge.