An diesem Morgen melden sich in einem Pull Request vier Stimmen zu Wort. Eine Kollegin hat einen Kommentar hinterlassen. Dazu kommen zwölf Anmerkungen von CodeRabbit. Der Code selbst stammt von Claude Code. Und ein zweiter Agent widerspricht dem ersten in der Frage, ob ein Fehlerfall überhaupt behandelt werden muss. Der Maintainer muss vor dem Stand-up entscheiden, welche dieser Stimmen zählt.
So sieht KI-Code-Review 2026 aus. Es ist nicht mehr nur eine Beziehung zwischen zwei Menschen, sondern ein Prozess mit menschlichen und maschinellen Beteiligten. Und niemand hat dem Team gesagt, welche Regeln dafür gelten.
Kurz gefasst: „KI-Code-Review“ ist keine einzelne Tätigkeit, sondern ein Vier-Parteien-Problem: Mensch prüft Mensch, KI prüft Mensch, Mensch prüft KI, KI prüft KI. Jede Konstellation hat ein anderes Versagensmuster und braucht eine andere Regel. KI-Reviewer arbeiten bei einzelnen Zeilen zuverlässig und haben strukturelle Schwächen, wenn es um die Frage geht, ob eine Änderung überhaupt existieren sollte. Wer alle vier gleich behandelt, regelt drei davon falsch.
Wer das Thema neben Einführung, Werkzeugauswahl und Erfolgsmessung einordnen will, findet im Leitfaden zu Coding Agents im Team den breiteren Rahmen. Dass der eigentliche Engpass im Pull Request liegt und nicht im Schreiben von Code, setzt dieser Beitrag voraus; die Telemetrie dazu steht in Der wahre Engpass sitzt im Pull Request. Dort war Review der Flaschenhals. Hier geht es darum, was Review überhaupt noch ist, wenn Autor und Reviewer Maschinen sein können.
Vier Parteien, nicht zwei
2020 war Code-Review noch eine Beziehung zwischen zwei Menschen. Ein Autor schrieb Code, eine Reviewerin las ihn, und beide stritten im Zweifel über Code einer dritten Person, der gerade geändert wurde. Drei Menschen, ein gemeinsames Vokabular, eine geteilte Vorstellung davon, warum der Code so aussieht, wie er aussieht.
2026 zerfällt diese Symmetrie in mindestens vier unterscheidbare Konstellationen.
Mensch prüft Mensch ist die ursprüngliche Beziehung. Sie findet noch statt, nur seltener, als die Führungsebene glaubt.
KI prüft Mensch ist das Produkt, das die meisten Anbieter verkaufen: CodeRabbit, Greptile oder Claude Code Review kommentieren einen manuell erstellten Pull Request.
Mensch prüft KI ist der Alltag in Teams, in denen Agenten selbst Pull Requests öffnen. Die Reviewerin übernimmt faktisch die Verantwortung für fremd erzeugten Code. Sie muss Code verstehen, den sie nicht geschrieben hat und nicht vorhersehen konnte.
KI prüft KI wird zur Normalität, sobald Teams Agenten schreiben lassen und jeden Pull Request zusätzlich von einem Reviewer-Agenten prüfen lassen. Anthropic berichtet immerhin, dass intern bei nahezu jedem Pull Request ein Agent mitliest. Ob der jeweilige PR vollständig von einer KI stammt, sagt diese Zahl nicht, aber sie zeigt, in welche Richtung sich die Standardkonfiguration entwickelt.
Dass KI in diesen Workflows angekommen ist, deuten die Umfragedaten von Stack Overflow an, wenn auch nur grob: Die Kategorie fasst Committen und Reviewen zusammen, taugt also nicht als isolierter Beleg. 2025 erledigten 10,2 Prozent der Befragten diesen Schritt überwiegend mit KI, weitere 22,6 Prozent teilweise. In Teams mit Coding Agents wird der Pull Request zur eigentlichen Kontrollstelle, und dort ist Review keine einzelne Kategorie mehr, sondern vier verschiedene.
Was KI-Reviewer wirklich können
Auf der Ebene einzelner Zeilen sind KI-Reviewer zuverlässig, als gelöstes Problem gilt Code-Review damit nicht. Der belastbarste Beleg zuerst. Im Februar 2026 hat das Forschungslabor Martian seinen Code Review Bench veröffentlicht, einen wissenschaftlich angelegten Benchmark mit offener Methodik: über 200.000 reale Pull Requests, eine Online-Auswertung echten Entwicklerverhaltens und ein Offline-Set mit von Hand geprüften Referenzkommentaren. Das ist kein perfekter Maßstab und kein begutachtetes Paper. Es ist derzeit aber der beste öffentliche Anhaltspunkt für diese Kategorie.
Die ernüchternde Zahl daraus: In den im März und April 2026 veröffentlichten Momentaufnahmen lagen starke Systeme grob zwischen 50 und F1-Werten im mittleren 60er-Bereich. CodeRabbit meldete für sich 51,2 Prozent, cubic 61,8 Prozent, Qodo in seiner stärkeren Variante etwas darüber. Welches Tool vorn liegt, hängt vom Messzeitpunkt ab, und F1 ist ohnehin nicht für jedes Teamziel die richtige Metrik. Wichtiger als die Rangliste ist die Größenordnung: Code-Review durch KI ist noch kein gelöstes Problem. F1 bündelt Präzision und Recall in einer einzigen Zahl; ein Wert um 55 reicht für eine zusätzliche Prüfschicht, nicht für eine automatische Freigabe. Selbst das beste veröffentlichte Ergebnis erkannte im Gold-Set nicht mehr als rund 63 Prozent der bekannten Probleme. Das ist nicht peinlich. Es ist eine realistische Ausgangslage.
Die zweite Datenquelle ist stärker und schwächer zugleich. Anthropic hat im März 2026 interne Zahlen zu Claude Code Review veröffentlicht: Der Anteil substanzieller Kommentare stieg von 16 auf 54 Prozent der PRs. Bei Änderungen mit mehr als 1.000 Zeilen findet das System in 84 Prozent der Fälle etwas, im Schnitt 7,5 Anmerkungen. Weniger als ein Prozent der Befunde wird als falsch markiert. Ein Review kostet zwischen 15 und 25 Dollar. Diese Zahlen sind anbieterintern, und das ist keine Formalie: Es sind Anthropic-Daten zu Anthropic-Code, bewertet von Anthropic-Ingenieuren. Die Zahlen sind plausibel. Die Übertragung auf ein Mittelstandsteam in Köln ist nicht automatisch gerechtfertigt.
Wichtiger als die Zahlen ist der Mechanismus dahinter. KI-Reviewer sind zuverlässig gut in einem klar umrissenen Bereich: Konsistenz, das Durchsetzen von Konventionen, vergessene Null-Prüfungen, offensichtliche Nebenläufigkeitsfallen, die Klasse von Fehlern, über die ein abgelenkter Mensch hinwegliest. Das hat echten Nutzen. Nur bestand Code-Review nie größtenteils daraus.
Was KI-Reviewer systematisch verpassen
Was KI-Reviewer verpassen, liegt selten an der Rechenleistung und fast immer am fehlenden Kontext. Ein deutscher Praxisbeitrag bei Informatik Aktuell kommt zu einem ähnlich nüchternen Fazit: GenAI kann Review unterstützen, soll aber spezialisierte Werkzeuge und das Vier-Augen-Prinzip nicht ersetzen. Das liegt vor allem an drei Schwächen.
Kontextarmut. Ein KI-Reviewer sieht den Diff, manchmal die Datei, selten das ganze Repository, fast nie das Ticket, die Architekturentscheidung oder das Gespräch vor drei Sprints, das erklärt, warum der Code so geschrieben ist. CodeRabbit hat in einer eigenen, anbieternahen Analyse von 470 Open-Source-PRs berichtet, dass bei Pull Requests, an denen eine KI mitgeschrieben hat, rund 1,7-mal so viele Befunde gemeldet wurden wie bei rein menschlichen. Die KI-Autorschaft wurde dabei über Signale abgeleitet, nicht direkt bewiesen. Besonders folgenreich war eine Kategorie: Logik- und Korrektheitsfehler, also Geschäftslogik, Kontrollfluss und Konfiguration, traten rund 75 Prozent häufiger auf. Die Auswertung stammt von einem Anbieter, der Code Review verkauft. Als Richtungsangabe taugt sie, als neutraler Beweis nicht.
Blindheit gegenüber Absicht. Greptile, Qodo und Augment Code bauen Kontextgraphen der Codebasis, und mit MCP- und Ticket-Integrationen lässt sich immer mehr Kontext anbinden. Trotzdem erkennt das System die Produktabsicht nur in dem Maß, in dem sie im mitgelieferten Kontext steht: Ticket, ADR, die Ausnahmeentscheidung von vor drei Sprints. Fehlt der, kennt der Agent den Satz nicht, der auf dem Ticket steht: „Für diesen Endpunkt keine idempotenten Retries, das hat letztes Mal die Abrechnung zerschossen.“ Er bewertet dann die Form der Änderung, nicht ihren Zweck. Eine korrekte Umsetzung der falschen Anforderung kann er nicht beanstanden. Das ist keine fehlende Produktfunktion. Das ist die Natur des Problems.
Architekturblindheit. Ein von Augment veröffentlichter Test an einem Monorepo mit 450.000 Dateien zeigt die Grenze deutlich: Die getesteten Open-Source-Reviewer prüften durchweg nur einzelne Dateien und verfehlten Brüche zwischen Diensten. Wenn eine Änderung in Dienst A eine Annahme in Dienst B verletzte, analysierte das Tool jede Datei für sich korrekt, ohne zu erkennen, dass beide voneinander abhingen. Auch das ist eine Anbieter-Quelle mit eigenem Produkt im Spiel, also ein Beispiel, kein Beweis.
Die praktische Heuristik dahinter: KI-Reviewer sind zuverlässig gut darin, Fragen wie „ist diese Zeile korrekt?“ zu beantworten. Sie sind strukturell schlecht darin, Fragen wie „sollte diese Änderung überhaupt existieren?“ zu beantworten. Die zweite Frage ist die folgenreichere.
Vier Konfigurationen, vier Regeln
Aus vier Versagensmustern folgen vier Regeln. Eine pro Konstellation.
Mensch prüft Mensch bleibt der Standard für kritische Pfade. Authentifizierung, Zahlungsverkehr, Datenmigrationen, alles mit Compliance-Bezug. Kein Agent entscheidet hier über den Merge. Ein namentlich bekannter Mensch unterschreibt. Das ist keine Skepsis gegen KI. Das ist Haftung. Es ist im Übrigen auch die Position von Anthropic: Das eigene System gibt PRs nicht frei, ein Mensch entscheidet zuletzt.
KI prüft Mensch liefert den größten Nutzen bei geringem Aufwand, solange sie als zusätzliche Stimme eingesetzt wird und nicht als Freigabeinstanz. KI-Reviewer gehören in die CI-Pipeline, nicht in den Merge-Button. Die einzeilige Änderung, die unbemerkt die Authentifizierung gebrochen hätte und die ein KI-Reviewer erkennt: Darin liegt der Wert. Die 7,5 Anmerkungen pro großem PR, wenn niemand die Befunde nach Wichtigkeit ordnet: Darin liegt zugleich das Risiko. Eine ungefilterte Liste ist kein Review, sondern neue Arbeit.
Mensch prüft KI ist die Konstellation, die die meisten Teams noch nicht als eigene Kategorie erkannt haben. Wer einen Agenten-PR prüft, ist kein Reviewer im klassischen Sinn. Diese Person ist faktisch mitverantwortlich für den Code und muss Code verstehen, den sie nicht geschrieben hat. Das braucht mehr Zeit, nicht weniger. Und es braucht einen Menschen, der den PR verantwortet, nicht nur einen, der ihn liest. Überprüfbar wird diese Konstellation überhaupt erst durch kleine PRs. Meine Faustregel aus The Magic Words That Make AI Code Better gilt hier unverändert: höchstens drei Dateien, etwa achtzig geänderte Zeilen pro Pull Request. Ein Agenten-PR mit 600 Zeilen ist kein Review-Problem. Er ist ein Prozessfehler.
KI prüft KI ist die neue Standardkonstellation in Teams, die Agenten ausgiebig einsetzen. Sie funktioniert am besten als Vorfilter, nicht als Abschluss. Der Agent, der die Änderung geschrieben hat, zielt auf eine akzeptable Lösung, nicht auf einen kritischen Gegenblick; der prüfende Agent ist eine zweite, unabhängige Prüfung. Beide zusammen ersetzen trotzdem nicht den Menschen, der am Ende entscheidet, ob der Code überhaupt existieren sollte. Wer diesen menschlichen Abschluss wegspart, spart das Falsche ein.
Review war nie nur Bug-Suche
Review war immer auch die Frage, ob der Code, den wir gerade schreiben, der Code ist, den wir schreiben wollten. Diese Frage darf kein Agent allein beantworten. Er kann nur schneller prüfen, ob wir diese Frage klar genug formuliert haben. Review schützt nicht nur den Code. Review schützt das mentale Modell des Teams.
Deshalb ist „wer prüft wen?“ keine Spielerei mit Begriffen, sondern eine Governance-Entscheidung. Sie legt fest, was ein KI-Reviewer entscheiden darf, was er nur melden soll und wo ein benannter Mensch unterschreiben muss. Das ist kein Werkzeugproblem, und kein weiteres Tool löst es. Wenn Sie diese vier Regeln für Ihr Team sauber ziehen wollen, klären wir das in einem Vorgespräch zu klaren Review-Verantwortlichkeiten.
