The Pulse
METR rileva che molte pull request che superano SWE-bench non verrebbero accettate
Uno studio di METR ha rilevato che il tasso di accettazione dei maintainer era inferiore di 24,2 punti percentuali rispetto ai punteggi automatici di SWE-bench, dopo che quattro maintainer avevano esaminato 296 pull request generate dall’IA
AI.info Team ·
I test automatici non predicevano l’accettazione dei maintainer
Uno studio dell’organizzazione non profit di ricerca METR ha rilevato un divario sostanziale tra le pull request generate dall’IA che superavano il valutatore automatico di SWE-bench Verified e quelle che i maintainer dei repository hanno dichiarato che avrebbero accettato. I ricercatori hanno chiesto a quattro maintainer attivi di tre repository open source di esaminare 296 pull request generate dall’IA e valutarle come avrebbero fatto durante una normale revisione del codice.
I maintainer si occupavano di scikit-learn, Sphinx e pytest. Nel loro insieme, i repository rappresentavano tre dei 12 progetti di SWE-bench Verified e 95 dei 500 problemi del benchmark. Ai revisori non è stato detto se una pull request fosse stata scritta da una persona o da un sistema di IA, e le patch sono state valutate tramite revisioni basate su GitHub.
«Abbiamo rilevato che all’incirca la metà delle PR di SWE-bench Verified che superavano i test e che erano state scritte da agenti dalla metà del 2024 alla metà/fine del 2025 non sarebbe stata integrata nel ramo principale dai maintainer dei repository, anche dopo aver corretto i risultati per tenere conto del rumore nelle decisioni dei maintainer sull’integrazione.»
— Parker Whitfill, Cheryl Wu, Joel Becker e Nate Rush, collaboratori di METR
Il divario di 24,2 punti
Il confronto principale di METR era tra la percentuale di superamento del valutatore automatico e la percentuale di accettazione da parte dei maintainer per lo stesso tipo di lavoro. In media, i risultati del valutatore automatico erano superiori di 24,2 punti percentuali rispetto alle decisioni dei maintainer sull’integrazione. L’errore standard riportato per questa differenza era di 2,7 punti percentuali.
Lo studio ha utilizzato un riferimento umano per tenere conto del fatto che la revisione del codice può comportare decisioni soggettive. I ricercatori hanno chiesto ai maintainer di esaminare 47 pull request originali scritte da persone, già integrate nei repository. I maintainer coinvolti nello studio hanno integrato circa il 68% di queste «patch dorate» e i ricercatori hanno normalizzato i risultati rispetto a questo riferimento.
METR ha affermato che la differenza mostra perché il punteggio di un benchmark non dovrebbe essere automaticamente interpretato come una misura dell’utilità nel mondo reale. Le attività di SWE-bench hanno una procedura di valutazione automatica e verificabile. Nel revisionare una pull request, un maintainer considera anche se la patch rispetta gli standard del repository, causa problemi altrove o risolve davvero il problema sottostante.
Perché superare i test non bastava
I maintainer hanno classificato le patch respinte in base ai problemi principali. Le categorie comprendevano la qualità del codice, errori non documentati o di altro tipo, la compromissione di altro codice e problemi nelle funzionalità fondamentali. Alcune patch superavano i test automatici, ma venivano comunque giudicate inadatte all’integrazione perché erano troppo prolisse, non rispettavano le convenzioni del progetto o non risolvevano correttamente il problema.
Per l’analisi principale, METR ha esaminato le patch generate dall’IA che avevano superato il valutatore automatico. Lo studio ha inoltre conteggiato le patch respinte dal valutatore come patch che i maintainer avrebbero respinto, verificando questa ipotesi su un campione più piccolo. Nell’esame di 31 patch relative a 27 problemi, i ricercatori hanno trovato un caso in cui i maintainer hanno considerato valida una patch, nonostante fosse stata respinta dal valutatore automatico.
Le esecuzioni degli agenti provenivano dall’hub di benchmarking di Epoch e comprendevano Claude 3.5 Sonnet, Claude 3.7 Sonnet, Claude 4 Opus, Claude 4.5 Sonnet e GPT-5. I ricercatori hanno utilizzato le patch nello stato originale, tranne per la rimozione di vari file di debug che agli agenti non era stato chiesto di eliminare prima dell’invio.
I limiti del confronto
METR ha precisato che i risultati non dimostrano l’esistenza di un limite fondamentale che impedisca ai sistemi di IA di superare la revisione dei maintainer. In genere, gli agenti avevano una sola opportunità per inviare una soluzione, mentre gli sviluppatori umani ricevono comunemente commenti e modificano il proprio lavoro. Prompt migliori, una progettazione migliore degli agenti o un processo di revisione iterativo potrebbero risolvere alcuni dei problemi individuati nello studio.
I ricercatori hanno anche detto che le condizioni della revisione non erano del tutto identiche a quelle dello sviluppo ordinario. Gli strumenti di integrazione continua non erano disponibili perché le patch erano state caricate su repository in stati storici, e ai maintainer era stato chiesto di ignorare i requisiti di test, poiché agli agenti non era stato chiesto di includere test adeguati.
La conclusione centrale dello studio è più circoscritta dell’affermazione secondo cui i benchmark automatici sarebbero inutili. METR ha affermato che SWE-bench Verified fornisce comunque informazioni utili per confrontare i sistemi, ma è difficile tradurne i punteggi in prestazioni nei flussi di lavoro umani. I risultati dell’organizzazione suggeriscono che i punteggi dei benchmark costituiscono un elemento di valutazione e non dovrebbero essere considerati equivalenti alla decisione di un maintainer di approvare e integrare una pull request.