Codice legacy e linguaggi a bassa risorsa: cosa cambia con i nuovi modelli OpenAI
Per anni la conversazione sull'AI per il codice ha ruotato intorno a Python, JavaScript e Go: linguaggi con milioni di esempi pubblici su cui i modelli si sono allenati. Il mondo reale, però, gira ancora in buona parte su COBOL, Fortran e Visual Basic: procedure batch dei gestionali, sistemi contabili, applicazioni scientifiche e fogli di calcolo evoluti in software. OpenAI ha pubblicato un'analisi su come i suoi modelli si comportano proprio in questi linguaggi. I numeri meritano una lettura attenta, senza trattarli come una promessa.
## Perché i linguaggi "a bassa risorsa" sono difficili
Il problema non è solo la quantità di esempi. Un linguaggio con poca documentazione pubblica, dialetti diversi e regole di business scritte direttamente nel codice mette alla prova qualsiasi modello. In un progetto tipico di migrazione ci si trova davanti a un programma batch scritto anni fa, senza test, in cui il comportamento reale dipende da dettagli di formattazione dell'output e da arrotondamenti mai documentati. Chi deve riscriverlo in Java o Python non sbaglia perché non sa programmare: sbaglia perché il sistema, di fatto, è la specifica.
## Cosa hanno misurato
OpenAI ha costruito due valutazioni. La prima, MultiLangBench, chiede al modello di realizzare da zero un motore di database compatibile con SQLite e verifica il risultato con l'implementazione di riferimento, usando gli stessi test per tutti i linguaggi. Su 20 linguaggi, il pass rate medio di GPT-5.6 Sol è del 26,8%, quello di GPT-6 Astra dell'87,4% e quello di GPT-6 Luna del 40,3%. COBOL resta il più difficile: 10,9% per GPT-5.6 Sol, 72,1% per Astra. Visual Basic, invece, sale da 27,5% a 89,4% con Astra.
La seconda valutazione riguarda la migrazione del COBOL verso C++, Java, Kotlin, Python o Rust. Qui il criterio è severo: test nascosti che richiedono parità byte per byte negli output osservabili, e una migrazione conta solo se li supera tutti. GPT-5.6 Sol si ferma al 5,4% con basso reasoning effort. GPT-6.1 Sol arriva all'86,6% con la stessa impostazione, a un costo API inferiore del 39%, e al 97,9% con alto reasoning effort. Quest'ultimo numero dice anche che il benchmark è quasi saturo, quindi discrimina poco tra i modelli migliori.
## La migrazione è una questione di test, non di sintassi
Il dato che mi interessa di più non è il punteggio, ma il criterio. Se una migrazione è accettata solo quando l'output coincide byte per byte, la domanda giusta non è "il codice compila?", ma "quale comportamento del sistema legacy devo congelare prima di toccare una riga?". Il metodo che funziona in un progetto reale è sempre lo stesso: catturare input e output del sistema, trasformarli in test di caratterizzazione e solo dopo chiedere al modello di riscrivere. Il modello diventa un generatore di candidati, e il test è l'oracolo.
Anche la scelta del modello è una leva di costo. Nel caso COBOL, la differenza tra basso e alto reasoning effort pesa molto sulla qualità, mentre il costo cresce. Conviene fare un pilota su un modulo rappresentativo, misurare pass rate e costo, e poi decidere quante risorse investire sul resto del sistema.
## Limiti da tenere a mente
OpenAI stessa riconosce che l'applicazione a software di produzione richiede comunque revisione esperta e test sulle regole di business e sulle dipendenze del sistema. I costi indicati sono stime, e per il modello più potente non viene riportato un costo per campione. Inoltre, i benchmark sono controllati: un sistema aziendale reale ha integrazioni, file e job schedulati che nessun test sintetico copre del tutto.
Il quadro, quindi, non è la fine della manutenzione del COBOL, che secondo OpenAI sta alla base di oltre il 40% dei sistemi di online banking. È un cambio di scala: un lavoro che richiedeva mesi di analisi manuale può trasformarsi in un ciclo di generazione, test e revisione molto più corto, a patto che qualcuno sappia scrivere una specifica precisa.
## In pratica
1. Prima di migrare, scegli un modulo piccolo e cattura input e output del sistema attuale per costruire test di caratterizzazione.
2. Confronta almeno due configurazioni di modello, per esempio basso e alto reasoning effort, su quel modulo, misurando pass rate e costo per caso.
3. Mantieni la revisione umana obbligatoria su regole di business, arrotondamenti e dipendenze esterne, e documenta ogni differenza accettata.
Se lavori con sistemi legacy, condividi l'articolo con chi se ne occupa, lascia un commento con il linguaggio che usi di più e iscriviti per i prossimi approfondimenti su AI e automazione.
Fonte: [Advancing coding in low-resource programming languages, OpenAI, 19 ottobre 2026](https://openai.com/index/low-resource-programming-languages)
## Perché i linguaggi "a bassa risorsa" sono difficili
Il problema non è solo la quantità di esempi. Un linguaggio con poca documentazione pubblica, dialetti diversi e regole di business scritte direttamente nel codice mette alla prova qualsiasi modello. In un progetto tipico di migrazione ci si trova davanti a un programma batch scritto anni fa, senza test, in cui il comportamento reale dipende da dettagli di formattazione dell'output e da arrotondamenti mai documentati. Chi deve riscriverlo in Java o Python non sbaglia perché non sa programmare: sbaglia perché il sistema, di fatto, è la specifica.
## Cosa hanno misurato
OpenAI ha costruito due valutazioni. La prima, MultiLangBench, chiede al modello di realizzare da zero un motore di database compatibile con SQLite e verifica il risultato con l'implementazione di riferimento, usando gli stessi test per tutti i linguaggi. Su 20 linguaggi, il pass rate medio di GPT-5.6 Sol è del 26,8%, quello di GPT-6 Astra dell'87,4% e quello di GPT-6 Luna del 40,3%. COBOL resta il più difficile: 10,9% per GPT-5.6 Sol, 72,1% per Astra. Visual Basic, invece, sale da 27,5% a 89,4% con Astra.
La seconda valutazione riguarda la migrazione del COBOL verso C++, Java, Kotlin, Python o Rust. Qui il criterio è severo: test nascosti che richiedono parità byte per byte negli output osservabili, e una migrazione conta solo se li supera tutti. GPT-5.6 Sol si ferma al 5,4% con basso reasoning effort. GPT-6.1 Sol arriva all'86,6% con la stessa impostazione, a un costo API inferiore del 39%, e al 97,9% con alto reasoning effort. Quest'ultimo numero dice anche che il benchmark è quasi saturo, quindi discrimina poco tra i modelli migliori.
## La migrazione è una questione di test, non di sintassi
Il dato che mi interessa di più non è il punteggio, ma il criterio. Se una migrazione è accettata solo quando l'output coincide byte per byte, la domanda giusta non è "il codice compila?", ma "quale comportamento del sistema legacy devo congelare prima di toccare una riga?". Il metodo che funziona in un progetto reale è sempre lo stesso: catturare input e output del sistema, trasformarli in test di caratterizzazione e solo dopo chiedere al modello di riscrivere. Il modello diventa un generatore di candidati, e il test è l'oracolo.
Anche la scelta del modello è una leva di costo. Nel caso COBOL, la differenza tra basso e alto reasoning effort pesa molto sulla qualità, mentre il costo cresce. Conviene fare un pilota su un modulo rappresentativo, misurare pass rate e costo, e poi decidere quante risorse investire sul resto del sistema.
## Limiti da tenere a mente
OpenAI stessa riconosce che l'applicazione a software di produzione richiede comunque revisione esperta e test sulle regole di business e sulle dipendenze del sistema. I costi indicati sono stime, e per il modello più potente non viene riportato un costo per campione. Inoltre, i benchmark sono controllati: un sistema aziendale reale ha integrazioni, file e job schedulati che nessun test sintetico copre del tutto.
Il quadro, quindi, non è la fine della manutenzione del COBOL, che secondo OpenAI sta alla base di oltre il 40% dei sistemi di online banking. È un cambio di scala: un lavoro che richiedeva mesi di analisi manuale può trasformarsi in un ciclo di generazione, test e revisione molto più corto, a patto che qualcuno sappia scrivere una specifica precisa.
## In pratica
1. Prima di migrare, scegli un modulo piccolo e cattura input e output del sistema attuale per costruire test di caratterizzazione.
2. Confronta almeno due configurazioni di modello, per esempio basso e alto reasoning effort, su quel modulo, misurando pass rate e costo per caso.
3. Mantieni la revisione umana obbligatoria su regole di business, arrotondamenti e dipendenze esterne, e documenta ogni differenza accettata.
Se lavori con sistemi legacy, condividi l'articolo con chi se ne occupa, lascia un commento con il linguaggio che usi di più e iscriviti per i prossimi approfondimenti su AI e automazione.
Fonte: [Advancing coding in low-resource programming languages, OpenAI, 19 ottobre 2026](https://openai.com/index/low-resource-programming-languages)
AI, OpenAI, COBOL, migrazione codice, sviluppo software
