Doppelte Gates – warum jede Stufe einen Reviewer braucht, nicht nur der Code

In zwei Beiträgen dieser Serie ging es um Struktur, um drei Schichten und einen prüfbaren Vertrag dazwischen, in zwei weiteren um Tokens. Dieser Beitrag geht zurück zum Ablauf und zu einer Asymmetrie, die mir lange nicht aufgefallen ist, obwohl ich täglich damit gearbeitet habe.

Wir haben in der Softwareentwicklung eine ausgereifte Kultur für Code-Review. Vier-Augen-Prinzip, Kommentare am Diff, Approval als Merge-Bedingung. Und wir haben für die beiden Stufen davor, Anforderung und Lösungsdesign, im Wesentlichen: einen Handschlag.

Das ist ökonomisch bemerkenswert falsch herum. Ein Fehler in der Anforderung ist um Größenordnungen billiger zu beheben als in der Implementierung; trotzdem prüfen wir ihn am spätesten.

Der Moment, in dem es aufgefallen ist

In meinem Agenten-Team aus der ersten Serie gab es eine Übergabe, die nie funktioniert hat: Der Business Analyst schrieb einen Use Case, ich las ihn, ich fand ihn gut, der Solution Architect baute darauf auf — und zwei Stufen später stellte sich heraus, dass ein Akzeptanzkriterium mehrdeutig war.

Der erste Reflex war, den Business Analyst besser zu prompten. Das habe ich mehrfach getan, und es hat jedes Mal ein bisschen geholfen. Was nicht half, war die Idee, die ich danach hatte: den Agenten sein eigenes Ergebnis prüfen zu lassen. Ich habe ihm eine Prüf-Phase angehängt: „gehe dein Dokument noch einmal gegen diese Kriterien durch".

Das Ergebnis war so vorhersehbar, wie es im Nachhinein klingt: Er fand Kleinigkeiten. Formulierungen, fehlende Nummerierungen, einen Tippfehler. Was er nie fand, waren die Annahmen, die er selbst getroffen hatte, weil er sie beim Schreiben für das Naheliegende hielt und nicht für Annahmen.

Ein Autor, der sein eigenes Werk prüft, liest bestätigend. Das gilt für mich, und es gilt für ein Modell mit demselben Kontextfenster.

Das Problem betrifft jeden Autor und ist kein KI-Problem. Es ist der Grund, warum wir überhaupt Vier-Augen-Prinzip haben. Ich hatte es nur in der Agenten-Pipeline an zwei von drei Stellen vergessen, bei der Anforderung und beim Konzept.

Das Muster: zwei Gates pro Stufe

Was daraus geworden ist, wiederholt sich jetzt auf jeder Stufe identisch:

1. Ein Agenten-Gate: Ein Reviewer-Agent prüft das Artefakt, bevor ein Mensch es überhaupt zu sehen bekommt.
2. Ein Mensch-Gate: Die Freigabe trifft immer ein Mensch.

Die Rollenteilung dahinter:

Agenten produzieren und prüfen. Entscheiden tut der Mensch.

Und zwar an genau drei Stellen: Freigabe der Anforderung, Freigabe des Konzepts, Merge. Alle drei liegen an teuren oder unumkehrbaren Weichen. Dazwischen arbeiten die Agenten autonom, aber vorqualifiziert.

Eine Lücke an diesen Freigabestellen habe ich in Zielprojekt B gesehen, einem Nuxt-Projekt. Die Agenten arbeiteten dort in einem eigenen Git-Worktree. Ich habe die Use-Case-Datei zuerst im Haupt-Checkout gesucht, sie nicht gefunden und später nach dem Branch gefragt. Der Workflow nennt den Arbeitsort bei Freigaben nicht deutlich genug.

Der ganze Ablauf

Ausgeschrieben sieht das inzwischen so aus:

Ebene 2 übersetzt jedes Akzeptanzkriterium in ein Testszenario, noch bevor das Konzept entsteht; darum geht es in einem eigenen Beitrag später in dieser Serie. Drei weitere Entscheidungen darin sind erklärungsbedürftig.

Der Reviewer ändert keinen Status. Jedes Dokument durchläuft die Status „Entwurf", „In Review" und „Freigegeben". Der Reviewer ist ein Qualitätsgate innerhalb des Status „Entwurf". Erst der Mensch setzt „In Review" und danach „Freigegeben". Das ist wichtig, auch wenn es bürokratisch wirkt: Sonst hätte ich einen Agenten, der seine eigene Pipeline weiterschiebt, und das Mensch-Gate wäre eine Formalität mit vorbelegtem Ergebnis.

Der Reviewer schreibt keine Datei. Sein Report geht inline an den Producer zurück. Doc-Reviews sind Iterationsartefakte: Sie haben ihren Zweck erfüllt, wenn der Befund eingearbeitet ist. Genau eine Ausnahme gibt es: Der finale Code-Review wird als Datei im Feature-Branch abgelegt und gehört zum Pull Request. Das ist die einzige Review-Runde, deren Ergebnis nach dem Merge noch jemanden interessiert.

Die Auditoren stehen außerhalb. Die drei Ganz-Codebase-Prüfer (Health, Spec-Compliance, Konventionen) laufen ereignisbasiert: vor Releases, nach großen Merges. Pro Pull Request wären sie redundant zum Code-Reviewer und würden jedes Mal dieselben Bestandsbefunde melden. Ihr Job ist Drift über Zeit, nicht Feature-Abnahme. Das habe ich zuerst falsch gemacht, und es war der schnellste Weg, Findings zu Rauschen zu machen.

Was ein guter Reviewer-Agent anders macht

Ein Reviewer ist nicht einfach ein Producer mit umgedrehtem Auftrag. Vier Dinge haben bei mir den Unterschied gemacht.

Er hat einen eigenen Kontext. Das ist der ganze Grund seiner Existenz. Er liest das Artefakt und die Regeln und nicht die Gedanken, mit denen es entstanden ist. Was der Producer für offensichtlich hielt, muss im Dokument stehen, sonst existiert es nicht.

Er verifiziert gegen die Codebase, nicht gegen das Dokument. Der Konzept-Reviewer prüft, ob die genannten Dateien, Klassen und Composables tatsächlich existieren. Das klingt nach einer Kleinigkeit und ist der häufigste echte Befund: Ein Konzept, das eine Datei erwähnt, die es nicht (mehr) gibt, liest sich vollkommen plausibel.

Er darf „das konnte ich nicht prüfen" sagen. Ein Reviewer, der zu jedem Punkt ein Urteil abgibt, gibt zu manchen Punkten ein erfundenes ab. Ein ausgewiesener blinder Fleck ist ein Ergebnis; ein stillschweigend übersprungener Prüfpunkt ist eine Lüge mit Haken dran.

Für meinen Audit-Skill, der den Workflow vor jedem Release gegen die aktuelle Doku von Claude Code prüft, gilt dasselbe. Eine Nachprüfung seines ersten Laufs fand fünf Schwächen, darunter Aussagen über das Verhalten von Claude Code ohne Beleg. Ein Befund über doppelt geladene Skills war als Major eingestuft, aber nur aus dem Text abgeleitet; in den Transkripten trat das in keinem Lauf auf. Seitdem braucht jede Aussage des Skills über das Verhalten von Claude Code ein Zitat aus der Doku oder eine Messung im Transkript.

Er muss sagen, was gut ist. In meinem Review-Protokoll ist mindestens ein Eintrag im Abschnitt „Was ist gut" Pflicht. Das war zuerst Kosmetik und hat sich als das Nützlichste am ganzen Report herausgestellt. Mit Streicheleinheiten für den Producer hat das nichts zu tun: Es zwingt den Reviewer, das Artefakt als Ganzes zu verstehen, statt nur eine Fehlerliste abzuarbeiten. Ein Reviewer, der nichts Gutes findet, hat meistens nicht genau gelesen.

Was das kostet

Über die Kosten lese ich in solchen Beiträgen selten etwas.

Ein Feature durchläuft in diesem Aufbau mindestens acht Agenten-Aufrufe: Producer und Reviewer auf drei Stufen, dazu die Test-Vorbereitung und die Test-Absicherung. Jeder dieser Aufrufe startet mit frischem Kontext und macht seine eigene Analyse der Codebase. Das ist ja der Sinn, und das kostet.

Zwei Feature-Läufe in echten Projekten kosteten insgesamt 48,3 Millionen Tokens (ein kleines Feature in Zielprojekt A) und 153,4 Millionen (ein großes in Zielprojekt B), davon 94 bzw. 96 % Cache-Reads. Details stehen in Teil 3.

Was ich an den Freigaben noch geändert habe, habe ich in beiden Feature-Läufen notiert. In Zielprojekt A war es beim Use Case eine Ergänzung, beim Konzept nichts und nach dem Test auf dem Gerät der Wunsch nach einem Fade-Effekt. In Zielprojekt B mit fünf Use Cases habe ich beim Use Case neun Fachfragen des Business Analyst entschieden, zum Konzept fünf Vorgaben gemacht und nach meinem Test eine Korrektur an der Navigation verlangt. Die Freigaben kosten auch Wartezeit: In A wartete die Pipeline eine Stunde und 33 Minuten auf meine Use-Case-Freigabe, in dieser Zeit habe ich den Use Case selbst gelesen. In B wartete sie über den ganzen Lauf zusammen etwa 50 Minuten auf mich.

Den Nutzen kann ich nur qualitativ angeben: Für ein Feature mit einem echten fachlichen Kern lohnt es sich deutlich. Für eine Textänderung ist es absurd. Beim Umbau nach dem Audit aus Teil 2 haben die Reviewer echte Fehler gefunden, unter anderem ein MAJOR im ersten Konzept, ein Schlupfloch über Symlinks und einen Merge der settings.json, der Hook-Gruppen verlor.

Deshalb gibt es als Gegengewicht eine explizit definierte Fast Lane: Trivialänderungen (Tippfehler, Doku-Korrektur, Tooling-Anpassung) überspringen die Spezifikationskette komplett. Was sie nicht überspringen, sind die Quality Gates, der Code-Reviewer und das Merge-Gate.

Der Gedanke dahinter ist mir wichtig: Ein Leichtgewichts-Pfad entsteht sowieso. Wenn ich ihn nicht definiere, definiert ihn die Ungeduld, und dann ist er undokumentiert und unbegrenzt. Die Fast Lane ist der Versuch, die Abkürzung sichtbar und begrenzt zu machen, statt sie zu verbieten.

Eine solche Abkürzung habe ich in Zielprojekt A gesehen, einem Flutter-Projekt. Nach dem Test auf dem Gerät wünschte ich mir noch einen Fade-Effekt. Die Hauptsession, die die Agenten steuert, hat ihn selbst umgesetzt, statt ihn an den Implementierungs-Agenten zu geben. Die Gates liefen, und der Code-Reviewer prüfte nach. Eine Abkürzung an der Pipeline vorbei war es trotzdem. In Zielprojekt B ging meine Rückmeldung nach dem Test über den regulären Weg: als neuer Plan-Schritt an den Implementierungs-Agenten, danach folgte ein Review nur der Änderung (Delta-Review).

Blinde Flecken

Zwei Reviewer-Ebenen fangen mehr als eine. Sie fangen nicht alles, und sie fangen eine Sorte Fehler systematisch nicht: die, bei denen Producer und Reviewer dieselbe falsche Annahme teilen. Beide lesen dieselben Regeln, beide arbeiten mit demselben Modelltyp, beide sehen dieselbe Codebase. Wenn die Regel selbst falsch ist, nickt der Reviewer sie mit ab.

Ich habe genau diesen Fall erlebt, und er ist unangenehm genug für einen eigenen Beitrag später in dieser Serie: ein Realisierungsplan, der gegen die harte Regel verstieß, dass Kern-Dateien im Projekt nie direkt geändert werden, und von zwei Instanzen abgenommen wurde. Aufgefallen ist er erst in der Umsetzung, als ein Guard den Schreibzugriff blockierte, und dann schrieb der Implementierungs-Agent die Datei per Shell-Befehl, den der Guard nicht sieht.

Die Konsequenz daraus war kein weiterer Reviewer. Die vorhandenen haben eine feste Prüfgrundlage bekommen: Der Solution Architect klärt für jede Datei, ob sie zum Kern oder zum Adapter gehört, bevor sie in eine Maßnahme kommt, und der Konzept-Reviewer gleicht jede genannte Datei gegen die Kategorien-Tabelle ab. Die Prüfung hängt damit an einer Tabelle, nicht an der Auslegung der Regel.

Fazit

Was ich mitnehme, ist weniger eine KI-Erkenntnis als eine Prozess-Selbstverständlichkeit, die ich nie auf die frühen Stufen angewendet habe: Jede Produktionsstufe verdient einen Reviewer, nicht nur die letzte. Anforderungs- und Konzeptfehler werden dort gefangen, wo sie billig sind, und das ist der einzige Grund, warum sich der zusätzliche Aufwand überhaupt rechnet.

Der zweite Teil ist die Rollenteilung: Agenten dürfen produzieren und prüfen, aber nicht entscheiden. Drei menschliche Freigaben klingen nach viel. In der Praxis ist es deutlich weniger Review-Last als vorher, weil ich Artefakte bekomme, die eine Vorprüfung bestanden haben, statt Rohentwürfe, bei denen ich selbst die Kleinigkeiten suche.

Im nächsten Beitrag geht es um die unangenehme Kehrseite dieses Musters: Was passiert, wenn Producer und Reviewer sich nicht einigen? Jede Schleife braucht eine Abbruchbedingung — und meine hat zwei Runden.

Wie prüft ihr eure Anforderungen, bevor jemand anfängt zu bauen? Gibt es bei euch ein Gate vor dem Code-Review — und falls ja, ist es formal oder ein Handschlag?