Waarom AI-vertaalde COBOL uw database laat crashen

Het probleem

Een grote bank vroeg AI om dertig jaar COBOL naar Java te herschrijven. De AI vertaalde de syntaxis feilloos. De code compileerde. De unittests slaagden. Toen liet de eerste transactie de database crashen.

De mislukking had niets te maken met slechte code. De Java was grammaticaal foutloos. Het probleem was een verborgen afhankelijkheid — een variabele genaamd TRN-LIMIT, gedefinieerd in een gedeeld headerbestand duizenden regels verwijderd van de code die de AI daadwerkelijk vertaalde. Dat headerbestand bevatte een REDEFINES-clausule, een COBOL-feature waarmee één geheugenadres twee verschillende datatypen kan bevatten, afhankelijk van een vlag die in een compleet andere module wordt gezet. De AI zag hier niets van. Het behandelde TRN-LIMIT als een gewoon getal. In werkelijkheid was het een packed decimal. Deze mismatch zorgde ervoor dat de Java-applicatie gecorrumpeerde binaire gegevens in de database wegschreef, wat een referentiële-integriteitsfout veroorzaakte.

Dit is geen randgeval. Onderzoek toont aan dat 70% tot 80% van de moderniseringsprojecten voor legacysystemen hun doelen niet haalt. Uw organisatie draait vrijwel zeker kritieke systemen op code die ouder is dan de meeste van uw medewerkers. Als u een migratie plant — of al middenin zit — dan zou dit faalpatroon u ernstig zorgen moeten baren. De AI maakte geen typefout. Het miste een relatie die het niet kon zien. Dat is een fundamenteel ander soort risico, en de meeste huidige tools hebben daar geen antwoord op.

Waarom dit belangrijk is voor uw bedrijf

De financiële blootstelling hier is enorm, en het raakt elke post op uw balans.

Alleen al in de Verenigde Staten is de technologische schuld naar schatting opgelopen tot $1.52 biljoen. Als uw organisatie met legacysystemen werkt, draagt u op dit moment een deel van die last. Ongeveer 80% van de federale IT-budgetten gaat naar beheer en onderhoud — er blijft slechts 20% over voor alles wat nieuw is. De bankensector is bijzonder kwetsbaar: 43% van de banksystemen draait nog op COBOL, en die systemen verwerken 95% van alle geldautomaattransacties.

Dit betekent het volgende voor uw risicoprofiel:

• Het beveiligingsrisico verdrievoudigt. Systemen ouder dan tien jaar lopen statistisch gezien drie keer zo veel kans op een datalek als moderne applicaties. Elk kwartaal waarin u modernisatie uitstelt, groeit uw aanvalsoppervlak.
• De nalevingsdruk neemt toe. Regelgeving zoals GDPR en DORA eist realtime rapportage en controles op gegevensprivacy. Legacysystemen zijn niet ontworpen voor deze eisen. Uw onvermogen om zich aan te passen wordt een compliance-risico waar uw toezichthouders iets van zullen merken.
• Uw experts vertrekken. De ontwikkelaars die deze systemen schreven, gaan met pensioen. Achtenvijftig procent van de ontwikkelaars zegt te overwegen te stoppen vanwege verouderde technologiestacks. Wanneer institutionele kennis de deur uitloopt, stijgen uw onderhoudskosten verder.
• Mislukte migraties verspillen miljoenen. Met een faalkans van 70-80% staan de kansen tegen u. Een mislukte migratie kost niet alleen het projectbudget — hij ondermijnt het vertrouwen in uw technologieleiderschap en stelt de bedrijfsmogelijkheden waarop uw teams wachten uit.

Uw raad van bestuur wil digitale transformatie. Uw toezichthouders willen moderne controles. Uw budget is al krap om de boel draaiende te houden. U kunt een migratie die stilletjes mislukt niet veroorloven.

Wat er werkelijk onder de motorkap gebeurt

Om te begrijpen waarom standaard AI hierin faalt, moet u uw codebase zien als een stad. Elke functie, variabele en databasetabel is een gebouw. De verbindingen ertussen — welke functie welke aanroept, welke variabele welke berekening voedt — zijn de wegen.

Stelt u zich nu voor dat u iemand een telefoonboek geeft met elk gebouw in de stad en vraagt om het openbaarvervoersysteem opnieuw te ontwerpen. Die persoon heeft namen en adressen, maar geen kaart. Hij kan niet zien welke wegen welke gebouwen verbinden. Precies dat doet een standaard AI-codingtool met uw code. Het leest de tekst, maar ziet de structuur niet.

Het specifieke technische falen staat bekend als het "Lost in the Middle"-effect. Large Language Models — de AI-motoren achter tools zoals codingassistenten — verwerken tekst met behulp van een attention-mechanisme. Onderzoek heeft aangetoond dat deze modellen sterke reproductie vertonen van informatie aan het begin en het einde van een lange invoer, maar dat hun prestaties scherp dalen voor informatie die middenin begraven ligt. In een COBOL-programma dat duizenden regels beslaat en naar externe bestanden verwijst, zitten cruciale variabeledefinities vaak precies in die blinde vlek.

Als de AI een definitie mist, stopt het niet om het te vragen. Het raadt. Het vult het gat met iets dat statistisch plausibel maar feitelijk onjuist is. In AI-terminologie heet dit een hallucinatie. In uw banksysteem betekent dit dat de AI kan aannemen dat een variabele een integer is terwijl het in werkelijkheid een packed decimal is. Die ene verkeerde aanname kan financiële gegevens corrumperen, de database-integriteit breken en een transactiesysteem stilleggen. Uw code compileert. Uw tests slagen. Uw productieomgeving faalt.

Wat werkt (en wat niet)

Beginnen we met wat uw teams waarschijnlijk al hebben geprobeerd of overwogen — en waarom elke aanpak tekortschiet.

Lift and Shift (rehosting): U verplaatst de gecompileerde applicatie naar een cloudemulator. Dit verandert uw hostingfactuur, maar behoudt elke regel verstrikte legacycode. U neemt alle technologische schuld mee naar een nieuwe omgeving en wint geen enkele flexibiliteit van de cloud.

Handmatige herschrijving: U huurt ontwikkelaars in om alles met de hand naar Java te herschrijven. Dit is pijnlijk traag, astronomisch duur en afhankelijk van het vinden van mensen die zowel COBOL als moderne architectuur begrijpen. Nu uw COBOL-experts met pensioen gaan, wordt dit elk jaar moeilijker.

AI-wrappertools: U richt een commerciële AI-codeerassistent op uw codebase. Het vertaalt syntaxis snel. Maar zoals de mislukking bij de bank laat zien, mist het afhankelijkheden tussen bestanden, hallucineert het variabeledefinities en produceert het code die er goed uitziet maar zich verkeerd gedraagt.

Dit is wat daadwerkelijk werkt — een op grafen gebaseerde aanpak die uw code behandelt als een verbonden systeem in plaats van een stapel tekstbestanden:

1. Parseer de structuur, niet alleen de tekst. In plaats van uw code in willekeurige tekstchunks te hakken, parseert u elk bestand naar een boom die de logische structuur weergeeft — elke variabele, elke functie, elke tak van de controlestroom. Zo respecteert de AI de grenzen van uw code. Een functie wordt behandeld als een complete logische eenheid, niet als een willekeurig plakje tekst.

2. Bouw een kaart van elke relatie. U haalt elke verbinding in uw codebase eruit — welke modules welke subroutines aanroepen, welke bestanden welke variabelen definiëren, welke functies welke databasetabellen bijwerken — en slaat ze op in een knowledge graph. Als de AI een betalingsfunctie moet vertalen, grijpt het niet zomaar tekst die "payment" vermeldt. Het volgt de daadwerkelijke afhankelijkheidsketen om elke variabeledefinitie, elk gedeeld headerbestand en elke downstream-impact binnen te halen. Dit is wat Veriprajna noemt: een Repository-Aware Knowledge Graph, en het lost daarmee het "Lost in the Middle"-probleem rechtstreeks op.

3. Controleer elke output tegen de kaart. De AI genereert Java-code en compileert die vervolgens in een sandbox. Als de compiler een foutmelding geeft — bijvoorbeeld een ontbrekende variabele — raadpleegt het systeem de graaf, vindt de afhankelijkheid en genereert de code opnieuw. Deze compile-fix-lus draait automatisch. Uw ontwikkelaars beoordelen geverifieerde outputs, geen ruwe AI-gokjes.

Het voordeel dat voor uw compliance- en auditteams het zwaarst weegt: elke beslissing die de AI neemt, is traceerbaar. De knowledge graph legt exact vast waarom de AI een bepaalde bibliotheek importeerde of een variabele op een bepaalde manier definieerde. In plaats van een black box krijgt u een citatieketen. Uw auditors kunnen de logicadrade van elke regel gegenereerde code volgen.

Deze aanpak elimineert ook verspilling voordat de migratie begint. De knowledge graph identificeert dode code — functies die niets in uw systeem daadwerkelijk aanroept. Het verwijderen van dode code verkleint de codebase doorgaans met 20-30%, wat neerkomt op lagere migratiekosten en een schoner eindresultaat.

Voor organisaties in financiële dienstverlening die te maken hebben met toezicht door toezichthouders, is dit soort transparantie niet optioneel. En als uw modernisatie vereist dat u de herkomst van gegevens over systemen heen kunt traceren, breiden Veriprajna's gegevensherkomst en traceerbaarheid -mogelijkheden dezelfde op grafen gebaseerde aanpak uit naar uw volledige datapijplijn.

U kunt de volledige technische analyse lezen voor de engineeringdetails, of de interactieve versie verkennen voor een visuele rondleiding langs de manier waarop de knowledge graph in de praktijk werkt.