Benchmark di coding AI: perché ogni nuovo modello si dice il migliore a programmare

Ogni volta che un laboratorio presenta un nuovo modello di intelligenza artificiale, la scena si ripete quasi identica. C’è una tabella, ci sono barre colorate e c’è una frase che promette il primato: il modello appena annunciato sarebbe il migliore al mondo a scrivere codice. È accaduto con Gemini 3.8 Flash, con GPT-6 Astra, con l’ultimo modello di punta di Alibaba e con una decina di altri sistemi usciti solo nelle ultime settimane.

Ma cosa misurano davvero quei numeri? E perché due modelli che si dichiarano entrambi primi in classifica possono comportarsi in modo molto diverso quando li metti al lavoro sul tuo progetto reale?

Per rispondere devi capire come funzionano i benchmark di coding, gli esami standardizzati con cui si valuta un’AI. Non sono verdetti neutri: raccontano una parte della verità e ne lasciano un’altra nell’ombra.

Che cosa misura davvero un benchmark di coding

Un benchmark è una prova ripetibile: un insieme fisso di compiti, una procedura per assegnare il punteggio e una classifica finale. L’idea è semplice, dai lo stesso test a modelli diversi e confronti i risultati. Il problema è che programmare non è un compito unico, ma decine di attività diverse, e ogni benchmark ne cattura solo alcune.

I primi test erano elementari. Con HumanEval, il benchmark introdotto da OpenAI nel 2021, al modello veniva chiesto di completare una singola funzione a partire dalla sua descrizione, e si controllava se il codice superava alcuni test automatici. Utile per farsi un’idea, ma lontano dal lavoro quotidiano di uno sviluppatore.

Da HumanEval a SWE-bench: dalle funzioni ai problemi reali

Il salto di qualità è arrivato con SWE-bench, proposto nel 2023 da un gruppo di ricercatori dell’università di Princeton. Invece di far scrivere una funzione isolata, parte da problemi veri: prende migliaia di segnalazioni di bug e richieste di modifica archiviate su GitHub, in progetti Python molto diffusi come Django o scikit-learn.

Al modello viene consegnato il codice del progetto e il testo del problema. Il suo compito è produrre una patch, cioè una modifica al codice, che risolva davvero la questione. Per stabilire se ci è riuscito non si giudica l’eleganza della soluzione, ma un criterio brutale e oggettivo: la patch viene applicata e si eseguono i test del progetto. Se le prove che prima fallivano ora passano, e quelle che già funzionavano non si rompono, il compito è risolto.

È un esame molto più onesto, perché somiglia a ciò che fa un programmatore in azienda: capire una richiesta, orientarsi in una base di codice che non ha scritto, intervenire nel punto giusto e non provocare danni altrove.

Proprio per questo SWE-bench è diventato il riferimento che quasi tutti citano. Ne esistono più versioni: una ridotta, per spendere meno nei test, e soprattutto SWE-bench Verified, un sottoinsieme di cinquecento problemi controllati da esseri umani per eliminare i casi ambigui o impossibili. Quando un annuncio parla di risultati sul coding, nove volte su dieci si riferisce a una di queste liste.

Un’altra sigla che incontri spesso è pass@1, cioè la percentuale di problemi risolti al primo tentativo. Alcuni annunci mostrano invece il pass@k, la probabilità di riuscita concedendo più prove. Sembra un dettaglio, ma cambia parecchio: un modello che azzecca la soluzione solo dopo dieci tentativi è molto meno utile, sul lavoro, di uno che la trova subito.

Perché i numeri non raccontano tutta la storia

Qui iniziano le insidie. Il primo problema si chiama contaminazione. I modelli vengono addestrati su enormi quantità di codice pescato dal web, GitHub compreso. Se un modello ha già visto, durante l’addestramento, il progetto e magari la soluzione di un problema che poi ritrova nel benchmark, il suo punteggio è gonfiato: non sta ragionando, sta ricordando.

Il secondo problema è più sottile e riguarda l’impalcatura attorno al modello, quella che in gergo si chiama scaffolding. Un modello quasi mai lavora da solo: è inserito in un agente che gli consente di leggere file, eseguire comandi, osservare l’esito dei test e riprovare. Due laboratori possono usare lo stesso modello con impalcature diverse e ottenere punteggi molto distanti. Spesso, insomma, non stai confrontando due cervelli, ma due squadre.

C’è poi la scelta dei compiti. Un benchmark fatto solo di problemi Python dice poco sulle capacità in linguaggi come Rust, Go o COBOL. E i bug archiviati su GitHub, con tanto di discussione e soluzione già scritta dagli sviluppatori, non somigliano sempre ai problemi nuovi e mai visti che affronti tu.

Nessuno di questi limiti rende i benchmark inutili. Servono a capire l’ordine di grandezza dei progressi. Ma un decimale di differenza tra due modelli, sventolato come sorpasso storico, quasi sempre è soltanto rumore.

Il costo conta quanto il punteggio

Un numero, da solo, non basta, perché ottenerlo ha un prezzo. Un modello può arrivare primo in classifica macinando molti più passaggi di ragionamento e consumando molti più token, quindi molti più soldi, di un rivale che si ferma appena sotto.

Per questo i laboratori più seri hanno smesso di mostrare solo la vetta della classifica e ragionano in termini di frontiera di efficienza, il miglior punteggio possibile a parità di costo. L’annuncio di Gemini 3.8 Flash di Google è un buon esempio: sul benchmark CWE-Bench, dedicato alla correzione delle vulnerabilità, il modello si ferma a un passo dal leader di categoria, con un pass@1 del 47,2% contro il 47,8%, ma a un costo molto più basso, stando ai dati diffusi dall’azienda.

Tradotto: il modello migliore non è per forza quello con la barra più alta, ma quello che ti dà il risultato che ti serve al prezzo che puoi permetterti. Per chi lavora, è questa la metrica che conta.

Oltre il coding puro: ragionamento, cyber e compiti a lungo orizzonte

Negli ultimi mesi le classifiche si sono moltiplicate, perché scrivere codice è solo una parte di ciò che chiediamo a questi sistemi. Sono comparsi benchmark sul ragionamento generale, come HLE, che mettono alla prova il modello su domande difficili di scienza, diritto e materie umanistiche. Ed è proprio su questo terreno che si sfidano oggi i modelli di punta di OpenAI, Google e Alibaba.

Poi c’è la frontiera degli agenti a lungo orizzonte, i compiti che richiedono decine di passaggi coordinati invece di una singola risposta. Test come DeepSWE nascono per misurare quanto un’AI riesce a portare a termine un lavoro di ingegneria dall’inizio alla fine, in autonomia.

Un capitolo a parte è la cybersicurezza. Benchmark come CyberGym valutano la capacità di scovare vulnerabilità nel software, mentre altri misurano quanto bene il modello sappia poi correggerle. È un terreno delicato: le stesse abilità che aiutano a difendere un sistema possono servire ad attaccarlo, ed è il motivo per cui alcuni modelli specializzati vengono distribuiti solo a soggetti selezionati.

Il senso di fondo è semplice: non esiste un unico numero capace di dire quale AI sia la migliore. Esistono tanti esami diversi, e un modello può essere primo in uno e mediocre in un altro.

Come leggere un annuncio senza farti ingannare

La prossima volta che vedi un grafico trionfale, poche domande ti bastano per inquadrare la realtà. Su quale benchmark è stato ottenuto quel risultato, e con quale versione? Il confronto tiene conto del costo, oppure mostra solo il punteggio più alto? Il distacco dal rivale è netto o è un decimale? E, soprattutto, quel test somiglia al lavoro che devi svolgere tu?

Se un annuncio risponde a queste domande con dati chiari e verificabili, merita fiducia. Se invece si limita a una barra che svetta sulle altre senza contesto, prendilo per quello che è: marketing, non scienza.

Il consiglio pratico, se stai scegliendo un modello per un progetto reale, è ignorare la classifica assoluta e costruirti un piccolo banco di prova personale: una manciata di compiti presi dal tuo lavoro quotidiano, dati in pasto ai due o tre modelli che stai valutando. È l’unico test che parla davvero la tua lingua.

In sintesi

I benchmark di coding sono bussole preziose, non verdetti definitivi. Ti dicono in che direzione si muove la tecnologia e con quale velocità, ma non sostituiscono la prova sul campo. Nella raffica di annunci di queste settimane, chi sa leggere quei numeri con spirito critico ha un vantaggio concreto: distingue il progresso reale dal rumore promozionale.

Se ti occupi di tecnologia o la usi per lavoro, tieni d’occhio come si evolvono questi test, non solo i punteggi. E se stai valutando quale AI adottare, parti sempre dalle tue esigenze concrete: è lì che si capisce davvero chi programma meglio.