Die KI übersetzte 30 Jahre COBOL fehlerfrei. Dann zerstörte sie die Datenbank.

Es war ein Dienstagabend, und ich starrte auf einen Stack-Trace, der keinen Sinn ergab.

Wir hatten mit einem Team aus dem Finanzdienstleistungssektor zusammengearbeitet, das versuchte, ein zentrales Transaktionsmodul von COBOL nach Java zu migrieren. Die KI hatte ihre Arbeit getan — dachten wir zumindest. Der generierte Java-Code war sauber, gut strukturiert und kompilierte ohne einen einzigen Fehler. Die Unit-Tests bestanden. Alle in der Besprechung waren vorsichtig optimistisch. Dann spielten sie ihn in die Testumgebung ein, und die erste Überweisung beschädigte die Datenbank.

Der Fehler lag nicht im Java. Das Java war syntaktisch perfekt. Der Fehler lag in dem, was die KI nie zu Gesicht bekam.

Eine Variable namens TRN-LIMIT — definiert nicht in der Quelldatei, die die KI übersetzte, sondern in einem COPYBOOK, das Tausende Zeilen früher in der Ausführungskette eingebunden wurde — enthielt eine REDEFINES. Das ist ein COBOL-Konstrukt, bei dem dieselbe Speicheradresse je nach einem Flag, das in einem völlig anderen Modul gesetzt wird, als zwei verschiedene Datentypen interpretiert wird. Die KI sah TRN-LIMIT als einfaches numerisches Feld. Das war es nicht. Es war eine gepackte Dezimalzahl, die sich je nach Laufzeitkontext als Ganzzahl ausgab. Die KI halluzinierte eine Standarddefinition, und die Java-Anwendung schrieb beschädigte Binärdaten in eine Datenbankspalte.

In jener Nacht, als ich mit meinem Team in einem Konferenzraum saß und auseinandernahm, was schiefgelaufen war, wurde mir etwas klar, das alles neu prägen sollte, was wir bei Veriprajna aufgebaut haben: Die KI versagte nicht, weil sie dumm war. Sie versagte, weil sie blind war.

Das 1,52-Billionen-Dollar-Problem, über das niemand sprechen will

Hier ist die unbequeme Realität der Weltwirtschaft im Jahr 2025: 43 % der Bankensysteme laufen noch immer auf COBOL, und diese Systeme wickeln 95 % aller Geldautomatentransaktionen ab. Die Software, auf der Fortune-500-Unternehmen laufen? Rund 70 % davon wurde vor über zwei Jahrzehnten geschrieben. Allein in den USA ist die technische Schuld auf geschätzte 1,52 Billionen Dollar angeschwollen.

Und die Menschen, die diesen Code geschrieben haben, gehen in Rente. Nicht „könnten irgendwann in Rente gehen“ — sie gehen jetzt und nehmen jahrzehntelanges institutionelles Wissen mit sich. Unterdessen fließen 80 % der föderalen IT-Budgets in die Aufrechterhaltung von Altsystemen, sodass kaum 20 % für Neues übrig bleiben.

Ich habe CTOs gegenübergesessen, die ihre Modernisierungssituation so beschreiben, wie man ein Haus mit bröckelndem Fundament beschreiben würde: Man weiß, dass man es reparieren muss, man weiß, dass Warten es schlimmer macht, aber jeder Handwerker, der es versucht hat, hat die Sache teurer gemacht, ohne das Problem tatsächlich zu lösen.

Die Zahlen belegen das. Zwischen 70 % und 80 % der Legacy-Modernisierungsprojekte verfehlen ihre Ziele. Das galt schon bevor generative KI ins Spiel kam.

Warum dachten alle, GPT könnte das lösen?

Ich verstehe das. Wirklich. Als GPT-4 erschien, lief der Markt für Softwareberatung auf Hochtouren. Plötzlich hatte jede Firma einen „COBOL-Migrationsbeschleuniger“ — der sich, wenn man unter die Haube schaute, als dünne Hülle um ein Foundation-Modell entpuppte. COBOL-Absatz einfügen, Java-Methode zurückbekommen. Zauberei.

Mein Mitgründer und ich verbrachten Wochen damit, diese Tools zu evaluieren. Wir fütterten sie mit echtem Legacy-Code aus Kundenumgebungen und prüften die Ausgabe. Die Syntax war fast immer korrekt. Der Code kompilierte. Und dann versagte er auf eine Weise, die unglaublich schwer zu diagnostizieren war, weil die Form des Codes richtig aussah, selbst wenn die Bedeutung falsch war.

Der gefährlichste Fehler ist nicht der, der Ihr System zum Absturz bringt. Es ist der, der Ihre Daten sechs Monate lang stillschweigend beschädigt, bevor es jemand bemerkt.

Das Problem ist architektonischer Natur, und es hängt damit zusammen, wie große Sprachmodelle Informationen verarbeiten. LLMs verwenden einen Aufmerksamkeitsmechanismus, um die Bedeutung verschiedener Teile ihrer Eingabe zu gewichten. Moderne Modelle rühmen sich mit Kontextfenstern von bis zu einer Million Token. Doch die Forschung hat ein Phänomen nachgewiesen, das als „Lost in the Middle“-Effekt bezeichnet wird: LLMs weisen eine U-förmige Leistungskurve auf; sie erinnern sich gut an Informationen am Anfang und Ende eines Prompts, verschlechtern sich aber erheblich bei allem, was in der Mitte steht.

In einem Modernisierungsprojekt kann ein einziges COBOL-Programm Tausende Zeilen lang sein und Copybooks referenzieren, die selbst Tausende Zeilen lang sind. Wenn die Definition von MAX-TRANSACTION-LIMIT in der Mitte dieses gewaltigen Kontexts sitzt, ist es statistisch wahrscheinlich, dass die KI sie übersieht. Und wenn sie etwas übersieht, hält sie nicht inne und fragt nach. Sie halluziniert. Sie erfindet eine plausible Definition und macht weiter.

Was passiert, wenn man Code wie Text behandelt?

Das ist der Kernfehler, den ich das gesamte „KI-Wrapper“-Ökosystem begehen sehe, und es ist das Argument, das ich anfangs immer wieder mit einem potenziellen Investor hatte. Er sah sich unseren Ansatz an — den Aufbau von Wissensgraphen aus Code-Repositorys — und sagte: „Warum nicht einfach ein größeres Kontextfenster verwenden? GPT-5 wird das lösen.“

Ich öffnete ein COBOL-Programm auf meinem Laptop. „Finde mir die Definition von ACCOUNT-BALANCE“, sagte ich.

Er durchsuchte die Datei. Konnte sie nicht finden. Weil sie nicht in dieser Datei war. Sie befand sich in einem Copybook, eingebunden über eine Anweisung in Zeile 47, die ihrerseits eine gemeinsam genutzte Datendivision referenzierte, die von einem völlig anderen Team gepflegt wurde.

„Nun stell dir vor, du bist ein LLM“, sagte ich. „Du führst eine Vektor-Ähnlichkeitssuche nach Code zum Thema ‚Zahlungsabwicklung‘ durch. Du findest fünf Chunks, die das Wort ‚Zahlung‘ erwähnen. Du übersiehst völlig die Datei namens GlobalVarDef.cbl, die den von der Zahlungslogik verwendeten Steuersatz definiert — weil diese Datei das Wort ‚Zahlung‘ nirgends erwähnt.“

Standard-Retrieval-Augmented-Generation, kurz RAG — die Technik, die die meisten KI-Coding-Tools nutzen, um LLMs mit Wissen anzureichern —, ruft Kontext auf Basis textueller Ähnlichkeit ab. Sie wandelt Code in Vektoren um und findet ähnliche Vektoren. Für FAQ-Chatbots funktioniert das wunderbar. Für Code ist es katastrophal unzureichend.

Code ist keine natürliche Sprache. „The cat sat on the mat“ bedeutet ungefähr dasselbe, unabhängig davon, was man fünfzig Seiten zuvor gelesen hat. Aber x = y + 1 bedeutet nichts, es sei denn, man kennt die Definitionen, Typen und aktuellen Zustände von x und y — die möglicherweise in einer anderen Datei, einem anderen Modul definiert oder von einer übergeordneten Klasse geerbt sind.

Ich habe ausführlich über dieses strukturelle Problem geschrieben, in der interaktiven Version unserer Forschung. Die Kurzfassung: Software ist kein Text. Software ist ein Graph.

Die Nacht, in der wir aufhörten, einen besseren Wrapper zu bauen

Es gab einen Moment — ich erinnere mich klar daran —, als mein Team über unsere Architektur debattierte. Wir hatten zwei Wege. Weg eins: eine intelligentere RAG-Pipeline bauen. Besseres Chunking, bessere Embeddings, bessere Prompts. Den Wrapper-Ansatz iterieren, bis er gut genug funktioniert. Weg zwei: das textbasierte Paradigma komplett verwerfen und Code als das behandeln, was er tatsächlich ist — ein relationales System aus Logik.

Weg eins war schneller. Weg eins war das, was Investoren verstanden. Weg eins hatte bereits ein Dutzend Konkurrenten, die die Marktnachfrage belegten.

Meine leitende Ingenieurin ging an ein Whiteboard und zeichnete ein COBOL-Programm als Graph. Knoten für Variablen, Funktionen, Copybooks, Datenbanktabellen. Kanten für CALLS, READS, UPDATES_TABLE, IMPORTS_COPYBOOK. Dann verfolgte sie eine Abhängigkeitskette: Modul A ruft Modul B auf, das Variable X verändert, die von Modul C in einem völlig anderen Verzeichnis gelesen wird.

„Lass eine Vektorsuche diese Kette finden“, sagte sie.

Niemand konnte es.

Das war die Nacht, in der wir uns dazu verpflichteten, das zu bauen, was wir heute einen Repository-Aware Knowledge Graph nennen — eine einheitliche Graphdatenbank, die die statische Struktur des Codes (abstrakte Syntaxbäume, Aufrufgraphen) mit der semantischen Bedeutung der Geschäftslogik (Dokumentation, Kommentare, Variablenabsicht) kombiniert. Wir wollten keinen besseren Übersetzer bauen. Wir wollten eine Karte bauen.

Wie verwandelt man dreißig Jahre COBOL in eine Karte?

Der Prozess hat vier Phasen, und ich erspare Ihnen die Implementierungsdetails — die finden Sie in unserer vollständigen technischen Tiefenanalyse. Aber die Konzepte sind wichtig, denn sie erklären, warum dieser Ansatz dort funktioniert, wo Wrapper scheitern.

Erstens: Wir parsen Code strukturell, nicht textuell. Standard-RAG-Pipelines verwenden „naives Splitting“ — sie zerschneiden eine Datei alle 500 Token und trennen dabei oft eine Funktionssignatur von ihrem Rumpf. Wir verwenden Parser wie Tree-sitter, um abstrakte Syntaxbäume zu erzeugen, die die logischen Grenzen des Codes respektieren. Eine Funktion wird als vollständige Logikeinheit behandelt, nicht als zufälliger Textabschnitt.

Zweitens: Wir extrahieren Entitäten und Beziehungen. Klassen, Paragraphen, Variablen, Datenbanktabellen, API-Endpunkte — diese werden zu Knoten. Die Kanten zwischen ihnen — CALLS, UPDATES_TABLE, DEFINES_VARIABLE — werden zum verbindenden Gewebe. Wir können den Graphen nun abfragen: „Zeig mir jeden Paragraphen, der das Feld CUSTOMER-ID aktualisiert.“ Exakte Ergebnisse, sofort. Versuchen Sie das mal mit grep.

Drittens — und hier wird es interessant — lösen wir Symbole über das gesamte Repository hinweg auf. Ein Standardparser sieht ACCT-NUM in Datei A und ACCT-NUM in Datei B als zwei verschiedene Zeichenketten. Unser System stellt fest, dass sich beide auf denselben Eintrag in einem gemeinsam genutzten Copybook beziehen, und führt sie zu einem einzigen Knoten zusammen. Wir führen außerdem Dokumentation mit Code zusammen: Wenn ein PDF-Anforderungsdokument die „User API“ beschreibt und der Code eine Klasse namens UserAPI enthält, verknüpft das System Absicht mit Implementierung.

Viertens: Wir berechnen die transitive Hülle. Erinnern Sie sich an das Bankversagen? A hängt von B ab, B hängt von C ab, und die KI sah A, übersah aber C. Unser Graph durchläuft tiefgehend — A zu B zu C —, um die Wurzeldefinition jeder Variable zu ermitteln. Wenn die KI Code für Modul A generiert, importiert sie die korrekten Definitionen aus Modul C, selbst wenn Modul C in einem völlig anderen Verzeichnis oder Repository liegt.

Warum scheitert Standard-RAG bei der Code-Migration?

Da gibt es immer Widerspruch. „RAG funktioniert doch für Code“, sagen die Leute. „Nimm einfach bessere Embeddings.“

Lassen Sie mich drei Szenarien nennen, in denen die Vektor-Ähnlichkeitssuche völlig zusammenbricht:

Ein Entwickler benennt Account in Acct um. Die semantische Ähnlichkeit sinkt, obwohl die Logik identisch ist. Eine Funktion namens FNC-001 führt eine Zinsberechnung durch, enthält aber keine Kommentare — eine Suche nach „Zinsberechnung“ wird sie nie finden. Und der häufigste Fehlschlag: Vektor-RAG ruft einen Unit-Test und einen UI-Kommentar ab, die „Zahlung“ erwähnen, verfehlt aber die zentrale Geschäftslogik, weil die Variablennamen nicht mit den Suchbegriffen übereinstimmen.

Graphbasierte Abfrage fragt nicht „Welcher Text sieht ähnlich aus?“ Sie fragt „Was ist logisch verbunden?“ — und dieser Unterschied ist der Unterschied zwischen Code, der kompiliert, und Code, der funktioniert.

Was wir GraphRAG nennen, arbeitet mit Struktur, nicht mit Ähnlichkeit. Wenn jemand sagt „Refaktoriere die Zahlungslogik“, nutzt das System die Vektorsuche, um den Einstiegspunkt zu finden — etwa den ProcessPayment-Paragraphen. Aber dann durchläuft es, statt anzuhalten, die Kanten des Graphen. Es zieht die Subroutinen über CALLS-Kanten heran, die Variablendefinitionen über READS-Kanten, die Copybooks über INCLUDES-Kanten. Diese verbundenen Teile mögen textuell unähnlich, aber logisch untrennbar sein.

Untersuchungen zeigen, dass GraphRAG Vektor-RAG beim Multi-Hop-Reasoning deutlich übertrifft — dem Verknüpfen von Fakten, die mehrere Schritte voneinander entfernt sind. In der Software ist nahezu jeder ernsthafte Fehler ein Versagen des Multi-Hop-Reasonings. Wenn ich die Zinssatzlogik in Modul A ändere, welche Reporting-Bildschirme in Modul Z brechen dann? Vektor-RAG kann das nicht beantworten. Der Graph kann es, weil er die Kette von Funktionsaufrufen durchläuft, die sie verbindet.

Das GOTO-Problem (oder: Warum COBOL die KI Schleifen halluzinieren lässt)

Ich möchte Ihnen von einer bestimmten technischen Herausforderung erzählen, die uns fast zerbrochen hätte, denn sie veranschaulicht, warum diese Arbeit so viel schwieriger ist, als die Leute annehmen.

COBOL hat eine GOTO-Anweisung. Java nicht. GOTO lässt die Programmausführung überallhin springen — vorwärts, rückwärts, mitten in einen anderen Block. Es erzeugt den „Spaghetticode“, vor dem Sie jeder Informatikprofessor warnt. Das Übersetzen von GOTO ist kein Syntaxproblem. Es ist ein Topologieproblem.

Wir beobachteten, wie drei verschiedene kommerzielle KI-Tools versuchten, ein COBOL-Modul mit starker GOTO-Nutzung zu übersetzen. Eines generierte einen rekursiven Funktionsaufruf, der in der Produktion einen StackOverflowError verursacht hätte. Ein anderes erzeugte eine while(true)-Schleife ohne Abbruchbedingung. Das dritte — mein persönlicher Favorit — erfand einfach einen Kontrollfluss, der im Originalcode nicht existierte. Er sah plausibel aus. Er war völlig falsch.

Unser Ansatz: die GOTO-Ziele als Kanten in einem Kontrollflussgraphen abbilden. Dann Mustererkennung auf dem Graphen anwenden. Ein GOTO, das zu einem früheren Label zurückspringt? Das ist eine Schleife. Ein GOTO, das einen Block überspringt? Das ist eine Bedingung. Ein GOTO zu einem Exit-Paragraphen? Das ist eine Return-Anweisung. Die KI refaktoriert diese Sprünge, geleitet von der Graphstruktur, in while-Schleifen, if/else-Blöcke oder break/continue-Anweisungen.

Ohne den Graphen rät die KI. Mit dem Graphen betreibt sie Ingenieurskunst.

Der Unterschied zwischen einem Chatbot und einem Agenten

Wir bauen keine Chatbots. Das muss ich klarstellen, denn der Markt ist überschwemmt mit Tools, mit denen man „mit seiner Codebasis chatten“ kann, und das ist nicht dasselbe.

Ein Chatbot nimmt Ihre Frage, schickt sie an GPT-4 und gibt zurück, was auch immer herauskommt. Wenn die Ausgabe falsch ist, debuggen Sie sie manuell. Das ist der Workflow für jeden KI-Wrapper auf dem Markt.

Was wir einsetzen, sind autonome Agenten, die planen, ausführen und sich selbst korrigieren. Der Agent analysiert den AST der Ziel-COBOL-Datei, identifiziert Abhängigkeiten, fragt den Wissensgraphen ab, generiert Java-Code und kompiliert ihn dann in einer Sandbox. Wenn der Compiler einen Fehler wirft — „Variable nicht gefunden“ —, liest der Agent den Fehler, fragt den Graphen nach der fehlenden Abhängigkeit ab und generiert neu. Dann führt er Unit-Tests aus, die aus den ursprünglichen COBOL-Ausführungsspuren abgeleitet sind, um die Verhaltensäquivalenz zu überprüfen.

Diese Compile-Fix-Schleife verlagert die Validierungslast vom Menschen auf das System. Aber — und das ist in regulierten Branchen enorm wichtig — der Wissensgraph bietet vollständige Interpretierbarkeit. Ein Entwickler kann genau sehen, warum die KI jede Entscheidung getroffen hat: „Die KI hat com.bank.logic importiert, weil sie eine Abhängigkeit von COPYBOOK-X fand.“ Nicht „vertrau mir, ich bin eine KI.“ Stattdessen: Hier ist die Zitationskette für diese Logik.

Im Bankwesen muss jede Codezeile prüfbar sein. Man kann keine Blackbox einsetzen, die es „wahrscheinlich“ richtig gemacht hat. Man braucht ein System, das seinen Lösungsweg zeigen kann.

Was ist mit totem Code?

Eine Sache hat mich überrascht: Altsysteme sind voll von Code, den niemand mehr nutzt. Alte Aktionen, ausgemusterte Produkte, Debug-Routinen aus dem Jahr 1997. Eine textbasierte KI migriert alles, was man ihr gibt — sie kann aktiven Code nicht von totem Code unterscheiden.

Unser Aufrufgraph identifiziert unerreichbare Knoten — Paragraphen oder Dateien ohne eingehende Kanten, das heißt, nichts ruft sie auf. Wir markieren diesen toten Code zur Löschung, bevor die Migration beginnt. Unserer Erfahrung nach verringert das die Codebasis typischerweise um 20–30 %. Das ist keine geringfügige Optimierung. Das eliminiert ein Viertel der Arbeit und ein Viertel der Angriffsfläche.

„Lösen größere Kontextfenster das nicht?“

Diese Frage bekomme ich immer noch ständig. Die Annahme ist, dass das „Lost in the Middle“-Problem verschwindet, wenn GPT-5 oder Claude 4 zehn Millionen Token verarbeiten können.

Wird es nicht. Und hier ist der Grund.

Selbst wenn sich die Aufmerksamkeitsdegradation verbessert — und das wird sie —, betreiben Sie immer noch Text-Retrieval. Sie suchen immer noch nach ähnlichen Zeichenketten, statt logische Verbindungen zu durchlaufen. Ein Kontextfenster von einer Million Token hilft nicht, wenn die benötigte Variable in einer Datei definiert ist, die null Schlüsselwörter mit der Datei teilt, die Sie gerade übersetzen. Das Problem ist nicht die Größe des Fensters. Das Problem ist, dass das Fenster auf das Falsche schaut.

Der andere Einwand, den ich höre: „Wissensgraphen sind teuer im Aufbau.“ Sind sie. Ein ganzes Repository zu parsen, Symbole aufzulösen, die transitive Hülle zu berechnen — das ist eine erhebliche Vorabinvestition. Aber bedenken Sie die Alternative. Die manuelle Migration eines großen COBOL-Systems kostet zweistellige Millionenbeträge und dauert Jahre. Wrapper-basierte KI-Migration kostet vorab weniger, erzeugt aber einen stetigen Strom halluzinationsbedingter Fehler, die teures menschliches Debugging erfordern. Der graphbasierte Ansatz hat höhere Einrichtungskosten und dramatisch niedrigere Nacharbeitskosten. Daten von McKinsey legen nahe, dass GenAI Coding-Aufgaben um 50 % reduzieren kann, aber nur bei korrekter Umsetzung. Wir haben im Vergleich zu Standard-KI-Tools eine 2- bis 3-fache Steigerung der Entwicklerproduktivität gesehen, gerade weil Entwickler keine Stunden mehr damit verbringen, herauszufinden, wo eine Variable definiert ist.

Die Karte ist der Vermögenswert

Das hätte ich am Anfang gern verstanden: Der Wissensgraph ist nicht nur ein Werkzeug für die Migration. Er ist ein dauerhafter Vermögenswert.

Sobald Ihre Codebasis als Graph existiert, bleibt sie eine lebendige Repräsentation Ihres Systems. Während sich der neue Java-Code weiterentwickelt, aktualisiert sich der Graph. Sie erhalten automatisierte Dokumentation, die stets aktuell ist. Sie erhalten eine Erkennung von Architekturdrift — das System warnt Sie, wenn neuer Code die von Ihnen definierten Modularitätsregeln verletzt. Sie erhalten Impact-Analyse auf Abruf: „Wenn ich diese Methode ändere, was bricht dann?“

Modernisierung ist kein einmaliges Ereignis. Sie ist ein Lebenszyklus. Die Organisationen, die sie als Projekt behandeln — mit einem Start- und einem Enddatum —, landen in fünf Jahren wieder dort, wo sie angefangen haben, ertrinkend in einer neuen Generation technischer Schulden.

Code ist kein Text

Die Lektion, zu der ich immer wieder zurückkehre — jene aus der Dienstagnacht, in der ich auf einen Stack-Trace starrte —, ist täuschend einfach: Code ist kein Text, und Werkzeuge, die ihn als Text behandeln, erzeugen Ergebnisse, die richtig aussehen und sich falsch verhalten.

Die gesamte „KI-Wrapper“-Wirtschaft beruht auf einem Kategorienfehler. Sie geht davon aus, dass LLMs, weil sie außergewöhnlich gut Sprache verarbeiten, auch außergewöhnlich gut Code verarbeiten müssen. Aber Code ist keine Sprache. Code ist ein Graph — ein dichtes, vernetztes System aus Abhängigkeiten, Datenflüssen und Zustandsänderungen, das gleichzeitig in mehreren Dimensionen existiert. Zu versuchen, ihn mit textbasierten Werkzeugen zu modernisieren, ist wie das Navigieren durch eine Stadt mit einer Liste von Straßennamen, aber ohne Karte. Sie werden sich „in der Mitte verlieren“.

Wir haben die Karte gebaut. Und sie funktioniert — nicht weil wir klüger sind als die Teams, die Foundation-Modelle bauen, sondern weil wir eine andere Frage gestellt haben. Sie fragten: „Wie bringen wir KI dazu, Text besser zu verstehen?“ Wir fragten: „Was, wenn das Problem gar nicht der Text ist?“

Die Zukunft der Legacy-Modernisierung ist kein größeres Sprachmodell. Es ist ein System, das Software so versteht, wie Software tatsächlich funktioniert — als Struktur, nicht als Zeichenketten.

Das ist die Wette, die wir bei Veriprajna eingegangen sind. Jeden Tag entdeckt eine weitere Organisation, dass ihr KI-generiertes Java wunderbar kompiliert und katastrophal versagt. Jeden Tag wird die Kluft zwischen syntaktischer Übersetzung und semantischem Verständnis teurer zu ignorieren. Die Organisationen, die diese Kluft schließen, werden ihren Code nicht nur modernisieren. Sie werden ihn endlich verstehen — viele von ihnen zum ersten Mal.