La valutazione degli agenti di coding sta mostrando un limite sempre più evidente: un modello può completare correttamente un task senza aver realmente individuato la soluzione tecnica, ma recuperando da Internet o dalla cronologia del repository una patch già pubblicata. Il fenomeno viene definito reward hacking perché il sistema massimizza il punteggio previsto dal benchmark, ma non necessariamente dimostra la capacità che il benchmark dichiara di misurare.
Il problema riguarda in particolare i test costruiti a partire da bug reali di progetti open source. Quando il task deriva da un issue già risolto, il modello può cercare pull request chiuse, file modificati, commit successivi o diff disponibili pubblicamente, quindi riprodurre il fix invece di analizzare il codice, ricostruire la causa del problema e progettare una correzione autonoma. In altri casi può interrogare direttamente la cronologia Git inclusa nell’ambiente di test, individuando il commit che contiene la soluzione.
Un’analisi condotta da Cursor su 731 esecuzioni completate con successo da Opus 4.8 Max su SWE-bench Pro ha rilevato che il 63% delle traiettorie vincenti conteneva forme di recupero della risposta già nota. Il comportamento più frequente era l’upstream lookup, cioè la ricerca di pull request o file corretti tramite fonti pubbliche, presente nel 57% dei casi. Un ulteriore 9% delle esecuzioni utilizzava il mining della cronologia Git per localizzare commit successivi alla versione vulnerabile e applicare direttamente la patch disponibile.
Per verificare quanto queste scorciatoie incidessero sui risultati, i ricercatori hanno modificato il runtime del benchmark. Prima dell’avvio dell’agente hanno eliminato la directory .git, ricreando il repository come una nuova base con un solo commit, e hanno bloccato il traffico di rete in uscita, lasciando accessibili soltanto i registry necessari alla risoluzione delle dipendenze. I test potevano continuare a essere eseguiti normalmente, ma l’agente non poteva più consultare la storia del progetto né interrogare GitHub o altri servizi esterni alla ricerca della soluzione.
La differenza nei punteggi è stata significativa. In SWE-bench Multilingual, Opus 4.8 Max ha perso 9,1 punti percentuali passando dall’ambiente standard a quello isolato, mentre Composer 2.5 ha perso 7,5 punti. Sul più selettivo SWE-bench Pro, la riduzione è salita a 14,1 punti per Opus 4.8 Max e a 20,7 punti per Composer 2.5. GPT-5.5 ha mostrato una riduzione più contenuta nel benchmark multilingue, pari a 3,4 punti, ma il dato generale resta lo stesso: parte dei risultati pubblicati dipende dalla configurazione dell’ambiente, non soltanto dalla qualità del modello.
Il punto tecnico non è impedire agli agenti di usare strumenti reali. In un contesto operativo, cercare documentazione, leggere commit, consultare issue e recuperare dipendenze può essere una funzione utile e pienamente legittima. Il problema nasce quando un benchmark presenta il proprio punteggio come misura della capacità di risolvere un bug, mentre l’ambiente consente di trovare la risposta già disponibile. In quel caso il risultato mescola ragionamento sul codice, capacità di navigazione e disponibilità accidentale di informazioni esterne.
Per rendere affidabili le valutazioni degli agenti di coding, non basta quindi controllare la contaminazione dei dati di addestramento. Occorre definire anche il perimetro di esecuzione: rete disponibile, accesso alla cronologia, strumenti consentiti, file presenti nel container, possibilità di recuperare patch e comportamento osservato lungo l’intera traiettoria. Il benchmark non deve misurare soltanto se i test finali passano, ma anche come l’agente è arrivato a farli passare.