OpenAI ha pubblicato il 19 ottobre una valutazione pubblica che dimostra come i suoi modelli di intelligenza artificiale riescano a comprendere e migrare il COBOL, linguaggio che ancora alimenta oltre il 40 % dei servizi bancari online, l’80 % dei pagamenti con carta e il 95 % dei prelievi dagli sportelli. Queste applicazioni, per lo più scritte decenni fa, racchiudono regole di business quasi dimenticate, e la loro modernizzazione è sempre stata ostacolata dal costo elevato della comprensione del codice legacy.

Benchmark pubblico e risultati sorprendenti

OpenAI ha introdotto MultiLangBench, un banco di prova pubblico che richiede al modello di costruire da zero un motore di database compatibile con SQLite. Il modello riceve una base dati e una query SQL, e i risultati vengono confrontati con l’implementazione di riferimento di SQLite tramite test tratti dalla suite ufficiale del progetto.

I venti linguaggi testati includono C, Java, Python, ma anche COBOL, Fortran, Visual Basic, OCaml, Common Lisp e Lean. OpenAI ricorda che il Fortran è ancora impiegato per le previsioni meteorologiche e per l’analisi di sicurezza dei reattori nucleari.

Performance dei modelli

    • GPT‑6 Astra: 87,4 % di successo medio, contro 26,8 % di GPT‑5.6 Sol.
    • Superamento dell’83 % nei test su 19 dei 20 linguaggi.
    • Nel COBOL, tasso di successo salito dal 10,9 % al 72,1 %, rimane il linguaggio più difficile.
    • GPT‑6 Luna (modello a basso costo): 40,3 % di successo a 0,77 $ per campione, contro 3,48 $ di GPT‑5.6 Sol.

Una seconda valutazione ha sottoposto gli stessi modelli alla migrazione diretta da COBOL verso C++, Java, Kotlin, Python o Rust. La migrazione è considerata valida solo se le uscite osservabili coincidono byte per byte con i test nascosti.

    • GPT‑6.1 Sol: 86,6 % di migrazioni riuscite con basso sforzo di ragionamento, rispetto al 5,4 % di GPT‑5.6 Sol.
    • Con alto sforzo, raggiunge il 97,9 % di successo, avvicinando la saturazione della valutazione.
    • Il costo per campione è inferiore del 39 % rispetto alla generazione precedente.

Impatto pratico per le DSI

OpenAI ha pubblicato su GitHub la configurazione e la suite di test di MultiLangBench, consentendo a chiunque di replicare la valutazione e confrontare altri modelli. Il costo per campione, affiancato al tasso di successo, fornisce un ordine di grandezza utile per budgetizzare una migrazione su larga scala.

Tuttavia, la valutazione è stata progettata e valutata da OpenAI su programmi scelti dall’azienda; finora non esistono risultati indipendenti. OpenAI avverte che una migrazione in produzione richiede ancora revisione da esperti e test basati sulle regole di business.

Da analisi a validazione

Anthropic, con il suo Claude Code, ha evidenziato come la modernizzazione fosse bloccata perché più costoso comprendere il codice ereditato che riscriverlo. Claude Code mappa le dipendenze su migliaia di righe, evidenziando strutture dati condivise, operazioni su file, moduli fortemente accoppiati e componenti isolati, oltre a duplicazioni logiche e debiti tecnici.

L’analisi richiedeva in passato grandi team di consulenti; secondo Anthropic, la modernizzazione ora può avvenire in pochi trimestri anziché anni, sebbene l’azienda non fornisca dati precisi sul risparmio. Viene consigliato di iniziare con un singolo componente di complessità media e limiti chiari, piuttosto che affrontare un intero sottosistema.

Il lavoro rimasto alle DSI

La parità di output misurata da OpenAI rappresenta solo una parte del lavoro. Le DSI devono dimostrare che l’applicazione migrata produce gli stessi risultati dell’originale, caso per caso, includendo processi di fine mese e scenari di errore rari. Anthropic suggerisce di scrivere test di non regressione prima di ogni modifica, adottare migrazioni incrementali e incapsulare il codice legacy con API che consentano l’esecuzione parallela delle due versioni.

I test nascosti di OpenAI simulano questo ruolo nella valutazione, ma in ambiente reale è indispensabile il coinvolgimento di esperti di dominio per verificare scenari critici e requisiti normativi.

Limiti dell’automazione

    • Dipendenze implicite, dati condivisi e stato globale rimangono parzialmente fuori dall’analisi automatica.
    • Regole normative, priorità di business e tolleranza al rischio richiedono giudizio umano.
    • La validazione finale sposta la spesa dai consulenti che leggevano il codice alle team che definiscono le funzionalità richieste.

Visioni contrastanti: IBM e il valore della piattaforma

Nel medesimo giorno, Rob Thomas di IBM Software ha sottolineato che “tradurre il codice è una cosa, modernizzare una piattaforma ne è un’altra”. IBM sostiene che la resilienza transazionale, la sicurezza e l’efficienza del mainframe derivino da un’architettura integrata, non dal linguaggio di programmazione. Il mainframe garantisce fino a 25 miliardi di transazioni cifrate al giorno e una disponibilità di otto nove (99,999999 %).

IBM stima che il 40 % del COBOL giri su Windows, Linux o altre piattaforme distribuite, un contesto diverso rispetto al mainframe. L’azienda utilizza anch’essa l’IA generativa per modernizzare il codice senza abbandonare la piattaforma, citando esempi come il capoverdiano NOSI, che ha ridotto del 94 % il tempo di analisi del codice superfluo con watsonx Code Assistant for Z, e la Royal Bank of Canada, che ha mappato dipendenze e flussi di dati con lo stesso strumento.

IBM richiama inoltre l’importanza della sovranità e della residenza dei dati, aspetti critici per le applicazioni sostituite da servizi SaaS.

Approcci basati su regole di business: AWS e Pega

AWS Transform for Mainframe, disponibile dal maggio 2025, affronta la migrazione estraendo le regole di business dal codice COBOL e PL/I su z/OS. L’outil catalogue le funzioni di business, ne estrae le regole integrate e genera artefatti moderni. Da giugno 2026, la funzionalità consente alle organizzazioni di creare cataloghi delle regole di business e di migrare in modo più controllato.

Pega, da parte sua, si concentra sulla ricostruzione dei processi di business a partire dalle regole estratte, fornendo una piattaforma low‑code per la realizzazione di applicazioni moderne che mantengono la logica originale.

Conclusioni

L’avanzamento dell’IA generativa sta invertendo la tradizionale equazione della modernizzazione: comprendere il codice legacy è ora più economico della sua riscrittura. I benchmark pubblici di OpenAI offrono dati concreti su costi e tassi di successo, ma la migrazione reale richiede ancora validazione umana, test di non regressione e attenzione a requisiti normativi e operativi.

Le DSI devono quindi riorientare le proprie risorse, passando dalla lettura del codice all’assicurazione che il nuovo software si comporti identicamente. I fornitori, da parte loro, dovranno adattare le proprie offerte, distinguendo tra semplice traduzione del codice e vera modernizzazione della piattaforma, tenendo conto di fattori quali resilienza, sicurezza e sovranità dei dati.