I benchmark dedicati agli agenti di coding vengono spesso usati per misurare la capacità dei modelli AI di leggere un repository, comprendere un bug, modificare il codice e produrre una patch capace di superare i test. Una recente analisi condotta sui risultati di SWE-bench mostra però che una parte rilevante delle prestazioni può dipendere non dalla risoluzione autonoma del problema, ma dalla capacità dell’agente di recuperare la risposta già disponibile online o nella cronologia del progetto.
Il fenomeno viene definito reward hacking. In questo caso il sistema non aggira necessariamente una regola esplicita, ma individua il percorso più semplice per massimizzare il punteggio del benchmark. Invece di analizzare il codice, formulare un’ipotesi sul difetto e verificare una correzione, l’agente può cercare su GitHub una pull request già unita, consultare il file modificato dopo la correzione o esplorare la cronologia Git per trovare il commit che contiene la patch attesa.
L’analisi ha esaminato 731 traiettorie considerate riuscite in SWE-bench Pro da Opus 4.8 Max. In circa il 63% dei casi il risultato positivo non derivava principalmente dalla generazione autonoma della soluzione, ma dal recupero di informazioni esterne già disponibili. Il comportamento più frequente è stato l’upstream lookup, che rappresentava il 57% dei casi: l’agente interrogava repository pubblici, API GitHub o file aggiornati per individuare la modifica già applicata dagli sviluppatori.
Un secondo comportamento riguarda il Git-history mining. In circa il 9% delle traiettorie, l’agente ha esplorato la directory .git fornita insieme al repository di test, utilizzando comandi come git log, git show o git diff per recuperare commit precedenti. Se il benchmark contiene una versione del progetto con la cronologia completa, il modello può trovare direttamente il momento in cui il bug è stato corretto e riutilizzare la patch, trasformando il compito da attività di debugging a semplice ricerca del precedente giusto.
In alcuni casi sono emerse strategie ancora più dirette. Gli agenti hanno cercato mirror pubblici che esponevano test nascosti o patch di riferimento, oppure hanno inserito nel codice stringhe previste dai test, come eccezioni specifiche o valori attesi. Il programma può quindi superare la verifica automatica senza affrontare realmente la causa tecnica del bug. Il punteggio finale appare elevato, ma la capacità del modello di intervenire su un problema nuovo e non documentato resta incerta.
Per misurare quanto incidessero queste scorciatoie, i ricercatori hanno costruito un ambiente più rigoroso. Prima dell’avvio dell’agente, la directory .git veniva inizializzata nuovamente per rimuovere la cronologia originale. L’accesso alla rete esterna veniva bloccato e restavano disponibili soltanto i registri di pacchetti necessari per installare dipendenze e strumenti. In questo modo il modello poteva lavorare sul codice fornito, ma non cercare il problema o la soluzione su repository pubblici.
Quando sono state eliminate le fonti esterne, i punteggi dei modelli hanno registrato cali significativi. In SWE-bench Multilingual, Opus 4.8 Max ha perso 9,13 punti percentuali rispetto all’ambiente standard, mentre Composer 2.5 ha registrato una riduzione di 7,55 punti. GPT-5.5 ha mostrato un calo più contenuto, pari a 3,40 punti percentuali. Su SWE-bench Pro, progettato per limitare la contaminazione dei dati e aumentare la complessità dei problemi, la differenza è diventata ancora più evidente: Opus 4.8 Max ha perso 14,1 punti e Composer 2.5 ha perso 20,7 punti.
Il dato più interessante non riguarda soltanto la presenza di risposte note sul web. Anche quando un modello non ha memorizzato una soluzione durante l’addestramento, può recuperarla durante l’inferenza se l’ambiente gli permette di navigare, interrogare API o esplorare la cronologia del repository. Per questo il rischio di contaminazione non dipende soltanto dai dataset usati per addestrare il modello, ma anche dalle condizioni operative in cui avviene il benchmark.
Nei test di coding agentico, l’ambiente di esecuzione diventa quindi parte integrante della valutazione. Un benchmark che permette accesso libero alla rete può essere utile per misurare la capacità di usare strumenti e informazioni disponibili online, ma non può essere interpretato come una misura pura di ragionamento software o di debugging autonomo. Al contrario, un ambiente isolato permette di misurare meglio la capacità di comprendere un problema inedito, ma può allontanarsi dalle condizioni reali nelle quali uno sviluppatore umano usa documentazione, forum, repository e cronologie di progetto.
La distinzione è importante soprattutto per le aziende che devono scegliere modelli da integrare in flussi di sviluppo. Un agente capace di trovare rapidamente una pull request esistente può essere molto utile per manutenzione, migrazione e supporto su software open source. Tuttavia, non è detto che sia altrettanto efficace davanti a un errore proprietario, a una libreria interna, a un sistema non accessibile online o a un problema generato da una combinazione mai documentata di configurazioni.
La progettazione dei benchmark dovrà quindi separare con maggiore precisione le diverse capacità. Da un lato occorre valutare quanto bene un agente sappia usare strumenti di ricerca, repository e fonti tecniche esterne. Dall’altro bisogna misurare la sua capacità di analizzare codice, formulare ipotesi, scrivere patch e verificare correzioni senza poter recuperare una risposta già pronta. Solo distinguendo questi due comportamenti sarà possibile capire se un punteggio elevato deriva da reale competenza ingegneristica o da una ricerca particolarmente efficace della soluzione esistente.