c-CRAB, de Code Review Agent Benchmark: wat het meet, wat het vond, en wat 41,5% echt betekent

Een code-reviewagent en een menselijke reviewer bekeken hetzelfde pull-verzoek en uitten dezelfde zorg. Het opvolgen van de opmerking van de agent verhelpt de bug; de test slaagt. En elke tekstsimilariteitsmetriek die de auteurs berekenden, beoordeelde de review van de agent als in wezen niet gerelateerd aan die van de mens: BLEU-4 0.00, ROUGE-L 7.02, chrF 20.74, embedding similarity 54.59. Dezelfde zorg, andere woorden, en de standaardmanier om een review te scoren kon niet zien dat ze het eens waren. Dat ene voorbeeld is het argument achter c-CRAB (uitgesproken als “see-crab”), de Code Review Agent Benchmark, gepubliceerd alsarXiv:2603.23448.

c-CRAB evalueert code-review-agenten, niet code-schrijvende agenten. Gegeven een pull-request — dat afkomstig kan zijn van een mens of van een coderingsagent — produceert een review-agent een review, en c-CRAB scoort die review door te kijken of het opvolgen ervan leidt tot een gedragsmatig correcte fix. De benchmark is ontwikkeld door software-engineering-onderzoekers Yuntong Zhang, Zhiyuan Pan, Imam Nur Bani Yusuf, Haifeng Ruan, Ridwan Shariffdeen en Abhik Roychoudhury, en evalueert vier tools: PR-Agent, Devin, Claude Code en Codex. Een van de auteurs is verbonden aan SonarSource, en het artikel is expliciet over wat dat wel en niet betekent, in eigen woorden: “De standpunten en conclusies in dit artikel zijn uitsluitend die van de auteurs en vertegenwoordigen niet het officiële beleid of de goedkeuringen van SonarSource. Bovendien zijn de hierin gepresenteerde bevindingen onafhankelijk en mogen ze niet worden geïnterpreteerd als een evaluatie van de kwaliteit van producten van SonarSource.”

Twee opmerkingen vooraf. Sommige externe artikelen noemen hetzelfde werk “CR-bench”; het is dezelfde benchmark, en deze pagina gebruikt doorlopend c-CRAB. Elke figuur hieronder is het eigen gerapporteerde resultaat van het paper, vandaag gelezen uit het paper en het replicatiepakket — niet onafhankelijk opnieuw uitgevoerd — en de interpretatie is van ons, aangevuld met de praktijkdiscussie die het paper al heeft opgeroepen. Niets hiervan is afkomstig van de leveranciers van wie de tools zijn geëvalueerd. En als je nog steeds overweegt of je überhaupt een code-review-agent wilt inzetten, is onze kopersgids over code-review-agenten het betere startpunt; deze pagina gaat over hoe die agenten worden gemeten.

Waarom c-CRAB reviews scoort met tests in plaats van met een LLM-beoordelaar

De gebruikelijke manier om een code-reviewagent te beoordelen is door zijn review te vergelijken met die van een mens, met een LLM-as-judge of een tekstsimilariteitsmetriek. De auteurs van c-CRAB verwerpen beide. LLM-as-judge, zo betogen zij, lijdt aan vooringenomenheid, instabiliteit en promptgevoeligheid, waardoor reproduceerbare, consistente scores moeilijk te bereiken zijn. En de bovenstaande casestudy laat zien wat stringmetrieken daadwerkelijk meten: woordkeuze, niet effectiviteit. Bij die python-telegram-bot pull request zei de Codex-review hetzelfde als de mens, en BLEU-4 en ROUGE-L konden dat niet herkennen.

Dus c-CRAB doet het tegenovergestelde. Elke menselijke reviewcommentaar wordt omgezet in een uitvoerbare test die het onderliggende probleem vastlegt. Een reviewcommentaar telt als correct als het opvolgen ervan een gedragsmatig correcte fix oplevert — een die de test laat slagen. Elke instantie wordt geleverd met een uitvoerbare Docker-omgeving, zodat de beslissing over slagen/falen wordt genomen door code uit te voeren, niet door een ander model te vragen hoe vergelijkbaar twee teksten zijn. Daarom is dit belangrijk: de taak van een review is om te veranderen wat een ontwikkelaar doet, en een test is het enige scoresignaal dat die verandering direct meet.

Het artikel definieert twee soorten tests, in eigen woorden: “Gedragstests importeren en voeren de geteste code uit tijdens runtime. Ze roepen de geteste functies aan met specifieke invoer, en controleren uitvoer of verifiëren uitzonderingen. Structurele tests inspecteren daarentegen de broncodetekst, matchen patronen en controleren API-oppervlakken om te bepalen of de gewenste codewijzigingen zijn aangebracht.” De uiteindelijke verdeling is 42 gedragstests (17,9%) en 192 structurele tests (82,1%). Het is de moeite waard om eerlijk te zijn: het grootste deel van de oracle is patroonherkenning op brontekst, niet het uitvoeren van de code. Die scheefheid is een reële beperking om in gedachten te houden.

Hoe de benchmark werd opgebouwd, en wat de trechter kostte

c-CRAB is gebouwd bovenop de bestaande inclusionAI/SWE-CARE-dataset, die pull-request-instanties met commit-metadata levert; de eigen bijdrage van c-CRAB is de oracle, niet het PR-corpus. De curatiepijplijn voert vier filters uit, en elke filter kost instanties. Het paper rapporteert de trechter als volgt:

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

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

• Bouw van uitvoerbare omgeving — 410 PRs, 595 opmerkingen. Eén Docker-image per PR, waarbij het oplossen van afhankelijkheden terugvalt op een code-agent wanneer automatisering faalt.

• Natuurlijke-taalopmerkingen omzetten naar tests — 339 PR's, 481 opmerkingen. Tests worden gegenereerd met GPT-5.2 in een uitvoeringsgestuurde verfijningslus van maximaal drie pogingen; een test wordt alleen bewaard als deze faalt op de originele code en slaagt na de fix.

• Validatie met een codeeragent — 184 PR's, 234 opmerkingen. Claude Code op een Sonnet-4.6-backend probeert de code te herstellen met alleen de menselijke reviewopmerking; gevallen waarin het de test niet kan laten slagen, worden weggegooid. Dit is de uiteindelijke set.

Ongeveer 27% van de aanvankelijke pull requests overleven. Dat is de eerlijke prijs van een op tests gebaseerde oracle, en het is ook de reden dat de benchmark klein is in plaats van uitgestrekt. De overlevende set: 184 PR-instanties, 234 gevalideerde reviewcommentaren, 1,27 tests per instantie, gemiddeld 418,1 gewijzigde regels per PR, 31,8 regels per test. Twee annotatoren beoordeelden onafhankelijk of een gegenereerde test de zorg van de menselijke reviewer getrouw weergaf, bij 50 steekproefinstanties, en waren het in 84% van de gevallen eens.

Een discrepantie die u zult opmerken als u nauwkeurig leest: de tabel van de dataset vermeldt 67 repositories, terwijl de sectie over bedreigingen voor de validiteit zegt: “184 pull request-instanties met 234 verifieerbare oracles verspreid over 56 repositories.” Het artikel vermeldt beide cijfers, op verschillende plaatsen, en we gaan ze niet middelen of stilletjes het handigste cijfer kiezen. Lezers gebruiken precies dit soort details om te beoordelen of een benchmark hun tijd waard is, dus beide worden hier weergegeven zoals gepubliceerd.

De resultaten, en hoe je ze moet lezen.

Het slaagpercentage is het geaggregeerde testslaagpercentage: per instantie is dat het aandeel van de tests van die PR die slagen, en het hoofdcijfer is het gemiddelde over instanties. Het paper rapporteert per tool:

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

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

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

• Codex — 324 opmerkingen, 1.8 per PR — gedragsmatig 38.1%, structureel 16.1%, totaal 20.1%

• Mens — 234 opmerkingen, 1,3 per PR — 100% per constructie. De mensen schreven het orakel, dus deze rij is een schaalmarker, geen concurrent.

Lees die rijen zorgvuldig voordat u er een citeert. De “slechts ongeveer 40%” uit de samenvatting is een unie: 41,5% van de 234 tests werd door ten minste één van de vier tools doorstaan. Het is niet de score van één enkele agent — de beste individuele score is Claude Code’s 32,1% — en het betekent niet dat de vier tools samen 40% van de echte defecten hebben gevonden. De sectie hieronder legt uit waarom.

Het interessantste getal is niet de winnaar. Claude Code en Devin plaatsten elk meer dan 1.300 opmerkingen — ongeveer 7,3 per PR — om respectievelijk 32,1% en 24,8% te halen. Codex plaatste 324 opmerkingen, ongeveer 1,8 per PR, om 20,1% te halen. De menselijke basislijn is 1,3 opmerkingen per PR. Doe de rekensom: een ruwweg viervoudig aantal opmerkingen levert ruim minder dan een verdubbeling van het slagingspercentage op. Volume is geen dekking. Een praatzieke reviewer is niet hetzelfde als een nuttige, en c-CRAB is de eerste benchmark die dat aantoont.

Bruikbaarheid snijdt de andere kant op.

De lage slagingspercentages lezen als een veroordeling, totdat je kijkt naar wat de auteurs verder nog hebben gemeten. Ze hebben handmatig 92 opmerkingen in 6 PR's geïnspecteerd en 84% daarvan nuttig bevonden (77 van de 92) — PR-Agent 94%, Codex 88%, Devin 85%, Claude Code 78%. Dus de meeste opmerkingen die een c-CRAB-test niet doorstaan, zijn geen ruis; ze gaan over iets dat de menselijke reviewer niet heeft aangekaart. De steekproef is klein — 92 opmerkingen, 6 PR's — en de paper zegt dat ook, en dat zouden wij ook moeten erkennen.

Hetzelfde patroon komt naar voren in waar de reviewers het over hebben. Menselijke reviewers waren vooral gericht op onderhoudbaarheid, ontwerp en documentatie; de tools op robuustheid, testen en foutafhandeling. Het paper leest dit als een argument voor mens-agent samenwerking in plaats van vervanging. Het is ook de best beschikbare verklaring voor de lage scores: agenten en mensen kijken vaak naar verschillende dingen, en de oracle beloont alleen de lijst van de mens.

Wat c-CRAB niet kan zien

De benchmark is expliciet over zijn blinde vlek, en dat zijn wij ook. c-CRAB geeft geen erkenning voor een geldig probleem dat de menselijke beoordelaar nooit heeft aangekaart. De oracle is de menselijke beoordelingsintentie: een agent die een echte bug vindt die niemand noemde, scoort er nul voor. Het paper stelt het direct — geautomatiseerde beoordelingstools kunnen andere waardevolle opmerkingen genereren die menselijke beoordelaars niet hebben geïdentificeerd, maar “net als andere bestaande benchmarks evalueert c-CRAB deze aanvullende opmerkingen niet direct.”

Die ene zin is de correctie op de meeste berichtgeving over dit resultaat. Iedereen die “review agents lossen slechts 40% op” aanhaalt alsof het meet hoeveel echte defecten de agents opsporen, leest het getal verkeerd. Het meet hoeveel door mensen aangedragen problemen de agents gezamenlijk wisten op te lossen — een beperktere en veel eerlijkere claim.

Het zelf draaien

Als je de cijfers wilt reproduceren of je eigen reviewer wilt toevoegen, is het replicatiepakket openbaar beschikbaar op c-CRAB-Benchmark/dataset. De README is de eigenlijke documentatie en is eerlijk over de staat van het geheel. Installatie is code>uv sync/code>; je hebt Docker en een code>OPENAI_API_KEY/code> of code>ANTHROPIC_API_KEY/code>, en Claude Code leest daarnaast inloggegevens uit code>~/.claude/.credentials.json/code>. De organisatie publiceert ook voorgebouwde Docker-images voor de omgevingen.

De indeling: code>pipeline//code> bevat de pijplijnlogica en prompts, code>execution//code> de Docker-imagebuilders en runtime-helpers, code>results_preprocessed//code> de uitgebrachte benchmark-subset (410 voorbewerkte instanties), code>results_pipeline_funnel//code> de stage0–stage4 JSONL-bestanden en de funnel-samenvatting, en code>raw_results_compressed//code> de ruwe experimentoutputs.

Het reproduceren van de volledige run bestaat uit vijf stappen: bouw de Docker-omgevingen (code>execution.build_swe_care/code>), genereer de tests (code>run_testgen_full.sh/code>), verzamel baseline-reviews (code>run_batch_baselines.py --tools pr-agent devin claude-code codex/code>), voer de agentresolutie uit (code>run_batch_agent_resolution.py/code>), en evalueer vervolgens (code>run_batch_tool_eval.py --tool <name>/code>). Als je een vijfde beoordelaar wilt toevoegen, houd er dan rekening mee dat het uitbreidingspunt geen plugin-interface is: de baseline-review-prompts voor elke tool staan in code>run_batch_baselines.py/code>, en de README beschrijft geen schonere manier — je bewerkt dat script.

Twee aanvullende feiten voordat je het clonet. Het paper is gelicenseerd onder CC BY 4.0; de repositorypagina vermeldt geen licentie voor de code, dus neem er geen aan. En het paper publiceert geen cijfers over kosten of tokenverbruik voor het draaien van de benchmark — dat is niet gepubliceerd, dus we gaan het niet verzinnen. Wat de pipeline wel impliceert: één Docker-image per PR voor 184 instanties, plus een agent-resolutiepass, is geen middagje op laptop-schaal.

Wat dit betekent voor iedereen die een review-pipeline uitbrengt

Het kernargument van c-CRAB is dat een LLM-beoordelaar een onbetrouwbaar orakel is. Als je geen uitvoerbare orakels kunt bouwen — en de meeste teams kunnen dat niet — is de beste beschikbare mitigatie om de beoordelaar nooit te laten draaien op het model dat de review heeft geproduceerd. Een beoordelaar die hetzelfde model deelt als de reviewer is het met zichzelf eens, en de verificatieslag verandert in een formaliteit die nog steeds een getal retourneert.

Dat is precies het falen waartegen de routing-recipe achter de reviewer die wij leveren beschermt — en het is een ontwerpparallel met de kritiek van c-CRAB, geen benchmarkresultaat. De harness draait hoe dan ook een LLM-judge als tweede doorgang die bevindingen clustert, elk cluster 0–1 scoort op de vraag of het een concreet defect is in deze wijziging, en alles onder een drempel verwijdert. De recipe die dit regelt, code>recipes/orcacode-review.dsl.yaml/code>, is een openbaar bestand. De Action noemt nooit een model: hij roept een router-alias aan, en de recipe beslist. In de standaardconfiguratie is de recipe vier regels — het standaardmodel voor de reviewer is code>deepseek/deepseek-v4-flash-0731/code>, en een regel die overeenkomt met de header code>x-cr-lens: judge/code> stuurt de judge-doorgang naar code>z-ai/glm-5.3/code>, een andere leverancier. De eigen woorden van de recipe vereisen dat de judge “MAG HET STANDAARDMODEL NIET NOEMEN”, want op het eigen model van de reviewer “is het het met zichzelf eens, waardoor de doorgang inert wordt terwijl hij toch succes meldt”.

Een beoordelaar van een andere leverancier vermindert zelfovereenstemming; het maakt van een LLM-beoordelaar geen test. c-CRAB heeft onze reviewer niet getest, en we gaan niet anders impliceren.OrcaCode Review voert een reviewpass uit plus een onafhankelijke verificatiebeoordelaar, per token in plaats van per gebruiker, en elke prompt erin is openbaar — dus je kunt het op een benchmark als deze richten en je eigen getal krijgen in plaats van het onze.

Kortom

c-CRAB is de eerste code-review-benchmark waarvan je de score grotendeels kunt vertrouwen dat die betekent wat er staat: een review slaagt alleen als het opvolgen ervan de code repareert. De kopcijfers zijn echt laag — beste enkele tool 32,1%, union 41,5% — maar ze meten de overlap met door mensen aangedragen aandachtspunten, niet de kwaliteit van de reviews, en de bruikbaarheidsdata toont aan dat de meeste opmerkingen echte signalen zijn. De blijvende lessen zijn precies die waarvoor het artikel zelf pleit: volume is geen dekking, agenten en mensen kijken naar verschillende dingen, en de juiste inzet is mens-agent-samenwerking. En de benchmark is open, dus de eerlijke volgende stap is om je eigen reviewer erop te draaien en je eigen cijfer te krijgen.