Der Zwei-Phasen-Review-Workflow

Review war eine einzige Tätigkeit, weil eine Person beide Jobs tragen konnte: Korrektheit prüfen und Qualität beurteilen. KI-Volumen hat diese Jobs auseinandergerissen: Telemetrie über 10.000+ Entwickler berichtet in einer Drittzusammenfassung von 2026 eine Assoziation zwischen intensiver KI-Nutzung, mehr gemergten PRs und längerer Review-Zeit; eine Ursache-Wirkung-Beziehung ist damit nicht belegt. Laut Sonar empfinden 38 % das Review von KI-Code als aufwendiger. Wenn dieselben knappen Minuten Stil-Nits, Typfehler, Scope-Checks und Architektur-Urteil tragen müssen, verdrängt die mechanische Arbeit das Urteil - also genau den Teil, für den Menschen gebraucht wurden.

JetBrains’ Engineering-Blog formuliert den Fix unverblümt: maschinell fangbare Fehler gar nicht erst ins menschliche Review schicken. Der Zwei-Phasen-Workflow ist dieses Prinzip, systematisiert.

Wo die Grenze zwischen den beiden Jobs verläuft - wofür Review da ist und was Verifikation tatsächlich abdeckt - zeigt Code-Review vs. Verifikation.

Phase 1 läuft bei jedem Push, als Required Status Check - nichts erreicht einen Menschen, das hier durchfällt:

1. Deterministische Gates. Formatierung, Lint, Typen, Build und die Testsuite - inklusive vor dem Run geschriebener Tests, damit das generierende Modell nicht seinen eigenen Richter verfasst hat. Ob diese Gates tatsächlich gelaufen sind statt nur als gelaufen gemeldet zu werden, ist ein eigener Nachweis: die pro Befehl beobachteten Exit-Codes.
2. Grenzprüfung. Der Diff gegen die deklarierten Auftragsgrenzen - Dateien und Verhalten, die sich nicht ändern dürfen. Änderungen außerhalb lassen die Phase scheitern.
3. Soll-Abgleich. Der Soll-Ist-Abgleich gegen die Akzeptanzkriterien des Auftrags, mit festgehaltenem Ergebnis.
4. Optional: KI-Pre-Review als Hypothesenfilter. Ein KI-Reviewer markiert wahrscheinliche Probleme im Diff. Cloudflares Orchestrierung dokumentiert eine konkrete Produktionsumsetzung im großen Maßstab. Das ist kein Beleg für denselben Effekt in jedem Team; der Output bleibt ein Screening-Signal, das Menschen bewerten, nie ein Verdikt.

Der Reviewer bekommt den Diff plus die Phase-1-Ergebnisse: was geprüft wurde, was bestand, was übersprungen wurde. Der Job wandelt sich vom Absichts-Rekonstruieren zum Urteilen - ist das der richtige Ansatz, passt es zur Architektur, sollte es das überhaupt geben. Die saubere Aufteilung:

• Alibi-Automatisierung. Ein grünes Phase-1-Badge ist ein Input für das Review, kein Ersatz. Werden Freigaben reflexhaft, ist der Workflow leise gescheitert.
• Lautes Pre-Review. Ein KI-Reviewer, der ständig Alarm schlägt, trainiert das Team, Phase 1 komplett zu ignorieren. Auf Präzision statt Vollständigkeit tunen; die Autorität tragen die deterministischen Gates.
• Keine schriftliche Absicht. Ohne Auftragsvorgabe schrumpft Phase 1 auf Stil und Tests - echter Wert, aber die stärksten Prüfungen (Grenzen, Kriterien) brauchen ein schriftliches Soll.
• Phase 1 als optional behandeln. Eine Vorprüfung, die sich unter Termindruck überspringen lässt, wird übersprungen - Required Status Checks gibt es aus gutem Grund.

Die Quellen beschreiben konkrete Umfragen, Produkte und Betriebskontexte mit Abrufstand Juli 2026. Eine bestandene erste Phase belegt nur, dass die deklarierten Checks bestanden wurden; sie beweist weder Korrektheit noch Eignung, Freigabe oder Release-Reife. Vor Merge oder Deployment muss ein Mensch Belege und Restrisiko einordnen und entscheiden.

Reality Graph ist eine strukturierte Phase 1 mit Auftragsbezug: Grenzen und Akzeptanzkriterien vor dem Run definiert, der Diff danach dagegen geprüft, Validierung, die das Modell nicht verfasst hat, und ein Prüfbericht als Übergabe-Artefakt in Phase 2 - das fehlende Stück zwischen generischen CI-Checks und dem menschlichen Reviewer, eingebettet in den Verifikations-Loop.