Agents lösen den Reviewer ab, nicht das Review

Im Juni 2026 veröffentlichte Martin Monperrus, ein für die automatisierte Programmreparatur bekannter Forscher im Bereich Software Engineering, ein Paper mit dem Titel The End of Code Review: Coding Agents Supersede Human Inspection. Das Argument lautet, dass Coding Agents eine Leistungsschwelle überschritten haben, ab der es kein notwendiges Qualitätstor mehr darstellt, dass ein Mensch einen Diff vor dem Merge prüft, und dass die übliche Konstellation, in der Agents Code schreiben und Menschen die obligatorischen Reviewer bleiben, eine Sackgasse ist.¹

Das Paper hat in mehr Punkten recht, als seine Kritiker zugeben werden, und liegt an einer bestimmten, entscheidenden Stelle falsch. Agents haben den Reviewer abgelöst: Der Mensch, der einen Diff Zeile für Zeile auf Fehler durchsucht, verrichtet eine Arbeit, die ein Ensemble von Agents nun besser und bei jedem Commit erledigt. Doch das Paper vermengt diese Rolle mit dem Review selbst. Wenn man die von ihm vorgeschriebene Agent-Pipeline tatsächlich betreibt, verschwindet die menschliche Arbeit nicht. Sie verlagert sich, von der Prüfung des Codes hin zur Verantwortung für die Intention, die der Code erfüllen sollte. Ich betreibe diese Pipeline. Der Reviewer stirbt. Das Review wandert die Wertschöpfungskette hinauf.

Ich möchte das Paper ernst nehmen, denn die meisten Reaktionen darauf werden das nicht tun. Die reflexhafte Antwort lautet „aber Agents halluzinieren”, und genau das räumt Monperrus bereits ein. Die ehrliche Auseinandersetzung beginnt damit, einzugestehen, worin er recht hat.

TL;DR

• Monperrus argumentiert, Coding Agents hätten die Notwendigkeit menschlichen Code Reviews beendet, weil jedes Ziel des Reviews (Fehlererkennung, Stil, Sicherheit, Wissenstransfer) von Agents besser und günstiger erfüllt wird und die menschliche Review-Kapazität nicht mit dem von Agents getriebenen Durchsatz skalieren kann.¹
• Er hat recht damit, dass die obligatorische menschliche Freigabe per Häkchen am Ende ist, und recht damit, dass Agents eine systematische Prüfung besser leisten als ein müder Mensch, der einen großen Diff überfliegt.
• Er ist dabei nicht naiv: Das Paper räumt Halluzination, Prompt Injection und die Korrelation sicherheitsbezogener blinder Flecken ein und behält Menschen für riskante, neuartige, regulierte und ethische Änderungen vor.¹
• Die Lücke besteht darin, dass er die verbleibende menschliche Rolle als kleine Menge von Eskalationsfällen behandelt. In der Produktion ist sie das tragende Zentrum: Der Agent optimiert auf die ihm gegebene Spezifikation, und das Schreiben und Verantworten dieser Spezifikation ist der unhintergehbar menschliche Akt.
• Die Rolle des Reviewers wird automatisiert. Das Review, verstanden als Urteil darüber, ob die Software für ihren Zweck korrekt ist, verlagert sich dorthin, wohin der Agent nicht folgen kann.

Worin das Paper recht hat

Monperrus baut auf der Aufzählung von Bacchelli und Bird auf, warum Teams Code reviewen: Fehlererkennung, Durchsetzung von Stil und Standards, Wissenstransfer und Team-Bewusstsein, mit Sicherheit als fünfter Dimension.¹² Sein Schachzug besteht darin, jedes Ziel aufzugreifen und zu argumentieren, dass ein Agent es besser erfüllt. Agents prüfen jeden Commit ohne Ermüdung oder Zeitzonenverzögerung. Sie zählen Schwachstellenklassen systematischer auf als ein Mensch, der einen Ad-hoc-Durchgang macht. Sie erzeugen architektonische Zusammenfassungen und aktualisierte Dokumentation zum Zeitpunkt des Merges. Das Paper führt die SWE-bench-Leistungskurve ins Feld, um den Schwellenwert zu begründen, von einem besten Modell, das beim Start des Benchmarks 2023 unter 2 Prozent der realen GitHub-Issues löste, bis zu Spitzen-Agents, die Ende 2025 über 70 Prozent erreichten.¹³

Mit diesem Teil habe ich keinen Streit, denn ich erlebe täglich, wie er funktioniert. Meine autonome Build-Schleife läuft über ein Tor mit drei Reviewern: Getrennte Agents prüfen Korrektheit, Konventionen und Sicherheit, bevor Code gemergt wird, und eine zweite Schleife schickt die Implementierung an ein unabhängiges Modell für einen adversariellen Durchgang. Diese Agents finden echte Fehler, und sie finden sie bei jeder Änderung, nicht nur bei den Änderungen, für die ein Mensch Zeit hatte. Die beiden Beiträge, die diesem hier auf dieser Seite vorausgingen, durchliefen jeweils einen Agent-Evaluator, der sie anhand eines Bewertungsrasters einstufte und konkrete sachliche Probleme markierte, die ich daraufhin beheben musste. Die Behauptung des Papers, dass Agents handlungsleitende, strukturierte Review-Ergebnisse erzeugen, die mit denen eines geschulten Reviewers vergleichbar sind, ist für mich nicht spekulativ. Sie ist mein Dienstagsalltag.

Auch das Durchsatz-Argument stimmt, und es ist der Teil, den man unterschätzt. Eine von Agents unterstützte Entwicklerin erzeugt mehr Pull Requests pro Tag, als die menschliche Review-Kapazität aufnehmen kann. Wenn der Schreibende schnell ist und der Reviewer ein Mensch, wird die Review-Warteschlange zur bindenden Beschränkung, und das Review verkommt unter Zeitdruck zur Formalität.¹ Monperrus hat recht, dass die naive Anordnung, bei der Agents schreiben und ein Mensch abnickt, keine echte Gewähr bietet. Ein Mensch, der zustimmt, weil der Code korrekt aussieht und die Tests durchlaufen, reviewt nicht. Er unterschreibt.

Die von ihm beschriebene Pipeline ist die, die ich betreibe

Was das Paper als Ersatz für das menschliche Review vorschlägt, ist nicht „vertraue einem Modell”. Es ist eine Agent-in-the-Loop-Verifikationspipeline: mehrere unabhängige Agents, idealerweise verschiedene Modelle, die kalibrierte, strukturierte Freigaben erzeugen (Testabdeckung, Sicherheits-Scans, Reasoning-Traces als JSON oder SARIF, das Standard-Austauschformat für Ergebnisse statischer Analyse) anstelle informeller Kommentarstränge, wobei die Agents angewiesen sind, sich bei Unsicherheit zu enthalten, und Menschen für die schweren Fälle vorbehalten bleiben.¹

Das ist, unter anderen Namen, die Architektur, die ich seit einem Jahr aufbaue und über die ich schreibe. Ich habe argumentiert, dass Agent-Pull-Requests kleinere Review-Flächen brauchen, dass automatisiertes Review Widerspruch braucht statt eines einzelnen selbstsicheren Richters, und dass Review-Pakete aus strukturierter Evidenz den informellen Diff-Kommentar ablösen. Ich argumentiere also nicht gegen die Pipeline. Ich habe mitgeholfen, sie zu begründen. Ich argumentiere darüber, was dem Menschen bleibt, sobald die Pipeline existiert, denn ich habe in der Antwort gelebt, und es ist nicht die Antwort, die das Paper gibt.

Wo das Argument bricht: Review war nie nur Prüfung

Monperrus behält den Menschen für riskante Änderungen, neuartige Architektur, regulierte Code-Pfade und ethische Urteile vor, und er rahmt diese als Eskalation: Ausnahmen, die an eine Person weitergeleitet werden, wenn die Agents sie markieren.¹ Diese Rahmung lässt die menschliche Rolle wie eine seltene Unterbrechung an einer ansonsten automatisierten Linie klingen.

Der Betrieb der Linie lehrt das Gegenteil. Der Agent erzeugt nicht seinen eigenen Zweck. Er optimiert auf die Spezifikation, die ihm in die Hand gegeben wird, und bei jeder Änderung, die zählt, muss jemand entscheiden, was korrekt bedeutet, bevor die Agents irgendetwas dagegen prüfen können. Das Paper selbst gesteht die Grenze in seinem Diskussionsteil ein: Agents optimieren auf technische Qualitätsmetriken und sind nicht verlässlich in der Lage zu bemerken, dass eine Telemetrie-Änderung die berechtigte Datenschutzerwartung eines Nutzers verletzt oder dass eine Ranking-Anpassung Verzerrungen verstärkt.¹ Das wird als Beschränkung an den Rändern präsentiert. Es liegt aber nicht an den Rändern. Die Frage „ist diese Änderung korrekt im Hinblick auf das, was wir tatsächlich wollen” steht im Zentrum jedes nicht-trivialen Merges, und es ist genau die Frage, die ein auf eine Spezifikation kalibrierter Agent über die Spezifikation selbst nicht stellen kann.

Ich habe das ganz konkret bei den beiden Beiträgen gespürt, die ich vor diesem veröffentlicht habe. Der Agent-Reviewer bewertete sie und fing bei jedem einen sachlichen Übergriff ab: in dem einen eine unbelegte institutionelle Behauptung, in dem anderen eine falsch zugeordnete Statistik. Das Aufspüren war Sache des Agents. Die Korrektur nicht. Zu entscheiden, wie ein Übergriff wahrheitsgemäß zu korrigieren ist, welche Quelle die Behauptung tatsächlich stützte, wie die ehrliche Fassung des Satzes lautete, erforderte ein Urteil über die Intention, das das Bewertungsraster markieren, aber nicht auflösen konnte. Der Agent fand, dass etwas falsch war. Ein Mensch entschied, wie richtig aussah. Diese Arbeitsteilung ist die Verlagerung, und sie geschah bei routinemäßigen Inhalten, nicht bei einem regulierten Grenzfall.

Der Mensch verlässt die Schleife also nicht. Der Mensch wandert von ihrem Ende an ihren Anfang. Früher war das Review der letzte Kontrollpunkt, eine Person, die fertigen Code prüft. In einer Agent-Pipeline ist die Prüfung automatisiert, und die unhintergehbare menschliche Arbeit wandert nach vorn: die Intention so präzise zu spezifizieren, dass die Agents etwas Wahres haben, woran sie verifizieren können, und die Konsequenzen zu verantworten, wenn das ausgelieferte Ergebnis die Spezifikation erfüllt, aber am Ziel vorbeigeht. Rechenschaft lässt sich nicht an ein System delegieren, das auf Metriken optimiert, denn Rechenschaft ist die Bereitschaft, absichtlich falschzuliegen und dafür einzustehen.

Die ehrliche Fassung der These

Streicht man die Provokation aus dem Titel, ist die haltbare These enger als „das Ende des Code Reviews”. Die haltbare These ist das Ende des Menschen als Diff-Prüfer und obligatorisches Freigabe-Häkchen. Diese Rolle ist tatsächlich am Ende, und das Gegenteil zu behaupten, um ein bequemes Ritual zu schützen, ist seinerseits eine Form der Unehrlichkeit. Teams, die einen Menschen als Theater auf dem Prüfsitz halten und Agent-Code abnicken, den sie gar nicht wirklich durchdringen können, haben die Gewähr, die sie zu haben glauben, bereits verloren.

Doch „Code Review” war immer ein stellvertretendes Wort. Es benannte einen Kontrollpunkt und meinte ein Urteil: Tut diese Änderung, was wir brauchen, auf sichere Weise und so, dass wir dafür einstehen können. Automatisiert man den Kontrollpunkt, verflüchtigt sich das Urteil nicht. Es verlagert sich auf die Spezifikation der Intention beim Eingang und die Rechenschaft beim Ausgang, und in einem Team, das sich mit Agent-Geschwindigkeit bewegt, wird es wichtiger, nicht unwichtiger, denn die Agents werden getreulich und rasch alles bauen, was die Spezifikation vorgibt, einschließlich des Falschen. Je schneller der Schreibende, desto mehr wird der Engpass die Frage, was man verlangen soll. Monperrus hat recht, dass der Reviewer abgelöst wird. Er irrt darin, dass das Review endet. Es wandert auf den einen Sitz, den der Agent nicht einnehmen kann.

Zentrale Erkenntnisse

Für Engineering-Verantwortliche: - Hören Sie auf, menschliches Review als Diff-Prüfung zu besetzen. Agents leisten das besser und kontinuierlich; ein menschliches Freigabe-Häkchen auf Agent-Code ist Gewähr-Theater. - Verlagern Sie diese menschliche Kapazität auf die Spezifikation der Intention und auf Rechenschaft, jene Teile des Reviews, die darüber entscheiden, ob spezifikationskorrekt auch tatsächlich-korrekt ist.

Für Entwickler von Developer-Tools: - Bauen Sie die Ensemble-Review-Pipeline, die das Paper beschreibt: mehrere Modelle, kalibrierte Enthaltung, strukturierte Freigabe. Der Widerspruch zwischen den Reviewern ist das Signal. - Gestalten Sie den Anfang der Pipeline, nicht nur das Tor. Die wertvollste Fläche ist dort, wo ein Mensch die Intention in eine Spezifikation verwandelt, gegen die die Agents verifizieren können.

Für Engineers: - Ihre Review-Fähigkeit wird nicht wertlos; sie ändert ihre Adresse. Der Wert wandert vom Aufspüren des Fehlers im Diff hin zur Definition dessen, was der Code tun sollte, und zur Verantwortung für das Ergebnis.

FAQ

Bedeutet dieses Paper, dass das menschliche Code Review vorbei ist?

Der Mensch als Zeile-für-Zeile-Diff-Prüfer und obligatorischer Freigebender ist vorbei, was der stärkste Punkt des Papers ist: Agents leisten die systematische Prüfung besser und bei jedem Commit. Was nicht endet, ist das Urteil, für das das Code Review ein Stellvertreter war, nämlich ob eine Änderung für ihren tatsächlichen Zweck korrekt ist. Dieses Urteil verlagert sich auf die Spezifikation der Intention und die Verantwortung für die Konsequenzen, statt zu verschwinden.

Was argumentiert Monperrus tatsächlich?

Dass Coding Agents nun jedes erklärte Ziel des Code Reviews (Fehlererkennung, Stil, Wissenstransfer, Sicherheit) zu geringeren Kosten und höherem Durchsatz erfüllen, und dass es eine Sackgasse ist, Menschen als obligatorische Reviewer von Agent-geschriebenem Code zu behalten, weil das keine echte Gewähr bietet und nicht skalieren kann. Er schlägt ein Agent-Ensemble vor, das strukturierte Freigaben erzeugt, wobei Menschen für riskante und ethische Fälle vorbehalten bleiben. Es ist ein Positionspapier, keine empirische Studie.¹

Wo ist das Argument am schwächsten?

Darin, die verbleibende menschliche Rolle als seltene Eskalation zu behandeln. In der Praxis ist die menschliche Rolle bei jeder nicht-trivialen Änderung tragend, weil der Agent auf eine Spezifikation optimiert, die er weder verfassen noch hinterfragen kann. Die Spezifikation zu definieren und für das Ergebnis einzustehen, ist zentrale Arbeit, kein Grenzfall.

Sollten Teams einen menschlichen Freigabeschritt bei Agent-Pull-Requests beibehalten?

Nicht als Prüfungs-Theater. Wenn der Mensch die Änderung nicht wirklich durchdringen kann, ist die Freigabe eine Unterschrift, kein Review. Besser ist es, die menschliche Mühe vorgelagert zu investieren, in die präzise Spezifikation der Intention, und nachgelagert, in die Verantwortung für das ausgelieferte Ergebnis, während man ein Agent-Ensemble die Prüfung übernehmen lässt.

Quellen

• Martin Monperrus, „The End of Code Review: Coding Agents Supersede Human Inspection”, arXiv, 11. Juni 2026: arxiv.org/abs/2606.13175. Ein Positionspapier, das bestehende Leistungsbelege zusammenführt; es zählt die Ziele des Code Reviews nach Bacchelli und Bird auf, verweist auf die SWE-bench-Leistungskurve und erörtert Beschränkungen einschließlich Halluzination, Prompt Injection und ethischer Rechenschaft.
• Alberto Bacchelli und Christian Bird, „Expectations, Outcomes, and Challenges of Modern Code Review”, ICSE 2013, die empirische Quelle für die Taxonomie der Review-Ziele, auf die das Paper aufbaut: Microsoft Research
• Carlos E. Jimenez et al., „SWE-bench: Can Language Models Resolve Real-World GitHub Issues?”, ICLR 2024, der Benchmark hinter der Leistungskurve (das beste Modell löste beim Start 1,96 %): arxiv.org/abs/2310.06770
• Verwandte Texte zum Agent-Review aus der Produktionserfahrung: kleinere Review-Flächen, Review braucht Widerspruch, Review-Pakete und die autonome Build-Schleife, deren Tor mit drei Reviewern die Pipeline ist, deren Betrieb dieser Beitrag beschreibt.