Un punteggio di benchmark non è una recensione del modello

Due punti di vantaggio in un benchmark di programmazione non significano che due modelli lavoreranno quasi allo stesso modo in un repository reale. Il punteggio riguarda un insieme di task, una configurazione dell’agente e una regola di valutazione. Non dice quanta supervisione serve a ciascun modello, quanto costano i suoi fallimenti o se accetterei la sua pull request.

DeepSWE offre un buon esempio. Luna Max raggiunge il 67,2% e Sol High il 69,4%, anche se il costo mostrato per Luna è circa un sesto [2]. Questo riepilogo fa sembrare Luna la scelta ovvia. In pratica, però, tassi di successo simili possono nascondere grandi differenze nel tempo che dedico a guidare il modello, controllare le sue ipotesi e riparare il suo lavoro.

Gli sviluppatori a volte chiamano questa differenza “big model smell”: la sensazione che un modello più capace capisca il lavoro con meno spiegazioni e prenda meno decisioni da annullare in seguito. L’espressione è informale, ma l’esperienza che descrive si può verificare. Posso contare quante volte devo reindirizzare il modello, riparare il suo lavoro o rifiutare una patch che ha superato i test.

Che cosa misurano davvero il 67% e il 69%?

Nei dati DeepSWE v1.1 di Datacurve, Luna Max ha superato 301 tentativi su 448 e Sol High 313 su 451 [1] [2]. Questi totali producono i punteggi del 67,2% e del 69,4%. Mostrano un divario di 2,2 punti percentuali in questo test, ma non che i modelli lavorino allo stesso modo nell’uso quotidiano.

DeepSWE mantiene costanti diverse variabili importanti. I suoi 113 task provengono da 91 repository open source e coprono TypeScript, Go, Python, JavaScript e Rust [1]. Sono stati scritti per questa valutazione invece di essere copiati da vecchie issue di GitHub. Tutti i modelli hanno inoltre usato mini-swe-agent con lo stesso strumento bash e lo stesso prompt di base [5], mentre un container nuovo ha controllato ogni patch per il comportamento richiesto e le regressioni.

Questi controlli rendono utile il confronto, ma il risultato mantiene un margine di incertezza. Datacurve assegna a Luna un intervallo del 95% tra il 63,2% e il 71,2%, mentre quello di Sol va dal 68,0% al 70,8% [2]. Gli intervalli si sovrappongono, quindi il divario di 2,2 punti è inferiore alla variazione osservata tra le esecuzioni. Datacurve non pubblica un confronto statistico dei due modelli sugli stessi task, perciò i dati non dimostrano che il vantaggio di 2,2 punti di Sol sia ripetibile.

Le due configurazioni usano anche livelli di effort diversi: max per Luna e high per Sol. La classifica cambia con la misura empirica Pass@4 di Datacurve, che verifica se almeno uno dei tentativi registrati ha risolto ciascun task. Con questa misura, Luna copre il 90,3% dei 113 task e Sol l’86,7% [2]. Il successo per tentativo favorisce Sol, mentre la copertura dei task favorisce Luna, perché le due misure rispondono a domande diverse.

Misurazione	Luna Max	Sol High
Successo per tentativo, %	67,2	69,4
Intervallo del 95% tra esecuzioni	63,2–71,2%	68,0–70,8%
Tentativi valutati	448	451
Task con ≥1 successo, %	90,3 (Valore migliore della riga)	86,7
Costo medio per tentativo, $	0,61 (Valore migliore della riga)	3,47
Token di output per tentativo, migliaia	73,4	28,5 (Valore migliore della riga)
Passaggi dell'agente per tentativo	101,7	36,9 (Valore migliore della riga)

Il confronto completo mi dà un motivo per provare entrambi i modelli, ma non per considerarli equivalenti. Tutte le misure della figura 1 provengono dai task e dalla configurazione dell’agente di DeepSWE. Il mio repository potrebbe favorire altre qualità e mettere in luce altri fallimenti.

Perché due punteggi vicini possono sembrare così diversi?

Due modelli possono superare lo stesso numero di task e richiedere quantità di lavoro molto diverse allo sviluppatore. Osservo se il modello trova i file corretti, rispetta il design esistente, fa una domanda prima di adottare un’ipotesi rischiosa, si riprende dopo un comando fallito e si ferma quando la modifica richiesta è finita. DeepSWE riduce il risultato finale a successo o fallimento e quindi non valuta separatamente questi comportamenti.

I dati grezzi di DeepSWE forniscono un indizio. Luna Max ha usato in media 101,7 passaggi dell’agente e 73.400 token di output per tentativo, contro 36,9 passaggi e 28.450 token di Sol High [2]. Luna ha quindi utilizzato circa 2,8 volte più passaggi e 2,6 volte più token per raggiungere un tasso di successo simile. I dati non dicono se quei passaggi aggiuntivi siano stati utili, ma mostrano chiaramente che i modelli non hanno lavorato allo stesso modo.

Anche il costo mostrato richiede contesto. I trial di Luna sono stati eseguiti il 7 luglio, quando il consumo registrato dei token costava circa 3,03 dollari per tentativo [2] [3]. OpenAI ha ridotto i prezzi dei token di Luna dell’80% il 30 luglio [4], e DeepSWE ha ricalcolato il vecchio consumo con la nuova tariffa. È così che 3,03 dollari sono diventati gli 0,61 dollari mostrati. La cifra più bassa stima correttamente il costo attuale dello stesso consumo, ma non la somma pagata da Datacurve quando ha eseguito il test.

Il costo API per tentativo è anche diverso dal costo necessario per ottenere una modifica accettata. Il prezzo della leaderboard esclude nuovi tentativi, tempo di revisione, modifiche manuali, attese ed eventuali secondi modelli usati per controllare o riparare il lavoro del primo. Un tentativo può costare un sesto e risultare comunque più caro nel complesso se l’ingegnere deve supervisionare ogni decisione.

Queste differenze nel lavoro sono ciò che l’espressione “big model smell” cerca di descrivere. Le domande utili sono concrete: il modello ha tenuto presenti tutti i vincoli? Ha preso decisioni sensate per questo repository? Ha evitato modifiche non correlate, espresso chiaramente l’incertezza e fallito in un modo facile da riconoscere e annullare? Un singolo tasso di successo non può rispondere a nessuna di queste domande.

Quanto può influire la configurazione sul punteggio?

Un benchmark di programmazione valuta un sistema completo, non solo il modello. Il prompt, gli strumenti, la gestione del contesto, i limiti di esecuzione, il numero di tentativi e il valutatore influenzano tutti il risultato. Cambiarne uno può spostare il punteggio anche quando il modello resta esattamente lo stesso.

Il paper di SWE-agent pubblicato a NeurIPS offre un esempio controllato. Con lo stesso GPT-4 Turbo su SWE-bench Lite, un’interfaccia limitata alla shell ha risolto l’11% dei task, mentre l’interfaccia completa di SWE-agent ne ha risolti il 18% [6]. Quando i ricercatori hanno sostituito i risultati di ricerca ripetuti con uno strumento che li riassumeva, il punteggio è salito dal 12% al 18%. Limitare il visualizzatore a 100 righe invece di restituire tutto il file lo ha spostato dal 12,7% al 18%. Queste modifiche all’interfaccia hanno aggiunto da cinque a sette punti percentuali senza cambiare il modello.

Il numero di tentativi può cambiare ancora di più il dato messo in evidenza. Sei esecuzioni della stessa combinazione di GPT-4 e SWE-agent hanno raggiunto una media del 17,94% al primo tentativo. Contando un task come risolto quando almeno uno dei sei tentativi passava, la copertura saliva al 32,67% [6]. L’aumento di 14,73 punti è utile se un sistema di produzione genera davvero sei candidati e sa identificare quello corretto. Diventa fuorviante se appare accanto a un risultato a tentativo singolo senza un’etichetta chiara.

Anche l’infrastruttura aggiunge rumore. Anthropic ha mantenuto costanti il modello Claude, l’harness e i task di Terminal-Bench 2.0, cambiando solo i limiti di CPU, memoria e durata. La configurazione senza limiti rigidi ha ottenuto circa sei punti percentuali in più, mentre gli errori dell’infrastruttura sono scesi dal 5,8% allo 0,5% [7]. Per questo ogni riga di una leaderboard va letta come il risultato di un sistema testato, non come un numero permanente legato al nome del modello.

Modifica al sistema	Prima	Dopo	Variazione
Solo shell → interfaccia SWE-agent	11,0%	18,0%	+7,0 pp
File intero → vista di 100 righe	12,7%	18,0%	+5,3 pp
Uno → sei tentativi	17,94%	32,67%	+14,73 pp
Limiti rigidi → senza limiti	Non pubblicato	Non pubblicato	circa +6 pp

Tutte e quattro le modifiche della figura 2 superano il divario di 2,2 punti tra Luna e Sol. Questo non rende inutili i benchmark, ma rende la configurazione parte del risultato. Prima di confrontare due punteggi, controllo quindi la versione dei task, la configurazione dell’agente, le risorse, il numero di tentativi e la regola di valutazione.

Perché una patch che supera i test può essere rifiutata?

Superare un benchmark significa che una patch ha superato i controlli del benchmark. È un’indicazione utile del fatto che il codice funziona, ma non è una code review. I controlli possono non vedere una soluzione incompleta e potrebbero non considerare la manutenibilità, l’architettura esistente, le modifiche non correlate o il lavoro necessario prima del merge.

EvalPlus ha mostrato quanto i test scelti possano influenzare il risultato. I ricercatori hanno aumentato di circa 80 volte le suite di test di HumanEval e valutato 26 modelli. Con i test più severi, i tassi di successo dei modelli più colpiti sono diminuiti da 19,3 a 28,9 punti percentuali e alcune classifiche si sono invertite [8]. Le risposte non erano cambiate; le suite più grandi hanno semplicemente rilevato più errori.

I benchmark basati sui repository hanno lo stesso problema. Nel febbraio 2026, OpenAI ha controllato 138 task di SWE-bench Verified che o3 falliva in modo discontinuo in 64 esecuzioni. Ha trovato problemi rilevanti nel 59,4% del gruppo selezionato, inclusi test che rifiutavano soluzioni valide e test che richiedevano comportamenti non menzionati nella issue [9]. L’audit ha cercato intenzionalmente task sospetti, quindi il 59,4% non descrive tutti i 500 task. Mostra comunque che errori nei task e nei test possono distorcere le differenze tra modelli molto capaci.

Il problema opposto conta allo stesso modo: una patch può superare i test automatici e non essere pronta al merge. METR ha chiesto ai maintainer di esaminare 296 pull request generate dall’IA in tre repository e 95 task. Il loro tasso di accettazione era inferiore di 24,2 punti percentuali rispetto al punteggio automatizzato di SWE-bench [10]. Hanno rifiutato patch per difetti nella funzione principale, rotture non correlate, scarsa qualità del codice e altri problemi di integrazione. Un punteggio binario nasconde tutte queste ragioni dietro la stessa etichetta di successo o fallimento.

più test in EvalPlus

80×

alcune classifiche si sono invertite

problemi in un audit mirato

59,4%

non rappresentativo di tutti i 500 task

divario rispetto ai maintainer

24,2 pp

METR ha esaminato 296 pull request

Nel complesso, questi risultati mostrano che la qualità dei test e la revisione umana rispondono a domande diverse. “La patch ha superato i test” resta un’informazione utile, ma non mi dice se voglio che quel modello modifichi ogni giorno il mio branch.

Che cosa nasconde una media sull’affidabilità?

Un tasso medio combina tutti i successi e i fallimenti in un solo numero. Non mostra se il modello riesce con costanza, se la sua affidabilità crolla nei task lunghi o se un’esecuzione fallita produce un piccolo diff sbagliato o danneggia lo stato di lavoro. Queste differenze contano quando uso il modello più volte invece di provarlo una sola volta.

Il paper di tau-bench rende visibile la ripetibilità con pass^k, che verifica se un agente risolve lo stesso task ogni volta in più prove. GPT-4o ha ottenuto il 61,2% nei task retail guardando una sola prova, ma il suo pass^8 retail è sceso sotto il 25% [11]. Un modello che funziona tre volte e fallisce la quarta può mantenere una media rispettabile. Come collaboratore quotidiano, sembra imprevedibile.

La lunghezza del task crea una separazione simile. METR ha valutato gli agenti su 170 task con circa otto esecuzioni per coppia modello-task. La durata in cui un modello riusciva nell’80% dei casi era da quattro a sei volte più breve rispetto al suo orizzonte di successo al 50% [12]. Un modello può quindi ottenere credito su task notevoli da due ore alla soglia del 50%, pur restando affidabile solo su lavori molto più brevi.

Questo spiega perché le impressioni pratiche possono contraddire una leaderboard. L’uso quotidiano include task ripetuti, contesto del repository facile da ignorare, comandi non funzionanti, requisiti ambigui, cicli di review e le conseguenze dei peggiori tentativi falliti. Anche le impressioni personali possono essere sbagliate, perché una risposta ben presentata o un unico fallimento disastroso possono dominare la memoria. Invece di scegliere tra benchmark e intuizione, devo misurare le parti del mio flusso di lavoro che hanno creato quell’impressione.

Come confronto i modelli per il mio lavoro?

Uso i benchmark pubblici come filtro. Mi dicono quali modelli meritano tempo e denaro per un test, e una valutazione controllata come DeepSWE offre molte più informazioni di una demo di lancio. La scelta finale arriva comunque da una piccola valutazione costruita sul mio lavoro.

Anthropic consiglia di iniziare con 20-50 task per agenti ricavati da controlli manuali, fallimenti comuni, bug report e richieste di sviluppo già incontrate [13]. Sono sufficienti per individuare grandi incompatibilità senza fingere di produrre una leaderboard universale. Per un confronto ravvicinato, eseguirei gli stessi task più volte mantenendo fissi ambiente, strumenti, prompt, livello di effort e budget.

Prima di vedere gli output, definirei cosa significa accettare il risultato. I test vengono prima, ma non sono l’intera griglia. Registrerei anche:

• accettazione al primo tentativo;
• tempo totale per ottenere un risultato accettato, inclusi revisione e riparazione;
• minuti di review attiva separati dalla latenza del modello;
• chiarimenti, correzioni di rotta, riavvii e modifiche manuali;
• file cambiati senza motivo e violazioni delle convenzioni del repository;
• fallimenti gravi come regressioni di sicurezza, rischi di perdita dati o rotture non correlate;
• token e costo API dell’intero risultato accettato.

Per la qualità del codice, nasconderei i nomi dei modelli e valuterei le patch concorrenti in ordine casuale quando possibile. Pubblicherei i risultati per tipo di task invece di combinare bug fix, review, refactoring e feature lunghe in un unico totale. Se due modelli restano vicini dopo più prove, sceglierei quello economico. Se il suo maggiore costo di review consuma il risparmio API, però, non è il modello più economico per il mio flusso.

Il risultato DeepSWE offre un buon motivo per provare seriamente Luna Max. Il suo tasso di successo rientra nell’incertezza attorno a Sol High e il suo prezzo API attuale è molto più basso. Questo non rende i modelli intercambiabili. Per decidere quale sia più economico e migliore per il mio lavoro, devo contare anche la guida, la revisione, le riparazioni e le esecuzioni fallite che la leaderboard esclude.