Warum werden Teams mit KI-Agenten nicht im gleichen Maß schneller, wie sie Code erzeugen?

Weil Code schreiben nur einen Teil der Arbeit ausmacht. Laut einer Harvard-Studie mit Jellyfish-Daten verbringen Entwickler 30 bis 40 Prozent ihrer Zeit mit Code, der Rest geht in Planung, Review, Tests und Deployment, und genau dort staut sich die zusätzliche Menge.

Liegt der höhere Review-Aufwand an größeren Pull Requests?

Nach der Studie nicht. Die Autoren schreiben, dass der gestiegene Aufwand pro Pull Request nicht dadurch erklärt werden kann, dass einzelne Pull Requests größer geworden wären.

Löst ein KI-Reviewer den Review-Engpass?

Die Studie fand keine Verbesserung durch den Einsatz von KI im Review selbst. Automatisches Review kann Stil- und Import-Kleinkram vorab abfangen, die inhaltliche Prüfung bleibt beim Menschen.

Wo sollten Menschen in einem Agenten-Workflow prüfen?

Bewährt haben sich Prüfpunkte vor dem Code, also bei Spezifikation und Testnamen, und vor dem Merge. Änderungen an Tests sollten automatisch einen menschlichen Reviewer einbinden, etwa über CODEOWNERS.

Reviewzeit statt Tippzeit: der neue Engpass im Team

Wer im Team Claude Code, Cursor oder Codex einführt, sieht schnell mehr Commits und mehr Pull Requests. Dass Tickets entsprechend schneller fertig werden, folgt daraus nicht. Häufig stehen die Änderungen dann im Review-Stau, und die erfahrensten Leute im Team verbringen ihre Tage mit Kommentaren statt mit Architektur. Eine aktuelle Studie liefert dafür erstmals belastbare Zahlen, und ein Erfahrungsbericht eines kleinen Teams zeigt, wie man den Prüfaufwand anders verteilen kann.

Mehr Code heißt nicht mehr erledigte Arbeit

InfoQ berichtet über eine Harvard-Studie, die Daten der Analyseplattform Jellyfish aus 718 Firmen auswertet: rund 300 Millionen Arbeitsereignisse von etwa 700.000 Beschäftigten zwischen Januar 2021 und März 2026. Einbezogen wurden unter anderem Versionskontrolle, Issue-Tracker, Kalender und KI-Tools wie GitHub Copilot, Cursor und Claude Code.

Die Forscher trennen zwischen Coding-Assistenten und Agenten. Assistenten erhöhen die Zahl der Codezeilen um 12 Prozent, der Commits um 9 Prozent und der Pull Requests um 5 Prozent, wobei nur der Effekt auf Commits statistisch signifikant ist. Agenten wirken deutlich stärker: 30 Prozent mehr Codezeilen, 20 Prozent mehr Commits, 23 Prozent mehr Pull Requests.

Gemessen an gelösten Jira-Issues pro Person und Monat sieht es nüchterner aus. Assistenten steigern diesen Wert gar nicht, Agenten um 12 Prozent, also weit weniger, als die 30 Prozent mehr Code erwarten lassen. Die Erklärung der Autoren: Entwickler verbringen nur 30 bis 40 Prozent ihrer Zeit mit dem Schreiben von Code. Der Rest geht in Planung, Review, Tests und Deployment. Wird nur das Schreiben schneller, werden die anderen Schritte zum Engpass.

Wo genau es hakt: im Review

Die deutlichsten Effekte zeigen sich nach dem Öffnen des Pull Requests. Die durchschnittliche Review-Zeit pro Pull Request stieg um 49 Prozent, die Zahl der Kommentare pro Pull Request um 53 Prozent, und der Anteil der Pull Requests, die Änderungen brauchen, hat sich verdoppelt. Gleichzeitig wuchs der Anteil der Beschäftigten, die Reviews übernehmen, um 14 Prozent.

Zwei Details sind für Teamleads besonders wichtig. Erstens lässt sich der Mehraufwand laut den Autoren nicht damit erklären, dass einzelne Pull Requests größer geworden wären. Das Problem ist also nicht allein mit einer Regel zur Diff-Größe gelöst. Zweitens brachte KI-Unterstützung im Review selbst keine messbare Verbesserung. Wer den Stau einfach mit einem zusätzlichen Review-Bot auflösen will, sollte die Erwartungen niedrig halten.

Prüfpunkte vor den Code ziehen

Wie ein Team darauf reagieren kann, beschreibt ein Erfahrungsbericht auf Reddit: Sechs Entwickler an einem SaaS-Produkt haben KI über zwölf Monate schrittweise eingeführt. Sie nutzen bewusst verschiedene Tools, einige Claude Code, einige Codex, einige Cursor. Gemeinsam ist der Prozess, und die Konventionen stehen in einer AGENTS.md im Repository, der einzigen Datei, die alle Tools gleich lesen.

Der Ablauf verlagert die menschliche Prüfung nach vorn:

Der Agent befragt das Team anhand der Projektdokumentation und bringt so Wissen ans Licht, das nie aufgeschrieben wurde.
Daraus entsteht eine Spezifikation, die ein Mensch ernsthaft reviewt. Eine schlechte Spezifikation macht alles danach teuer.
Die Arbeit wird in kleine Tickets geschnitten, damit der Agent nicht abschweift.
Der Agent setzt Ticket für Ticket gegen die Spezifikation um.
Im Pull Request laufen zuerst automatisches Review und Pipelines, dann entscheidet ein Mensch über den Merge.

Das automatische Review fängt Stil- und Import-Rauschen ab, sodass der Mensch sich auf das Wesentliche konzentrieren kann. Das Team prüft Spezifikation und Merge und verzichtet auf das zeilenweise Lesen dazwischen. Den Versuch, Tickets komplett autonom abarbeiten zu lassen, bewertet es offen als Experiment: Die Demos sehen gut aus, die Qualität im eigenen Repository reicht noch nicht.

Die Tests nicht aus den Augen verlieren

In den Kommentaren ergänzen mehrere Entwickler, wo sie trotzdem genau hinsehen. Einer liest Spezifikation und Testnamen, bevor er Code öffnet. Taucht ein Test auf, den niemand verlangt hat, schaut er in den Diff. Ein anderer schlägt vor, die Testordner per CODEOWNERS zu schützen, damit jede Änderung an Tests automatisch einen Menschen einbindet. Wenn die Spezifikation der Vertrag ist, sind die Tests der Nachweis, und genau dort sollte kein Agent unbemerkt Erwartungen anpassen.

# CODEOWNERS
/tests/   @ihr-team/reviewer

Weitere Hinweise aus der Diskussion: Ob ein Ticket eine Spezifikation braucht, hängt eher von der Reichweite der Änderung ab als von ihrer Größe. Riskante Dateien wie Migrationen werden genau gelesen. Mehr Autonomie gibt es zuerst für risikoarme, umkehrbare Tickets. Wie Sie solche Punkte als Teamstandard festhalten, zeigt unsere Review-Checkliste für KI-generierte Pull Requests.

Was das für Ihr Entwicklerteam bedeutet

Die Zahlen sprechen dafür, Review-Kapazität als eigene Größe in die Einführung einzuplanen, statt sie als Nebenwirkung hinzunehmen. Konkret heißt das: Klären Sie, wer Spezifikationen freigibt, wer Agenten-PRs reviewt und welche Pfade immer einen Menschen brauchen. Verankern Sie die Planungsphase im gemeinsamen Ablauf, wie im Beitrag zum Agenten-Workflow aus Plan, Umsetzung und Test beschrieben. Und testen Sie neue Prüfpunkte zuerst in einem Pilotteam, bevor sie für alle gelten.

Ein KI-Reviewer kann Kleinkram vorfiltern, aber die Studie gibt keinen Anlass zu erwarten, dass er den Engpass allein auflöst. Die Entlastung kommt eher aus einem Prozess, in dem Menschen früher und gezielter prüfen.

Fazit

Agenten verschieben Arbeit vom Schreiben ins Prüfen. Teams, die das ignorieren, bekommen mehr Pull Requests und keine schnelleren Tickets. Teams, die Prüfpunkte bewusst setzen, bei Spezifikation, Tests und Merge, nutzen die zusätzliche Geschwindigkeit dort, wo sie ankommt.

Sie wollen Ihre Prüfpunkte zwischen Mensch und Agent am eigenen Repository festlegen, von der Spezifikation bis zu CODEOWNERS? Inhouse-Training anfragen.