Stellen Sie sich eine neue Kollegin vor, die unglaublich schnell arbeitet. Jeder Pull Request ist in zwei Minuten fertig. Sie wird nie müde.
Sie würden sie einstellen. Am ersten Tag würden Sie ihr trotzdem keinen Zugriff auf die Zahlungsinfrastruktur geben. In Woche zwei würden Sie ihre 50-Dateien-PRs nicht durchwinken, ohne genau hinzusehen.
2026 machen viele Engineering-Teams genau das. Mit KI-Agenten statt mit Menschen. Die Velocity-Dashboards sehen besser aus denn je. Gleichzeitig gehen die Pager häufiger los. Beides stimmt. Beides gleichzeitig ernst zu nehmen fällt schwer.
Was passiert hier? KI hat einen Teil der Arbeit beschleunigt: das Schreiben von Code. Der Rest der Pipeline ist beim Tempo von 2023 stehen geblieben. Der Engpass ist nicht verschwunden. Er ist umgezogen.
Kurz gefasst: KI verkürzt die Code-Erzeugung, verschiebt den Engpass aber in den Review. Die Telemetrie von Faros über rund 22.000 Entwickler zeigt plus 441 Prozent PR-Review-Zeit und plus 242 Prozent Incidents pro Pull Request in Phasen hoher KI-Adoption. Die Lösung ist kein weiteres Tool, sondern benannte Reviewer, Risk Lanes und ein Change-Budget von drei Dateien pro PR.
Wer den Review-Engpass im Kontext der gesamten Agent-Einführung sehen will, findet im Überblick zu Coding Agents im Entwicklerteam den breiteren Rahmen.
Warum sich Produktivität so schwer messen lässt
Eine der interessantesten Zahlen dieser Debatte kam im Juli 2025 vom Forschungsinstitut METR. Die Studie war ein echtes Experiment: Erfahrene Open-Source-Maintainer arbeiteten an ihren eigenen, reifen Repositories. Per Zufall bekam die eine Hälfte KI-Assistenz, die andere nicht.
Das Ergebnis: Die Entwickler mit KI schätzten sich rund 20 Prozent schneller ein. Gemessen wurden sie 19 Prozent langsamer.
Diese Zahl war ein Warnsignal. Aber sie ist nicht das Ende der Geschichte.
Im Februar 2026 hat METR die eigene Studie neu eingeordnet. In den Rohdaten des neuen Experiments sah das Bild anders aus: Bei einem Teil der ursprünglichen Entwickler lag die Schätzung nun bei 18 Prozent schneller. Das Konfidenzintervall reichte von 38 Prozent schneller bis 9 Prozent langsamer. Bei neu rekrutierten Entwicklern war der Effekt kleiner: 4 Prozent schneller, mit breiter Streuung. METR betont zugleich, dass diese Daten wegen Selektions- und Messproblemen nur schwache Evidenz für die tatsächliche Größe des Effekts liefern.
Was ist die Lehre? Nicht dass eine Zahl richtig und die andere falsch ist. Die Lehre ist, dass sich das Messobjekt verändert. Tooling wird besser. Entwickler gewöhnen sich an die Werkzeuge. Die Besten mit KI wollen nicht mehr an Studien teilnehmen, in denen ihnen die KI weggenommen wird. All das verschiebt das Ergebnis.
Für Velocity-Dashboards in Ihrer Organisation gilt dasselbe Problem. Was sie messen, verhält sich 2026 anders als 2023. Und die Frage, ob ein einzelner Entwickler mit KI schneller tippt, ist für die Teamleistung ohnehin zu eng gefasst. Die bessere Frage: Was passiert, wenn viele Entwickler schneller Code erzeugen, als Review, Verständnis und Betrieb ihn aufnehmen können?
Warum schnelleres Tippen nicht gleich schnellere Lieferung ist
Gene Amdahl hat das schon 1967 beschrieben. Der Gesamtgewinn einer Pipeline wird durch den langsamsten Abschnitt begrenzt. Beschleunigen Sie einen Schritt, wandert der Engpass zum nächsten.
Konkret: Wenn Code-Generierung 25 bis 35 Prozent des Entwicklungszyklus ausmacht, bringt selbst eine Verdopplung dieses Schritts nur grob 15 bis 25 Prozent Beschleunigung für das Gesamtsystem. Der Rest der Zeit geht für Spezifikation, Review, Tests, Integration und Betrieb drauf. Diese Schritte bleiben gleich schnell oder werden sogar langsamer, weil mehr Code durch sie hindurch muss.
Frank Westphal hat in Wenn sich der Engpass verschiebt denselben Mechanismus für eine frühere Generation deutscher Entwicklungsteams beschrieben. Die Lektion wird regelmäßig wiederentdeckt.
Was die Daten auf Systemebene zeigen
Die härtesten Zahlen zum Systemverhalten liefert die Telemetrie von Faros AI. Ihre Acceleration-Whiplash-Auswertung 2026 vergleicht innerhalb derselben Organisationen Zeiträume niedriger und hoher KI-Adoption. Das sind Daten von rund 22.000 Entwicklern in mehr als 4.000 Teams, über zwei Jahre hinweg.
Die Ergebnisse:
Diese Zahlen stammen nicht von Teams, die ihre Metriken nicht im Griff haben. Faros sieht nur Unternehmen, die Engineering-Metriken überhaupt sauber tracken. Das macht die Zahlen unangenehmer, nicht harmloser.
In der Praxis sieht das nicht spektakulär aus. Es sieht aus wie ein ganz normaler Dienstag: Zehn PRs offen, drei davon mit Agentenarbeit, zwei Reviewer in Meetings, ein Incident aus der Vorwoche noch nicht nachbesprochen. Der Code ist geschrieben. Die Entscheidung bleibt liegen. Genau dort entsteht der neue Stau.
Wo legt Cursor sein Geld hin? Im Dezember 2025 hat die Firma angekündigt, den Code-Review-Anbieter Graphite zu übernehmen. Eine KI-Coding-Plattform erwirbt ein Code-Review-Unternehmen. Das ist eine ehrlichere Roadmap als jede Pressemitteilung.
Warum fast richtig teuer ist
Zum Volumenproblem kommt ein Qualitätsproblem.
CodeRabbit, selbst Anbieter für KI-gestützte Reviews, hat 470 Open-Source-Pull-Requests analysiert. Die KI-mitgeschriebenen PRs enthielten im Schnitt 10,83 Review-Issues, die rein menschlichen 6,45. Das ist grob Faktor 1,7. CodeRabbit verkauft Review-Tools und hat deshalb Interesse daran, Probleme zu finden. Aber das Muster passt zur Faros-Telemetrie: Mehr Output bedeutet nicht automatisch bessere Wartbarkeit.
Die Stack-Overflow-Umfrage 2025 ist keine harte Produktivitätsmessung, aber ein nützlicher Stimmungsindikator. 66 Prozent der Befragten nannten „KI-Lösungen, die fast richtig sind, aber nicht ganz" als Hauptfrustration.
Der Mechanismus dahinter ist klar. Fast richtig ist teuer. Es zwingt den Reviewer, die Domänenlogik nachzubauen. Also genau die Arbeit, die der Vorschlag eigentlich hätte abnehmen sollen.
Eine Studie von Anthropic macht das Problem konkreter. 52 überwiegend als Junior eingestufte Entwickler. Die eine Hälfte bekam KI-Unterstützung, die andere nicht. Danach ein Quiz zum Code-Verständnis. Die KI-Gruppe schnitt 17 Prozent schlechter ab. Die Studie kommt von einem Unternehmen, das KI-Coding-Werkzeuge verkauft. Gerade deshalb ist sie bemerkenswert.
Die praktische Lesart: Die Reviewer der nächsten Jahre werden gerade jetzt daran gewöhnt, KI-generierten Code schlechter zu verstehen als Code, den sie selbst geschrieben hätten. Warum erfahrene Entwickler deshalb skeptisch bleiben, beschreibt der Beitrag zur Senior-Skepsis.
Was heißt das praktisch? Behandeln Sie KI-generierten Code wie den Pull Request einer sehr schnellen Kollegin, der Sie noch nicht vertrauen. Freundlich, aber gründlich. Vertrauensvorschuss ja, Prüfung bleibt Pflicht.
Amazon als umstrittener Fall
Einer der diskutiertesten Datenpunkte des Jahres betrifft AWS.
Die Financial Times berichtete Ende 2025 und Anfang 2026 über eine Reihe von Vorfällen in der Amazon-Infrastruktur und brachte sie mit dem hauseigenen KI-Coding-Assistenten Kiro in Verbindung. Das Ergebnis: eine interne Entscheidung, nach der Junior- und Mid-Level-Engineers für KI-gestützte Änderungen an kritischen Systemen ein Senior-Sign-off einholen müssen.
Amazon widersprach. In der offiziellen Stellungnahme wird der Cost-Explorer-Incident auf eine falsch konfigurierte IAM-Rolle zurückgeführt, die mit jedem Werkzeug hätte entstehen können.
Unabhängig von der Ursachenfrage steht fest: Amazon beschreibt zusätzliche Safeguards, darunter verpflichtenden Peer Review für Produktionszugriffe; die FT berichtete zusätzlich über Senior-Sign-off für KI-gestützte Änderungen durch Junior- und Mid-Level-Engineers. Das ist der Review-Engpass, der zur Richtlinie wird.
Bei einer sehr schnellen neuen Kollegin wäre die Reaktion dieselbe: zusätzliches Sign-off, bis das Vertrauen gewachsen ist.
Was Sie jetzt ändern können
Der erste Schritt ist eine Review-Inventur: Wo stapeln sich PRs? Wer reviewt sie? Wie groß sind sie? Welche davon berühren kritische Pfade?
Daraus ergeben sich vier Korrekturen. Keine davon bedeutet, ein neues Tool zu kaufen.
Review-Kapazität gehört in die Planung
Wenn der Code-Ausstoß steigt, muss Review-Kapazität in die Planung. Ein Teil des KI-generierten Codes ist risikoarm und darf durch automatische Gates laufen. Ein Teil berührt kritische Systeme und braucht benannte Reviewer. Die Entscheidung, welcher Code in welche Kategorie fällt, ist eine architektonische Entscheidung. In den meisten Organisationen wird sie heute implizit und unter Zeitdruck getroffen.
Risk Lanes statt Einheitsprozess
Zwei oder drei Spuren reichen. Änderungen mit niedrigem Risiko (interne Werkzeuge, Tests) laufen durch statische Analyse, Typprüfung und Smoke-Tests mit minimaler menschlicher Beteiligung. Kritische Pfade (Auth, Zahlung, regulierte Module) bekommen benannte Reviewer, kleinere PR-Limits und kein agentengesteuertes Merge. Für regulierte Branchen gelten zusätzliche Anforderungen, die der Beitrag zu BaFin und MaRisk beschreibt.
In welcher Spur ein Change landet, entscheidet das Architekturteam. Nicht der einzelne Entwickler und schon gar nicht der Agent. Die Spur wird vor Beginn der Arbeit festgelegt, nicht im Review, wenn der Code schon fertig ist.
Downstream-Metriken statt PR-Zähler
Change Failure Rate, Mean Time to Recovery, Defect Density. PRs pro Woche und Deployment-Frequenz sind Input-Zahlen. Die Output-Zahlen liegen im Betrieb.
Hängen Sie jede Change-Failure an den auslösenden PR, den betroffenen Service und die Review-Spur. Nach vier Wochen sehen Sie, welche Art von KI-Change zu viel Review bekommt und welche zu wenig. Ein Dashboard, das Ihren Pager nicht kennt, misst nur die einfache Hälfte der Pipeline.
Kleine PRs, besonders für Agenten
Faros meldet einen Anstieg der durchschnittlichen PR-Größe in KI-lastigen Teams um 51 Prozent. Ein Review von fünf Dateien dauert Minuten. Ein Review von fünfzig Dateien dauert Tage und findet meistens nicht statt.
Die Zahl, die ich meinen Agenten oft mitgebe und in The Magic Words That Make AI Code Better dokumentiert habe: ein Change-Budget von höchstens drei Dateien und etwa 80 geänderten Zeilen. Größer zu werden ist billig. Reviewbar zu bleiben ist die Disziplin.
Schnell ist nicht gleich produktiv
Schnell tippen ist nicht produktiv. Zuverlässig ausliefern ist produktiv.
Wer Velocity-Dashboards grün meldet, während die Incident-Quote steigt, misst die einfache Hälfte der Pipeline.
Das ist ein Prozessproblem. Prozessprobleme löst man nicht durch eine weitere Lizenz. Die sehr schnelle Kollegin bleibt im Team. Sie bekommt einen kleineren Change-Umfang, benannte Reviewer auf den kritischen Pfaden und einen zweiten Blick, bevor ihr Code in das Zahlungssystem fließt. So führt man Menschen. Inzwischen führt man so auch Werkzeuge.
Wenn Sie den Review-Engpass in Ihrer Organisation vermessen wollen, bevor er sich in der Incident-Kurve selbst vermisst: Ein Review-Audit dauert 60 Minuten. PR-Größen, Review-Zeiten, ungeprüfte Merges, Change-Failure-Rate und kritische Pfade. Sprechen Sie mich an.
Häufige Fragen
- Widersprechen sich die METR-, CodeRabbit- und Anthropic-Zahlen nicht?
- Nein, sie messen unterschiedliche Dinge. METR zeigt, wie schwer Produktivität mit KI überhaupt zu messen ist: Selbstwahrnehmung und Stoppuhr können in verschiedene Richtungen zeigen. CodeRabbit misst Defekt-Dichte pro Pull Request. Anthropic misst Code-Verständnis nach Delegation an KI. Zusammen beschreiben sie kein einzelnes Geschwindigkeitsmaß, sondern ein Systemverhalten: Generierung steigt, Review wird teurer, Verständnis sinkt.
- Ist der Review-Engpass nicht einfach eine Kapazitätsfrage, die mit mehr Reviewern verschwindet?
- Nein, weil Code-Generierung schneller skaliert als menschlicher Review. Ein KI-Agent kann in kurzer Zeit viele Änderungen erzeugen, ohne dass Verständnis, Ownership und Betrieb im gleichen Tempo mitwachsen. Ohne Risk Lanes erhöhen zusätzliche Reviewer die Kosten, aber nicht automatisch das Verhältnis zwischen generiertem und geprüftem Code.
- Sind diese Zahlen auf Engineering-Teams im DACH-Raum übertragbar?
- Richtungsweisend, nicht punktgenau. Faros wertet Telemetrie vor allem aus Organisationen mit reifen Engineering-Metriken aus. Die exakten Prozentwerte sollte kein Team ungeprüft übernehmen. Der zugrunde liegende Mechanismus ist aber nicht regional: Code-Erzeugung wird schneller, während Review-Prozesse und Betriebsverantwortung oft gleich bleiben.
- Ist das Risk-Lane-Konzept nicht einfach Code-Ownership neu verpackt?
- Verwandt, aber anders zugeschnitten. Code-Ownership bindet Verantwortung an Module. Risk Lanes binden Review-Intensität an die Risiko-Klasse eines Changes. Ein Module-Owner darf eine risikoarme Änderung trotzdem durch die schnelle Spur schicken.
Quellen
- METR: Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity (Juli 2025)
- METR: We are Changing our Developer Productivity Experiment Design (Februar 2026)
- Faros AI: Acceleration Whiplash · Takeaways
- CodeRabbit: State of AI vs. Human Code Generation Report
- Stack Overflow: Developer Survey 2025 · AI
- Anthropic: AI Assistance and Coding Skills
- Cursor: Welcoming Graphite to Cursor
- Financial Times: AWS, Kiro und die Folgen
- AWS Newsroom: Offizielle Stellungnahme zum Cost-Explorer-Incident
- Frank Westphal: Wenn sich der Engpass verschiebt
