Das 23,5-Prozent-Problem: Warum KI-unterstützte Pull Requests mehr Incidents verursachen

Letztes Quartal bat uns ein Mittelstandskunde, sich sein Incident-Log anzusehen. Neun Monate zuvor hatte er den Großteil seiner Entwickler auf Claude Code und Cursor umgestellt. Das PR-Volumen war gestiegen, die Zufriedenheitsumfragen fielen glänzend aus, und die Produktions-Incidents waren im Jahresvergleich um 31 % gestiegen — mit einer deutlichen Verschiebung hin zu "wir haben eine Regression gemergt, die im Review niemand erwischt hat".

Dieses Muster ist kein Bauchgefühl. Der Cortex 2026 Engineering Benchmark (opens in new tab) liefert die Zahlen dazu: Pull Requests pro Autor sind im Jahresvergleich um 20 % gestiegen, Incidents pro Pull Request um 23,5 % und die Change Failure Rate liegt rund 30 % höher. Die Werkzeuge haben einzelne Entwickler schneller und das Gesamtsystem gleichzeitig unzuverlässiger gemacht.

Wir sind nicht gegen KI — wir liefern jeden Tag KI-generierten Code über ZahlFlow, Commersio, FlexiLearn, BookMe, Ordrino und iCAS aus. Aber wir behandeln "das hat ein LLM geschrieben" inzwischen als erstklassiges Signal im Code Review.

Die Entkopplung von Durchsatz und Qualität ist real und messbar

GitClear hat 211 Millionen geänderte Codezeilen von 2020 bis 2024 ausgewertet (opens in new tab) und festgestellt, dass der Refactoring-Anteil von 25 % der geänderten Zeilen 2021 auf unter 10 % im Jahr 2024 gefallen ist, Copy-Paste-Klone von 8,3 % auf 12,3 % gewachsen sind und der kurzfristige Churn spürbar gestiegen ist. KI hat es billiger gemacht, eine zweite Implementierung hinzuzufügen, als die erste zu erweitern, und Entwickler haben den billigeren Weg gewählt.

Auf der Security-Seite hat Veracodes 2025 GenAI Code Security Report (opens in new tab) festgestellt, dass 45 % der Samples eine OWASP-Top-10-Schwachstelle eingeführt haben, wobei XSS-Abwehrmechanismen in 86 % der einschlägigen Aufgaben versagten. Der unangenehme Befund: Die Security-Performance stagniert über Modellgenerationen hinweg. Modelle werden besser darin, Funktionstests zu bestehen, nicht darin, Log-Injection-Sinks zu vermeiden.

CodeRabbits Vergleich von 470 Open-Source-PRs (opens in new tab) zeigt, dass KI-generierte PRs insgesamt 1,7× mehr Issues enthalten (10,83 gegenüber 6,45 pro PR), wobei Security-Issues 2,74× häufiger auftreten. "KI macht Entwickler 20 % produktiver" und "KI liefert 23,5 % mehr Incidents pro Merge aus" sind dieselbe Aussage in unterschiedlichen Einheiten.

Warum das passiert: Comprehension Debt trifft auf Reviewer-Ermüdung

Addy Osmanis Begriff der Comprehension Debt (opens in new tab) (Verständnisschuld) ist die sauberste Diagnose: "die wachsende Lücke zwischen der Menge an Code, der in Ihrem System existiert, und dem Anteil, den irgendein Mensch tatsächlich versteht." Ein Junior-Entwickler mit Claude generiert inzwischen schneller Code, als ein Senior ihn kritisch auditieren kann. Osmani zitiert eine Anthropic-Studie, in der Ingenieure mit KI-Unterstützung in einem Folge-Verständnisquiz 17 Prozentpunkte niedriger abschnitten, mit den größten Abständen beim Debugging.

Der Mechanismus verstärkt sich im Review durch drei neue Formen der Ermüdung:

Falsche Flüssigkeit. LLM-Code liest sich gut — idiomatische Namen, vollständige Sätze in Kommentaren, vertrauter Kontrollfluss. Reviewer mustern ihn nach dem Schema "sieht aus wie Code, den ich selbst geschrieben hätte" und winken ihn durch. Veracodes 45 % sind fast vollständig das.

PR-Size-Creep. Die Grenzkosten für "noch eine Sache" sind gefallen, als der Autor aufgehört hat, sie zu tippen. Anthropics 2026 Agentic Coding Trends Report (opens in new tab) beschreibt Agenten, die sieben Stunden am Stück laufen — Code, der immer noch durch einen menschlichen Review-Slot muss, der für einen 200-Zeilen-Diff ausgelegt ist.

Novelty Inversion. Vor KI gingen Reviewer davon aus, dass der Autor "warum so und nicht anders?" beantworten konnte. Nach KI hat der Autor die Alternative möglicherweise nie erwogen. Die deutsche Umfrage unter Softwareingenieuren (opens in new tab) bringt die Reaktion erfahrener Ingenieure auf den Punkt: "in komplexen Projekten sind Halluzinationen überall" und das Risiko von "KI-generierter Software, getestet mit KI-generierten Tests."

Worin KI im Review tatsächlich gut ist — und worin nicht

Gut eingesetzt, findet ein KI-Reviewer Namensinkonsistenzen, fehlende Null-Checks, offensichtliche n+1-Queries und Dokumentationslücken. Anthropics Claude-Code-Review-Feature (opens in new tab) meldet Funde in 84 % der Reviews über 1.000 Zeilen. Wir lassen es auf jedem PR laufen, und es hat eine echte Trefferquote bei der langweiligen, aber wichtigen Klasse von Defekten.

Worin KI-Review nicht gut ist: Ihnen zu sagen, dass der PR einer Designentscheidung von vor sechs Monaten widerspricht, oder dass der neue Endpoint einen in einem Modul dupliziert, das der Autor nie geöffnet hat, oder dass der Autor ein Junior ist, der dieses Muster lernen sollte, indem er es selbst schreibt. KI-Review ist ein besserer Linter. Die Engineering-Konversation müssen weiterhin Menschen führen.

Fünf Review-Disziplinen, die den Abstand tatsächlich schließen

Keine davon verbietet KI. Alle erhöhen die Kosten dafür, Code auszuliefern, den niemand versteht.

1. Kleine PRs, erzwungen

Wir begrenzen KI-unterstützte PRs auf 400 Diff-Zeilen, ohne Lockfiles und generierten Code. PRs unter 400 Zeilen produzierten in unseren Monorepos 3,1 Incidents pro 1.000 gemergten PRs; PRs über 800 Zeilen produzierten 11,4. Halbiert man den Diff, verdoppelt sich die Aufmerksamkeit pro Zeile ungefähr.

2. Pflicht-"Was und Warum" in der Beschreibung

Jeder PR beginnt mit zwei Absätzen: Was die Änderung auf Verhaltensebene macht, und warum sie die richtige Änderung ist. Kann der Autor die Änderung nicht artikulieren, hat er nicht verstanden, was die KI produziert hat — und der Reviewer wird es auch nicht. Reviewer berichten, dass PRs mit echten Beschreibungen weniger Zeit kosten, weil die Beschreibung die Kontextaufbauarbeit leistet.

3. Property- und Mutation-Tests auf KI-berührten Modulen

Für jedes Modul, bei dem in den letzten 90 Tagen eine KI mehr als 30 % der Zeilen geschrieben hat, verlangen wir Property-basierte Tests (fast-check, hypothesis) plus ein Mutation-Testing-Gate (Stryker, mutmut) mit einer Kill-Rate-Untergrenze von 70 %. LLMs schreiben häufig Tests, die genau auf den Beispielen bestehen, die sie selbst bedacht haben; Property Tests sondieren den Raum, den sie nicht bedacht haben. Das ist die einzige Technik, die wir gefunden haben, die zuverlässig die Veracode-Klasse von Fehlern fängt.

4. Diff-first-Review, nicht File-first

Wir verlangen, dass das Review beim Commit-für-Commit-Diff beginnt und die Änderung in der Reihenfolge liest, in der der Autor sie gemacht hat. Das zwingt Reviewer, Intent zu rekonstruieren, statt den Endzustand zu bewerten — der einzige Weg zu bemerken, dass Commit 3 etwas rückgängig gemacht hat, das Commit 1 etabliert hatte.

5. Static Analysis, abgestimmt auf KI-Idiome

Out-of-the-box-Linter verpassen Dinge, die LLMs tun und Menschen selten: doppelte Utility-Funktionen über Dateien hinweg, hartkodierte Magic Values mit subtilem Drift, defensiver Code, der Fehler verschluckt. Wir haben eigene Semgrep (opens in new tab)-Regeln und SonarQube-Profile ergänzt, die diese markieren. Wenn 12,3 % der neuen Zeilen Klone sind, muss der Analyzer das bemerken.

Das Explain-Back-Gate

Bevor ein Reviewer einen KI-unterstützten PR approved, fügt er eine zwei- bis viersätzige Zusammenfassung der Änderung ein — in eigenen Worten, als Top-Level-Kommentar. Keine Beschreibung des Diffs; eine Beschreibung der Änderung am System.

Vier Konsequenzen, die wir alle wollen: Der Reviewer kann nicht approven, was er nicht versteht; der Autor erhält einen kostenlosen Verständnis-Check; das Team sammelt ein Korpus an Zusammenfassungen, das zur besten internen Dokumentation wird, die man hat; und es setzt die Machtdynamik zwischen Autor und Reviewer gegen den Drift der Comprehension Debt zurück.

Der Einwand, den wir hören: "Das verlangsamt Reviews." Tut es, am Anfang. Nach einem Monat beschleunigt es sie, weil Reviewer aufhören, mehrdeutige PRs zu approven und sie aus der Produktion zurückgeschickt zu bekommen. Bei unserem Kunden ist die Incident-Rate pro PR innerhalb von zwei Sprints nach Einführung dieses Gates von der um 23,5 % erhöhten Baseline wieder unter die Vor-KI-Baseline gefallen.

Was man nicht tun sollte

Verbieten Sie KI-Assistenten nicht. Das Produktivitätssignal ist real. Verbote treiben die Werkzeuge in den Untergrund und kosten den Durchsatzzuwachs bei eindeutig guten Anwendungen — Boilerplate, Test-Scaffolds, Übersetzungen.

Verlangen Sie nicht, dass Menschen KI-Code von Hand neu schreiben. Wir haben es versucht. Es produziert KI-Code, den ein Mensch abgetippt hat, was strikt schlechter ist als reiner menschlicher Code oder reviewter KI-Code. Das einzig zuverlässige Ergebnis ist Groll.

Ignorieren Sie das Incident-Signal nicht. Das schlimmste Muster ist Führung, die Durchsatzmetriken zitiert ("PRs um 20 % hoch!"), während die On-Call-Rotation im Stillen die 23,5 % absorbiert. In dieser Lücke wohnt Burnout.

Setzen Sie nicht zu sehr auf KI-Review-Tools als Lösung. Sie fangen die Klasse von Bugs, die für Menschen ohnehin billig zu fangen war. Die "das widerspricht unserer Architektur"-Klasse ist genau die, die KI-Review nicht adressieren kann, weil es Ihre Architektur nicht kennt.

Die härtere Wahrheit: KI hat verschoben, wo Engineering-Aufwand hinfließt. Code zu schreiben wurde billiger. Code zu verstehen wurde teurer. Review-, Test- und Dokumentationsbudgets müssen alle entsprechend steigen. "KI macht Sie schneller" hat ein Sternchen: genau dann, wenn Ihre Review-Disziplin mit Ihrer Generierungsgeschwindigkeit Schritt gehalten hat.