c-CRAB, benchmarken för kodgranskningsagenter: Vad den mäter, vad den fann och vad 41,5 % egentligen betyder

En kodgranskningsagent och en mänsklig granskare tittade på samma pull request och tog upp samma oro. Att agera på agentens kommentar åtgärdar buggen; testet passerar. Och varje textlikhetsmått som författarna beräknade visade att agentens granskning i princip var orelaterad till den mänskliga granskningen: BLEU-4 0.00, ROUGE-L 7.02, chrF 20.74, embedding-likhet 54.59. Samma oro, andra ord, och det vanliga sättet att poängsätta en granskning kunde inte se att de var överens. Det enda exemplet är argumentet bakom c-CRAB (uttalas ”see-crab”), Code Review Agent Benchmark publicerad som arXiv:2603.23448.

c-CRAB utvärderar kodgranskningsagenter, inte kodskrivande agenter. Givet en pull request — som kan komma från en människa eller från en kodagent — producerar en granskningsagent en granskning, och c-CRAB poängsätter den granskningen utifrån huruvida att agera på den leder till en beteendemässigt korrekt korrigering. Benchmarken byggdes av programvaruteknikforskarna Yuntong Zhang, Zhiyuan Pan, Imam Nur Bani Yusuf, Haifeng Ruan, Ridwan Shariffdeen och Abhik Roychoudhury, och den utvärderar fyra verktyg: PR-Agent, Devin, Claude Code och Codex. En av författarna är knuten till SonarSource, och artiklen är tydlig med vad det innebär och inte innebär, med sina egna ord: “De åsikter och slutsatser som uttrycks i denna artikel är författarnas egna och representerar inte SonarSources officiella policy eller rekommendationer. Vidare är de resultat som presenteras här oberoende och bör inte tolkas som en utvärdering av kvaliteten på produkter från SonarSource.”

Två anmärkningar innan vi går in på detaljerna. Vissa tredjepartsartiklar kallar samma arbete “CR-bench”; det är samma benchmark, och den här sidan använder c-CRAB genomgående. Varje siffra nedan är artikelns eget rapporterade resultat, hämtat idag från artikeln och replikeringspaketet — inte oberoende omkört — och tolkningen är vår, tillsammans med den praktikerdiskussion som artikeln redan har gett upphov till. Inget av det är vägledning från leverantörerna vars verktyg utvärderades. Och om du fortfarande funderar på om du överhuvudtaget ska köra en code-review-agent, är vår köpguide om code-review-agenter en bättre utgångspunkt; den här sidan handlar om hur dessa agenter mäts.

Varför c-CRAB poängsätter recensioner med tester, inte en LLM-domare

Det vanliga sättet att betygsätta en kodgranskningsagent är att jämföra dess granskning med en människas, med en LLM-as-judge eller ett textlikhetsmått. c-CRAB:s författare avfärdar båda. LLM-as-judge, menar de, lider av partiskhet, instabilitet och promptkänslighet, vilket gör reproducerbar och konsekvent poängsättning svår. Och fallstudien ovan visar vad strängmått faktiskt mäter: formulering, inte effektivitet. På den python-telegram-bot-pull requesten sa Codex-granskningen samma sak som människan, och BLEU-4 och ROUGE-L kunde inte känna igen det.

Så c-CRAB gör tvärtom. Varje mänsklig granskningskommentar omvandlas till ett körbart test som fångar det underliggande problemet. En granskningskommentar räknas som korrekt om att agera på den ger en beteendemässigt korrekt korrigering — en som får testet att gå igenom. Varje instans levereras med en körbar Docker-miljö, så beslutet om godkänn/underkänn fattas genom att köra kod, inte genom att fråga en annan modell hur lika två texter är. Det är därför det spelar roll: en gransknings uppgift är att ändra vad en utvecklare gör, och ett test är den enda poängsättningssignal som mäter den förändringen direkt.

Artikeln definierar två typer av tester, med sina egna ord: “Beteendetester importerar och exekverar den testade koden vid körning. De anropar de testade funktionerna med specifika indata och kontrollerar utdata eller verifierar undantag. Å andra sidan inspekterar strukturella tester källkodstexten, matchar mönster och kontrollerar API-ytor för att avgöra om önskade kodändringar har gjorts.” Den slutliga uppdelningen är 42 beteendetester (17,9 %) och 192 strukturella (82,1 %). Det är värt en ärlig mening: större delen av oraklet är mönstermatchning på källtext, inte exekvering av koden. Den snedfördelningen är en verklig begränsning att ha i åtanke.

Hur benchmarken byggdes, och vad tratten kostade.

c-CRAB är byggt ovanpå det befintliga inclusionAI/SWE-CARE-datasetet, som tillhandahåller pull-request-instanser med commit-metadata; c-CRAB:s eget bidrag är oraklet, inte PR-korpusen. Kureringspipelinen kör fyra filter, och varje filter kostar instanser. Artikeln rapporterar tratten enligt följande:

• Initialt dataset — 671 PRs, 1 313 kommentarer.

• Granskningsfiltrering — 410 PR:ar, 595 kommentarer. En LLM-klassificerare, kalibrerad mot ett guldset med 100 manuellt annoterade kommentarer, behåller endast objektivt verifierbara problem och filtrerar bort konversations- eller subjektiv feedback.

• Konstruktion av körbar miljö — 410 PR:er, 595 kommentarer. En Docker-avbildning per PR, med beroendelösning som faller tillbaka på en kodningsagent när automatiseringen misslyckas.

• Konvertering av kommentarer i naturligt språk till tester — 339 PR:ar, 481 kommentarer. Tester genereras med GPT-5.2 i en exekveringsstyrd förfiningsloop på upp till tre försök; ett test behålls endast om det misslyckas på originalkoden och godkänns efter fixen.

• Validering med en kodningsagent — 184 PR:er, 234 kommentarer. Claude Code på en Sonnet-4.6-backend försöker åtgärda koden utifrån enbart den mänskliga granskningskommentaren; fall där den inte kan få testet att passera kasseras. Detta är den slutgiltiga uppsättningen.

Ungefär 27 % av de ursprungliga pull requests överlever. Det är det ärliga priset för ett testbaserat orakel, och det är också anledningen till att benchmarken är liten snarare än utbredd. Den överlevande uppsättningen: 184 PR-instanser, 234 validerade granskningskommentarer, 1,27 tester per instans, 418,1 modifierade rader per PR i genomsnitt, 31,8 rader per test. Två annotatorer bedömde oberoende av varandra, på 50 samplade instanser, huruvida ett genererat test troget fångade den mänskliga granskarens invändning, och var överens i 84 % av fallen.

En avvikelse du kommer att märka om du läser noga: dataset-tabellen listar 67 repositories, medan avsnittet om hot mot validiteten säger “184 pull request-instanser med 234 verifierbara orakel över 56 repositories.” Artikeln anger båda siffrorna, på olika ställen, och vi tänker inte räkna ut medelvärdet eller tyst välja den bekväma. Läsare använder just den här typen av detaljer för att bedöma om en benchmark är värd deras tid, så båda återges här som publicerade.

Resultaten, och hur man läser dem

Godkännandefrekvensen är den sammanlagda testgodkännandefrekvensen: per instans är det andelen av den PR:ns tester som godkänns, och huvudsiffran är genomsnittet över instanserna. Artikeln rapporterar, per verktyg:

• Claude Code — 1 336 kommentarer, 7,3 per PR — beteendemässiga 38,1 %, strukturella 30,7 %, totalt 32,1 %

• Devin — 1 344 kommentarer, 7,3 per PR — beteendemässigt 31,0 %, strukturellt 23,4 %, totalt 24,8 %

• PR-Agent — 524 kommentarer, 2.8 per PR — beteendemässig 38.1%, strukturell 19.8%, totalt 23.1%

• Codex — 324 kommentarer, 1.8 per PR — beteendemässig 38.1%, strukturell 16.1%, total 20.1%

• Människa — 234 kommentarer, 1,3 per PR — 100 % per konstruktion. Människorna skrev oraklet, så denna rad är en skalmarkör, inte en konkurrent.

Läs de raderna noggrant innan du citerar någon av dem. “bara cirka 40 %” från abstraktet är en union: 41,5 % av de 234 testerna klarades av minst ett av de fyra verktygen. Det är inte någon enskild agents poäng — det bästa enskilda resultatet är Claude Codes 32,1 % — och det betyder inte att de fyra verktygen tillsammans fångade 40 % av de verkliga defekterna. Avsnittet nedan förklarar varför.

Det mest intressanta numret är inte vinnaren. Claude Code och Devin postade vardera över 1 300 kommentarer — ungefär 7,3 per PR — för att nå 32,1 % och 24,8 %. Codex postade 324, ungefär 1,8 per PR, för att nå 20,1 %. Den mänskliga baslinjen är 1,3 kommentarer per PR. Gör matematiken: ungefär fyra gånger så stor kommentarsvolym ger långt under dubbla godkännandegraden. Volym är inte täckning. En pratglad granskare är inte samma sak som en användbar sådan, och c-CRAB är det första riktmärket som är utformat för att visa det.

Användbarheten talar för motsatsen.

De låga godkännandefrekvenserna framstår som en fällande dom tills man ser vad författarna också mätte. De granskade manuellt 92 kommentarer från 6 PR:er och bedömde att 84 % av dem var användbara (77 av 92) – PR-Agent 94 %, Codex 88 %, Devin 85 %, Claude Code 78 %. Så de flesta kommentarer som inte klarar ett c-CRAB-test är inte brus; de rör något som den mänskliga granskaren inte tog upp. Urvalet är litet – 92 kommentarer, 6 PR:er – och det påpekar studien, och det bör vi också göra.

Samma mönster återkommer i det som granskarna talar om. Mänskliga granskare lutade åt underhållbarhet, design och dokumentation; verktygen lutade åt robusthet, testning och felhantering. Artikeln tolkar detta som ett argument för samarbete mellan människa och agent snarare än ersättning. Det är också den bästa tillgängliga förklaringen till varför poängen ser låga ut: agenter och människor tittar ofta inte på samma saker, och oraklet belönar bara människans lista.

Det c-CRAB inte kan se

Benchmarken är tydlig med sin blinda fläck, och det är vi också. c-CRAB ger ingen poäng för ett giltigt problem som den mänskliga granskaren aldrig tog upp. Oraklet är mänsklig granskningsavsikt: en agent som hittar en riktig bugg som ingen nämnde får noll poäng för det. Artikeln uttrycker det direkt — automatiserade granskningsverktyg kan generera andra värdefulla kommentarer som mänskliga granskare inte identifierade, men “liksom andra befintliga benchmarks utvärderar c-CRAB inte direkt dessa ytterligare kommentarer.”

Den enda meningen är korrigeringen av det mesta av bevakningen av detta resultat. Den som citerar “granskande agenter löser bara 40 %”, som om det mätte hur många verkliga defekter agenterna fångar, misläser siffran. Den mäter hur många problem som påtalats av människor och som agenterna tillsammans lyckades lösa — ett snävare och mycket ärligare påstående.

Att köra det själv

Om du vill återskapa siffrorna eller lägga till en egen granskare, är replikeringspaketet offentligt på c-CRAB-Benchmark/dataset. README är den faktiska dokumentationen, och den är ärlig om hur det hela är utformat. Installationen är code>uv sync/code>; du behöver Docker och en code>OPENAI_API_KEY/code> eller code>ANTHROPIC_API_KEY/code>, och Claude Code läser dessutom inloggningsuppgifter från code>~/.claude/.credentials.json/code>. Organisationen publicerar också färdigbyggda Docker-avbildningar för miljöerna.

Layouten: code>pipeline//code> innehåller pipeline-logiken och promptarna, code>execution//code> Docker-imagebyggarna och runtime-hjälpfunktionerna, code>results_preprocessed//code> den publicerade benchmark-delmängden (410 förbehandlade instanser), code>results_pipeline_funnel//code> stage0–stage4 JSONL-filerna och funnel-sammanfattningen, och code>raw_results_compressed//code> de råa experimentutdata.

Att återskapa hela körningen består av fem steg: bygg Docker-miljöerna (code>execution.build_swe_care/code>), generera testerna (code>run_testgen_full.sh/code>), samla in baslinjegranskningar (code>run_batch_baselines.py --tools pr-agent devin claude-code codex/code>), kör agentupplösning (code>run_batch_agent_resolution.py/code>), utvärdera sedan (code>run_batch_tool_eval.py --tool <name>/code>). Om du vill lägga till en femte granskare, tänk på att utbyggnadspunkten inte är ett plugin-gränssnitt: baslinjegranskningsprompterna för varje verktyg finns i code>run_batch_baselines.py/code>, och README dokumenterar ingen renare metod — du redigerar det skriptet.

Två ytterligare fakta innan du klonar den. Artikeln är licensierad under CC BY 4.0; repository-sidan anger ingen licens för koden, så anta inte att det finns en. Och artikeln publicerar inga siffror för kostnad eller tokenanvändning för att köra benchmarken — det är inte publicerat, så vi tänker inte hitta på det. Vad pipelinen däremot antyder: en Docker-avbild per PR över 184 instanser, plus ett agent-upplösningspass, är inte något man gör på en laptop på en eftermiddag.

Vad detta innebär för alla som levererar en recensionspipeline

c-CRAB:s kärnargument är att en LLM-domare är ett opålitligt orakel. Om du inte kan bygga exekverbara orakel — och de flesta team kan inte det — är den bästa tillgängliga motåtgärden att aldrig låta domaren köras på den modell som producerade granskningen. En domare som delar granskarens modell håller med sig själv, och verifieringsgenomgången blir en gummistämpel som ändå returnerar ett nummer.

Det är precis det misslyckande som routingreceptet bakom den granskare vi levererar skyddar mot — och det är en designmässig parallell till c-CRAB’s kritik, inte ett benchmarkresultat. Harnessen kör ändå en LLM-domare, som ett andra pass som klustrar fynden, poängsätter varje kluster 0–1 för om det är en konkret defekt i denna ändring, och förkastar allt under en tröskel. Receptet som styr det, code>recipes/oracode-review.dsl.yaml/code>, är en offentlig fil. Actionen namnger aldrig en modell: den anropar ett routeralias, och receptet avgör. Såsom den är konfigurerad består receptet av fyra rader — standardgranskaren är code>deepseek/deepseek-v4-flash-0731/code>, och en regel som matchar headern code>x-cr-lens: judge/code> skickar domarpasset till code>z-ai/glm-5.3/code>, en annan leverantör. Receptets egna ord kräver att domaren “FÅR INTE NAMNGI STANDARDENS MODELL”, eftersom den på granskarens egen modell “håller med sig själv, så blir passet inaktivt medan det fortfarande rapporterar framgång”.

En domare från en annan leverantör minskar självöverensstämmelse; det gör inte en LLM-domare till ett test. c-CRAB testade inte vår granskare, och vi tänker inte antyda något annat.OrcaCode Review kör en granskningsomgång plus en oberoende verifieringsdomare, per token snarare än per plats, och varje prompt i den är offentlig — så du kan rikta den mot ett riktmärke som detta och få ditt eget nummer istället för vårt.

Slutsats

c-CRAB är det första code-review-benchmarket vars poäng du till stor del kan lita på: en granskning godkänns bara när åtgärder baserade på den åtgärdar koden. Huvudsiffrorna är genuint låga — bästa enskilda verktyget 32,1 %, unionen 41,5 % — men de mäter överlappning med problem som människor tagit upp, inte granskningarnas kvalitet, och användbarhetsdatan visar att de flesta kommentarerna är verklig signal. De bestående slutsatserna är de som själva artikeln argumenterar för: volym är inte täckning, agenter och människor ser på olika saker, och rätt användning är samarbete mellan människa och agent. Och benchmarket är öppet, så det ärliga nästa steget är att köra din egen granskare på det och få en egen siffra.