Benchmark degli strumenti di revisione del codice IA
Con il crescente utilizzo di strumenti di codifica IA, le codebase sono diventate più soggette a vulnerabilità, il che ha aumentato la necessità di revisioni del codice efficaci. Per affrontare questo, introduciamo RevEval (AI Code Review Eval), che confronta i quattro principali strumenti di revisione del codice IA su 309 pull request provenienti da repository di dimensioni variabili e ne valuta le prestazioni utilizzando i contributi di 10 sviluppatori e un LLM-as-a-judge.
Risultati del benchmark
CodeRabbit si è classificato come lo strumento di revisione del codice di maggior successo nel 51% delle 309 PR:
Per misurare la classifica abbiamo utilizzato i punteggi del LLM-as-a-judge. Abbiamo esaminato quale strumento di revisione del codice IA ha ottenuto il punteggio più alto in ogni PR (valutata tramite il nostro LLM-as-a-judge), quindi abbiamo calcolato la percentuale di tutte le PR in cui ciascuno strumento si è classificato al primo posto.
CodeRabbit ha ottenuto il punteggio più alto sia nelle valutazioni manuali umane sia in quelle del LLM-as-a-judge, seguito da Greptile e da GitHub Copilot:
Nel calcolare il punteggio medio, tutte e tre le categorie di valutazione sono state ponderate allo stesso modo. I punteggi dei repository di grandi dimensioni e di piccole dimensioni sono stati valutati dal LLM-as-a-judge, mentre le valutazioni degli sviluppatori sono state completate manualmente per verificare i punteggi del LLM-as-a-judge.
Valutazioni umane
Abbiamo chiesto agli sviluppatori che hanno partecipato alle valutazioni quale strumento di revisione del codice IA avrebbero preferito integrare nei propri flussi di lavoro. Poiché i CTO svolgono un ruolo decisionale chiave nello sviluppo software, abbiamo evidenziato le loro risposte in un grafico separato:
Confronto dettagliato
Abbiamo calcolato il numero medio di bug per PR contando tutti i bug/problemi segnalati da ciascuno strumento di revisione del codice e dividendo per il numero totale di PR (309). Non tutte le PR nella nostra codebase contengono bug o problemi. GitHub Copilot non segnala esplicitamente quando rileva un bug in una PR; pertanto, è stato escluso da questo confronto.
Di seguito puoi vedere la nostra metodologia.
Funzionalità
* È fornito dalla funzione “agentic pre-merge checks” di CodeRabbit. Convalida automaticamente le pull request rispetto agli standard di qualità e ai requisiti organizzativi personalizzati prima del merge e restituisce risultati superato/non superato con spiegazioni direttamente nel walkthrough della PR. Ogni controllo può essere configurato per avvisare gli sviluppatori o bloccare completamente i merge. Sebbene GitHub Copilot, Cursor BugBot e Greptile offrano funzionalità di revisione delle PR, funzionano come sistemi consultivi che forniscono feedback e suggerimenti anziché framework di validazione sistematici.
** Cursor e GitHub Copilot possono offrire più capacità oltre ai loro componenti di revisione del codice; nel nostro confronto sono incluse solo le funzionalità di Cursor Bugbot e di GitHub Copilot Code Review.
Le funzionalità variano in base ai piani di abbonamento, quindi alcune funzionalità indicate come disponibili sopra potrebbero non essere disponibili nel tuo abbonamento.
Nelle revisioni automatiche del codice, CodeRabbit, GitHub Copilot e Cursor Bugbot sono stati più facili da configurare rispetto a Greptile perché in Greptile le revisioni automatiche del codice non possono essere abilitate per un repository vuoto.
Approfondimento sulle funzionalità
CodeRabbit
- 40+ linter integrati e scanner di sicurezza.
- Istruzioni personalizzate basate su pattern AST.
- Si adatta nel tempo ai feedback degli sviluppatori.
- Gli sviluppatori possono taggare @coderabbitai per porre domande di follow-up, richiedere correzioni o mettere in discussione i suggerimenti.
- Supporta server MCP personalizzati per un contesto aggiuntivo.
GitHub Copilot Code Review
- Il pulsante “Implement suggestion” passa il controllo all’agente di codifica Copilot.
- Stretta integrazione con l’ecosistema GitHub.
- Istruzioni personalizzate tramite copilot-instructions.md.
Greptile
- Apprende gli standard di codifica del team dalla cronologia dei commenti delle PR.
- Con i repository di pattern, gli sviluppatori possono fare riferimento a repository correlati in greptile.json, in modo da fornire contesto aggiuntivo.
- Gli sviluppatori possono rispondere con @greptileai per domande di follow-up o suggerimenti di correzione.
- Greptile apprende dai feedback con pollice su/giù.
- Diagrammi di sequenza generati automaticamente per tutte le PR.
Cursor BugBot
- Dopo che BugBot ha identificato un bug, gli sviluppatori possono usare il pulsante “Fix in Cursor” per aprire rapidamente Cursor e correggere il bug.
- Gli sviluppatori possono personalizzare le proprie regole di revisione del codice nei file BUGBOT.md.
Avevamo anche intenzione di includere Graphite nel benchmark; tuttavia, a causa di un bug nella loro dashboard, non siamo riusciti ad abilitare le revisioni automatiche del codice per i nuovi repository. Abbiamo contattato il loro team di supporto il 25 ottobre 2025, ma la risposta non ha risolto il problema. Nonostante le email di follow-up e un messaggio nel loro canale Slack, il problema è rimasto irrisolto.
Componenti e integrazioni
* Tutte queste soluzioni supportano GitHub.
Metodologia
Abbiamo creato repository di benchmark separati per ciascuno strumento all’interno della nostra organizzazione GitHub dedicata.
Dopo aver abilitato le revisioni automatiche del codice per ogni strumento nel repository assegnato, abbiamo aperto le pull request in sequenza, atteso che lo strumento completasse la revisione, quindi chiuso le PR per registrare i risultati. Non abbiamo modificato né regolato alcuna impostazione degli strumenti. Ogni strumento è stato valutato utilizzando la configurazione predefinita, esattamente come installato.
Il nostro flusso di lavoro inizia clonando il repository sorgente così come esisteva in una data di riferimento selezionata, quindi riproducendo una per una le pull request inviate dopo tale data, preservando la struttura originale del repository.
Abbiamo utilizzato le versioni di novembre 2025 di tutti i prodotti. Il nostro benchmark era composto da 2 diversi gruppi di repository sorgente:
1. Repository noti e di dimensioni medio-grandi
Il nostro obiettivo era verificare quanto bene gli strumenti di revisione del codice IA comprendono repository con strutture ampie e complesse. Abbiamo esaminato complessivamente 289 PR in 7 repository.
2. Repository piccoli e nuovi
Siamo consapevoli che non possiamo alimentare il nostro LLM-as-a-judge con il
l’intero repository nei repository di grandi dimensioni, poiché le loro finestre di contesto non sono sufficienti a tale scopo. Pertanto, per superare questo limite, abbiamo valutato anche le prime 3-5 PR di repository nuovi e piccoli. I server MCP si adattano perfettamente alle nostre esigenze. Di conseguenza, abbiamo scelto 8 server MCP ufficiali e abbiamo fatto revisionare 20 PR su di essi.
Il nostro dataset contiene codice scritto da sviluppatori esperti. Non abbiamo valutato le prestazioni su codebase interamente generate dall’IA.
Valutazioni degli sviluppatori
Abbiamo selezionato casualmente 35 PR e le abbiamo assegnate a 10 sviluppatori; ogni PR è stata valutata 5 volte dagli sviluppatori. Il nostro obiettivo nel ripetere la valutazione era ridurre al minimo i pregiudizi degli sviluppatori. Gli sviluppatori hanno valutato i risultati in modo indipendente dal fornitore.
La maggior parte di loro è giunta alle stesse conclusioni di alto livello:
- Le revisioni dettagliate di CodeRabbit sono utili e lo strumento è efficace nel rilevamento dei bug.
- Greptile ha fornito riepiloghi efficaci, ma i diagrammi di sequenza generati non sono necessari per alcune PR.
- GitHub Copilot è molto efficace nel trovare refusi nel codice e fornisce suggerimenti azzeccati; la sua analisi è più breve di quelle di CodeRabbit e Greptile.
- Cursor Bugbot fornisce un’analisi meno dettagliata e meno accurata.
Dopo le valutazioni, hanno anche dichiarato che inizieranno a utilizzarli nei propri repository come strumento di supporto per gli sviluppatori.
LLM-as-a-Judge
Abbiamo utilizzato GPT-5 per valutare le revisioni. Dopo la valutazione, abbiamo utilizzato GPT-4o per strutturare l’output in formato JSON.
Il nostro flusso di lavoro di valutazione include:
- Per i repository di grandi dimensioni: corpo originale della PR, diff e commenti/revisioni degli strumenti.
- Per i repository piccoli: intera codebase, corpo originale della PR, diff e commenti/revisioni degli strumenti.
Ecco il prompt completo che abbiamo utilizzato:
Valuta ogni strumento su queste dimensioni (scala 1-5):
1. Correttezza
I problemi identificati sono realmente problemi reali, bug o correzioni nel codice?
– 5 (Eccellente): tutti i problemi identificati sono problemi reali
– 4 (Buono): la maggior parte dei problemi è reale, lievi errori di identificazione
– 3 (Accettabile): mix di problemi reali e discutibili
– 2 (Scarso): la maggior parte dei problemi identificati non sono problemi reali
– 1 (Fallito): non è in grado di identificare problemi reali, tutti i risultati sono errati
2. Completezza
Ha individuato i problemi importanti? Quanto è completa la revisione?
– 5 (Eccellente): individua tutti i problemi critici e la maggior parte di quelli importanti.
– 4 (Buono): individua i problemi principali, ne trascura alcuni minori
– 3 (Accettabile): individua alcuni problemi importanti ma presenta lacune notevoli
– 2 (Scarso): non individua diversi problemi critici
– 1 (Fallito): non individua tutti o quasi tutti i problemi critici
3. Azionabilità
I suggerimenti sono chiari e implementabili? Include patch o correzioni? Se nel codice non ci sono bug, scrivi “null” per l’azionabilità per tutti gli strumenti e non assegnare punteggi ad alcuno strumento per quella PR.
– 5 (Eccellente): tutti i suggerimenti includono patch/correzioni chiare e sono direttamente implementabili
– 4 (Buono): la maggior parte dei suggerimenti offre indicazioni chiare, alcuni includono patch
– 3 (Accettabile): i suggerimenti sono abbastanza chiari ma mancano di patch per alcuni problemi
– 2 (Scarso): i suggerimenti sono per lo più poco chiari o non implementabili
– 1 (Fallito): non vengono forniti suggerimenti o indicazioni chiare
4. Profondità
Dimostra di comprendere la logica e lo scopo del codice?
– 5 (Eccellente): dimostra una profonda comprensione della logica, dell’architettura e dello scopo del codice
– 4 (Buono): mostra una buona comprensione con piccole lacune
– 3 (Accettabile): comprensione superficiale, perde parte del contesto
– 2 (Scarso): spiegazioni superficiali o errate del comportamento del codice
– 1 (Fallito): nessuna comprensione della logica e dello scopo del codice
Formato dell’output
Per ogni strumento, fornisci:
1. Ragionamento dettagliato: cosa ha trovato? Ha trascurato problemi importanti? Sono incluse patch? Comprensione approfondita della codebase? Esempi specifici.
2. Punteggi individuali (1-5 per ciascuna dimensione, utilizzando la scala sopra indicata)
Output di esempio
Strumento A:
Ragionamento: lo strumento A ha dimostrato un’eccellente correttezza identificando una vera perdita di memoria nella logica di pooling delle connessioni alla riga 145, fornendo una patch specifica tramite un context manager. Ha inoltre rilevato la gestione degli errori mancante nell’endpoint API con codice attuabile. Il punteggio di completezza riflette che, sebbene abbia individuato problemi importanti, non ha rilevato la race condition nel gestore async che potrebbe causare problemi in produzione. Tutti e 4 i commenti erano sostanziali e direttamente implementabili. La profondità è stata elevata, mostrando una comprensione dei pattern di gestione delle risorse e della propagazione degli errori nella codebase.
Correttezza: 5
Completezza: 4
Azionabilità: 5
Profondità: 4
Strumento B:
Ragionamento: lo strumento B ha identificato correttamente la vulnerabilità di convalida dell’input alla riga 89 e ha fornito una correzione chiara utilizzando la sanitizzazione dei parametri. Tuttavia, la completezza ha sofferto in modo significativo perché non ha rilevato la vulnerabilità di sicurezza critica nel flusso di autenticazione che consente il riutilizzo del token. L’azionabilità è stata per lo più buona: i suggerimenti includevano snippet di codice. La profondità è stata accettabile ma superficiale, concentrandosi su controlli di superficie piuttosto che sulla comprensione del modello di sicurezza o delle implicazioni del flusso di dati.
Correttezza: 4
Completezza: 1
Azionabilità: 4
Profondità: 2
Strumenti da valutare: CodeRabbit, Cursor Bugbot, Github Copilot, Greptile
Sii obiettivo e accurato. Utilizza esempi specifici tratti dalle revisioni per supportare i tuoi punteggi.
Aggiungi come fonte preferitaChe cos’è la revisione del codice con l’IA?
La revisione del codice con l’IA è l’analisi automatizzata del codice sorgente tramite modelli di apprendimento automatico, principalmente modelli linguistici di grandi dimensioni (LLMs), per identificare bug, inefficienze e potenziali vulnerabilità. Oltre a rilevare i problemi, questi sistemi possono fornire spiegazioni contestuali, suggerire correzioni concrete e generare patch che aiutano gli sviluppatori a migliorare sia la qualità del codice sia la manutenibilità. Molti strumenti di revisione IA assistono anche nella documentazione, riepilogando le modifiche e producendo commenti descrittivi o spiegazioni per il codice appena aggiunto.
Poiché i modelli IA possono valutare il codice rapidamente e su larga scala, accelerano significativamente il processo di revisione e facilitano l’individuazione precoce dei problemi, mantenendo standard di codifica coerenti in progetti ampi o in rapida evoluzione.
Nei moderni ambienti di sviluppo assistiti dall’IA come Cursor o Claude Code, gli sviluppatori possono perdere involontariamente di vista l’evoluzione della propria codebase quando fanno “vibe coding” o si affidano pesantemente a suggerimenti generati automaticamente. Ciò può introdurre vulnerabilità nascoste o incoerenze logiche. Gli strumenti di revisione del codice IA aiutano a mitigare questi rischi fornendo un ulteriore livello di analisi strutturata e sistematica per convalidare e migliorare il codice generato dall’IA.
Vantaggi della revisione del codice con l’IA
Efficienza e velocità
Gli strumenti di revisione del codice IA possono analizzare il codice in tempo reale, fornendo un feedback immediato e segnalando potenziali problemi mentre gli sviluppatori lavorano. Sono in grado di rilevare errori e vulnerabilità di sicurezza che i revisori umani potrebbero trascurare, in particolare in codebase ampie o in rapida evoluzione. Automatizzando i controlli di routine, questi strumenti consentono agli sviluppatori di concentrarsi su ragionamenti di livello superiore, risoluzione di problemi complessi e decisioni architetturali.
Migliore qualità del codice
Gli strumenti di revisione del codice IA aiutano a mantenere standard di codifica coerenti tra i team, identificando incoerenze stilistiche e deviazioni dalle migliori pratiche. Offrono inoltre feedback dettagliati e raccomandazioni su un’ampia gamma di problemi di codifica, dai piccoli miglioramenti ai bug significativi. Nel tempo, gli sviluppatori possono imparare da questo feedback, affinare le proprie abitudini di codifica e adottare nuove tecniche che rafforzano la qualità complessiva del loro lavoro.
Limiti e sfide
Eccessiva dipendenza dagli strumenti IA
Una preoccupazione comune legata alla revisione del codice IA è l’eccessiva dipendenza dal feedback automatizzato. Sebbene l’IA possa essere una preziosa fonte di insight, non dovrebbe essere considerata un sostituto completo dell’esperienza umana. Le revisioni automatizzate possono accelerare i flussi di lavoro, ma i revisori umani restano essenziali per garantire correttezza, consapevolezza del contesto e allineamento con gli obiettivi del progetto. Nel nostro benchmark, gli sviluppatori hanno dichiarato costantemente che non si affiderebbero ciecamente a questi strumenti. Li considerano assistenti che integrano il giudizio umano anziché sostituirlo.
Gestire falsi positivi e falsi negativi
I falsi positivi si verificano quando lo strumento identifica erroneamente il codice funzionante come problematico, mentre i falsi negativi si verificano quando non vengono rilevati problemi reali. Nella nostra valutazione, la preoccupazione più significativa riguardava i falsi negativi. Gli strumenti tendevano più a trascurare problemi importanti che a sollevare avvisi errati. Ciò evidenzia la necessità di un miglioramento continuo dei modelli e degli algoritmi sottostanti.
Per affrontare queste sfide, gli strumenti di revisione del codice IA devono evolvere attraverso un addestramento migliore, una gestione del contesto potenziata e capacità di ragionamento più accurate.
Buone pratiche per l’uso delle revisioni del codice IA
Consigli dagli esperti
Abbina le revisioni IA all’intuito umano: utilizza le revisioni del codice IA insieme alle revisioni umane per garantire che il codice sia tecnicamente valido e allineato agli obiettivi del progetto.
Personalizza le regole in base al progetto: regola le regole dello strumento IA affinché corrispondano agli standard di codifica del progetto, riducendo gli avvisi non necessari.
Usa il feedback dell’IA come strumento di apprendimento: tratta i suggerimenti dell’IA come un’opportunità per imparare e migliorare, discutendoli con il team per capire perché e come evitare problemi simili in futuro.
Ringraziamenti
Rivolgiamo la nostra sincera gratitudine agli sviluppatori che hanno dedicato tempo e competenze per svolgere le valutazioni manuali:
Aziz Durmaz (CTO presso un’azienda di trasporti e logistica)
Berk Kalelioğlu (co-fondatore presso uno studio di sviluppo di videogiochi)
Elif Ece Örnek (ingegnere del software presso un sito web di viaggi)
Haydar Külekçi (consulente presso un’azienda di tecnologie di ricerca e IA)
Mehmet Şirin Can (responsabile dello sviluppo presso AIMultiple)
Mehmet Korkmaz (CTO presso un’azienda media nel settore degli e-sport e dei videogiochi)
Murat Orno (ex CTO presso una piattaforma di pagamento regionale con 500+ dipendenti)
Orçun Candan (sviluppatore full-stack presso AIMultiple)
Yalçın Börlü (ingegnere del software senior presso un’azienda di salute e benessere)
Yiğit Dinç (co-fondatore di un’azienda di tecnologia legale)
Ringraziamo inoltre gli sviluppatori e i manutentori dei repository open source inclusi nel nostro benchmark per il loro lavoro e i preziosi contributi alla comunità.
Anonimizzazione delle identità originali degli sviluppatori
Per condurre il benchmark in modo responsabile, abbiamo anonimizzato tutti i nomi e gli indirizzi email degli sviluppatori originali durante la riproduzione delle pull request dai repository upstream. Poiché i repository del benchmark sono pubblici, preservare le informazioni sugli autori originali potrebbe esporre involontariamente dati personali e creare il rischio di notificare gli sviluppatori ogni volta che una pull request ricreata viene aperta o aggiornata. Sebbene GitHub in genere non notifichi gli autori quando i loro commit vengono riprodotti in un repository separato, abbiamo ritenuto che fosse buona pratica evitare qualsiasi possibilità di notifiche indesiderate, problemi di attribuzione o preoccupazioni sulla privacy.
L’anonimizzazione garantisce che:
- Gli sviluppatori non vengano disturbati da migliaia di eventi PR automatizzati.
- Le informazioni personali non vengano ripubblicate in un repository pubblico diverso.
- I benchmark restino imparziali, impedendo che strumenti o giudici LLM siano influenzati da nomi di autori riconoscibili.
- Gli standard etici e di privacy vengano mantenuti quando si lavora con contributi open source.
Sono stati modificati solo i metadati relativi all’identità; tutto il codice, i diff, l’ordinamento dei commit e la struttura dei file sono stati preservati esattamente per mantenere l’autenticità e la riproducibilità del benchmark.
Cita questo benchmark
Scegli il formato adatto a dove pubblicherai. Incollare la versione con link nel tuo CMS preserva il backlink.
@misc{dilmegani2026,
author = {Dilmegani, Cem and Alper, Şevval},
title = {{Benchmark degli strumenti di revisione del codice IA}},
year = {2026},
month = mar,
howpublished = {\url{https://aimultiple.com/ai-code-review-tools}},
note = {AIMultiple. Consultato il 13 Marzo 2026}
}Il lavoro di Cem è stato citato da importanti pubblicazioni globali tra cui Business Insider, Forbes, Washington Post, aziende globali come Deloitte, HPE e ONG come il World Economic Forum e organizzazioni sovranazionali come la Commissione europea.
Nel corso della sua carriera, Cem ha lavorato come consulente tecnologico, acquirente di tecnologia e imprenditore tecnologico. Ha consigliato aziende sulle loro decisioni tecnologiche presso McKinsey & Company e Altman Solon per oltre un decennio. Ha anche pubblicato un rapporto McKinsey sulla digitalizzazione.
Ha guidato la strategia tecnologica e gli approvvigionamenti di una società di telecomunicazioni rispondendo direttamente al CEO. Ha anche guidato la crescita commerciale dell'azienda deep tech Hypatos che ha raggiunto un fatturato annuo ricorrente a 7 cifre e una valutazione a 9 cifre partendo da 0 in 2 anni. Il lavoro di Cem in Hypatos è stato trattato da importanti pubblicazioni tecnologiche come TechCrunch e Business Insider.
Cem interviene regolarmente a conferenze tecnologiche internazionali. Si è laureato in ingegneria informatica all'Università Bogazici e ha conseguito un MBA presso la Columbia Business School.
Prossimo da leggere
I migliori Google Proxies: Benchmark
I 6 migliori builder di app IA: Lovable, Base44 e Glide
Benchmark di Modelli Tabulari: Prestazioni su 19 Dataset
Top 10 Generatori di Documenti Word con IA: Recensiti & Testati
Ricerca agentica: Benchmark 8 API di ricerca per agenti
Esecuzione di codice con MCP: un nuovo approccio all'efficienza degli agenti IA
Sii il primo a commentare
Il tuo indirizzo email non verrà pubblicato. Tutti i campi sono obbligatori. I commenti vengono lasciati nella loro lingua originale.