31% Entwicklerzeit geht für unsichtbare Arbeit drauf
Der Harness-Report zeigt: KI-Tools steigern den Code-Output, aber die Review-Last explodiert. Teams messen die Gewinne und übersehen die Kosten.
Ein Entwickler generiert mit Copilot oder Claude Code doppelt so viele Pull Requests wie vor einem Jahr. Die Velocity-Metriken im Sprint-Board sehen fantastisch aus. Der Engineering-Manager berichtet stolz nach oben. Und trotzdem hat das Team das Gefühl, am Limit zu sein.
Der "State of Engineering Excellence 2026"-Report von Harness liefert jetzt Zahlen zu diesem Phänomen. 700 Engineering-Practitioners und -Manager aus den USA, UK, Indien, Frankreich und Deutschland wurden befragt. Die Ergebnisse zeigen ein Paradox, das viele Teams kennen, aber bisher nicht beziffern konnten.
Die Zahlen
89% der Engineering-Leader sagen, dass KI-Coding-Tools die Produktivität ihres Teams verbessert haben. 88% sagen, die Zufriedenheit der Entwickler sei gestiegen (Quelle: Harness Pressemeldung). Klingt nach Erfolg.
Gleichzeitig: 81% berichten, dass ihre Entwickler mehr Zeit in Code-Reviews verbringen als vor der KI-Adoption. Die Schätzung laut Report: Rund 31% der Entwicklerzeit fließt inzwischen in das, was Harness "unsichtbare Arbeit" nennt. Dazu gehören:
- KI-generierten Code reviewen und verstehen
- Bugs fixen, die aus generiertem Code entstehen
- Context-Switching zwischen Tools
- Prompts iterieren, bis das Ergebnis passt
Und hier kommt der eigentliche Widerspruch: 94% der Befragten geben zu, dass ihre aktuellen Metriken Faktoren wie Tech Debt, Validierungszeit, kognitive Last und Burnout nicht erfassen (Quelle: Harness Blog). Man misst den Output und übersieht die Kosten.
Warum das passiert
KI-Coding-Tools senken die Kosten für das Erstellen von Code auf nahezu null. Aber Code schreiben war nie der Engpass. Der Engpass war immer: Code verstehen, Code bewerten, sicherstellen dass er mit dem Rest des Systems funktioniert.
Wenn ein Agent in 20 Minuten 500 Zeilen Code erzeugt, muss jemand diese 500 Zeilen verstehen. Nicht nur syntaktisch, sondern im Kontext der bestehenden Architektur. Ob der Agent die Randfälle bedacht hat. Ob die Fehlerbehandlung stimmt. Ob die Namenskonventionen passen. Das ist kognitive Arbeit, die in keinem Sprint-Burndown auftaucht.
Das Ergebnis: Mehr Commits, mehr PRs, kürzere Zykluszeiten. Und gleichzeitig höhere Review-Last, mehr Kontextwechsel, schleichende Erschöpfung.
Was Teams anders machen können
Die offensichtliche Antwort "weniger KI-Code generieren" wird niemand umsetzen. Die Produktivitätsgewinne sind real. Aber die Messbarkeit muss sich anpassen.
Review-Last als Metrik einführen. Wieviel Zeit verbringt ein Entwickler pro Woche mit dem Reviewen von Code, den andere (oder Agenten) geschrieben haben? Wenn dieser Wert steigt, während die eigene Coding-Zeit sinkt, hat man ein Verteilungsproblem.
Validation Time messen. Nicht nur "wie schnell geht ein PR durch", sondern "wie viel Aufwand steckt in der Prüfung". Ein PR, der in 2 Stunden gemergt wird, kann trotzdem 45 Minuten konzentrierte Review-Arbeit gekostet haben.
Code-Quality-Indikatoren neben Velocity stellen. Bug-Rate pro generiertem vs. manuell geschriebenem Code. Rework-Quote. Wie oft wird KI-generierter Code innerhalb von zwei Wochen wieder geändert?
Kognitive Last ansprechen. In Retros fragen: "Wo verbringt ihr Zeit, die in keinem Ticket steht?" Die Antworten werden unbequem sein.
Zweite Welle braucht andere Metriken
Die Harness-Zahlen passen ins Bild, das wir hier seit Wochen beobachten: Die METR- und Faros-Studien zeigen denselben Engpass, und die Fehlerquote bei KI-generiertem Code erklärt, warum Review-Aufwand steigt.
Der Report bestätigt etwas, das sich in vielen Teams abzeichnet: Die erste Welle der KI-Adoption hat die einfach messbaren Kennzahlen verbessert. Jetzt beginnt die Phase, in der man die tatsächlichen Auswirkungen auf Teamgesundheit und Codequalität verstehen muss.
Wer nur Velocity misst, wird bald Leute verlieren. Nicht weil sie langsam sind, sondern weil sie ausbrennen unter einer Review-Last, die in keiner Statistik auftaucht.