Legacy-modernisering: verder dan syntaxis met neuro-symbolische AI

Samenvatting voor bestuurders

De modernisering van enterprise-legacy-systemen—specifiek de migratie van mainframe- architecturen naar cloud-native omgevingen—heeft een kritisch kantelpunt bereikt in de midden-jaren 2020. Decennialang hebben de financiële en overheidssectoren gewerkt volgens een paradoxaal paradigma: de noodzaak om te moderniseren is existentieel, maar het faalpercentage van zulke initiatieven blijft catastrofaal hoog, en schommelt tussen 70% en 80%. ¹ De recente opkomst van Large Language Models (LLM's) beloofde een revolutie, met de verleidelijke mogelijkheid van geautomatiseerde codevertaling. Vroege adoptiecycli hebben echter een kritieke, systemische tekortkoming blootgelegd in standaard generatieve-AI-benaderingen wanneer die worden toegepast op complexe, monolithische repositories.

We zien momenteel een nieuwe categorie van engineeringfalen ontstaan, getypeerd door het apocriefe maar zeer realistische scenario van een grote bank die probeert dertig jaar COBOL naar Java te herschrijven met een commerciële coding-assistent. De AI, die fungeerde als een geavanceerde gelokaliseerde vertaler, zette de syntaxis perfect om. Toch crashte de resulterende applicatie bij deployment de database. Het falen was geen kwestie van syntaxis, maar van context. De AI, beperkt door het "Lost in the Middle"-syndroom en een tekstgebaseerd begrip van software, miste een kritieke variabele-afhankelijkheid die duizenden regels vóór het uitvoeringsblok. ³

Dit whitepaper, aangeboden door Veriprajna, stelt dat de heersende "LLM-wrapper"- benadering—die code behandelt als een lineaire reeks teksttokens—fundamenteel ongeschikt is voor de niet-lineaire complexiteit van enterprise-modernisering. Software is geen tekst; het is een graaf. Het is een sterk gestructureerd systeem van logische afhankelijkheden, datastromen en toestandsveranderingen dat bestaat in een meerdimensionale topologische ruimte. ⁵

Wij poneren dat de enige levensvatbare weg vooruit de adoptie is van repository-bewuste kennis- grafen . Door over te stappen van stochastische tekstvoorspelling naar graafgebaseerd deterministisch redeneren, kunnen we variabele-afhankelijkheden over miljoenen regels code in kaart brengen, het "Lost in the Middle"-fenomeen oplossen en modernisering van een riskante gok omzetten in een wiskundig verifieerbaar engineeringproces. ⁷ Dit document schetst de technische overgang van syntaxisvertaling aan de oppervlakte naar diepe, semantische structurele transformatie.

Hoofdstuk 1: De stille crisis van legacy- infrastructuur

1.1 De moderniseringsparadox

In de huidige digitale economie steunt de infrastructuur van de wereldhandel precair op technologie die tijdens de Koude Oorlog is ontwikkeld. Het is een schokkende, vaak niet erkende realiteit dat, in 2025, een aanzienlijke meerderheid van de financiële, zorg- en overheidssystemen ter wereld draait op legacy-codebases—monolithische applicaties geschreven in talen als COBOL, PL/I en RPG, die allang uit het mainstream informatica-curriculum zijn verdwenen. Deze systemen zijn niet louter "oud"; ze vormen het fundament van de wereldeconomie, maar eroderen in alarmerend tempo.

De statistieken schetsen een somber beeld van deze afhankelijkheid. Ongeveer 70% van de software die bij Fortune 500-bedrijven draait, is meer dan twee decennia geleden ontwikkeld. ⁹ In de bankensector is de situatie nog nijpender: 43% van de banksystemen is gebouwd op COBOL, en deze systemen verwerken 95% van alle pinautomaattransacties. ¹ We laten in feite de moderne, instant-betalingseconomie draaien op een digitale fundering van vóór het internet.

De kosten van het in stand houden van deze status quo exploderen. Technische schuld is opgelopen tot een geschatte $1.52 trillion in de VS alleen al. ¹ Organisaties zitten vast in een cyclus van "de lampen aanhouden," waarbij 80% van de federale IT-budgetten naar exploitatie en onderhoud gaat, en een schrale 20% overblijft voor innovatie. ⁹ Deze resource-uitputting wordt versterkt door een ernstig tekort aan vaardigheden; naarmate de generatie ontwikkelaars die deze systemen schreef met pensioen gaat, verdwijnt de institutionele kennis die nodig is om ze te onderhouden. ¹⁰

Tabel 1: De economische last van legacy-systemen

Kengetal	Statistiek	Bron
Kosten technische schuld (VS)	$1.52 Trillion	1
Federaal IT-onderhouds- budget	~80% van de totale uitgaven	9
Bankafhankelijkheid	95% van de pinautomaattransacties op COBOL	1

Kans op datalek	3x hoger voor systemen >10 jaar oud	11
Uitstroom van ontwikkelaars	58% overweegt te vertrekken vanwege legacy-stacks	1

Deze gegevens wijzen op een systemische kwetsbaarheid. De moderniseringsnoodzaak gaat niet louter over kostenreductie; het gaat om overleven. Systemen ouder dan tien jaar hebben statistisch drie keer meer kans op een beveiligingslek dan moderne applicaties. ¹¹ Naarmate regelgevende eisen rond gegevensprivacy en realtimerapportage strenger worden (bijv. GDPR, DORA), wordt het onvermogen van legacy-systemen om zich aan te passen een compliance-risico van de hoogste orde.

1.2 De anatomie van de "bankcrash"

Om de noodzaak van een nieuwe aanpak te begrijpen, moeten we het scenario ontleden dat de "Patiënt Zero" van AI-moderniseringsfalen is geworden. Deze casestudy, aangehaald door Veriprajna-leiding, illustreert het specifieke mechanisme waarmee standaard-AI faalt in enterprise-omgevingen.

Een grote financiële instelling startte een project om een kern-transactieverwerkingssysteem te migreren van een IBM-mainframe (COBOL/DB2) naar een cloud-native Java-microservicesarchitectuur. De bank gebruikte een populaire AI-coding-assistent—in wezen een wrapper rond een foundation- model—om de code te vertalen.

De AI nam een COBOL-programma in zich op dat verantwoordelijk was voor het verwerken van high-value-overschrijvingen. Het programma bevatte een complexe COMPUTE-instructie met een variabele die we TRN-LIMIT noemen. De AI vertaalde de syntaxis perfect. Ze zette de COMPUTE-instructie om in een Java- BigDecimal-bewerking. De code compileerde. De unittests—gegenereerd door dezelfde AI op basis van het lokale codeblok—slaagden.

Bij deployment in de User Acceptance Testing (UAT)-omgeving, de eerste transactie crashte de consistentiecontrole van de database.

De autopsie: De variabele TRN-LIMIT was niet gedefinieerd in het bronbestand dat de AI vertaalde. Ze was gedefinieerd in een COPYBOOK (een gedeeld headerbestand) dat duizenden regels eerder in de uitvoeringsketen was opgenomen. Belangrijker nog: dat COPYBOOK bevatte een REDEFINES-clausule—een COBOL-constructie die toestaat dat hetzelfde geheugenadres als twee verschillende datatypes wordt geïnterpreteerd, afhankelijk van een vlag die in een volledig andere module is gezet. De AI, die op een "chunk" tekst werkte, zag TRN-LIMIT als een eenvoudig numeriek veld. Ze zag de REDEFINES-clausule niet omdat die in een ander bestand stond dat niet in het directe contextvenster zat. Ze "hallucineerde" een standaarddefinitie voor de variabele. In de mainframe- omgeving bevatte het geheugenadres een packed decimal; in de Java-omgeving behandelde de AI het als een standaard integer. De mismatch zorgde ervoor dat de Java-applicatie corrupte binaire data in de databasekolom schreef, wat een fout in de referentiële integriteit veroorzaakte. ⁴

Het falen was geen kwestie van syntaxis; de Java-code was syntactisch perfect. Het falen was een kwestie van contextuele blindheid . De AI miste een afhankelijkheid buiten haar "gezichtsveld," wat tot een catastrofale semantische divergentie leidde.

1.3 Het dilemma van "lift and shift" versus refactoring

Het trackrecord van de sector op modernisering is abominabel, al vóór de introductie van generatieve AI. Onderzoek wijst uit dat tussen 70% en 80% van de digitale transformatie- en legacy-moderniseringsprojecten hun doelstellingen niet haalt. ²

Traditioneel stonden organisaties voor een binaire keuze:

1.​ Rehost (lift and shift): Verplaats de gecompileerde applicatie naar een emulator in de cloud. Dit behoudt de "spaghetti-code" en de schuld, en verandert slechts de hostingrekening. Het slaagt er niet in de wendbaarheid van de cloud te ontsluiten. ¹⁴

2.​ Rewrite (refactor): Herschrijf de code handmatig in een moderne taal. Dit is astronomisch duur, traag en riskant door het gebrek aan documentatie en de "Big Ball of Mud"-architectuur waarin bedrijfslogica onlosmakelijk verstrengeld is met gegevenstoegang. ¹⁰

Generatieve AI zou een "derde weg" bieden—geautomatiseerde refactoring. De "bankcrash" bewijst echter dat AI zonder dieper begrip van softwaretopologie louter het aanmaken van gebrekkige code versnelt.

Hoofdstuk 2: Het falen van stochastische vertaling

2.1 De "wrapper"-economie en haar grenzen

In deze omgeving met hoge inzet verscheen de "LLM-wrapper." De onmiddellijke reactie van de softwareconsultancy-markt op de release van GPT-4 was de wildgroei van tools die fungeren als dunne softwarelagen tussen een ontwikkelaar en een foundation-model. ¹⁵ Deze tools beloven te "chatten met je code," zodat ontwikkelaars een COBOL-paragraaf kunnen plakken en een Java- methode terugkrijgen.

Hoewel deze wrappers de instapdrempel voor AI-adoptie verlagen, zijn ze fundamenteel gebrekkig wanneer ze worden toegepast op grootschalige systeemherengineering. Wrappers steunen doorgaans op Naïve RAG (retrieval-augmented generation). In dit proces neemt het systeem een gebruikersvraag, zoekt een vector-database naar codesnippets die tekstueel vergelijkbaar zijn met de query, en voert die snippets als context aan de LLM. ¹⁷

De beperkingen van deze aanpak in een enterprise-context zijn ernstig:

1.​ Contextuele bijziendheid: Een wrapper ziet code als tekstsegmenten. Ze begrijpt niet dat een variabele ACCOUNT-BALANCE die in SECTION-A wordt gewijzigd, een beslissingslogica aandrijft in SECTION-Z vijfduizend regels verderop.

2.​ Syntactisch succes, semantisch falen: Zoals opgemerkt kan een LLM Java-code produceren die perfect compileert maar het exacte runtimegedrag van de oorspronkelijke COBOL niet repliceert omdat ze een globale toestandsverandering miste. ⁴

Veriprajna onderscheidt zich door de "thin wrapper"-filosofie af te wijzen. Wij stellen dat diepe AI-oplossingen de structuur van de repository moeten begrijpen, niet alleen de tekst van het bestand.

2.2 Het "Lost in the Middle"-syndroom

Om te begrijpen waarom standaard-AI faalt bij legacy-modernisering, moeten we de cognitieve architectuur van Large Language Models begrijpen. Deze modellen zijn gebaseerd op de Transformer-architectuur, die een "aandachtsmechanisme" gebruikt om het belang te wegen van verschillende delen van de invoertekst. ¹⁸

Hoewel moderne LLM's massieve contextvensters claimen (tot 1 miljoen tokens), is hun vermogen om die context effectief te gebruiken niet uniform. Empirisch onderzoek heeft een fenomeen aangetoond dat bekendstaat als het "Lost in the Middle"-effect . Wanneer ze een lange informatiesequentie voorgelegd krijgen, vertonen LLM's een U-vormige prestatiecurve:

●​ Primacy bias: Ze zijn zeer accuraat in het terughalen van informatie aan het begin van de prompt.

●​ Recency bias: Ze zijn zeer accuraat in het terughalen van informatie aan het einde van de prompt.

●​ Het dal: De prestatie verslechtert aanzienlijk voor informatie in het midden. ³

In een moderniseringsproject kan één COBOL-programma duizenden regels lang zijn, en het kan copybooks (afhankelijkheden) refereren die zelf duizenden regels lang zijn. Als de definitie van een kritieke variabele—zeg MAX-TRANSACTION-LIMIT—verschijnt in het midden van deze massieve context, is de AI statistisch geneigd haar over het hoofd te zien. ²¹

Wanneer de AI een variabeledefinitie over het hoofd ziet, stopt ze niet. Ze "hallucineert." Ze neemt een standaardtype of -waarde voor de variabele aan op basis van waarschijnlijkheid, niet van feit. In een banksysteem kan aannemen dat een variabele een Integer is terwijl het eigenlijk een packed decimal is, leiden tot afrondings- fouten die financiële data corrumperen. ²²

Tabel 2: De cognitieve beperkingen van standaard-LLM's

Fenomeen	Beschrijving	Impact op modernisering
Lost in the Middle	Verslechterde aandacht in het midden van lange prompts.3	Gemiste variabeledefinities begraven in grote bestanden.
Hallucinatie	Verzinnen van aannemelijke maar onjuiste feiten.22	Verzinnen van afhankelijkheden of logica om gaten in de context te vullen.
Primacy/recency-bias	Focus op begin/einde van tekst.20	Negeren van kernbedrijfs- logica die in het midden van een procedure staat.
Stochastische generatie	Probabilistische tekst- voorspelling.	Inconsistente code- generatie; het opnieuw uitvoeren van de prompt levert andere logica op.

2.3 De "zak met woorden" versus de "boom van logica"

Standaard-LLM's en vector-RAG-systemen verwerken code primair als een reeks tokens. Ze steunen op semantische similariteit—controleren of woorden in de query overeenkomen met woorden in de document- vectorruimte. ¹⁷

Code is echter geen natuurlijke taal. In natuurlijke taal heeft "De kat zat op de mat" een betekenis die grotendeels onafhankelijk is van een zin vijftig pagina's eerder. In software heeft x = y + 1 nul betekenis tenzij we de definities, types en huidige toestanden van x en y kennen. Deze definities kunnen in een ander bestand, een andere module of via overerving van een parent- class bestaan. ⁵

Wanneer een "wrapper"-AI context ophaalt voor een query als "Refactor de betalingslogica," kan ze vijf codechunks ophalen die het woord "payment" bevatten. Ze zal waarschijnlijk de chunk genaamd GlobalVarDef.cbl missen die het belastingtarief definieert dat de betalingslogica gebruikt, omdat dat bestand nooit het woord "payment" noemt.

Deze kloof vertegenwoordigt het fundamentele gat tussen tekstuele retrieval en structureel begrip . Om die kloof te dichten moeten we ophouden code als literatuur te behandelen en haar gaan behandelen als een graaf. ²³

Hoofdstuk 3: De fysica van software –

code als een graaf

3.1 Software als relationeel systeem

Bij Veriprajna erkennen we dat een softwarerepository fundamenteel een relationele database van logica is. Elke entiteit in de codebase—variabelen, functies, klassen, modules, database- schema's—bestaat in een dicht web van relaties.

●​ Containment: Een bestand bevat een class; een class bevat een methode; een methode bevat een variabeledeclaratie.

●​ Inheritance: Class B erft eigenschappen en methoden van Class A.

●​ Invocation: Methode X roept Methode Y aan.

●​ Data flow: Variabele Z wordt gewijzigd door Functie Q en gelezen door Functie R.

Deze relaties vormen de "grondwaarheid" van de applicatie. Ze zijn niet probabilistisch; ze zijn deterministisch. Als Methode X Methode Y aanroept, is dat een hard feit, geen statistische waarschijnlijkheid. Standaard-LLM's opereren in het probabilistische domein. Om legacy- systemen veilig te moderniseren, moeten we hun probabilistische generatiecapaciteit verankeren in de deterministische realiteit van de codestructuur. ⁷

3.2 De Abstract Syntax Tree (AST)

De fundamentele eenheid van dit structurele begrip is de Abstract Syntax Tree (AST) . De AST is een boomrepresentatie van de abstracte syntactische structuur van broncode. In tegenstelling tot een ruwe tekststring vangt een AST de hiërarchie en grammaticale regels van de taal. ²⁴

Bijvoorbeeld, de COBOL-instructie: COMPUTE INTEREST = PRINCIPAL * RATE is niet zomaar vijf woorden. In een AST is het een AssignmentNode met een Target (Interest) en een Expression. De Expression is een MultiplicationNode met een LeftOperand (Principal) en een RightOperand (Rate).26 Door legacy-code in AST's te parsen, gaan we voorbij de ambiguïteiten van tekst. We kunnen programmatisch elk variabelengebruik, elke rekenkundige bewerking en elke control- flow-vertakking identificeren. Dit stelt ons in staat tot "round-trip"-engineering—code naar AST omzetten en terug naar code zonder dataverlies—waarmee we garanderen dat onze structurele analyse accuraat is. ²⁷

In tegenstelling tot "text chunking" in standaard-RAG—waarbij een bestand blind in 500-token- segmenten wordt geknipt, vaak midden in een functie—respecteert AST-parsing de logische grenzen van de code. Een functie wordt behandeld als een discrete logische eenheid, niet als een willekeurige tekstspan. ²³

3.3 De call graph en de afhankelijkheidsmatrix

Terwijl de AST de structuur van één bestand weergeeft, vertegenwoordigt de call graph het zenuw- stelsel van de hele applicatie. Hij visualiseert de controlestroom en brengt in kaart welke paragrafen of subroutines andere aanroepen. ²⁹

In legacy-COBOL-systemen worden call graphs vaak versluierd door dynamische calls of GOTO-logica die "spaghetti-code" creëert. Een statische tekstanalyse kan niet eenvoudig oplossen waar een GOTO LABEL_X landt als LABEL_X dynamisch of conditioneel is gedefinieerd.

Door een strikte call graph te construeren, identificeert Veriprajna "dode code" (code die nooit wordt aangeroepen) en "God Classes" (modules die te sterk gekoppeld zijn). Deze analyse is cruciaal voor het opbreken van monolieten in microservices. Als we de complete aanroepketen niet kennen, kunnen we een service niet veilig extraheren; we riskeren een "dangling reference" achter te laten die een runtimefout veroorzaakt—precies het scenario dat de bank in onze openingscasestudy teisterde. ³¹

Tabel 3: Structurele analyse versus tekstanalyse

Kenmerk	Tekstanalyse (standaard- AI)	Structurele analyse (Veriprajna)
Analyse-eenheid	Token / woord	Node (AST-element)
Contextgrens	Willekeurige tokenlimiet	Logisch bereik (functie/class)
Afhankelijkheidsresolutie	Keyword-matching	Graaftraversie
GOTO-afhandeling	Behandelt als tekststring	Mapt control-flow-edges
Nauwkeurigheid	Probabilistisch	Deterministisch

3.4 Dependency injection en inversie

Moderne Java- en cloud-native architecturen steunen zwaar op dependency injection (DI) en inversion of control (IoC). Legacy-COBOL steunt daarentegen op hardgecodeerde afhankelijkheden en globale toestand. Van het ene naar het andere gaan vereist het identificeren van elke afhankelijkheid in de graaf en die te "inverteren."

We moeten het paradigma veranderen van "Module A hardcodeert een verbinding naar Database B" naar "Module A accepteert een databaseverbinding als parameter." Deze architectuurverschuiving is onmogelijk als de AI de afhankelijkheid überhaupt niet kan zien. De kennisgraaf maakt deze afhankelijkheden expliciet, zodat de AI de benodigde DI-boilerplate automatisch kan genereren en het nieuwe systeem modulair en testbaar is. ⁴

Hoofdstuk 4: De Veriprajna Semantic Forge

4.1 Architectuur van de repository-bewuste kennis- graaf

De oplossing voor het "Lost in the Middle"-syndroom en de broosheid van tekstgebaseerde migratie is de repository-bewuste kennisgraaf . Dit is een uniforme graafdatabase die de statische structuur van de code (AST's, call graphs) combineert met de semantische betekenis van de bedrijfslogica (documentatie, commentaar, variabele-intentie). ⁵

Veriprajna gebruikt een propriëtaire pipeline, in geavanceerd onderzoek vaak aangeduid als een "Semantic Forge," om deze intelligentie op te bouwen. Dit is geen generiek ETL-proces; het is een doelgebouwde engine voor legacy-modernisering. ³³

4.2 Fase 1: Intelligent parsen met Tree-sitter

We gebruiken robuuste parsers, primair Tree-sitter, om de legacy-codebase in te lezen. Dit proces ondersteunt meer dan 13 talen, waaronder COBOL, JCL, PL/I en Java. De parser genereert een AST voor elk bestand in de repository.

Cruciaal is dat we semantische chunking inzetten. Standaard-RAG-pipelines gebruiken "naïeve splitting," waarbij tekst elke n tokens wordt geknipt. Dit scheidt vaak een functiesignatuur van haar body of een variabeledefinitie van haar gebruik, en vernietigt zo de context. Semantische chunking gebruikt de AST om logische grenzen te identificeren. We chunken de code per SECTION, PARAGRAPH of METHOD, zodat elke node in onze graaf een complete, uitvoerbare logische eenheid vertegenwoordigt. ²³

4.3 Fase 2: Extractie van entiteiten en relaties

Zodra de AST's zijn gegenereerd, extraheert de Semantic Forge de entiteiten en relaties om de graafdatabase te vullen (bijv. Neo4j, Memgraph).

●​ Entiteiten: Classes, paragrafen, variabelen, databasetabellen, API-endpoints.

●​ Relaties:

○​ CALLS: Verbindt een paragraaf met de subroutine die ze aanroept.

○​ UPDATES_TABLE: Verbindt een logicablok met de DB2-tabel die het wijzigt.

○​ IMPORTS_COPYBOOK: Verbindt een bronbestand met zijn afhankelijkheid.

○​ DEFINES_VARIABLE: Verbindt een data division met de variabelen die ze aanmaakt.

Deze fase transformeert de statische tekst tot een dynamische topologie. We kunnen nu de graaf bevragen: "Toon me elke paragraaf die het veld CUSTOMER-ID bijwerkt." Deze query geeft exacte resultaten onmiddellijk, iets wat onmogelijk is met grep of vector search. ¹⁴

4.4 Fase 3: Entiteitsresolutie en samenvoeging

Dit is het cruciale differentiatiepunt. Een standaardparser ziet ACCT-NUM in File A en ACCT-NUM in File B als twee verschillende strings. Ons systeem voert symboolresolutie uit. Het bepaalt dat beide naar dezelfde entry in een gedeeld copybook verwijzen. Het voegt deze samen tot een enkele Variable Node in de graaf.

Verder voeren we cross-modale merging uit. Als de codebase een PDF- requirementdocument bevat dat de "User API" beschrijft, en de code een class bevat genaamd UserAPI, berekent het systeem embeddings om te herkennen dat het hetzelfde concept is. Het voegt de documentatienode samen met de codenode. Dit koppelt de intentie (docs) aan de implementatie (code), en geeft de AI het "waarom" naast het "hoe". ⁸

4.5 Fase 4: Berekening van de transitieve sluiting

De "bankcrash" werd veroorzaakt door een transitieve afhankelijkheid: A hangt af van B, B hangt af van C. De AI zag A maar miste C.

De Veriprajna-kennisgraaf berekent transitieve sluiting . Wanneer het systeem Module A analyseert, stopt het niet bij de directe buren. Het traverseert de graaf diep (A -> B -> C) om de "Root of Truth" van elke variabele te identificeren. Dit garandeert dat wanneer de AI code voor Module A genereert, ze de juiste definities uit Module C importeert, zelfs als Module C in een andere directory of repository staat. ⁸

Hoofdstuk 5: Graph Retrieval-Augmented Generation (GraphRAG)

5.1 De beperkingen van vector-RAG

Vector Retrieval-Augmented Generation (RAG) is de industriestandaard om kennis aan LLM's toe te voegen. Het zet tekst om in vectoren (numerieke representaties) en vindt vergelijkbare vectoren. Uitstekend voor het bevragen van ongestructureerde tekst zoals FAQ's, maar ontoereikend voor code.

●​ Hernoemen van variabelen: Als een ontwikkelaar Account hernoemt tot Acct, daalt de semantische similariteit, ook al is de logica identiek.

●​ Logica versus trefwoorden: Zoeken naar "Interest Calculation" kan de echte wiskunde missen als de functie FNC-001 heet en geen commentaar bevat.

●​ Gefragmenteerde context: Vector-RAG haalt "chunks" op op basis van cosinus-similariteit. Ze kan een unittest en een UI-commentaar ophalen, maar de kernbedrijfslogica missen omdat de variabelenamen niet overeenkomen met de querywoorden. ³⁶

5.2 Het GraphRAG-voordeel

GraphRAG opereert op de structuur van de kennisgraaf, niet alleen op tekstsimilariteit.

1.​ Ankeridentificatie: Wanneer een gebruiker vraagt "Refactor de betalingslogica," gebruikt het systeem vector search om het ingangspunt te vinden (bijv. de ProcessPayment-paragraaf).

2.​ Graaftraversie (expansie): In plaats van daar te stoppen, traverseert GraphRAG de graaf- edges. Het haalt binnen:

○​ De CALLS-edges om subroutines te vinden.

○​ De READS-edges om variabeledefinities te vinden.

○​ De INCLUDES-edges om copybooks te vinden.

3.​ Contextconstructie: Deze verbonden stukken—die tekstueel ongelijksoortig kunnen zijn maar logisch onlosmakelijk zijn—worden tot een coherente prompt samengesteld.

Deze relevantie-expansie zorgt ervoor dat de LLM een zelfstandige, uitvoerbare slice van logica ontvangt. Ze begrijpt niet alleen de tekst van de berekening, maar de machinerie ervan. ³⁶

5.3 Multi-hop-redeneren

Onderzoek toont dat GraphRAG Vector RAG significant overtreft bij taken die "multi-hop-redeneren" vereisen—feiten verbinden die meerdere stappen van elkaar liggen. In software is bijna elke bug een falen van multi-hop-redeneren (bijv. A roept B aan, B wijzigt X, C leest X. Als A verandert, breekt C dan?).

GraphRAG laat de AI complexe impactanalysevragen beantwoorden: "Als ik de rente- logica in Module A wijzig, welke rapportageschermen in Module Z worden dan beïnvloed?" Vector RAG kan dit niet beantwoorden omdat Module A en Module Z geen tekstsimilariteit delen; ze zijn verbonden alleen door een keten van functieaanroepen. De graaf traverseert deze keten om een definitief antwoord. ³⁸

Tabel 4: Vector RAG versus GraphRAG

Kenmerk	Vector RAG	GraphRAG
Retrieval-sleutel	Similariteit (cosinusafstand)	Relatie (graaf-edge)
Contextkwaliteit	Hoge recall, lage precisie (ruis)	Hoge precisie, verbonden context

Multi-hop-redeneren	Slecht (mist indirecte links)	Uitstekend (traverseert ketens)
Hallucinatiesrisico	Hoog (raadt ontbrekende links)	Laag (opgehaalde links zijn expliciet)
Beste use case	Ongestructureerde tekst (FAQ's)	Gestructureerde systemen (code, biologie)

Hoofdstuk 6: De migratie engineeren – technische deep dive

6.1 De val van de "globale variabele" oplossen

Een van de gevaarlijkste aspecten van COBOL is het gebruik van globale variabelen die in de DATA DIVISION zijn gedefinieerd en door verschillende PERFORM-statements door het hele programma worden gewijzigd. In Java schrijft best practice encapsulatie voor; een methode mag niet op verborgen toestand steunen.

De oplossing: De agents van Veriprajna voeren dataflow-analyse uit op de graaf. We traceren de levenscyclus van elke variabele.

●​ Als een paragraaf CALC-TAX GROSS-INCOME leest, identificeert de graaf GROSS-INCOME als een invoerafhankelijkheid .

●​ Bij het genereren van de Java-methode calcTax() voegt de AI expliciet BigDecimal grossIncome toe aan de methodesignatuur.

●​ Vervolgens werkt ze de aanroeper van de methode bij om de juiste waarde door te geven.

Deze automatische refactoring van "impliciete globale toestand" naar "expliciete parameterdoorgave" voorkomt de side-effectbugs die de bank in onze casestudy teisterden. ⁴

6.2 De GOTO-spaghetti ontwarren

Een van de felste obstakels bij COBOL-migratie is de GOTO-instructie. GOTO laat programma-uitvoering overal naartoe springen, wat niet-lineaire controlestromen creëert die haaks staan op moderne gestructureerde programmering. ⁴⁰ Java heeft geen GOTO-instructie.

GOTO-logica vertalen vereist meer dan syntaxisvertaling; het vereist control-flow- flattening .

1.​ Graafanalyse: We mappen de GOTO-bestemmingen als edges in de Control Flow Graph (CFG).

2.​ Patroonherkenning: De graaf identificeert patronen.

○​ Een GOTO die terugspringt naar een eerdere label wordt geïdentificeerd als een lus .

○​ Een GOTO die een blok overslaat wordt geïdentificeerd als een conditioneel (if/else).

○​ Een GOTO naar een exit-paragraaf is een return .

3.​ Herstructurering: De AI, geleid door de graaf, herfactort deze sprongen tot while-lussen, do-while-lussen, of break/continue-statements in Java.

Zonder een graaf om de "lussen" te visualiseren die GOTO creëert, zal een tekstgebaseerde LLM vaak een recursieve functieaanroep genereren die tot een StackOverflowError leidt, of simpelweg een logische flow hallucineren die niet bestaat. ⁴

6.3 Omgaan met "dode code"

Legacy-systemen zitten vol code die niet meer wordt gebruikt—oude campagnes, uitgefaseerde producten, debugroutines. Deze code migreren is geldverspilling en vergroot het aanvalsoppervlak. Tekstgebaseerde AI migreert alles wat ze krijgt; ze kan geen onderscheid maken tussen actieve en dode code.

De oplossing: De call graph identificeert onbereikbare nodes—paragrafen of bestanden zonder inkomende edges (geen aanroepers). Het systeem van Veriprajna markeert deze "dode code" voor verwijdering voordat de migratie start. Dit reduceert de codebase doorgaans met 20-30%, wat leidt tot aanzienlijke kostenbesparingen en een schonere eindarchitectuur.31

Hoofdstuk 7: De agentische toekomst – Deep AI versus oppervlakkige wrappers

7.1 Voorbij de chatbot: de agentische workflow

Veriprajna deployt geen "chatbots." Wij deployen autonome AI-agents . Een agent is een systeem dat kan plannen, uitvoeren en zijn acties op basis van feedback corrigeren. ²

De oppervlakkige-wrapper-workflow:

1.​ Gebruiker: "Converteer deze code."

2.​ Wrapper: Stuurt tekst naar GPT-4.

3.​ Output: Geeft Java-code terug.

4.​ Resultaat: Code compileert of draait niet. Ontwikkelaar debugt handmatig.

De Veriprajna Deep Agent-workflow:

1.​ Planning: De agent analyseert de AST van het doel-COBOL-bestand. Hij identificeert afhankelijkheden en bevraagt de kennisgraaf.

2.​ Retrieval: Hij haalt de GraphRAG-context op die nodig is voor de migratie.

3.​ Generatie: Hij genereert de Java-code met een "schematic-constraint decoder" die Java-syntaxisregels en typeveiligheid afdwingt. ⁷

4.​ Verificatie (de lus): De agent compileert de gegenereerde Java-code in een sandbox.

5.​ Zelfcorrectie: Als de compiler een fout gooit (bijv. "Variable not found"), leest de agent de fout, bevraagt de graaf voor de ontbrekende afhankelijkheid, en genereert de code opnieuw.

6.​ Validatie: Hij voert unittests uit (gegenereerd uit de oorspronkelijke COBOL-traces) om te garanderen dat de output overeenkomt met het invoergedrag.

Deze compile-fix-lus verschuift de validatielast van de mens naar de AI, dramatisch de kosten van refactoring verlagend. ⁴²

7.2 Human-in-the-loop-supervisie

Hoewel de agent autonoom is in uitvoering, wordt hij in strategie gesuperviseerd. De kennisgraaf biedt interpreteerbaarheid . In tegenstelling tot een "black box"-neuraal netwerk laat de graaf ontwikkelaars precies zien waarom de AI een beslissing nam. "De AI importeerde com.bank.logic omdat hij een afhankelijkheid van COPYBOOK-X."

Deze transparantie is vitaal voor gereguleerde sectoren zoals het bankwezen, waar elke regel code auditbaar moet zijn. We bewegen van "Vertrouw me, ik ben AI" naar "Hier is de citatieketen voor deze logica". ⁴³

Hoofdstuk 8: Conclusie en strategisch perspectief

8.1 De ROI van repository-awareness

McKinsey-gegevens suggereren dat GenAI codingtaken met 50% kan reduceren, maar alleen indien correct ingezet. ¹⁴ Het rendement op investering (ROI) van Veriprajna's graafgebaseerde aanpak wordt gedreven door het wegnemen van herwerk.

●​ Handmatige migratie: Hoge kosten, hoog risico, trage time-to-market.

●​ Wrapper-AI: Gemiddelde kosten (door debuggen van "hallucinaties"), hoog risico (verborgen bugs), gemiddelde time-to-market.

●​ Repository-graaf-AI: Lage kosten (automatisering), laag risico (deterministische verificatie), snelle time-to-market.

Door de overhead van "context switching" weg te nemen—waarbij ontwikkelaars uren zoeken naar waar een variabele is gedefinieerd—verhoogt Veriprajna de productiviteit van ontwikkelaars met 2x tot 3x vergeleken met standaard-AI-tools. ²

8.2 Toekomstbestendig maken via continue modernisering

Modernisering is geen eenmalige gebeurtenis; het is een levenscyclus. Zodra de codebase tot een kennisgraaf is omgezet, blijft die een levend asset. Naarmate de nieuwe Java-code evolueert, wordt de graaf in realtime bijgewerkt. Dit maakt mogelijk:

●​ Geautomatiseerde documentatie: De AI kan actuele documentatie genereren voor het nieuwe systeem door de graaf te lezen. ⁴⁴

●​ Detectie van architectuurdrift: Het systeem kan architecten waarschuwen als nieuwe code modulariteitsregels schendt die in de graaf zijn gedefinieerd. ⁴⁵

8.3 De structurele verschuiving

De les van de "bankcrash" is helder: code is geen tekst. Het is een complex, onderling verbonden systeem van logica. Het moderniseren met tools die alleen tekst begrijpen is vergelijkbaar met een stad navigeren met een lijst straatnamen maar zonder kaart. U raakt "Lost in the Middle."

Veriprajna biedt de kaart. Door repository-bewuste kennisgrafen te bouwen, geven we de AI de structurele intelligentie die ze nodig heeft om de complexiteit van legacy-systemen te navigeren. We brengen de afhankelijkheden in kaart, we ontwarren de knopen, en we leveren modernisering die werkt niet alleen in syntaxis, maar in de werkelijkheid.

We schrijven niet louter code; we engineeren begrip. Dit is het verschil tussen een chatbot en een solution provider. Dit is de toekomst van enterprise-modernisering.

Veriprajna. Deep AI voor diepe oplossingen.

Geciteerde werken

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

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

3. Lost-in-the-Middle Effect | LLM Knowledge Base - Promptmetheus, geraadpleegd op 10 december 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, geraadpleegd op 10 december 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, geraadpleegd op 10 december 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, geraadpleegd op 10 december 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, geraadpleegd op 10 december 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, geraadpleegd 10 december 2025, https://arxiv.org/html/2509.25257v1

9. 40 Legacy Software Migration Trends for Enterprises in 2025 | Adalo, geraadpleegd op 10 december 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, geraadpleegd op 10 december 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, geraadpleegd op 10 december 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, geraadpleegd op 10 december 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, geraadpleegd op 10 december 2025, https://www.esparkinfo.com/blog/application-modernization-statistics

14. Modernizing legacy architectures using GenAI-powered Knowledge Graphs | by Sigmoid, geraadpleegd op 10 december 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, geraadpleegd op 10 december 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, geraadpleegd op 10 december 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, geraadpleegd op 10 december 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, geraadpleegd op 10 december 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, geraadpleegd 10 december 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, geraadpleegd op 10 december 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, geraadpleegd op 10 december 2025, https://pub.towardsai.net/why-language-models-are-lost-in-the-middle-629b20d86152

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

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

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

25. BMSD 2011, geraadpleegd op 10 december 2025, https://is-bmsd.org/Documents/ProceedingsOfFirstBMSD.pdf

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

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

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

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

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

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

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

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

34. Codebase to Knowledge Graph generator : r/LocalLLaMA - Reddit, geraadpleegd op 10 december 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, geraadpleegd op 10 december 2025, https://arxiv.org/html/2511.07584

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

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

38. Navigating the Nuances of GraphRAG vs. RAG - foojay, geraadpleegd op 10 december 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, geraadpleegd op 10 december 2025, https://medium.com/data-science-in-your-pocket/graphrag-vs-rag-which-is-beter-81a27780c4ff

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

41. Alternative to a goto statement in Java - Stack Overflow, geraadpleegd op 10 december 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, geraadpleegd op 10 december 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, geraadpleegd op 10 december 2025, https://www.mitre.org/news-insights/publication/legacy-it-modernization-ai

44. Documenting and Modernizing Legacy Codebases with C3 Generative AI, geraadpleegd op 10 december 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, geraadpleegd op 10 december 2025, https://vfunction.com/blog/ai-app-modernization-strategy/