Cosa misurano SWE-bench e i benchmark di programmazione?

Cos’è SWE-bench e come si calcola il punteggio?

Un benchmark di programmazione è un elenco fisso di compiti più una regola di valutazione. Il modello o l’agente di programmazione risolve i compiti, la regola segna ogni soluzione come superata o no, e il punteggio è la percentuale di quelle superate. Questo articolo parte dal benchmark di cui si parla di più, SWE-bench, e poi legge gli altri con le stesse quattro domande. La struttura che sta intorno al modello (l’harness) l’abbiamo descritta nell’articolo sull’harness engineering, le valutazioni assegnate da un modello giudice nell’articolo su LLM-as-a-judge.

SWE-bench è un benchmark costruito con issue reali di GitHub. Secondo la sua pagina, la prima versione è uscita a ottobre 2023 e conta 2.294 compiti raccolti da issue e pull request di 12 repository Python popolari. Ogni compito nasce da una pull request che ha chiuso una issue e ha modificato anche dei file di test.

La valutazione funziona così: il modello riceve il testo della issue e il repository com’era prima della pull request, e modifica il codice. Quando il modello ha finito, girano due gruppi di test:

• FAIL_TO_PASS: test che fallivano prima della pull request e passano dopo. Dimostrano che la issue è davvero risolta.
• PASS_TO_PASS: test che devono passare sia prima sia dopo. Dimostrano che la modifica non ha rotto nulla di ciò che già funzionava.

Se passano entrambi i gruppi, il compito conta come risolto. Il punteggio è la percentuale di compiti risolti; nelle classifiche compare come «% Resolved».

Oggi SWE-bench non è un solo set ma una famiglia. I numeri della tabella li abbiamo letti il 20 ottobre 2026 sulla pagina di ciascun set:

Fonte: la pagina di SWE-bench, l’annuncio di Multilingual e la pagina di SWE-bench Pro di Scale AI, 20 ottobre 2026. I risultati del set privato di Pro sono pubblicati in una classifica a parte.

Quando si legge la classifica conta un altro dettaglio. La pagina di Verified scrive che la classifica mette nella stessa lista sistemi di programmazione di ogni tipo, dai semplici cicli di agente ai sistemi che fanno più tentativi. Per confrontare i modelli tra loro c’è una vista a parte, «Bash Only»: lì ogni modello gira con lo stesso piccolo agente (mini-SWE-agent) e con una sola shell bash.

Perché SWE-bench Verified non basta più?

Verified è uscito con OpenAI ad agosto 2024. Secondo Epoch AI, i suoi 500 compiti sono stati scelti tra i 2.294 del set originale con la revisione indipendente di tre esperti, per scartare i compiti che avevano problemi.

Il 3 settembre Epoch ha riesaminato Verified e lo ha giudicato «difettoso» (Flawed). Le ragioni che dà sono tre:

• I test rifiutano soluzioni corrette. In una verifica pubblicata il 23 febbraio 2026, OpenAI ha guardato i compiti che i modelli spesso non riescono a risolvere. Ne ha esaminato il 27,6% e ha trovato che nel 59,4% di questi il test rifiutava una soluzione che funzionava correttamente. Secondo Epoch, questo vuol dire che almeno il 16,4% di tutti i compiti è rotto. L’asticella di Epoch è che un difetto del genere riguardi meno del 20% delle domande.
• I compiti sono finiti nei dati di addestramento. Verified è un set fisso; tutti i compiti e tutte le soluzioni sono pubblici. Secondo la verifica di OpenAI, tutti i modelli di frontiera testati avevano visto durante l’addestramento almeno una parte di questi problemi e delle loro soluzioni. La conclusione di OpenAI: i progressi su Verified non mostrano più una vera capacità di sviluppo software, ma quanto di questo benchmark il modello ha visto durante l’addestramento.
• Il punteggio si può aggirare. Il team RDI di Berkeley ha trovato un reward hack che porta al punteggio pieno.

I produttori di modelli si sono comportati di conseguenza. Secondo l’articolo di Cursor, OpenAI ha smesso del tutto di pubblicare risultati su Verified dopo aver visto che i modelli di frontiera riuscivano a riprodurre a memoria le soluzioni di riferimento. La system card di Opus 5 di Anthropic, del 24 luglio, riportava ancora Verified: 96,0%, la media di cinque prove. Nella card di Opus 5.5, del 22 settembre, Verified non c’è; ci sono solo Pro, Multilingual e Multimodal. Nell’annuncio dello stesso modello Anthropic scrive anche che, a questo livello di capacità, i distacchi nei benchmark indicano in modo meno affidabile le differenze nell’uso reale.

Un benchmark in cui tutti sono vicini al tetto non riesce più a distinguere i modelli. Lo vede anche chi costruisce i benchmark. Aider ha sostituito il suo vecchio benchmark di editing con un set più difficile quando i punteggi hanno superato l’80%. Terminal-Bench 4.0 ha considerato «saturi» i compiti che tutti i modelli più recenti risolvevano 5 volte su 5, e li ha tolti dal set. Anche la pagina di DeepSWE scrive che i modelli di testa si affollano in una fascia di punteggi stretta e che gli intervalli di confidenza di configurazioni vicine spesso si sovrappongono.

Nella stessa settimana Epoch ha dato lo stesso giudizio su altri due benchmark di programmazione. Giudica un benchmark «difettoso» quando i difetti possono incidere sul 20% del punteggio o più:

Fonte: le revisioni di Epoch AI. Per Verified, Epoch si basa sulla verifica di OpenAI. I compiti di Terminal-Bench vengono dalla comunità; Epoch ha contato i problemi segnalati pubblicamente nel suo repository. Per BFCL ha preso un campione casuale da 5.088 elementi.

Ecco come si presenta un difetto, con un esempio da BFCL. Nel compito «What is the current time in Sydney, Australia?» il modello riceve una funzione chiamata get_local_time(location). La chiave delle risposte segna il compito come «irrilevante». Prende il punteggio pieno solo un modello che non chiama nessuna funzione; un modello che chiama la funzione nel modo giusto prende zero.

Cosa misurano gli altri benchmark di programmazione?

SWE-bench guarda un solo tipo di lavoro: una patch che chiude una issue in un repository. Quello che ci si aspetta da un agente di programmazione è più ampio, quindi ogni benchmark ne misura una parte diversa. Le informazioni della tabella le abbiamo lette il 20 ottobre 2026 sulla pagina di ciascun benchmark:

Fonte: la pagina o l’annuncio di ciascun benchmark, 20 ottobre 2026. «La sua pagina non lo dice»: nella pagina che abbiamo letto quel giorno non abbiamo trovato una frase che lo dica. I giudizi di Cognition e di Cursor vengono dagli articoli in cui presentano i propri benchmark.

Nemmeno le classifiche sono tutte aggiornate allo stesso modo. La classifica di Aider è stata aggiornata l’ultima volta il 20 novembre 2025, quella di BFCL il 12 aprile 2026. La versione più recente nel repository di LiveCodeBench (release_v6) copre 1.055 problemi pubblicati tra maggio 2023 e aprile 2025. Se un modello manca da una classifica del genere, può voler dire che la classifica è vecchia, non che il modello è scarso.

Il nome più vecchio che non è nella lista è HumanEval: un set che OpenAI ha pubblicato nel 2021 e che fa scrivere codice a partire da una docstring. Il suo repository oggi è segnato come «Deprecated and unmaintained». Il team di LiveCodeBench ha anche trovato che alcuni modelli che vanno bene su HumanEval potrebbero essersi adattati troppo a quel set.

Anche gli strumenti di code review hanno i loro benchmark. GitHub ha pubblicato ReviewBench il 5 ottobre; lì un modello giudice decide se un commento è un rilievo corretto, e GitHub ha pubblicato anche il prompt del giudice. Come leggere un benchmark valutato da un modello giudice l’abbiamo spiegato nell’articolo su LLM-as-a-judge.

Il codice che passa i test arriva al merge?

Il punteggio di SWE-bench viene da un valutatore automatico: se i test passano, il compito conta come risolto. In uno studio pubblicato il 10 marzo 2026, METR ha misurato quanto quel numero corrisponda alla review di un vero maintainer. 4 maintainer attivi di 3 repository di Verified (scikit-learn, Sphinx, pytest) hanno letto in tutto 296 PR scritte da un’IA come in una vera review, e hanno deciso se ne avrebbero fatto il merge. Non sapevano chi avesse scritto la PR.

Il risultato: i maintainer non avrebbero fatto il merge di circa metà delle PR che passavano i test. Siccome la decisione di un maintainer può cambiare da persona a persona, METR ha fatto leggere agli stessi maintainer anche PR umane davvero arrivate al merge nel repository; ne hanno approvato circa il 68%. Con i punteggi riportati a questa base, il valutatore automatico sta in media 24,2 punti sopra la decisione dei maintainer. Senza questa scala, la distanza è di 34,9 punti.

I maintainer hanno rifiutato per tre tipi di motivi: la modifica non risolve davvero il problema, tocca codice estraneo e lo rompe, oppure il codice non rispetta gli standard del repository. METR dichiara apertamente anche i propri limiti: gli agenti non hanno avuto modo di correggere il lavoro dopo un feedback, e lo studio ha guardato una parte di un solo benchmark e un solo agente. Quindi il risultato non dice che i modelli non sappiano farlo. Dice un’altra cosa: letto da solo, un punteggio fa sembrare un agente più utile di quanto sia.

FrontierCode è un benchmark che porta queste domande dentro il punteggio. Cognition ha preparato 150 compiti con i maintainer di 36 repository open source; in ogni repository sono stati i maintainer a fissare i criteri perché una modifica conti come pronta per il merge. Accanto ai test unitari c’è un controllo del perimetro: la modifica tocca solo i file consentiti? Il diff supera una certa dimensione? Anche i test che scrive l’agente vengono eseguiti sul vecchio codice, quello rotto; un test che lì non fallisce non verifica niente.

Il rapporto di Anthropic stessa mostra l’effetto della penalità sul perimetro. Secondo la system card di Opus 5, ai livelli di effort sopra high il modello ha fatto più modifiche di quelle richieste dal compito, e il suo punteggio su FrontierCode è sceso. Quando al prompt è stata aggiunta una breve istruzione che gli chiedeva di restare nel perimetro del compito, il punteggio è tornato su nella maggior parte di quei compiti. È un risultato che il fornitore riporta per Opus 5; la card non dice quanti punti siano tornati.

È proprio in questo divario che lavora la code review: il test dimostra che la modifica produce il comportamento richiesto; la review chiede se quella modifica deve stare lì. In diffox questa domanda la fanno agenti specializzati. Uno confronta le righe modificate, una regola alla volta, con le regole del file delle regole del repository (AGENTS.md, CLAUDE.md); una regola che non è scritta nel file non conta. Un altro cerca un test che non verifica quello che dice il suo nome, o un’asserzione che non può mai fallire; un test mancante, invece, per lui non è un rilievo. Come capire se un test verifica davvero qualcosa l’abbiamo spiegato nell’articolo sulla review del codice generato dall’IA.

Come si legge il punteggio di un benchmark?

Quando trovi un punteggio, fai queste sei domande. Se due punteggi differiscono anche su una sola di esse, non misurano più la stessa cosa:

1. Quale set o sottoinsieme? «SWE-bench» da solo non dice niente: Verified, il set pubblico di Pro e un sottoinsieme scelto da un’azienda sono numeri diversi. La documentazione di Anthropic scrive che i punteggi sul sottoinsieme di 482 problemi che Anthropic ha scelto da Pro non sono confrontabili con la classifica pubblica. Non lo sono nemmeno con i risultati di Pro nella system card della stessa azienda, perché quelli sono stati misurati su un altro insieme di problemi e con max effort.
2. Dentro quale agente? Un punteggio non appartiene al modello, ma alla coppia formata dal modello e dall’agente che lo esegue. Secondo Epoch, i risultati su Verified dipendono molto dall’agente usato; nella classifica di Terminal-Bench ogni riga è un modello e un agente. Anche sullo stesso benchmark le impostazioni possono cambiare: Epoch ha notato che su Terminal-Bench le voci di Codex ritentano i rifiuti per sicurezza, mentre l’impostazione predefinita no. Anche Artificial Analysis scrive che i suoi risultati appartengono a configurazioni precise e non a nomi di prodotto, e che il modello, le impostazioni e il modo di eseguirlo possono cambiare sensibilmente il risultato. Epoch conta inoltre una cattiva gestione del contesto da parte dell’agente come un problema di allestimento che abbassa il punteggio; cosa fanno gli agenti di programmazione quando il contesto è pieno l’abbiamo spiegato nell’articolo sull’auto-compact.
3. A quale livello di effort? Le classifiche spesso mostrano un modello al livello in cui va meglio. I risultati nell’annuncio di Opus 5.5 di Anthropic sono stati misurati con max effort, salvo indicazione diversa; la riga di Terminal-Bench è al livello che ha dato a ciascun modello il punteggio più alto. Anche FrontierCode esegue ogni modello 5 volte a ogni livello di effort e riporta il livello migliore. Se usi lo strumento al livello predefinito, potresti non vedere il risultato della tabella.
4. Quante esecuzioni, quanta incertezza? La stessa configurazione può dare punteggi diversi in due esecuzioni. La classifica di Terminal-Bench mostra la media di 5 esecuzioni con un intervallo di confidenza al 95%; Epoch consiglia almeno 5 esecuzioni per modello per le barre d’errore. Una differenza che non supera il rumore non è una differenza; il rumore tra due esecuzioni nelle nostre misure l’abbiamo descritto nell’articolo su LLM-as-a-judge.
5. Chi ha misurato? La tabella di un produttore di modelli è misurata in condizioni scelte da lui. Le misure indipendenti cercano di far girare ogni modello con le stesse regole: DeepSWE fa girare tutti i modelli con lo stesso piccolo agente. In entrambi i casi guarda i dettagli: Artificial Analysis lascia finire un altro modello quando un modello rifiuta un compito, e conta anche quel tentativo; Anthropic scrive a sua volta che, quando sono intervenute le sue protezioni di sicurezza, altri modelli hanno completato una parte dei compiti di Opus 5.5.
6. Il set è saturo, contaminato, aggiornato? Un set in cui tutti sono vicini al tetto non distingue i modelli; un set con compiti e soluzioni pubblici può misurare anche la memoria. Guarda la data di pubblicazione dei compiti (LiveCodeBench la conserva per ogni problema), chiedi se il set ha una parte chiusa e controlla quando la classifica è stata aggiornata l’ultima volta.

Un esempio che mostra l’effetto dell’effort sullo stesso modello e sugli stessi compiti si trova nel documento di Anthropic su costo e intelligenza. L’unica cosa che cambia è il livello di effort:

Sullo stesso modello, cambiando solo l’effort, il punteggio si sposta di 9,3 punti, e il costo per compito sale da $0,11 a $0,74. In una tabella che confronta due modelli, guarda prima a quale livello è stato misurato ciascuno: se uno è stato misurato a max e l’altro al suo livello predefinito, la differenza può venire dall’impostazione e non dal modello.

Quale benchmark guardare per quale lavoro?

Scegliere un benchmark vuol dire scegliere cosa vuoi dall’agente. La tabella qui sotto abbina lavori comuni al benchmark che più gli si avvicina:

Fonte: le tabelle di questo articolo e la pagina di ciascun benchmark, 20 ottobre 2026.

Nessuno di questi sostituisce il lavoro nel tuo repository. Anche la documentazione di Anthropic consiglia di provare l’impostazione di effort sul tuo carico di lavoro. La misura più affidabile è eseguire più volte alcuni compiti reali del tuo repository, con lo stesso agente e allo stesso livello di effort.

Nessuno di questi misura nemmeno se una modifica dovrebbe arrivare al merge. FrontierCode è quello che ci va più vicino, ma anche lì decidono criteri che i maintainer hanno scritto in anticipo. Nel tuo repository quella decisione la prende la review.

Domande frequenti

Cos’è SWE-bench?

SWE-bench è un benchmark che misura se i modelli di IA e gli agenti di programmazione sanno risolvere issue reali di GitHub. Il modello riceve il testo della issue e il repository com’era in quel momento, e modifica il codice. Se la modifica passa i test FAIL_TO_PASS, che dimostrano che la issue è risolta, e i test PASS_TO_PASS, che dimostrano che non si è rotto nulla, il compito conta come risolto. La prima versione contiene 2.294 compiti da 12 repository Python; esistono sottoinsiemi e set affini come Verified, Pro e Multilingual.

Che differenza c’è tra SWE-bench Verified e SWE-bench Pro?

Verified è un sottoinsieme di 500 compiti del set originale rivisto da persone; compiti e soluzioni sono pubblici. Pro è il set più difficile di Scale AI, con 1.865 compiti da 41 repository: le soluzioni sono in media di 107,4 righe e 4,1 file. I compiti di Pro vengono da repository con licenza copyleft e dal codice chiuso di aziende, e i risultati di una parte non vengono mai pubblicati. Epoch AI ha giudicato Verified difettoso a settembre 2026; anche l’ultima model card di Anthropic riporta Pro al posto di Verified.

Qual è una buona percentuale su SWE-bench?

Non c’è una soglia unica. Un punteggio dipende dal set, dall’agente e dal livello di effort a cui appartiene: sul sottoinsieme di Anthropic lo stesso modello si sposta di 9,3 punti solo con il livello di effort, e Anthropic scrive che questi punteggi non sono confrontabili con la classifica pubblica. Confronta due punteggi solo se sono stati misurati sullo stesso set, con lo stesso agente e con impostazioni simili; non guardare un numero da solo, ma la sua distanza da altri modelli misurati nelle stesse condizioni.

Cosa misura Terminal-Bench?

Terminal-Bench misura se un agente sa portare a termine compiti da inizio a fine nel terminale: compiti di software, scienza, ML, operations, sicurezza, hardware e media. Ogni compito ha il suo verificatore. Con la versione 4.0 è diventato un benchmark aggiornato in continuo; toglie dal set i compiti saturi, quelli rifiutati e quelli la cui soluzione è diventata pubblica. La classifica mostra, per ogni coppia modello e agente, la media di 5 esecuzioni con un intervallo di confidenza al 95%. Il 4 settembre Epoch AI ha registrato un difetto di valutazione segnalato pubblicamente in 30 dei 66 compiti.

Che differenza c’è tra LiveCodeBench e SWE-bench?

LiveCodeBench usa problemi raccolti dalle gare di LeetCode, AtCoder e Codeforces per guardare la capacità di un modello di scrivere codice, correggere il proprio codice, eseguire codice e prevedere l’output di un test; un compito è un singolo problema. SWE-bench invece chiede una modifica che chiuda una issue reale in un repository. Siccome LiveCodeBench segna ogni problema con la sua data di pubblicazione, puoi misurare un modello su problemi usciti dopo la sua data limite di addestramento; così il modello non può aver visto la soluzione durante l’addestramento.

Quanto ci si può fidare del punteggio di un benchmark?

Un punteggio risponde alla domanda stretta che pone il benchmark. Prima di fidarti, controlla sei cose: quale set, quale agente, quale livello di effort, quante esecuzioni e quale intervallo di confidenza, chi ha misurato, e se il set è saturo o contaminato. Per questo contano le verifiche indipendenti: a settembre 2026 Epoch AI ha giudicato difettosi SWE-bench Verified, Terminal-Bench 4.0 e BFCL v4; METR ha misurato che circa metà delle PR di SWE-bench che passano i test non supererebbe la review dei maintainer.

Con quale benchmark si misura diffox?

diffox è uno strumento di code review con IA, quindi non si misura con benchmark di programmazione ma con benchmark di code review. Abbiamo eseguito noi stessi il benchmark open source di code review di Martian e pubblicato il risultato con le prove: ogni review è una pull request pubblica, la valutazione l’ha fatta il codice stesso del benchmark, e puoi ricostruire la tabella sulla tua macchina con i comandi del repository delle prove. Quell’articolo dice anche da quante esecuzioni viene ogni riga: l’esecuzione pubblica l’abbiamo fatta con l’impostazione di sensibilità Alta di allora, e le righe Media e Bassa sono la media di più esecuzioni interne.