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. Die Forschung dazu, wie Menschen KI-Pull-Requests tatsächlich reviewen, berichtet Muster in einer begrenzten Stichprobe. Als Preprint vom Mai 2026 ist er ein nützlicher Beleg, kein universelles Gesetz. Schriftlicher Auftrag kann einen klareren Bezugspunkt liefern; die Studie beweist weder Review-Versagen noch Ersatz durch Verifikation.

Eine Sonar-Anbieterumfrage von 2026 berichtet selbst eingeschätztes Review-Verhalten. Sie ist datiert und relevant, aber keine universelle Produktionstelemetrie und kein Beleg für eine kausale Durchsatzregel.

NISTs Secure Software Development Framework vom Februar 2022 behandelt Peer Review, Codeanalyse und ausführbare Tests als getrennte Praktiken. Kombiniert Belegquellen risikogerecht und haltet Abdeckung sowie Auslassungen fest. Fehlende oder veraltete Belege erzeugen Verification Debt.

Eine der Praktiken als universellen Ersatz zu behandeln, ist die falsche Abstraktion. 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. Auftrag definieren und Prüfungen wählen. Ein Soll-Ist-Abgleich gegen den schriftlichen Auftrag sowie risikogerechte statische Analyse, Tests und weitere Belege mit dokumentierten Grenzen.
2. Review mit Belegen. Der Reviewer bekommt Diff, Befunde und Ergebnisse, hinterfragt deren Abdeckung und kann eine weitere Iteration verlangen.
3. Menschliches Gate zuletzt. Die benannte Person übernimmt oder verwirft nach den Entscheidungsrechten des Teams. Review-Urteil und Verifikationsbelege informieren diese Geschäfts- oder Release-Entscheidung; sie treffen sie nicht automatisch.

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. Als konkreter Prozess mit Schritten und Rollen ist sie im Zwei-Phasen-Review beschrieben.

• 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 hält eine auftragsbezogene Belegschicht fest: schriftlicher Auftrag vor dem Run, Grenz- und Kriterienprüfung danach, ausgewählte Validierungsergebnisse und Auslassungen sowie ein Prüfbericht, den der Reviewer liest. Worauf diese Prüfungen hinauslaufen, ein Wert pro Run statt eines Flickenteppichs aus Einzelstatus je Tool, folgt den Regeln unter wie das Ergebnis berechnet wird. Er beweist weder Korrektheit, Sicherheit noch Compliance und trifft keine Geschäfts-, Rechts- oder Release-Freigabe. Review-Prozess und Entscheidungsrechte bleiben eure.