Ci sono città che sono cresciute senza un piano. Un quartiere tira l’altro, una strada si innesta sull’altra a seconda di dove passava un torrente o finiva un campo, e per anni nessuno possiede una mappa completa: si va a memoria, si chiede al vicino, ci si perde. Poi, a espansione ormai avvenuta, arriva qualcuno con il compito ingrato di cartografare tutto quanto — non per costruire, ma per capire cosa è stato costruito. È esattamente la posizione in cui si trova oggi chi studia i modelli linguistici che scrivono codice. In quattro anni siamo passati dall’autocompletamento che suggerisce la riga successiva agli agenti che aprono un repository, leggono i file, eseguono i test e propongono una pull request da soli. Nessuno aveva ancora tracciato la mappa dell’intero territorio.
Ci hanno provato in tanti. Il paper si intitola From Code Foundation Models to Agents and Applications, è uscito su arXiv a fine 2025, conta 303 pagine ed è firmato da una settantina di ricercatori sparsi su una trentina di istituzioni — prevalentemente cinesi (Beihang, Alibaba, ByteDance, Tencent, Kuaishou), con contributi da Regno Unito, Australia e Singapore. Non è la solita rassegna che elenca modelli in ordine cronologico. È un tentativo di mettere in fila l’intero ciclo di vita di un modello per il codice, dalla raccolta dei dati fino all’agente autonomo, e — cosa più rara — di corredarlo con esperimenti originali che dicono, numeri alla mano, cosa funziona e cosa no.
Cosa prova a mappare, e perché conta
Il punto di partenza è un salto di prestazioni che ha del vertiginoso. Su HumanEval, il benchmark diventato lo standard per misurare la generazione di codice (dato un commento, scrivi la funzione corrispondente e falla passare attraverso una batteria di test), i modelli sono passati in pochi anni da percentuali di successo a una cifra a oltre il 95 per cento. È un progresso che ha smesso di essere curiosità accademica: oggi è prodotto commerciale, incorporato in GitHub Copilot di Microsoft, in Cursor di Anysphere, in Trae di ByteDance, in Claude Code di Anthropic, nella Gemini CLI di Google. Strumenti a cui un programmatore delega compiti veri, dal terminale.
La rassegna individua una biforcazione strategica nel campo. Da una parte i modelli generalisti — le famiglie GPT, Claude, LLaMA — che imparano il codice come effetto collaterale di un addestramento su enormi quantità di testo di ogni tipo, e ci guadagnano in ampiezza e comprensione del contesto. Dall’altra i modelli specializzati sul codice — StarCoder, Code LLaMA, DeepSeek-Coder, CodeGemma, QwenCoder — che sacrificano la varietà per la profondità, addestrandosi quasi solo su codice e vincendo sui benchmark di settore. Non c’è un vincitore netto: c’è un compromesso, e buona parte del paper serve proprio a renderlo esplicito.
Gli autori inquadrano tutto in una linea temporale a sei stadi, dall’era del coding guidato dall’uomo a quella dell’intelligenza del codice: scrittura manuale (anni Sessanta-Ottanta), assistita da strumenti, basata su framework, poi assistita dall’AI (2020-2025), guidata dall’AI (dal 2025) e infine — con un punto interrogativo che gli autori lasciano onestamente aperto — autonoma. Quel punto di domanda è la cosa più sincera del paper: nessuno sa ancora se l’ultimo stadio arriverà davvero.
C’è una ragione dichiarata per cui questa rassegna esiste, ed è una lacuna nelle precedenti. Gli autori confrontano le rassegne esistenti su otto dimensioni — dominio, se sono specifiche sul codice, uso degli LLM, pre-training, fine-tuning supervisionato, reinforcement learning, ricette di addestramento, applicazioni — e osservano che quasi tutte si concentrano sui compiti e sulle applicazioni, mentre pochissime coprono i metodi di reinforcement learning. È proprio lì, nella fase che ha reso possibili gli agenti moderni, che il campo era peggio cartografato. La scelta di riempire quel vuoto con esperimenti propri, e non solo con citazioni, è ciò che distingue questo lavoro da un’enciclopedia commentata.
Il ciclo di vita di un modello che scrive codice
La spina dorsale del lavoro è un percorso in cinque tappe, lo stesso per quasi tutti i modelli moderni. Conviene immaginarlo come la formazione di un artigiano. Prima la raccolta dei dati: si rastrellano miliardi di righe da GitHub e da altre fonti, si eliminano i duplicati, si filtrano per qualità. Poi il pre-training, la fase in cui il modello legge quel corpus sterminato e ne assorbe la grammatica implicita — è l’apprendista che sfoglia ogni manuale della bottega senza che nessuno gli spieghi ancora cosa fare. Segue il fine-tuning supervisionato (SFT), la pratica guidata: si mostrano al modello coppie istruzione-soluzione ben scelte, perché impari a rispondere e non solo a completare. Quindi il reinforcement learning (RL): il modello prova a risolvere problemi, il codice viene eseguito davvero e un verificatore automatico lo promuove o lo boccia a seconda che i test passino. È il tirocinio per prova ed errore, con un maestro che controlla il risultato. Infine l’agente: il modello smette di essere una scatola che sputa testo e diventa un attore che usa strumenti, apre file, lancia comandi, itera.
Le cinque fasi non sono intercambiabili: sono impilate. Il pre-training determina il tetto massimo di ciò che il modello potrà fare; l’allineamento (SFT e RL) decide quanto di quel potenziale emerge; l’impalcatura agentica trasforma un buon generatore di testo in qualcosa che agisce sul mondo.
La legge di scala, e perché Python è la lingua più difficile
La domanda più concreta che si pone chi addestra questi modelli è banale e feroce: quanti dati e quanti parametri servono per ottenere un certo livello? Il paper risponde con una legge di scala in stile Chinchilla, adattata al codice. La perdita del modello — quanto sbaglia, in media — si può prevedere così:
$$L(N, D) = \left(\frac{N_c}{N}\right)^{\alpha_N} + \left(\frac{D_c}{D}\right)^{\alpha_D} + L_\infty$$
dove $N$ è il numero di parametri, $D$ il numero di token di addestramento, e $L_\infty$ è la perdita irriducibile: il muro contro cui si va a sbattere anche con dati e calcolo infiniti, una misura della complessità intrinseca di ciò che si sta imparando. Gli esponenti $\alpha_N$ e $\alpha_D$ dicono quanto la perdita cala aggiungendo rispettivamente parametri e dati.
La parte affascinante è che gli autori hanno calcolato questi valori per sette linguaggi diversi — Python, Java, JavaScript, TypeScript, C#, Go, Rust — e hanno trovato che non scalano allo stesso modo. La perdita irriducibile mette i linguaggi in un ordine preciso: C# ha il valore più basso (0,288), seguito da Java e Rust, Go, TypeScript, JavaScript, e infine Python con il più alto (0,566). Tradotto: per una rete neurale, C# è la lingua più facile da imparare fino in fondo, Python la più difficile. La spiegazione è quasi linguistica. I linguaggi a tipizzazione statica e sintassi rigida, come C# o Rust, mettono più informazione in ogni token e lasciano meno spazio all’ambiguità; Python, con la sua tipizzazione dinamica, la sintassi flessibile e i mille modi di scrivere la stessa cosa, è un paesaggio statistico più accidentato. La libertà che noi umani amiamo in Python è, per il modello, rumore in più da domare.
Ne discende un consiglio operativo controintuitivo: non distribuire i token di addestramento in parti uguali tra i linguaggi. Le lingue più «dure» meritano proporzionalmente più dati, quelle più regolari saturano prima e sprecarci calcolo rende poco. E c’è di più: mescolare linguaggi imparentati aiuta. Un addestramento congiunto Java-C# riduce la perdita di oltre il 20 per cento rispetto al solo Java, e la sinergia tra due lingue si può misurare come $\Delta(\ell, \ell’) = L(\ell + \ell) – L(\ell + \ell’)$, cioè la differenza tra ripetere la stessa lingua e affiancarne una parente. Python fa eccezione — aiuta gli altri come lingua ausiliaria, ma ne trae poco quando è lui l’obiettivo — ma la regola generale, per gli autori, è che il multilinguismo conviene quasi sempre.
Gli esperimenti: stessi risultati, sei volte il tempo
Qui il paper si stacca dalle rassegne tradizionali. Invece di limitarsi a citare i lavori altrui, gli autori hanno addestrato modelli veri e riportato cosa è successo. Il primo esperimento riguarda la fase di fine-tuning supervisionato, e la domanda è mondana ma costosa: quale framework di addestramento conviene usare? Hanno preso lo stesso modello (Qwen2.5-Coder da 14 miliardi di parametri), lo stesso dataset, gli stessi iperparametri, e lo hanno addestrato con quattro framework diversi su 64 GPU. Il risultato è istruttivo proprio perché deludente sul piano dell’accuratezza: tutti e quattro arrivano più o meno allo stesso punto su HumanEval, tra 0,848 e 0,872. Ma il tempo per arrivarci va da circa 20 minuti a 2 ore — un fattore sei — a parità di risultato. La scelta del framework non ti fa un modello migliore; ti fa risparmiare (o buttare) ore di cluster. È il genere di verità che nei paper dei singoli modelli non viene quasi mai detta.
Il secondo esperimento sonda gli iperparametri, e trova un colpevole dominante: la dimensione del batch. Su un modello Mixture-of-Experts da 30 miliardi di parametri, il punteggio MBPP crolla da 0,860 con batch 64 a 0,556, poi 0,254, poi 0,169 man mano che il batch sale a 512, 1024, 2048. Il modello denso da 14 miliardi, invece, incassa gli stessi aumenti quasi senza scomporsi. Due lezioni in una: batch piccoli (tra 64 e 256) preservano meglio il segnale del gradiente sul codice, e le architetture sparse Mixture-of-Experts sono molto più capricciose delle dense — raggiungono le stesse vette in condizioni ideali, ma il margine di sicurezza è sottile. Per dare la misura del punto di partenza: lo stesso modello da 14 miliardi passava dallo 0,634 di HumanEval della versione base a oltre 0,87 dopo un fine-tuning fatto bene. La differenza tra un modello mediocre e uno competitivo, a volte, è tutta nella regolazione.
La scelta del framework non ti regala un modello migliore. Ti regala, o ti ruba, ore di calcolo a parità di risultato. È la parte del lavoro che nessuno mette nell’annuncio.
Lo stesso vale un piano più sotto, tra i framework di calcolo distribuito che rendono possibile addestrare un modello enorme spartendolo su centinaia di schede. Il paper li mette a confronto con numeri concreti: TorchTitan riporta un’accelerazione del 65 per cento su un modello LLaMA 3.1 da 8 miliardi di parametri distribuito su 128 GPU rispetto alle baseline ottimizzate, mentre altri sistemi puntano più sull’efficienza di memoria che sulla velocità pura, permettendo di addestrare modelli grandi anche su hardware modesto. Non esiste il framework migliore in assoluto: esiste quello giusto per il tuo cluster, la tua scala e il tuo vincolo dominante, che sia la memoria, la banda di rete o le ore. Sono decisioni ingegneristiche invisibili all’utente finale, eppure decidono se un modello si può addestrare o no.
Il terzo blocco riguarda il reinforcement learning, dove il modello impara facendosi giudicare da un verificatore che esegue davvero il suo codice. Anche qui emergono numeri onesti e non trionfali. Confrontando diversi metodi per stimare quanto «premiare» ogni tentativo, il migliore per diversità delle soluzioni (Pass@5) raggiunge 0,389, mentre una variante più semplice converge circa il 30 per cento più in fretta restando competitiva su entrambe le metriche — e per chi paga il cluster a ore, la velocità di convergenza vale quanto il picco. Ancora più interessante è la lunghezza massima consentita alle risposte: la relazione con le prestazioni non è lineare. La configurazione da 16 mila token dà il miglior Pass@1 (0,336), ma quella da appena 2 mila token vince sul Pass@5 (0,398), come se contesti più corti spingessero il modello a esplorare strategie più compatte; e in mezzo, a 8 mila token, si apre un’inspiegabile buca di prestazioni. Nessuna ricetta unica: più contesto per la singola soluzione giusta, meno contesto per la varietà, un valore intermedio come compromesso di default.
Il divario tra benchmark e software vero
La parte più importante del paper, e la più coraggiosa, è quella in cui gli autori mettono il dito nella piaga: la distanza tra ciò che i benchmark misurano e ciò che serve per scrivere software di produzione. HumanEval e MBPP verificano una cosa sola, la correttezza funzionale — il codice fa quello che gli è stato chiesto? Ma un programma può funzionare ed essere pessimo. Ed è qui che i numeri diventano scomodi.
Sulla sicurezza, il paper cita valutazioni su larga scala — oltre cento modelli su una ottantina di compiti — secondo cui circa il 45 per cento del codice generato contiene vulnerabilità note. E, dettaglio che dovrebbe far riflettere chi pensa che il tempo risolva tutto, i modelli più recenti e più grandi non migliorano quasi per niente su questo fronte. Codice che passa i test e apre una falla di sicurezza è la norma, non l’eccezione.
Sul contesto lungo, il problema ha un nome quasi poetico: lost in the middle, perso nel mezzo. Anche i modelli con finestre di contesto enormi degradano quando l’informazione rilevante sta in mezzo all’input invece che all’inizio o alla fine — e un repository reale è fatto quasi tutto di «mezzo». Tracciare le dipendenze tra file, ragionare sull’intero sistema e non sul singolo frammento resta un punto debole documentato. E sul fronte agentico, la rassegna raccoglie le prove che gli agenti falliscono ancora per fragilità nel ragionamento a lungo termine e per «allucinazioni da strumento»: scegliere l’attrezzo sbagliato, usarlo al momento sbagliato, o inventarsi un risultato che lo strumento non ha mai prodotto. La demo che risolve un bug giocattolo e l’agente che sistema una issue vera in una codebase da milioni di righe sono, per ora, due cose diverse.
Perché leggerlo
Un atlante di 303 pagine su un territorio che cambia ogni mese ha un difetto strutturale evidente: nasce già in parte datato, e gli stessi autori lo sanno, tanto da nominare i modelli dell’ultima ora sapendo che ne arriveranno altri prima ancora della pubblicazione. Ma la mappa non serve a fotografare l’istante. Serve a mostrare la forma del terreno — dove si sale, dove si scende, dove ci sono ancora zone bianche.
La zona bianca più grande, dice questo lavoro, non è la potenza dei modelli: è la distanza tra il benchmark e il cantiere. Sappiamo far scrivere a una macchina codice che passa i test nel 95 per cento dei casi; non sappiamo ancora farle scrivere codice che sia anche sicuro, manutenibile e coerente con un sistema grande. Il valore di una rassegna come questa, per chi lavora o studia nel campo, non sta nelle percentuali da record che tutti citano, ma nell’onestà con cui affianca a ogni numero trionfale il suo contraltare. È la differenza tra chi vende la città nuova con le foto del rendering e chi ti consegna la mappa con segnate anche le strade che finiscono nel fango.
Il paper
Jian Yang, Xianglong Liu, Weifeng Lv et al. (una settantina di autori), From Code Foundation Models to Agents and Applications: A Comprehensive Survey and Practical Guide to Code Intelligence, arXiv:2511.18538v5 [cs.SE], dicembre 2025. Disponibile su arXiv: arxiv.org/abs/2511.18538.
I commenti sono riservati agli iscritti.
Accedi per commentare