Strumenti di benchmark per la revisione del codice tramite intelligenza artificiale
Con il crescente utilizzo di strumenti di programmazione basati sull'IA , le codebase sono diventate più vulnerabili, aumentando la necessità di efficaci revisioni del codice. Per affrontare questo problema, presentiamo RevEval (AI Code Review Eval), uno strumento che mette a confronto le prestazioni dei quattro migliori strumenti di revisione del codice basati sull'IA, analizzando 309 pull request provenienti da repository di diverse dimensioni e valutandone le performance grazie al contributo di 10 sviluppatori e di un esperto di LLM in veste di giudice.
Risultati di riferimento
CodeRabbit si è classificato come lo strumento di revisione del codice di maggior successo nel 51% delle 309 pull request analizzate:
Per misurare la classifica abbiamo utilizzato i punteggi LLM-as-a-judge. Abbiamo esaminato quale strumento di revisione del codice basato sull'IA ha ottenuto il punteggio più alto in ogni PR (valutato utilizzando il nostro LLM-as-a-judge) e 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 effettuate da esseri umani che in quelle condotte da LLM in veste di giudice, seguito da Greptile e GitHub Copilot:
Nel calcolo del punteggio medio, tutte e tre le categorie di valutazione sono state ponderate in egual misura. I punteggi dei repository di grandi dimensioni e quelli dei repository di piccole dimensioni sono stati valutati da LLM in veste di giudice, mentre le valutazioni degli sviluppatori sono state completate manualmente per verificare i punteggi di LLM in veste di giudice.
valutazioni umane
Abbiamo chiesto agli sviluppatori che hanno partecipato alle valutazioni quale strumento di revisione del codice basato sull'IA avrebbero preferito integrare nei loro flussi di lavoro. Poiché i CTO svolgono un ruolo chiave nel processo decisionale relativo allo sviluppo del software, abbiamo evidenziato le loro risposte in un grafico separato:
Dettaglia
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 potete consultare la nostra metodologia .
Caratteristiche
* Questa funzionalità è fornita da CodeRabbit tramite la funzione "controlli pre-unione agenti". Convalida automaticamente le pull request rispetto agli standard di qualità e ai requisiti organizzativi personalizzati prima dell'unione, restituendo risultati di successo/fallimento con relative spiegazioni direttamente nella procedura guidata della pull request. Ogni controllo può essere configurato per avvisare gli sviluppatori o bloccare completamente l'unione. Sebbene GitHub Copilot, Cursor BugBot e Greptile offrano funzionalità di revisione delle pull request, funzionano come sistemi di consulenza che forniscono feedback e suggerimenti, piuttosto che come framework di convalida sistematici.
** Cursor e GitHub Copilot potrebbero offrire funzionalità aggiuntive oltre ai loro componenti di revisione del codice; nel nostro confronto sono incluse solo le funzionalità di Cursor Bugbot e GitHub Copilot Code Review.
Le funzionalità variano a seconda del piano di abbonamento, pertanto alcune funzionalità indicate come disponibili sopra potrebbero non essere incluse nel tuo abbonamento.
Nelle revisioni automatiche del codice, CodeRabbit, GitHub Copilot e Cursor Bugbot si sono rivelati più facili da configurare rispetto a Greptile, poiché in quest'ultimo non è possibile abilitare le revisioni automatiche del codice per un repository vuoto.
Analisi approfondita delle funzionalità
CodeRabbit
- Oltre 40 filtri per pelucchi e scanner di sicurezza integrati.
- Istruzioni personalizzate basate su modelli AST.
- Si adatta nel tempo in base al feedback degli sviluppatori.
- Gli sviluppatori possono taggare @coderabbitai per chiedere chiarimenti, richiedere correzioni o porre domande sui suggerimenti.
- Supporta server MCP personalizzati per un contesto aggiuntivo.
Revisione del codice di GitHub Copilot
- Il pulsante "Implementa suggerimento" trasferisce il controllo all'agente di programmazione di Copilot.
- Stretta integrazione con l'ecosistema di GitHub.
- Istruzioni personalizzate tramite copilot-instructions.md.
Greptile
- Apprende gli standard di codifica del team dalla cronologia dei commenti alle pull request.
- Con i repository di pattern, gli sviluppatori possono fare riferimento a repository correlati in greptile.json, in modo da poter fornire un contesto aggiuntivo.
- Gli sviluppatori possono rispondere con @greptileai per ulteriori domande o suggerimenti di correzione.
- Greptile impara dai feedback positivi/negativi.
- Diagrammi di sequenza generati automaticamente per tutti i PR.
Cursor BugBot
- Una volta che BugBot ha identificato un bug, gli sviluppatori possono utilizzare il pulsante "Correggi nel cursore" per aprire rapidamente il cursore e correggere il bug.
- Gli sviluppatori possono personalizzare le proprie regole di revisione del codice nei file BUGBOT.md.
Avevamo anche intenzione di eseguire un benchmark su Graphite; 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 sollecito e un messaggio sul loro canale Slack, il problema è rimasto irrisolto.
Componenti e integrazioni
* Tutte queste soluzioni supportano GitHub.
Metodologia
Abbiamo creato repository di benchmark separati per ogni 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 e quindi chiuso le PR per registrare i risultati. Non abbiamo modificato né ottimizzato alcuna impostazione dello strumento. Ogni strumento è stato valutato utilizzando la sua configurazione predefinita, esattamente come installata.
Il nostro flusso di lavoro inizia clonando il repository sorgente così come si presentava in una data di riferimento selezionata, per poi riprodurre 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 consisteva in 2 diverse gamme di repository di codice sorgente:
1. Repository di dimensioni medio-grandi e ben noti
Il nostro obiettivo era valutare la capacità degli strumenti di revisione del codice basati sull'IA di comprendere repository con strutture ampie e complesse. Abbiamo analizzato complessivamente 289 pull request (PR) in 7 repository.
2. Repository piccoli e nuovi
Siamo consapevoli che non possiamo alimentare il nostro LLM-come-giudice con il
L'intero repository nei repository di grandi dimensioni, poiché le loro finestre di contesto non sono sufficienti a questo scopo. Pertanto, per ovviare a questo problema, abbiamo valutato anche le prime 3-5 PR dei repository nuovi e di piccole dimensioni. I server MCP si sono rivelati perfetti per le nostre esigenze. Di conseguenza, abbiamo scelto 8 server MCP ufficiali e abbiamo fatto revisionare 20 PR su di essi.
Il nostro set di dati contiene codice scritto da sviluppatori esperti. Non abbiamo valutato le prestazioni su codebase interamente generate dall'IA.
Valutazioni degli sviluppatori
Abbiamo selezionato casualmente 35 pull request (PR) e le abbiamo assegnate a 10 sviluppatori, ciascuno dei quali è stato valutato 5 volte dagli sviluppatori. Il nostro obiettivo, ripetendo la valutazione, era quello di minimizzare 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 recensioni dettagliate di CodeRabbit sono utili e il sistema si dimostra efficace nell'individuazione dei bug.
- Greptile ha fornito riepiloghi efficaci, ma i diagrammi di sequenza generati non sono necessari per alcuni PR.
Figura 1: Esempio di diagramma di sequenza fornito da Greptile. Greptile genera i diagrammi per ogni PR. 1
- GitHub Copilot è molto efficace nell'individuare errori di battitura nel codice e fornisce suggerimenti precisi; la sua analisi è più breve di quella di CodeRabbit e Greptile.
- Cursor Bugbot fornisce analisi meno dettagliate e meno accurate.
Dopo le valutazioni, hanno anche affermato che inizieranno a utilizzarli nei propri repository come strumento di supporto per gli sviluppatori.
LLM in veste di giudice
Abbiamo utilizzato GPT-5 per valutare le recensioni. Dopo la valutazione, abbiamo utilizzato GPT-4o per strutturare l'output in formato JSON.
Il nostro flusso di lavoro di valutazione comprende:
- Per repository di grandi dimensioni: il corpo originale della pull request, le differenze e i commenti/revisioni degli strumenti.
- Per i repository di piccole dimensioni: intero codice sorgente, il corpo originale della pull request, le differenze e i commenti/revisioni degli strumenti.
Ecco il prompt completo che abbiamo utilizzato:
Valuta ogni strumento in base a queste dimensioni (scala da 1 a 5):
1. Correttezza
I problemi identificati corrispondono effettivamente a veri e propri bug/correzioni nel codice?
– 5 (Eccellente): Tutti i problemi identificati sono problemi reali
– 4 (Buono): La maggior parte dei problemi sono errori di identificazione reali e di lieve entità
– 3 (Accettabile): Un mix di questioni reali e discutibili
– 2 (Scarso): La maggior parte dei problemi identificati non sono problemi reali
– 1 (Errore): Impossibile identificare problemi reali, tutti i risultati sono errati
2. Completezza
Ha individuato i problemi più importanti? Quanto è esaustiva la revisione?
– 5 (Eccellente): Individua tutte le questioni critiche e quelle più importanti.
– 4 (Buono): Individua i problemi principali, ma ne tralascia alcuni minori
– 3 (Accettabile): Individua alcune questioni importanti ma presenta lacune notevoli
– 2 (Scarso): Non rileva diverse questioni critiche
– 1 (Errore): Non rileva tutti o quasi tutti i problemi critici
3. Attuabilità
I suggerimenti sono chiari e implementabili? Sono incluse patch/correzioni? Se non ci sono bug nel codice, scrivi "null" per l'attuabilità in tutti gli strumenti, non assegnare alcun punteggio a nessuno strumento per quella pull request.
– 5 (Eccellente): Tutti i suggerimenti includono patch/correzioni chiare e sono direttamente implementabili
– 4 (Buono): La maggior parte dei suggerimenti ha indicazioni chiare, alcuni includono patch
– 3 (Accettabile): I suggerimenti sono abbastanza chiari ma mancano le soluzioni per alcuni problemi
– 2 (Scarso): I suggerimenti sono per lo più poco chiari o non attuabili
– 1 (Errore): Nessun suggerimento o indicazione chiara fornita
4. Profondità
Dimostra di aver compreso la logica e lo scopo del codice?
– 5 (Eccellente): Dimostra una profonda comprensione della logica del codice, dell'architettura e dello scopo
– 4 (Buono): Dimostra una buona comprensione con piccole lacune
– 3 (Accettabile): Comprensione superficiale, manca parte del contesto
– 2 (Scarso): Spiegazioni superficiali o errate del comportamento del codice
– 1 (Errore): Mancanza di comprensione della logica e dello scopo del codice
Formato di output
Per ogni strumento, fornire:
1. Motivazione dettagliata: Cosa ha rilevato? Ha tralasciato problemi importanti? Patch incluse? Comprensione approfondita del codice sorgente? Esempi specifici.
2. Punteggi individuali (da 1 a 5 per ciascuna dimensione, utilizzando la scala sopra riportata)
Esempio di output
Strumento A:
Motivazione: Lo strumento A ha dimostrato un'eccellente correttezza identificando una reale perdita di memoria nella logica di pooling delle connessioni alla riga 145, fornendo una patch specifica tramite un gestore di contesto. Ha inoltre individuato la mancanza di gestione degli errori nell'endpoint API con codice utilizzabile. Il punteggio di completezza riflette il fatto che, pur avendo trovato problemi importanti, non ha rilevato la condizione di gara nel gestore asincrono che avrebbe potuto causare problemi in produzione. Tutti e 4 i commenti erano sostanziali e direttamente implementabili. La profondità dell'analisi era elevata, dimostrando una comprensione dei modelli di gestione delle risorse e della propagazione degli errori nel codice sorgente.
Correttezza: 5
Completezza: 4
Attuabilità: 5
Profondità: 4
Strumento B:
Motivazione: Lo strumento B ha identificato correttamente la vulnerabilità di convalida dell'input alla riga 89 e ha fornito una soluzione chiara tramite la sanificazione dei parametri. Tuttavia, la completezza è risultata significativamente compromessa in quanto non ha rilevato la vulnerabilità di sicurezza critica nel flusso di autenticazione che consente il riutilizzo del token. L'applicabilità è stata perlopiù buona: i suggerimenti includevano frammenti di codice. La profondità era 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
Attuabilità: 4
Profondità: 2
Strumenti da valutare: CodeRabbit, Cursor Bugbot, Github Copilot, Greptile
Siate obiettivi e scrupolosi. Utilizzate esempi specifici tratti dalle recensioni per motivare le vostre valutazioni.
Che cos'è la revisione del codice basata sull'IA?
La revisione del codice tramite intelligenza artificiale è l'analisi automatizzata del codice sorgente utilizzando modelli di apprendimento automatico, principalmente modelli linguistici complessi (LLM), per identificare bug, inefficienze e potenziali vulnerabilità. Oltre a rilevare i problemi, questi sistemi possono fornire spiegazioni contestualizzate, suggerire soluzioni concrete e generare patch che aiutano gli sviluppatori a migliorare sia la qualità che la manutenibilità del codice. Molti strumenti di revisione basati sull'IA contribuiscono anche alla documentazione, riassumendo le modifiche e producendo commenti o spiegazioni descrittive per il codice appena aggiunto.
Grazie alla loro capacità di valutare il codice rapidamente e su larga scala, i modelli di intelligenza artificiale accelerano significativamente il processo di revisione e facilitano l'individuazione precoce dei problemi, mantenendo al contempo standard di codifica coerenti in progetti di grandi dimensioni o in rapida evoluzione.
Negli ambienti di sviluppo moderni assistiti dall'IA, come Cursor o Claude Code, gli sviluppatori possono inavvertitamente perdere traccia dell'evoluzione del proprio codice quando si affidano all'intuito ("vibe coding") o si basano eccessivamente sui suggerimenti generati automaticamente. Questo può introdurre vulnerabilità nascoste o incongruenze logiche. Gli strumenti di revisione del codice basati sull'IA contribuiscono 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 tramite IA
Efficienza e velocità
Gli strumenti di revisione del codice basati sull'intelligenza artificiale possono analizzare il codice in tempo reale, fornendo 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, soprattutto in codebase di grandi dimensioni 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.
Qualità del codice migliorata
Gli strumenti di revisione del codice basati sull'intelligenza artificiale aiutano a mantenere standard di codifica uniformi tra i team, identificando incongruenze stilistiche e deviazioni dalle migliori pratiche. Offrono inoltre feedback e raccomandazioni dettagliate su un'ampia gamma di problematiche di codifica, dai piccoli miglioramenti ai bug più significativi. Nel tempo, gli sviluppatori possono imparare da questo feedback, affinare le proprie abitudini di programmazione e adottare nuove tecniche che migliorano la qualità complessiva del loro lavoro.
Limitazioni e sfide
Eccessiva dipendenza dagli strumenti di intelligenza artificiale
Una preoccupazione comune riguardo alla revisione del codice tramite IA è l'eccessiva dipendenza dal feedback automatizzato. Sebbene l'IA possa essere una preziosa fonte di informazioni, non dovrebbe essere considerata un sostituto completo dell'esperienza umana. Le revisioni automatizzate possono accelerare i flussi di lavoro, ma i revisori umani rimangono essenziali per garantire la correttezza, la consapevolezza del contesto e l'allineamento con gli obiettivi del progetto. Nel nostro benchmark, gli sviluppatori hanno costantemente affermato che non si affiderebbero ciecamente a questi strumenti. Li consideravano assistenti che integrano il giudizio umano, non che lo sostituiscono.
Gestione dei falsi positivi e dei falsi negativi
I falsi positivi si verificano quando lo strumento identifica erroneamente un codice funzionante come problematico, mentre i falsi negativi si verificano quando vengono trascurati problemi reali. Nella nostra valutazione, la preoccupazione maggiore è risultata essere rappresentata dai falsi negativi. Gli strumenti tendevano a trascurare problemi importanti piuttosto che a generare 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 basati sull'IA devono evolversi attraverso un addestramento migliore, una gestione del contesto più efficace e capacità di ragionamento più accurate.
Le migliori pratiche per l'utilizzo delle revisioni del codice basate sull'IA
Consigli degli esperti
Integra le revisioni del codice basate sull'IA con le valutazioni umane: utilizza le revisioni del codice basate sull'IA insieme alle revisioni umane per garantire che il codice sia tecnicamente valido e in linea con gli obiettivi del progetto.
Personalizza le regole in base al tuo progetto: adatta le regole dello strumento di intelligenza artificiale agli standard di codifica del tuo progetto per ridurre gli avvisi non necessari.
Utilizza il feedback dell'IA come strumento di apprendimento: considera i suggerimenti dell'IA come un'opportunità per imparare e migliorare, discutendone con il tuo team per comprenderne il perché e come evitare problemi simili in futuro.
Ringraziamenti
Esprimiamo la nostra sincera gratitudine agli sviluppatori che hanno dedicato il loro tempo e la loro competenza all'esecuzione delle valutazioni manuali:
Aziz Durmaz (CTO di un'azienda di trasporti e logistica)
Berk Kalelioğlu (co-fondatore di uno studio di sviluppo di giochi)
Elif Ece Örnek (ingegnere software presso un sito web di viaggi)
Haydar Külekçi (consulente presso un'azienda di tecnologie di ricerca e intelligenza artificiale)
Mehmet Şirin Can (responsabile dello sviluppo presso AIMultiple)
Mehmet Korkmaz (CTO di un'azienda di media nel settore degli e-sport e dei videogiochi)
Murat Orno (ex CTO di una piattaforma di pagamento regionale con oltre 500 dipendenti)
Orçun Candan (sviluppatore full-stack presso AIMultiple)
Yalçın Börlü (ingegnere informatico senior presso un'azienda del settore salute e benessere)
Yiğit Dinç (co-fondatore di una società di tecnologia legale)
Ringraziamo inoltre gli sviluppatori e i manutentori dei repository open-source inclusi nel nostro benchmark per il loro lavoro e il prezioso contributo alla comunità.
Anonimizzazione delle identità degli sviluppatori originali
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, conservare le informazioni sugli autori originali potrebbe esporre involontariamente dati personali e comportare il rischio di notificare agli 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 opportuno evitare qualsiasi possibilità di notifiche indesiderate, problemi di attribuzione o violazioni della privacy.
L'anonimizzazione garantisce che:
- Gli sviluppatori non vengono disturbati da migliaia di eventi PR automatizzati.
- Le informazioni personali non vengono ripubblicate in un altro archivio pubblico.
- I parametri di riferimento rimangono imparziali, impedendo che gli strumenti o i giudici del LLM siano influenzati da nomi di autori noti.
- Gli standard etici e di privacy vengono rispettati quando si lavora con contributi open-source.
Sono stati modificati solo i metadati relativi all'identità; tutto il codice, le differenze, l'ordine dei commit e le strutture dei file sono stati preservati esattamente per mantenere l'autenticità e la riproducibilità del benchmark.
Collegamenti di riferimento
Prossimo da leggere
6 migliori fornitori di scraping a confronto (991259_843 recensioni)
Analisi comparativa dei 5 migliori scraper di recensioni di Yelp
6 migliori strumenti per la raccolta di lead: analisi di prezzi e prestazioni
Strumenti per la creazione di agenti IA low/no-code: n8n, make, Zapier
I migliori strumenti di conversione da progettazione a programmazione: un'analisi dettagliata a confronto.
Strumenti CLI di Agentic: Codex vs Claude Code
Sii il primo a commentare
Il tuo indirizzo email non verrà pubblicato. Tutti i campi sono obbligatori.