Code Review Agent Benchmark: Wie man einen Reviewer bewertet und c-CRAB auf Ihrem eigenen Code ausführt

Wie erkennt man, ob ein Code-Review-Agent etwas taugt? In der kurzen Geschichte dieses Bereichs lautete die Antwort meist: „Man misst, wie nah seine Kommentare an denen eines menschlichen Reviewers sind.“ – Das klingt vernünftig, bis man es tatsächlich ausprobiert, denn zwei Reviewer können dasselbe Problem mit völlig anderen Worten ansprechen. Das Code Review Agent Benchmark – das Papier ist arXiv:2603.23448, sein Datensatz heißt c-CRAB – ist der erste ernsthafte Versuch, ein Review danach zu bewerten, was das Befolgen seiner Hinweise bewirkt, statt nach seiner Formulierung. Es wurden 234 menschliche Review-Kommentare in ausführbare Tests umgewandelt und vier weit verbreitete Reviewer darauf losgelassen – PR-Agent, Devin, Claude Code und Codex – mit dem Ergebnis, dass alle vier zusammen 41,5 % dieser Tests bestehen, „nur rund 40 %“ in den Worten des Papiers. Diese Seite ist ein Leitfaden: wie man dieses Ergebnis liest, ohne es zu verfälschen, wie man c-CRAB selbst ausführt und was man tut, wenn die eigene Codebasis überhaupt nicht im Benchmark vorkommt.

Die Schlagzeilenzahl ist die am wenigsten nützliche Sache auf dieser Seite. Das Nützliche sind die Methode und die Fehlermodi: warum jedes frühere Bewertungsschema die falsche Sache maß, was es kostet, eine Review stattdessen mit ausführbaren Tests zu bewerten, und warum „Review-Agenten finden nur 40 % der Bugs“ eine dreifache Fehllesung des tatsächlichen Ergebnisses ist. Alles hier ist eine gemeinschaftliche Auswertung des veröffentlichten Benchmarks und der Erfahrungen von Anwendern, die ihn ausgeführt haben — keine Herstelleranleitung der beteiligten Tool-Anbieter.

Warum die offensichtlichen Metriken nicht funktionieren

Vor c-CRAB fielen Bewertungen von Code-Review-Agenten in eine kleine Anzahl von Familien, und die eigene Vergleichstabelle des Papers (Tabelle 1) legt die Abstammung dar. Die älteste ist Textüberlappung – BLEU, ROUGE, chrF und Verwandte, verwendet von Benchmarks wie CodeReviewer und ContextCRBench. Die Idee ist, dass der Kommentar eines Agenten gut ist, wenn seine n-Gramme mit denen eines Menschen übereinstimmen. Die Idee scheitert an der einen Art von Fall, die überall im Code-Review vorkommt: derselbe Defekt, beschrieben mit anderen Worten.

Die Fallstudie des Papers ist das klarste Beispiel. In einem Pull-Request in python-telegram-bot (PR #3514) haben der menschliche Reviewer und Codex beide denselben Robustheitsfehler bei der verschachtelten Indizierung erkannt. Codex' Review war verhaltensmäßig korrekt – ein Coding-Agent, der darauf reagierte, erzeugte einen Fix, der den ausführbaren Test bestand. Doch die Textmetriken bewerteten es mit BLEU-4 0,00, ROUGE-L 7,02, chrF 20,74 und Embedding-Ähnlichkeit 54,59. Null n-Gramm-Überlappung, und das Review war richtig. Gleiche Sorge, andere Worte: Die String-Metriken konnten es nicht sehen. Die Embedding-Ähnlichkeit ist ein teilweiser Fortschritt – 54,59 bei einem bestätigten Bestehen ist immer noch weit von einer brauchbaren Schwelle entfernt – und sie erbt dasselbe Problem in abgeschwächter Form.

LLM-as-judge, bei dem ein Modell die Bewertung des Agenten mit der des Menschen vergleicht und abstimmt, behebt das Vokabularproblem, führt aber drei neue ein, die das Papier direkt benennt: Bias, Instabilität und Empfindlichkeit gegenüber dem Prompt-Design. Führt man denselben Vergleich zweimal durch, kann ein Richter unterschiedliche Urteile fällen; formuliert man den Bewertungs-Prompt um, verschieben sich die Rankings. Wenn man zwischen zwei Reviewern wählt, die im selben Benchmark drei Punkte auseinanderliegen, kann ein Richter mit dieser Varianz keine Entscheidung stützen – und eine Bewertung, die man nicht reproduzieren kann, ist keine Bewertung.

Was ein ausführbares Orakel bringt — und was es kostet

Die Idee, auf der c-CRAB aufbaut, ist zugleich einfach und radikal: Statt zu fragen: „Klingt das Review wie das eines Menschen?“, fragt man: „Wenn man dem Review folgt, wird der Code dann korrigiert?“ Jeder übernommene menschliche Review-Kommentar wird in einen ausführbaren Test umgewandelt, der das zugrunde liegende Problem erfasst. Ein Review-Kommentar gilt als korrekt, wenn das Befolgen einen verhaltenskorrekten Fix erzeugt, der den Test bestehen lässt — und jede Instanz wird mit einer ausführbaren Docker-Umgebung ausgeliefert, sodass „den Test bestehen lassen“ eine Tatsache und kein Urteil ist.

Das Papier definiert zwei Arten von Tests. Verhaltenstests „importieren und führen den getesteten Code zur Laufzeit aus", rufen Funktionen „mit spezifischen Eingaben" auf und prüfen „Ausgaben oder verifizieren Ausnahmen". Strukturtests „inspizieren 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 ist 42 verhaltensbezogene (17,9 %) und 192 strukturelle (82,1 %) – und diese Schieflage verdient einen ehrlichen Satz: Der Großteil dieses Orakels ist Musterabgleich auf Quelltext, nicht das Ausführen des Codes. Der Goldstandard ist der Verhaltenstest; der Großteil des Datensatzes ist die pragmatische Version davon.

Der Bau des Orakels ist ein vierstufiger Trichter, und jede Stufe verwirft Dinge:

• Ausgangsdatensatz — 671 PRs, 1.313 Review-Kommentare.

• Review-Filterung — 410 PRs, 595 Kommentare. Ein LLM-Klassifikator, kalibriert gegen einen Goldstandard von 100 manuell annotierten Kommentaren, behält nur objektiv verifizierbare 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ückgreift, wenn die Automatisierung fehlschlägt.

• Umwandlung von NL-Kommentaren in Tests — 339 PRs, 481 Kommentare. Generiert mit GPT-5.2 unter einer ausführungsgesteuerten Verfeinerungsschleife (bis zu drei Versuche); ein Test wird nur beibehalten, wenn er auf der Vorher-Version fehlschlägt und auf der Nachher-Version besteht.

• Validierung mit einem Coding-Agenten — 184 PRs, 234 Kommentare (endgültig). Claude Code auf einem Sonnet-4.6-Backend versucht, den Code ausschließlich anhand des menschlichen Review-Kommentars zu korrigieren; Fälle, in denen es den Test nicht bestehen kann, werden verworfen.

Etwa 27 % der ursprünglichen Pull Requests überleben. Sagen wir es deutlich, denn das ist der ehrliche Preis eines testbasierten Orakels: Wenn ein Kommentar nicht konkret genug ist, um zu einem fehlschlagenden Test zu werden, oder die Umgebung nicht gebaut werden kann, oder ein kompetenter Code-Agent den Code anhand des Kommentars allein nicht korrigieren kann, wird die Instanz verworfen. Das ist auch der Grund, warum der Benchmark klein ist. 184 PR-Instanzen und 234 validierte Kommentare sind ein Datensatz, den man lesen kann, kein Korpus, in dem man ertrinken kann – und für ein Orakel, das echte Docker-Umgebungen ausführen muss, ist Kleinheit ein Feature.

Zur Einordnung: Eine durchschnittliche Instanz betrifft 418,1 geänderte Zeilen, Tests durchschnittlich 31,8 Zeilen, und es gibt 1,27 Tests pro Instanz. Zwei Annotatoren stimmten in 84 % der Fälle überein — bei über 50 Stichproben-Instanzen — ob ein generierter Test das Anliegen des menschlichen Reviewers getreu erfasst.

Eine bibliografische Warze, auf die du stoßen wirst, wenn du das Paper selbst liest: Die Datensatztabelle (Tabelle 4) listet 67 Repositorys auf, während der Abschnitt „Threats to Validity“ von „184 Pull-Request-Instanzen mit 234 verifizierbaren Orakeln über 56 Repositorys“ spricht. Das Paper nennt beide Zahlen an verschiedenen Stellen und gleicht sie nicht ab. Bevorzuge keine der beiden und bilde keinen Durchschnitt – zitiere jede dort, wo sie erscheint. Diskrepanzen wie diese sind genau das Detail, anhand dessen Leser entscheiden, ob ein Benchmark ihre Zeit wert ist.

Zur Sorgfaltsprüfung der Unabhängigkeit: Das Paper legt offen, dass einer der Autoren mit SonarSource verbunden ist, und stellt fest, dass die Ergebnisse nicht als „an evaluation of the quality of products at SonarSource“ interpretiert werden sollten. Das ist ihr Haftungsausschluss, wörtlich zitiert statt paraphrasiert.

Wie man eine Partitur auf c-CRAB liest, ohne sie falsch zu zitieren

Die wichtigste Kennzahl ist die Bestehensquote: pro Instanz der Anteil der Tests des jeweiligen PR, die bestanden werden, gemittelt über die 184 Instanzen. Hier ist die vollständige Ergebnistabelle aus dem Papier, eine Zeile pro Gutachter. Die menschliche Zeile ist eher ein Skalenmarker als ein Wettbewerber – die Menschen haben das Orakel geschrieben, also erzielen sie konstruktionsbedingt 100 %:

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

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

• {{1}}PR-Agent{{/1}} — {{2}}524 Kommentare{{/2}}, {{3}}2,8 pro PR{{/3}}, {{4}}insgesamt 23,1 %{{/4}} {{5}}(verhaltensbedingt 38,1 %, strukturell 19,8 %){{/5}}.

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

• Mensch — 234 Kommentare, 1,3 pro PR, 100 % konstruktionsbedingt.

Drei Korrekturen, denn die „nur etwa 40 %“ aus dem Abstract sind derzeit die am häufigsten falsch zitierte Zahl in dieser Ecke der KI-Programmierer-Diskussion. Erstens: Die 41,5-%-Angabe – 97 der 234 Tests wurden von mindestens einem Tool bestanden – ist eine Vereinigungsmenge über alle vier Prüfer: Ein Test zählt einmal, wenn irgendein Agent ihn bestanden hat. Kein einzelner Agent erreichte 41,5 %; die beste Einzelwertung ist Claude Code mit 32,1 %. Zweitens: Die menschliche Zeile ist das Orakel, nicht ein Teilnehmer; sie als „Menschen schlagen die Bots“ zu wiederholen, ist ein Kategorienfehler. Drittens und am wichtigsten: c-CRAB gibt keine Anerkennung für ein gültiges Problem, das der menschliche Prüfer nie aufgeworfen hat. Das Orakel ist die menschliche Prüfabsicht. Ein Agent, der einen echten Bug findet, den niemand erwähnt hat, erhält dafür null Punkte. Also ist „KI-Prüfagenten erkennen nur 40 % der Bugs“ gleich dreifach falsch – es ist eine Vereinigungsmenge, es ist keine Fehlererkennungsrate, und es misst die Übereinstimmung mit menschlichen Prüfern, nicht die Gesamtkorrektheit.

Kommentarvolumen ist die Falle.

Die interessanteste Zahl in den Ergebnissen ist nicht der Gewinner. Claude Code und Devin haben jeweils mehr als 1.300 Kommentare verfasst – etwa 7,3 pro PR – und damit 32,1 % bzw. 24,8 % erreicht. Codex veröffentlichte 324 Kommentare, etwa 1,8 pro PR, und erzielte 20,1 %. Die menschliche Basislinie liegt bei 1,3 Kommentaren pro PR. Volumen ist keine Abdeckung: Ungefähr fünfmal so viele Kommentare bringen deutlich weniger als die doppelte Erfolgsquote. Wenn Sie einen Reviewer auswählen, sind die tatsächlichen Kosten all dieser zusätzlichen Kommentare die Ermüdung bei der menschlichen Durchsicht – jeder Kommentar, den ein Agent verfasst, ist eine Entscheidung, die eine Person priorisieren muss.

Der Befund zur Nützlichkeit weist in die andere Richtung – und genau das verhindert, dass dies eine billige „die Bots sind laut“-Geschichte ist. Die Autoren haben 92 Kommentare in 6 PRs von Hand geprüft und 84 % (77/92) als nützlich bewertet – PR-Agent 94 %, Codex 88 %, Devin 85 %, Claude Code 78 %. Die meisten Kommentare, die den 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 –, was man im selben Atemzug wie die Prozentzahlen nennen sollte.

Worüber die beiden Seiten tatsächlich sprechen, erklärt die Form der Ergebnisse. Menschliche Prüfer tendierten zu Wartbarkeit, Design und Dokumentation; die Tools tendierten zu Robustheit, Testen und Fehlerbehandlung. Das Papier liest dies als Argument für die Zusammenarbeit von Mensch und Agent statt für deren Ersetzung – und es ist zugleich die beste verfügbare Erklärung dafür, warum die Bewertungen so niedrig erscheinen. Ein Prüfer, der bei Randfällen scharfsinnig ist, aber beim Design schweigt, wird systematisch die Kategorien übersehen, die Menschen markieren, und das Orakel ist vollständig aus menschlichen Markierungen aufgebaut.

Praktiker, die das durchgearbeitet haben, kommen zu demselben Ergebnis. Ein ausführlicher Bericht von Daniel Vaughan, der die Arbeit CR-bench nennt, zieht dieselbe Schlussfolgerung und macht daraus einen Workflow: Man lässt den Agenten den Robustheits- und Korrektheits-Check durchführen, behält Menschen für Design, Konventionen und Architektur – die Kategorien, in denen Agenten am schlechtesten abschneiden – und steuert den Agenten mit Review-Anweisungen, die die schwachen Kategorien benennen. Sein nützlichster Hinweis für alle, die das Leaderboard lesen: „Nützlichkeit ist nicht dasselbe wie Bestehensquote“, weil die Testsuite Übereinstimmung mit der vom Menschen beabsichtigten Korrektur verlangt und eine gültige alternative Korrektur durch den Test fällt. Der Weg von 20 % zu einer deutlich höheren Punktzahl ist seiner Lesart nach kein Modell-Upgrade, sondern Konfigurationsarbeit.

c-CRAB selbst ausführen

Alles oben Genannte besteht darin, die Ergebnisse anderer zu lesen. Das Replikationspaket macht den Benchmark ausführbar — es befindet sich unter c-CRAB-Benchmark/dataset auf GitHub — und die README sagt ehrlich, was dafür nötig ist.

Voraussetzungen: code>uv sync/code>; Docker; und entweder code>OPENAI_API_KEY/code> oder code>ANTHROPIC_API_KEY/code> (Claude Code liest zusätzlich Anmeldedaten aus code>~/.claude/.credentials.json/code>, die standardmäßig in Container eingebunden sind). Das Layout besteht aus fünf Verzeichnissen: code>pipeline//code> (Pipeline-Logik und Prompts), code>execution//code> (Builder für Docker-Images und Laufzeit-Hilfsprogramme), code>results_preprocessed//code> (die veröffentlichte Benchmark-Teilmenge), code>results_pipeline_funnel//code> (die Stage0–Stage4-JSONL-Dateien und die Funnel-Zusammenfassung), und code>raw_results_compressed//code> (die rohen Ausgaben der Experimente). Die fünf Schritte in der richtigen Reihenfolge:

1. Erstellen Sie die Docker-Umgebungen — code>uv run python -m execution.build_swe_care --split test --instance results_preprocessed/instance-ids.txt --max-workers 4/code>. Vorgefertigte Images sind auch unter der c-CRAB-Benchmark GitHub Packages-Org veröffentlicht, falls Sie den Build lieber überspringen möchten.

2. Generieren Sie die Tests — code>./run_testgen_full.sh --instances-file results_preprocessed/instance-ids.txt --workers 4 --output-dir results_testgen/code>.

3. Baseline-Reviews erfassen — code>uv run python run_batch_baselines.py --split test --instances-file results_preprocessed/instance-ids.txt --tools pr-agent devin claude-code codex --output-dir baselines_output --workers 4/code>. Konfigurieren Sie vor diesem Schritt die entsprechenden Zugangsdaten für die externen Tools.

Führen Sie die Agentenauflösung aus — code>uv run python run_batch_agent_resolution.py --stage3-file results_pipeline_funnel/stage3_testgen_verified.jsonl --testgen-dir results_testgen --output-dir results_agent_resolution --workers 4/code>.

5. Evaluieren — einmal pro Tool wiederholen: code>uv run python run_batch_tool_eval.py --tool pr-agent --stage3-file results_pipeline_funnel/stage3_testgen_verified.jsonl --testgen-dir results_testgen --tool-results-dir baselines_output --output-dir results_eval_pr-agent --workers 4/code>.

Zwei Dinge, die die README nicht preisgibt. Einen fünften Gutachter hinzuzufügen bedeutet das Bearbeiten von code>run_batch_baselines.py/code>

Kosten sind der andere nicht beworbene Punkt. Das Paper veröffentlicht keine Token- oder Dollarzahlen für den Betrieb der Pipeline, also behandeln Sie jede Kostenzahl, die Sie online zitiert sehen, als unbestätigt. Was die Struktur impliziert, ist klar genug: ein Docker-Image pro PR über 184 Instanzen, plus ein Coding-Agent-Auflösungsdurchgang und ein Evaluierungsdurchgang pro Tool. Das ist kein Nachmittag auf Laptop-Ebene – planen Sie echte Rechenleistung ein.

Wenn Sie sich keine ausführbaren Orakel leisten können

Die ehrliche Position der meisten Teams ist: Der Benchmark hat recht, dass ein LLM-Judge keine Bewertungen abgeben kann, aber die Entwicklung eines testbasierten Orakels für die eigenen PRs ist ein großer Aufwand. Die Unterscheidung, die sich lohnt, ist zwischen einem LLM-Judge als Bewerter und einem LLM-Judge als Filter. Die Ablehnung des Judges als Orakel durch c-CRAB macht einen Judge nicht nutzlos innerhalb eines Reviewers – ein Judge, der doppelte Befunde bündelt und schwache verwirft, kann die Präzision dennoch erhöhen. Der Fehlermodus, gegen den man entwerfen muss, ist Unabhängigkeit.

Ein Judge, der auf dem eigenen Modell des Reviewers läuft, stimmt mit sich selbst überein: Er liest das Review, findet es plausibel und meldet Erfolg, ohne etwas zu ändern. Ein Judge eines anderen Anbieters reduziert diese Selbstübereinstimmung — er macht aus einem Judge zwar keinen Test, aber er beendet das Abnicken. Wir können Ihnen ein konkretes, überprüfbares Beispiel genau für diesen Schutzmechanismus zeigen, weil unsere eigene Testumgebung offen ist: Orca-Code-Review auf GitHub ist MIT-lizenziert, und sein Routing-Rezept formuliert die Regel in den eigenen Worten des Repos — der Judge „DARF DAS MODELL DES DEFAULTS NICHT NENNEN", weil „auf dem eigenen Modell des Reviewers stimmt es mit sich selbst überein, also wird der Pass wirkungslos, während er weiterhin Erfolg meldet." Die Action nennt nie ein Modell; das Rezept entscheidet. In der bereitgestellten Konfiguration ist der Standard-Reviewer deepseek/deepseek-v4-flash-0731, und eine Regel, die auf den code>x-cr-lens: judge/code>-Header zutrifft, sendet den Judge-Pass an z-ai/glm-5.3 — einen anderen Anbieter. Das ist eine Entwurfs-Parallele zum Argument von c-CRAB, kein Ergebnis: Wir sind nicht Teil der Benchmark, und es gibt keinen c-CRAB-Score für unseren Reviewer. Aber es ist die praktische Gegenmaßnahme, die jedem zur Verfügung steht, der keine ausführbaren Orakel bauen kann, und sie ist günstig, wenn Judge und Reviewer bei verschiedenen Anbietern hinter einem einzigen Schlüssel leben können — genau dafür ist ein Router da. Bei OrcaRouter sind der Reviewer und sein Judge zwei Zeilen in einem Routing-DSL, und Sie zahlen den Listenpreis des Anbieters ohne jeden Aufschlag.

Wenn dein Code nicht im Benchmark enthalten ist

184 PRs in 56 oder 67 öffentlichen Repositories sind nicht deine Codebasis und werden es auch nie sein. Der übertragbare Teil ist die Methode, und du kannst sie in viel kleinerem Maßstab auf deiner eigenen Historie ausführen. Nimm gemergte PRs, zu denen es menschliche Review-Kommentare gab. Schreibe für eine Stichprobe dieser Kommentare einen Test, der fehlschlägt, bevor die Review-Anmerkungen umgesetzt wurden, und danach besteht – genau diese Eigenschaft, erst Fehlschlag, dann Bestehen, ist das A und O. Führe deinen Kandidaten-Reviewer auf dem Diff vor dem Review aus. Überprüfe dann, ob das Umsetzen seiner Kommentare den Test bestehen lässt. Was du bekommst, ist eine Zahl, die anhand des tatsächlich ausgelieferten Codes berechnet wird, und die ist mehr wert als ein Platz auf der Bestenliste. Was es kostet, ist genau die Wand, an die das Paper gestoßen ist: Du brauchst reproduzierbare Umgebungen für jeden einzelnen PR, denn ein Test, der nur auf deinem Laptop besteht, ist kein Orakel.

Sie brauchen keine 234 Tests. Ein gutes Dutzend gezielt ausgewählter PRs, über die Ihr Team tatsächlich gestritten hat, verrät Ihnen mehr über Ihren Reviewer als ein Benchmark-Wert. Und eine parallele Praktiker-Analyse dieser Benchmark-Familie ist unverblümt, was das Tor betrifft: Die Präzision des LLM-Klassifikators dabei, ob ein Kommentar ein gültiges, überprüfbares Problem ist, liegt zwischen 66 % und 85 % – behandeln Sie maschinelle Filter also als Kurzliste und behalten Sie einen menschlichen Entscheidungsschritt bei, bevor irgendetwas zu einem Test wird. Derselbe Bericht merkt an, dass LangChains ReviewBench, unabhängig auf derselben Kommentar-zu-Test-Idee aufgebaut, bestenfalls etwa 30 % seiner Basisprobleme wiederfindet – in derselben Größenordnung wie c-CRABs 20–32 %, und eine Erinnerung daran, dass einstellige Leaderboard-Differenzen zwischen Tools oft kleiner sind als das Rauschen im eigenen Setup.

Wenn Sie sich überhaupt überlegen, welches Review-Tool Sie kaufen sollen, ist das eine andere Frage – unser Kaufratgeber für Code-Review-Agenten behandelt Bot vs. Agent, Preise pro Sitzplatz vs. pro Token und wann sich Selbsthosting lohnt – und sobald Sie eines haben, werden die laufenden Kosten einer Review-Umgebung bei jedem Push in unserem Erklärartikel zu automatisierten Code-Reviews behandelt. Diese Seite befasst sich ausschließlich mit der Messung, und der Begleitartikel zu dieser erläutert die Anatomie des Benchmarks: den Konstruktionstrichter, die Datensatzstatistiken und die vollständige Ergebnistabelle.

FAQ

Ist 41,5 % die beste Punktzahl des Agenten? Nein. 41,5 % ist die Vereinigungsmenge aller vier Tools — ein Test zählt einmal, wenn eines davon ihn bestanden hat. Die beste Einzelpunktzahl erzielt Claude Code mit 32,1 %.

Misst c-CRAB, wie viele Fehler ein Prüfer findet? Nein. Es misst, wie gut eine Überprüfung mit dem übereinstimmt, was ein menschlicher Prüfer angemerkt hat, umgewandelt in ausführbare Tests. Ein echter Fehler, den der Mensch nie erwähnt hat, wird mit null bewertet, egal wie berechtigt er ist.

Haben die menschlichen Prüfer die Bots "geschlagen"? Die 100% menschliche Zeile ist das Orakel selbst — die Menschen haben die Tests geschrieben — also ist sie ein Maßstabsmarker, kein Konkurrent.

Ist c-CRAB dasselbe wie CR-bench?Ja. Der Datensatz ist c-CRAB; einige Berichte Dritter nennen ihn CR-bench, aber es gibt hier nur einen Benchmark.

Was kostet es, das auszuführen? Das Paper veröffentlicht keine Kostenzahlen. Ein Docker-Image pro PR auf 184 Instanzen, plus ein Durchlauf zur Agentenauflösung, bedeutet echte Rechenleistung — kein Nachmittag am Laptop.

Fazit

Der Beitrag von c-CRAB ist nicht die Bestenliste — es ist der Nachweis, dass eine Review bewertet werden kann, indem man ihre Empfehlungen ausführt, und dass die zuvor verwendeten Textähnlichkeits- und LLM-Judge-Schemata das Falsche bewertet haben. Wenn man eine Sache mitnimmt, dann die dreiteilige Korrektur: 41,5 % ist eine Vereinigungsmenge, die menschliche Zeile ist das Orakel, und die Benchmark gibt keinerlei Anerkennung für Mängel, die Menschen nie angesprochen haben. Und wenn man eine Zahl möchte, mit der man arbeiten kann: Die Methode ist übertragbar — Fehlschlag-dann-Erfolg-Tests auf den eigenen gemergten PRs, ein menschlicher Beurteilungsschritt und, falls man keine ausführbaren Orakel bauen kann, zumindest ein Judge, dessen Modell unabhängig von dem des Reviewers ist.

Wenn Sie einen Reviewer lieber messen, als über einen zu diskutieren, beginnen Sie mit einem Harness, den Sie lesen können. OrcaCode Review führt einen Review-Durchlauf plus einen unabhängigen Verifikations-Judge aus, pro Token statt pro Sitzplatz, und jeder Prompt darin ist öffentlich — so können Sie es auf ein Benchmark wie dieses ausrichten und Ihre eigene Zahl statt unserer erhalten.