Michael JohnsonDet er mulig å flytte et COBOL-program til et moderne språk og bevare syntaksen, samtidig som reglene for pengeutregning endres. OpenAI viet publiseringen 19. oktober til nettopp dette problemet: Selskapet rapporterte resultater for modellene sine på programmeringstester i COBOL, Fortran og andre språk med mindre tilgjengelig treningsmateriale, og åpnet testpakken MultiLangBench.
For team som vedlikeholder gamle forretningssystemer, handler nytten ikke bare om prosentsatsene selskapet oppgir, men også om to ulike typer testing. Den ene vurderer hvordan programmer lages fra bunnen av i forskjellige språk; den andre undersøker om en migrering av COBOL-kode bevarer den observerbare oppførselen. Oppgavene krever ulike tester og har ulik betydning for risikoen ved innføring.
To tester – to ingeniøroppgaver
I MultiLangBench skal modellen lage en SQLite-kompatibel motor som tar imot spørringer og endrer en databasefil. OpenAI oppgir den gjennomsnittlige andelen beståtte tester på tvers av 20 språk: GPT‑6 Astra fikk 87,4 % med høyeste resonneringsnivå, mens GPT‑5.6 Sol fikk 26,8 %. Hver implementasjon kontrolleres mot det forventede databaseinnholdet; også kjøretid og API-kostnad vurderes.
Selskapet har publisert MultiLangBench på GitHub, inkludert testinfrastrukturen. Det publiserte repositoriet beskriver tester basert på testpakken SQLite TCL Tests og reglene for å kontrollere resultatet. Dermed kan utviklere se hvilke operasjoner som inngår i evalueringen, og deretter gjenskape den med sin egen modellkonfigurasjon.
COBOL-migrering tester en annen evne: å skrive om et eksisterende program til C++, Java, Kotlin, Python eller Rust og bevare oppførselen på skjulte tester. OpenAI rapporterer 86,6 % nøyaktighet for GPT‑6.1 Sol med lavt resonneringsnivå, mot 5,4 % for GPT‑5.6 Sol i samme modus. Med et høyere resonneringsnivå når GPT‑6.1 Sol 97,9 % i denne evalueringen.
Hvorfor migrering krever kontroll av forretningsreglene
I beskrivelsen understreker OpenAI at kompatibiliteten avhenger av semantikken i kildespråket. COBOLs aritmetikk med fast presisjon forkaster for eksempel overflødige desimaler hvis avrunding ikke er angitt eksplisitt. Hvis den nye implementasjonen avrunder annerledes, kan programmet kjøre uten problemer, men likevel gi andre økonomiske resultater.
Kriteriet i migreringstesten er derfor at utdataene samsvarer for tilfellene som kontrolleres. Teamets praktiske kriterier bør i tillegg omfatte egne beregningsregler, dataformater og systemavhengigheter. Et nyttig første steg er å velge en modul med tydelige inndata og utdata, fastsette referanseresultater for reelle grensetilfeller og kjøre den opprinnelige og den omskrevne versjonen parallelt.
Hva resultatene betyr for team
OpenAIs tall gjelder de publiserte datasettene og innstillingene for resonnering. MultiLangBench vurderer utvikling av en SQLite-kompatibel implementasjon, mens COBOL-testpakken undersøker om oppførselen bevares ved migrering; resultatene beskriver disse konkrete kontrollene. For team gir de et utgangspunkt for å velge modeller og et grunnlag for egne, reproduserbare sammenligninger – ikke en ferdig vurdering av kompatibilitet med ethvert produksjonssystem.
Den praktiske konklusjonen er enkel: Test modeller på egen kode og egne kontrolltilfeller, og vurder kostnaden sammen med andelen vellykkede kjøringer. Ved modernisering av COBOL er det særlig viktig å kontrollere avrunding, manglende poster og andre regler som ligger nedfelt i den gamle programmets oppførsel. De nye resultatene gjør slik testing mer tilgjengelig; ansvaret for å bekrefte at løsningene er likeverdige, ligger fortsatt i ingeniørprosessen.