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 zeigt bei KI-intensiven Teams ~98 % mehr gemergte PRs bei +91 % Review-Zeit, und 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.

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.
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 zeigt, dass das im großen Maßstab trägt – als Screening-Schicht, deren Output Menschen bewerten, nie als 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.

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.