In un qualsiasi progetto software su GitHub, ogni giorno, qualcuno apre una segnalazione: «il grafico va in errore quando la lista dei dati è vuota», con tanto di messaggio di crash allegato. Da qualche parte, in un codice sparso su decine di file, c’è la riga sbagliata. Un programmatore la trova, capisce perché rompe, scrive la correzione, verifica che i test esistenti continuino a passare e apre una pull request. Nel 2023 un gruppo di ricercatori tra Princeton e l’Università di Chicago si è chiesto: quanto sono bravi i modelli linguistici a fare esattamente questo lavoro, non su esercizi inventati ma su bug reali? La risposta, all’inizio, è stata impietosa. Il benchmark che l’ha misurata si chiama SWE-bench.
Pianificare, coordinare più agenti, la memoria che dura e il problema difficile di valutarli: nel libro.
Perché i benchmark di prima non bastavano
Fino ad allora la capacità di programmare dei modelli si valutava con problemi in miniatura: scrivi una funzione che, dato un input, produca l’output atteso. Utile, ma lontanissimo dal mestiere vero. Un ingegnere del software passa poco tempo a scrivere funzioni isolate e moltissimo a orientarsi in una base di codice che non ha scritto lui, capire quale delle centinaia di funzioni esistenti va toccata, e cambiarla senza rompere tutto il resto. È la differenza tra risolvere un cruciverba e riparare l’impianto elettrico di una casa già costruita: nel secondo caso il vincolo non è l’ingegno, è il contesto.
SWE-bench prende questo mestiere e lo trasforma in un test verificabile a macchina. Ogni compito parte da una situazione reale, pescata dalla storia di progetti Python molto usati: librerie come Django, scikit-learn, SymPy, Matplotlib. Si prende una segnalazione di bug davvero esistita, si riporta il codice al momento immediatamente precedente alla correzione, e si chiede al modello di produrre la patch. In tutto il benchmark originale raccoglie 2.294 di questi compiti, estratti da dodici repository.
Come si stabilisce se ha vinto
Qui sta l’eleganza dell’idea. Non c’è nessun giudizio soggettivo su quanto è «bello» il codice prodotto. Ogni bug reale, nella storia vera del progetto, era stato chiuso da una pull request che portava con sé dei test. SWE-bench usa proprio quei test come esame. La patch del modello viene applicata al codice e poi si lancia la suite: ci sono i test che prima fallivano e devono passare (la prova che il bug è effettivamente risolto) e i test che già passavano e devono continuare a passare (la prova che non hai rotto nient’altro nel frattempo). Se entrambe le condizioni sono soddisfatte, il compito è risolto. Altrimenti no. Nessuna via di mezzo, nessuna interpretazione.
È lo stesso criterio con cui giudicheresti un idraulico: non ti interessa quanto è elegante la sua saldatura, ti interessa che il rubinetto che perdeva ora non perda più e che, nel farlo, non abbia allagato la cucina.
Il compito parte da una segnalazione reale e dal codice congelato al commit precedente; l’agente propone una patch, e il verdetto lo dà l’esecuzione della suite di test del progetto, senza giudizi soggettivi.
Il primo verdetto: quasi zero
Quando gli autori hanno passato ai modelli migliori dell’epoca l’intero benchmark, il risultato è stato un bagno di umiltà: la percentuale di bug effettivamente risolti restava sotto il due per cento. Modelli che sembravano bravissimi a scrivere codice in vitro si perdevano appena messi davanti a un progetto vero, dove bisogna prima capire dove guardare. Non era un problema di sintassi: era un problema di navigazione e di contesto. Il codice giusto da cambiare era lì, ma trovarlo tra migliaia di righe, e cambiarlo nel modo che non rompe il resto, era un’altra cosa.
SWE-bench è diventato in fretta un punto di riferimento proprio perché era duro e onesto. Per renderlo maneggevole ne sono state ricavate versioni ridotte: SWE-bench Lite, un sottoinsieme di 300 compiti più leggeri, e più tardi SWE-bench Verified, 500 compiti rivisti a mano per eliminare quelli mal posti o impossibili (casi in cui, per esempio, la soluzione dipendeva da informazioni che il modello non poteva avere).
Poi sono arrivati gli agenti
La svolta non è venuta da modelli più grandi, ma dal modo di usarli. Invece di chiedere al modello di sputare la patch in un colpo solo, gli stessi autori hanno costruito SWE-agent, dandogli un’interfaccia agente-computer: un piccolo insieme di comandi per muoversi nel progetto come farebbe un programmatore. Aprire un file, cercare una stringa, scorrere fino a una funzione, modificarla, lanciare i test, leggere l’errore, correggere di nuovo. Un ciclo, non un salto.
Il modello non era diventato più intelligente. Gli avevano dato mani e occhi per lavorare sul codice invece di doverlo indovinare a memoria.
Con questo scaffold il tasso di risoluzione è salito dai frammenti di percentuale iniziali alle doppie cifre. Ed è stato solo l’inizio: nell’arco dei mesi successivi, con agenti sempre più raffinati, la quota di bug risolti sulla versione Verified ha superato la metà. Un progresso che dice qualcosa di importante: gran parte della capacità di «programmare» di un modello non sta nel modello, ma nell’impalcatura che gli costruisci intorno.
Le insidie di un benchmark che diventa una gara
Con la popolarità arrivano i problemi. Il primo è la contaminazione: i bug di SWE-bench vengono da progetti pubblici, e le loro soluzioni sono su GitHub. Se un modello è stato addestrato su tutto internet, potrebbe aver già «visto» la patch giusta, e allora non la sta ragionando, la sta ricordando. È il motivo per cui la data del bug rispetto alla data di addestramento conta, e per cui i test più affidabili usano problemi successivi al taglio dei dati. Il secondo è l’inseguimento del punteggio: quando una classifica diventa un trofeo, si finisce per ottimizzare gli agenti sulle idiosincrasie di quei dodici repository invece che sul saper riparare software in generale. Un numero alto su SWE-bench è un buon segnale, non una garanzia che quell’agente sistemerà il tuo codice.
Perché ti riguarda
Quando leggi che un assistente «risolve il 60% dei problemi di ingegneria del software», con ogni probabilità quel numero viene da qui. Capire com’è costruito il test ti dice cosa misura davvero e cosa no: che il compito è chiuso automaticamente da veri test, il che è rassicurante; che i progetti sono un campione ristretto di librerie Python, il che invita alla prudenza; e soprattutto che il salto di prestazioni degli ultimi anni è venuto più dalle impalcature agentiche che dai modelli in sé. Se domani un agente aprirà una pull request nel tuo repository, l’antenato di quel gesto ha questo nome.
Per approfondire
Il paper del benchmark: Jimenez, Yang e colleghi, SWE-bench: Can Language Models Resolve Real-World GitHub Issues?, 2023, presentato a ICLR 2024: arxiv.org/abs/2310.06770. Il lavoro sullo scaffold agentico: Yang, Jimenez e colleghi, SWE-agent: Agent-Computer Interfaces Enable Automated Software Engineering, 2024: arxiv.org/abs/2405.15793. Codice, dati e classifica aggiornata sono pubblici sul sito del progetto.
I commenti sono riservati agli iscritti.
Accedi per commentare