Code Review Agent Benchmark: Hoe je een reviewer evalueert en c-CRAB op je eigen code uitvoert

Hoe weet je of een code-reviewagent iets kan? Voor het grootste deel van de korte geschiedenis van dit vakgebied was het antwoord: "meet hoe dicht de opmerkingen bij die van een menselijke reviewer liggen" — wat redelijk klinkt tot je het echt probeert, want twee reviewers kunnen hetzelfde probleem in totaal andere woorden aankaarten. De Code Review Agent Benchmark — het paper is arXiv:2603.23448, de dataset is c-CRAB — is de eerste serieuze poging om een review te beoordelen op wat het oplevert als je ernaar handelt, in plaats van op de formulering ervan. Het zette 234 menselijke reviewopmerkingen om in uitvoerbare tests, liet vier veelgebruikte reviewers erop los — PR-Agent, Devin, Claude Code en Codex — en ontdekte dat alle vier samen 41,5% van die tests halen, "slechts rond de 40%" in de woorden van het paper zelf. Deze pagina is een draaiboek: hoe je dat resultaat leest zonder het te verminken, hoe je c-CRAB zelf draait, en wat je moet doen als je codebase helemaal niet in de benchmark voorkomt.

Het kopcijfer is het minst nuttige onderdeel van deze pagina. De nuttige zaken zijn de methode en de faalwijzen: waarom elk eerder scoresysteem het verkeerde mat, wat het kost om een review te scoren met uitvoerbare tests in plaats daarvan, en waarom 'review-agents vangen slechts 40% van de bugs' een drievoudige verkeerde lezing is van het daadwerkelijke resultaat. Alles hier is een community-lezing van de gepubliceerde benchmark en van de ervaringen van beoefenaars die deze uitvoeren — geen leveranciersrichtlijn van de betrokken toolmakers.

Waarom de voor de hand liggende metrieken niet werken

Vóór c-CRAB vielen evaluaties van code-reviewagenten uiteen in een klein aantal families, en de eigen vergelijkingstabel van het artikel (Tabel 1) legt de afstamming uit. De oudste is tekstoverlap — BLEU, ROUGE, chrF en verwanten, gebruikt door benchmarks zoals CodeReviewer en ContextCRBench. Het idee is dat de opmerking van een agent goed is wanneer de n-grammen ervan overeenkomen met die van een mens. Het idee stort in bij het ene soort geval dat overal in code review voorkomt: hetzelfde defect beschreven in verschillende woorden.

De case study van het paper is het duidelijkste voorbeeld. Bij een pull request in python-telegram-bot (PR #3514) wezen zowel de menselijke reviewer als Codex op dezelfde robuustheidsbug in geneste indexering. De review van Codex was gedragsmatig correct: een codeeragent die erop reageerde produceerde een fix die de uitvoerbare test doorstond. Toch scoorden de tekstmetrieken het BLEU-4 0,00, ROUGE-L 7,02, chrF 20,74 en embeddingsimilariteit 54,59. Nul n-gram-overlap, en de review had gelijk. Hetzelfde probleem, andere woorden: de stringmetrieken konden het niet zien. Embeddingsimilariteit is een gedeeltelijke stap vooruit — 54,59 tegenover een bevestigde pas is nog steeds verre van een bruikbare drempel — en het erft hetzelfde probleem in zachtere vorm.

LLM-as-judge, waarbij een model de review van de agent vergelijkt met die van de mens en stemt, verhelpt het vocabulaireprobleem, maar introduceert drie nieuwe problemen, die het artikel direct benoemt: vooringenomenheid, instabiliteit en gevoeligheid voor promptontwerp. Voer dezelfde vergelijking twee keer uit en een rechter kan je verschillende oordelen geven; herformuleer de beoordelingsprompt en de rangschikkingen verschuiven. Wanneer je kiest tussen twee reviewers die drie punten uit elkaar liggen op dezelfde benchmark, kan een rechter met die variatie geen beslissing ondersteunen — en een score die je niet kunt reproduceren is geen score.

Wat een executable oracle oplevert — en wat het kost

Het idee waar c-CRAB op is gebouwd, is tegelijkertijd eenvoudig en radicaal: vraag niet "klinkt de review als die van de mens?", maar vraag "wordt de code gerepareerd als je op de review acteert?". Elke bewaarde menselijke reviewopmerking wordt omgezet in een uitvoerbare test die het onderliggende probleem vastlegt. Een reviewopmerking telt als correct als het acteren erop een gedragsmatig correcte fix oplevert die de test laat slagen — en elke instantie wordt geleverd met een draaiende Docker-omgeving, dus "de test laten slagen" is een feit in plaats van een oordeel.

Het paper definieert twee soorten testen. Gedragstesten "importeren en voeren de geteste code uit tijdens runtime", roepen functies aan "met specifieke invoer" en controleren "uitvoer of het verifiëren van uitzonderingen". Structurele testen "inspecteren de broncodetekst, matchen patronen en controleren API-oppervlakken om te bepalen of de gewenste codewijzigingen zijn aangebracht". De uiteindelijke verdeling is 42 gedragstesten (17,9%) en 192 structurele testen (82,1%) — en die scheefheid verdient een eerlijke zin: het grootste deel van dit orakel is patroonmatching op brontekst, niet het uitvoeren van de code. De gouden standaard is de gedragstest; het grootste deel van de dataset is de pragmatische versie daarvan.

Het bouwen van de oracle is een trechter van vier fasen, en elke fase gooit dingen weg:

• Initiële dataset — 671 PR's, 1.313 reviewopmerkingen.

• Reviewfiltering — 410 PR's, 595 opmerkingen. Een LLM-classificatie, gekalibreerd tegen een gouden set van 100 handmatig geannoteerde opmerkingen, behoudt alleen objectief verifieerbare problemen en laat conversationele of subjectieve feedback buiten beschouwing.

• Constructie van uitvoerbare omgeving — 410 PR's, 595 opmerkingen. Eén Docker-image per PR, met afhankelijkheidsresolutie die terugvalt op een codeeragent waar automatisering faalt.

• Natuurlijke-taalopmerkingen omzetten naar tests — 339 PR's, 481 opmerkingen. Gegenereerd met GPT-5.2 onder een door uitvoering geleide verfijningslus (maximaal drie pogingen); een test wordt alleen behouden als deze faalt op de voor-versie en slaagt op de na-versie.

• Validatie met een codeeragent — 184 PRs, 234 opmerkingen (definitief). Claude Code op een Sonnet-4.6-backend probeert de code te repareren op basis van alleen de menselijke reviewopmerking; gevallen waarin het de test niet kan laten slagen worden weggegooid.

Ongeveer 27% van de oorspronkelijke pull requests overleeft. Zeg dat ronduit, want het is de eerlijke prijs van een testgebaseerde oracle: als een opmerking niet concreet genoeg is om een falende test te worden, of de omgeving niet kan worden gebouwd, of een competente codeeragent de code niet uitsluitend op basis van de opmerking kan repareren, wordt de instantie geschrapt. Het is ook de reden waarom de benchmark klein is. 184 PR-instanties en 234 gevalideerde opmerkingen vormen een dataset die je kunt lezen, geen corpus waarin je kunt verdrinken — en voor een oracle die echte Docker-omgevingen moet draaien, is kleinheid een pluspunt.

Ter indicatie: een gemiddelde instantie raakt 418,1 gewijzigde regels, tests zijn gemiddeld 31,8 regels, en er zijn 1,27 tests per instantie. Twee beoordelaars waren het 84% van de tijd eens — over 50 geselecteerde instanties — over de vraag of een gegenereerde test de zorg van de menselijke beoordelaar getrouw weergaf.

Een bibliografische oneffenheid waar je tegenaan loopt als je het paper zelf leest: de databasetabel (Tabel 4) vermeldt 67 repositories, terwijl de sectie 'Threats to Validity' zegt: „184 pull request-instanties met 234 verifieerbare oracles verspreid over 56 repositories." Het paper geeft beide cijfers op verschillende plaatsen en verzoent ze niet. Kies geen favoriet en bereken geen gemiddelde — citeer elk cijfer waar het voorkomt. Dit soort discrepanties zijn precies het detail waarmee lezers bepalen of een benchmark de moeite waard is.

Voor de due diligence betreffende onafhankelijkheid: het artikel vermeldt dat één van de auteurs is gelieerd aan SonarSource, en stelt dat de bevindingen niet mogen worden geïnterpreteerd als "een evaluatie van de kwaliteit van producten bij SonarSource." Dat is hun disclaimer, geciteerd in plaats van geparafraseerd.

Hoe lees je een partituur op c-CRAB zonder deze verkeerd te citeren?

De hoofdmetriek is het slagingspercentage: per instantie het aandeel van de tests van die PR die slagen, gemiddeld over de 184 instanties. Hier is de volledige resultatentabel uit het paper, één regel per reviewer. De human-rij is een schaalmarkering in plaats van een concurrent — de mensen hebben het orakel geschreven, dus zij scoren 100% per constructie:

• Claude Code — 1.336 opmerkingen, 7,3 per PR, totaal 32,1% (gedragsmatig 38,1%, structureel 30,7%).

• Devin — 1.344 opmerkingen, 7,3 per PR, in totaal 24,8% (gedragsmatig 31,0%, structureel 23,4%).

• PR-Agent — 524 opmerkingen, 2,8 per PR, totaal 23,1% (gedragsmatig 38,1%, structureel 19,8%).

• Codex — 324 opmerkingen, 1,8 per PR, in totaal 20,1% (gedragsmatig 38,1%, structureel 16,1%).

• Mens — 234 opmerkingen, 1,3 per PR, 100% per definitie.

Drie correcties, want het "slechts ongeveer 40%" uit de samenvatting is op dit moment het meest verkeerd geciteerde getal in dit hoekje van het AI-codersgesprek. Ten eerste: het cijfer van 41,5% — 97 van de 234 tests werden door ten minste één tool gehaald — is een unie van alle vier de reviewers: een test telt één keer mee als een agent hem heeft gehaald. Geen enkele agent scoorde 41,5%; de beste individuele score is die van Claude Code: 32,1%. Ten tweede: de mensenrij is het orakel, geen deelnemer; het herhalen ervan als "mensen verslaan de bots" is een categoriefout. Ten derde, en het belangrijkste: c-CRAB telt een reëel probleem dat de menselijke reviewer nooit heeft opgeworpen niet mee. Het orakel is de intentie van de menselijke review. Een agent die een echte bug vindt die niemand noemde, scoort er nul voor. Dus "AI-reviewagenten vangen slechts 40% van de bugs" is op drie manieren fout — het is een unie, het is geen bugvangstpercentage, en het meet overeenstemming met menselijke reviewers, niet de totale correctheid.

Reactievolume is de valstrik.

Het meest interessante getal in de resultaten is niet de winnaar. Claude Code en Devin plaatsten elk meer dan 1.300 opmerkingen — ongeveer 7,3 per PR — om 32,1% en 24,8% te bereiken. Codex plaatste 324 opmerkingen, ongeveer 1,8 per PR, en behaalde 20,1%. De menselijke basislijn is 1,3 opmerkingen per PR. Volume is geen dekking: ongeveer vijf keer zoveel opmerkingen levert nog geen dubbel slagingspercentage op. Als je een reviewer kiest, zijn de echte kosten van al die extra opmerkingen menselijke reviewmoeheid — elke opmerking die een agent plaatst is een oordeel dat iemand moet triagen.

De bevinding over bruikbaarheid wijst echter de andere kant op, en het is precies dat element dat voorkomt dat dit een goedkoop 'de bots veroorzaken veel ruis'-verhaal wordt. De auteurs hebben 92 opmerkingen in 6 PR's handmatig geïnspecteerd en beoordeelden 84% (77/92) als nuttig — PR-Agent 94%, Codex 88%, Devin 85%, Claude Code 78%. De meeste opmerkingen die de test niet doorstaan, zijn dus geen ruis; ze gaan over iets waar de menselijke reviewer geen aandacht aan besteedde. De steekproef is klein — 92 opmerkingen, 6 PR's — en dat verdient het om in dezelfde adem als de percentages te worden genoemd.

Wat de twee kanten daadwerkelijk bespreken verklaart de vorm van de resultaten. Menselijke beoordelaars neigden naar onderhoudbaarheid, ontwerp en documentatie; de tools neigden naar robuustheid, testen en foutafhandeling. Het artikel leest dit als een argument voor samenwerking tussen mens en agent in plaats van vervanging — en het is ook de beste beschikbare verklaring voor waarom de scores laag lijken. Een beoordelaar die scherp is op randgevallen maar stil over ontwerp, zal systematisch de categorieën missen die mensen markeren, en de oracle is volledig opgebouwd uit menselijke markeringen.

Praktijkmensen die dit hebben doorgewerkt, komen op dezelfde plek uit. Een gedetailleerd artikel van Daniel Vaughan, die het werk CR-bench noemt, komt tot dezelfde conclusie en maakt er een workflow van: laat de agent de robuustheids- en correctheidsscan doen, houd mensen bezig met ontwerp, conventies en architectuur — de categorieën waar agenten het slechtst scoren — en stuur de agent aan met reviewinstructies die de zwakke categorieën benoemen. Zijn nuttigste kanttekening voor wie de ranglijst leest: 'bruikbaarheid is niet hetzelfde als slaagpercentage', omdat de testsuite vereist dat de oplossing overeenkomt met wat de mens beoogde, en een valide alternatieve oplossing de test niet haalt. De weg van 20% naar een betekenisvol hogere score is volgens hem geen modelupgrade — het is configuratiewerk.

c-CRAB zelf draaien

Alles hierboven gaat over het lezen van de resultaten van anderen. Het replicatiepakket maakt de benchmark uitvoerbaar — het staat op c-CRAB-Benchmark/dataset op GitHub — en de README is eerlijk over wat ervoor nodig is.

Vereisten: code>uv sync/code>; Docker; en ofwel code>OPENAI_API_KEY/code> of code>ANTHROPIC_API_KEY/code> (Claude Code leest daarnaast inloggegevens uit code>~/.claude/.credentials.json/code>, standaard gemonteerd in containers). De indeling bestaat uit vijf mappen: code>pipeline//code> (pijplijnlogica en prompts), code>execution//code> (Docker-imagebouwers en runtime-helpers), code>results_preprocessed//code> (de vrijgegeven benchmark-subset), code>results_pipeline_funnel//code> (de stage0–stage4 JSONL-bestanden en funnel-samenvatting), en code>raw_results_compressed//code> (ruwe experiment-outputs). De vijf stappen, in volgorde:

1. Bouw de Docker-omgevingen — code>uv run python -m execution.build_swe_care --split test --instance results_preprocessed/instance-ids.txt --max-workers 4/code>. Vooraf gebouwde images zijn ook gepubliceerd onder de c-CRAB-Benchmark GitHub packages-org als je de build liever overslaat.

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

3. Verzamel baseline-reviews — 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>. Configureer de bijbehorende externe tool-referenties voordat je deze stap uitvoert.

4. Voer agentresolutie uit — 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. Evalueer — herhaal één keer per tool: 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>.

Twee dingen die de README niet vermeldt. Een vijfde reviewer toevoegen betekent het bewerken van code>run_batch_baselines.py/code> — dat is waar de per-tool-baseline-reviewprompts zich bevinden, en er is geen plugin-interface; de README documenteert geen netter uitbreidingspunt. En de repository bevat geen expliciet licentiebestand, dus ga er niet vanuit dat de code MIT of Apache is — het paper is CC BY 4.0, en de licentievoorwaarden van de code worden niet vermeld.

Kosten zijn het andere niet genoemde onderdeel. Het paper publiceert geen token- of dollarbedragen voor het draaien van de pipeline, dus behandel elk kostenbedrag dat je online geciteerd ziet als ongeverifieerd. Wat de structuur impliceert is duidelijk genoeg: één Docker-image per PR over 184 instanties, plus een coding-agent-resolutiepass en een evaluatiepass per tool. Dat is geen laptop-schaal middagwerk — reken op echte rekenkracht.

Wanneer u zich geen uitvoerbare orakels kunt veroorloven

De eerlijke positie van de meeste teams is: de benchmark heeft gelijk dat een LLM-rechter geen reviews kan beoordelen, maar het bouwen van een op tests gebaseerde oracle voor je eigen PR's is een hele klus. Het onderscheid dat de moeite waard is om te maken, is tussen een LLM-rechter als scorer en een LLM-rechter als filter. De afwijzing door c-CRAB van de rechter als oracle maakt een rechter niet nutteloos binnen een reviewer — een rechter die dubbele bevindingen clustert en zwakke bevindingen weglaat, kan nog steeds de precisie verhogen. De faalmodus waar tegen ontworpen moet worden, is onafhankelijkheid.

Een judge die op het eigen model van de reviewer draait, is het met zichzelf eens: hij leest de review, vindt die aannemelijk en rapporteert succes terwijl er niets verandert. Een judge van een andere leverancier vermindert die instemming met zichzelf — het verandert een judge niet in een test, maar het stopt de automatische goedkeuring. We kunnen je een concreet, controleerbaar voorbeeld van precies deze guardrail tonen, omdat onze eigen harness open is: Orca-Code-Review op GitHub is MIT-gelicenseerd, en het routingrecept vermeldt de regel in de eigen woorden van de repo: de judge "MAG HET MODEL VAN DE DEFAULT NIET NOEMEN", omdat "hij op het eigen model van de reviewer het met zichzelf eens is, waardoor de pass inert wordt terwijl die nog steeds succes meldt". De Action noemt nooit een model; het recept beslist. Zoals geconfigureerd is de standaardreviewer deepseek/deepseek-v4-flash-0731, en een regel die overeenkomt met de code>x-cr-lens: judge/code> header stuurt de judge-pass naar z-ai/glm-5.3 — een andere leverancier. Dat is een ontwerp dat parallel loopt aan het argument van c-CRAB, geen resultaat: we maken geen deel uit van de benchmark en er is geen c-CRAB-score voor onze reviewer. Maar het is de praktische mitigatie die beschikbaar is voor iedereen die geen uitvoerbare orakels kan bouwen, en het is goedkoop wanneer judge en reviewer op verschillende providers achter één key kunnen draaien — dat is waar een router voor is. Op OrcaRouter zijn de reviewer en zijn judge twee regels in een routing-DSL, en je betaalt de lijstprijs van de provider zonder opslag.

Wanneer uw code niet in de benchmark staat

184 pull-requests verspreid over 56 of 67 openbare repositories is niet jouw codebase, en dat was het ook nooit van plan. Het overdraagbare deel is de methode, en je kunt die op je eigen historie draaien op een veel kleinere schaal. Neem gemergde PR's waar menselijk reviewcommentaar op zat. Schrijf voor een steekproef van die opmerkingen een test die faalt voordat het review is verwerkt en daarna slaagt — de faal-dan-slaag-eigenschap is het hele spel. Draai je kandidaat-reviewsysteem op de diff van vóór het review. Controleer vervolgens of het opvolgen van de opmerkingen de test laat slagen. Wat je krijgt is een getal berekend over de code die je daadwerkelijk uitbrengt, en dat is meer waard dan een positie op een ranglijst. Wat het kost is precies de muur waar het paper tegenaan liep: je hebt reproduceerbare per-PR-omgevingen nodig, want een test die alleen op je laptop slaagt is geen orakel.

Je hebt geen 234 tests nodig. Een dozijn goed gekozen tests op PR's waar je team daadwerkelijk over heeft gediscussieerd, zal je meer vertellen over je reviewer dan een benchmarkscore. En een parallelle praktijkanalyse van deze benchmarkfamilie is bot over de poort: de precisie van de LLM-classificator bij het beoordelen of een opmerking een geldig, verifieerbaar probleem is, ligt tussen 66% en 85%, dus behandel machinefiltering als een shortlist en houd een menselijke beoordelingsstap voordat iets een test wordt. Hetzelfde artikel merkt op dat LangChain's ReviewBench, onafhankelijk gebouwd op hetzelfde idee van opmerking-naar-test, op zijn best ruwweg 30% van de problemen uit zijn baseline terugvindt — in dezelfde orde van grootte als c-CRAB's 20–32%, en een herinnering dat enkelcijferige leaderboardverschillen tussen tools vaak kleiner zijn dan de ruis in je eigen opstelling.

Of je überhaupt beslist welke reviewtool je wilt kopen, is een andere vraag — onze kopersgids voor code-review-agents behandelt bot versus agent, prijzen per seat versus per token, en wanneer self-hosting de beste keuze is — en als je er eenmaal een hebt, komen de lopende kosten van een review-harness bij elke push aan bod in ons uitlegartikel over geautomatiseerde code-review. Deze pagina gaat alleen over meten, en het bijbehorende artikel neemt de anatomie van de benchmark door: de constructietrechter, de datasetstatistieken en de volledige resultatentabel.

Veelgestelde vragen

Is 41.5% de hoogste score van een agent? Nee. 41.5% is de unie over alle vier de tools — een test telt één keer als een van de tools hem heeft doorstaan. De beste individuele score is die van Claude Code: 32.1%.

Meet c-CRAB hoeveel bugs een reviewer vindt? Nee. Het meet hoe goed een review overeenkomt met wat een menselijke reviewer heeft aangevoerd, omgezet in uitvoerbare tests. Een echt defect dat de mens nooit noemde, scoort nul, hoe terecht het ook is.

Hebben de menselijke beoordelaars de bots "verslagen"? De 100% menselijke rij is de oracle zelf — de mensen schreven de tests — dus het is een schaalmarkering, geen concurrent.

Is c-CRAB hetzelfde als CR-bench? Ja. De dataset is c-CRAB; sommige externe berichtgeving noemt het CR-bench, maar er is hier maar één benchmark.

Wat kost het om het te draaien? Het paper publiceert geen kostencijfers. Eén Docker-image per PR over 184 instanties, plus een agent-resolutiepass, betekent serieuze rekenkracht — geen middagwerk op laptopschaal.

Kortom

De bijdrage van c-CRAB is niet het leaderboard — het is de demonstratie dat een review kan worden gescoord door het advies uit te voeren, en dat de eerdere methoden op basis van tekstovereenkomst en LLM-beoordelaars het verkeerde beoordeelden. Als je maar één ding onthoudt, laat het dan de driedelige correctie zijn: 41,5% is een vereniging, de menselijke rij is de oracle, en de benchmark geeft geen krediet voor defecten die mensen nooit hebben gemeld. En als je een getal wilt waar je iets aan hebt, dan is de methode overdraagbaar: fail-then-pass-tests op je eigen gemergde PR's, een menselijke beoordelingsstap, en, als je geen uitvoerbare oracles kunt bouwen, op zijn minst een beoordelaar wiens model onafhankelijk is van het model van de reviewer.

Als u liever een beoordelaar meet dan erover te discussiëren, begin dan met een testomgeving die u kunt lezen. OrcaCode Review voert een beoordelingsronde uit plus een onafhankelijke verificatiebeoordelaar, per token in plaats van per gebruiker, en elke prompt daarin is openbaar — zodat u het op een benchmark zoals deze kunt richten en uw eigen cijfer krijgt in plaats van het onze.