c-CRAB, die Code-Review-Agenten-Benchmark: Was sie misst, was sie herausgefunden hat und was 41,5 % wirklich bedeutet

Ein Code-Review-Agent und ein menschlicher Prüfer untersuchten denselben Pull-Request und äußerten dieselbe Sorge. Wenn man den Kommentar des Agenten befolgt, wird der Fehler behoben; der Test besteht. Und jede Textähnlichkeitsmetrik, die die Autoren berechneten, bewertete die Überprüfung des Agenten als im Wesentlichen unzusammenhängend mit der des Menschen: BLEU-4 0.00, ROUGE-L 7.02, chrF 20.74, Embedding-Ähnlichkeit 54.59. Dieselbe Sorge, andere Worte, und die übliche Methode zur Bewertung einer Überprüfung konnte nicht erkennen, dass sie übereinstimmten. Dieses eine Beispiel ist das Argument hinter c-CRAB (ausgesprochen „see-crab“), dem Code Review Agent Benchmark, veröffentlicht als arXiv:2603.23448.

c-CRAB bewertet Code-Review-Agenten, nicht Agenten, die Code schreiben. Bei einem Pull-Request — der von einem Menschen oder von einem Coding-Agenten stammen kann — erstellt ein Review-Agent ein Review, und c-CRAB bewertet dieses Review danach, ob dessen Umsetzung einen verhaltensmäßig korrekten Fix hervorbringt. Die Benchmark wurde von den Software-Engineering-Forschern Yuntong Zhang, Zhiyuan Pan, Imam Nur Bani Yusuf, Haifeng Ruan, Ridwan Shariffdeen und Abhik Roychoudhury entwickelt und bewertet vier Tools: PR-Agent, Devin, Claude Code und Codex. Einer der Autoren steht in Verbindung mit SonarSource, und das Paper legt ausdrücklich dar, was das bedeutet und was nicht, in seinen eigenen Worten: “Die in diesem Paper geäußerten Ansichten und Schlussfolgerungen sind allein die der Autoren und stellen weder die offiziellen Richtlinien noch die Empfehlungen von SonarSource dar. Darüber hinaus sind die hierin präsentierten Ergebnisse unabhängig und sollten nicht als Bewertung der Qualität der Produkte von SonarSource interpretiert werden.”

Zwei Anmerkungen vorab. Einige Berichte Dritter bezeichnen dieselbe Arbeit als “CR-bench”; es ist derselbe Benchmark, und diese Seite verwendet durchgängig c-CRAB. Jede Abbildung unten ist das vom Paper selbst berichtete Ergebnis, heute aus dem Paper und dem Replikationspaket entnommen — nicht unabhängig erneut ausgeführt — und die Interpretation ist unsere eigene, ergänzt um die Praktiker-Diskussion, die das Paper bereits ausgelöst hat. Nichts davon ist eine Empfehlung der Anbieter, deren Werkzeuge bewertet wurden. Und wenn Sie noch darüber entscheiden, ob Sie überhaupt einen Code-Review-Agenten einsetzen möchten, ist unser Käuferleitfaden zu Code-Review-Agenten der bessere Einstieg; auf dieser Seite geht es darum, wie diese Agenten gemessen werden.

Warum c-CRAB Rezensionen mit Tests bewertet, nicht mit einem LLM-Richter

Die übliche Methode, einen Code-Review-Agenten zu bewerten, besteht darin, seine Bewertung mit der eines Menschen zu vergleichen, mithilfe eines LLM-as-judge oder einer Textähnlichkeitsmetrik. Die Autoren von c-CRAB lehnen beides ab. LLM-as-judge, so argumentieren sie, leidet unter Bias, Instabilität und Prompt-Sensitivität, was reproduzierbare, konsistente Bewertungen erschwert. Und die obige Fallstudie zeigt, was String-Metriken tatsächlich messen: Wortlaut, nicht Effektivität. Bei diesem Pull-Request zu python-telegram-bot sagte die Codex-Bewertung das Gleiche wie der Mensch, und BLEU-4 und ROUGE-L konnten es nicht erkennen.

Also macht c-CRAB das Gegenteil. Jeder menschliche Review-Kommentar wird in einen ausführbaren Test umgewandelt, der das zugrunde liegende Problem erfasst. Ein Review-Kommentar gilt als korrekt, wenn das Handeln danach eine verhaltensorientiert korrekte Korrektur erzeugt – eine, die den Test bestehen lässt. Jede Instanz wird mit einer ausführbaren Docker-Umgebung ausgeliefert, sodass die Entscheidung über Bestehen/Nichtbestehen durch das Ausführen von Code getroffen wird, nicht indem ein anderes Modell gefragt wird, wie ähnlich sich zwei Texte sind. Deshalb ist das wichtig: Die Aufgabe einer Review besteht darin, zu verändern, was ein Entwickler tut, und ein Test ist das einzige Bewertungssignal, das diese Veränderung direkt misst.

Das Papier definiert zwei Arten von Tests, in seinen eigenen Worten: “Verhaltenstests importieren und führen den getesteten Code zur Laufzeit aus. Sie rufen die getesteten Funktionen mit bestimmten Eingaben auf und prüfen Ausgaben oder verifizieren Ausnahmen. Strukturtests hingegen untersuchen den Quellcodetext, gleichen Muster ab und prüfen API-Oberflächen, um festzustellen, ob die gewünschten Codeänderungen vorgenommen wurden.” Die endgültige Aufteilung beträgt 42 verhaltensbasierte (17,9 %) und 192 strukturelle (82,1 %) Tests. Ein ehrlicher Satz ist angebracht: Der Großteil des Orakels besteht aus Musterabgleich im Quelltext, nicht aus der Ausführung des Codes. Diese Schieflage ist eine echte Einschränkung, die man im Hinterkopf behalten sollte.

Wie der Benchmark erstellt wurde und was der Funnel kostete

c-CRAB basiert auf dem bestehenden inclusionAI/SWE-CARE-Datensatz, der Pull-Request-Instanzen mit Commit-Metadaten liefert; der eigene Beitrag von c-CRAB ist der Orakel, nicht das PR-Korpus. Die Kuratierungspipeline durchläuft vier Filter, und jeder einzelne kostet Instanzen. Das Papier berichtet den Trichter wie folgt:

• Ursprünglicher Datensatz — 671 PRs, 1.313 Kommentare.

• Review-Filterung — 410 PRs, 595 Kommentare. Ein LLM-Klassifikator, kalibriert anhand eines Goldstandards von 100 manuell annotierten Kommentaren, behält nur objektiv überprüfbare Probleme und verwirft konversationelles oder subjektives Feedback.

• Aufbau ausführbarer Umgebungen — 410 PRs, 595 Kommentare. Ein Docker-Image pro PR, wobei die Abhängigkeitsauflösung auf einen Coding-Agenten zurückfällt, falls die Automatisierung fehlschlägt.

• Umwandlung von natürlichsprachlichen Kommentaren in Tests — 339 PRs, 481 Kommentare. Tests werden mit GPT-5.2 in einer ausführungsgesteuerten Verfeinerungsschleife mit bis zu drei Versuchen generiert; ein Test wird nur übernommen, wenn er beim ursprünglichen Code fehlschlägt und nach der Korrektur besteht.

• Validierung mit einem Coding-Agenten — 184 PRs, 234 Kommentare. Claude Code auf einem Sonnet-4.6-Backend versucht, den Code nur anhand des menschlichen Review-Kommentars zu reparieren; Instanzen, in denen der Test nicht bestanden werden kann, werden verworfen. Dies ist der endgültige Datensatz.

Etwa 27 % der ursprünglichen Pull-Requests überleben. Das ist der ehrliche Preis eines testbasierten Orakels, und es ist auch der Grund, warum der Benchmark klein und nicht riesig ist. Die überlebende Menge: 184 PR-Instanzen, 234 validierte Review-Kommentare, 1,27 Tests pro Instanz, durchschnittlich 418,1 geänderte Zeilen pro PR, 31,8 Zeilen pro Test. Zwei Annotatoren bewerteten unabhängig voneinander, ob ein generierter Test die Sorge des menschlichen Reviewers getreu erfasste – anhand von 50 Stichprobeninstanzen – und stimmten in 84 % der Fälle überein.

Eine Abweichung, die Ihnen bei genauem Lesen auffallen wird: Die Datensatztabelle listet 67 Repositorys auf, während der Abschnitt zu den Bedrohungen der Validität von “184 Pull-Request-Instanzen mit 234 verifizierbaren Orakeln in 56 Repositorys” spricht. Das Papier nennt beide Zahlen, an verschiedenen Stellen, und wir werden sie weder mitteln noch stillschweigend die bequemere auswählen. Leserinnen und Leser nutzen genau diese Art von Details, um zu beurteilen, ob ein Benchmark ihre Zeit wert ist, daher werden beide hier so wiedergegeben, wie sie veröffentlicht wurden.

Die Ergebnisse und wie man sie liest

Die Pass-Rate ist die aggregierte Test-Pass-Rate: Pro Instanz ist sie der Anteil der Tests dieses PR, die bestehen, und der ausgewiesene Wert ist der Durchschnitt über alle Instanzen. Das Paper berichtet pro Tool:

• Claude Code — 1.336 Kommentare, 7,3 pro PR — verhaltensbezogen 38,1 %, strukturell 30,7 %, insgesamt 32,1 %

• Devin — 1.344 Kommentare, 7,3 pro PR — verhaltensbezogen 31,0 %, strukturell 23,4 %, insgesamt 24,8 %

• PR-Agent — 524 Kommentare, 2,8 pro PR — verhaltensbezogen 38,1 %, strukturell 19,8 %, insgesamt 23,1 %

• Codex — 324 Kommentare, 1,8 pro PR — verhaltensbezogen 38,1 %, strukturell 16,1 %, insgesamt 20,1 %

• Mensch — 234 Kommentare, 1,3 pro PR — 100 % konstruktionsbedingt. Die Menschen haben das Orakel geschrieben, also ist diese Zeile ein Skalenmarker, kein Konkurrent.

Lesen Sie diese Zeilen sorgfältig, bevor Sie eine davon zitieren. Die „nur etwa 40 %“ aus der Zusammenfassung sind eine Vereinigungsmenge: 41,5 % der 234 Tests wurden von mindestens einem der vier Tools bestanden. Es ist nicht die Punktzahl eines einzelnen Agenten — die beste Einzelpunktzahl erreicht Claude Code mit 32,1 % — und es bedeutet nicht, dass die vier Tools zusammen 40 % der echten Defekte erfasst haben. Der folgende Abschnitt erklärt, warum.

Die interessanteste Zahl ist nicht der Gewinner. Claude Code und Devin haben jeweils mehr als 1.300 Kommentare gepostet – etwa 7,3 pro PR – und damit 32,1 % bzw. 24,8 % erreicht. Codex postete 324, etwa 1,8 pro PR, und erreichte damit 20,1 %. Die menschliche Basislinie liegt bei 1,3 Kommentaren pro PR. Rechnen Sie selbst: Ungefähr das Vierfache an Kommentarvolumen bringt weit weniger als die doppelte Bestehensquote. Volumen ist keine Abdeckung. Ein gesprächiger Reviewer ist nicht dasselbe wie ein nützlicher, und c-CRAB ist das erste Benchmark, das eingerichtet wurde, um das zu zeigen.

Die Nützlichkeit wirkt in die andere Richtung.

Die niedrigen Bestehensquoten lesen sich wie eine Verurteilung, bis man sich anschaut, was die Autoren sonst noch gemessen haben. Sie haben 92 Kommentare in 6 PRs manuell geprüft und 84% davon als nützlich bewertet (77 von 92) — PR-Agent 94%, Codex 88%, Devin 85%, Claude Code 78%. Die meisten Kommentare, die einen c-CRAB-Test nicht bestehen, sind also kein Rauschen; sie betreffen etwas, das der menschliche Reviewer nicht angesprochen hat. Die Stichprobe ist klein — 92 Kommentare, 6 PRs — und das Paper sagt das, und das sollten wir auch sagen.

Dasselbe Muster zeigt sich darin, worüber {{1}}die Gutachter sprechen. Menschliche Gutachter tendierten zu Wartbarkeit, Design und Dokumentation; die Werkzeuge tendierten zu Robustheit, Testabdeckung und Fehlerbehandlung. Das Papier deutet dies als Argument für die Zusammenarbeit zwischen Mensch und Agent anstelle einer Ersetzung{{/1}}. Es ist auch die beste verfügbare Erklärung dafür, warum die Bewertungen niedrig aussehen: Agenten und Menschen betrachten oft nicht dieselben Dinge, und das Orakel belohnt nur die Liste des Menschen.

Was c-CRAB nicht sehen kann

Der Benchmark ist sich seines blinden Flecks explizit bewusst, und wir auch. c-CRAB vergibt keine Anerkennung für ein gültiges Problem, das der menschliche Reviewer nie angesprochen hat. Das Orakel ist die menschliche Review-Absicht: Ein Agent, der einen echten Fehler findet, den niemand erwähnt hat, erhält dafür null Punkte. Das Papier formuliert es direkt — automatisierte Review-Tools mögen andere wertvolle Kommentare erzeugen, die menschliche Reviewer nicht identifiziert haben, aber “wie andere bestehende Benchmarks bewertet c-CRAB diese zusätzlichen Kommentare nicht direkt.”

Dieser eine Satz ist die Korrektur für den Großteil der Berichterstattung über dieses Ergebnis. Wer “Review-Agenten lösen nur 40%” zitiert, als ob es messe, wie viele echte Defekte die Agenten finden, missversteht die Zahl. Sie misst, wie viele von Menschen vorgebrachte Bedenken die Agenten gemeinsam beheben konnten — eine engere und viel ehrlichere Behauptung.

Selbst ausführen

Wenn Sie die Zahlen reproduzieren oder einen eigenen Gutachter hinzufügen möchten, ist das Replikationspaket öffentlich verfügbar unter c-CRAB-Benchmark/dataset. Die README ist die eigentliche Dokumentation, und sie ist ehrlich, was die Beschaffenheit der Sache angeht. Setup ist code>uv sync/code>; Sie benötigen Docker und einen code>OPENAI_API_KEY/code> oder code>ANTHROPIC_API_KEY/code>, und Claude Code liest zusätzlich Anmeldedaten aus code>~/.claude/.credentials.json/code>. Die Organisation veröffentlicht auch vorgefertigte Docker-Images für die Umgebungen.

Das Layout: code>pipeline//code> enthält die Pipeline-Logik und die Prompts, code>execution//code> die Docker-Image-Builder und Laufzeit-Helfer, code>results_preprocessed//code> die veröffentlichte Benchmark-Teilmenge (410 vorverarbeitete Instanzen), code>results_pipeline_funnel//code> die JSONL-Dateien für stage0–stage4 und die Trichter-Zusammenfassung, und code>raw_results_compressed//code> die rohen Experimentausgaben.

Die Reproduktion des vollständigen Laufs umfasst fünf Schritte: Docker-Umgebungen bauen (code>execution.build_swe_care/code>), Tests generieren (code>run_testgen_full.sh/code>), Baseline-Reviews sammeln (code>run_batch_baselines.py --tools pr-agent devin claude-code codex/code>), Agentenauflösung ausführen (code>run_batch_agent_resolution.py/code>), dann evaluieren (code>run_batch_tool_eval.py --tool <name>/code>). Wenn Sie einen fünften Reviewer hinzufügen möchten, beachten Sie, dass der Erweiterungspunkt keine Plugin-Schnittstelle ist: Die Baseline-Review-Prompts für jedes Tool befinden sich in code>run_batch_baselines.py/code>, und das README dokumentiert keinen saubereren Weg — Sie bearbeiten dieses Skript.

Noch zwei Fakten, bevor du es klonst. Das Paper ist unter CC BY 4.0 lizenziert; die Repository-Seite gibt keine Lizenz für den Code an, also nimm keine an. Und das Paper veröffentlicht keine Kosten- oder Token-Verbrauchszahlen für die Ausführung des Benchmarks — diese sind nicht veröffentlicht, also werden wir sie nicht erfinden. Was die Pipeline impliziert: ein Docker-Image pro PR über 184 Instanzen, plus ein Agent-Resolution-Durchlauf, ist kein Nachmittag im Laptop-Maßstab.

Was das für jeden bedeutet, der eine Review-Pipeline ausliefert.

Das Kernargument von c-CRAB ist, dass ein LLM-Richter ein unzuverlässiges Orakel ist. Wenn man keine ausführbaren Orakel bauen kann – und die meisten Teams können das nicht – ist die beste verfügbare Gegenmaßnahme, den Richter niemals auf dem Modell laufen zu lassen, das das Review erstellt hat. Ein Richter, der dasselbe Modell wie der Rezensent verwendet, stimmt mit sich selbst überein, und der Verifikationsdurchlauf wird zu einem Gummistempel, der trotzdem eine Zahl zurückgibt.

Genau das ist der Fehler, gegen den das Routing-Rezept hinter dem von uns ausgelieferten Reviewer schützt — und es ist eine Design-Parallele zur Kritik von c-CRAB, kein Benchmark-Ergebnis. Die Testumgebung führt ohnehin einen LLM-Judge aus, als zweiten Durchlauf, der Befunde gruppiert, jede Gruppe danach mit 0–1 bewertet, ob es sich um einen konkreten Defekt in dieser Änderung handelt, und alles unterhalb eines Schwellenwerts verwirft. Das Rezept, das dies steuert, code>recipes/orcacode-review.dsl.yaml/code>, ist eine öffentliche Datei. Die Action nennt nie ein Modell: Sie ruft einen Router-Alias auf, und das Rezept entscheidet. Wie ausgeliefert umfasst das Rezept vier Zeilen — das Standardmodell des Reviewers ist code>deepseek/deepseek-v4-flash-0731/code>, und eine Regel, die auf den Header code>x-cr-lens: judge/code> passt, sendet den Judge-Durchlauf an code>z-ai/glm-5.3/code>, einen anderen Anbieter. Das Rezept verlangt in seinem Wortlaut, dass der Judge “DAS MODELL DES STANDARDS NICHT NENNEN DARF”, denn auf dem eigenen Modell des Reviewers “stimmt es mit sich selbst überein, sodass der Durchlauf wirkungslos wird, während er weiterhin Erfolg meldet”.

Ein Judge eines anderen Anbieters reduziert die Selbstübereinstimmung; er macht aus einem LLM-Judge aber keinen Test. c-CRAB hat unseren Reviewer nicht getestet, und wir werden auch nicht das Gegenteil andeuten. OrcaCode Review führt einen Review-Durchlauf plus einen unabhängigen Verifikations-Judge aus, pro Token statt pro Arbeitsplatz, und jeder Prompt darin ist öffentlich — so kannst du es auf einen Benchmark wie diesen anwenden und deine eigene Zahl bekommen, statt unserer.

Fazit

c-CRAB ist der erste Code-Review-Benchmark, dessen Bewertung man weitgehend trauen kann: Ein Review besteht nur dann, wenn das Befolgen seiner Hinweise den Code behebt. Die Schlagzeilen-Zahlen sind wirklich niedrig — bestes einzelnes Tool 32,1 %, Vereinigungsmenge 41,5 % — aber sie messen die Überlappung mit von Menschen vorgebrachten Bedenken, nicht die Qualität der Reviews, und die Nützlichkeitsdaten zeigen, dass die meisten Kommentare echte Signale sind. Die bleibenden Erkenntnisse sind die, für die das Paper selbst argumentiert: Quantität ist keine Abdeckung, Agenten und Menschen betrachten verschiedene Dinge, und der richtige Einsatz ist die Zusammenarbeit zwischen Mensch und Agent. Und der Benchmark ist offen, also ist der ehrliche nächste Schritt, den eigenen Reviewer darauf laufen zu lassen und eine eigene Zahl zu erhalten.