OpenAI hat am 19. Oktober 2026 neue Ergebnisse zur Programmierung in wenig vertretenen Sprachen vorgestellt. Die Forschung zu OpenAI und COBOL umfasst den Aufbau einer SQLite-kompatiblen Implementierung sowie die Migration bestehender Programme. Die Testergebnisse verbessern sich laut Unternehmensangaben; wer solche Systeme betreut, muss jedoch das Verhalten der Software erhalten, einschließlich der Regeln, die scheinbar modernerer Code verändern könnte.
Was messen die beiden Tests?
OpenAI unterscheidet zwei Fähigkeiten. MultiLangBench misst, wie viel funktionierendes Software ein Modell in zwanzig Programmiersprachen erstellen kann. Die zweite Bewertung betrifft die Übersetzung von COBOL-Programmen unter Beibehaltung ihrer Ausgaben. Dabei handelt es sich um vom Hersteller veröffentlichte Benchmarks, nicht um einen Bericht über abgeschlossene Bankmigrationen. Die Ankündigung aktualisiert den Rahmen für agentisches Coding bei OpenAI: Sie macht Aufgaben und spezifische Erfolgskriterien sichtbar, anhand derer der erklärte Fortschritt überprüft werden kann.
Laut OpenAI erreicht GPT-6 Astra auf MultiLangBench eine durchschnittliche Test-Bestehensrate von 87,4%, verglichen mit 26,8% für GPT-5.6 Sol auf dem höchsten Reasoning-Niveau. Bei der COBOL-Migration erzielt GPT-6.1 Sol laut Unternehmensangaben 86,6% bei niedrigem Reasoning gegenüber 5,4% beim Vorgänger; mit höherem Reasoning steigt der Wert auf 97,9%. GPT-6 Luna erreicht auf MultiLangBench 40,3%. Die Tests haben unterschiedliche Kriterien: Diese Prozentzahlen bilden keine einheitliche Rangliste.
Our latest model advances bring stronger capabilities for building and migrating software in low-resource programming languages such as COBOL, Fortran, and Visual Basic.
, OpenAI (@OpenAI) October 19, 2026
These languages power software that banks, governments, and businesses depend on. Progress here means… pic.twitter.com/Mulo5P3iCO
Für alle, die die KI-Einführung in Unternehmen beobachten, kommt es darauf an, welche Frage an das System gestellt wird. Eine neue Funktion zu schreiben und ein seit Jahren laufendes Programm zu ersetzen, erfordert zwar ähnliche Kenntnisse, birgt aber unterschiedliche Risiken. Im zweiten Fall kann eine scheinbar sinnvolle Vereinfachung eine Regel verändern, die nirgendwo dokumentiert wurde. Die Bewertung muss daher auch berücksichtigen, was der neue Code erhalten muss.
Wie prüft man eine rekonstruierte SQLite-Engine?
Das öffentliche MultiLangBench-Repository beschreibt das Protokoll im Detail. Das Modell erhält die Dokumentation von SQLite 3.40.1 und muss eine ausführbare Datei in der geforderten Sprache erzeugen. Jeder Testfall beginnt mit einer Ausgangsdatenbank, wendet eine Abfrage auf das Kandidatenprogramm an und überprüft das Ergebnis anhand der Referenzimplementierung. So lassen sich Implementierungen in verschiedenen Sprachen über eine gemeinsame Schnittstelle bewerten, anstatt nur zu beurteilen, ob der Code für einen Leser plausibel wirkt.
Das README unterscheidet zudem zwischen dem verfügbaren Material und dem empfohlenen Teilset. Rund 24.000 Fälle wurden aus der ursprünglichen Suite konvertiert; aus Kostengründen empfiehlt das Dokument ein Teilset von 272 Tests und erlaubt umfangreichere Durchläufe, sofern diese transparent deklariert werden. Es wäre falsch, die Gesamtzahl der Fälle im Repository mit der tatsächlich in jeder Bewertung ausgeführten Anzahl gleichzusetzen. Dieses Detail ist wichtig, weil eine Prozentzahl nur dann vergleichbar wird, wenn Stichprobe, Umgebung und Ausführungsregeln explizit angegeben sind.
Die Anweisungen schreiben eine Umgebung ohne Internetzugang vor und verlangen die Entfernung von SQLite-Kopien, die das Modell wiederverwenden könnte. Diese Bedingungen sollen die beobachtete Fähigkeit isolieren. Bei Benchmark-Vergleichen ist der Umfang der verfügbaren Werkzeuge Teil des Ergebnisses. Hier geht es um die Fähigkeit, eine Implementierung von Grund auf zu erstellen: Das Abrufen des Originalprogramms würde die Aufgabe verändern und den erzielten Score weniger aussagekräftig machen.
Warum ist der Erhalt von Ausgaben schwieriger als das Neuschreiben?
Das interessanteste Kriterium betrifft die Kontinuität von Regeln. Ein Programm kann kompilieren, schnell antworten und eine gültige Datei erzeugen, dabei aber einen Grenzfall anders behandeln. Als illustratives Beispiel sei ein Archiv genannt, in dem ein leeres Feld „zu prüfen“ bedeutet. Eine Neufassung, die dieses Feld stets in null umwandelt, könnte viele gewöhnliche Tests bestehen und dabei nur den Datensätzen schaden, die noch unvollständig sind.
Der Vergleich mit der vorherigen Ausgabe hilft, ähnliche Abweichungen zu erkennen; er entscheidet jedoch nicht, ob die alte Regel korrekt war. Es sind zwei getrennte Aufgaben: das bestehende Verhalten replizieren und bewusst entscheiden, welche Verhaltensweisen geändert werden sollen. Vermischt man beides, wird es schwer zu erkennen, ob eine Abweichung ein Migrationsfehler oder eine beabsichtigte Änderung ist. Menschliche Kontrolle bleibt vor allem dann notwendig, wenn die Entscheidung von einer Unternehmensregel abhängt und nicht von der Grammatik der Programmiersprache.
OpenAI beschreibt einen konkreten Fall: Die Festkomma-Arithmetik von COBOL schneidet überschüssige Dezimalstellen ab, wenn keine explizite Rundung angefordert wird. Wer diesen Teil durch Rundung ersetzt, kann andere Zahlen produzieren, ohne Ausführungsfehler zu erzeugen. Deshalb verlangt der Migrationstest eine Byte-für-Byte-Übereinstimmung der beobachtbaren Ausgaben und wertet eine Migration nur dann als erfolgreich, wenn alle Tests bestanden werden. Der Maßstab für „Erfolg“ ist anspruchsvoller als die bloße Kompilierung.
Ersetzt ein Benchmark die Zuverlässigkeitsprüfungen?
Die offizielle SQLite-Dokumentation zeigt, wie umfangreich das Problem der Datenbankrobustheit ist. Sie beschreibt Tests zu Speichererschöpfung, Lese- und Schreibfehlern, Abstürzen, Stromausfällen, beschädigten Dateien und Regressionen. Die bei einer Menge von Abfragen beobachtete funktionale Kompatibilität ist eine nützliche Dimension. Die Fähigkeit, Daten und Zustand zu schützen, wenn die Umgebung ausfällt, ist eine andere Dimension, für die eigens konstruierte Tests erforderlich sind.
Der Benchmark wird nützlicher, wenn er hilft, fehlende Kontrollen zu identifizieren. In einem Archiv wären zum Beispiel die Wiederherstellung nach einem Ausfall und die Kompatibilität mit den Anwendungen, die es abfragen, relevant. Das sind Prüfungen, die erst noch entworfen werden müssen, keine Ergebnisse, die den Forschungsmodellen direkt zugeschrieben werden können. Die veröffentlichte Suite misst einen Teil der Funktionalität: Die Zuverlässigkeit eines Ersatzsystems würde auch Tests erfordern, die auf die Fehler und Abhängigkeiten des Originalsystems zugeschnitten sind.
Was macht den Vergleich reproduzierbar?
Das Repository definiert das Ergebnis über zwei Elemente: Bestehensrate und Kosten der API-Aufrufe. Eine Replikation sollte Modell, Stichprobe, Konfiguration und Ausführungsbedingungen sowie die beobachteten Kosten ausweisen. Werden diese Elemente festgehalten, lässt sich nachvollziehen, ob eine Abweichung auf ein besseres Modell oder auf ein größeres Budget zurückzuführen ist. Nur die finale Prozentzahl zu protokollieren, würde Informationen entfernen, die für eine Wiederholung des Vergleichs notwendig sind.
Auch dem Reasoning-Niveau ist Aufmerksamkeit zu schenken. Bei der COBOL-Migration beziehen sich sowohl 86,6% als auch 5,4% auf das niedrige Niveau; die 97,9% gehören zu einer anspruchsvolleren Konfiguration, die im Text nicht mit einem genauen Label versehen ist. Sie zu verwechseln würde eine erklärte Differenz auslöschen. Bei der Bewertung von KI-Anwendungen im Software-Bereich muss das Verhältnis zwischen Genauigkeit und eingesetzten Ressourcen sichtbar bleiben, besonders wenn entschieden wird, welche Konfiguration für ein eigenes Projekt erprobt werden soll.
OpenAI und COBOL: Zusammenfassung
- Bestätigt: Veröffentlichung der Ergebnisse am 19. Oktober und öffentlich zugängliches MultiLangBench-Repository.
- Nicht belegt: dass die Punktzahlen der Zuverlässigkeit einer Bankmigration im Produktionsbetrieb entsprechen.
- Zu beobachten: externe Replikationen, deklarierte Stichproben und Überprüfungen der systemspezifischen Unternehmensregeln.
Das größere Bild
Die interessanteste Veränderung besteht darin, einen Teil der Arbeit an älterer Software sichtbar machen zu können. Ein öffentlicher Prüfstand ermöglicht die Diskussion von Eingaben, Kontrollen und konkreten Fehlern. Deshalb bleibt das Thema der unabhängigen Überprüfung von KI-Bewertungen relevant, auch wenn das Material von einem anderen Labor stammt: Zugang zur Methode und unabhängige Bestätigung sind zwei getrennte Schritte.
Die zu verfolgenden Signale sind reproduzierbare Implementierungen, dokumentierte Mängel und der Vergleich zwischen der bei der Code-Erstellung eingesparten Zeit und dem für die Verifikation erforderlichen Aufwand. Ein Ergebnis nahe dem Benchmark-Maximum kann auf einen Test hinweisen, der schwieriger gestaltet werden sollte, nicht auf ein industrielles Problem, das endgültig gelöst ist. Wer kritische Systeme betreut, misst nützlichen Fortschritt an der Qualität der Änderungen, die er akzeptieren und erklären kann.
