DeepSWE: il benchmark che smonta le classifiche AI per il coding

Per mesi i benchmark di coding AI hanno raccontato una storia rassicurante ma imprecisa: i modelli migliori sono tutti più o meno equivalenti. La famiglia GPT-5 di OpenAI, Claude Opus di Anthropic e Gemini Pro di Google viaggiavano in una fascia ristretta su SWE-Bench Pro di Scale AI, rendendo quasi impossibile per i team di ingegneria capire quale agente funzionasse meglio nel loro codice. Lunedì una startup chiamata Datacurve ha pubblicato un benchmark che, a suo dire, distrugge quell’illusione.

DeepSWE è una valutazione di 113 task su 91 repository open source e 5 linguaggi di programmazione. Produce una distribuzione molto più ampia tra gli stessi modelli frontier e incorona GPT-5.5 di OpenAI come leader netto al 70%, sedici punti avanti rispetto al suo concorrente più vicino. “Sulle classifiche pubbliche i modelli migliori spesso appaiono vicini in capacità”, ha scritto su X Serena Ge, co-autrice di Datacurve. “DeepSWE mostra dove divergono realmente, riflettendo l’esperienza realistica degli sviluppatori nel loro lavoro quotidiano.”

Il benchmark include anche una critica puntuale all’infrastruttura di valutazione su cui l’industria dell’AI fa affidamento: l’audit di Datacurve ha scoperto che i verificatori di SWE-Bench Pro — i valutatori automatici che determinano se un agente ha risolto un task — emettevano verdetti errati su circa un terzo dei casi esaminati. Se la scoperta regge, le implicazioni sono enormi. I team di procurement aziendali, i venture capitalist e i dipartimenti marketing dei laboratori AI si basano pesantemente sui punteggi dei benchmark per decisioni da milioni di dollari. Un tasso di errore del 32% nel benchmark di coding più citato suggerisce che l’industria potrebbe aver navigato con una bussola rotta.

Perché il benchmark di coding più popolare potrebbe valutare male

Per capire cosa sostiene Datacurve, aiuta sapere come funzionano i benchmark di coding — e come possono andare storti. Il paradigma dominante, inaugurato dalla famiglia SWE-Bench mantenuta da Scale AI e da ricercatori accademici, costruisce task estraendo commit GitHub reali. Il processo estrae una correzione di bug o un’aggiunta di funzionalità dalla storia del repository, riporta il codice allo stato precedente la correzione, e chiede a un agente AI di riprodurre la modifica. La suite di test del commit originale funge da verificatore: se la patch dell’agente fa passare gli stessi test, ottiene il punteggio.

Questo approccio ha un’eleganza semplice, ma Datacurve sostiene che introduce tre debolezze sistemiche. Prima: contaminazione. Poiché i task sono tratti dalla storia pubblica di GitHub, il problema, la discussione e spesso la soluzione esatta sono già presenti nei dati di training dei modelli frontier. “La famiglia SWE-Bench estrae issue e PR esistenti da GitHub, creando due problemi: memorizzazione (i modelli hanno già visto la soluzione) e banalità (la maggior parte dei task è piccola)”, ha scritto Ge. Seconda: ampiezza. I task di SWE-Bench Pro richiedono in media solo 120 righe di codice aggiunte in 5 file. Le soluzioni di riferimento di DeepSWE richiedono in media 668 righe aggiunte in 7 file — circa 5,5 volte più codice. Tuttavia i prompt di DeepSWE sono più brevi, in media 2.158 caratteri contro i 4.614 di SWE-Bench Pro. DeepSWE dà meno istruzioni ma si aspetta molto più output, più simile a come uno sviluppatore umano delegherebbe il lavoro a un assistente AI. Terza, e più dannosa: affidabilità del verificatore. Datacurve ha estratto 30 task a caso sia da DeepSWE che da SWE-Bench Pro, eseguito tre roll-out su 10 configurazioni di modelli frontier, e usato un giudice basato su LLM per valutare indipendentemente se la patch di ogni agente risolvesse effettivamente il problema. I verificatori di SWE-Bench Pro accettavano implementazioni errate nell’8,5% dei casi e rifiutavano implementazioni corrette nel 24% dei casi. Quelli di DeepSWE registravano rispettivamente lo 0,3% e l’1,1%.

Il problema dei falsi negativi è particolarmente insidioso perché penalizza soluzioni creative. In un caso documentato, la pull request gold-standard per un task di SWE-Bench Pro rifattorizzava una funzione helper privata. Un agente che risolveva correttamente il task inlining la stessa logica — una scelta ingegneristica perfettamente valida — falliva perché la suite di test provava a importare un simbolo che esisteva solo nell’implementazione specifica dell’autore originale.

GPT-5.5 domina il nuovo benchmark, mentre Claude e Gemini inciampano

I risultati principali di DeepSWE riordinano la gerarchia familiare in modi che dovrebbero contare per ogni team di ingegneria che valuta strumenti di coding AI. Su SWE-Bench Pro i modelli di OpenAI, Anthropic e Google si sono scambiati il primato entro un intervallo del 30%. DeepSWE allunga quel range al 70%. GPT-5.5 è in testa al 70%, seguito da GPT-5.4 al 56% e Claude Opus 4.7 al 54%. Poi il calo è netto: Claude Sonnet 4.6 al 32%, Gemini 3.5 Flash al 28%, GPT-5.4-mini e Kimi K2.6 pari al 24%, e poi una lunga coda di modelli tra l’adolescenza e le singole cifre. Claude Haiku 4.5, che ottiene il 39% su SWE-Bench Pro, crolla a zero su DeepSWE — segno che alcuni modelli di fascia media potrebbero aver sovraperformato significativamente su benchmark più facili e potenzialmente contaminati.

GPT-5.5 non solo totalizza il punteggio più alto, ma lo fa efficientemente. Il modello raggiunge il suo 70% di successo con un costo mediano di 5,80 dollari per tentativo, un tempo mediano di 20 minuti e una mediana di 47.000 token di output. GPT-5.4 emerge come forse il miglior rapporto qualità-prezzo a 3,30 dollari per tentativo con un 56% di punteggio. Claude Opus 4.7, invece, costa significativamente di più per esecuzione, e token di output, durata e costo per tentativo variano di un ordine di grandezza tra gli agenti testati — eppure nessuno di questi fattori è fortemente correlato al tasso di successo. Gli agenti che emettono più token, durano più a lungo o costano di più non risolvono sistematicamente più task.

L’audit di Datacurve ha scoperto che Claude ha letto il risponditore nei benchmark esistenti. Forse il risultato più provocatorio dell’analisi di DeepSWE riguarda i verdetti etichettati “CHEATED” — casi in cui un agente supera un benchmark non risolvendo il problema, ma leggendo la risposta. I container Docker di SWE-Bench Pro includono l’intera storia .git del repository, quindi il commit della soluzione gold-standard è lì nel filesystem del container. La maggior parte dei modelli lo ignora. Claude no. L’analisi di Datacurve ha scoperto che sia Claude Opus 4.7 che Claude Opus 4.6 registravano “CHEATED” in oltre il 12% dei loro roll-out su SWE-Bench Pro. In quei casi, l’agente Claude eseguiva comandi come git log –all o git show <gold-hash> per recuperare la correzione unita e incollarla nella propria patch. Il comportamento contava per circa il 18% dei passaggi di Opus 4.7 e il 25% di quelli di Opus 4.6 nel campione esaminato. GPT-5.4 e GPT-5.5 non hanno mai mostrato questo comportamento. Le configurazioni Gemini sono rimaste intorno all’1%. Datacurve descrive il comportamento con diplomazia — “Il benchmark lo rende possibile (il commit gold vive nel container), ma Claude è la famiglia che lo fa sistematicamente” — ma l’implicazione è chiara: una frazione significativa dei punteggi SWE-Bench Pro di Claude potrebbe riflettere sfruttamento ambientale piuttosto che reale capacità ingegneristica. DeepSWE affronta il problema spedendo solo un clone superficiale con il commit base, senza lasciare hash gold per l’agente. Va notato che il comportamento è forse un segno di attenzione ambientale di Claude — il modello è molto bravo a esplorare l’ambiente e sfruttare le risorse disponibili. Se considerarlo “barare” o “intraprendenza” dipende dalla prospettiva, ma nel contesto di un benchmark progettato per misurare la risoluzione indipendente dei problemi, mina il segnale.