Warum schnelleres Codeverständnis noch keine bessere Anwendung ergibt

Es gibt derzeit kaum eine Präsentation zur Mainframe-Modernisierung, in der künstliche Intelligenz nicht eine Hauptrolle spielt. KI analysiert COBOL, erklärt PL/I, durchsucht JCL, erkennt Abhängigkeiten, erzeugt Dokumentationen und schlägt Testfälle vor. Agentische Systeme können selbstständig Quelltexte verändern und Entwicklungsprozesse ausführen.

Das klingt nach dem langen ersehnten Durchbruch. Anwendungen, die über Jahrzehnte gewachsen sind, lassen sich plötzlich in Tagen statt in Monaten analysieren. Fehlende Dokumentationen entstehen auf Knopfdruck. Der Fachkräftemangel verliert seinen Schrecken, weil sich die KI auch in alten Programmiersprachen auskennt.

Zumindest lautet so die Erzählung.

Die Realität ist komplizierter. KI verändert die Geschwindigkeit der Mainframe-Modernisierung. Sie beseitigt aber nicht deren grundlegende Risiken.

Nach dem ersten Hype müssen wir deshalb genauer betrachten, was diese Werkzeuge tatsächlich leisten und an welcher Stelle aus einer beeindruckenden Demonstration ein belastbares Modernisierungsvorhaben wird.

Eine Anwendung besteht nicht nur aus Quellcode

Ein KI-System kann in wenigen Minuten erklären, welche Dateien ein COBOL-Programm verarbeitet, welche Unterprogramme es aufruft und unter welchen Bedingungen ein bestimmtes Feld verändert wird. Das ist wertvoll, denn solche Analysen haben bisher oft viel Zeit und Erfahrung erfordert.

Trotzdem bleibt eine entscheidende Frage offen: Hat die KI damit wirklich die Anwendung verstanden?

Geschäftskritische Mainframe-Systeme bestehen nicht nur aus Programmen. Ihre tatsächliche Bedeutung entsteht durch das Zusammenspiel von Quellcode, Daten, Batchketten, Schnittstellen, Betriebsabläufen und fachlichen Regeln. Hinzu kommen seltene Ausnahmefälle, historische Entscheidungen und manuelle Eingriffe, die in keinem Programmkommentar beschrieben sind.

Eine KI kann erkennen, dass ein bestimmter Programmpfad nur selten ausgeführt wird. Sie weiß deshalb noch nicht, ob dieser Pfad überflüssig ist oder eine gesetzlich vorgeschriebene Ausnahme behandelt. Sie kann feststellen, dass ein Datenfeld mehrere Werte enthält. Sie kann jedoch nicht automatisch beurteilen, ob diese Werte technisch historisch gewachsen oder fachlich weiterhin notwendig sind.

Eine plausible Beschreibung ist noch kein belastbares Anwendungsverständnis.

Gerade für Entscheider ist diese Unterscheidung wichtig. Wer eine automatisch erzeugte Analyse mit vollständigem Verständnis verwechselt, beseitigt keine Unsicherheiten. Er beschleunigt lediglich die Produktion möglicherweise falscher Annahmen.

KI kann das Verstehen unterstützen. Der Nachweis, dass etwas richtig verstanden wurde, bleibt jedoch eine gemeinsame Aufgabe von Fachbereich, Entwicklung und Betrieb.

Aus COBOL wird nicht automatisch eine moderne Java-Anwendung

Besonders sichtbar wird dieses Problem bei der automatischen Transformation von COBOL nach Java. Moderne Transpiler und KI-Werkzeuge können erstaunlich schnell lauffähigen Java-Code erzeugen. Der neue Quelltext kompiliert, lässt sich in aktuellen Entwicklungsumgebungen bearbeiten und kann auf einer anderen Plattform betrieben werden.

Damit wurde aber zunächst nur die Sprache gewechselt.

Prozedurale Strukturen, globale Datenmodelle, Copybooks, Batchabhängigkeiten und mainframetypische Laufzeitkonzepte verschwinden nicht automatisch. Sie werden häufig lediglich in Java nachgebildet. Das Ergebnis sieht dann modern aus, verhält sich aber weiterhin wie die ursprüngliche COBOL-Anwendung.

Dafür hat sich nicht ohne Grund der Begriff „JOBOL“ etabliert.

Das bedeutet nicht, dass eine automatische Übersetzung grundsätzlich falsch ist. Sie kann eine sinnvolle Übergangsstrategie sein. Sie kann den Wechsel einer Plattform erleichtern, fachliche Logik bewahren und die Grundlage für spätere Verbesserungen schaffen.

Problematisch wird es erst, wenn die Übersetzung bereits als abgeschlossene Modernisierung verkauft wird.

Java-Syntax macht aus einer COBOL-Architektur noch keine moderne Java-Anwendung.

Eine erfolgreiche Modernisierung muss sich daran messen lassen, ob das Ergebnis verständlicher, wartbarer, sicherer und besser integrierbar ist. Ein Java-Team sollte die Anwendung nicht nur kompilieren, sondern auch sinnvoll weiterentwickeln können. Andernfalls wurden die Altlasten nicht beseitigt, sondern lediglich in eine neue Sprache übertragen.

Modernisierung bedeutet nicht automatisch Abriss

Die Debatte wird häufig künstlich auf zwei Möglichkeiten reduziert. Entweder bleibt die alte Anwendung unverändert bestehen oder sie wird vollständig neu entwickelt.

In der Praxis liegt der sinnvollste Weg häufig dazwischen.

Viele Mainframe-Anwendungen lassen sich gezielt verbessern. Aktuelle Compiler, moderne Entwicklungswerkzeuge, automatisierte Builds und Tests, optimierte Datenzugriffe sowie klar definierte APIs können den technischen Zustand erheblich verändern. Benutzeroberflächen lassen sich entkoppeln, einzelne Komponenten können ersetzt und ungenutzte Programme entfernt werden.

Dabei bleibt die bewährte fachliche Logik erhalten, während Risiken schrittweise reduziert werden.

Eine vollständige Neuentwicklung wirkt auf dem Papier oft sauberer. Sie bringt jedoch die Verpflichtung mit sich, sämtliche fachlichen Sonderfälle neu zu entdecken und korrekt nachzubilden. Jahrzehntelang bewährte Betriebsverfahren müssen rekonstruiert werden. Fehlerbehandlung, Restart-Verfahren und Lastverhalten entstehen nicht automatisch neu, nur weil die Architektur moderner aussieht.

Modernisierung ist kein Wettbewerb darum, möglichst viel alten Code zu beseitigen.

Sie ist eine Reihe bewusster Entscheidungen. Was ist weiterhin wertvoll? Was muss technisch verbessert werden? Welche Komponente verhindert heute notwendige Veränderungen? Wo erzeugt ein Austausch tatsächlich einen geschäftlichen Nutzen?

KI kann diese Entscheidungen vorbereiten. Sie kann Abhängigkeiten analysieren, ungenutzten Code identifizieren und mögliche Refactorings vorschlagen. Sie kann dem Unternehmen aber nicht die Verantwortung dafür abnehmen, die richtige Modernisierungsstrategie zu wählen.

Manchmal ist ein Rewrite notwendig. Manchmal genügt eine technische Erneuerung. Häufig besteht der beste Weg aus mehreren kontrollierten Schritten.

Die eigentlichen Engpässe liegen außerhalb des Codes

Viele Modernisierungsvorhaben scheitern nicht daran, dass der Quellcode unzugänglich wäre. Sie scheitern daran, dass niemand zuverlässig erklären kann, welches Verhalten unbedingt erhalten bleiben muss.

Das Wissen über eine Anwendung verteilt sich auf Programme, JCL, Datenbanken, Tickets, Betriebsdokumentationen und Arbeitsanweisungen. Ein wichtiger Teil befindet sich häufig nur in den Köpfen erfahrener Mitarbeiter. Diese Menschen wissen, welche Verarbeitung jeden Monatsletzten länger dauert, wann ein Batchlauf manuell neu gestartet werden muss oder warum ein scheinbar überflüssiges Feld nicht entfernt werden darf.

KI kann solche Informationen zusammenführen. Sie kann aber nicht garantieren, dass nichts fehlt.

Auch Daten sind weniger eindeutig, als technische Strukturen vermuten lassen. Ein Feld kann formal sauber definiert sein und trotzdem historisch mehrere fachliche Bedeutungen besitzen. Sonderwerte, manuelle Korrekturen und unterschiedliche Interpretationen in angeschlossenen Systemen sind im Datenmodell nicht zwingend erkennbar.

Wer diese Zusammenhänge übersieht, überträgt alte Missverständnisse direkt in die modernisierte Lösung.

Der dritte Engpass ist die Testbarkeit. Viele Mainframe-Anwendungen laufen seit Jahrzehnten stabil, verfügen aber nicht über eine vollständige automatisierte Testbasis. Seltene Ausnahmefälle, Batchabhängigkeiten und Recovery-Szenarien wurden nie systematisch erfasst.

Damit stellt sich eine unbequeme Frage: Wie soll ein Modernisierungsprojekt seinen Erfolg beweisen, wenn das erwartete Verhalten nicht eindeutig beschrieben werden kann?

Erst belastbares Wissen, verstandene Daten und verlässliche Tests machen aus schneller Analyse eine kontrollierbare Veränderung.

Wenn der Agent programmiert, bleibt die Verantwortung beim Unternehmen

Die nächste Entwicklungsstufe geht über reine Analyse hinaus. KI-Agenten können Dateien verändern, Tests erzeugen, Builds starten und Entwicklungsabläufe selbstständig ausführen.

Damit werden sie vom unterstützenden Werkzeug zum handelnden Akteur.

Eine Änderung kann technisch korrekt sein und trotzdem fachlich falsch. Sie kann alle automatisierten Tests bestehen und einen seltenen Sonderfall übersehen. Sie kann die Performance verbessern und zugleich ein wichtiges Betriebsverfahren beschädigen.

Das Problem besteht nicht darin, dass KI Fehler machen kann. Menschen machen ebenfalls Fehler. Entscheidend ist, wie eine Entscheidung zustande kommt, ob sie nachvollziehbar bleibt und wer für die Folgen einsteht.

Verantwortung lässt sich nicht an ein Modell delegieren.

Es genügt deshalb nicht, am Ende eines automatisierten Prozesses einen Menschen auf „Freigeben“ klicken zu lassen. Wer eine Änderung verantwortet, muss verstehen können, welche Quellen der Agent verwendet, welche Annahmen er getroffen und welche Auswirkungen er geprüft hat.

Unternehmen benötigen klare Grenzen. Welche Daten darf ein Agent lesen? Welche Dateien darf er verändern? Darf er Builds starten oder Testsysteme konfigurieren? Wann sind ein technisches Review, eine fachliche Abnahme oder ein Vier-Augen-Prinzip erforderlich?

Diese Regeln sind keine bürokratische Bremse. Sie bilden das Betriebsmodell für eine neue Form der Softwareentwicklung.

Die Reife eines KI-gestützten Modernisierungsansatzes zeigt sich daher nicht nur darin, was ein Agent ausführen kann. Sie zeigt sich auch darin, wann er stoppen muss, weil Wissen, Tests oder fachliche Sicherheit fehlen.

Nach dem Hype beginnt die eigentliche Arbeit

KI wird die Mainframe-Modernisierung erheblich verändern. Sie kann Analysen beschleunigen, Wissen zugänglicher machen, Dokumentation erzeugen und Entwicklungsaufgaben automatisieren. Das Potenzial ist real und sollte nicht kleingeredet werden.

Es wäre jedoch ein Fehler, Geschwindigkeit mit Sicherheit und plausibel erzeugte Ergebnisse mit fachlicher Gewissheit zu verwechseln.

Mainframe-Modernisierung nach dem KI-Hype bedeutet, Automatisierung und Verantwortung gemeinsam zu gestalten.

Die entscheidende Frage lautet nicht mehr, ob KI COBOL lesen oder Java erzeugen kann. Die entscheidende Frage lautet, ob Unternehmen die Ergebnisse verstehen, überprüfen und verantworten können.

Die Zukunft gehört deshalb vermutlich nicht dem vollständig autonomen Agenten. Sie gehört den Organisationen, die KI konsequent nutzen, ohne ihr die Entscheidungen zu überlassen, für deren Folgen weiterhin Menschen und Unternehmen einstehen müssen.

Über den Autor: Uwe Graf ist Head of Consulting bei der EasiRun Europa GmbH und gilt auf LinkedIn als eine der profiliertesten Stimmen in Sachen Mainframe-Modernisierung. Seine Beiträge sind fachlich präzise, pointiert – und unverkennbar durch den kleinen Dino, der als Symbol für den Brückenschlag zwischen Tradition und Innovation steht. Für sein Engagement in der Mainframe-Community wurde er 2025 sowohl als IBM Champion als auch als „Influential Mainframer“ von planetmainframe.com ausgezeichnet