Die Architektur des Verstehens: Jenseits der Syntax in der Enterprise-Legacy Modernisierung

Zusammenfassung

Die Modernisierung von Enterprise-Legacy-Systemen—insbesondere die Migration von Mainframe- Architekturen in Cloud-native Umgebungen—hat in der Mitte der 2020er-Jahre einen kritischen Wendepunkt erreicht. Über Jahrzehnte haben der Finanz- und der Regierungssektor unter einem paradoxen Paradigma operiert: Der Imperativ zur Modernisierung ist existenziell, doch die Misserfolgsquote solcher Initiativen bleibt katastrophal hoch und pendelt zwischen 70% und 80%. ¹ Das jüngste Aufkommen von Large Language Models (LLMs) versprach eine Revolution und bot die verlockende Möglichkeit der automatisierten Code-Übersetzung. Frühe Adoptionszyklen haben jedoch eine kritische, systemische Schwäche standardmäßiger generativer KI-Ansätze offenbart, wenn sie auf komplexe, monolithische Repositories angewendet werden.

Wir erleben derzeit das Entstehen einer neuen Kategorie von Engineering-Fehlern, typisiert durch das apokryphe, aber höchst realistische Szenario einer Großbank, die versucht, dreißig Jahre COBOL mit einem kommerziellen Coding-Assistenten nach Java umzuschreiben. Die KI, die als ausgefeilter lokaler Übersetzer fungierte, konvertierte die Syntax perfekt. Die resultierende Anwendung ließ jedoch bei der Bereitstellung die Datenbank abstürzen. Der Fehler war keiner der Syntax, sondern des Kontexts. Die KI, eingeschränkt durch das „Lost in the Middle“-Syndrom und ein textbasiertes Verständnis von Software, übersah eine kritische Variablenabhängigkeit, die Tausende von Zeilen vor dem Ausführungsblock definiert war. ³

Dieses Whitepaper, vorgelegt von Veriprajna, argumentiert, dass der vorherrschende „LLM-Wrapper“- Ansatz—der Code als lineare Sequenz von Text-Tokens behandelt—grundsätzlich ungeeignet ist für die nichtlineare Komplexität der Enterprise-Modernisierung. Software ist kein Text; sie ist ein Graph. Sie ist ein hoch strukturiertes System logischer Abhängigkeiten, Datenflüsse und Zustandsänderungen, das in einem mehrdimensionalen topologischen Raum existiert. ⁵

Wir vertreten die Auffassung, dass der einzig gangbare Weg die Einführung von Repository-Aware Knowledge Graphs ist. Indem wir von stochastischer Textvorhersage zu graphbasiertem deterministischem Schließen übergehen, können wir Variablenabhängigkeiten über Millionen von Codezeilen hinweg abbilden, das „Lost in the Middle“-Phänomen auflösen und Modernisierung von einem riskanten Glücksspiel in einen mathematisch verifizierbaren Engineering-Prozess verwandeln. ⁷ Dieses Dokument skizziert den technischen Übergang von oberflächlicher Syntaxübersetzung zu tiefer, semantischer Strukturtransformation.

Kapitel 1: Die stille Krise der Legacy- Infrastruktur

1.1 Das Modernisierungsparadox

In der heutigen Digitalwirtschaft stützt sich die Infrastruktur des globalen Handels prekär auf Technologie, die während des Kalten Krieges entwickelt wurde. Es ist eine erschreckende, oft unerkannte Realität, dass im Jahr 2025 eine deutliche Mehrheit der weltweiten Finanz-, Gesundheits- und Regierungssysteme von Legacy-Codebasen betrieben wird—monolithischen Anwendungen, geschrieben in Sprachen wie COBOL, PL/I und RPG, die längst aus den Mainstream-Informatik-Curricula verschwunden sind. Diese Systeme sind nicht bloß „alt“; sie sind das Fundament der Weltwirtschaft, und doch erodieren sie in alarmierendem Tempo.

Die Statistiken zeichnen ein düsteres Bild dieser Abhängigkeit. Rund 70% der Software, die in Fortune-500-Unternehmen läuft, wurde vor über zwei Jahrzehnten entwickelt. ⁹ Im Bankensektor ist die Lage noch akuter: 43% der Banksysteme basieren auf COBOL, und diese Systeme verarbeiten 95% aller Geldautomaten-Transaktionen. ¹ Wir betreiben faktisch die moderne Sofortzahlungsökonomie auf einem digitalen Fundament, das älter ist als das Internet.

Die Kosten, diesen Status quo aufrechtzuerhalten, explodieren. Technische Schuld hat sich auf geschätzte geschätzte $1.52 Billionen allein in den USA. ¹ Organisationen sind in einem Zyklus des „keeping the lights on“ gefangen, wobei 80% der bundesstaatlichen IT-Budgets in Betrieb und Wartung fließen und nur magere 20% für Innovation bleiben. ⁹ Dieser Ressourcenabfluss wird durch einen gravierenden Fachkräftemangel verschärft; während die Generation der Entwickler, die diese Systeme geschrieben hat, in den Ruhestand geht, verschwindet das institutionelle Wissen, das zu ihrer Wartung nötig ist. ¹⁰

Tabelle 1: Die wirtschaftliche Last von Legacy-Systemen

Kennzahl	Statistik	Quelle
Kosten technischer Schuld (USA)	$1.52 Billionen	1
Bundesstaatliche IT-Wartung Budget	~80% der Gesamtausgaben	9
Abhängigkeit im Bankwesen	95% der Geldautomaten-Transaktionen auf COBOL	1

Wahrscheinlichkeit einer Datenschutzverletzung	3x höher bei Systemen >10 Jahre alt	11
Entwicklerfluktuation	58% erwägen Kündigung wegen Legacy-Stacks	1

Diese Daten zeigen eine systemische Verwundbarkeit. Der Modernisierungsimperativ geht nicht bloß um Kostensenkung; es geht ums Überleben. Systeme älter als zehn Jahre haben statistisch dreimal häufiger eine Sicherheitsverletzung als moderne Anwendungen. ¹¹ Während regulatorische Anforderungen an Datenschutz und Echtzeit-Reporting strenger werden (z. B. DSGVO, DORA), wird die Unfähigkeit von Legacy-Systemen, sich anzupassen, zu einem Compliance-Risiko höchster Ordnung.

1.2 Die Anatomie des „Bank-Ausfalls“

Um die Notwendigkeit eines neuen Ansatzes zu verstehen, müssen wir das Szenario sezieren, das zum „Patienten Null“ der KI-Modernisierungsfehler geworden ist. Diese Fallstudie, referenziert von der Veriprajna-Führung, illustriert den konkreten Mechanismus, durch den Standard-KI in Enterprise-Umgebungen versagt.

Ein großes Finanzinstitut startete ein Projekt zur Migration eines Kern-Transaktionsverarbeitungssystems von einem IBM-Mainframe (COBOL/DB2) zu einer Cloud-nativen Java-Microservices-Architektur. Die Bank nutzte einen beliebten KI-Coding-Assistenten—im Wesentlichen einen Wrapper um ein Foundation- Modell—, um den Code zu übersetzen.

Die KI nahm ein COBOL-Programm auf, das hochwertige Überweisungen verarbeitete. Das Programm enthielt eine komplexe COMPUTE-Anweisung mit einer Variable, die wir TRN-LIMIT nennen. Die KI übersetzte die Syntax perfekt. Sie wandelte die COMPUTE-Anweisung in eine Java- BigDecimal-Operation um. Der Code kompilierte. Die Unit-Tests—generiert von derselben KI auf Basis des lokalen Codeblocks—bestanden.

Bei der Bereitstellung in der User-Acceptance-Testing-(UAT-)Umgebung ließ jedoch die erste Transaktion die Datenbank-Konsistenzprüfung abstürzen.

Die Autopsie: Die Variable TRN-LIMIT war nicht in der Quelldatei definiert, die die KI übersetzte. Sie war in einem COPYBOOK definiert (einer gemeinsamen Header-Datei), das Tausende von Zeilen früher in der Ausführungskette eingebunden war. Noch wichtiger: Dieses COPYBOOK enthielt eine REDEFINES-Klausel—ein COBOL-Konstrukt, das erlaubt, dieselbe Speicheradresse als zwei verschiedene Datentypen zu interpretieren, abhängig von einem Flag, das in einem völlig anderen Modul gesetzt wird. Die KI, die auf einem Text-„Chunk“ operierte, sah TRN-LIMIT als einfaches numerisches Feld. Sie sah nicht die REDEFINES-Klausel, weil diese in einer anderen Datei lag, die nicht im unmittelbaren Kontextfenster war. Sie „halluzinierte“ eine Standarddefinition für die Variable. In der Mainframe- Umgebung hielt die Speicheradresse ein Packed Decimal; in der Java-Umgebung behandelte die KI es als Standard-Integer. Die Diskrepanz führte dazu, dass die Java-Anwendung korrumpierte Binärdaten in die Datenbankspalte schrieb und einen referenziellen Integritätsfehler auslöste. ⁴

Der Fehler war keiner der Syntax; der Java-Code war syntaktisch perfekt. Der Fehler war einer der kontextuellen Blindheit . Die KI übersah eine Abhängigkeit, die außerhalb ihres „Sichtfelds“ lag, was zu einer katastrophalen semantischen Divergenz führte.

1.3 Das Dilemma „Lift and Shift“ vs. Refactoring

Die Erfolgsbilanz der Branche bei der Modernisierung ist miserabel, schon vor der Einführung von generativer KI. Untersuchungen zeigen, dass zwischen 70% und 80% der Digital-Transformation- und Legacy-Modernisierungsprojekte ihre Ziele nicht erreichen. ²

Traditionell standen Organisationen vor einer binären Wahl:

1.​ Rehost (Lift and Shift): Verschieben der kompilierten Anwendung auf einen Emulator in der Cloud. Dies bewahrt den „Spaghetti-Code“ und die Schuld und ändert lediglich die Hosting-Rechnung. Es gelingt nicht, die Agilität der Cloud zu erschließen. ¹⁴

2.​ Rewrite (Refactor): Manuelles Umschreiben des Codes in einer modernen Sprache. Das ist astronomisch teuer, langsam und riskant wegen fehlender Dokumentation und der „Big- Ball-of-Mud“-Architektur, in der Geschäftslogik untrennbar mit Datenzugriff verflochten ist. ¹⁰

Generative KI sollte einen „dritten Weg“ bieten—automatisiertes Refactoring. Der „Bank-Ausfall“ beweist jedoch, dass KI ohne tieferes Verständnis der Software-Topologie lediglich die Erzeugung fehlerhaften Codes beschleunigt.

Kapitel 2: Das Versagen stochastischer Übersetzung

2.1 Die „Wrapper“-Ökonomie und ihre Grenzen

In dieses Hochrisiko-Umfeld trat der „LLM-Wrapper“. Die unmittelbare Reaktion des Software-Beratungsmarkts auf die Veröffentlichung von GPT-4 war die Proliferation von Tools, die als dünne Softwareschichten zwischen einem Entwickler und einem Foundation-Modell agieren. ¹⁵ Diese Tools versprechen, mit Ihrem Code zu „chatten“, sodass Entwickler einen COBOL-Absatz einfügen und eine Java- Methode zurückerhalten.

Obwohl diese Wrapper die Einstiegshürde für KI-Adoption senken, sind sie grundlegend fehlerhaft, wenn sie auf großskaliges System-Re-Engineering angewendet werden. Wrapper stützen sich typischerweise auf Naïve RAG (Retrieval-Augmented Generation). Dabei nimmt das System eine Nutzeranfrage, durchsucht eine Vektordatenbank nach Code-Snippets, die der Anfrage textuell ähnlich sind, und speist diese Snippets dem LLM als Kontext. ¹⁷

Die Grenzen dieses Ansatzes im Enterprise-Kontext sind gravierend:

1.​ Kontextuelle Myopie: Ein Wrapper sieht Code als Textsegmente. Er versteht nicht, dass eine Variable ACCOUNT-BALANCE, die in SECTION-A modifiziert wird, eine Entscheidungslogik in SECTION-Z fünftausend Zeilen entfernt steuert.

2.​ Syntaktischer Erfolg, semantisches Versagen: Wie erwähnt kann ein LLM Java-Code erzeugen, der perfekt kompiliert, aber das exakte Laufzeitverhalten des originalen COBOL nicht repliziert, weil er eine globale Zustandsänderung übersehen hat. ⁴

Veriprajna unterscheidet sich, indem es die Philosophie des „dünnen Wrappers“ ablehnt. Wir behaupten, dass tiefe KI-Lösungen die Struktur des Repositories verstehen müssen, nicht nur den Text der Datei.

2.2 Das „Lost in the Middle“-Syndrom

Um zu verstehen, warum Standard-KI bei der Legacy-Modernisierung versagt, müssen wir die kognitive Architektur von Large Language Models verstehen. Diese Modelle basieren auf der Transformer-Architektur, die einen „Aufmerksamkeitsmechanismus“ nutzt, um die Wichtigkeit verschiedener Teile des Eingabetextes zu gewichten. ¹⁸

Obwohl moderne LLMs massive Kontextfenster vorweisen (bis zu 1 Million Tokens), ist ihre Fähigkeit, diesen Kontext effektiv zu nutzen, nicht gleichmäßig. Empirische Forschung hat ein Phänomen namens „Lost in the Middle“-Effekt nachgewiesen. Wenn ihnen eine lange Informationssequenz präsentiert wird, zeigen LLMs eine U-förmige Leistungskurve:

●​ Primacy Bias: Sie erinnern Informationen am Anfang des Prompts höchst genau.

●​ Recency Bias: Sie erinnern Informationen am Ende des Prompts höchst genau.

●​ Das Tal: Die Leistung fällt für Informationen in der Mitte deutlich ab. ³

In einem Modernisierungsprojekt kann ein einzelnes COBOL-Programm Tausende von Zeilen lang sein, und es kann Copybooks (Abhängigkeiten) referenzieren, die selbst Tausende von Zeilen lang sind. Wenn die Definition einer kritischen Variable—etwa MAX-TRANSACTION-LIMIT—in der Mitte dieses massiven Kontexts erscheint, übersieht die KI sie statistisch wahrscheinlich. ²¹

Wenn die KI eine Variablendefinition übersieht, hält sie nicht an. Sie „halluziniert“. Sie nimmt einen Standardtyp oder -wert für die Variable an, basierend auf Wahrscheinlichkeit, nicht auf Fakten. In einem Banksystem kann die Annahme, eine Variable sei ein Integer, obwohl sie tatsächlich ein Packed Decimal ist, zu Rundungs- fehlern führen, die Finanzdaten korrumpieren. ²²

Tabelle 2: Die kognitiven Grenzen standardmäßiger LLMs

Phänomen	Beschreibung	Auswirkung auf die Modernisierung
Lost in the Middle	Verminderte Aufmerksamkeit in der Mitte langer Prompts.3	Übersehene Variablendefinitionen, vergraben in großen Dateien.
Halluzination	Erfindung plausibler, aber falscher Fakten.22	Erfinden von Abhängigkeiten oder Logik, um Lücken im Kontext zu füllen.
Primacy/Recency Bias	Fokus auf Anfang/Ende des Textes.20	Ignorieren der Kern-Geschäfts- logik, die in der Mitte einer Prozedur liegt.
Stochastische Generierung	Probabilistische Text- vorhersage.	Inkonsistente Code- generierung; erneutes Ausführen des Prompts liefert andere Logik.

2.3 Der „Bag of Words“ vs. der „Tree of Logic“

Standard-LLMs und Vector-RAG-Systeme verarbeiten Code primär als Sequenz von Tokens. Sie stützen sich auf semantische Ähnlichkeit—prüfen, ob Wörter in der Anfrage mit Wörtern im Dokument- Vektorraum übereinstimmen. ¹⁷

Code ist jedoch keine natürliche Sprache. In natürlicher Sprache hat „The cat sat on the mat“ eine Bedeutung, die weitgehend unabhängig von einem Satz fünfzig Seiten zuvor ist. In Software hat x = y + 1 null Bedeutung, solange wir die Definitionen, Typen und aktuellen Zustände von x und y nicht kennen. Diese Definitionen können in einer anderen Datei, einem anderen Modul existieren oder von einer Eltern- klasse geerbt sein. ⁵

Wenn eine „Wrapper“-KI Kontext für eine Anfrage wie „Refactore die Zahlungslogik“ abruft, könnte sie fünf Code-Chunks holen, die das Wort „payment“ enthalten. Sie wird wahrscheinlich den Chunk namens GlobalVarDef.cbl verfehlen, der den von der Zahlungslogik genutzten Steuersatz definiert, weil diese Datei nie das Wort „payment“ erwähnt.

Diese Diskrepanz markiert die fundamentale Lücke zwischen textuellem Retrieval und strukturellem Verstehen . Um sie zu schließen, müssen wir aufhören, Code als Literatur zu behandeln, und beginnen, ihn als Graph zu behandeln. ²³

Kapitel 3: Die Physik der Software –

Code als Graph

3.1 Software als relationales System

Bei Veriprajna erkennen wir, dass ein Software-Repository fundamental eine relationale Datenbank der Logik ist. Jede Entität in der Codebasis—Variablen, Funktionen, Klassen, Module, Datenbank- schemas—existiert in einem dichten Beziehungsgeflecht.

●​ Containment: Eine Datei enthält eine Klasse; eine Klasse enthält eine Methode; eine Methode enthält eine Variablendeklaration.

●​ Vererbung: Klasse B erbt Eigenschaften und Methoden von Klasse A.

●​ Aufruf: Methode X ruft Methode Y auf.

●​ Datenfluss: Variable Z wird von Funktion Q modifiziert und von Funktion R gelesen.

Diese Beziehungen bilden die „Ground Truth“ der Anwendung. Sie sind nicht probabilistisch; sie sind deterministisch. Wenn Methode X Methode Y aufruft, ist das eine harte Tatsache, keine statistische Wahrscheinlichkeit. Standard-LLMs operieren im probabilistischen Bereich. Um Legacy- systeme sicher zu modernisieren, müssen wir ihre probabilistischen Generierungsfähigkeiten an die deterministische Realität der Codestruktur verankern. ⁷

3.2 Der Abstract Syntax Tree (AST)

Die grundlegende Einheit dieses Strukturverständnisses ist der Abstract Syntax Tree (AST) . Der AST ist eine Baumdarstellung der abstrakten syntaktischen Struktur von Quellcode. Anders als eine rohe Textzeichenkette erfasst ein AST die Hierarchie und die grammatikalischen Regeln der Sprache. ²⁴

Zum Beispiel ist die COBOL-Anweisung: COMPUTE INTEREST = PRINCIPAL * RATE nicht bloß fünf Wörter. In einem AST ist sie ein AssignmentNode mit einem Target (Interest) und einem Expression. Der Expression ist ein MultiplicationNode mit einem LeftOperand (Principal) und einem RightOperand (Rate).26 Indem wir Legacy-Code in ASTs parsen, gehen wir über die Mehrdeutigkeiten von Text hinaus. Wir können programmatisch jede Variablennutzung, jede arithmetische Operation und jeden Kontroll- flusszweig identifizieren. Das erlaubt uns „Round-Trip“-Engineering—Umwandlung von Code in AST und zurück in Code ohne Datenverlust—, sodass unsere Strukturanalyse korrekt ist. ²⁷

Anders als „Text Chunking“ in Standard-RAG—wo eine Datei blind in 500-Token- Segmente geschnitten wird und oft eine Funktion halbiert—respektiert AST-Parsing die logischen Grenzen des Codes. Eine Funktion wird als diskrete Logikeinheit behandelt, nicht als zufällige Textspanne. ²³

3.3 Der Call Graph und die Abhängigkeitsmatrix

Während der AST die Struktur einer einzelnen Datei darstellt, repräsentiert der Call Graph das Nerven- system der gesamten Anwendung. Er visualisiert den Kontrollfluss und mappt, welche Paragraphs oder system der gesamten Anwendung. Er visualisiert den Kontrollfluss und bildet ab, welche Paragraphs oder ²⁹

In Legacy-COBOL-Systemen sind Call Graphs oft durch dynamische Aufrufe oder GOTO-Logik verdunkelt, die „Spaghetti-Code“ erzeugt. Eine statische Textanalyse kann nicht leicht auflösen, wo ein GOTO LABEL_X landet, wenn LABEL_X dynamisch oder bedingt definiert ist.

Durch Konstruktion eines rigorosen Call Graph identifiziert Veriprajna „Dead Code“ (Code, der nie aufgerufen wird) und „God Classes“ (Module, die zu stark gekoppelt sind). Diese Analyse ist kritisch, um Monolithen in Microservices zu zerlegen. Wenn wir die vollständige Aufrufkette nicht kennen, können wir einen Service nicht sicher extrahieren; wir riskieren eine „dangling reference“, die einen Laufzeitfehler verursacht—genau das Szenario, das die Bank in unserer Eröffnungsfallstudie plagte. ³¹

Tabelle 3: Strukturanalyse vs. Textanalyse

Merkmal	Textanalyse (Standard- KI)	Strukturanalyse (Veriprajna)
Analyseeinheit	Token / Wort	Knoten (AST-Element)
Kontextgrenze	Beliebiges Token-Limit	Logischer Scope (Funktion/Klasse)
Abhängigkeitsauflösung	Keyword-Matching	Graph-Traversal
GOTO-Behandlung	Behandelt als Textstring	Mappt Kontrollflusskanten
Genauigkeit	Probabilistisch	Deterministisch

3.4 Dependency Injection und Inversion

Moderne Java- und Cloud-native Architekturen stützen sich stark auf Dependency Injection (DI) und Inversion of Control (IoC). Legacy-COBOL stützt sich umgekehrt auf hart kodierte Abhängigkeiten und globalen Zustand. Der Wechsel von einem zum anderen erfordert, jede Abhängigkeit im Graphen zu identifizieren und sie zu „invertieren“.

Wir müssen das Paradigma ändern von „Modul A hartkodiert eine Verbindung zu Datenbank B“ zu „Modul A akzeptiert eine Datenbankverbindung als Parameter.“ Dieser Architekturwechsel ist unmöglich, wenn die KI die Abhängigkeit gar nicht erst sieht. Der Wissensgraph macht diese Abhängigkeiten explizit und erlaubt der KI, den nötigen DI-Boilerplate-Code automatisch zu erzeugen, sodass das neue System modular und testbar ist. ⁴

Kapitel 4: Die Veriprajna Semantic Forge

4.1 Architektur des Repository-Aware Knowledge Graph

Die Lösung für das „Lost in the Middle“-Syndrom und die Fragilität textbasierter Migration ist der Repository-Aware Knowledge Graph . Dies ist eine einheitliche Graphdatenbank, die die statische Struktur des Codes (ASTs, Call Graphs) mit der semantischen Bedeutung der Geschäftslogik (Dokumentation, Kommentare, Variablenintention) kombiniert. ⁵

Veriprajna setzt eine proprietäre Pipeline ein, in der fortgeschrittenen Forschung oft als „Semantic Forge“ bezeichnet, um diese Intelligenz aufzubauen. Das ist kein generischer ETL-Prozess; es ist eine zweckgebaute Engine für Legacy-Modernisierung. ³³

4.2 Phase 1: Intelligentes Parsing mit Tree-sitter

Wir nutzen robuste Parser, vor allem Tree-sitter, um die Legacy-Codebasis einzulesen. Dieser Prozess unterstützt über 13 Sprachen, darunter COBOL, JCL, PL/I und Java. Der Parser erzeugt einen AST für jede Datei im Repository.

Entscheidend setzen wir Semantic Chunking ein. Standard-RAG-Pipelines nutzen „naives Splitting“, schneiden Text alle n Tokens. Das trennt häufig eine Funktionssignatur von ihrem Rumpf oder eine Variablendefinition von ihrer Nutzung und zerstört den Kontext. Semantic Chunking nutzt den AST, um logische Grenzen zu identifizieren. Wir zerlegen den Code nach SECTION, PARAGRAPH oder METHOD, sodass jeder Knoten in unserem Graphen eine vollständige, ausführbare Logikeinheit repräsentiert. ²³

4.3 Phase 2: Entitäts- und Beziehungsextraktion

Sobald die ASTs erzeugt sind, extrahiert die Semantic Forge die Entitäten und Beziehungen, um die Graphdatenbank zu befüllen (z. B. Neo4j, Memgraph).

●​ Entitäten: Klassen, Paragraphs, Variablen, Datenbanktabellen, API-Endpunkte.

●​ Beziehungen:

○​ CALLS: Verbindet einen Paragraph mit der Subroutine, die er aufruft.

○​ UPDATES_TABLE: Verbindet einen Logikblock mit der DB2-Tabelle, die er modifiziert.

○​ IMPORTS_COPYBOOK: Verbindet eine Quelldatei mit ihrer Abhängigkeit.

○​ DEFINES_VARIABLE: Verbindet eine Data Division mit den Variablen, die sie erzeugt.

Diese Phase verwandelt den statischen Text in eine dynamische Topologie. Wir können nun den Graphen abfragen: „Zeige mir jeden Paragraph, der das Feld CUSTOMER-ID aktualisiert.“ Diese Abfrage liefert exakte Ergebnisse sofort, ein Kunststück, das mit grep oder Vektorsuche unmöglich ist. ¹⁴

4.4 Phase 3: Entitätsauflösung und Merging

Das ist der kritische Differenzierungspunkt. Ein Standardparser sieht ACCT-NUM in Datei A und ACCT-NUM in Datei B als zwei verschiedene Strings. Unser System führt Symbol Resolution durch. Es stellt fest, dass beide auf denselben Eintrag in einem gemeinsamen Copybook verweisen. Es führt diese zu einem einzigen Variable Node im Graphen zusammen.

Darüber hinaus führen wir Cross-Modal Merging durch. Wenn die Codebasis ein PDF- Anforderungsdokument enthält, das die „User API“ beschreibt, und der Code eine Klasse namens UserAPI enthält, berechnet das System Embeddings, um zu erkennen, dass sie dasselbe Konzept sind. Es führt den Dokumentationsknoten mit dem Codeknoten zusammen. Das verknüpft die Intention (Docs) mit der Implementierung (Code) und gibt der KI das „Warum“ neben dem „Wie“. ⁸

4.5 Phase 4: Berechnung der transitiven Hülle

Der „Bank-Ausfall“ wurde durch eine transitive Abhängigkeit verursacht: A hängt von B ab, B hängt von C ab. Die KI sah A, verfehlte aber C.

Der Veriprajna-Wissensgraph berechnet die transitive Hülle . Wenn das System Modul A analysiert, bleibt es nicht bei den direkten Nachbarn stehen. Es traversiert den Graphen tief (A -> B -> C), um die „Root of Truth“ für jede Variable zu identifizieren. Das stellt sicher, dass die KI, wenn sie Code für Modul A erzeugt, die korrekten Definitionen aus Modul C importiert, selbst wenn Modul C in einem anderen Verzeichnis oder Repository liegt. ⁸

Kapitel 5: Graph Retrieval-Augmented Generation (GraphRAG)

5.1 Die Grenzen von Vector RAG

Vector Retrieval-Augmented Generation (RAG) ist der Industriestandard, um Wissen zu LLMs hinzuzufügen. Es wandelt Text in Vektoren (numerische Repräsentationen) um und findet ähnliche Vektoren. Hervorragend zum Abfragen unstrukturierten Texts wie FAQs, ist es für Code unzureichend.

●​ Variablenumbenennung: Wenn ein Entwickler Account in Acct umbenennt, fällt die semantische Ähnlichkeit, auch wenn die Logik identisch ist.

●​ Logik vs. Keywords: Die Suche nach „Interest Calculation“ könnte die tatsächliche Mathematik verfehlen, wenn die Funktion FNC-001 heißt und keine Kommentare enthält.

●​ Fragmentierter Kontext: Vector RAG holt „Chunks“ basierend auf Kosinusähnlichkeit. Es könnte einen Unit-Test und einen UI-Kommentar holen, aber die Kern-Geschäftslogik verfehlen, weil die Variablennamen nicht zu den Anfragewörtern passen. ³⁶

5.2 Der GraphRAG-Vorteil

GraphRAG operiert auf der Struktur des Wissensgraphen, nicht nur auf Textähnlichkeit.

1.​ Ankeridentifikation: Wenn ein Nutzer fragt „Refactore die Payment Logic“, nutzt das System Vektorsuche, um den Einstiegspunkt zu finden (z. B. den ProcessPayment-Paragraph).

2.​ Graph-Traversal (Expansion): Statt dort zu stoppen, traversiert GraphRAG die Graph- kanten. Es zieht herein:

○​ Die CALLS-Kanten, um Subroutinen zu finden.

○​ Die READS-Kanten, um Variablendefinitionen zu finden.

○​ Die INCLUDES-Kanten, um Copybooks zu finden.

3.​ Kontextkonstruktion: Diese verbundenen Stücke—die textuell unähnlich, aber logisch untrennbar sein können—werden zu einem kohärenten Prompt zusammengesetzt.

Diese Relevance Expansion stellt sicher, dass das LLM eine in sich geschlossene, ausführbare Scheibe der Logik erhält. Es versteht nicht nur den Text der Berechnung, sondern die Maschinerie dahinter. ³⁶

5.3 Multi-Hop-Reasoning

Forschung zeigt, dass GraphRAG Vector RAG bei Aufgaben, die „Multi-Hop-Reasoning“—Fakten verbinden, die mehrere Schritte auseinanderliegen. In Software ist fast jeder Bug ein Versagen von Multi-Hop-Reasoning (z. B. A ruft B auf, B ändert X, C liest X. Wenn A sich ändert, bricht C?).

GraphRAG erlaubt der KI, komplexe Impact-Analyse-Fragen zu beantworten: „Wenn ich die Zins- satzlogik in Modul A ändere, welche Reporting-Screens in Modul Z sind betroffen?“ Vector RAG kann das nicht beantworten, weil Modul A und Modul Z keine Textähnlichkeit teilen; sie sind nur durch eine Kette von Funktionsaufrufen verknüpft. Der Graph traversiert diese Kette, um eine definitive Antwort zu liefern. ³⁸

Tabelle 4: Vector RAG vs. GraphRAG

Merkmal	Vector RAG	GraphRAG
Retrieval-Schlüssel	Ähnlichkeit (Kosinusdistanz)	Beziehung (Graphkante)
Kontextqualität	Hohe Recall, niedrige Precision (Rauschen)	Hohe Precision, verbundener Kontext

Multi-Hop-Reasoning	Schwach (verfehlt indirekte Links)	Exzellent (traversiert Ketten)
Halluzinationsrisiko	Hoch (rät fehlende Links)	Niedrig (abgerufene Links sind explizit)
Bester Anwendungsfall	Unstrukturierter Text (FAQs)	Strukturierte Systeme (Code, Biologie)

Kapitel 6: Engineering der Migration – Technischer Deep Dive

6.1 Die „globale Variable“-Falle lösen

Einer der gefährlichsten Aspekte von COBOL ist die Nutzung globaler Variablen, definiert in der DATA DIVISION und modifiziert durch verschiedene PERFORM-Anweisungen im gesamten Programm. In Java diktiert Best Practice Kapselung; eine Methode sollte sich nicht auf versteckten Zustand stützen.

Die Lösung: Die Agenten von Veriprajna führen Data-Flow-Analyse auf dem Graphen durch. Wir verfolgen den Lebenszyklus jeder Variable.

●​ Wenn ein Paragraph CALC-TAX GROSS-INCOME liest, identifiziert der Graph GROSS-INCOME als eine Input Dependency .

●​ Beim Erzeugen der Java-Methode calcTax() fügt die KI explizit BigDecimal grossIncome zur Methodensignatur hinzu.

●​ Anschließend aktualisiert sie den Aufrufer der Methode, damit er den korrekten Wert übergibt.

Dieses automatische Refactoring von „implizitem globalem Zustand“ zu „expliziter Parameterübergabe“ verhindert die Seiteneffekt-Bugs, die die Bank in unserer Fallstudie plagten. ⁴

6.2 Die GOTO-Spaghetti dekonstruieren

Eines der härtesten Hindernisse in der COBOL-Migration ist die GOTO-Anweisung. GOTO erlaubt der Programmausführung, überallhin zu springen, und erzeugt nichtlineare Kontrollflüsse, die ein Anathema für moderne strukturierte Programmierung sind. ⁴⁰ Java hat keine GOTO-Anweisung.

GOTO-Logik zu übersetzen erfordert mehr als Syntaxübersetzung; es erfordert Control Flow Flattening .

1.​ Graphanalyse: Wir mappen die GOTO-Ziele als Kanten im Control Flow Graph (CFG).

2.​ Mustererkennung: Der Graph identifiziert Muster.

○​ Ein GOTO, der zu einem früheren Label zurückspringt, wird als Schleife identifiziert.

○​ Ein GOTO, der einen Block überspringt, wird als Bedingung identifiziert (if/else).

○​ Ein GOTO zu einem Exit-Paragraph ist ein Return .

3.​ Umstrukturierung: Die KI, geleitet vom Graphen, refaktoriert diese Sprünge in while-Schleifen, do-while-Schleifen oder break/continue-Anweisungen in Java.

Ohne einen Graphen, der die durch GOTO erzeugten „Schleifen“ visualisiert, wird ein textbasiertes LLM oft einen rekursiven Funktionsaufruf erzeugen, der zu einem StackOverflowError führt, oder einfach einen Logikfluss halluzinieren, der nicht existiert. ⁴

6.3 Umgang mit „Dead Code“

Legacy-Systeme sind voll von Code, der nicht mehr genutzt wird—alte Promotionen, zurückgezogene Produkte, Debug-Routinen. Diesen Code zu migrieren verschwendet Geld und vergrößert die Angriffsfläche. Textbasierte KI migriert alles, was sie bekommt; sie kann nicht zwischen aktivem und totem Code unterscheiden.

Die Lösung: Der Call Graph identifiziert unerreichbare Knoten—Paragraphs oder Dateien, die keine eingehenden Kanten haben (keine Aufrufer). Das System von Veriprajna markiert diesen „Dead Code“ zur Löschung, bevor die Migration beginnt. Das reduziert die Codebasis typischerweise um 20-30%, was zu erheblichen Kosteneinsparungen und einer saubereren finalen Architektur.31

Kapitel 7: Die agentische Zukunft – Deep AI vs. flache Wrapper

7.1 Jenseits des Chatbots: Der agentische Workflow

Veriprajna stellt keine „Chatbots“ bereit. Wir stellen autonome KI-Agenten bereit. Ein Agent ist ein System, das planen, ausführen und seine Aktionen anhand von Feedback korrigieren kann. ²

Der flache-Wrapper-Workflow:

1.​ Nutzer: „Konvertiere diesen Code.“

2.​ Wrapper: Sendet Text an GPT-4.

3.​ Ausgabe: Gibt Java-Code zurück.

4.​ Ergebnis: Code kompiliert oder läuft nicht. Entwickler debuggt manuell.

Der Veriprajna-Deep-Agent-Workflow:

1.​ Planung: Der Agent analysiert den AST der Ziel-COBOL-Datei. Er identifiziert Abhängigkeiten und befragt den Wissensgraphen.

2.​ Retrieval: Er holt den für die Migration nötigen GraphRAG-Kontext.

3.​ Generierung: Er erzeugt den Java-Code mit einem „Schematic-Constraint Decoder“, der Java-Syntaxregeln und Typsicherheit erzwingt. ⁷

4.​ Verifikation (die Schleife): Der Agent kompiliert den erzeugten Java-Code in einer Sandbox.

5.​ Selbstkorrektur: Wenn der Compiler einen Fehler wirft (z. B. „Variable not found“), liest der Agent den Fehler, befragt den Graphen nach der fehlenden Abhängigkeit und generiert den Code neu.

6.​ Validierung: Er führt Unit-Tests aus (generiert aus den originalen COBOL-Traces), um sicherzustellen, dass die Ausgabe dem Eingabeverhalten entspricht.

Diese Compile-Fix-Schleife verlagert die Validierungslast vom Menschen auf die KI und senkt dramatisch die Kosten des Refactorings. ⁴²

7.2 Human-in-the-Loop-Supervision

Während der Agent in der Ausführung autonom ist, wird er in der Strategie supervidiert. Der Wissensgraph liefert Interpretierbarkeit . Anders als ein „Black Box“-neuronales Netz erlaubt der Graph Entwicklern, genau zu sehen, warum die KI eine Entscheidung traf. „Die KI importierte com.bank.logic, weil sie eine Abhängigkeit von COPYBOOK-X fand.“

Diese Transparenz ist vital für regulierte Branchen wie das Bankwesen, wo jede Codezeile auditierbar sein muss. Wir gehen von „Vertrau mir, ich bin KI“ zu „Hier ist die Zitationskette für diese Logik“. ⁴³

Kapitel 8: Fazit und strategischer Ausblick

8.1 Der ROI der Repository-Awareness

McKinsey-Daten legen nahe, dass GenAI Coding-Aufgaben um 50% reduzieren kann, aber nur wenn sie korrekt bereitgestellt wird. ¹⁴ Der Return on Investment (ROI) von Veriprajnas graphbasiertem Ansatz wird getrieben durch die Eliminierung von Nacharbeit.

●​ Manuelle Migration: Hohe Kosten, hohes Risiko, langsames Time-to-Market.

●​ Wrapper-KI: Mittlere Kosten (durch Debugging von „Halluzinationen“), hohes Risiko (versteckte Bugs), mittleres Time-to-Market.

●​ Repository-Graph-KI: Niedrige Kosten (Automatisierung), niedriges Risiko (deterministische Verifikation), schnelles Time-to-Market.

Durch Eliminierung des „Context-Switching“-Overheads—bei dem Entwickler Stunden damit verbringen, zu suchen, wo eine Variable definiert ist—steigert Veriprajna die Entwicklerproduktivität um 2x bis 3x gegenüber standardmäßigen KI-Tools. ²

8.2 Future-Proofing durch kontinuierliche Modernisierung

Modernisierung ist kein einmaliges Ereignis; sie ist ein Lebenszyklus. Sobald die Codebasis in einen Wissensgraphen überführt ist, bleibt sie ein lebendiges Asset. Während der neue Java-Code evolviert, wird der Graph in Echtzeit aktualisiert. Das ermöglicht:

●​ Automatisierte Dokumentation: Die KI kann aktuelle Dokumentation für das neue System erzeugen, indem sie den Graphen liest. ⁴⁴

●​ Erkennung architektonischer Drift: Das System kann Architekten alarmieren, wenn neuer Code Modularitätsregeln verletzt, die im Graphen definiert sind. ⁴⁵

8.3 Der strukturelle Shift

Die Lektion des „Bank-Ausfalls“ ist klar: Code ist kein Text. Er ist ein komplexes, vernetztes System von Logik. Ihn mit Tools zu modernisieren, die nur Text verstehen, gleicht dem Versuch, eine Stadt mit einer Liste von Straßennamen, aber ohne Karte zu navigieren. Sie werden „Lost in the Middle.“

Veriprajna bietet die Karte. Indem wir Repository-Aware Knowledge Graphs bauen, geben wir der KI die strukturelle Intelligenz, die sie braucht, um die Komplexität von Legacy-Systemen zu navigieren. Wir mappen die Abhängigkeiten, wir entwirren die Knoten, und wir liefern Modernisierung, die nicht nur in der Syntax funktioniert, sondern in der Realität.

Wir schreiben nicht nur Code; wir erzeugen Verständnis. Das ist der Unterschied zwischen einem Chatbot und einem Lösungsanbieter. Das ist die Zukunft der Enterprise-Modernisierung.

Veriprajna. Tiefe KI für tiefe Lösungen.

Quellen

1. 2025 Legacy Code Stats: Costs, Risks & Modernization - Pragmatic Coders, abgerufen am 10. Dezember 2025, https://www.pragmaticcoders.com/resources/legacy-code-stats

2. Legacy App Modernization: AI Automation Slashes Costs & Time - SoftProdigy, abgerufen am 10. Dezember 2025, https://softprodigy.com/ai-driven-legacy-app-modernization/

3. Lost-in-the-Middle Effect | LLM Knowledge Base - Promptmetheus, abgerufen am 10. Dezember 2025, https://promptmetheus.com/resources/llm-knowledge-base/lost-in-the-middle-efectf

4. How We Use AI Agents for COBOL Migration and Mainframe Modernization | All things Azure - Microsoft Developer Blogs, abgerufen am 10. Dezember 2025, https://devblogs.microsoft.com/all-things-azure/how-we-use-ai-agents-for-cobol-migration-and-mainframe-modernization/

5. Bridging Code and Context: A Knowledge Graph-Based Repository-Level Code Generation, abgerufen am 10. Dezember 2025, https://quantiphi.com/blog/bridging-code-and-context-a-knowledge-graph-based-repository-level-code-generation/

6. Structural-Semantic Code Graph (SSCG) - Emergent Mind, abgerufen am 10. Dezember 2025, https://www.emergentmind.com/topics/structural-semantic-code-graph-sscg

7. SemanticForge: Repository-Level Code Generation through Semantic Knowledge Graphs and Constraint Satisfaction - ResearchGate, abgerufen am 10. Dezember 2025, https://www.researchgate.net/publication/397521461_SemanticForge_Repository-Level_Code_Generation_through_Semantic_Knowledge_Graphs_and_Constraint_Satisfaction

8. RANGER: Repository‑level Agent for Graph‑Enhanced Retrieval - arXiv, abgerufen am 10. Dezember 2025, https://arxiv.org/html/2509.25257v1

9. 40 Legacy Software Migration Trends for Enterprises in 2025 | Adalo, abgerufen am 10. Dezember 2025, https://www.adalo.com/posts/cost-savings-from-replacing-legacy-tools-with-no-code-stats

10. The problems with migrating legacy code: Moving from COBOL to Java and how Metabob can help, abgerufen am 10. Dezember 2025, https://metabob.com/blog-articles/the-problems-with-migrating-legacy-code-moving-from-cobol-to-java-and-how-metabob-can-help.html

11. 7 Signs Legacy System Modernisation Can't Wait Any Longer - Dreamix, abgerufen am 10. Dezember 2025, https://dreamix.eu/insights/when-to-invest-in-legacy-system-modernisation/

12. How to plan a seamless COBOL to Java migration in 8 weeks? - OptiSol Business Solutions, abgerufen am 10. Dezember 2025, https://www.optisolbusiness.com/insight/how-to-plan-a-seamless-cobol-to-java-migration-in-8-weeks

13. Application Modernization Statistics: Future-Proof Insights - eSparkBiz, abgerufen am 10. Dezember 2025, https://www.esparkinfo.com/blog/application-modernization-statistics

14. Modernizing legacy architectures using GenAI-powered Knowledge Graphs | by Sigmoid, abgerufen am 10. Dezember 2025, https://sigmoidanalytics.medium.com/modernizing-legacy-architectures-using-genai-powered-knowledge-graphs-73d96169f6d7

15. How GPT Wrappers Can Accelerate Your AI Product Development - Synergy Labs, abgerufen am 10. Dezember 2025, https://www.synergylabs.co/fr/blog/how-gpt-wrappers-can-accelerate-your-ai-product-development

16. The Ephemeral Scaffolding or Enduring Infrastructure? LLMs, Their Wrappers, and the Specter of a Dotcom Déjà Vu - Torome, abgerufen am 10. Dezember 2025, https://torome.co.uk/Template/PDO3/the-ephemeral-scafolding-or-enduring-inffrastructure-llms-their-wrappers-and-the-specter-of-a-dotcom-deja-vu

17. GraphRAG vs. Vector RAG: Side-by-side comparison guide - Meilisearch, abgerufen am 10. Dezember 2025, https://www.meilisearch.com/blog/graph-rag-vs-vector-rag

18. Lost in the Middle in LLMS. Why large language models ignore the… | by Cengizhan Bayram | Nov, 2025 | Medium, abgerufen am 10. Dezember 2025, https://medium.com/@cenghanbayram35/lost-in-the-middle-in-llms-86e461dc7212

19. A practical guide to the Claude code context window size - eesel AI, abgerufen am 10. Dezember 2025, https://www.eesel.ai/blog/claude-code-context-window-size

20. Lost in the Middle: How Language Models Use Long Contexts - MIT Press Direct, abgerufen am 10. Dezember 2025, https://direct.mit.edu/tacl/article/doi/10.1162/tacl_a_00638/119630/Lost-in-the-Middle-How-Language-Models-Use-Long

21. Why Language Models Are “Lost in the Middle” - Towards AI, abgerufen am 10. Dezember 2025, https://pub.towardsai.net/why-language-models-are-lost-in-the-middle-629b20d86152

22. LLM Hallucinations – Definition, Examples and Potential Remedies - Software Mind, abgerufen am 10. Dezember 2025, https://softwaremind.com/blog/llm-hallucinations-definition-examples-and-potential-remedies/

23. Repository GraphRAG MCP Server: A Deep Dive for AI Engineers, abgerufen am 10. Dezember 2025, https://skywork.ai/skypage/en/repository-graphrag-mcp-server-ai-engineers/1978326852212269056

24. AST-Based Source Code Migration Through Symbols Replacement, abgerufen am 10. Dezember 2025, https://www.computer.org/csdl/proceedings-article/csde/2022/10089298/1M7LebbRyEw

25. BMSD 2011, abgerufen am 10. Dezember 2025, https://is-bmsd.org/Documents/ProceedingsOfFirstBMSD.pdf

26. Abstract Syntax Tree Creation - Compiler Design - Meegle, abgerufen am 10. Dezember 2025, https://www.meegle.com/en_us/topics/compiler-design/abstract-syntax-tree-creation

27. AST (Abstract Syntax Tree) - by Dinis Cruz - Medium, abgerufen am 10. Dezember 2025, https://medium.com/@dinis.cruz/ast-abstract-syntax-tree-538aa146c53b

28. Daily Papers - Hugging Face, abgerufen am 10. Dezember 2025, https://huggingface.co/papers?q=outlier%20chunk%20handling

29. What is a Call Graph? And How to Generate them Automatically freeCodeCamp, abgerufen am 10. Dezember 2025, https://www.freecodecamp.org/news/how-to-automate-call-graph-creation/

30. Generation of Call Graph for Java Higher Order Functions - IEEE Xplore, abgerufen am 10. Dezember 2025, https://ieeexplore.ieee.org/document/9138056/

31. Enhancing Neural Code Representation with Additional Context - arXiv, abgerufen am 10. Dezember 2025, https://arxiv.org/html/2510.12082v1

32. Can We Translate Code Better with LLMs and Call Graph Analysis? - IJCAI, abgerufen am 10. Dezember 2025, https://www.ijcai.org/proceedings/2025/0848.pdf

33. Code Graph: From Visualization to Integration - FalkorDB, abgerufen am 10. Dezember 2025, https://www.falkordb.com/blog/code-graph/

34. Codebase to Knowledge Graph generator : r/LocalLLaMA - Reddit, abgerufen am 10. Dezember 2025, https://www.reddit.com/r/LocalLLaMA/comments/1mzvk44/codebase_to_knowledge_graph_generator/

35. SemanticForge: Repository-Level Code Generation through Semantic Knowledge Graphs and Constraint Satisfaction - arXiv, abgerufen am 10. Dezember 2025, https://arxiv.org/html/2511.07584

36. RAG vs GraphRAG: Shared Goal & Key Differences - Memgraph, abgerufen am 10. Dezember 2025, https://memgraph.com/blog/rag-vs-graphrag

37. Do You Really Need GraphRAG? A Practitioner's Guide Beyond the Hype, abgerufen am 10. Dezember 2025, https://towardsdatascience.com/do-you-really-need-graphrag-a-practitioners-guide-beyond-the-hype/

38. Navigating the Nuances of GraphRAG vs. RAG - foojay, abgerufen am 10. Dezember 2025, https://foojay.io/today/navigating-the-nuances-of-graphrag-vs-rag/

39. GraphRAG vs RAG: Which is Better? | by Mehul Gupta | Data Science in Your Pocket, abgerufen am 10. Dezember 2025, https://medium.com/data-science-in-your-pocket/graphrag-vs-rag-which-is-beter-81a27780c4ff

40. Why not GOTO Statement? [closed] - Stack Overflow, abgerufen am 10. Dezember 2025, https://stackoverflow.com/questions/19766205/why-not-goto-statement

41. Alternative to a goto statement in Java - Stack Overflow, abgerufen am 10. Dezember 2025, https://stackoverflow.com/questions/2430782/alternative-to-a-goto-statement-in-java

42. Legacy Code Modernization with Claude Code: Breaking Through Context Window Barriers, abgerufen am 10. Dezember 2025, https://www.tribe.ai/applied-ai/legacy-code-modernization-with-claude-code-breaking-through-context-window-barriers

43. Legacy IT Modernization with AI | MITRE, abgerufen am 10. Dezember 2025, https://www.mitre.org/news-insights/publication/legacy-it-modernization-ai

44. Documenting and Modernizing Legacy Codebases with C3 Generative AI, abgerufen am 10. Dezember 2025, https://c3.ai/blog/documenting-and-modernizing-legacy-codebases-with-c3-generative-ai/

45. The AI revolution in application modernization: from manual burden to strategic advantage, abgerufen am 10. Dezember 2025, https://vfunction.com/blog/ai-app-modernization-strategy/