Vai al contenuto principale
OpenAI

19 ottobre 2026

PubblicazioneRicerca

Progressi nella programmazione con linguaggi a risorse limitate

Caricamento in corso...

I più recenti progressi dei nostri modelli potenziano le capacità di sviluppo e migrazione del software in linguaggi di programmazione con poche risorse disponibili, come COBOL, Fortran e Visual Basic. Rispetto a linguaggi come Python e JavaScript, questi linguaggi offrono meno codice e documentazione da cui i modelli possono apprendere, eppure sono alla base di infrastrutture critiche e servizi essenziali in tutto il mondo. COBOL è alla base⁠(si apre in una nuova finestra) di oltre il 40% dei sistemi bancari online, dell’80% delle transazioni con carta di credito effettuate di persona e del 95% delle transazioni agli sportelli bancomat, mentre Fortran viene utilizzato nelle previsioni meteorologiche⁠(si apre in una nuova finestra) e nelle analisi di sicurezza dei reattori nucleari⁠(si apre in una nuova finestra). Migliorare la capacità dell’IA di lavorare con questi linguaggi potrebbe aiutare i team a mantenere e modernizzare il software da cui dipendono servizi essenziali.

Questo lavoro è guidato dai feedback di sviluppatori e clienti aziendali, che ci hanno segnalato come i modelli di programmazione incontrino spesso difficoltà con questi linguaggi. Mantenere e modernizzare questo software può essere difficile: la documentazione può essere incompleta, gli sviluppatori originali possono aver lasciato l’azienda e importanti regole di business possono essere presenti soltanto nel codice. Che si tratti di correggere bug o di migrare a un altro linguaggio, i team devono preservare il comportamento da cui dipende il funzionamento dei loro sistemi.

Per misurare i progressi, abbiamo sviluppato due valutazioni. MultiLangBench verifica se un modello è in grado di creare da zero un motore di database compatibile con SQLite in 20 diversi linguaggi di programmazione. La nostra valutazione della migrazione da COBOL verifica se un modello è in grado di migrare programmi esistenti a un altro linguaggio preservandone il comportamento. Insieme, mettono alla prova due capacità complementari: creare nuovo software e preservare il funzionamento di quello esistente.

I nostri modelli più recenti mostrano miglioramenti sostanziali in entrambe le valutazioni, offrendo un’accuratezza molto maggiore a un costo inferiore.

Su MultiLangBench, GPT‑6 Astra raggiunge una percentuale media di test superati dell’87,4% su 20 linguaggi di programmazione, rispetto al 26,8% di GPT‑5.6 Sol, con miglioramenti in ogni linguaggio testato. Anche GPT‑6 Luna supera GPT‑5.6 Sol, raggiungendo il 40,3% con un costo API stimato inferiore di circa il 78%.

Nella nostra valutazione della migrazione da COBOL, GPT‑6.1 Sol raggiunge un’accuratezza dell’86,6% con uno sforzo di ragionamento basso, rispetto ad appena il 5,4% di GPT‑5.6 Sol, a un costo inferiore del 39%. Con uno sforzo di ragionamento maggiore, l’accuratezza raggiunge il 97,9%, avvicinandosi al massimo misurabile dalla valutazione.

Nel complesso, questi risultati mostrano che i nostri modelli stanno migliorando significativamente nel lavorare con un’ampia gamma di linguaggi di programmazione, diventando al contempo più efficienti in termini di costi.

1. Creare SQLite da zero (MultiLangBench)

MultiLangBench chiede a un modello di creare un motore di database compatibile con SQLite in un linguaggio di programmazione specificato. Il modello deve organizzare una base di codice, gestire lo stato e gli errori e aggiungere nuove funzionalità preservando quelle esistenti.

Per confrontare le implementazioni nei diversi linguaggi, usiamo i file di database come interfaccia comune. Il programma da valutare riceve un database iniziale e una query SQL, quindi produce un database modificato. Usiamo l’implementazione di riferimento di SQLite per verificare che il database risultante contenga i dati previsti. Questo ci consente di applicare gli stessi test indipendentemente dal linguaggio usato per creare il motore.

Abbiamo adattato a questo formato i test della suite esistente di SQLite. La valutazione misura quante funzionalità effettivamente funzionanti un modello riesce a realizzare durante una sessione di programmazione prolungata, riportando sia la percentuale di test superati sia il costo API.

Con il massimo sforzo di ragionamento, GPT‑6 Astra raggiunge una percentuale media di test superati dell’87,4% sui 20 linguaggi, rispetto al 26,8% di GPT‑5.6 Sol. I miglioramenti riguardano tutti i linguaggi testati, tra cui COBOL (dal 10,9% al 72,1%), OCaml (dal 25,6% all’85,8%), Fortran (dal 21,4% all’83,5%) e Visual Basic (dal 27,5% all’89,4%). Astra supera l’83% in 19 dei 20 linguaggi; COBOL resta il più difficile, con il 72%.

GPT‑6 Luna offre un’alternativa meno costosa che supera anch’essa GPT‑5.6 Sol in tutti i linguaggi testati. Con il massimo sforzo di ragionamento, raggiunge una percentuale media di test superati del 40,3%. Tra i miglioramenti figurano COBOL (dal 10,9% al 17,1%), OCaml (dal 25,6% al 34,1%), Fortran (dal 21,4% al 31,4%) e Visual Basic (dal 27,5% al 41,6%). Questi miglioramenti si ottengono con un costo API medio stimato di 0,77 $ per campione, rispetto ai 3,48 $ di GPT‑5.6 Sol: circa il 78% in meno.

Pubblichiamo su GitHub⁠(si apre in una nuova finestra) la configurazione di valutazione e la suite di test di MultiLangBench, insieme ai risultati per ciascun linguaggio. Gli sviluppatori possono esaminare cosa viene testato dalla valutazione, analizzare le prestazioni nei linguaggi che usano e individuare le lacune rilevanti per il proprio lavoro.

2. Migrare una base di codice COBOL

La nostra seconda valutazione chiede ai modelli di migrare programmi COBOL a C++, Java, Kotlin, Python o Rust, preservando il funzionamento di ciascun programma.

Per riuscire nella migrazione è necessario comprendere sia la logica di business del programma sia il comportamento specifico del linguaggio COBOL. I programmi COBOL elaborano spesso transazioni finanziarie e record aziendali, in cui dettagli come le regole di arrotondamento e la gestione dei record mancanti riflettono requisiti di business. Ad esempio, l’aritmetica a virgola fissa di COBOL scarta le cifre decimali in eccesso, a meno che non venga richiesto esplicitamente l’arrotondamento. Una versione riscritta che invece arrotonda questi valori può essere eseguita senza errori, ma produrre risultati finanziari diversi.

Per verificare che questi comportamenti vengano preservati, sottoponiamo i nostri modelli a test nascosti che richiedono una corrispondenza byte per byte degli output osservabili. Una migrazione è considerata riuscita solo se tutti i test vengono superati. Queste capacità di preservare il comportamento sono utili ai team che mantengono e modernizzano i sistemi meno recenti. Tuttavia, il loro impiego su software in produzione richiede ancora la revisione di esperti e test che verifichino il rispetto delle regole di business e delle dipendenze del sistema.

In questa valutazione, GPT‑6.1 Sol raggiunge un’accuratezza dell’86,6% con uno sforzo di ragionamento basso, rispetto al 5,4% di GPT‑5.6 Sol con la stessa impostazione, sostenendo appena il 61% del costo API. Con uno sforzo di ragionamento maggiore, l’accuratezza raggiunge il 97,9%, avvicinandosi al massimo misurabile dalla valutazione. Questi risultati dimostrano progressi verso una migrazione del codice più accurata ed economica per i team che modernizzano il software da cui dipendono le loro aziende.

Potenziare le capacità per il software aziendale

Queste valutazioni, insieme ai feedback diretti di sviluppatori e clienti aziendali, ci aiutano a capire dove i nostri modelli stanno migliorando e dove presentano ancora dei limiti.

Il nostro obiettivo è aiutare i modelli ad applicare le competenze di ingegneria del software a un numero maggiore di linguaggi: comprendere repository sconosciuti, pianificare modifiche, usare strumenti di build, eseguire test e individuare e correggere errori.

Puoi provare i nostri modelli più recenti tramite l’API su attività di programmazione nei linguaggi usati dal tuo team. I tuoi feedback su ciò che funziona, sulle difficoltà dei modelli e sui linguaggi o flussi di lavoro a cui dovremmo dare priorità ci aiutano a definire come addestrare e valutare i modelli per supportare meglio il software da cui dipendi.