Benchmark för kodgranskningsagenter: Hur man utvärderar en granskare och kör c-CRAB på din egen kod

Hur vet man om en kodgranskningsagent är bra? För större delen av detta områdes korta historia var svaret ”mät hur nära dess kommentarer ligger en mänsklig granskares” – vilket låter rimligt tills man faktiskt försöker, eftersom två granskare kan påpeka samma problem med helt olika ord. Code Review Agent Benchmark – artiklen är arXiv:2603.23448, dess dataset är c-CRAB – är det första seriösa försöket att betygsätta en granskning utifrån vad den leder till snarare än dess formulering. Det omvandlade 234 mänskliga granskningskommentarer till körbara tester, körde fyra vanliga granskare mot dem – PR-Agent, Devin, Claude Code och Codex – och fann att alla fyra tillsammans klarar 41,5 % av dessa tester, ”bara runt 40 %” enligt artikelns egna ord. Den här sidan är en handbok: hur man läser resultatet utan att förvanska det, hur man kör c-CRAB själv och vad man gör när ens kodbas inte finns med i benchmarken alls.

Rubriksiffran är det minst användbara på den här sidan. Det användbara är metoden och felsätten: varför varje tidigare poängsättningsschema mätte fel sak, vad det kostar att poängsätta en recension med körbara tester istället, och varför "recensionsagenter fångar bara 40 % av buggarna" är en tredubbel feltolkning av det faktiska resultatet. Allt här är en gemenskapsläsning av den publicerade benchmarken och av praktikers erfarenhet av att köra den — inte leverantörsvägledning från de inblandade verktygstillverkarna.

Varför de uppenbara mätvärdena inte fungerar

Före c-CRAB hamnade utvärderingar av kodgranskningsagenter i ett litet antal familjer, och artikelns egen jämförelsetabell (Tabell 1) visar härstamningen. Den äldsta är textöverlappning — BLEU, ROUGE, chrF och liknande, som används av benchmarks som CodeReviewer och ContextCRBench. Tanken är att en agents kommentar är bra när dess n-gram matchar en människas. Tanken faller samman för den typ av fall som finns överallt i kodgranskning: samma defekt beskriven med olika ord.

Artikelns fallstudie är det tydligaste exemplet. Vid en pull request i python-telegram-bot (PR #3514) flaggade både den mänskliga granskaren och Codex samma robusthetsbugg med kapslad indexering. Codex granskning var beteendemässigt korrekt — en kodagent som agerade på den producerade en fix som klarade det körbara testet. Ändå gav textmåtten den BLEU-4 0.00, ROUGE-L 7.02, chrF 20.74 och embeddingsimilaritet 54.59. Noll n-gramöverlappning, och granskningen hade rätt. Samma problem, andra ord: strängmåtten kunde inte se det. Embeddingsimilaritet är ett delvis steg framåt — 54.59 mot ett bekräftat godkänt resultat är fortfarande långt ifrån en användbar tröskel — och den ärver samma problem i mjukare form.

LLM-as-judge, där en modell jämför agentens granskning med människans och röstar, löser vokabulärproblemet men för in tre nya, som studien namnger direkt: bias, instabilitet och känslighet för promptdesign. Kör samma jämförelse två gånger så kan en domare ge dig olika utslag; omformulera domarprompten så flyttar sig rankningarna. När du väljer mellan två granskare som ligger tre poäng ifrån varandra på samma benchmark, kan en domare med den variationen inte stödja ett beslut – och en poäng du inte kan reproducera är ingen poäng.

Vad ett exekverbart orakel ger — och vad det kostar

Idén som c-CRAB bygger på är enkel och radikal på samma gång: istället för att fråga ”låter recensionen som människans?”, fråga ”om du agerar på recensionen, blir koden fixad?”. Varje kvarhållen mänsklig recensionskommentar omvandlas till ett körbart test som fångar det underliggande problemet. En recensionskommentar räknas som korrekt om att agera på den ger en beteendemässigt korrekt fix som får testet att passera – och varje instans levereras med en körbar Docker-miljö, så ”får testet att passera” är ett faktum snarare än en bedömning.

Artikeln definierar två typer av test. Beteendetester "importerar och exekverar den testade koden vid körning," anropar funktioner "med specifika indata" och kontrollerar "utdata eller verifierar undantag." Strukturella tester "inspekterar källkodstext, matchar mönster och granskar API-ytor för att avgöra om önskade kodändringar har gjorts." Den slutgiltiga fördelningen är 42 beteendetester (17,9 %) och 192 strukturella tester (82,1 %) – och den snedfördelningen förtjänar en ärlig mening: större delen av denna testorakel är mönstermatchning på källtext, inte exekvering av koden. Guldstandarden är beteendetestet; majoriteten av datamängden är den pragmatiska versionen av det.

Att bygga oraklet är en tratt i fyra steg, och varje steg kastar bort saker:

• Initialt dataset — 671 PR:er, 1 313 granskningskommentarer.

• Granskningsfiltrering — 410 PR:er, 595 kommentarer. En LLM-klassificerare, kalibrerad mot en guldstandard av 100 manuellt annoterade kommentarer, behåller endast objektivt verifierbara problem och tar bort konversations- eller subjektiv feedback.

• Byggande av körbara miljöer — 410 PR:er, 595 kommentarer. En Docker-image per PR, där beroendeupplösningen faller tillbaka på en kodningsagent när automatiseringen misslyckas.

• Konvertering av NL-kommentarer till tester — 339 PR:er, 481 kommentarer. Genererad med GPT-5.2 under en exekveringsstyrd förfiningsloop (upp till tre försök); ett test behålls endast om det misslyckas på före-versionen och passerar på efter-versionen.

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

Ungefär 27 % av de ursprungliga pull requestarna överlever. Säg det rakt ut, för det är det ärliga priset för ett testbaserat orakel: om en kommentar inte är tillräckligt åtgärdbar för att bli ett misslyckat test, eller om miljön inte kan byggas, eller om en kompetent kodningsagent inte kan åtgärda koden enbart utifrån kommentaren, tas instansen bort. Det är också därför benchmarken är liten. 184 PR-instanser och 234 validerade kommentarer är en datamängd du kan läsa, inte en korpus du kan drunkna i – och för ett orakel som måste köra riktiga Docker-miljöer är litenhet en funktion.

Som referens: en genomsnittlig instans berör 418,1 modifierade rader, testerna är i genomsnitt 31,8 rader långa, och det finns 1,27 tester per instans. Två annoterare var överens i 84 % av fallen — fler än 50 samplade instanser — om huruvida ett genererat test troget fångade den mänskliga granskarens invändning.

En bibliografisk skönhetsfläck du kommer att stöta på om du läser artikeln själv: datatabellen (Tabell 4) listar 67 repository, medan avsnittet om hot mot validiteten säger "184 pull request-instanser med 234 verifierbara orakel över 56 repository." Artikeln anger båda siffrorna på olika ställen men avstämmer dem inte. Välj inte en favorit och ta inte genomsnittet av dem — citera varje siffra där den förekommer. Avvikelser av det här slaget är precis den typ av detalj som läsare använder för att avgöra om ett benchmark är värt deras tid.

För due diligence gällande oberoende: rapporten uppger att en författare är knuten till SonarSource och anger att resultaten inte ska tolkas som "an evaluation of the quality of products at SonarSource." Det är deras friskrivning, citerad snarare än parafraserad.

Hur man läser en notbild på c-CRAB utan att felcitera den

Huvudmåttet är godkännandegraden: per instans, andelen av den PR:ns tester som godkänns, i genomsnitt över de 184 instanserna. Här är hela resultattabellen från papperet, en rad per granskare. Den mänskliga raden är en skalmarkör snarare än en konkurrent — människorna skrev oraklet, så de får 100% per definition:

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

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

• PR-Agent — 524 kommentarer, 2.8 per PR, totalt 23.1% (beteendemässigt 38.1%, strukturellt 19.8%).

• Codex — 324 kommentarer, 1,8 per PR, totalt 20,1 % (beteendemässigt 38,1 %, strukturellt 16,1 %).

Mänsklig — 234 kommentarer, 1,3 per PR, 100 % per konstruktion.

Tre korrigeringar, eftersom abstraktets "bara runt 40%" är den mest felciterade siffran i den här delen av AI-kodardiskussionen just nu. För det första: siffran 41,5 % — 97 av de 234 testerna klarades av minst ett verktyg — är en union över alla fyra granskarna: ett test räknas en gång om någon agent klarade det. Ingen enskild agent nådde 41,5 %; det bästa enskilda resultatet är Claude Codes 32,1 %. För det andra: den mänskliga raden är oraklet, inte en tävlande; att upprepa det som "människor slår botarna" är ett kategorifel. För det tredje, och viktigast: 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 verklig bugg som ingen nämnde får noll poäng för det. Så "AI-granskningsagenter fångar bara 40 % av buggarna" är fel på tre sätt — det är en union, det är inte en andel fångade buggar, och det mäter överensstämmelse med mänskliga granskare, inte total korrekthet.

Kommentarvolymen är fällan.

Det mest intressanta numret i resultaten är inte vinnaren. Claude Code och Devin publicerade vardera fler än 1 300 kommentarer — cirka 7,3 per PR — för att nå 32,1 % och 24,8 %. Codex publicerade 324 kommentarer, cirka 1,8 per PR, och nådde 20,1 %. Den mänskliga baslinjen är 1,3 kommentarer per PR. Volym är inte täckning: ungefär fem gånger så många kommentarer ger väl under dubbelt så hög godkännandegrad. Om du väljer en granskare är den verkliga kostnaden för alla dessa extra kommentarer mänsklig granskningströtthet — varje kommentar en agent publicerar är ett bedömningsbeslut som en person måste sortera.

Användbarhetsresultatet pekar åt andra hållet, och det är den del som hindrar att detta blir en billig "botarna är brusiga"-historia. Författarna granskade för hand 92 kommentarer över 6 PR:er och bedömde 84% (77/92) som användbara — PR-Agent 94%, Codex 88%, Devin 85%, Claude Code 78%. Så de flesta kommentarer som inte klarar testet är inte brus; de handlar om något som den mänskliga granskaren inte tog upp. Urvalet är litet — 92 kommentarer, 6 PR:er — och värt att säga i samma andetag som procentsiffrorna.

Vad de två sidorna faktiskt pratar om förklarar resultatens utformning. Mänskliga granskare lutade mot underhållbarhet, design och dokumentation; verktygen lutade mot robusthet, testning och felhantering. Artikeln läser detta som ett argument för samarbete mellan människa och agent snarare än ersättning – och det är också den bästa tillgängliga förklaringen till varför poängen ser låga ut. En granskare som är skarp på kantfall men tyst om design kommer systematiskt att missa de kategorier som människor flaggar, och oraklet är byggt helt från mänskliga flaggningar.

Praktiker som har arbetat igenom detta kommer fram till samma sak. En detaljerad genomgång av Daniel Vaughan, som kallar arbetet CR-bench, når samma slutsats och omvandlar det till ett arbetsflöde: låt agenten göra robusthets- och korrekthetsgenomgången, behåll människor på design, konventioner och arkitektur — de kategorier där agenter presterar sämst — och styr agenten med granskningsinstruktioner som namnger de svaga kategorierna. Hans mest användbara varning för den som läser resultatlistan: "användbarhet är inte samma sak som godkännandegrad", eftersom testsviten kräver att man matchar människans avsedda lösning, och en giltig alternativ lösning misslyckas i testet. Vägen från 20 % till en avsevärt högre poäng, enligt hans tolkning, är inte en modelluppgradering — det är konfigurationsarbete.

Köra c-CRAB själv

Allt ovan handlar om att läsa andras resultat. Replikeringspaketet gör benchmarken körbar — den finns på c-CRAB-Benchmark/dataset på GitHub — och README:n är ärlig om vad som krävs.

Krav: code>uv sync/code>; Docker; och antingen code>OPENAI_API_KEY/code> eller code>ANTHROPIC_API_KEY/code> (Claude Code läser dessutom inloggningsuppgifter från code>~/.claude/.credentials.json/code>, monterade i containrar som standard). Layouten består av fem kataloger: code>pipeline//code> (pipeline-logik och prompts), code>execution//code> (Docker-avbildningsbyggare och runtime-hjälpare), code>results_preprocessed//code> (den publicerade benchmark-delmängden), code>results_pipeline_funnel//code> (stage0–stage4 JSONL-filerna och funnel-sammanfattningen), och code>raw_results_compressed//code> (råa experimentutdata). De fem stegen, i ordning:

1. Bygg Docker-miljöerna — code>uv run python -m execution.build_swe_care --split test --instance results_preprocessed/instance-ids.txt --max-workers 4/code>. Färdigbyggda avbildningar publiceras också under c-CRAB-Benchmarks GitHub-paketorganisation om du hellre vill hoppa över bygget.

2. Generera testerna — code>./run_testgen_full.sh --instances-file results_preprocessed/instance-ids.txt --workers 4 --output-dir results_testgen/code>.

3. Samla in baslinjerecensioner — 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>. Konfigurera motsvarande externa verktygsuppgifter innan detta steg.

4. Kör agentupplösning — 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. Utvärdera — upprepa en gång per verktyg: 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>.

Två saker som README inte nämner. Att lägga till en femte granskare innebär att redigera code>run_batch_baselines.py/code> — det är där de verktygsspecifika baslinjegranskningsprompterna finns, och det finns inget plugin-gränssnitt; README dokumenterar ingen renare utbyggnadspunkt. Och repot innehåller ingen explicit licensfil, så anta inte att koden är MIT eller Apache — artikeln är CC BY 4.0, och kodens egna villkor anges inte.

Kostnad är den andra oannonserade punkten. Artikeln publicerar inga siffror i token eller dollar för att köra pipelinen, så behandla alla kostnadssiffror du ser citerade online som overifierade. Vad strukturen antyder är tydligt nog: en Docker-avbild per PR över 184 instanser, plus en lösningskörning för kodningsagenten och en utvärderingskörning per verktyg. Det är inte en eftermiddag i laptopskala — budgetera för riktig datorkraft.

När du inte har råd med exekverbara orakel

De flesta teams ärliga ståndpunkt är: benchmarken har rätt i att en LLM-domare inte kan betygsätta recensioner, men att bygga ett testbaserat orakel för sina egna PR:er är ett stort lyft. Distinktionen som är värd att dra är mellan en LLM-domare som poängsättare och en LLM-domare som filter. c-CRAB:s avvisande av domaren som orakel gör inte en domare oanvändbar i en granskare — en domare som klustrar dubblettfynd och sållar bort svaga kan fortfarande höja precisionen. Den feltyp man ska designa mot är oberoende.

En domare som körs på granskarens egen modell håller med sig själv: den läser granskningen, finner den trovärdig och rapporterar framgång utan att ändra något. En domare från en annan leverantör minskar den självöverensstämmelsen — den gör inte en domare till ett test, men den sätter stopp för stämpelgodkännandet. Vi kan visa dig ett konkret, kontrollerbart exempel på just denna skyddsmekanism eftersom vår egen testmiljö är öppen: Orca-Code-Review på GitHub är MIT-licensierad, och dess routing-recept anger regeln med repots egna ord — domaren ”FÅR INTE NÄMNA DEFAULTENS MODELL”, eftersom ”på granskarens egen modell håller den med sig själv, så godkännandet blir inaktivt samtidigt som det fortfarande rapporterar framgång.” Action nämner aldrig en modell; det är receptet som avgör. I den förinställda konfigurationen är granskarens standard deepseek/deepseek-v4-flash-0731, och en regel som matchar code>x-cr-lens: judge/code>-headern skickar domargodkännandet till z-ai/glm-5.3 — en annan leverantör. Det är en designparallell till c-CRAB:s argument, inte ett resultat: vi är inte med i benchmarken och det finns ingen c-CRAB-poäng för vår granskare. Men det är den praktiska skyddsåtgärden som är tillgänglig för alla som inte kan bygga exekverbara orakel, och det är billigt när domare och granskare kan ligga hos olika leverantörer bakom en enda nyckel — vilket är vad en router är till för. På OrcaRouter är granskaren och dess domare två rader i en routing-DSL, och du betalar leverantörens listpris utan påslag.

När din kod inte är med i benchmarken.

184 PR:er över 56 eller 67 publika repositories är inte din kodbas, och det var aldrig tänkt att bli det. Den överförbara delen är metoden, och du kan köra den på din egen historik i mycket mindre skala. Ta sammanslagna PR:er som hade mänskliga granskningskommentarer. För ett urval av dessa kommentarer, skriv ett test som misslyckas innan granskningen åtgärdats och passerar efteråt — egenskapen misslyckas-sedan-passerar är hela poängen. Kör din kandidatgranskare på diffen före granskning. Kontrollera sedan om att agera på dess kommentarer får testet att passera. Det du får är en siffra beräknad på koden du faktiskt levererar, vilket är värt mer än en position på en ledartavla. Vad det kostar är exakt den vägg som pappret slog i: du behöver reproducerbara miljöer per PR, eftersom ett test som bara passerar på din laptop inte är en oracle.

Du behöver inte 234 tester. Ett dussin väl valda sådana på PR:er som ditt team faktiskt argumenterade om kommer att berätta mer om din granskare än ett benchmark-resultat. Och en parallell praktikeranalys av denna benchmarkfamilj är rak på tal om grinden: LLM-klassificerarens precision i frågan om en kommentar är ett giltigt, verifierbart problem ligger mellan 66 % och 85 %, så behandla maskinfiltrering som en kortlista och behåll ett mänskligt bedömningssteg innan något blir ett test. Samma text noterar att LangChains ReviewBench, som byggts oberoende på samma kommentar-till-test-idé, återfinner ungefär 30 % av sina baslinjeproblem i bästa fall — i samma härad som c-CRAB:s 20–32 %, och en påminnelse om att ensiffriga leaderboard-skillnader mellan verktyg ofta är mindre än bruset i din egen miljö.

Om du överhuvudtaget funderar på vilket granskningsverktyg du ska köpa, är det en annan fråga — vår köpguide för kodgranskningsagenter täcker bot-mot-agent, prissättning per användare jämfört med per token, och när självhostning lönar sig — och när du väl har ett, täcks den löpande kostnaden för en granskningsmiljö vid varje push i vår förklaring av automatisk kodgranskning. Den här sidan handlar bara om mätning, och den kompletterande texten till den här går igenom benchmarkens anatomi: konstruktionstratten, datasetstatistiken och den fullständiga resultattabellen.

FAQ

Är 41.5% den bästa agentens poäng? Nej. 41.5% är unionen över alla fyra verktygen — ett test räknas en gång om något av dem klarade det. Det bästa enskilda resultatet är Claude Codes 32.1%.

Mäter c-CRAB hur många buggar en granskare hittar? Nej. Det mäter hur väl en granskning matchar vad en mänsklig granskare tog upp, omvandlat till körbara tester. Ett verkligt fel som granskaren aldrig nämnde ger noll poäng, hur giltigt det än är.

Slog de mänskliga granskarna \"botarna\"? Den 100-procentigt mänskliga raden är själva oraklet — människorna skrev testerna — så den är en skalamarkör, inte en konkurrent.

Är c-CRAB samma sak som CR-bench? Ja. Datasetet är c-CRAB; viss tredjepartsbevakning kallar det CR-bench, men det finns bara ett benchmark här.

Vad kostar det att köra det? Artikeln publicerar inga kostnadssiffror. En Docker-avbild per PR över 184 instanser, plus ett agent-upplösningssteg, innebär reell beräkning — inte en eftermiddag i laptopskala.

Slutsats

c-CRAB:s bidrag är inte topplistan — det är demonstrationen att en granskning kan poängsättas genom att utföra dess råd, och att textlikhets- och LLM-domarsystemen som kom innan poängsatte fel sak. Om du bara tar med dig en sak, låt det vara den tredelade korrigeringen: 41,5% är en union, den mänskliga raden är oraklet, och benchmarken ger ingen poäng för brister som människor aldrig påtalat. Och om du vill ha en siffra du kan agera på, så överförs metoden — fail-then-pass-tester på dina egna sammanslagna PR:ar, ett mänskligt bedömningssteg, och, om du inte kan bygga exekverbara orakel, åtminstone en domare vars modell är oberoende av granskarens.

Om du hellre vill mäta en granskare än att argumentera om en, börja med en testrigg du kan läsa. OrcaCode Review kör en granskningsomgång plus en oberoende verifieringsdomare, per token snarare än per användare, 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.