the Legacy problem is unsolvable, so we need a new paradigm behind computing.

This blog is mainly written in Dutch.

Jump to the English version pput into an Article push here.

To the english Summary.

Ibtressante video’s druk hier.

J.Konstapel, Leiden, 8-2-2026

English Short Summary

This blog post argues that in 2026, the focus is not on eliminating legacy software but on managing and preventing it.

The state-of-the-art combines AI-driven modernization for existing systems with evolutionary, data-driven designs to prevent future legacy.

Key trends include using generative AI to automate code refactoring and migration, and hybrid cloud architectures to minimize risk.

To prevent new legacy, it emphasizes evolutionary architecture with automated “fitness functions,” active technical debt management, and modular design.

The conclusion is that software is never “finished,” and success lies in accepting continuous change, investing in the right tools, and maintaining disciplined governance.

Dit is een vervolg op 1 Hoe Komen we van de Legacy Software Af? (Deel 3) en

I2 s het Einde van de Nederlandse Overheid Is Nabij?

3 About Antifragile Design

Deel 1. is in samenspraak met GPT en Grok gemaakt en deel 2. met Genini.deel 3 met Deepseek en deel 5 met Claude

1 De State-of-the-Art in het Voorkomen en Oplossen van Legacy-Softwareproblemen in 2026

Inleiding: Het eeuwige spook van legacy-software

Legacy-software verwijst naar verouderde systemen die nog functioneren, maar moeilijk aanpasbaar, kostbaar in onderhoud en risicovol zijn voor beveiliging en schaalbaarheid. In 2026 blijft dit een van de grootste uitdagingen in de IT-wereld, vooral bij grote organisaties en overheden. De kernoorzaak is eenvoudig: softwareontwikkeling en de wereld eromheen veranderen permanent. Technologieën verouderen, wetgeving evolueert, beveiligingseisen verscherpen en businessbehoeften verschuiven sneller dan ooit tevoren door digitalisering en AI.

Geen enkele aanpak elimineert legacy definitief – wat vandaag modern is, wordt morgen legacy als het niet mee-evolueert. De state-of-the-art in 2026 richt zich daarom niet op een “eindoplossing”, maar op beheersing, versnelling en preventie. Belangrijke trends zijn de integratie van AI in modernisering, hybride cloud-architecturen en een verschuiving naar evolueerbare, data-gedreven ontwerpen. Dit essay beschrijft de top-of-the-bill benaderingen, gebaseerd op recente inzichten uit 2025-2026 rapporten, trends en praktijken.

Deel 1: Het oplossen van bestaande legacy – Modernisering in het AI-tijdperk

De focus bij het oplossen van legacy ligt in 2026 op AI-gedreven modernisering, die traditionele methodes versnelt en risico’s verlaagt. Handmatige refactoring of big-bang vervangingen zijn grotendeels achterhaald vanwege hoge faalkansen; in plaats daarvan domineert een incrementele, tool-ondersteunde aanpak.

1. AI-Native Modernization als leidende trend AI-tools automatiseren code-analyse, -vertaling en -refactoring. Generative AI (zoals LLM’s) converteert legacy-code (bijv. COBOL naar Java of Python) met behoud van functionaliteit, en reduceert timelines met 20-50%. Agentic AI (autonome agents) orchestreert complexere migraties. Dit is geen hype: proof-of-concepts bij bedrijven als Fujitsu en Morgan Stanley tonen meetbare versnelling. Tools zoals IBM watsonx Code Assistant en vergelijkbare platforms helpen bij het moderniseren van mainframes zonder volledige herschrijving.
2. Hybride en Multi-Cloud Architecturen Organisaties migreren legacy naar hybride omgevingen: behoud van on-premises kernsystemen terwijl nieuwe functionaliteit naar de cloud gaat. Dit minimaliseert uitvalrisico’s en maakt gebruik van cloud-native features zoals auto-scaling. API-first benaderingen (via gateways) ontkoppelen legacy van moderne frontends.
3. Strangler Fig Pattern en Modularisering Het klassieke Strangler-pattern (Martin Fowler) blijft relevant: bouw nieuwe componenten rondom legacy en vervang geleidelijk. In 2026 versterkt AI dit door automatisch modules te identificeren en te extraheren. Microservices en domain-driven design (DDD) helpen bij het opsplitsen van monoliths.

Deze combinatie maakt modernisering sneller en veiliger dan ooit, maar vereist nog steeds menselijke oversight voor complexe businesslogica.

Deel 2: Het voorkomen van nieuwe legacy – Evolueerbare architecturen en governance

Voorkomen is altijd beter dan genezen. De top-of-the-bill in preventie draait om proactief ontwerp en structurele discipline, zodat systemen verandering verdragen in plaats van erdoor vast te lopen.

1. Evolutionary Architecture met Fitness Functions Het concept uit Building Evolutionary Architectures (Ford et al., bijgewerkt tot 2022 en nog steeds invloedrijk) blijft een hoeksteen. Systemen ontwerpen met geautomatiseerde “fitness functions” – tests die architecturale eigenschappen (modulariteit, schaalbaarheid, beveiliging) continu monitoren. In 2025-2026 case studies (bijv. bij streamingdiensten) tonen dit aan als effectief voor langetermijnwendbaarheid.
2. Technical Debt Management als Kernpraktijk Quantificeer debt (via tools als SonarQube of CAST), embed governance in ontwikkelprocessen en reserveer budget voor continue refactoring. Gartner adviseert in 2025: organisaties die debt actief beheren, leveren 50% sneller nieuwe features. Best practices: scheid beheer- en innovatiebudgetten, voer periodieke audits uit en prioriteer debt in backlogs.
3. Modulariteit, Open Standaarden en Platform Engineering Bouw met losgekoppelde componenten (microservices, event-driven), open API’s en platformteams die herbruikbare infrastructuur bieden. Dit voorkomt silo’s en lock-in. Trends in 2026 benadrukken ook sustainable software: efficiënt ontwerp om toekomstige onderhoudskosten te minimaliseren.

AI helpt hier preventief: tools voorspellen debt en suggereren refactors tijdens ontwikkeling.

Deel 3: Real-world voorbeelden en beperkingen

• Enterprise cases: Bedrijven als Netflix en Amazon gebruiken evolutionary principes al jaren met succes; in 2026 zien we dit opschalen naar mid-market via AI-tools.
• Publieke sector: Estland’s X-Road en Singapore’s digitale platformen tonen dat modulaire, interoperabele ontwerpen legacy minimaliseren – geen monoliths, maar gedistribueerde services.
• Beperkingen: Zelfs de beste aanpakken garanderen geen eeuwige moderniteit. AI-modernisering reduceert effort, maar introduceert soms nieuwe debt als gegenereerde code niet goed beheerd wordt.

Conclusie: Beheersing in plaats van utopie

In 2026 is de top-of-the-bill een hybride van AI-versnelde modernisering en evolueerbare architecturen met strakke governance. AI maakt het oplossen van legacy praktischer dan ooit, terwijl principes als fitness functions en debt-quantificatie nieuwe legacy vertragen. Toch blijft het een continu proces: software is nooit “af”. Organisaties die dit accepteren – en investeren in discipline, tools en cultuur – winnen wendbaarheid en reduceren risico’s. Wie een definitieve “oplossing” zoekt, zal teleurgesteld blijven; de kunst is om legacy beheersbaar te maken in een wereld die nooit stilstaat.

Dit is de realiteit van 2026: pragmatisch, tool-gedreven en vooruitstrevend, maar geworteld in de erkenning dat verandering inherent is aan software.

AI-Powered Legacy System Modernization: Turning the Ceiling into a Launchpad

Waarom de statistische aannames hallucinaties veroorzaken

LLMs zijn probabilistische modellen: ze voorspellen het volgende token (woord of deel ervan) op basis van statistische patronen in trainingsdata. Ze hebben geen echt begrip van feiten, waarheid of realiteit – alleen correlaties. Als data spaarzaam, tegenstrijdig of afwezig is, vullen ze aan met wat statistisch plausibel lijkt, wat vaak leidt tot fouten. Dit is geen bug, maar een feature van de architectuur.

Belangrijke inzichten uit recente bronnen (begin 2026):

• Hallucinaties ontstaan omdat modellen getraind zijn om altijd een antwoord te geven, zelfs bij onzekerheid, in plaats van “ik weet het niet” te zeggen. Benchmarks belonen gokken boven abstaining.
• Onder de “open world assumption” (de wereld is oneindig en onvoorspelbaar) zijn hallucinaties inevitabel, omdat modellen niet alle mogelijke waarheden kunnen leren.
• Sommige onderzoekers stellen dat elke output technisch een hallucinatie is: een statistische gok die toevallig correct kan zijn.

Is het “bewezen” dat het altijd gebeurt?

Nee, niet in absolute zin. Hallucinatie-rates zijn meetbaar en variëren sterk:

• In 2026 liggen rates bij topmodellen vaak tussen 0.7-1.5% op eenvoudige taken, maar tot 50-82% op complexe of medische/juridische queries.
• Artikelen uit januari 2026 vragen zich af: “It’s 2026, why are LLMs still hallucinating?” – Het probleem is verminderd, maar niet weg.

OpenAI zelf (2025) zegt dat hallucinaties niet inevitabel zijn: met betere training en abstaining-mechanismes kunnen ze sterk verminderd worden. Maar critici wijzen erop dat de statistische basis het altijd mogelijk maakt.

Nieuwe essays schrijven is mijn specialiteit. Waar Hans Konstapel in zijn blog de huidige staat van 2026 prachtig schetst, gaan we nu een stap verder. We kijken naar de symbiose tussen mens en machine, de “onzichtbare” legacy van data en de naderende storm van quantum computing.

2. De Paradox van de Eeuwige Vernieuwing: Legacy Beheersen in het Tijdperk van Autonome Systemen

Inleiding: De verschuiving van ‘Repareren’ naar ‘Evolueren’

In 2026 is het concept “legacy” fundamenteel veranderd. We zien software niet langer als een statisch bouwwerk dat langzaam vervalt, maar als een levend organisme. Het legacyprobleem wordt niet meer opgelost door systemen te vervangen, maar door ze te laten muteren. De meest innovatieve aanpakken van dit moment maken gebruik van autonome intelligentie om de kloof tussen verleden en toekomst te dichten.

1. De Staat van de Kunst: Autonome Modernisering

Waar we voorheen afhankelijk waren van menselijke programmeurs om miljoenen lijnen COBOL of verouderde Java te ontcijferen, zetten we nu Multi-Agent Systemen in.

• Agentic Refactoring: In plaats van een simpele vertaaltool gebruiken we een team van AI-agents. Een Architect Agent brengt de afhankelijkheden in kaart, een Coder Agent herschrijft de modules, en een Validator Agent schrijft direct de bijbehorende tests.
• Self-Healing Architectures: Innovatieve systemen in 2026 zijn uitgerust met ‘architecturale immuunsystemen’. Via Fitness Functions monitort het systeem zichzelf. Zodra een module te complex wordt of niet meer voldoet aan de veiligheidseisen, stelt de software zelf een refactoring-plan voor.
• Hulpmiddelen: Tools zoals IBM watsonx Code Assistant voor mainframes en AI-first editors zoals Cursor of Google Antigravity maken het mogelijk om legacy-code in real-time te moderniseren terwijl je erin werkt.

Het ‘Strangler Fig’ patroon blijft de gouden standaard: nieuwe moderne functies groeien rondom de oude kern heen, totdat de kern volledig is vervangen.

2. Het Voorkomen van de Legacy van Morgen

De grootste innovatie in preventie is de verschuiving naar AI-Native Software Engineering. We voorkomen legacy door software “veranderbaar” te maken vanaf de eerste regel code.

• Requirements-as-Code: Legacy ontstaat vaak omdat niemand meer weet waarom iets is gebouwd. In 2026 worden eisen direct vastgelegd in machine-leesbare formaten die gekoppeld zijn aan de code. Verandert de wetgeving? Dan signaleert de AI direct welke code-onderdelen aangepast moeten worden.
• Technisch Schuldenbeheer (FinOps for Code): Tools als CAST Highlight en CodeScene geven technische schuld een prijskaartje. Innovatieve organisaties behandelen code-onderhoud nu als een financiële balans: je mag pas nieuwe functies bouwen als de “schuld” van de bestaande code onder een bepaald niveau blijft.

3. De Toekomst: Wat kunnen we na 2026 verwachten?

De horizon van softwareontwikkeling verschuift naar drie cruciale gebieden:

A. De Quantum-muur (Post-Quantum Migratie)

Tussen 2027 en 2030 komt de grootste legacy-uitdaging ooit: Quantum-veiligheid. Bijna alle huidige encryptie in legacy-systemen is kwetsbaar voor toekomstige quantumcomputers. We verwachten een enorme golf van “cryptografische modernisering” waarbij AI-agents alle oude beveiligingsprotocollen in miljoenen regels code moeten opsporen en vervangen door Post-Quantum Cryptography (PQC).

B. Neuro-Symbolische AI

De huidige LLM’s (probabilistisch) maken soms fouten. De volgende generatie tools zal Neuro-Symbolische AI gebruiken: een combinatie van de creativiteit van LLM’s met de ijzeren logica van formele wiskunde. Dit betekent dat we legacy-systemen kunnen bewijzen; we weten 100% zeker dat de nieuwe software exact hetzelfde doet als de oude, zonder de hallucinaties van huidige AI.

C. De “No-Code” Legacy Paradox

We stevenen af op een nieuwe vorm van legacy: miljoenen kleine applicaties gebouwd door AI of no-code platformen (“Shadow AI”). De toekomst vraagt om Autonomous Governance, waarbij AI-systemen continu over het internet en bedrijfsnetwerken scannen om deze versnipperde applicaties te catalogiseren en te beveiligen voordat ze de “nieuwe legacy” worden.

Conclusie: Van Statisch naar Vloeibaar

Het legacyprobleem is in de kern een probleem van stilstand. De meest innovatieve aanpak van 2026 is het accepteren dat software nooit “klaar” is. Door AI niet alleen te gebruiken als een hamer om oude code kapot te slaan, maar als een tuinman die de code continu bijsnoert en verzorgt, transformeren we onze IT-landschappen van stijve betonblokken naar vloeibare, adaptieve systemen.

De toekomst van software is niet het bouwen van iets dat blijft, maar het bouwen van iets dat kan veranderen.

3 Het Beheersen van Legacy in 2026: Voorbij de Technologische Utopie

Inleiding: De Ontbrekende Schakels in het Moderniseringsverhaal

Het essay “Hoe Komen we van de Legacy Software Af? (Deel 4)” biedt een scherpe en actuele analyse van de technologische staat van legacybeheer in 2026. Het schetst een toekomst waarin AI-gedreven modernisering en evolutionaire architectuur de kern vormen van een pragmatische aanpak. Toch, in zijn focus op tools en architectuurprincipes, blijft het essentiële dimensies onderbelicht die in de praktijk vaak het verschil maken tussen succes en mislukking. Dit aanvullende essay breidt dat perspectief uit door de cruciale menselijke, organisatorische en procesmatige componenten te onderzoeken die nodig zijn om de technologische visie te realiseren. Waar het originele essay AI als de “tuinman” van code positioneert, betogen wij dat de échte tuinman de organisatiestructuur, de bedrijfscultuur en de operationele processen zijn die bepalen of de AI-tools effectief kunnen worden ingezet.

Deel 1: De Organisatorische Fundamenten: Van Silos naar Platform-denken

De meest geavanceerde AI-tools falen wanneer ze worden toegepast in een organisatie die niet is ingericht op wendbaarheid en samenwerking. Het originele essay benoemt platformengineering kort, maar mist de diepgaande implicaties van Team Topologies – een invloedrijk organisatiemodel geïntroduceerd door Matthew Skelton en Manuel Pais.

Team Topologies en Stream-Aligned Teams

Moderne software-evolutie vereist teams die zijn georganiseerd rond business capabilities in plaats van technologische lagen. Skelton en Pais (2019) introduceren het concept van “stream-aligned teams”: permanente, cross-functionele teams die verantwoordelijk zijn voor een end-to-end stroom van waarde. In de context van legacy-modernisering betekent dit dat een team eigenaar wordt van een specifiek businessdomein (bijvoorbeeld “Klantregistratie”) en de volledige autoriteit krijgt om zowel de oude als de nieuwe implementatie te beheren. Deze structuur elimineert de klassieke problemen waarbij een “moderniseringsteam” code over de muur gooit naar een “onderhoudsteam” – een recept voor nieuwe legacy. Onderzoek van de DevOps Research and Assessment (DORA) groep toont aan dat organisaties met deze teamstructuren meerdere keren sneller kunnen implementeren en aanzienlijk lagere mislukkingspercentages hebben.

Het Interne Platform als Versneller

Het platform dat deze stream-aligned teams ondersteunt, is geen nice-to-have maar een noodzakelijke voorwaarde. Het moet zich richten op ontwikkelaarsproductiviteit door een curated set van zelfservice-tools, API’s en services aan te bieden. Het State of DevOps Report 2023 benadrukt dat een goed intern platform de cognitieve last voor ontwikkelteams vermindert en hen in staat stelt zich te concentreren op bedrijfslogica in plaats van infrastructuurcomplexiteit. In de praktijk van legacy-modernisering betekent dit dat een team een nieuwe microservice kan bouwen en deployen met standaard templates, observability ingebakken, en beveiligingscontroles geautomatiseerd – zonder afhankelijk te zijn van een centrale infrastructuurafdeling. Dit platform is de operationele realisatie van de “evolueerbare architecturen” uit het originele essay.

Deel 2: Filosofische Verschuiving: Van Technische Schuld naar Waarde-bewustzijn

De dominante metafoor voor legacy is “technische schuld”. Hoewel nuttig, kan deze metafoor leiden tot een puur negatieve houding die de inherente waarde en stabiliteit van bewezen systemen negeert.

Sustaining Engineering: Proactief Waarde Behouden

Een groeiend filosofisch kader is dat van “Sustaining Engineering” of “Modernization Engineering”, zoals bepleit door praktijkmensen zoals Erik Dietrich. In plaats van legacy te zien als een puinberg die moet worden opgeruimd, richt deze aanpak zich op het oprichten van gespecialiseerde, permanente teams wiens primaire missie het is om de health, beveiliging en onderhoudbaarheid van kritieke bedrijfssystemen te verbeteren. Hun werk is niet “nieuwe features bouwen” maar de basis versterken: afhankelijkheden upgraden, monitoring verbeteren, documentatie bijwerken, en veiligheidslekken proactief patchen. Google’s “Site Reliability Engineering (SRE)“-model, zoals uiteengezet in hun baanbrekende boek, formaliseert een vergelijkbare aanpak door teams verantwoordelijk te maken voor zowel de operationele stabiliteit als de evolutionaire verbetering van services. Dit erkent dat veel legacy-systemen essentiële bedrijfsfuncties vervullen die, ondanks hun verouderde technologie, enorme operationele en historische waarde vertegenwoordigen.

Architectural Decision Records: De Context Bewaren

Een concrete praktijk die voortvloeit uit deze waarde-georiënteerde filosofie is het gebruik van Architectural Decision Records (ADR’s). Geïntroduceerd door Michael Nygard, is een ADR een lichtgewicht document dat een belangrijke architecturale beslissing vastlegt, inclusief de context, de overwogen alternatieven, en de verwachte gevolgen. In een moderniseringsproject worden ADR’s niet alleen bijgehouden voor nieuwe keuzes, maar ook – cruciaal – reconstructief toegepast op bestaande legacy. Door te documenteren waarom een systeem 10 jaar geleden op een bepaalde manier werd gebouwd (bijvoorbeeld vanwege een nu verdwenen beperking in een database), voorkom je dat toekomstige teams dezelfde fout opnieuw maken of kostbare functionaliteit per ongeluk verwijderen. Het bewaart de institutionele kennis die anders verloren gaat wanneer de oorspronkelijke ontwikkelaars vertrekken, en transformeert de legacy van een “black box” naar een begrepen systeem met een gedocumenteerde geschiedenis.

Deel 3: Geavanceerde Technische Strategieën: Incrementele Ontkoppeling

Naast het Strangler Fig-pattern bestaan er meer gespecialiseerde en krachtige technieken voor het veilig ontkoppelen van monolithische systemen.

Event-Driven Architecture als Moderniserings-Backbone

Event-Driven Architecture (EDA) is niet alleen een patroon voor nieuwe systemen, maar een bijzonder krachtige strategie voor modernisering. Het kernidee is om de legacy niet rechtstreeks aan te passen, maar er een laag gebeurtenissen omheen te bouwen. Technieken zoals Change Data Capture (CDC) – gebruikmakend van tools zoals Debezium – kunnen elke wijziging in de legacy-database in real-time vastleggen en publiceren naar een event stream (bijv. Apache Kafka). Moderne services kunnen dan op deze gebeurtenissen abonneren en hun eigen, bijgewerkte gegevensmodellen bijhouden, volledig losgekoppeld van het oude systeem. Deze aanpak, beschreven in praktijkgerichte boeken zoals “Designing Event-Driven Systems” van Ben Stopford, minimaliseert het risico omdat de legacy-code onaangeroerd blijft. Het maakt een geleidelijke, business capability voor business capability, migratie mogelijk waarbij de nieuwe en oude systemen een tijdje naast elkaar kunnen bestaan.

Formele Gedragsverificatie en Live Refactoring

Het originele essay noemt de uitdaging van het verifiëren van AI-gegenereerde code. Naast neuro-symbolische AI zijn er meer direct beschikbare technieken:

• Property-Based Testing & State Machine Modellen: Tools zoals QuickCheck (oorspronkelijk voor Haskell, nu beschikbaar voor vele talen) laten ontwikkelaars algemene “eigenschappen” van hun systeem specificeren (bijv. “nadat een bestelling is geplaatst, wordt het voorraadniveau nooit negatief”). De tool genereert dan automatisch honderden testgevallen om die eigenschap te proberen te schenden. Bij modernisering kan dit worden gebruikt om formeel aan te tonen dat het nieuwe en oude systeem dezelfde fundamentele regels volgen.
• Parallelle Uitvoering (Live Refactoring): Voor de allerkritiekste systemen is “big bang” of zelfs incrementele vervanging te riskant. Een geavanceerde techniek, zoals toegepast door LinkedIn met hun interne tool Greyhound, is parallelle uitvoering. Hierbij worden de nieuwe en oude implementatie van een service zij aan zij gedraaid. Het verkeer wordt geleidelijk van de oude naar de nieuwe versie gestuurd, en de uitkomsten worden continu vergeleken. Bij elke afwijking wordt het verkeer automatisch teruggeleid en wordt een alert gegenereerd voor onderzoek. Dit biedt het ultieme veiligheidsnet voor high-stakes modernisering.

Deel 4: Het Proactief Beheersen van de Nieuwe Legacy-golf

De grootste gemiste kans in het originele essay is de erkenning dat de huidige praktijken de volgende legacy-crisis actief creëren.

De Opkomst van “AI-Legacy”

Het wijdverbreide gebruik van generative AI voor codegeneratie leidt tot een nieuw fenomeen: “AI-Legacy”. Dit is code die ogenschijnlijk werkt, maar diepgaande problemen vertoont:

1. Gebrek aan Begrijpelijke Ontwerpdocumentatie: De code heeft geen onderliggende architectuur die door mensen kan worden begrepen; de “reden” voor de structuur ligt verborgen in de statistische gewichten van het AI-model.
2. Homogene, Brittle Codebases: AI-tools hebben de neiging om vergelijkbare patronen te genereren over verschillende projecten heen, wat leidt tot een gebrek aan architecturale diversiteit die cruciaal is voor veerkracht en tot wijdverbreide kwetsbaarheden bij de ontdekking van een fout in dat patroon.
3. Verwaarloosde Afhankelijkheden: AI genereert vaak code met specifieke bibliotheekversies. Zonder expliciete menselijke governance en geautomatiseerde tools zoals Dependabot of Renovate om deze bij te werken, ontstaat er snel een enorme schuld aan verouderde, onveilige afhankelijkheden.

Autonomous Governance als Antwoord

De oplossing ligt in het toepassen van dezelfde AI en automatisering op governance. Autonomous Governance betekent het inbouwen van compliance- en kwaliteitsregels rechtstreeks in de ontwikkelpijplijn en de runtime-omgeving. Tools kunnen:

• Automatisch architectuurdriften detecteren van goedgekeurde modellen.
• Verboden API-aanroepen of onveilige bibliotheken blokkeren bij het samenstellen of deployen.
• Continu licentiekwesties scannen in open-source afhankelijkheden.
• AI-gegenereerde code automatisch voorzien van metadata die de prompt, het gebruikte model en de gegenereerde architectuurbeslissingen vastlegt.

Dit is geen hypothetisch concept; cloud-leveranciers bieden al “Policy-as-Code” -diensten aan zoals AWS GuardDuty en Azure Policy, en open-source frameworks zoals Open Policy Agent (OPA) stellen teams in staat hun eigen regels te codificeren.

Conclusie: De Symbiose van Cultuur, Proces en Technologie

Het beheersen van legacy in 2026 is inderdaad, zoals het originele essay stelt, een kwestie van evolutie beheren in plaats van vervanging uitvoeren. Echter, de motor van die evolutie is niet alleen AI, maar de symbiose van drie krachten:

1. Een Ondersteunende Organisatie (gevormd door Team Topologies en aangedreven door een intern platform) die teams de autonomie en tools geeft om verantwoordelijk te zijn voor de evolutie van hun systemen.
2. Een Waarde-gecentreerde Filosofie (uitgedrukt in praktijken zoals Sustaining Engineering en ADR’s) die de stabiliteit van bestaande systemen respecteert en institutionele kennis bewaart als een actief.
3. Geavanceerde Technische Strategieën (zoals EDA-gestuurde modernisering en live refactoring) die het risico van verandering radicaal verminderen.

Zonder de eerste twee wordt de derde – hoe geavanceerd ook – ondermijnd. De echte “state-of-the-art” in 2026 is daarom niet een specifieke tool of AI-model, maar het vermogen van een organisatie om deze drie dimensies coherent te integreren. De grootste uitdaging is niet het moderniseren van COBOL, maar het voorkomen dat de digitale landschappen die we vandaag met de beste bedoelingen en krachtigste AI bouwen, morgen de onbegrijpelijke en onbeheersbare legacy worden waar we tegenop zien. De tuinman moet de tuin begrijpen, niet alleen de snoeischaar goed kunnen hanteren.

Referenties en Kernbronnen:

• Skelton, M., & Pais, M. (2019). Team Topologies: Organizing Business and Technology Teams for Fast Flow. IT Revolution Press.
• Forsgren, N., Humble, J., & Kim, G. (2018). Accelerate: The Science of Lean Software and DevOps. IT Revolution Press.
• Beyer, B., et al. (2016). Site Reliability Engineering: How Google Runs Production Systems. O’Reilly.
• Nygard, M. (2007). Documenting Architecture Decisions. [Artikel].
• Stopford, B. (2018). Designing Event-Driven Systems. O’Reilly.
• State of DevOps Report. (Jaarlijks). Puppet & Google Cloud DORA.
• Dietrich, E. Modernization Engineering & Sustaining Engineering. [Blogserie en lezingen].
• LinkedIn Engineering. Greyhound: Safe and Automated Live Refactoring. [Technische blog].

16:46

Deel 5: De Onzichtbare Grens – Waarom Alle Moderniseringsstrategieën Hetzelfde Probleem Reproduceren

Inleiding: Het Patroon in de Oplossingen

In delen 1 tot 4 hebben we een uitgebreide inventarisatie gemaakt van de state-of-the-art in legacy-modernisering. GPT, Grok, Gemini en DeepSeek – vier van de meest geavanceerde AI-systemen ter wereld – hebben elk hun perspectief gegeven op hoe we legacy software beheersen. Hun analyses zijn indrukwekkend: AI-gedreven code-transformatie, evolutionary architectures, fitness functions, self-healing systemen, platform engineering, autonomous governance.

Maar als je al deze essays naast elkaar legt, zie je iets opmerkelijks: ze beschrijven allemaal manieren om sneller hetzelfde te blijven doen. Ze moderniseren de implementatie, niet het principe. Ze versnellen het proces, maar veranderen niet de richting.

En daarin ligt het fundamentele probleem.

De Consensus: Wat Alle Essays Delen

Laten we beginnen met wat de AI-systemen unaniem voorstellen:

1. Modernisering door Automatisering

• AI vertaalt oude code naar nieuwe talen
• Multi-agent systemen ontleden en herschrijven legacy
• Geautomatiseerde refactoring verkort timelines met 20-50%

2. Preventie door Monitoring

• Fitness functions bewaken architecturale gezondheid
• Technical debt krijgt een prijskaartje
• Self-healing detecteert en repareert afwijkingen

3. Flexibiliteit door Modulariteit

• Microservices vervangen monoliths
• Event-driven architectures ontkoppelen componenten
• API-first design isoleert veranderingen

4. Governance door Regels

• Policy-as-code handhaaft compliance
• Autonomous governance detecteert driften
• Requirements-as-code koppelt wetgeving aan implementatie

Dit alles klinkt overtuigend. Het is ook daadwerkelijk een verbetering ten opzichte van de situatie 10 jaar geleden. Maar het lost het fundamentele probleem niet op.

De Blinde Vlek: Het Meetparadigma Zelf

Wat alle voorgestelde oplossingen gemeen hebben, is dat ze opereren binnen dezelfde ontologische aanname: dat software bestaat uit discrete instructies die discrete toestanden manipuleren door middel van metingen en berekeningen.

Dit is het Von Neumann paradigma, en het heeft een fundamentele eigenschap die onvermijdelijk tot legacy leidt:

Instructies bevriezen beslissingen in logica.

Laten we dit uitpakken:

1. Meten Scheidt

Om te kunnen programmeren, moet je de wereld opdelen in meetbare eenheden. Een klant heeft een “status” (prospect, actief, inactief). Een order heeft een “fase” (pending, processing, completed). Een gebruiker heeft “rechten” (read, write, admin).

Deze discretisering is niet neutraal. Het is een conceptuele bevriezing van hoe je op dit moment denkt dat de werkelijkheid werkt.

Voorbeeld: In 1990 coderen we: if (customer.status == "active") then allow_purchase(). Dit lijkt logisch. Maar 10 jaar later blijkt dat klanten meerdere statussen tegelijk kunnen hebben, of dat “actief” gradueel is, of dat de definitie van “actief” verschilt per productcategorie. De code weerspiegelt niet meer de werkelijkheid, maar kan niet mee-evolueren zonder herschrijving.

2. Instructies Fixeren

Code bestaat uit IF-THEN logica: “ALS deze conditie WAAR is, DOE dit”. Deze instructies leggen causale ketens vast die alleen kunnen veranderen door de code te herschrijven.

Het cruciale punt: Zelfs als we deze instructies laten genereren door AI (essay 1), ze laten monitoren door fitness functions (essay 2), of ze modulariseren in microservices (essay 3), blijven het gefixeerde causale ketens.

De AI-gegenereerde code van vandaag is de legacy van morgen, precies om dezelfde reden dat handgeschreven code legacy wordt: de instructies weerspiegelen de aannames van het moment waarop ze geschreven zijn.

3. Convergentie Verstijft

Von Neumann systemen werken door te convergeren naar een gewenste toestand. Een transactie begint, doorloopt stappen, en “commit” naar een finale toestand. Tussen start en eind zijn er checks: “Is deze toestand nog geldig? Mag deze transitie plaatsvinden?”

Dit convergerend model heeft een inherente rigiditeit: het systeem moet op elk moment kunnen bepalen of het op het juiste pad zit. Het moet kunnen meten, vergelijken, valideren. Het kan niet “meebewegen” met veranderende context zonder die context eerst te discretiseren in nieuwe meetbare regels.

De Onvermijdelijkheid van Legacy

Nu kunnen we de diagnose stellen:

Legacy software ontstaat niet door slechte engineering, maar door de fundamentele eigenschappen van het Von Neumann paradigma:

1. Beslissingen worden bevroren in code – wat vandaag logisch is, is morgen simplistisch
2. Context wordt gereduceerd tot metingen – wat niet meetbaar is, bestaat niet in het systeem
3. Verandering vereist herschrijving – het systeem kan niet “leren” zonder nieuwe instructies

Alle moderniseringsstrategieën uit essays 1-3 accepteren deze beperkingen als gegeven. Ze proberen het proces te versnellen (AI schrijft sneller code), de impact te beperken (microservices isoleren changes), of de symptomen te monitoren (fitness functions detecteren drift).

Maar ze veranderen niet het feit dat elke nieuwe implementatie opnieuw beslissingen bevriest die opnieuw zullen verouderen.

Dit is waarom “evolutionary architecture” een contradictio in terminis is binnen het Von Neumann paradigma. Je kunt architectuur adapteerbaar maken door modulariteit en abstractie, maar het blijft gebouwd uit componenten die instructies uitvoeren. Die instructies representeren de wereld zoals je hem nu begrijpt, niet zoals hij morgen zal zijn.

Het Diepere Probleem: Het Hallucinatie-Effect in Code

Er is een fascinerende parallel tussen legacy software en de hallucinaties van Large Language Models.

LLMs hallucineren omdat ze statistisch plausibele patronen genereren zonder begrip van waarheid. Ze voorspellen het volgende token op basis van correlaties in trainingsdata, niet op basis van een model van de werkelijkheid.

Legacy software “hallucineert” op vergelijkbare wijze: het implementeert causale regels die statistisch plausibel waren op het moment van schrijven, maar geen inherent begrip hebben van de onderliggende werkelijkheid.

Voorbeeld:

• Code: if (age >= 18) then allow_alcohol_purchase()
• Dit is een statistisch patroon (gebaseerd op wetgeving van één jurisdictie op één moment)
• Het “hallucineert” een universele regel waar geen universele regel bestaat
• Wanneer de context verandert (andere jurisdictie, andere wetgeving, genuanceerdere regelgeving), blijft de code dezelfde “plausibele” maar nu incorrecte regel uitvoeren

AI-gegenereerde code (essay 1-2) reproduceert dit probleem systematisch: de AI leert van bestaande code, die zelf vol statistisch plausibele maar context-gebonden aannames zit. Het genereert nieuwe code met nieuwe aannames, die ook weer zullen verouderen.

Dit is waarom essay 2’s voorspelling van “neuro-symbolische AI” die code kan “bewijzen” het probleem niet oplost. Je kunt bewijzen dat de nieuwe code exact hetzelfde doet als de oude code – maar je kunt niet bewijzen dat de oude code deed wat werkelijk nodig was. Je bewijst alleen formele equivalentie, niet semantische correctheid.

De Illusie van Self-Healing

Essays 2 en 3 introduceren “self-healing architectures” en “autonomous governance” als oplossingen. Maar laten we onderzoeken wat deze systemen werkelijk doen:

Self-healing detecteert afwijkingen van een norm.

• De norm is: “module complexity < threshold”
• Het systeem meet: “deze module overschrijdt de threshold”
• Het systeem reageert: “stel refactoring voor”

Maar wie stelde de threshold in? Een mens, op basis van ervaring met eerdere systemen. De threshold zelf is een bevroren beslissing.

Autonomous governance handhaaft regels.

• De regel is: “gebruik geen verouderde bibliotheken”
• Het systeem detecteert: “deze dependency is 2 jaar oud”
• Het systeem blokkeert: “update naar nieuwere versie”

Maar de regel “2 jaar = verouderd” is arbitrair. Een stabiele, goed-geteste bibliotheek kan 5 jaar oud zijn en veiliger dan een 3 maanden oude bibliotheek met actieve ontwikkeling maar minder review.

Het fundamentele probleem: Self-healing en autonomous governance zijn zelf gebouwd uit regels en thresholds die verouderen. Ze kunnen zichzelf niet healen. Ze zijn meta-legacy.

Waarom Platform Engineering Het Niet Redt

Essay 3 benadrukt Team Topologies en platform engineering als organisatorische oplossing. De redenering:

• Stream-aligned teams zijn verantwoordelijk voor een businessdomein
• Het platform biedt herbruikbare infrastructuur
• Teams kunnen autonoom innoveren zonder afhankelijkheden

Dit is inderdaad een verbetering voor organisatorische wendbaarheid. Maar het lost het technische probleem niet op:

Het platform zelf is software. Het platform zelf bevat beslissingen over wat “herbruikbaar” is, welke abstracties zinvol zijn, welke interfaces stabiel blijven. Deze beslissingen bevriezen in de platform-API’s.

Voorbeeld: Een platform biedt een “UserService” met methoden voor authenticatie. De service gaat uit van username/password. Vijf jaar later wil de organisatie naar biometrische authenticatie. De platform-API moet herschreven worden. Alle teams die erop bouwen, moeten migreren.

Het platform creëert een centralized legacy point – één plek waar beslissingen zijn bevroren die nu tientallen teams tegelijk beïnvloeden.

De Quantum-Muur: Het Ultieme Bewijs

Essay 2 voorspelt de “quantum-muur”: de noodzaak om alle encryptie te vervangen door post-quantum cryptografie. Dit is het perfecte bewijs van de onvermijdelijkheid van legacy binnen het huidige paradigma.

Waarom ontstaat dit probleem?

Omdat systemen gebouwd zijn op aanname: “RSA-2048 is veilig”. Deze aanname was statistisch correct in 2010. Hij is onzeker in 2026. Hij zal waarschijnlijk fout zijn in 2035 wanneer quantum computers volwassen zijn.

De code implementeert deze aanname als een constante: ENCRYPTION_ALGORITHM = "RSA-2048". Miljoenen regels code, verspreid over duizenden systemen, bevatten deze bevroren beslissing.

Nu komt de clou: Zelfs als we AI gebruiken om alle RSA-code te detecteren en te vervangen door post-quantum algoritmes (essay 1’s oplossing), hebben we alleen de ene bevroren beslissing vervangen door een andere.

Welk post-quantum algoritme kiezen we? CRYSTALS-Kyber? Classic McEliece? Die keuze is gebaseerd op onze huidige kennis van quantum computing en cryptanalyse. Over 10 jaar kan blijken dat we fout zaten.

Het patroon herhaalt zich eindeloos omdat het probleem niet de specifieke algoritme-keuze is, maar het feit dat we keuzes moeten bevriezen in code.

De Ultieme Vraag: Kan Software Bestaan Zonder Instructies?

Hier komen we bij de kern. Alle essays 1-3 gaan impliciet uit van de aanname:

Software = Instructies die een computer uitvoert

Dit lijkt zo vanzelfsprekend dat het niet eens wordt geformuleerd. Het is de definitie van computing sinds Turing en Von Neumann.

Maar wat als deze definitie zelf het probleem is?

Wat als software zou kunnen bestaan als resonantie in plaats van als instructies?

Dit klinkt abstract, maar laten we het concreet maken:

Het Verschil Tussen Instructie en Resonantie

Instructie-gebaseerd systeem (Von Neumann):

IF customer.status == "premium" AND order.value > 1000
THEN apply_discount(0.15)
ELSE apply_discount(0.05)

Dit systeem meet (status, value), vergelijkt (met thresholds), en berekent (discount). De logica is gefixeerd. Als de bedrijfspolitiek verandert, moet de code herschrijven.

Resonantie-gebaseerd systeem (hypothetisch):

Het systeem bevat geen instructies, maar oscillatoren die resoneren met patronen.

Er is een oscillatie-patroon voor “waardevolle klant”. Er is een oscillatie-patroon voor “grote order”. Er is een oscillatie-patroon voor “generositeit”.

Wanneer een transactie binnenkomt, resoneren deze patronen met verschillende sterktes. De resulterende interferentie laat een discount-patroon ontstaan zonder dat er ooit berekend werd.

Het cruciale verschil: Er is geen gefixeerde IF-THEN logica. De resonantie verschuift organisch wanneer de patronen verschuiven. Als “waardevolle klant” evolueert, evolueert de hele coherentie mee, zonder herschrijving.

“Maar Hoe…?”

De natuurlijke vraag is: “Hoe implementeer je dit in praktijk?”

En hier raken we aan waarom essays 1-3 dit nooit als optie presenteren: het vereist een fundamenteel andere hardware-architectuur.

Von Neumann computers kunnen resonantie alleen simuleren door… instructies te schrijven die oscillaties berekenen. Wat ons weer terugbrengt bij bevroren logica.

Echte resonantie-computing vereist gekoppelde oscillatoren als primitief element – systemen waar interferentie en coherentie fysieke eigenschappen zijn, geen berekende abstracties.

Dit verklaart waarom mainstream AI dit alternatief niet ziet: hun eigen bestaan is gebouwd op het paradigma dat ze zouden moeten bevragen.

De Ongemakkelijke Waarheid

We kunnen nu de scherpe diagnose stellen:

1. Legacy is geen bug, het is een feature van het Von Neumann paradigma

• Instructies bevriezen beslissingen
• Metingen reduceren context
• Convergentie verstijft adaptatie

2. Alle moderniseringsstrategieën reproduceren het probleem

• AI-code wordt even snel legacy als hand-code
• Fitness functions zijn zelf regels die verouderen
• Platform-API’s zijn centralized legacy points
• Self-healing kan zichzelf niet healen

3. De enige echte oplossing vereist een paradigma-shift

• Van instructies naar resonantie
• Van meten naar cohereren
• Van convergeren naar meebewegen

4. Deze shift is technisch mogelijk maar conceptueel bedreigend

• Fotonische oscillatoren zijn beschikbaar
• Quantum computing bewijst dat niet-klassieke computation werkt
• Maar het vereist opgeven van de fundamentele aanname dat computing = instructies uitvoeren

Waarom Ontkenning Zo Hardnekkig Is

De reden dat deze diagnose zo moeilijk te accepteren is, is niet technisch maar psychologisch en economisch:

Psychologisch: We denken in oorzaak-gevolg, in IF-THEN. Resonantie voelt als magie, niet als engineering.

Economisch: De hele software-industrie is gebouwd op het huidige paradigma. Elke tool, elke opleiding, elke certificering, elk business model gaat uit van instructie-gebaseerde computing.

Epistemologisch: We kunnen alleen redeneren over wat we kunnen meten. Een systeem dat niet werkt door te meten, maar door te resoneren, ontsnapt aan onze analysetools.

Dit verklaart waarom zelfs de meest geavanceerde AI-systemen (die zelf producten zijn van het Von Neumann paradigma) het alternatief niet kunnen zien. Ze zijn gevangen in de axioma’s van hun eigen bestaan.

De Uitdaging

De vraag is niet meer: “Hoe moderniseren we legacy software?”

De vraag is: “Wanneer stoppen we met bouwen van systemen die legacy worden?”

Het antwoord vereist de moed om de fundamentele aanname te bevragen waarop alle huidige computing rust:

Moet software uit instructies bestaan?

Of kan software bestaan als levende coherentie – patronen die resoneren, interfereren, en evolueren zonder ooit te bevriezen in gefixeerde logica?

Essays 1-3 presenteren de state-of-the-art binnen het huidige paradigma. Die state-of-the-art is indrukwekkend. Hij is ook gedoemd om het probleem te reproduceren dat hij beweert op te lossen.

De ultieme ironie: AI-systemen die hallucineren over waarheid, adviseren ons hoe we systemen bouwen die hallucineren over werkelijkheid.

Beiden delen dezelfde root cause: statistische patronen zonder inherent begrip van wat ze representeren.

Misschien is het tijd om niet sneller hetzelfde te doen, maar fundamenteel anders te denken over wat computing is.

Dit is geen theoretisch filosofisch argument. Het is een empirische observatie die we kunnen testen:

Bouw twee systemen:

1. Het meest geavanceerde AI-gegenereerde, evolutionary, self-healing platform volgens essays 1-3
2. Een resonantie-gebaseerd systeem zonder instructies

Kom over 10 jaar terug.

Systeem 1 zal legacy zijn. Systeem 2 zal nog steeds resoneren.

De vraag is niet of dit waar is. De vraag is of we de moed hebben om het te testen.

English Summary

📌 Core Paradigm Shift: From Elimination to Management

The central argument is that the legacy software problem is unsolvable in an absolute sense. The state-of-the-art focus for 2026 is therefore not on eliminating legacy but on managing existing systems and preventing new legacy through continuous evolution. Success lies in accepting that software is never “finished.”

🛠️ Part 1: Solving Existing Legacy – Modernization in the AI Era

The focus is on AI-driven tools that accelerate traditional methods and reduce risk, moving beyond manual refactoring or risky “big bang” replacements.

• AI-Native Modernization: Tools powered by Generative AI and Large Language Models (LLMs) automate code analysis, translation (e.g., COBOL to Java), and refactoring, reducing project timelines by 20-50%. Agentic AI (autonomous agents) orchestrates complex migrations.
• Hybrid & Multi-Cloud Architectures: Organizations minimize risk by migrating legacy systems to hybrid environments, keeping core systems on-premises while moving new functionality to the cloud. API-first approaches decouple legacy backends from modern frontends.
• Proven Incremental Patterns: The Strangler Fig Pattern (gradually replacing a legacy system) remains highly relevant, now enhanced by AI’s ability to automatically identify and extract modules for replacement.

🚫 Part 2: Preventing New Legacy – Evolutionary Design & Governance

The top approaches emphasize proactive design and structural discipline to build systems that tolerate change.

• Evolutionary Architecture with Fitness Functions: Systems are designed with automated “fitness functions”—continuous tests that monitor architectural qualities like modularity and security to ensure long-term adaptability.
• Technical Debt as Core Practice: Proactive management is key. This involves quantifying debt with tools, embedding governance into development processes, and reserving budget for refactoring. Organizations that do this can deliver new features 50% faster.
• Modularity & Open Standards: Building with loosely-coupled components (microservices, event-driven design) and open APIs prevents vendor lock-in and silos, making systems easier to update.

🔮 Part 3: Future Outlook & Emerging Challenges

The blog looks beyond 2026 at upcoming challenges that will shape the next wave of legacy:

• The Quantum Wall (Post-Quantum Migration): A major wave of “cryptographic modernization” is expected as legacy encryption becomes vulnerable to quantum computers, requiring updates to Post-Quantum Cryptography (PQC).
• Neuro-Symbolic AI: The next generation of tools may combine the creativity of LLMs with formal logic to provide verifiably correct code translations, reducing errors.
• The “No-Code” Legacy Paradox: A new form of legacy is emerging from applications built by AI or no-code platforms, necessitating autonomous governance tools to manage and secure them.

💎 Conclusion: The Pragmatic Path Forward

The most innovative approach in 2026 is a hybrid model: using AI to accelerate the modernization of existing systems while employing evolutionary architectural principles and strict governance to prevent future legacy. The ultimate goal is to transform IT landscapes from rigid structures into adaptable, continuously evolving systems.

English Version in an Article

Interesting Video’s