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

Ein Team stellt den Großteil seiner Entwickler auf Claude Code und Cursor um. Das PR-Volumen steigt, die Zufriedenheitsumfragen fallen glänzend aus, und ein paar Quartale später hat das Incident-Log leise seine Form verändert — immer mehr davon liest sich wie "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. Das ist die langweilige, aber wichtige Klasse von Defekten, und sie zu automatisieren lohnt sich.

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

Begrenzen Sie KI-unterstützte PRs auf einige hundert Diff-Zeilen, ohne Lockfiles und generierten Code. Halbiert man den Diff, verdoppelt sich die Aufmerksamkeit pro Zeile ungefähr — und die Aufmerksamkeit des Reviewers ist die knappe Ressource, um die sich das ganze Problem dreht.

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

Verlangen Sie für Module, in denen ein LLM einen großen Teil der jüngeren Zeilen geschrieben hat, Property-basierte Tests (fast-check, hypothesis) und ein Mutation-Testing-Gate (Stryker, mutmut). 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. Es ist die direkteste Antwort, die wir auf die Veracode-Klasse von Fehlern kennen, weil sie die Annahme angreift und nicht das Ergebnis.

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

Beginnen Sie das Review beim Commit-für-Commit-Diff und lesen Sie die Änderung in der Reihenfolge, 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. Eigene Semgrep (opens in new tab)-Regeln und SonarQube-Profile lassen sich so tunen, dass sie 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 naheliegende Einwand: "Das verlangsamt Reviews." Tut es, am Anfang. Die Wette ist, dass es sie später beschleunigt, weil Reviewer aufhören, mehrdeutige PRs zu approven und ihnen dann in der Produktion wiederzubegegnen.

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. 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.