Die Velocity-Falle

Warum Generierung die Verifikation überholen und den echten Delivery-Durchsatz senken kann.

Die Velocity-Falle: Generierung überholt Verifikation

In einem agentischen Workflow ist Code-Generierung billig, und die Verifikation wird zum Bottleneck. Der Wert von Engineers hängt dann davon ab, wie gründlich sie die Korrektheit einer generierten Funktion nachweisen. Wie schnell sie selbst eine Funktion schreiben, zählt weniger. Die Velocity-Falle (Velocity Trap) schnappt zu, wenn die Generierung der Verifikation davonläuft. Ein Team führt Agents ein, der Output schießt nach oben, und das Team prüft den neuen Code weiter auf die alte Art. Senior Engineers öffnen einen agentengenerierten Pull Request mit tausend Zeilen und überfliegen ihn. Das LLM ermüdet nicht, die Reviewer:innen aber schon. Sie gehen von “probably got it right” aus und geben frei.

Die gefühlte Geschwindigkeit ist echt, der tatsächliche Durchsatz kann trotzdem sinken. Ungeprüfter Code erzeugt nämlich eigene Nacharbeit. Dazu gehören inkompatible Muster im State Management, halluzinierte Datenbankstrategien und Edge-Case-Bugs, die erst in Produktion auftauchen. Es gibt nur einen Ausweg: Automatisiert die Verifikation. Wenn ihr den Output eines Agents nicht automatisch verifizieren könnt, solltet ihr den Agent nicht einsetzen.

Der March of Nines erklärt, warum beeindruckende Demos täuschen. Eine Agent-Demo funktioniert in etwa 90 % der Fälle, nämlich auf dem Happy Path. Diese erste Neun ist billig, weil sie die Trainingsdaten dominiert. Enterprise-Software braucht vier oder fünf Neunen. Jede weitere Neun kostet ungefähr so viel Engineering-Aufwand wie die vorige, während die sichtbare Verbesserung schrumpft. Die zweite Neun verlangt Edge Cases und Fehlerbehandlung, die dritte Race Conditions und Timeout-Handling, die vierte Skalierung und Query-Optimierung. Addy Osmani nennt dieselbe Form das 70-%-Problem: KI kommt etwa 70 % des Weges weit, und die letzten 30 %, also Edge Cases, Architektur, Tests und Aufräumen, brauchen weiter die Arbeit der Engineers (The AI-Native Software Engineer, Addy Osmani (öffnet in einem neuen Tab), 5. Dezember 2025). Die billige Masse kommt zuerst, die eigentliche Engineering-Arbeit steckt im harten Rest.

Geschlossene Loops tragen den Agent auf dieser Leiter so weit nach oben, wie Automatisierung reicht. Doch die Leiter hat ein oberes Ende. Die Race Condition beim verteilten Locking, der Timeout, der die Abrechnung korrumpiert, die N+1-Query, die den Cluster zum Schmelzen bringt: Genau diese Fehler fangen Unit-Tests, Typen, Linter und CI allein nicht ab. Dieser Rest sind die letzten 30 %, und sie bleiben beim menschlichen Urteil, nicht bei einem weiteren Check.

Berichte aus dem Inneren von Anthropic beziffern diese Aufteilung. Der Umbau der Bun-Runtime von Zig nach Rust umfasste 535.496 Zeilen ohne Kommentare. Vom Start bis zum Merge vergingen elf Tage, mit 64 parallelen Agents und Tokens für 165.000 $ zu API-Preisen. Geschätzt war dafür rund ein Jahr für drei Engineers mit vollem Kontext. Die Implementierung machte etwa 15 % des Aufwands aus, das Fixen und Validieren des Ergebnisses die übrigen 85 %.

Zwei Voraussetzungen machten diese elf Tage möglich, und die Agents waren keine davon. Die bestehende Test-Suite war in TypeScript geschrieben und hing deshalb nicht von der Implementierungssprache ab. So bewertete sie den neuen Code, ohne vorher portiert zu werden. Die fachliche Einschätzung, die den Agents fehlte, kam von der Person, die die Runtime geschaffen hat. Der Head of Platform Engineering des Labs formuliert die These dieser Seite in denselben Worten: Verifikation kostet mehr Zeit als Implementierung. Laut den Engineers dort fließen die meisten Tokens in Discovery, Prototyping, Mocking und Verifikation statt ins Schreiben des Codes (The Pragmatic Engineer - How software gets built at Anthropic (öffnet in einem neuen Tab), Juli 2026, kostenpflichtig).

Quellen

Praxisberichte

• The Pragmatic Engineer - How software gets built at Anthropic (öffnet in einem neuen Tab) - Kostenpflichtiger, interviewbasierter Bericht über die Engineering-Praxis in einem KI-Lab, mit Aufwandsverteilung, Agent-Zahlen und Token-Kosten aus zwei ausgelieferten Projekten.