Una suite verde risponde a una domanda precisa: il codice soddisfa i controlli che abbiamo scritto? Non dimostra automaticamente che la richiesta fosse completa, che la soluzione rispetti l’architettura o che un maintainer sia disposto a sostenerla nel tempo. Con i coding agent questa distanza conta di più, perché produrre molte patch è diventato più economico mentre l’attenzione necessaria per valutarle resta limitata.
Che cosa dimostra davvero un test verde
Un test che passa è evidenza utile contro una regressione specifica. La sua forza dipende però dalla copertura, dagli input scelti e dall’indipendenza dell’oracolo che stabilisce il risultato corretto. Una suite può non esercitare un ramo di autorizzazione, una condizione di concorrenza o l’interazione con una versione reale del servizio esterno.
Se lo stesso agente modifica implementazione e test, esiste inoltre il rischio che i due si accordino sul comportamento sbagliato. Per questo test nuovi, eliminati, saltati o resi meno precisi vanno letti come parte della patch, non come prova neutrale della sua bontà.
Quando il maintainer aggiunge il giudizio che manca
Nel 2026 METR ha chiesto a quattro maintainer attivi di scikit-learn, Sphinx e pytest di valutare 296 pull request generate da agenti che avevano superato il grader automatico di SWE-bench Verified. La nota stima che circa metà delle patch test-passing non sarebbe stata unita al ramo principale, anche dopo un aggiustamento per la variabilità delle decisioni dei maintainer.
Il risultato non va trasformato in una misura universale. Lo studio copre tre repository, un solo harness e modelli disponibili fino al 2025; la review era statica, senza CI e senza consentire all’agente di correggere la patch dopo il feedback. Gli autori stessi non parlano quindi di un limite fondamentale, ma di un avvertimento contro l’equivalenza tra punteggio del benchmark e utilità senza supervisione.
Anche il benchmark può misurare il bersaglio sbagliato
OpenAI ha smesso di riportare i punteggi di SWE-bench Verified nei lanci dei modelli di frontiera e lo considera non più adatto a misurarne in modo affidabile i progressi, dopo aver documentato problemi nei task e rischio di contaminazione: descrizioni, patch e repository pubblici possono essere già comparsi nei dati disponibili ai modelli. In alcuni casi i test erano troppo stretti o coprivano requisiti non espressi dal problema.
Un audit successivo di SWE-bench Pro ha stimato che circa il 30% dei task esaminati presentasse problemi sostanziali, con valori diversi tra pipeline assistita e annotatori umani. Anche questa è una stima su uno specifico dataset, non una sentenza su tutti i benchmark. La lezione operativa è più semplice: prima di interpretare un punteggio bisogna verificare qualità dei task, copertura dei test, ambiente e criterio di valutazione.
Le domande che non entrano in un’asserzione
Il maintainer controlla se la patch risolve l’intento, limita lo scope e usa le astrazioni già presenti. Valuta compatibilità, nomi, gestione degli errori, documentazione, costo operativo e facilità di rimozione. Può bocciare codice funzionante perché duplica una funzione, introduce una dipendenza sproporzionata o rende più fragile un confine architetturale.
Sicurezza e dati richiedono una lettura ancora più rigorosa. Una correzione locale può aggirare un controllo di autorizzazione, esporre informazioni nei log o trasformare una migrazione innocua sui dati di prova in un lock prolungato in produzione. Questi rischi emergono collegando il diff alla storia e all’ambiente del sistema, non soltanto eseguendo la suite.
Progettare una pipeline di accettazione, non una fabbrica di patch
Affida agli agenti compiti circoscritti, con criteri di accettazione e file sensibili dichiarati. Pretendi diff piccoli, una spiegazione delle decisioni, test legati ai requisiti e l’elenco dei controlli eseguiti. La CI dovrebbe segnalare modifiche a workflow, soglie di copertura, dipendenze, migrazioni e asserzioni; sulle aree critiche serve un approvatore competente e indipendente.
Misura tempo alla patch accettata, cicli di rework, difetti sfuggiti e carico di review, non il solo numero di pull request o di test verdi. Un coding agent crea valore quando riduce il lavoro totale fino a una modifica manutenibile; se sposta il costo sul revisore o sul prossimo incidente, la velocità osservata è soltanto apparente.