Multi-Agent-Code-Review-Workflow: Zwei Reviewer, ein finaler Writer
Ich stoße immer wieder auf dieselbe Einschränkung, wenn ich mehrere AI-Coding-Sitzungen verwende. Meiner Erfahrung nach finden parallele Sitzungen unterschiedliche Codepfade, aber ihre Meinungsverschiedenheiten bleiben in getrennten Threads eingeschlossen. Ich werde zum Message-Bus, kopiere eine Review in eine andere Sitzung und entscheide, welches Modell die Datei verstanden hat.
Das bessere Design ist ein Multi-Agent-Code-Review-Workflow mit drei klar getrennten Rollen. Zwei AI-Sitzungen untersuchen unabhängig voneinander dieselbe Dateirevision. Sie tauschen Erkenntnisse aus und hinterfragen gegenseitig ihre Belege. Eine dritte Sitzung erhält das Entscheidungsprotokoll, schreibt einen Patch und führt die Prüfungen aus.
Behandle die Datei während der Review als gemeinsame, unveränderliche Eingabe. Gewähre einer Sitzung Schreibzugriff, sobald die Review zu einer Entscheidung gelangt.
Das unterscheidet sich von meiner aktuellen hybriden AI-Code-Review-Schleife→, bei der ein Modell schreibt und ein zweites Modell jede Änderung überprüft. Diese Schleife gibt dem Reviewer bereits nützliche Unabhängigkeit. Das nächste Experiment verzögert das Schreiben: Die beiden ersten Sitzungen führen zunächst die Review durch, und eine dritte Sitzung beginnt erst dann mit dem Coden, wenn ihre Meinungsverschiedenheit ein Entscheidungsprotokoll hervorgebracht hat.
Dieses Muster entspricht bereits weitgehend dem, was aktuelle Agent-Tools unterstützen. Die Codex-Subagent-Dokumentation von OpenAI empfiehlt parallele Agents für leseintensive Exploration, Tests, Triage und Reviews, warnt jedoch davor, dass parallele schreibintensive Workflows Konflikte und Koordinationsaufwand erzeugen. Was fehlt, ist eine erstklassige Diskussions- und Syntheseebene zwischen den Reviewern und dem Writer.
Warum braucht ein Multi-Agent-Code-Review-Workflow einen Writer?
Parallele Analyse liefert unterschiedliche Fehlerhypothesen, ohne mehrere konkurrierende Patches zu erzeugen.
Ein Reviewer kann Verhalten und Invarianten nachverfolgen. Der andere kann nach Sicherheitsproblemen, Race Conditions, fehlenden Tests oder Brüchen von API-Verträgen suchen. Beide starten beim selben Commit-SHA und mit derselben Aufgabe, erhalten aber unterschiedliche Review-Briefings. Diese Trennung verringert die Wahrscheinlichkeit, dass beide Sitzungen derselben ersten Idee folgen.
Anthropic beschreibt ein verwandtes Produktionsmuster in Building effective agents: Mehrere Model-Aufrufe können Code aus unterschiedlichen Perspektiven prüfen, während ein Orchestrator-Worker-Workflow Aufgaben delegiert und die Ergebnisse synthetisiert. Anthropic rät Teams außerdem, agentische Komplexität nur dann hinzuzufügen, wenn sie gemessene Ergebnisse verbessert. Drei Sitzungen kosten mehr Tokens und Zeit als eine, daher braucht der Workflow einen guten Grund.
Gleichzeitige Änderungen sind selten dieser Grund. Wenn zwei Agents dieselbe Arbeitskopie bearbeiten, muss das System veralteten Kontext, überlappende Hunks und teilweise angewandte Annahmen auflösen. Git bietet bereits ein sichereres Primitiv: verknüpfte Worktrees ermöglichen es getrennten Sitzungen, isolierte `HEAD`- und Index-Zustände zu verwenden und gleichzeitig die gemeinsame Repository-Historie zu nutzen.
Die Reviewer können Worktrees für Experimente verwenden, aber nur der Integrator sollte den Kandidaten-Patch besitzen.
Was besitzt jede AI-Sitzung?
| Sitzung | Zugriff | Erforderliche Ausgabe | Darf nicht |
|---|---|---|---|
| --- | --- | --- | --- |
| Reviewer A | Read-only-Snapshot | Verhaltensrisiken, gebrochene Invarianten, Zeilenreferenzen, vorgeschlagene Tests | Den finalen Branch bearbeiten |
| Reviewer B | Read-only-Snapshot | Sicherheit, Nebenläufigkeit, Edge Cases, Gegenbeispiele | Die Schlussfolgerung von Reviewer A ohne Belege übernehmen |
| Integrator | Exklusiver Schreibzugriff | Akzeptierter Patch, abgelehnte Findings mit Begründungen, Testergebnisse, finaler Diff | Über den vereinbarten Umfang hinaus umschreiben |
Der dritte Agent ist nicht automatisch intelligenter. Sein Vorteil entsteht durch Ownership. Er erhält begrenzte Belege, macht die Konfliktauflösung explizit und erzeugt einen einzigen prüfbaren Diff.
Ich würde die Reviewer außerdem für ihren ersten Durchlauf voneinander abschirmen. Eine kontrollierte Studie zu Multi-Agent-Debatten stellte fest, dass Mehrheitsdruck unabhängige Korrekturen unterdrücken kann. Früher Austausch kann aus zwei Reviewern eine wiederholte Meinung machen. Unabhängige Findings sollten zuerst entstehen; die Diskussion sollte beginnen, nachdem beide ihre anfänglichen Belege festgehalten haben.
Wie sollten die Reviewer über eine Datei diskutieren?
Freiform-Chat ist für Menschen nützlich, aber ein Coding-Workflow braucht ein kompaktes Finding-Register. Jede Behauptung sollte genügend Belege enthalten, damit der Integrator sie überprüfen kann, ohne eine private Gedankenkette nachzuvollziehen.
{ "id": "F-03", "revision": "8a31f2c", "file": "src/auth/session.ts", "lines": "84-103", "claim": "A refresh failure can leave the previous session active", "evidence": "The error branch returns before clearSession()", "risk": "stale authorization state", "proposed_test": "refresh 401 clears the active session", "confidence": "high", "status": "disputed" }
Der zweite Reviewer kann das Finding akzeptieren, es mit einem Argument zum erreichbaren Code widerlegen oder seinen Umfang einschränken. Das Register bewahrt beide Positionen. Übereinstimmung allein beweist keine Korrektheit, und ein selbstsicherer Absatz sollte einen reproduzierbaren Test nicht überwiegen.
Agent-Protokolle bewegen sich in diese Richtung. Googles Agent2Agent-Protokoll modelliert Zusammenarbeit über Tasks, Nachrichten, Zustände und Artefakte. Ein lokales Coding-System muss nicht das vollständige Protokoll übernehmen, um den Vertrag zu nutzen: Verwende typisierte Nachrichten, stabile IDs, explizite Statusangaben und dauerhafte Artefakte statt eines unstrukturierten Transkripts.
Meine AI-Peer-Review-Bridge→ verpackt bereits einen Diff, Fokusfragen und ein strukturiertes Urteil für ein zweites Modell. Ein Workflow mit drei Sitzungen braucht die nächste Ebene: zwei Review-Pakete, die vor der Übergabe an den Writer auf dieselben Finding-IDs verweisen, sie anfechten und auflösen können.
Was muss der Writer vor dem Bearbeiten erhalten?
Der Integrator sollte nicht zwei lange Chatverläufe erhalten. Er braucht ein kleines Übergabepaket:
Der Writer liest anschließend die aktuelle Datei erneut und vergleicht ihre Revision mit der Übergabe. Bei einer Abweichung wird der Schreibvorgang gestoppt. Diese eine Prüfung verhindert, dass eine gültige Review der Datei von gestern zu einem fehlerhaften Patch gegen den Code von heute wird.
Hier sollten auch die Berechtigungen deterministisch werden. Ich habe für deterministische Berechtigungen von AI-Agents→ argumentiert, weil eine Aufforderung wie „Bearbeite nur diese Datei“ schwächer ist als eine Tool-Richtlinie, die jeden anderen Pfad schreibgeschützt macht. In diesem Workflow sollte das Berechtigungsmodell die Rollentrennung erzwingen: Reviewer dürfen nicht schreiben, und der Integrator darf den Umfang ohne eine neue Entscheidung nicht erweitern.
Verbessert eine Debatte Software-Patches?
Die Belege unterstützen die Richtung, beweisen aber nicht, dass jedes Team genau zwei Reviewer und einen Writer verwenden sollte.
Improving Factuality and Reasoning in Language Models through Multiagent Debate zeigt, dass mehrere Modellinstanzen über mehrere Runden Antworten vorschlagen, kritisieren und verfeinern können, wodurch sich die Ergebnisse bei den Reasoning- und Factuality-Aufgaben der Studie verbessern. Diese Experimente testeten weder Git-Konflikte noch Produktions-Pull-Requests.
Ein näher am Coding liegendes Beispiel erschien im Preprint SWE-Debate aus dem Jahr 2025. Seine Agents diskutieren konkurrierende Traces zur Fehlerlokalisierung, konsolidieren einen Behebungsplan und übergeben diesen Plan an einen separaten Agent zur Patch-Generierung. Das Paper berichtet über 207 gelöste Aufgaben von 500 auf SWE-bench Verified, also 41,4 %, verglichen mit 38,8 % für seine stärksten aufgeführten Baselines. Benchmark und Architektur unterscheiden sich von dem Workflow, den ich vorschlage, aber die Trennung ist aufschlussreich: zuerst vielfältige Analyse, danach eine einzige Änderungsphase.
Der ehrliche nächste Schritt ist eine kleine kontrollierte Evaluation mit echten Pull-Requests. Vergleiche einen einzelnen Coding-Agent mit dem Workflow aus drei Sitzungen über 10 bis 20 Bugs hinweg. Miss gültige Findings, False Positives, Merge-Konflikte, die Zeit bis zu einem akzeptablen Patch und nach dem ersten Entwurf entdeckte Regressionen. Mehr Agent-Nachrichten sind keine Erfolgsmetrik.
Wie erzeugt der Writer einen prüfbaren Patch?
Der Integrator sollte einer engen Schleife folgen:
Diese letzte Review sollte den Patch prüfen und nicht die Design-Debatte neu starten. Jeder Reviewer beantwortet zwei Fragen: Hat der Writer die akzeptierte Entscheidung umgesetzt, und hat der Patch ein neues Risiko eingeführt?
OpenAIs aktuelle Codex-App verwendet bereits getrennte Threads und Worktrees, damit Agents parallel laufen können, ohne denselben lokalen Git-Zustand zu verändern, und ermöglicht Entwicklern, jeden Diff zu prüfen und zu kommentieren. Die Ankündigung der Codex-App zeigt, dass die Isolationsebene existiert. Ein gemeinsames Finding-Register und eine explizite Integrator-Rolle würden parallele Aufgaben in einen koordinierten Review-Raum verwandeln.
Welche Fehler bleiben bestehen?
Ein Writer beseitigt Bearbeitungs-Races, nicht Modellfehler.
Zwei Reviewer können denselben blinden Fleck haben, insbesondere wenn sie dasselbe Modell, denselben Prompt und denselben Kontext verwenden. Der Integrator kann das überzeugendere statt des korrekten Arguments auswählen. Repository-Kommentare können nicht vertrauenswürdige Anweisungen enthalten. Eine erfolgreiche Testsuite kann das Verhalten übersehen, auf das Nutzer angewiesen sind.
Der Workflow braucht Schutzmaßnahmen:
Meine frühere Schlussfolgerung nach 21,54 Milliarden Aktivitäts-Tokens von Code-Agents→ gilt weiterhin: Das System um das Modell entscheidet, ob mehr Intelligenz zu nützlicher Arbeit oder zu schnellerem Aufräumen führt.
Wann lohnt sich ein Workflow mit drei Sitzungen?
Verwende ihn, wenn ein falscher Patch teuer ist oder der Code mehr als eine plausible Interpretation zulässt: Authentifizierung, Berechtigungen, Zahlungen, Migrationen, Nebenläufigkeit, öffentliche APIs und Incident-Fixes. Er kann auch helfen, wenn ein Senior Engineer normalerweise zwei Spezialisten bitten würde, unterschiedliche Risikobereiche zu prüfen.
Überspringe ihn bei Formatierungen, generierten Dateien, einfachen Umbenennungen und Änderungen mit einem offensichtlichen Test-Orakel. Anthropic stellte bei seinem Multi-Agent-Team fest, dass die Koordinationskomplexität schnell wächst, und sein Produktionsforschungssystem hängt von klarer Delegation und einem Lead-Agent ab, der spezialisierte Ergebnisse synthetisiert. Coding braucht dieselbe Disziplin, mit noch weniger Toleranz für mehrdeutige Schreibvorgänge.
Ich möchte, dass Coding-Agents Belege diskutieren, bevor einer von ihnen den Cursor erhält. Zwei Sitzungen sollten dieselbe Datei untersuchen, öffentlich widersprechen und ein Entscheidungsprotokoll hinterlassen. Eine dritte sollte den Kandidaten-Patch schreiben und ihn gegen das Repository beweisen.
Dieser Kandidat braucht weiterhin Tests, eine Diff-Review und eine menschliche Release-Entscheidung. Drei AI-Sitzungen können den Weg zum Patch verbessern; sie machen den Patch nicht zur Wahrheit.
FAQ
Können zwei AI-Agents gleichzeitig dieselbe Datei bearbeiten?
Sie können es, aber gemeinsame Schreibvorgänge erzeugen veralteten Kontext und widersprüchliche Änderungen. Lass beide Agents dieselbe Revision im Read-only-Modus analysieren oder Experimente in getrennten Worktrees isolieren und gib anschließend einem Integrator exklusiven Schreibzugriff auf den finalen Branch.
Sollten beide Reviewer dasselbe Modell verwenden?
Sie können es, aber unterschiedliche Prompts, Rollen oder Modellfamilien können korrelierte blinde Flecken reduzieren. Vielfalt garantiert keine Korrektheit, daher braucht der Workflow weiterhin Belege und Tests.
Was passiert, wenn die Reviewer sich nicht einig sind?
Halte beide Positionen im Finding-Register fest. Der Integrator sollte die Behauptung reproduzieren, den vorgeschlagenen Test ausführen oder das Problem für einen Menschen als ungelöst markieren. Mehrheitsabstimmungen sind ein schwacher Ersatz für überprüfbare Belege.
Ersetzt die dritte AI-Sitzung die menschliche Code-Review?
Nein. Die dritte Sitzung übernimmt Synthese und den Kandidaten-Patch. Ein Mensch entscheidet weiterhin, ob der Patch zum Gesamtsystem, zur Produktabsicht und zum Release-Risiko passt.
Kann dieser Workflow Änderungen über mehrere Dateien hinweg verarbeiten?
Ja. Fixiere jede geprüfte Datei auf dieselbe Repository-Revision, weise klare Zuständigkeiten zu und behalte einen Integrations-Branch bei. Reviewer können über isolierte Worktrees hinweg arbeiten, während der Integrator die einzige Sitzung bleibt, die den finalen Patch zusammenstellt.