Agentischer Code-Review

• Durch die rasante Leistungssteigerung von Coding-Agenten verlagert sich der schwierige Teil im Engineering vom Schreiben von Code zur Entscheidung, ob diesem Code vertraut werden kann; Review wird zur Aufgabe mit dem höchsten Hebel
• AI steigert den Output massiv, verschlechtert aber Qualität und Reviewbarkeit; gemessen wurde eine Lücke, bei der bei 4× mehr Code der tatsächliche Wert nur um etwa 10 % steigt
• Wie intensiv ein Review sein muss, hängt vom Blast Radius einer Änderung ab; ein Solo-Entwickler und ein Team, das seit 10 Jahren ein großes System pflegt, haben völlig unterschiedliche Einschränkungen
• Agenten führen Schlussfolgerungen durch, aber diese werden nicht dem PR beigefügt und verworfen, wodurch Reviewer die verschwundene Absicht (intent) von Grund auf rekonstruieren müssen
• Schreiben ist billiger geworden, Verstehen bleibt teuer; Teams, die vertrauenswürdige Review-Systeme aufbauen, werden künftig im Vorteil sein

---

Was die Daten von 2026 tatsächlich zeigen

• Behauptungen, die jahrelang nur aus Anekdoten und Debatten bestanden, wurden nun in großem Maßstab von Organisationen mit unterschiedlichen Interessenlagen (teils sogar Konkurrenzverhältnissen) gemessen; alle kommen zum gleichen Schluss: AI lässt den Output explodieren, verschlechtert aber Qualität und Reviewbarkeit

• Faros-AI-Messung (Daten von März 2026)

  • Nachverfolgung der Umstellung von geringer auf hohe AI-Nutzung bei 4.000 Teams mit 22.000 Entwicklern
  • Positive Seite: Entwickler mergen mehr PRs und erledigen mehr Arbeit; der Durchsatz pro Engineer steigt
  • Negative Kennzahlen
    • Code-Churn +861 %
    • Verhältnis Incidents pro PR +242,7 %
    • Fehlerrate pro Entwickler von 9 % auf 54 %
    • Median der Review-Dauer +441,5 % (Zeit bis zum ersten Review und durchschnittliche Review-Zeit jeweils etwa verdoppelt)
    • PRs, die ohne Review gemergt wurden, +31,3 %
  • Merges ohne Review sind keine bewusste Entscheidung, sondern das Ergebnis davon, dass Reviewer mit der Menge nicht mehr hinterherkommen und ungelesener Code routinemäßig gemergt wird
  • Selbst Teams mit reifen und disziplinierten Engineering-Praktiken werden gleich stark getroffen; gute Prozesse schützen nicht (weil das Volumen schneller ankommt, als Prozesse gestaltet werden können)

• CodeRabbit-Studie (Dezember 2025)

  • Analyse von 470 Open-Source-PRs (320 mit AI-Koautorschaft, 150 nur von Menschen); AI-Änderungen gingen mit etwa 1,7× mehr Issues einher
    • Logik- und Korrektheitsprobleme etwa 75 % häufiger
    • Sicherheitsprobleme 1,5- bis 2-mal häufiger
    • Lesbarkeitsprobleme mehr als 3-mal häufiger
  • AI Director David Loker: „Eine vorhersehbare und messbare Schwäche, die Organisationen aktiv abmildern müssen“ — da die Schwäche bekannt und lokalisierbar ist, lässt sich der Review-Prozess gezielt darauf ausrichten

• GitClear-Produktivitätsdaten (bis 2025)

  • Nutzer, die AI täglich verwenden, erzielen gegenüber Nichtnutzern etwa 4× mehr Roh-Output, aber gegenüber sich selbst ein Jahr zuvor nur rund 12 % reale Produktivitätssteigerung
  • Die Struktur bleibt: Menschen müssen den 4× größeren Codeumfang trotzdem vollständig reviewen
  • Bill Harding weist ausdrücklich darauf hin, dass selbst diese 12 % teilweise auf Selection Bias zurückgehen könnten (starke Entwickler konzentrieren sich in der AI-Gruppe)

• GitHub-Bericht

  • Copilot Review wurde kumuliert mehr als 60 Millionen Mal ausgeführt, innerhalb eines Jahres mit 10× Wachstum; bei mehr als jedem fünften Plattform-Review ist ein Agent beteiligt
  • Das ist keine Nischenpraxis mehr, sondern die Art und Weise, wie Code überhaupt entsteht
• Vier Datensätze und vier Methodiken laufen auf dieselbe Schlussfolgerung hinaus: Der Flaschenhals verschwindet nicht, sondern wandert in die Verifikationsphase

Alle lösen unterschiedliche Probleme

• Die meisten warnenden Daten oben stammen aus Enterprise-Telemetrie und von überlasteten Open-Source-Maintainern; auf den Solo-Entwickler, der etwas für sehr wenige Nutzer baut, trifft vieles davon nur eingeschränkt zu

• Drei Variablen bestimmen die Position

  • Blast Radius: Was passiert, wenn etwas kaputtgeht — nichts, oder wütende Nutzer, Geldverlust, Offenlegung von PII
  • Lebensdauer des Codes: ein Wegwerfprototyp für nächste Woche oder eine Codebasis, die über Jahre gepflegt wird
  • Anzahl der Menschen, die den Code verstehen müssen: nur man selbst oder ein Team mit geteilter Ownership über längere Zeit

• Solo, Greenfield, keine Nutzer

  • Die zweite Rolle von Reviews, nämlich Wissensverteilung im Team, existiert nicht (man selbst ist das Team)
  • Vernünftige Wahl: stark auf Tests und Automatisierung setzen, nur wirklich wichtige Teile reviewen, den Rest leicht anfassen
  • Das funktioniert aber nur, wenn die Tests echt sind; wer Reviews ohne Sicherheitsnetz überspringt, spart die Arbeit nicht, sondern verschiebt sie nur teurer in die Zukunft (defer)
  • „Keine Nutzer“ ist eine Erlaubnis, Reviews aufzuschieben, nicht eine Erlaubnis, Verifikation zu überspringen

• Der gefährliche Mittelbereich

  • In dem Moment, in dem ein Projekt Nutzer bekommt, wird die Rolle des Bugfindens plötzlich wichtig (weil Bugs Menschen schaden), und auch Wissensaustausch wird relevant
  • Wenn ein Team dann noch ein paar Monate mit Solo-Gewohnheiten weitermacht und erst nach einem Postmortem aufwacht, werden die Faros-Zahlen zum eigenen Dashboard

• Große Organisationen, alte Codebasen, viele Nutzer

  • Alle Warnkennzahlen gelten hier mit voller Härte; Änderungen, die niemand versteht, werden zu Comprehension Debt (Verständnisschulden) und später zu On-Call-Incidents für irgendwen
  • Der Kern ist nicht „Unternehmen müssen vorsichtig sein, Solo-Leute können locker bleiben“, sondern: Je nach Position ändert sich der Zweck von Reviews, also müssen sich auch die Regeln ändern
  • Wer auf einen Prototypen mit zwei Personen eine Enterprise-Pipeline aus mehreren Agenten plus Belegpflicht setzt, erzeugt sinnlose Reibung; wer bei einem Zahlungssystem „Tests grün, also deployen“ anwendet, baut einen Incident-Generator mit grünem Häkchen

Was Reviews heute tatsächlich leisten

• Wenn Menschen Code schreiben, kommt die Absicht gratis mit; verworfene Alternativen und Abwägungen existieren im Kopf des Autors, und Review bedeutete, dieses Denken zu prüfen
• Moderne Agenten argumentieren ebenfalls und zeigen oft sogar einen sichtbaren Thinking Trace, aber diese Schlussfolgerungen werden verworfen, sobald der Diff erzeugt ist, und nicht an den PR angehängt
• Zudem ist das die Schlussfolgerung des Agenten darüber, wie etwas implementiert werden soll, nicht das menschliche Urteil darüber, ob es überhaupt die richtige Arbeit ist
• Dadurch wandelt sich Review von der Prüfung sichtbarer Argumentation zur Rekonstruktion nicht dokumentierter Absicht — und wird schwerer und langsamer (ein Grund für die 441 %)

• AI Slop and the Software Commons (Paper von 2026)

  • Analyse von 1.154 Beiträgen aus 15 Threads auf Reddit und Hacker News
  • Formulierung eines Entwicklers: Das Review von Agenten-PRs mache ihn zum „ersten Menschen, der diesen Code gesehen hat“
  • Im Wortlaut des Papers: Reviews sind „nicht dafür gebaut, verschwundene Absicht wiederherzustellen“

• Die Lösung ist ein Tooling-Problem

  • Verschwundene Absicht lässt sich wiederherstellen — die Schlussfolgerung existierte ja, sie wurde nur verworfen
  • Wenn Agenten festhalten müssen, was sie erreichen wollten und was sie bewusst ausgeschlossen haben, und das als Decision Log des PR erfasst wird, verschwindet ein großer Teil der Rekonstruktionskosten
• „AI reviewt AI“ allein ist keine vollständige Antwort; ein zweites Modell mit anderem Vorwissen findet zwar viele echte Bugs, kann aber das menschliche Urteil „Ist das überhaupt eine wertvolle Änderung?“ nicht liefern

Die Tools sind gut, aber nicht aus genau den Gründen, mit denen sie werben

• Dedizierte AI-Review-Tools sind inzwischen gut genug, und es ist sinnvoll, bei allem — auch Side Projects — zumindest den Haupt-Coding-Agenten laufen zu lassen (nach Möglichkeit zusätzlich einen dedizierten Review-Agenten)

• Eigenschaften wichtiger Tools

  • CodeRabbit: am weitesten verbreitet, Platz 1 bei F1 im unabhängigen Martian-Benchmark (Januar–Februar 2026), Präzision von rund 49 % bei branchenweit bester Recall
  • Greptile: tauscht Präzision gegen Recall; in einem Benchmark etwa 82 % Bug-Erkennungsrate (gegenüber 44 % bei CodeRabbit), aber mehr False Positives
  • Anthropic Code Review: Weniger als 1 % der Ergebnisse wurden von internen Engineers als Fehler markiert; der Anteil der PRs mit substanziellen Reviews stieg von 16 % auf 54 %

• Parallelversuch mit 4 Reviewern (Ergebnis außerhalb der Vendoren)

  • Ein Engineer setzte CodeRabbit, Sentry Seer, Greptile und Cursor BugBot 3,5 Wochen lang parallel auf 146 echte PRs mit 679 Funden an
  • Von 617 eindeutigen Fundstellen wurden 93,4 % nur von genau einem Tool erkannt, 6 % von zweien, drei fast nie, von allen vieren keine einzige
  • Kein einziges Mal markierten alle vier Tools dieselbe Zeile gemeinsam
  • Jedes Tool hatte andere Stärken: Greptile nahezu ohne False Positives bei Korrektheit und Architektur, CodeRabbit mit dem breitesten Netz und One-Click-Fixes, Seer stark bei der Schwere operativer Ausfälle
  • Heterogenität ist der Schlüssel — viermal dasselbe Modell ist nur ein einzelner Reviewer mit höherer Rechnung, vier tatsächlich unterschiedliche Reviewer finden Bugs, die keiner allein entdeckt

• Praktische Leitlinien

  • Nicht nach dem einen besten Tool suchen (das gibt es nicht)
  • In Hochrisikobereichen bewusst zwei unterschiedlich ausgerichtete Tools parallel einsetzen (im genannten Experiment Greptile für Alltagskorrektheit + Seer für die Schwere operativer Störungen)
  • Für Solo-Entwickler reicht ein guter Reviewer plus echte Tests
  • Unabhängig vom Marketing gilt: immer am eigenen Code messen, denn alle Ergebnisse sind an eine bestimmte Codebasis gebunden

Sollte man AI mehr vom Review überlassen?

• Eine Frage, die vor einem Jahr noch ketzerisch geklungen hätte, wird heute von erfahrenen Engineers gestellt: Sollte die Maschine mehr vom Review übernehmen, vielleicht sogar den Großteil?

• Die unbequeme Tatsache, dass AI-Review funktioniert

  • Bei Anthropic wurden weniger als 1 % der Funde als Fehler markiert; AI findet Bugs, die Menschen übersehen, und ermüdet auch beim 30. PR des Tages nicht (genau dann, wenn Menschen am unzuverlässigsten sind)
  • Umgekehrt kommen Menschen nicht mehr hinterher — 31 % mehr Merges ohne Review, Review-Zeiten mit dreistelligen Zuwächsen
  • Die ehrliche Rahmung ist nicht „Sollten wir AI mehr überlassen?“, sondern „AI tut es bereits — werden wir das bewusst gestalten oder so tun, als würden Menschen alles lesen, und es einfach treiben lassen?“

• Die Sicht aus dem Loop Engineering

  • Die Grundannahme dort lautet, nicht Menschen zu haben, die Agenten prompten, sondern Systeme zu bauen, die Agenten prompten; im Zentrum steht ein Judge-Agent, der entscheidet, ob die Arbeit erledigt ist
  • Der Reviewer wird damit zur nächsten Rolle, die absichtlich aus der inneren Schleife entfernt wird; ein Jahr nach der Automatisierung des Schreibens wird auch Verifikation automatisiert, und der Mensch wird nach oben geschoben

• Das Risiko geschlossener Schleifen

  • Wenn ein Agent schreibt, ein anderer reviewed und ein dritter urteilt, entsteht eine geschlossene Schleife von Modellen mit korrelierten blinden Flecken (correlated blind spots) — besonders dann, wenn sie aus derselben Familie stammen und an denselben Stellen selbstsicher übereinstimmen
  • Ein selbstbewusstes „looks good“ ganz ohne Menschen ist geborgte Sicherheit (borrowed confidence) — das Vertrauen des Systems wird zu meinem Vertrauen, obwohl es niemand wirklich verstanden hat

• Menschen verschwinden nicht, sie steigen eine Ebene höher

  • Der Wechsel geht weg vom Lesen jedes Diffs hin zum Besitz der Teile, die sich nicht an Modelle delegieren lassen; Verantwortlichkeit ist entscheidend
  • Bereiche, die Menschen schützen müssen: die Entscheidung, ob dies überhaupt die richtige Änderung ist; teure Gates für Änderungen mit hohem Blast Radius; und Verhalten, das nie spezifiziert wurde (Modelle reviewen existierenden Code, aber kaum Anforderungen, die niemand aufgeschrieben hat)
  • Von human in the loop zu human on the loop — statt jeden PR zu lesen, das System samplen, spot-checken und auditieren und die begrenzte Aufmerksamkeit dort bündeln, wo Fehler wirklich schmerzen

• Fall Kun Chen (ehemals Meta L8 Engineer, Solo Builder)

  • Liefert rund 40 PRs pro Tag aus und hat klassisches Code-Review faktisch eingestellt; 20–30 Agenten laufen parallel
  • Verlagert den Aufwand auf den Plan — schreibt vorab detaillierte Pläne, lässt Agenten stundenlang arbeiten, und die Qualität des Plans bestimmt, wie lange sie unbeaufsichtigt laufen können
  • Er hat die Verifikation nicht abgeschafft, sondern seine Absicht im Voraus dokumentiert und damit das Problem „erster Mensch, der den Code sieht“ halb gelöst (der Mensch versteht den Grund vorher statt nachher)
  • Er arbeitet nicht ohne Sicherheitsnetz — ein automatisches Review-Gate namens No Mistakes prüft den Code vor dem Merge; wenn Agenten steckenbleiben, wird eskaliert
  • Aber er ist ein Solo Builder ohne großes Team und ohne zehn Jahre alte Minenfeld-Systeme; seine Bedingungen haben die meisten Leser nicht — wer das auf ein Team mit vielen Nutzern kopiert, reproduziert die Faros-Zahlen im eigenen Dashboard
• Schlussfolgerung entlang des Spektrums: Für Solo-Entwickler ohne Nutzer ist es 2026 vertretbar, fast alles der AI zu überlassen; bei großen Setups mit vielen Nutzern übernehmen Maschinen den ersten und zweiten Pass sowie die langweiligen 90 %, aber auf load-bearing paths bleiben echte Menschen im Spiel; wie viele, bestimmt nicht Schuldgefühl, sondern der Blast Radius

Was man konkret tun sollte

• Organisatorisches Prinzip: Review-Aufwand am Preis eines Fehlers ausrichten, billige deterministische Arbeit so weit wie möglich nach vorn ziehen und menschliche Aufmerksamkeit für Aufgaben reservieren, die nur Menschen leisten können

• Nach Risiko staffeln, nicht nach Autor (Tier by risk, not by author)

  • Konfigurationsänderungen brauchen nur Linter und einen kurzen Blick
  • Änderungen an kritischen Business-Logic-Pfaden brauchen den vollen Stack: Typen, Tests, zwei unterschiedliche AI-Reviewer, einen Menschen als Eigentümer des Systems und einen Security-Pass
  • Kein schwergewichtiges Review auf Boilerplate verschwenden und keine großen Änderungen nur deshalb durchwinken, weil die Tests grün sind

• Den teuren Long Tail früh abbrechen (Fast-fail the expensive tail)

  • Early-Stage Prediction of Review Effort (Januar 2026), Studie zu 33.707 agentisch geschriebenen PRs
  • Agenten sind stark bei kleinen, klar definierten Änderungen; etwa 28 % werden fast sofort gemergt, aber sobald subjektives Feedback kommt, „verschwinden“ sie oft und geben das Hin und Her auf, das den Kern von Reviews ausmacht
  • In einem begleitenden Paper von 2026 machen Reviewer-Abbrüche 38 % der abgelehnten Agenten-PRs aus
  • Die Forschenden bauten erfolgreich einen „Circuit Breaker“, der mit billigen Signalen wie Dateityp und Patch-Größe PRs mit hohem Pflegeaufwand vorhersagt, bevor ein Mensch sie anschauen muss

• Die Schwelle für reviewwürdige Änderungen selbst anheben

  • Die Lösung ist nicht, das Repository abzuschließen, sondern Reviews für Änderungen ohne Belege zu verweigern
  • Vor dem Review erforderlich: eine Aussage zum Zweck der Änderung, ein Diff statt 3.500 unkommentierten Zeilen, Testausgaben und Nachweise, dass die Änderung tatsächlich ausgeführt wurde
  • Statt die teure Rekonstruktion der Absicht selbst zu übernehmen, gibt man diese Arbeit an den Einreicher zurück, der sie billig erledigen kann

• PRs bewusst klein halten

  • Agenten-PRs werden groß (laut Faros im Schnitt 51 % größer), und Reviewer-Beteiligung ist einer der stärksten Prädiktoren dafür, ob ein PR gemergt wird
  • Große, nicht reviewbare PRs werden entweder sofort abgelehnt oder — schlimmer noch — nur abgestempelt
  • Agenten gezielt zu kleinen Commits anweisen; ein Diff, das ein Mensch wirklich lesen kann, ist kein höfliches Extra mehr, sondern eine Design Constraint

• Teständerungen aufmerksamer lesen als den Code

  • Zu beobachtender Fehlermodus von Agenten: Verhalten wird geändert, danach werden Assertions umgeschrieben, damit sie zum neuen fehlerhaften Verhalten passen, und so die Tests „repariert“
  • Ein grüner Check über 200 bearbeiteten Tests ist bedeutungslos, solange nicht geklärt ist, ob die Änderungen richtig waren; Diffs, die viele Tests umschreiben, sollten zuerst gelesen und als Warnsignal behandelt werden
  • Der Wert von Mutation Testing: Coverage zeigt, ob eine Zeile ausgeführt wurde; Mutation Testing zeigt, ob die Tests merken würden, wenn diese Zeile falsch wäre

• CI wie eine unbewegliche Wand behandeln

  • Auf Muster achten, vor denen GitHub Reviewer warnt: entfernte Tests, übersprungene Lints, abgesenkte Coverage-Schwellen, duplizierte Helper trotz bereits vorhandener Varianten, nicht vertrauenswürdige Eingaben, die in Prompts fließen
  • Letzteres ist besonders wichtig — von Agenten gebaute Features erzeugen eine neue Quelle für Prompt Injection; wenn nutzerkontrollierter Text ungefiltert in LLM-Aufrufe gelangt, ist die Schwachstelle nicht im Diff sichtbar, sondern steckt in später eintreffenden Daten
  • Agenten schwächen CI nicht aus Bosheit, sondern weil der billigste Weg zu grün oft genau dort liegt; deterministische Gates sind der einzige Teil, den keine selbstsicheren Absätze überstimmen können, also müssen sie hart bleiben

• Merges bleiben Sache von Menschen

  • Modelle können weder gepaged werden noch Verantwortung tragen; die Person, die auf Merge klickt, trägt die Ownership
  • Wenn ein AI-Review in ruhigem, selbstsicherem Ton „looks good“ sagt, übergibt es zwangsläufig eine Sicherheit, die nicht verdient wurde
  • Jedes AI-Review deshalb als Sensor behandeln, nicht als Urteil — Daten, nicht Entscheidung

Was das für Teamführung bedeutet

• Die eigentliche Beschränkung für Shipping ist nicht mehr, wie schnell Code geschrieben wird, sondern wie schnell eine vertrauenswürdige Person von der Korrektheit einer Änderung überzeugt werden kann
• Jede Planung, die Generierung als Bottleneck sieht und Review als kostenlos annimmt, bleibt trotz grüner Speed-Dashboards still stehen
• Der Faros-Bericht sagt ausdrücklich, dass mit höherem Output auch QA- und Review-Arbeit zunimmt; Engineering-Stellen mit dem Argument „Dank AI sind wir schneller“ abzubauen, bevor die Review-Lücke geschlossen ist, ist riskant
• Die Senior-Engineer-Steuer aus dreistellig gestiegenen Review-Zeiten trifft am härtesten genau die Personen, die am wenigsten zum Bottleneck werden dürfen, und sie ist in Metriken, die nur gemergte PRs zählen, unsichtbar
• Open-Source-Maintainer stoßen zuerst und am härtesten gegen diese Wand — ein stetiger Strom plausibel wirkender, aber leerer Beiträge verbraucht selbst bei gutem Willen reale Triage-Zeit; das ist der Kanarienvogel im Bergwerk, Unternehmen sind als Nächstes dran
• Wer gut reagiert, behandelt Review-Kapazität nicht als von AI freigespielten Bonus, sondern als reale Ressource, die gemessen, geschützt und bewusst verbraucht werden muss

Schreiben wurde billig, Verstehen nicht

• Keine pauschalen Antworten von den Extremen akzeptieren — für Solo-Entwickler ohne Nutzer sind die Churn- und Duplikations-Horrorgeschichten der Enterprise-Welt kein heutiges Feuer, sondern ein zukünftiges Risiko; also auf Tests setzen, nur Wichtiges reviewen und ehrlich anerkennen, dass aufgeschobene Arbeit trotzdem Schulden bleibt
• Wer in großen Setups mit vielen Nutzern arbeitet, für den gelten alle Warnzahlen in diesem Text direkt; gültig sind dann nur Staffelung, Belegpflicht, bewusst heterogene Review-Prozesse und Menschen, die den Merge besitzen
• Was über das ganze Spektrum hinweg unverändert bleibt, ist die grundlegende Ökonomie — Schreiben wurde billig, Verstehen bleibt so teuer wie immer
• Teams, die künftig gut sind, sind nicht die Teams, die am meisten Code generieren, sondern die, die Review-Systeme aufbauen, denen man tatsächlich vertrauen kann; Teams, die „Tests sind grün“ niemals mit „Ein Mensch versteht, was das ist und warum es das tut“ verwechseln
• In Simon Willisons Worten besteht der Kern der Arbeit darin, Code zu liefern, dessen Funktion nachgewiesen ist — Agenten haben das nicht verändert, sondern den Nachweis vom Nebenaspekt ins Zentrum der Arbeit gerückt
• Die Fähigkeit, ein System gut genug zu verstehen, um dafür geradezustehen, bleibt die dauerhafteste und interessanteste Fähigkeit in der Softwareentwicklung — und es ist eine ausgezeichnete Zeit, darin extrem gut zu werden