OpenAI ha presentato il 19 ottobre 2026 nuovi risultati sulla programmazione in linguaggi meno rappresentati nei dati di addestramento. La ricerca su OpenAI e COBOL comprende la costruzione di un motore compatibile con SQLite e la migrazione di programmi esistenti. I risultati migliorano nei test dell’azienda; il punto per chi mantiene questi sistemi è conservare il comportamento del software, comprese le regole che un codice apparentemente più moderno potrebbe alterare.
Che cosa misurano le due prove?
OpenAI distingue due capacità. MultiLangBench osserva quanto software funzionante un modello riesca a costruire in venti linguaggi. La seconda valutazione riguarda la traduzione di programmi COBOL preservandone gli output. Sono benchmark pubblicati dal fornitore, non un resoconto di migrazioni bancarie completate. L’annuncio aggiorna il quadro del coding agentico di OpenAI: rende osservabili compiti e criteri di riuscita specifici, sui quali verificare il progresso dichiarato.
Su MultiLangBench, OpenAI riporta un tasso medio di superamento dei test dell’87,4% per GPT-6 Astra, contro il 26,8% di GPT-5.6 Sol, al massimo livello di ragionamento. Nella migrazione COBOL, GPT-6.1 Sol raggiunge l’86,6% a basso ragionamento contro il 5,4% del predecessore; con maggiore ragionamento arriva al 97,9%. Su MultiLangBench, GPT-6 Luna ottiene il 40,3%. Le prove hanno criteri diversi: quelle percentuali non formano una classifica unica.
Our latest model advances bring stronger capabilities for building and migrating software in low-resource programming languages such as COBOL, Fortran, and Visual Basic.
These languages power software that banks, governments, and businesses depend on. Progress here means… pic.twitter.com/Mulo5P3iCO
— OpenAI (@OpenAI) October 19, 2026
Per chi segue l’adozione dell’intelligenza artificiale nelle imprese, il punto è capire quale domanda venga posta al sistema. Scrivere una nuova funzione e sostituire un programma che opera da anni possono richiedere competenze sovrapposte, ma hanno rischi differenti. Nel secondo caso, una semplificazione che sembra ragionevole può cambiare una regola che nessuno ha documentato altrove. La valutazione deve quindi conoscere anche ciò che il nuovo codice deve conservare.
Come si controlla un motore SQLite ricostruito?
Il repository pubblico MultiLangBench spiega il protocollo. Il modello riceve la documentazione di SQLite 3.40.1 e deve produrre un eseguibile nel linguaggio richiesto. Ogni caso parte da un database iniziale, applica una query al programma candidato e verifica il risultato usando l’implementazione di riferimento. Questo consente di valutare implementazioni scritte in linguaggi differenti attraverso un’interfaccia comune, anziché giudicare soltanto se il codice sembri plausibile a un lettore.
Il README distingue anche il materiale disponibile dal campione suggerito. Circa 24.000 casi sono stati convertiti dalla suite originaria; per ragioni di costo indica un sottoinsieme di 272 test, consentendo prove più estese purché dichiarate. Non è corretto trasformare il numero di casi presenti nel repository nel numero sicuramente eseguito in ogni valutazione. Il dettaglio conta perché una percentuale diventa confrontabile quando sono espliciti campione, ambiente e regole di esecuzione.
Le istruzioni impongono un ambiente senza accesso a Internet e la rimozione delle copie di SQLite che il modello potrebbe riutilizzare. Sono condizioni costruite per isolare l’abilità osservata. Nei confronti fra benchmark, il perimetro degli strumenti disponibili è parte del risultato. Qui la domanda riguarda la capacità di costruire un’implementazione: poter richiamare il programma originale cambierebbe il compito e renderebbe meno informativo il punteggio ottenuto.
Perché conservare gli output è più difficile che riscrivere?
La nostra lettura è che il criterio più interessante riguardi la continuità delle regole. Un programma può compilare, rispondere rapidamente e produrre un file valido, ma trattare diversamente un caso limite. Immaginiamo, come esempio illustrativo nostro, un archivio nel quale un campo vuoto significhi “da verificare”. Una riscrittura che lo converta sempre in zero potrebbe passare molte prove ordinarie e cambiare il significato delle sole pratiche ancora incomplete.
Progressi nella programmazione con linguaggi a risorse limitate
Scopri come OpenAI migliora ChatGPT nei linguaggi con poche risorse, con nuove valutazioni per l’ingegneria del software, SQLite e la migrazione da COBOL.
Il confronto con l’output precedente serve a individuare differenze simili; non decide da solo se la vecchia regola fosse corretta. La nostra lettura distingue due lavori: replicare il comportamento esistente e scegliere consapevolmente quali comportamenti modificare. Mescolarli rende difficile capire se una differenza sia un errore di migrazione o un cambiamento voluto. Il controllo umano resta necessario soprattutto quando la decisione dipende da una regola aziendale, non dalla grammatica del linguaggio.
OpenAI descrive un caso concreto: l’aritmetica a virgola fissa di COBOL scarta le cifre decimali eccedenti quando non viene richiesto esplicitamente l’arrotondamento. Riscrivere quella parte arrotondando può produrre numeri diversi pur senza errori di esecuzione. Per questo la prova di migrazione richiede corrispondenza degli output osservabili byte per byte e considera riuscita una migrazione solo se supera tutti i test. Il significato di “successo” è più esigente della sola compilazione.
Un benchmark sostituisce le prove di affidabilità?
La documentazione ufficiale di SQLite mostra quanto sia ampio il problema della robustezza di un database. Descrive prove su esaurimento della memoria, errori di lettura e scrittura, crash, perdita di alimentazione, file malformati e regressioni. La compatibilità funzionale osservata su un insieme di query è una dimensione utile. La capacità di proteggere dati e stato quando l’ambiente si guasta è un’altra dimensione, che richiede prove costruite per quelle condizioni.
GitHub – openai/MultiLangBench: An eval based on SQLite that benchmarks language models in multiple languages.
An eval based on SQLite that benchmarks language models in multiple languages. – openai/MultiLangBench
La nostra lettura è che il benchmark diventi più utile quando aiuta a individuare i controlli mancanti. In un archivio conterebbero, per esempio, il recupero dopo un’interruzione e la compatibilità con le applicazioni che lo interrogano. Sono verifiche da progettare, non risultati attribuiti ai modelli della ricerca. La suite pubblicata serve a misurare una parte della funzionalità: l’affidabilità di un sostituto richiederebbe anche prove costruite sugli errori e sulle dipendenze del sistema originale.
Che cosa rende riproducibile il confronto?
Il repository definisce il risultato attraverso due elementi: tasso di superamento e costo delle chiamate all’interfaccia API. Una replica dovrebbe dichiarare modello, campione, configurazione e condizioni di esecuzione, oltre alla spesa osservata. La nostra lettura è che conservare questi elementi permetta di capire se una differenza derivi da un modello migliore o da un budget maggiore. Registrare soltanto la percentuale finale toglierebbe informazioni necessarie per ripetere il confronto.
Anche il livello di ragionamento richiede attenzione. Nella migrazione COBOL, l’86,6% e il 5,4% si riferiscono entrambi al livello basso; il 97,9% appartiene a una configurazione più impegnativa, non specificata con un’etichetta precisa nel testo. Confonderle cancellerebbe una differenza dichiarata. Nella valutazione dell’intelligenza artificiale applicata al software, il rapporto fra accuratezza e risorse impiegate deve restare visibile, soprattutto quando si decide quale configurazione provare su un proprio progetto.
OpenAI e COBOL in sintesi
- Confermato: pubblicazione dei risultati il 19 ottobre e repository MultiLangBench accessibile.
- Non dimostrato: che i punteggi equivalgano all’affidabilità di una migrazione bancaria in produzione.
- Da seguire: repliche esterne, campioni dichiarati e verifiche sulle regole specifiche dei sistemi aziendali.
La lettura più grande
La nostra lettura è che il cambiamento più interessante sia poter rendere osservabile una parte del lavoro sul software meno recente. Un banco di prova pubblico permette di discutere input, controlli ed errori concreti. Per questo il tema del controllo indipendente delle valutazioni AI resta rilevante anche quando il materiale arriva da un altro laboratorio: accesso al metodo e conferma indipendente sono passaggi distinti.
I segnali da seguire saranno implementazioni riproducibili, difetti documentati e confronto fra il tempo risparmiato nella scrittura e quello richiesto dalla verifica. Un risultato vicino al massimo del benchmark può indicare un test da rendere più difficile, non un problema industriale definitivamente risolto. Per chi mantiene sistemi essenziali, il progresso utile si misura nella qualità delle modifiche che riesce ad accettare e spiegare.
Be the first to comment