SWE-bench Verified è stato, per circa un anno e mezzo, il riferimento più citato per stimare quanto un modello fosse in grado di risolvere issue reali su repository Python: si parte dal testo di un issue e dallo stato del repo prima della fix, il modello produce una patch e “passa” solo se l’intera suite di test va in verde. OpenAI lo aveva pubblicato nell’agosto 2024 come sottoinsieme curato di SWE-bench, con l’obiettivo di rimuovere casi intrinsecamente ambigui o tecnicamente impossibili da chiudere con i soli indizi presenti nella descrizione del problema.
Nel febbraio 2026 OpenAI dichiara però che, ai livelli di performance attuali, SWE-bench Verified ha perso la capacità di discriminare miglioramenti reali. I punteggi si muovono ancora (da 74,9% a 80,9% in sei mesi), ma la correlazione con la qualità effettiva del lavoro “da ingegnere” in scenari non viziati si indebolisce. Il benchmark diventa sempre più sensibile a fattori estranei: qualità dei test e memoria di training.
Indice degli argomenti:
Il primo problema: test che respingono fix corrette
OpenAI ha auditato 138 task che il modello o3 non risolveva in modo consistente su 64 run. In questa revisione, ogni caso è stato letto da più ingegneri (almeno sei) e ri-verificato quando emergevano criticità. Il risultato è netto: nel campione esaminato, il 59,4% dei task presenta problemi “materiali” di test design e/o di descrizione, tali da renderli estremamente difficili o, in pratica, non risolvibili in modo affidabile anche per un umano competente.
Il punto non è che manchino test, ma che i test sono costruiti male rispetto al contratto implicito del benchmark.
Test troppo stretti
Una parte rilevante (35,5%) ricade in test troppo “stretti”: vincolano dettagli implementativi non necessari, bocciando soluzioni che rispettano il comportamento desiderato.
L’esempio citato da OpenAI (pylint-dev__pylint-4551) è tipico: la suite importa una funzione con un nome specifico che non è richiesto nella descrizione, quindi un fix corretto dal punto di vista funzionale può fallire per un semplice ImportError.
Test troppo larghi
Un altro blocco (18,8%) riguarda test troppo “larghi”: verificano anche funzionalità aggiuntive non presenti nella descrizione del problema. Qui il modello può implementare in modo corretto quanto richiesto, ma fallire perché la pull request originale risolveva più issue insieme e i test coprono l’intero pacchetto, mentre il task di benchmark descrive solo una parte (esempio: sympy__sympy-18199).
Questi due pattern portano a una conseguenza pratica: quando il margine di errore residuo è piccolo, il punteggio inizia a misurare quanto spesso un sistema indovina dettagli non dichiarati, invece di misurare la capacità di diagnosi, modifica del codice e rispetto dei vincoli di regressione.
Il secondo problema: contaminazione e training sul “gold patch”
Il secondo tema è più delicato, perché tocca l’affidabilità comparativa tra laboratori. SWE-bench (e quindi Verified) nasce da repository open source; quelle stesse basi di codice, le issue e spesso le patch sono presenti nel materiale che molti provider usano per addestrare modelli e strumenti di code completion. OpenAI riporta evidenze in cui modelli di diversi fornitori riproducono porzioni del “gold patch” (la patch umana di riferimento) o dettagli del task in modo pressoché verbatim.
In altre parole: parte del dataset è entrata, direttamente o indirettamente, nel “corpo” dei modelli. A quel punto, la valutazione perde la proprietà più importante di un benchmark: misurare generalizzazione su istanze non viste.
OpenAI sostiene di aver trovato segnali che l’esposizione in training aumenta la probabilità di successo, anche perché molti task hanno test sottospecificati: se sai già quale dettaglio implementativo “piace” ai test, hai un vantaggio. Da qui la decisione di smettere di riportare pubblicamente i risultati su SWE-bench Verified e di invitare anche gli altri a fare lo stesso.
Cosa cambia per chi usa i benchmark per decisioni reali
La reazione più comune, in questi casi, è liquidare la vicenda come una disputa accademica sui dataset. In realtà l’impatto è operativo: molte aziende e molti team di prodotto usano SWE-bench Verified per scegliere modelli, per impostare KPI interni o per giustificare investimenti in agenti di coding. Se il numero inizia a correlare con la “familiarità” del modello con quel tipo di materiale, il rischio è di prendere decisioni su un segnale distorto.
Dal lato dei vendor, il problema è reputazionale: quando un indicatore diventa un obiettivo pubblico, l’ecosistema tende a ottimizzarlo. Il risultato è una gara che produce progressi misurabili sul benchmark e molto più difficili da ritrovare in backlog veri, con codebase private, vincoli organizzativi e test non scritti “per il benchmark”.
Perché OpenAI spinge su SWE-bench Pro
In assenza di alternative immediatamente “private” e incontaminate, OpenAI raccomanda di usare SWE-bench Pro (in particolare lo split pubblico) come riferimento temporaneo. Il punto non è che Pro sia immune, ma che, per quanto osservato da OpenAI, la contaminazione sarebbe meno frequente e meno grave; nel loro setup nessun modello avrebbe ricostruito per intero un gold patch in modo verbatim come accade in Verified.
Per chi legge report di benchmark, l’indicazione pratica è semplice: considerare SWE-bench Pro come metrica primaria, e trattare SWE-bench Verified come un dato storico, utile per retrospettive ma meno adatto a misurare progressi marginali nel 2026.
Indicazioni pratiche per chi valuta agenti di coding in azienda
1) Separare “qualità del modello” da “qualità del sistema”. I risultati su benchmark pubblici tendono a premiare scaffolding, toolchain e retrieval. Se state valutando un agente, fissate esplicitamente cosa è dentro lo stack (IDE, strumenti di ricerca, accesso a doc, log, test runner, policy di write).
2) Portare la valutazione su artefatti proprietari. Bastano 20–50 issue reali del vostro backlog, scelte con criteri ripetibili (tipologia, criticità, area del codice, copertura test). Il valore sta nella stabilità del set nel tempo e nella tracciabilità degli errori, più che nel numero assoluto.
3) Audit dei test e dei task. L’analisi di OpenAI ricorda che un benchmark è un sistema socio-tecnico: se test e descrizioni sono incoerenti, state misurando la cosa sbagliata. Prima di attribuire un “fallimento” al modello, verificate se il contratto del task è chiaro e se la suite di test non forza dettagli arbitrarî.
4) Misurare anche costi e failure mode. Oltre a “pass/fail”, tracciate tempo, numero di iterazioni, patch size, regressioni introdotte, e soprattutto il tipo di errore (hallucinated API, misunderstanding del requisito, rottura di backward compatibility). Sono metriche più vicine alla realtà di engineering.
5) Stabilire un protocollo anti-contaminazione. Se usate esempi pubblici per training interno o fine-tuning, tenete separati in modo rigoroso i set di valutazione. A livello organizzativo vale la stessa regola dei test scolastici: ciò che entra nei materiali di preparazione non deve essere riusato come esame.
Uno sguardo più ampio: cosa ci insegna questa storia
Il tema non riguarda solo SWE-bench. Ogni benchmark basato su materiale pubblico, specie quando diventa “lingua franca” nelle release note, tende a collidere con le dinamiche di training e con la pressione a mostrare progressi. Questo non invalida i benchmark; spinge però verso due direzioni: più cura nella progettazione dei test (né troppo stretti né troppo larghi) e più investimenti in valutazioni private, create ad hoc, costose ma meno aggirabili.
OpenAI cita, tra gli approcci futuri, task “privatamente authored” e grading più olistico da parte di reviewer addestrati. È una strada onerosa, ma coerente con il fatto che, per i modelli di frontiera, l’ultimo 10% di “pass rate” spesso non è un problema di generazione di codice, ma di allineamento tra requisiti, test e contesto.
