De Decoherentie-val: Wanneer AI-slop het signaal overstemt in een eindeloze zee van ruis

In andere woorden: het is wat er gebeurt wanneer 'slop' het signaal overstemt in een eindeloze zee van ruis.

Decoherentie groeit relatief aan de snelheid van verandering van een systeem, en neemt sneller toe naarmate een systeem al decoherent is, wat resulteert in een runaway-exponentiële groei. Dit is geen nieuw fenomeen; mensen hebben dit altijd bestreden door zorgvuldig manieren te vinden om meer te doen met minder, en door uiteenlopende patronen en modellen te verenigen tot een samenhangend geheel. De wijdverspreide inzet van AI produceert dit echter momenteel op een onhoudbaar tempo.

Het goede nieuws is dat dit het spookbeeld van een runaway-recursieve zelfverbetering uitsluit, de intelligentie-explosie die parabolisch stijgt voordat iemand kan reageren. Decoherentie voorkomt namelijk dat AI in een bubbel verbetert en beperkt de snelheid waarmee het daarbuiten kan verbeteren. Het slechte nieuws is dat we rechtstreeks afstevenen op een ander soort ramp: Decoherentie-instorting (Decoherence Collapse).

De analogie van de leidingen

Stel je een gebouw voor, bijvoorbeeld een kleine kantoortoren. Bij de bouw is een type leiding gebruikt dat na verloop van tijd degradeert en uiteindelijk vervangen moet worden. Dit is standaard infrastructurele schuld: normale slijtage.

Wanneer het tijd is om de leidingen te vervangen, moet je overstappen op een nieuwe standaard. Dit kan komen door nieuwe bouwvoorschriften, omdat de oude leidingen niet meer gemaakt worden, of omdat nieuwe leidingen simpelweg beter en makkelijker te onderhouden zijn. Dit is standaard technische vooruitgangsschuld: de noodzaak om te upgraden door de vooruitgang van de technologie.

Er is echter een derde vorm van schuld die ontstaat door hoe de overgang van oude naar nieuwe leidingen wordt aangepakt. Overweeg de volgende opties:

1. Het gebouw sluiten en alle leidingen in één keer vervangen. Dit is zeer disruptief en duur, omdat het gebouw onbruikbaar is en de kosten vooraf betaald moeten worden. Maar het proces is aan het einde voltooid.
2. Elke verdieping één voor één afsluiten en de leidingen daar vervangen. Dit is minder disruptief, maar duurder vanwege de extra arbeid om alles draaiende te houden terwijl het werk vordert.
3. Leidingen vervangen wanneer ze beginnen te falen. Dit is de minst disruptieve strategie; de kosten worden over tijd gespreid via kleine reparaties.

Voor velen is optie 3 het meest aantrekkelijk. Men kan het gebouw draaiende houden en de kosten spreiden. Men denkt: als we als het 'Schip van Theseus' [1] de leidingen één voor één kunnen vervangen, waarom zouden we dat dan niet doen?

Het antwoord is dat dit decoherentie creëert. En decoherentie is veruit de ergste vorm van technische schuld.

Evolutie en het Schip van Theseus

Het Schip van Theseus biedt een goed perspectief om de werkelijke omvang van decoherentie te begrijpen. We weten hoe we schepen van hout moeten bouwen, en we weten hoe we schepen van staal moeten bouwen. Je kunt een schip stuk voor stuk repareren met hetzelfde materiaal, waardoor het schip functioneel blijft met alle oorspronkelijke ontwerpen intact.

Maar weten we hoe we elke iteratie tussen hout en staal moeten bouwen? Zou je langzaam elk onderdeel van een linieschip kunnen vervangen en het incrementeel kunnen veranderen in een moderne torpedobootjager, waarbij het schip in elke stap van het proces functioneel blijft?

Het antwoord is niet per se "nee", maar het zou enorme vindingrijkheid, vakmanschap en aandacht voor detail vereisen. Bovendien zou je het proces echt willen voltooien, want een vaartuig dat half linieschip en half torpedobootjager is, zal waarschijnlijk niet erg effectief zijn in een modern gevecht.

In de bouw zien we dit regelmatig. Elke keer als een leiding breekt, wordt de loodgieter gebeld, worden muren opengebroken en wordt de reparatie handmatig aangepast aan die specifieke plek. Als de loodgieter geen gedetailleerde aantekeningen achterlaat, zal een volgende technicus jaren later die muur openen en zich afvragen: "Wat is hier in hemelsnaam aan de hand?"

Wanneer dit proces zich over de tijd herhaalt, ontstaat er een lappendeken van oude en nieuwe leidingen die complexer is dan elk van de twee systemen afzonderlijk. Elke koppeling en handmatige patch is een uniek bundeltje van krachten en eigenschappen die onvoldoende bestudeerd zijn, waardoor er een expert in beide systemen nodig is om het te begrijpen.

Dit lijkt prima zolang de leidingen werken. Maar wat gebeurt er als we een aanbouw willen maken?

Stel dat het water voor de aanbouw door het bestaande gebouw moet lopen en dat we de totale waterdruk in het systeem moeten verhogen. De vraag is nu: is het veilig om de druk te verhogen?

Als we alleen type A of alleen type B leidingen hadden, zou dit een eenvoudige berekening zijn. Maar bij een onbekende mix van beide systemen is veel meer analyse nodig. Elke patch kan het antwoord beïnvloeden, zelfs patches aan het andere uiteinde van het systeem, omdat alles met elkaar verbonden is.

Dit is waar de ware complexiteit van decoherentie duidelijk wordt. Wijzigingen aan decoherente systemen vereisen veel meer expertise dan werken met een enkel systeem. De engineer moet het systeem grondiger in kaart brengen, omdat wijzigingen onbedoelde gevolgen kunnen hebben.

Wanneer management druk uitoefent om sneller te werken, zal de expert niet de analyse versnellen, maar eerder eerder stoppen en iets doen waarvan hij "vrij zeker" is dat het werkt: een slordige koppeling, een ongebruikelijk onderdeel, of wat extra beveiligingen voor de zekerheid. Dit creëert een domino-effect: de kwaliteit daalt, het systeem wordt fragieler en complexer, waardoor de volgende wijziging nóg meer zorg vereist. Als de druk hetzelfde blijft, wordt het volgende werk nog slechter.

Het Doolhof

Het lastige aan software, vergeleken met een fysiek gebouw, is dat het onzichtbaar is. Programmeurs lopen dagelijks door de gangen van codebases. We navigeren het labyrint zo succesvol dat we bekend raken met elke bocht. Wanneer de wandelingen langer worden, met meer doodlopende wegen en valkuilen, voelen we dat intuïtief.

Maar dit is moeilijk uit te leggen aan mensen die het doolhof niet kunnen zien. Wanneer het tijd is om technische schuld op te ruimen, zijn voorstellen om het doolhof korter en minder kronkelig te maken moeilijk te verkopen aan het management.

Wanneer we meer dan twee systemen door elkaar mengen met talloze haphazard-patches, explodeert de complexiteit. Het wordt combinatorisch: je moet denken aan A → B, A → C, B → C, A → B → C, C → B → A, enzovoort.

Zelfs de beste engineers kunnen het labyrint uiteindelijk niet meer veilig navigeren. Ze kunnen het 80 of 90% van de tijd lukken, maar uiteindelijk maken ze een verkeerde afslag en raken ze gevangen in de immensiteit van een groei die elke stap voorblijft.

Dit is de Decoherentie-val. Het doolhof groeit totdat het je volledig opslokt en je in het donker achterlaat.

Simulatie

Menselijke ontwikkelaars worden moe, maar autonome agent-zwermen kunnen 24/7 doorgaan met het in kaart brengen van het doolhof. Zouden we het probleem niet simpelweg kunnen oplossen door er meer rekenkracht (compute) tegenaan te gooien?

Dat hangt af van de aard van de complexiteit:

• Groeit het lineair met de grootte van de codebase?
• Of groeit het exponentieel, waarbij elke wijziging de kans vergroot dat de volgende wijziging nog meer complexiteit toevoegt?

In mijn ervaring is het dat laatste. In een simulatie kunnen we dit visualiseren met een graaf waarbij:

• Nodes (Knooppunten): Componenten binnen het systeem.
• Node-grootte: De omvang van de component.
• Node-kleur: Het dominante paradigma (het "type" component, zoals materiaal van leidingen of constructies in code).
• Edges (Verbindingen): Connecties tussen componenten.

Een actor (ontwikkelaar) implementeert een feature door een deel van de graaf te bewandelen en te muteren. Het gedrag wordt bepaald door een coherentiefactor:

• Lage coherentie: De actor haast zich, neemt snelle beslissingen en kiest eenvoudige oplossingen zonder rekening te houden met de context, wat complexiteit toevoegt.
• Hoge coherentie: De actor neemt meer tijd en denkt dieper na, waardoor de kans groter is dat de wijziging minder complex is of zelfs complexiteit verwijdert.

In het begin beweegt de actor met lage coherentie veel sneller. Echter, naarmate de graaf verandert, vertraagt de voortgang door:

1. Hogere connectiegraad: De last van het moeten begrijpen van alle aangrenzende nodes.
2. Transities tussen kleuren: De overhead bij het wisselen tussen paradigma's.
3. Padlengte: De noodzaak om meer te lezen en te herzien om de context te begrijpen.

Dit resulteert in een "Sweet Spot" (het ideale punt). Boven dit punt werken we hard om alles coherent te houden; dit vertraagt de feature-ontwikkeling, maar produceert een systeem dat snel kan worden geïtereerd. Onder dit punt is de daling echter abrupt: de snelheid keldert naarmate de codebase exponentieel complexer wordt.

De rol van AI-agenten

Kunnen AI-agenten deze systemen onderhouden en coherentie bewaren? Of introduceren ze, zelfs in kleine mate, decoherentie? Decoherentie groeit namelijk niet over tijd, maar door verandering. Als je een decoherent systeem tien jaar niet aanraakt, blijft het precies even decoherent.

De meeste bedrijven opereren ver onder de Sweet Spot in een cyclus van:

1. Decoherentie groeit totdat features niet meer binnen redelijke tijd voltooid kunnen worden.
2. Er wordt een grote inspanning geleverd om de decoherentie te verminderen.
3. Features worden weer op een acceptabel tempo opgeleverd.
4. De focus verschuift, en het systeem begint opnieuw te decohereren.

De vraag is of agenten significant beter zijn in dit proces dan de gemiddelde engineering-cultuur. Tot nu toe is daar geen bewijs voor. Sterker nog, vroege onderzoeken wijzen in de tegenovergestelde richting:

• Een Harvard-studie [4] onder 718 bedrijven wees uit dat coding agents de hoeveelheid geschreven code met 30% verhoogden, maar niet tot een meetbare toename van voltooid werk leidden. De extra code hoopte zich op in reviews; pull requests duurden 49% langer.
• Een Carnegie Mellon-studie [5] naar open-source projecten die Cursor gebruikten, zag een tijdelijke sprong in snelheid, gevolgd door een toename in code-complexiteit die uiteindelijk de oorzaak was van een vertraging.
• Een analyse van meer dan 300.000 AI-authored commits [6] vond dat ongeveer één op de elf commits kwaliteitsissues introduceerde.

Meer code, dezelfde hoeveelheid voltooid werk, en meer complexiteit bij elke wijziging.

Technologische progressie en automatisering

Een tegenargument is dat de eerste generatie agenten inferieur is, maar dat we processen kunnen bouwen in afwachting van betere agenten, vergelijkbaar met de Industriële Revolutie en textielmachines.

Maar er is een cruciaal verschil: textielmachines produceerden een eindproduct (textiel). In software is code echter niet het eindproduct, maar de machine die het product (de applicatie) produceert. Een accurate analogie zou zijn: een machine die textielmachines ontwerpt en autonoom itereert op de volgende generatie.

Dit is de droom van recursieve zelfverbetering en de technologische singulariteit [10].

De Singulariteit en de "Bubble"

Critici zoals Tom Reed spreken over de "Goodhart Singularity" [11], gebaseerd op de wet van Goodhart [12]: Wanneer een maatstaf een doel wordt, houdt het op een goede maatstaf te zijn.

Voorstanders van een Software Intelligence Explosion (SIE) [16] menen dat AI in isolatie (in een datacenter-bubbel) betere software kan maken door Reinforcement Learning (RL) [17] omgevingen te creëren. Voor spellen als Go of Schaken [18] werkt dit, omdat de regels de volledige wereld vormen en de overwinningen simpelweg meetbaar zijn.

Maar voor software is dit anders. Goede software wordt niet bepaald door snelheid of compactheid, maar door coherentie.

Software is een tool om een doel in de echte wereld te bereiken. Als we "beter" definiëren als snelheid of efficiëntie, eindigen we met software die klein en snel is, maar volledig decoherent. Code wordt namelijk snel door werk over te slaan via aannames over de rest van het systeem.

Goede software is aanpasbaar. Dit vereist coherentie. De enige manier om te testen of software coherenter is, is via feedback uit de echte wereld.

Neem als voorbeeld futures [22] in asynchrone programmering. Vóór futures was asynchrone code een decoherente chaos van callbacks. Het duurde decennia voordat de juiste API's werden gevonden die benarlijk werkten. Dit proces gebeurde niet in een bubbel, maar door ervaring met echte systemen.

Om softwarecoherentie te verbeteren zonder de bubbel te verlaten, heeft AI slechts twee opties:

1. Toepassen op alle bestaande software: Dit leidt tot overfitting. De AI optimaliseert voor wat we al kennen, maar kan niet voorzien hoe software moet evolueren voor problemen die nog niet bestaan.
2. Nieuwe software creëren: Zonder validatie in de echte wereld zal de AI onvermijdelijk afdrijven van de realiteit.

Conclusie: we kunnen een AI maken die snellere, efficiëntere software produceert boven het menselijke plafond, maar we kunnen geen AI maken die softwarecoherentie verbetert zonder de bubbel te verlaten.

Wiskunde en Realiteit

Wiskunde zou in theorie in een bubbel kunnen worden verbeterd via geverifieerde bewijzen. Echter, wiskunde is vaak arbitrair totdat het nuttig blijkt in de praktijk.

Boolean algebra [24] was bijna een eeuw lang een esoterische nieuwsgierigheid. Pas in 1937 maakte Claude Shannon [25, 26] de connectie met elektrische schakelingen. Shannon kon dit vinden omdat hij in een kamer vol relais stond met een echt probleem. Een AI die miljarden lokaal valide maar globaal betekenisloze bewijzen sorteert, zou deze connectie waarschijnlijk missen.

Zoals 25 Fields-medaillewinnaars, waaronder Terence Tao [27], betogen: het massaal produceren van ware beweringen kan de grond waarop nieuwe, werkelijke ideeën groeien, uithollen.

Decoherentie-instorting

Het bouwen van coherentie is een langzaam, onverbiddelijk proces van het verkennen van de realiteit.

Ik maak me zorgen dat we, in onze haast om agent-forward te gaan (denk aan projecten zoals Omarchy [28, 29]), vergeten dat we samen een berg beklimmen. De kracht van de open-source gemeenschap was juist het proces van het bouwen van coherentie over verschillende systemen heen.

Ik vrees dat we een soort "slash-and-burn" landbouw toepassen: we gooien weg de coherentie die we hebben opgebouwd ten gunste van het herbouwen van elke dependency en het aanpassen van elk stuk software om kortetermijnproblemen op te lossen.

Als we te lang doorgaan zonder coherentie te onderhouden, komen we in een positie terecht waarin we agenten moeten gebruiken om onze systemen te onderhouden, omdat ze te groot zijn voor mensen. Maar als agenten ons niet uit de val kunnen trekken door echt herstelwerk te verrichten, zitten we vast in een model dat onze systemen langzaam degradeert, ongeacht hoeveel moeite we doen om ze te "fixen".

Dit is Decoherentie-instorting. Ik ben hier banger voor dan voor een runaway-superintelligentie, want het gebeurt nu, voor onze ogen.

AI heeft nut, maar ik volg de "reverse-centaur" analyse van Cory Doctorow [31]: we willen niet dat de machine ons bestuurt, we willen de machine besturen.

Decoherentie is een vorm van entropie die we altijd hebben moeten bestrijden. Twee laatste gedachten:

1. Decoherentie verandert alleen wanneer systemen veranderen. We kunnen altijd stoppen met vooruit stormen en onszelf uit de val trekken.
2. We hebben al processen die coherentie verbeteren. Het open-source proces is hierin uitzonderlijk succesvol geweest.

***

Bronverwijzingen

[1] Ship of Theseus. Wikipedia. [2] Being picky with the plumbing work in my new house. r/Plumbing, Reddit. [3] Space-based data center. Wikipedia. [4] Fiona Chen and James Stratton. Artificial Intelligence in the Firm: Bottlenecks in Software Production. Working paper, Harvard University, August 4, 2026. [5] Hao He, Courtney Miller, Shyam Agarwal, Christian Kästner, and Bogdan Vasilescu. Speed at the Cost of Quality: How Cursor AI Increases Short-Term Velocity and Long-Term Complexity in Open-Source Projects. 23rd International Conference on Mining Software Repositories (MSR '26), 2026. [6] Yue Liu, Ratnadira Widyasari, Yanjie Zhao, Ivana Clairine Irsan, Junkai Chen, and David Lo. Debt Behind the AI Boom: A Large-Scale Empirical Study of AI-Generated Code in the Wild. arXiv:2603.28592, 2026. [7] Cory Doctorow. AI turns Amazon coders into Amazon warehouse workers. Pluralistic, May 27, 2025. [8] Clive Thompson. When Robots Take All of Our Jobs, Remember the Luddites. Smithsonian Magazine, January 2017. [9] Robert C. Allen. Engels' pause: Technical change, capital accumulation, and inequality in the British industrial revolution. Explorations in Economic History, 2009. [10] Technological singularity. Wikipedia. [11] Tom Reed. The Goodhart Singularity. Meagre Protestant History, May 7, 2026. [12] Goodhart's law. Wikipedia. [13] Tom Davidson. Forethought. [14] Tom Davidson. Data bottlenecks won't prevent an intelligence explosion (but they will slow it down). Forethought, September 8, 2026. [15] Daniel Kokotajlo and Eli Lifland. Takeoff Forecast. AI 2027, April 2025. [16] Daniel Eth and Tom Davidson. Will AI R&D Automation Cause a Software Intelligence Explosion?. Forethought, March 26, 2025. [17] Reinforcement learning. Wikipedia. [18] AlphaZero. Wikipedia. [19] AlphaStar (software). Wikipedia. [20] OpenAI Five. Wikipedia. [21] Vyacheslav Egorov. What's up with monomorphism?. mrale.ph, January 11, 2015. [22] Futures and promises. Wikipedia. [23] Melanie Bayley. Alice's adventures in algebra: Wonderland solved. New Scientist, December 16, 2009. [24] Boolean algebra. Wikipedia. [25] Jimmy Soni and Rob Goodman. A Mind at Play: How Claude Shannon Invented the Information Age. Simon & Schuster, 2017. [26] Claude E. Shannon. A Symbolic Analysis of Relay and Switching Circuits. Master's thesis, Massachusetts Institute of Technology, 1937. [27] Terence Tao and 24 other Fields Medalists. A Severe Misalignment of AI in Mathematics. What's new, September 11, 2026. [28] Omarchy. Wikipedia. [29] Bobby Borisov. Arch-Based Omarchy 4.0.4 Makes Its Custom Linux Kernel the Default. Linuxiac, September 16, 2026. [30] Unix wars. Wikipedia. [31] Cory Doctorow. The Reverse-Centaur's Guide to Criticizing AI. Pluralistic, December 5, 2025.