Was OpenAI am 19. Oktober veroeffentlicht hat
OpenAI hat am 19. Oktober 2026 neue Ergebnisse fuer Programmiersprachen veroeffentlicht, zu denen deutlich weniger Trainingsmaterial und Dokumentation existiert als etwa zu Python oder JavaScript. Im Mittelpunkt stehen COBOL, Fortran, Visual Basic, OCaml und weitere Sprachen, die teilweise noch kritische Infrastruktur und langjaehrige Unternehmenssysteme tragen.
Dafuer fuehrt OpenAI zwei Evaluierungen ein. MultiLangBench prueft, ob ein Modell in 20 Programmiersprachen schrittweise eine mit SQLite kompatible Datenbank-Engine bauen kann. Eine zweite Evaluation testet, ob COBOL-Programme nach C++, Java, Kotlin, Python oder Rust migriert werden koennen, ohne ihr beobachtbares Verhalten zu veraendern.
Bestaetigt sind die Veroeffentlichung, der beschriebene Versuchsaufbau und die von OpenAI bereitgestellten Ergebnisse. Die Leistungswerte stammen vom Hersteller. Eine unabhaengige Replikation fuer typische Unternehmensprojekte ist in der Ankuendigung nicht belegt.
Die neuen Zahlen sind OpenAI-Evaluierungen. Sie belegen Leistung innerhalb der beschriebenen Tests, nicht automatisch eine sichere Migration produktiver Altanwendungen.
GPT-6 Astra erreicht laut OpenAI 87,4 Prozent
Auf MultiLangBench erreicht GPT-6 Astra bei maximalem Reasoning-Aufwand laut OpenAI im Mittel 87,4 Prozent bestandene Tests. GPT-5.6 Sol kam im selben Vergleich auf 26,8 Prozent. Fuer einzelne Sprachen nennt OpenAI unter anderem 72,1 Prozent fuer COBOL, 83,5 Prozent fuer Fortran, 85,8 Prozent fuer OCaml und 89,4 Prozent fuer Visual Basic.
GPT-6 Luna erreicht im Mittel 40,3 Prozent und uebertrifft damit laut Anbieter ebenfalls GPT-5.6 Sol in allen 20 Sprachen. OpenAI beziffert die durchschnittlich geschaetzten API-Kosten pro Beispiel fuer Luna mit 0,77 US-Dollar gegenueber 3,48 US-Dollar fuer GPT-5.6 Sol, also rund 78 Prozent weniger.
MultiLangBench verlangt mehr als das Ergaenzen einzelner Funktionen: Das Modell muss Zustand verwalten, Fehler behandeln und neue Funktionen einbauen, ohne bestehende zu brechen. Dennoch bleibt es eine kontrollierte Aufgabe mit einer klaren Schnittstelle und automatisierten Tests. Gewachsene Produktionssysteme sind meist unvollstaendiger dokumentiert und staerker mit ihrer Umgebung verflochten.
Der COBOL-Test misst verhaltensgleiche Migration
Die zweite Evaluation konzentriert sich auf die Uebersetzung bestehender COBOL-Programme. Eine Migration gilt nur dann als erfolgreich, wenn alle verborgenen Tests bestanden werden und die beobachtbaren Ausgaben bytegenau uebereinstimmen. Das ist wichtig, weil scheinbar kleine Unterschiede bei Rundung, Dezimalstellen oder fehlenden Datensaetzen fachlich relevante Ergebnisse veraendern koennen.
GPT-6.1 Sol erreicht nach Angaben von OpenAI bei niedrigem Reasoning-Aufwand 86,6 Prozent Genauigkeit. GPT-5.6 Sol liegt im genannten Vergleich bei 5,4 Prozent. Mit hoeherem Reasoning-Aufwand steigt GPT-6.1 Sol laut Hersteller auf 97,9 Prozent.
Die Werte sprechen fuer einen deutlichen Fortschritt innerhalb dieses Tests. Sie sagen jedoch nicht, dass 97,9 Prozent eines beliebigen COBOL-Systems automatisch korrekt migriert werden. Entscheidend sind Umfang, Testabdeckung, externe Schnittstellen, Datenformate und implizite Geschaeftsregeln des konkreten Systems.
Was noch offen bleibt
OpenAI veroeffentlicht nach eigener Angabe den Aufbau und die Tests von MultiLangBench auf GitHub. Das verbessert die Nachpruefbarkeit. Fuer die Bewertung fehlen im Artikel jedoch unabhaengige Wiederholungen, Vergleiche auf realen proprietaeren Codebasen und Angaben dazu, wie viel menschliche Korrektur nach einer Modellmigration typischerweise notwendig ist.
Auch ein bestandener Funktionstest deckt nicht alle Risiken ab. Sicherheitsluecken, Performance-Probleme, Nebenlaeufigkeit, regulatorische Vorgaben oder schwer beobachtbare Randfaelle koennen ausserhalb der Tests liegen. Bei kritischen Systemen muss die fachliche Verantwortung deshalb bei qualifizierten Menschen bleiben.
Die Kostenangaben beziehen sich auf die konkreten Benchmark-Laeufe. Daraus lassen sich keine pauschalen Projektkosten fuer eine Modernisierung ableiten. Analyse, Testaufbau, Datenmigration, Parallelbetrieb und Abnahme koennen deutlich groessere Kostenfaktoren sein als die Modellnutzung.
Warum der Fortschritt trotzdem relevant ist
Viele Organisationen betreiben Systeme, deren urspruengliche Entwickler nicht mehr verfuegbar sind und deren Fachlogik nur noch im Code steckt. Bessere Modelle fuer COBOL, Fortran und andere weniger verbreitete Sprachen koennen bei Dokumentation, Testgenerierung, Fehlersuche und schrittweiser Modernisierung helfen.
Der wichtigste Nutzen liegt zunaechst nicht in einer vollautomatischen Komplettmigration. Realistischer ist ein assistierter Prozess: Das Modell erklaert Module, identifiziert Abhaengigkeiten, schlaegt Tests vor und erstellt begrenzte Uebersetzungen, die Fachleute pruefen.
Dass OpenAI verhaltensgleiche Ausgaben und nicht nur syntaktisch gueltigen Code misst, ist dabei ein sinnvoller Schwerpunkt. Bei Legacy-Systemen zaehlt schliesslich, ob die bestehende Geschaeftslogik erhalten bleibt.
So sollte ein eigener Pilot aussehen
Ein sicherer Pilot beginnt mit einem abgegrenzten, nicht kritischen Modul und einer unveraenderlichen Ausgangsversion. Bevor KI eingesetzt wird, sollten Teams vorhandenes Verhalten durch Golden-Master-, Integrations- und fachliche Akzeptanztests festhalten.
Das Modell sollte in einer isolierten Umgebung ohne produktive Schreibrechte arbeiten. Jede Aenderung bleibt versioniert und durchlaeuft statische Analyse, Sicherheitspruefungen und menschliches Review. Fuer sensible Quelltexte sind ausserdem Datenverarbeitung, Speicherorte und vertragliche Bedingungen des verwendeten Zugangs zu klaeren.
Gemessen werden nicht nur bestandene Tests, sondern auch manuelle Nacharbeit, neu eingefuehrte Fehler, Laufzeit, Wartbarkeit und Gesamtkosten. Erst ein stabiler Vergleich gegen den bisherigen Prozess zeigt, ob die Modellunterstuetzung einen wirtschaftlichen Vorteil bringt.
- Kleines, fachlich verstandenes Modul mit guter Testbasis waehlen
- Bestehendes Verhalten vor der Migration reproduzierbar festhalten
- KI-Ausgaben isolieren, versionieren und von Menschen pruefen
- Sicherheit, Performance und fachliche Randfaelle separat testen
- Nacharbeit und Gesamtkosten gegen den bisherigen Prozess vergleichen
Die MindrAils-Einordnung
Die von OpenAI gemeldeten Spruenge sind gross genug, um Legacy-Modernisierung als ernsthaften Anwendungsfall fuer aktuelle Coding-Modelle zu pruefen. Besonders interessant ist, dass die Evaluation sowohl den Neubau komplexerer Software als auch die Erhaltung vorhandenen Verhaltens betrachtet.
Die Zahlen sollten trotzdem nicht als Automatisierungsquote gelesen werden. Ein Benchmark mit klaren Tests ist kontrollierter als ein jahrzehntealtes Kernsystem mit unvollstaendiger Dokumentation und vielen Schnittstellen.
Die vernuenftige Schlussfolgerung lautet daher: Modelle koennen zu einem starken Werkzeug fuer Analyse und Migration werden, aber die belastbare Entscheidung entsteht erst aus eigenen Tests, unabhaengiger Qualitaetssicherung und klarer menschlicher Verantwortung.
Quellen und weiterführende Informationen
Die Quellen wurden zu den jeweils angegebenen Zeitpunkten abgerufen. Externe Inhalte können sich danach ändern.
- Advancing Coding in Low-Resource Programming LanguagesOpenAI · abgerufen amQuelle öffnen
Dieser Beitrag wurde von der MindrAils Redaktion quellenbasiert eingeordnet. Er dient der allgemeinen Information und ersetzt keine Rechts-, Datenschutz- oder Fachberatung für einen konkreten Einzelfall.