Code Review vs. Verifikation

Code Review verdient seinen Platz dreifach: Es transferiert Wissen, es fängt Designprobleme, die kein Compiler sieht, und es hält ein zweites Augenpaar auf allem, was ausgeliefert wird. Alle drei Leistungen setzen still etwas voraus: dass Lesekapazität und Schreibtempo ungefähr zusammenpassen. Zwanzig Jahre lang stimmte das – ein Reviewer rekonstruierte die Absicht des Autors aus Diff, Commit-Message und geteiltem Kontext, meist erfolgreich.

Genau dieser Rekonstruktionsschritt bricht mit KI. Der Autor der Änderung ist ein Modell, dessen „Absicht“ in einem Prompt lebte, der zur Review-Zeit verschwunden ist – und die Forschung dazu, wie Menschen KI-Pull-Requests tatsächlich reviewen, zeigt Reviewer, die auf Oberflächensignale ausweichen, wenn die Absicht fehlt. Review beurteilt weiter die Qualität; die Fähigkeit, Korrektheit gegen die Absicht zu beurteilen, verliert es leise.

Die Mengenverschiebung ist gemessen, nicht vermutet. Eine Faros-AI-Telemetriestudie über 10.000+ Entwickler in 1.255 Teams fand: Teams mit hoher KI-Nutzung mergen rund 98 % mehr Pull Requests – während die Review-Zeit pro PR um 91 % steigt. Mehr Code, und jede Einheit davon schwerer zu prüfen: 38 % der Entwickler sagen, das Review von KI-Code koste mehr Aufwand als das von Kollegen-Code.

Die Qualitätsdaten zeigen in dieselbe Richtung: Branchenauswertungen, gesammelt in Review-Standards-Guides 2026, beziffern KI-PRs auf etwa das 1,7-Fache der Defektrate menschlicher PRs; 45 % bringen mindestens ein OWASP-Top-10-Problem mit. Ein Reviewer mit doppeltem Volumen und subtileren Fehlermodi hat zwei Auswege: durchwinken oder zum Engpass werden. Beides sind Formen von Verification Debt.

Die Maximalthese – „Code Review ist tot“ – stellt die richtige Diagnose und verschreibt die falsche Kur. Wer den Menschen aus der Schleife nimmt, wirft die Urteilsschicht weg, die keine Prüfung ersetzen kann, und ignoriert, was Review für das geteilte Verständnis des Teams leistet. Die Arbeitsteilung, die sich in der Praxis trägt:

1. Verifikation zuerst, pro Änderung. Ein Soll-Ist-Abgleich gegen den schriftlichen Auftrag, Validierung, die das Modell nicht verfasst hat, ein festgehaltenes Ergebnis.
2. Review danach, auf verifizierten Änderungen. Der Reviewer bekommt den Diff plus das Verifikationsergebnis – und verwendet seine Aufmerksamkeit auf Architektur, Trade-offs und die Fragen, die keine Checkliste stellen kann.
3. Menschliches Gate zuletzt. Ein Mensch übernimmt oder verwirft – mit Belegen vor Augen. Die Verifikation informiert die Entscheidung; sie trifft sie nie.

Der Reviewer-Job wandelt sich von „rekonstruieren, was gewollt war“ zu „beurteilen, ob es gut ist“ – also zu dem Job, in dem Review immer am stärksten war. Diese Teilung ist der Kern des größeren Verifikations-Loops.

• Review komplett streichen. Verifikation prüft die formulierte Absicht; ob die Absicht klug war, beurteilt sie nicht. Das bleibt Reviewer-Arbeit.
• KI-Review-Tools mit Verifikation verwechseln. Ein KI-Reviewer ohne schriftlichen Auftrag ist eine weitere Meinung, keine Prüfung. Nützlich für den mechanischen Rückstau – kein Bezugspunkt.
• Konstante Review-Zeit als Fortschritt feiern. Wenn KI-PRs trotz subtilerer Fehlermodi dieselben Minuten bekommen wie menschliche, optimiert der Prozess Durchsatz statt Gewissheit – beides messen.

Reality Graph baut die Verifikationshälfte dieser Arbeitsteilung: schriftlicher Auftrag vor dem Run, Grenz- und Kriterienprüfung danach, Validierung, die das Modell nicht verfasst hat, und ein Prüfbericht, den der Reviewer liest, bevor er urteilt. Euer Review-Prozess bleibt eurer.