Dein KI-Coding-Agent hat die Nacht durchgearbeitet. Montagmorgen öffnest du das Dashboard und es leuchtet: 14 Pull Requests erstellt, 2.000 Zeilen geändert, drei Features aufgesetzt. Du nippst an deinem Kaffee und fühlst dich, als hättest du umsonst einen Junior-Entwickler eingestellt.
Dann liest du den Code tatsächlich. Die Hälfte dieser PRs enthält Fixes für Bugs, die der Agent zwei Commits vorher in derselben Session eingebaut hat. Eine Funktion wurde geschrieben, kaputtgemacht, neugeschrieben, wieder kaputtgemacht und landete schließlich beim fünften Versuch. Das Dashboard hat jeden Versuch als produktive Arbeit gezählt.
Willkommen bei der Rework Ratio — der Metrik, über die niemand reden will, der dir KI-Coding-Tools verkauft.
In einer Agent-Session
Im letzten Monat haben alle großen Coding-Tools autonome Agents ausgeliefert. GitHub Copilot und Cursor 3 haben ihre Anfang April gelauncht; Claude Code Routines folgten am 14. April; OpenAI Codex erweiterte auf Multi-Agent-Workflows am 16. April. Jedes Tool läuft in unüberwachten Iterationsschleifen — der Agent schreibt Code, prüft ob er funktioniert und versucht es erneut, wenn nicht.
Das "versucht es erneut" ist genau die Stelle, wo die Rechnung nicht mehr aufgeht. Hier eine komprimierte, aber repräsentative Session eines Agents, der einen User-Authentication-Endpoint hinzufügen sollte. Dreiundvierzig Minuten. Zwölf Commits:
| # | Commit-Nachricht | Typ |
|---|---|---|
| 1 | Add auth route handler | Neue Arbeit |
| 2 | Add JWT token generation | Neue Arbeit |
| 3 | Fix import error in auth.py | Rework |
| 4 | Add password hashing | Neue Arbeit |
| 5 | Fix type error in hash function | Rework |
| 6 | Rewrite auth route to fix 500 error | Rework |
| 7 | Add input validation | Neue Arbeit |
| 8 | Fix validation regex causing test failure | Rework |
| 9 | Fix test broken by commit 6 | Rework |
| 10 | Add rate limiting middleware | Neue Arbeit |
| 11 | Fix rate limiter config path | Rework |
| 12 | Clean up unused imports from iterations | Rework |
Fünf Commits bringen das Feature voran. Sieben reparieren Probleme, die der Agent in derselben Session verursacht hat. Das ist eine Rework Ratio von 58% — mehr als die Hälfte des Aufwands geht dafür drauf, den eigenen Output zu korrigieren.
Das Dashboard meldete 12 Commits, 847 geänderte Zeilen, ein Feature fertiggestellt. Alles technisch korrekt. Alles irreführend.
Wie man die Rework Ratio berechnet
Das ist keine Theorie. Du kannst sie aus jedem Repository extrahieren, in dem Agents arbeiten:
Rework Ratio = (Commits, die Code ändern, der früher in derselben Agent-Session geschrieben wurde) ÷ (Gesamtzahl der Commits in der Session)
Führe git log --diff-filter=M auf einem agentgenerierten Branch aus. Markiere jeden Commit, der eine Datei ändert, die der Agent in derselben Session schon angefasst hat. Trenne echte Erweiterungen (eine neue Funktion in einer bestehenden Datei) von Korrekturen (reparieren, was gerade kaputtgegangen ist). Die Ratio steckt direkt in der Diff-Historie.
GitClears Code-Quality-Report vom April 2026 hat ein verwandtes Signal gemessen — Code-Churn innerhalb von 72 Stunden nach dem Schreiben — und fand 7,1% bei KI-gestützten Projekten gegenüber 3,2% bei rein menschlichen Baselines. Aber das erfasst Churn nach dem Merge — Code, der ausgeliefert wird und dann umgeschrieben werden muss. Der Intra-Session-Churn, bei dem der Agent seinen eigenen Code kaputt macht und wieder repariert, bevor du den Pull Request überhaupt siehst, bleibt für jedes existierende Messinstrument unsichtbar.
Das ist die Lücke. GitClear misst Post-Merge-Churn. Vendor-Dashboards messen Aktivität. Niemand misst das Rework, das innerhalb der eigenen Schleife des Agents passiert.
Die Dashboard-Lüge
Rechne es für ein echtes Team durch. Sagen wir, deine Agents laufen 50 Sessions pro Woche über 10 Engineers, im Schnitt 12 Commits pro Session. Wenn die typische Rework Ratio bei 55% liegt:
- 50 Sessions × 12 Commits = 600 Commits/Woche (was das Dashboard zeigt)
- 600 × 0,55 = 330 Commits, die nichts produziert haben, was ausgeliefert wird
- 330 Rework-Commits × ~$0,15 durchschnittliche Token-Kosten = ~$50/Woche, verbrannt für das KI-Äquivalent von Rücktaste drücken
Skaliere das hoch. Eine Organisation mit 100 Engineers, die Agents aggressiv einsetzt, verbrennt monatlich $2.000–$5.000 an Tokens, die null Netto-Code erzeugen. Das Dashboard nennt das "KI-gestützte Entwicklung". Die GuV nennt es Verschwendung.
Wie mehrere Analysen dieses Jahr bestätigt haben — KI-generierter Code bringt rund 1,7× mehr Issues pro PR mit als menschlicher Code, Incidents steigen proportional zum KI-Output, und die Zuverlässigkeit von Agents wächst mit der halben Geschwindigkeit der Fähigkeiten. Die Rework Ratio erklärt einen Teil des Mechanismus: Code, der fünf interne Rewrites überlebt hat, trägt die architektonischen Narben der ersten vier Versuche. Funktionen werden durch Debugging-Historie geformt, nicht durch Design-Intention.
Was nach dem Rework übrig bleibt
Streiche die Selbstkorrektur-Schleifen raus, und der ehrliche Produktivitätsgewinn liegt bei den meisten Teams bei etwa 1,5–2×. Larridins Q1-2026-Produktivitäts-Benchmarks fanden heraus, dass die KI-Nutzung in Engineering-Teams um 65% gestiegen ist, während der PR-Durchsatz nur um etwa 10% gewachsen ist. Die Kluft zwischen Adoption und Output erklärt sich teilweise dadurch, dass Rework die Differenz auffrisst.
Die versteckten Kosten sind nicht nur Tokens. Jeder Korrekturzyklus fügt dem finalen Code defensive Komplexität hinzu. Variablennamen spiegeln Debugging-Historie wider statt Domänenkonzepte. Abstraktionen sammeln Guard Clauses aus vorherigen fehlgeschlagenen Versuchen an. Der Code funktioniert, aber er liest sich, als hätte ihn jemand geschrieben, der ständig seine Meinung geändert hat — weil genau das passiert ist.
Die Metrik, die den Einkauf verändern würde
Stell deinem KI-Coding-Tool-Anbieter vor dem nächsten Sprint Planning eine einzige Frage: Wie viel Prozent der Agent-Aktionen in einer Session korrigieren den eigenen vorherigen Output des Agents?
Ich habe jedes Dashboard, jede Analytics-Seite, jeden Engineering-Intelligence-Report der großen Tools geprüft, die diesen Monat Agents ausliefern. Keiner trennt "nützliche neue Arbeit" von "der Agent streitet mit sich selbst".
Der erste Anbieter, der diese Metrik ausliefert — ehrlich aufgeteilt in neue Arbeit und Selbstkorrektur — gewinnt die Enterprise-Deals. Nicht weil die Zahl gut aussehen würde (wird sie nicht), sondern weil sie etwas demonstriert, das bisher kein Anbieter geliefert hat: Ehrlichkeit darüber, was autonomes Coding tatsächlich produziert.
Du musst nicht warten. Clone irgendeinen agentgenerierten Branch. Lies die Commits der Reihe nach. Zähle die, die reparieren, was der Agent gerade kaputtgemacht hat.
Dein Dashboard sagt 10×. Dein Git-Log sagt was anderes. Glaub dem Git-Log.
