Quando leggi che un modello «risolve il 70% dei problemi di programmazione», quel numero viene quasi sempre da qui. SWE-bench è il banco di prova che ha smesso di misurare gli esercizietti di codice e ha cominciato a misurare il lavoro vero: prendere una segnalazione di bug scritta da un umano su un progetto reale, e sistemare il codice perché il bug sparisca. Nel 2023 un gruppo di Princeton (Carlos Jimenez e colleghi) l’ha costruito, e capire come è fatto ti insegna a leggere quelle percentuali senza farti impressionare.

Perché conta per te

Le percentuali sui benchmark di coding sono ovunque negli annunci, e sono il modo principale con cui i modelli si vendono come «bravi a programmare». Sapere cosa misura davvero SWE-bench, e cosa può gonfiarne il risultato, ti mette in condizione di leggere un annuncio con l’occhio giusto: quel numero dice qualcosa di reale, ma non quello che sembra dire a prima vista.

Cosa dice il paper

SWE-bench raccoglie 2.294 problemi reali presi da GitHub, da dodici progetti Python molto usati. Ogni problema è una issue vera (la descrizione di un bug o di una richiesta) accoppiata alla modifica che gli sviluppatori hanno poi fatto per risolverla. Il modello riceve il codice del progetto e la descrizione del problema, e deve produrre la modifica. Non è generare una funzioncina isolata: spesso bisogna capire un progetto grande, coordinare cambiamenti su più file, e far passare i test automatici che gli sviluppatori usavano. La correzione è oggettiva: o i test passano, o no.

Il dato che oggi fa sorridere è quello di partenza. Nel 2023, i modelli migliori dell’epoca risolvevano una frazione minuscola di questi problemi: il GPT-4 di allora era intorno all’1,7%, Claude 2 al 4,8%. L’autore lo definì un bagno di realtà. Da allora i numeri sono saliti moltissimo, ma la lezione del paper non è il punteggio di un anno: è aver costruito una prova fatta di lavoro vero, dove barare è difficile perché il giudice sono i test del progetto.

Quanto fidarsi

Proprio perché queste percentuali contano tanto, vanno lette con cura. Tre avvertenze.

La prima: un numero su SWE-bench ha senso solo con la data e la versione accanto. Il campo si muove in fretta, e «70% su SWE-bench» senza dire quando e con quale sistema è un’affermazione vuota. Lo stesso benchmark, mesi diversi, mondi diversi.

La seconda: non tutte le percentuali sono confrontabili. Attorno a SWE-bench sono nate varianti (sottoinsiemi più piccoli, versioni ripulite a mano perché alcune soluzioni originali erano indovinabili da indizi contenuti nel problema stesso). Un punteggio sulla versione facile e uno sulla versione dura non si mettono nella stessa frase. Quando confronti due numeri, controlla che siano sullo stesso banco.

La terza: risolvere issue GitHub in Python non è tutto il programmare, e programmare non è tutto il lavoro. Un modello fortissimo su questo benchmark può essere mediocre su un linguaggio diverso, su un progetto tuo, su un compito che non assomiglia a una issue. Il benchmark misura una cosa precisa, e va preso per quella.

Cosa farne

La regola pratica quando incontri una percentuale di coding: chiediti su quale versione del benchmark, in quale data, e se è la stessa su cui è misurato il numero con cui la stai confrontando. E ricorda che la prova che conta per te non è la classifica, è il tuo lavoro: un modello bravo su SWE-bench è un buon candidato, non una garanzia sul tuo progetto.

Cosa non concludere: che una percentuale alta significhi «sa programmare» in generale. Significa «risolve una certa fetta di issue Python reali, misurate così, a quella data». È un’informazione utile e onesta, se la leggi per quello che è e non per quello che l’annuncio vorrebbe farti capire.

Dove approfondire

La voce benchmark del glossario spiega in due righe perché un buon punteggio su una prova non garantisce il risultato sul tuo lavoro, ed è il principio da tenere in mano ogni volta che leggi una classifica.