c-CRAB, il Code Review Agent Benchmark: cosa misura, cosa ha scoperto e cosa significa davvero il 41,5%

Un agente di revisione del codice e un revisore umano hanno esaminato la stessa pull request e hanno sollevato la stessa osservazione. Dare seguito al commento dell'agente corregge il bug; il test passa. E ogni metrica di similarità testuale calcolata dagli autori ha valutato la revisione dell'agente come sostanzialmente non correlata a quella umana: BLEU-4 0.00, ROUGE-L 7.02, chrF 20.74, similarità dell'embedding 54.59. Stessa osservazione, parole diverse, e il metodo standard per valutare una revisione non è riuscito a vedere che erano d'accordo. Questo singolo esempio è l'argomento alla base di c-CRAB (pronunciato “see-crab”), il Code Review Agent Benchmark pubblicato come arXiv:2603.23448.

c-CRAB valuta agenti di revisione del codice, non agenti che scrivono codice. Data una pull request — che può provenire da un essere umano o da un agente che scrive codice — un agente di revisione produce una revisione, e c-CRAB assegna un punteggio a quella revisione in base al fatto che agire su di essa produca una correzione comportamentalmente corretta. Il benchmark è stato costruito dai ricercatori in ingegneria del software Yuntong Zhang, Zhiyuan Pan, Imam Nur Bani Yusuf, Haifeng Ruan, Ridwan Shariffdeen e Abhik Roychoudhury, e valuta quattro strumenti: PR-Agent, Devin, Claude Code e Codex. Uno degli autori è affiliato a SonarSource, e l'articolo è esplicito su cosa ciò significhi e cosa non significhi, con le sue stesse parole: “Le opinioni e le conclusioni espresse in questo articolo sono esclusivamente quelle degli autori e non rappresentano le politiche ufficiali o le approvazioni di SonarSource. Inoltre, i risultati qui presentati sono indipendenti e non devono essere interpretati come una valutazione della qualità dei prodotti di SonarSource.”

Due note prima di entrare nel dettaglio. Alcuni articoli di terze parti chiamano lo stesso lavoro “CR-bench”; è lo stesso benchmark, e questa pagina usa c-CRAB ovunque. Ogni figura qui sotto è un risultato riportato dall'articolo stesso, letto oggi dall'articolo e dal pacchetto di replica — non rieseguito in modo indipendente — e l'interpretazione è nostra, insieme alla discussione tra professionisti che l'articolo ha già suscitato. Nulla di tutto ciò è una guida da parte dei fornitori i cui strumenti sono stati valutati. E se stai ancora decidendo se utilizzare o meno un agente di code review, la nostra guida all'acquisto sugli agenti di code review è il punto di partenza migliore; questa pagina riguarda come vengono misurati quegli agenti.

Perché c-CRAB valuta le recensioni con test, non con un giudice LLM

Il modo abituale per valutare un agente di revisione del codice è confrontare la sua revisione con quella di un essere umano, utilizzando un LLM come giudice o una metrica di somiglianza testuale. Gli autori di c-CRAB rifiutano entrambi gli approcci. Sostengono che l'uso di un LLM come giudice soffra di pregiudizi, instabilità e sensibilità al prompt, rendendo difficile una valutazione riproducibile e coerente. E il caso di studio sopra mostra ciò che le metriche testuali misurano realmente: la formulazione, non l'efficacia. Su quella pull request di python-telegram-bot, la revisione di Codex diceva la stessa cosa di quella umana, ma BLEU-4 e ROUGE-L non sono riusciti a riconoscerlo.

Quindi c-CRAB fa l'opposto. Ogni commento di revisione umano viene convertito in un test eseguibile che cattura il problema sottostante. Un commento di revisione è considerato corretto se agendo su di esso si produce una correzione comportamentalmente corretta — una che fa superare il test. Ogni istanza è fornita con un ambiente Docker eseguibile, quindi la decisione di superamento/fallimento viene presa eseguendo il codice, non chiedendo a un altro modello quanto siano simili due testi. Ecco perché è importante: il compito di una revisione è cambiare ciò che fa uno sviluppatore, e un test è l'unico segnale di valutazione che misura direttamente quel cambiamento.

Il documento definisce due tipi di test, con le sue stesse parole: “I test comportamentali importano ed eseguono il codice testato a runtime. Invocano le funzioni testate con input specifici e controllano gli output o verificano le eccezioni. D'altra parte, i test strutturali ispezionano il testo del codice sorgente, confrontano i pattern e verificano le superfici API per determinare se le modifiche desiderate al codice sono state apportate.” La ripartizione finale è di 42 test comportamentali (17,9%) e 192 strutturali (82,1%). Vale la pena aggiungere una frase di onestà: la maggior parte dell'oracolo si basa sul pattern-matching del testo sorgente, non sull'esecuzione del codice. Questo squilibrio è una reale limitazione da tenere a mente.

Come è stato costruito il benchmark, e quanto è costato il funnel

c-CRAB è costruito sopra il dataset esistente inclusionAI/SWE-CARE, che fornisce istanze di pull-request con metadati dei commit; il contributo di c-CRAB è l'oracolo, non il corpus di PR. La pipeline di curation esegue quattro filtri, e ognuno costa istanze. L'articolo riporta il funnel come segue:

• Dataset iniziale — 671 PR, 1.313 commenti.

• Filtraggio delle revisioni — 410 PR, 595 commenti. Un classificatore LLM, calibrato su un gold set di 100 commenti annotati manualmente, conserva solo i problemi oggettivamente verificabili e scarta i feedback conversazionali o soggettivi.

• Costruzione dell'ambiente eseguibile — 410 PR, 595 commenti. Un'immagine Docker per PR, con risoluzione delle dipendenze che ricorre a un agente di codifica quando l'automazione fallisce.

• Conversione di commenti in linguaggio naturale in test — 339 PR, 481 commenti. I test sono generati con GPT-5.2 tramite un ciclo di raffinamento guidato dall'esecuzione fino a tre tentativi; un test viene mantenuto solo se fallisce sul codice originale e passa dopo la correzione.

• Validazione con un agente di codifica — 184 PR, 234 commenti. Claude Code su un backend Sonnet-4.6 tenta di correggere il codice basandosi solo sul commento di revisione umano; i casi in cui non riesce a far passare il test vengono scartati. Questo è il set finale.

Circa il 27% delle pull request iniziali sopravvive. Questo è il prezzo onesto di un oracolo basato su test, ed è anche il motivo per cui il benchmark è piccolo piuttosto che disperso. L'insieme sopravvissuto: 184 istanze di PR, 234 commenti di revisione validati, 1,27 test per istanza, 418,1 righe modificate per PR in media, 31,8 righe per test. Due annotatori hanno giudicato indipendentemente se un test generato catturasse fedelmente la preoccupazione del revisore umano, su 50 istanze campionate, e sono stati d'accordo l'84% delle volte.

Una discrepanza che noterete se leggete attentamente: la tabella del dataset elenca 67 repository, mentre la sezione sulle minacce alla validità riporta “184 istanze di pull request con 234 oracoli verificabili in 56 repository.” L'articolo riporta entrambe le cifre, in punti diversi, e non ne faremo una media né sceglieremo silenziosamente quella più comoda. I lettori usano proprio questo tipo di dettaglio per giudicare se un benchmark merita il loro tempo, quindi entrambe le cifre sono riprodotte qui come pubblicate.

I risultati, e come leggerli

Il tasso di superamento è il tasso aggregato di superamento dei test: per ciascuna istanza è la quota dei test di quella PR che superano, e il dato principale è la media tra le istanze. L'articolo riporta, per strumento:

• Claude Code — 1.336 commenti, 7,3 per PR — comportamentali 38,1%, strutturali 30,7%, complessivi 32,1%

• Devin — 1,344 commenti, 7.3 per PR — comportamentale 31.0%, strutturale 23.4%, complessivo 24.8%

• PR-Agent — 524 commenti, 2.8 per PR — comportamentale 38.1%, strutturale 19.8%, complessivo 23.1%

• Codex — 324 commenti, 1.8 per PR — comportamentale 38.1%, strutturale 16.1%, complessivo 20.1%

• Umano — 234 commenti, 1,3 per PR — 100% per costruzione. Gli esseri umani hanno scritto l'oracolo, quindi questa riga è un indicatore di scala, non un concorrente.

Leggi attentamente quelle righe prima di citarne una qualsiasi. Il “solo circa il 40%” dell'abstract è un'unione: il 41,5% dei 234 test è stato superato da almeno uno dei quattro strumenti. Non è il punteggio di un singolo agente — il miglior punteggio singolo è quello di Claude Code con il 32,1% — e non significa che i quattro strumenti insieme abbiano individuato il 40% dei difetti reali. La sezione seguente spiega perché.

Il numero più interessante non è il vincitore. Claude Code e Devin hanno pubblicato ciascuno più di 1.300 commenti — circa 7,3 per PR — per raggiungere il 32,1% e il 24,8%. Codex ha pubblicato 324 commenti, circa 1,8 per PR, per raggiungere il 20,1%. La baseline umana è di 1,3 commenti per PR. Fate i conti: approssimativamente quattro volte il volume di commenti ottiene ben meno del doppio del tasso di successo. Il volume non è copertura. Un revisore loquace non è la stessa cosa di uno utile, e c-CRAB è il primo benchmark progettato per dimostrarlo.

L'utilità ha l'effetto opposto.

I bassi tassi di superamento sembrano una condanna finché non si guarda cos'altro hanno misurato gli autori. Hanno ispezionato manualmente 92 commenti su 6 PR e giudicato utili l'84% di essi (77 su 92) — PR-Agent 94%, Codex 88%, Devin 85%, Claude Code 78%. Quindi la maggior parte dei commenti che falliscono un test c-CRAB non sono rumore; riguardano qualcosa che il revisore umano non ha sollevato. Il campione è piccolo — 92 commenti, 6 PR — e l'articolo lo dice, e dovremmo dirlo anche noi.

Lo stesso schema emerge in ciò di cui parlano i revisori. I revisori umani tendevano verso manutenibilità, design e documentazione; gli strumenti verso robustezza, testing e gestione degli errori. Il paper lo legge come un argomento a favore della collaborazione uomo-agente piuttosto che della sostituzione. È anche la migliore spiegazione disponibile per cui i punteggi sembrano bassi: agenti e umani spesso non guardano le stesse cose, e l'oracolo premia solo la lista dell'umano.

Ciò che c-CRAB non può vedere

Il benchmark è esplicito sul suo punto cieco, e anche noi lo siamo. c-CRAB non dà alcun merito per un problema valido che il revisore umano non ha mai sollevato. L'oracolo è l'intento della revisione umana: un agente che trova un vero bug che nessuno ha menzionato ottiene zero per questo. Il documento lo dice direttamente — gli strumenti di revisione automatizzata possono generare altri commenti utili che i revisori umani non hanno identificato, ma “come altri benchmark esistenti, c-CRAB non valuta direttamente questi commenti aggiuntivi.”

Quella singola frase è la correzione alla maggior parte della copertura di questo risultato. Chiunque citi “gli agenti di revisione risolvono solo il 40%” come se misurasse quanti difetti reali gli agenti individuano, sta leggendo male il numero. Misura quante preoccupazioni sollevate dagli esseri umani gli agenti, congiuntamente, sono riusciti a risolvere — un’affermazione più circoscritta e molto più onesta.

Eseguirlo da soli

Se vuoi riprodurre i numeri o aggiungere un tuo reviewer, il pacchetto di replica è pubblico su c-CRAB-Benchmark/dataset. Il README è la documentazione vera e propria, ed è onesto sulla forma della cosa. La configurazione è code>uv sync/code>; hai bisogno di Docker e di una code>OPENAI_API_KEY/code> o code>ANTHROPIC_API_KEY/code>, e Claude Code legge inoltre le credenziali da code>~/.claude/.credentials.json/code>. L'organizzazione pubblica anche immagini Docker precompilate per gli ambienti.

La struttura: code>pipeline//code> contiene la logica della pipeline e i prompt, code>execution//code> i builder di immagini Docker e gli helper di runtime, code>results_preprocessed//code> il sottoinsieme di benchmark rilasciato (410 istanze preprocessate), code>results_pipeline_funnel//code> i file JSONL degli stage0–stage4 e il riepilogo del funnel, e code>raw_results_compressed//code> gli output grezzi degli esperimenti.

Per riprodurre l'intera esecuzione servono cinque passaggi: creare gli ambienti Docker (code>execution.build_swe_care/code>), generare i test (code>run_testgen_full.sh/code>), raccogliere le revisioni di base (code>run_batch_baselines.py --tools pr-agent devin claude-code codex/code>), eseguire la risoluzione tramite agenti (code>run_batch_agent_resolution.py/code>), quindi valutare (code>run_batch_tool_eval.py --tool <name>/code>). Se vuoi aggiungere un quinto revisore, tieni presente che il punto di estensione non è un'interfaccia a plugin: i prompt delle revisioni di base per ogni strumento si trovano in code>run_batch_baselines.py/code>, e il README non documenta un modo più pulito — devi modificare quello script.

Ancora due fatti prima di clonarlo. L'articolo è concesso in licenza CC BY 4.0; la pagina del repository non indica una licenza per il codice, quindi non dare per scontato che ci sia. Inoltre, l'articolo non pubblica cifre relative a costi o utilizzo di token per l'esecuzione del benchmark — non sono pubblicate, quindi non le inventeremo. Ciò che la pipeline implica: un'immagine Docker per PR su 184 istanze, più un passaggio di risoluzione tramite agente, non è un pomeriggio da laptop.

Cosa significa per chiunque distribuisca una pipeline di recensioni

L’argomento centrale di c-CRAB è che un giudice LLM è un oracolo inaffidabile. Se non puoi costruire oracoli eseguibili — e la maggior parte dei team non può — la migliore mitigazione disponibile è non lasciare mai che il giudice venga eseguito sul modello che ha prodotto la recensione. Un giudice che condivide il modello del revisore è d’accordo con se stesso, e la fase di verifica si trasforma in un timbro di gomma che restituisce comunque un numero.

Questo è esattamente il difetto da cui la ricetta di routing dietro il reviewer che distribuiamo protegge — ed è un parallelo progettuale con la critica di c-CRAB, non un risultato di benchmark. L'harness esegue comunque un giudice LLM, come secondo passaggio che raggruppa i risultati, assegna a ciascun gruppo un punteggio 0–1 per stabilire se si tratta di un difetto concreto in questa modifica, e scarta tutto ciò che è sotto una soglia. La ricetta che lo governa, code>recipes/orcacode-review.dsl.yaml/code> è un file pubblico. L'Action non nomina mai un modello: chiama un alias del router e la ricetta decide. Come configurata, la ricetta è di quattro righe — il default del reviewer è code>deepseek/deepseek-v4-flash-0731/code>, e una regola che corrisponde all'header code>x-cr-lens: judge/code> invia il passaggio del giudice a code>z-ai/glm-5.3/code>, un fornitore diverso. Le parole stesse della ricetta richiedono che il giudice “non faccia il nome del modello di default”, perché sul modello del reviewer “concorda con sé stesso, quindi il passaggio diventa inerte pur continuando a segnalare successo”.

Un giudice di un altro fornitore riduce l'autoconcordanza; non trasforma un giudice LLM in un test. c-CRAB non ha testato il nostro reviewer, e non abbiamo intenzione di dare a intendere il contrario.OrcaCode Review esegue una passata di revisione più un giudice di verifica indipendente, per token piuttosto che per postazione, e ogni prompt al suo interno è pubblico — così puoi puntarlo verso un benchmark come questo e ottenere il tuo numero invece del nostro.

Il risultato finale

c-CRAB è il primo benchmark di code review di cui puoi fidarti abbastanza che il punteggio significhi ciò che dice: una review passa solo quando applicarla corregge il codice. I numeri principali sono genuinamente bassi — miglior strumento singolo 32.1%, unione 41.5% — ma misurano la sovrapposizione con le preoccupazioni sollevate dagli umani, non la qualità delle review, e i dati sull'utilità mostrano che la maggior parte dei commenti sono segnali reali. Le conclusioni durature sono quelle che il paper stesso sostiene: il volume non è copertura, agenti e umani guardano cose diverse, e l'impiego giusto è la collaborazione uomo-agente. E il benchmark è aperto, quindi il passo successivo onesto è eseguire il tuo reviewer su di esso e ottenere il tuo numero.