In vielen mittelständischen Unternehmen laufen zentrale Prozesse auf Software, die älter ist als die Mitarbeiterinnen und Mitarbeiter, die sie bedienen. Lohnverrechnung, Lagerführung, Abrechnungslogik: Oft steckt die eigentliche Geschäftslogik in COBOL-Programmen, Fortran-Berechnungen oder Visual-Basic-Anwendungen, die über Jahrzehnte gewachsen sind. Dokumentation existiert selten, die ursprünglichen Entwickler sind meist nicht mehr im Haus.

Genau an dieser Stelle setzt eine aktuelle Entwicklung bei OpenAI an. Das Unternehmen hat seine neuesten Modelle gezielt für Programmiersprachen optimiert, zu denen es im Vergleich zu Python oder JavaScript nur wenig öffentlich verfügbares Trainingsmaterial gibt.

Die gemeldeten Zahlen

OpenAI verweist auf einen neuen Benchmark namens MultiLangBench, der über 20 Programmiersprachen abdeckt. Ein Benchmark ist dabei ein standardisierter Testlauf, mit dem sich Modelle untereinander vergleichen lassen. GPT-6 Astra erreicht dort laut den Angaben eine Testbestehensrate von 87,4 Prozent, während das ältere GPT-5.6 Sol auf 26,8 Prozent kam.

Für die COBOL-Migration im Speziellen nennt OpenAI eine Genauigkeit von bis zu 97,9 Prozent für GPT-6.1 Sol. Das ist ein Wert, der insbesondere mit Blick auf Finanzinfrastruktur interessant ist, weil dort ein großer Teil der weltweit eingesetzten COBOL-Bestände liegt.

Einordnend gilt: Benchmark-Werte sind Laborwerte. Sie sagen aus, wie gut ein Modell unter definierten Testbedingungen abschneidet, nicht wie gut es eine konkrete, über 30 Jahre gewachsene Fachanwendung mit undokumentierten Sonderfällen übersetzt. Der Sprung von unter 30 auf über 85 Prozent ist dennoch groß genug, um die Frage nach dem Einsatz in realen Projekten neu zu stellen.

Warum Altsprachen für KI-Modelle schwierig sind

Sprachmodelle lernen aus Text. Je mehr Code einer Sprache öffentlich verfügbar ist, desto besser beherrschen Modelle deren Idiome, Fehlerbilder und Konventionen. Bei COBOL, Fortran und Visual Basic ist die Lage umgekehrt: Der meiste produktive Code liegt in geschlossenen Unternehmensumgebungen und taucht in öffentlichen Repositories nicht auf.

Dazu kommt, dass diese Sprachen oft eng mit der Plattform verwoben sind, auf der sie laufen. Ein COBOL-Programm greift auf Dateiformate, Transaktionsmonitore oder Datenbankzugriffe zu, die es in einer modernen Serviceumgebung so nicht mehr gibt. Eine reine Sprachübersetzung löst dieses Problem nicht.

Was eine Migration tatsächlich umfasst

Wer eine Altanwendung ablöst, steht selten vor einer reinen Übersetzungsaufgabe. Typischerweise fallen mehrere Arbeitspakete an:

  • Bestandsaufnahme: Welche Programme laufen überhaupt noch, welche sind faktisch tot? In gewachsenen Systemen ist das keine triviale Frage.
  • Fachlogik rekonstruieren: Was tut der Code und warum? Hier kann ein Modell gute Dienste leisten, indem es undokumentierte Routinen in verständliche Beschreibungen überführt.
  • Zielarchitektur festlegen: Monolith eins zu eins nachbauen oder in Services schneiden? Diese Entscheidung trifft kein Modell.
  • Schnittstellen und Daten: Datenformate, Zeichensätze und Satzstrukturen aus der Altwelt müssen sauber abgebildet werden.
  • Testabdeckung: Ohne belastbare Tests lässt sich nicht belegen, dass die neue Implementierung dasselbe tut wie die alte.

Die eigentliche Chance der neuen Modellgeneration liegt weniger in der automatischen Vollmigration als in der Beschleunigung dieser Vorarbeiten. Code lesbar zu machen, Abhängigkeiten zu kartieren und Testfälle aus bestehendem Verhalten abzuleiten, sind Aufgaben, bei denen ein starkes Modell Wochen an manueller Analyse abkürzen kann.

Risiken, die bleiben

Eine Genauigkeit von knapp 98 Prozent klingt beruhigend, ist es aber nicht automatisch. In einer Abrechnungslogik können zwei Prozent abweichender Fälle bedeuten, dass bei jedem fünfzigsten Vorgang ein falscher Betrag entsteht. Entscheidend ist deshalb, wie Abweichungen erkannt werden, nicht wie selten sie vorkommen.

Praktikabel ist ein Vorgehen, bei dem Alt- und Neusystem eine Zeit lang parallel laufen und ihre Ergebnisse automatisiert verglichen werden. Erst wenn über einen relevanten Zeitraum keine Abweichungen auftreten, wird umgeschaltet. Dieses Prinzip ist älter als KI-gestützte Migration, wird durch sie aber wichtiger, weil mehr Code in kürzerer Zeit entsteht.

Ein zweiter Punkt ist die Vertraulichkeit. Legacy-Code enthält häufig Geschäftsgeheimnisse, Preislogiken oder Kundendaten in Testdatensätzen. Wer solchen Code an einen externen Dienst übergibt, braucht eine klare Regelung dazu, wo verarbeitet wird und was mit den Daten geschieht.

Schrittweise statt Big Bang

Der verbreitetste Fehler bei Modernisierungsvorhaben ist der Versuch, alles auf einmal zu ersetzen. Realistischer ist ein Vorgehen, bei dem einzelne Funktionsbereiche nacheinander herausgelöst und über definierte Schnittstellen an das Altsystem angebunden werden. Das Altsystem schrumpft dabei über Monate, statt an einem Stichtag abgeschaltet zu werden.

Bessere Modelle verschieben in diesem Bild vor allem den Aufwand pro Schritt. Was bisher an fehlendem Wissen über den Altcode scheiterte, wird planbarer.

Einordnung für Web- und Softwareprojekte

Für Projekte, die eine gewachsene Fachanwendung an eine moderne Weboberfläche oder an Services anbinden sollen, sinkt die Einstiegshürde spürbar: Der Altcode lässt sich schneller verstehen und dokumentieren, bevor überhaupt eine Zeile neu geschrieben wird. Die Architekturentscheidungen, die Testdisziplin und die fachliche Abnahme bleiben jedoch unverändert in menschlicher Verantwortung. Wer Modernisierung plant, sollte die neuen Werkzeuge deshalb als Beschleuniger für Analyse und Testaufbau einplanen, nicht als Ersatz für ein sauber geschnittenes Migrationsprojekt.

Quellen