AI’s Beste ROI Op Dit Moment Is Het Repareren Van Oude Code, Niet Het Schrijven Van Nieuwe Code

Elke AI-productdemonstratie die ik bijwoon, begint op dezelfde manier: een lege promptbox, een verzoek in gewoon Engels en een werkende app een paar minuten later. Het is een echt indrukwekkende partytruc. Het is ook, zou ik argumenteren, het minst interessante dat er op dit moment gebeurt in enterprise AI.

Het meer consequente werk gebeurt op een veel minder glamoureuze plek: binnen vijftien jaar oude codebases die niemand wil aanraken, geschreven door ingenieurs die het bedrijf tien jaar geleden hebben verlaten, met bedrijfslogica die niemand in jaren volledig heeft begrepen. De meeste AI-berichtgeving krijgt dit verkeerd. Legacy-code is geen technische schuld. Het is opgespaarde bedrijfsintelligentie: decennia van beslissingen, gecodeerd als software, met de mensen die die beslissingen namen allang vertrokken.

Groene veldontwikkeling krijgt de keynote-slots. De oude code krijgt het geld, met tegenzin, en meestal zonder het begrip dat nodig is om het goed te besteden.

Het Echte Gebrek Is Niet Ontwikkelaars, Maar Geheugen

Dit is geen geïsoleerd probleem. Een studie van Pegasystems uit 2025, uitgevoerd door het onderzoeksbureau Savanta onder meer dan 500 IT-beslissers wereldwijd, schat dat het gemiddelde wereldwijde bedrijf meer dan $370 miljoen per jaar verliest door zijn onvermogen om legacy-systemen efficiënt te moderniseren, met bijna $134 miljoen daarvan gekoppeld aan langzame, resource-intensieve transformatieprojecten alleen.

We werkten onlangs met een batterijverdelingsbedrijf dat meer dan vijftien legacy-toepassingen uitvoerde, het soort verspreiding dat zich ophoopt over twintig jaar van fusies, eenmalige integraties en ingenieurs die vandaag probleem oplossen zonder veel te denken aan morgen. Daar waren prijsregels, voorraaddrempels en distributiebeperkingen begraven, die jaren van institutionele beslissingen vertegenwoordigden, nergens anders opgeschreven dan in logica die niemand volledig had gekarteerd.

Het is verleidelijk om dit een talentprobleem te noemen: meer ontwikkelaars inhuren, sneller migreren. Maar je kunt niet inhuren om het feit dat de persoon die begreep waarom een module op een bepaalde manier werkte, het bedrijf in 2014 heeft verlaten. De meeste bedrijven lijden aan een geheugentekort, niet aan een talenttekort. En tot voor kort was er geen echte manier om dit op grote schaal op te lossen. Je betaalde een handvol senior ingenieurs om de institutionele kennis in hun hoofd te houden totdat ze vertrokken.

Wat AI Echt Verandert

We hebben geen code-generatietool op de oude codebase gericht en hem verteld om alles opnieuw te schrijven; dat is ongeveer hoe je stilzwijgend bedrijfslogica verwijdert die je niet wist dat het bestond. In plaats daarvan gebruikten we AI-agents om het onglamoureuze grondwerk te doen: om te traceren hoe de vijftien-plus toepassingen daadwerkelijk met elkaar waren verbonden, om de beslissingen die in de logica waren ingebed te laten zien, die nooit elders waren opgeschreven, en om die context vast te houden als iets dat de organisatie kon opvragen, niet als iets dat alleen in het hoofd van een ingenieur leefde. Dit komt overeen met wat andere AI-leveranciers nu openbaar documenteren: Anthropics richtlijnen voor het moderniseren van COBOL-systemen met Claude Code beschrijven dezelfde sequentie, automatiseren van de exploratie- en analysefasen eerst in plaats van rechtstreeks naar herschrijven te springen.

De agents werden niet beoordeeld op hoeveel code ze gegenereerd hadden. Ze werden beoordeeld op hoeveel institutionele kennis ze konden blootleggen en behouden. Ingenieurs werkten vervolgens naast hen aan de daadwerkelijke migratie en testgeneratie, waarbij ze de agents’ interpretatie van bedrijfslogica controleerden tegen hoe het systeem zich in productie gedroeg, niet vertrouwend op geloof alleen. Een nuttig signaal dat we keken: kwam de agents’ verklaring van een regel overeen met een patroon dat we onafhankelijk konden verifiëren in productielogboeken, of was het een plausibele klinkende gok? De kloof tussen die twee is precies waar legacy-moderniseringsprojecten meestal misgaan.

De oorspronkelijke schatting voor het project was acht en een half maand. Het werd gesloten in vier, een reductie van 53%. Maar het duurzamere resultaat was niet de tijdlijn. Institutionele kennis die eerder elke keer verdween wanneer een ingenieur het bedrijf verliet, werd iets dat de organisatie daadwerkelijk kon behouden.

Software-ingenieurs hebben decennia lang software geschreven. Het komende decennium kan besteed worden aan het opgraven ervan, met AI die minder optreedt als auteur en meer als archeoloog, die zorgvuldig de redenering reconstrueert die begraven ligt in code die de mensen die het hebben geschreven, overleefd heeft.

Een Ruwe Kader Voor Het Doen Hiervan Zonder Dingen Te Breken

De projecten die goed gaan, lijken ongeveer dezelfde sequentie te volgen, of het systeem nu een prijsmotor of een claimsleiding is:

Ontdek: kaart hoe de systemen daadwerkelijk zijn verbonden, niet hoe de architectuurdiagram van 2016 zegt dat ze zijn verbonden.

Begrijp: laat de agent de bedrijfslogica en de aannamen erachter blootleggen, in gewoon taalgebruik dat een domeinexpert kan controleren.

Verifieer: controleer die interpretatie tegen echte productiegewoonten, niet alleen tegen de code-opmerkingen.

Transformeer: migreer of herbouw alleen wanneer de eerste drie fasen standhouden, met mensen die de goedkeuring bezitten.

Spring rechtstreeks naar Transformeren, en je bent niet aan het moderniseren. Je bent met logica gokken die je nog niet begrijpt.

Waarom Dit Buiten Engineering Teams Materiaal Is

Institutionele geheugen gaat niet zomaar stilzwijgend ten onder wanneer een senior ingenieur met pensioen gaat. Het wordt een acute aansprakelijkheid op het exacte moment dat een bedrijf het zich het minst kan veroorloven: tijdens een overname, wanneer een nieuwe eigenaar moet begrijpen wat hij daadwerkelijk heeft gekocht; tijdens een ERP-migratie, wanneer oude logica correct moet worden vertaald naar een nieuw systeem voor de eerste keer; tijdens een compliance-audit of incidentreactie, wanneer iemand moet uitleggen waarom het systeem op een bepaalde manier gedroeg, onder een deadline, aan een regulator die “de persoon die het heeft gebouwd, is in 2014 vertrokken” niet als antwoord accepteert.

Behandeld op deze manier, stopt legacy-modernisering met een engineering-regel en begint het eruit te zien als een organisatorische veerkrachtvraag, wat betekent dat het niet alleen CTO’s zijn die zich zorgen moeten maken. Het zijn CIO’s die overwegen wat er gebeurt wanneer belangrijke technische staf vertrekt, M&A-teams die proberen te begrijpen wat ze daadwerkelijk kopen, en raden die nadenken over hoeveel van de operationele kennis van het bedrijf nergens anders bestaat dan in code die niemand op dit moment leest.

De Voorbehoud Die Ertoe Doet

Niets van dit werkt onbeheerd. De riskantste versie van deze aanpak is een waarin een agents’ interpretatie van oude bedrijfslogica zonder verificatie wordt vertrouwd, omdat legacy-systemen precies de plek zijn waar een zelfverzekerde verkeerde AI-aanname het meeste kost. Volledige autonomie op uw nieuwste microservice is een redelijke gok. Volledige autonomie op de prijsmotor die niemand sinds 2011 heeft aangeraakt, is dat niet. De waarde is dat AI het mogelijk maakt om opnieuw de ingenieurs te worden die het bedrijf begrijpen, in een systeem dat niemand op dit moment begrijpt. Het vervangt ze niet.

Waar Ik Denk Dat Dit Naartoe Gaat

Twintig jaar lang hebben bedrijven legacy-software behandeld als iets om te ontsnappen: een kostenpost om met tegenzin te financieren en zo snel mogelijk te moderniseren. Ik denk dat AI op het punt staat te onthullen dat veel van die code eigenlijk een van de meest waardevolle kennisrepositories was die het bedrijf ooit heeft gebouwd. Het had alleen iets nodig dat het kon lezen. Onderzoekers documenteren al de andere kant van deze lus: een 2026 multivocal literatuuroverzicht over LLM-ondersteund ontwikkelingsonderzoek vindt dat de huidige achtervolging van AI-versnelde snelheid zelf “fast-integratieschuld” creëert, code die sneller wordt verzonden dan het kan worden begrepen. Legacy-modernisering is alleen maar de rekening die eindelijk komt, een generatie eerder.

Ik zou graag willen weten of andere technologie- en technologieleiders dezelfde verschuiving zien: verschijnt de return on your AI-investering meer in wat je aan het bouwen bent, of in wat je eindelijk kunt begrijpen en behouden? En voor iedereen die AI-agents heeft uitgevoerd tegen een echt oude, ongedocumenteerde systeem, waar hield de agents’ begrip stand onder verificatie, en waar viel het stilzwijgend uit elkaar?