Michael JohnsonUn revisore IA può lasciare decine di commenti e comunque non rilevare un difetto importante per il rilascio. Il 5 ottobre 2026 GitHub ha presentato ReviewBench, un’anteprima di ricerca di un benchmark che confronta gli agenti in base ai problemi individuati, alle omissioni e alla precisione dei commenti.
Per gli sviluppatori, qui è importante il passaggio dal conteggio dei commenti alla verifica del loro contenuto. Il benchmark confronta i risultati dell’agente con un insieme di problemi di riferimento per la pull request e considera separatamente la gravità e la categoria dei rilievi.
Che cosa valuta esattamente ReviewBench
Il corpus comprende 219 pull request pubbliche provenienti da 187 repository con codice e licenza open source, in 19 linguaggi. GitHub riferisce che, nella creazione del corpus, ha analizzato la distribuzione di oltre 103,9 milioni di PR. Le dimensioni dei repository e la distribuzione dei linguaggi sono state scelte tenendo conto del campione complessivo di GitHub, mentre la dimensione delle modifiche è stata intenzionalmente orientata verso PR più sostanziose e adatte alla revisione.
Per ogni PR il benchmark conserva commenti di riferimento con etichette di gravità e categoria, per esempio correttezza, sicurezza, affidabilità, manutenibilità e test. ReviewBench calcola la precisione, ossia quale quota dei commenti dell’agente corrisponde a problemi reali, e la completezza, ossia quale quota dei problemi noti l’agente ha individuato. La misura Fβ permette di modificare il peso relativo di questi due criteri: dare più peso alla completezza è utile per individuare un maggior numero di problemi, mentre dare più peso alla precisione aiuta a ridurre i commenti rumorosi.
Come interpretare i dati di GitHub
La pubblicazione indica un accordo del 96,6% tra le annotazioni di ReviewBench e una verifica indipendente effettuata da ingegneri senior. Si tratta di una misura di coerenza tra le valutazioni degli esperti sui rilievi di riferimento, non della precisione di un agente IA.
Separatamente, GitHub ha descritto un test A/B interno di un ensemble di modelli per Copilot code review. Secondo l’azienda, rispetto al gruppo di controllo, la quota di commenti seguiti da modifiche del codice pertinenti è aumentata dell’8,0%, la completezza del 13,6% e il volume dei commenti del 61%, mentre il costo della revisione è diminuito dell’8,0%. Sono risultati di un singolo esperimento di GitHub: non costituiscono una valutazione di tutti gli agenti né la promessa che altre équipe otterranno lo stesso effetto.
La distinzione tra metriche è particolarmente utile quando un’équipe sceglie le impostazioni di revisione. Un volume elevato di commenti può accompagnarsi a un aumento dei rilievi utili, ma da solo non indica quanti siano stati confermati. ReviewBench suddivide i risultati anche per gravità e categoria, così che l’équipe possa esaminare separatamente, per esempio, i difetti critici o i problemi di sicurezza.
Come provare il benchmark
Secondo la descrizione di GitHub, l’anteprima di ricerca permette di esaminare l’intero dataset, confrontare i risultati pubblicati ed eseguire un proprio agente. Per una prova preliminare sono disponibili 25 PR; l’esecuzione completa comprende 219 PR in tre round. Chi partecipa fornisce un’immagine container, una configurazione e la propria chiave del modello, mentre la valutazione viene eseguita con un giudice condiviso. I risultati restano privati fino alla verifica e all’approvazione dell’invio.
In pratica, una prova di questo tipo consente di ottenere un punto di partenza comparabile e poi testare il sistema con le regole di revisione proprie e le modifiche tipiche del repository. Le condizioni della singola équipe — linguaggi, architettura, soglie di gravità e livello di rumore accettabile — possono differire dalla composizione del corpus generale.
GitHub sostiene che, nei suoi esperimenti, le variazioni delle valutazioni offline di ReviewBench corrispondevano nella direzione ai risultati in produzione. Le misurazioni pubblicate riguardano i test interni dell’azienda. Pertanto, al momento, l’uso più affidabile del benchmark consiste nel confrontare agenti sullo stesso campione e diagnosticare i loro punti di forza; la decisione di adottarli dovrebbe basarsi anche su verifiche nel flusso di lavoro della singola équipe.