Comprehension Debt

Wat is Comprehension Debt?

Comprehension debt is de opgestapelde hoeveelheid code in een productiesysteem die niemand in het team oprecht begrijpt, ontstaan wanneer AI-gegenereerde wijzigingen uitgeleverd worden zonder echte review. De code werkt en de tests slagen, maar de kennis die normaal in een menselijk hoofd vormt door de code te schrijven, vormde zich nergens, en de kloof stapelt zich op met elke ongecontroleerde merge.

De belangrijkste punten

• Elke ongereviewde AI-merge is een lening. De feature levert vandaag uit; het begrip nodig om te debuggen, uit te breiden, of te beveiligen wordt uitgesteld tot wie het later nodig heeft, tegen incident-tijd-rentetarieven.
• Dit is een andere aansprakelijkheid dan technical debt. Technical debt is slechte code die je begrijpt; comprehension debt kan uitstekende code zijn die geen levend mens kan uitleggen.
• Het is onzichtbaar op elk dashboard. Velocity, dekking, en defectpercentages zien er allemaal gezond uit tot precies het eerste incident binnen de ongelezen code.
• De schuld is vermijdbaar op precies één punt: de reviewpoort. Zodra duizenden ongelezen regels in productie staan, zijn alle terugbetalingsopties duur.

Hoe het werkt

Voor coding-agents waren software schrijven en het begrijpen ervan dezelfde handeling. Je kon geen werkende betalingsflow produceren zonder er een mentaal model van te bouwen, dus liet elke uitgeleverde feature een persoon achter die ervoor kon instaan. Die koppeling was nooit een proces dat iemand ontwierp; het was een gratis bijproduct van de code zelf typen, en daarom merkte niemand het op tot het verdween. Agents braken de koppeling. Een AI-coding-agent kan nu de werkende feature produceren terwijl het begrip nergens gegenereerd wordt, en of een mens het verwerft wordt een optionele, bewuste, overslaanbare stap.

Onder deadlinedruk wordt het overgeslagen, en elke overslag is rationeel in isolatie. De diff is lang, de tests zijn groen, de demo werkt, en achthonderd regels zorgvuldig lezen zou de middag kosten die het volgende ticket nodig heeft. Dus gebeurt de merge op vibes in plaats van review, met automation bias die de geruststelling levert dat output zo schoon waarschijnlijk prima is. De geruststelling is misplaatst: 66% van de developers noemde "AI-oplossingen die bijna goed zijn, maar niet helemaal" hun grootste frustratie in het Stack Overflow Developer Survey van 2025 [1]. De herwerking verschijnt ook in repositorydata. GitClears analyse van 153 miljoen gewijzigde regels projecteerde dat codechurn, regels teruggedraaid of bijgewerkt binnen twee weken na schrijven, in 2024 zou verdubbelen vergeleken met de pre-AI-baseline van 2021 [2]. Vermenigvuldig met een jaar sprints en de codebase ontwikkelt regio's die niemand ooit heeft gelezen: ze compileren, ze bedienen verkeer, en ze zijn terra incognita voor het team dat ze op het organogram bezit.

De rente vervalt op de slechtste momenten, want de schuld is precies een tekort aan het ding dat noodgevallen consumeren: begrip onder tijdsdruk. Een incident in comprehension-debted code betekent debuggen van een systeem waar niemand een mentaal model van heeft, vaak met de agent als enige beschikbare gids voor zijn eigen eerdere output. Dat werk is meetbaar moeilijker: 45,2% van de developers vertelde hetzelfde Stack Overflow-onderzoek van 2025 dat het debuggen van AI-gegenereerde code meer tijd kost dan het debuggen van hun eigen code [3]. Het uitbreiden ervan betekent code wijzigen wier invarianten ongedocumenteerd en onbekend zijn. Het auditeren voor beveiliging betekent bij nul beginnen. Teams voelen de schuld voordat ze hem kunnen benoemen, in de vorm van engineers die stilletjes bang zijn om hele mappen van hun eigen product aan te raken.

Voorbeeld

Een startup levert een door een agent gebouwde facturatie-reconciliatiedienst uit in een week: schone code, 90 procent dekking, werkte vijf maanden feilloos. Dan verandert een betalingsprovider de bezorgsemantiek van een webhook en begint reconciliatie stilletjes een subset van accounts dubbel te crediteren. In de dienst ontdekt het team dat niemand ooit daadwerkelijk de retry- en deduplicatielogica heeft gelezen. De tests coderen wat de agent bouwde, dus slagen ze terwijl het geld weglekt. De engineer genoteerd als code-eigenaar keurde de originele PR goed in vier minuten. Diagnose duurt drie dagen, het meeste ervan besteed aan het reverse-engineeren van hun eigen service, en de uiteindelijke fix is elf regels. De drie dagen waren de rentebetaling; de review van vier minuten was de lening.

Veelvoorkomende misvattingen

De verleidelijke aanname is dat comprehension debt prima is omdat de agent de code kan uitleggen wanneer nodig, begrip op aanvraag, dus waarom voorraad aanleggen in mensen? Dit verwart een samenvatting met een mentaal model. Een agent die code uitlegt op vraagmoment produceert een aannemelijke lezing van wat op de pagina staat, zonder geheugen van de redenering erachter en zonder betrouwbaar begrip van welke regel dragend is; vraag het tijdens een uitval en het vertelt terwijl de klok loopt, en je kunt de accurate vertelling niet onderscheiden van de zelfverzekerde gok zonder precies de kennis die je oversloeg te verwerven. Echt begrip is wat een persoon in staat stelt te zeggen "die fout is onmogelijk tenzij de wachtrij verkeerd geconfigureerd is" in tien seconden. Het bestaat alleen in hoofden, het vormt zich alleen via betrokken review of auteurschap, en er is geen just-in-time-vervanging wanneer omzet weglekt.

FAQ

Hoe verschilt comprehension debt van technical debt? Technical debt is een bekend compromis in de code: shortcuts die je koos en kunt opsommen. Comprehension debt is een tekort in het team: code die perfect goed geëngineerd kan zijn maar geen mens heeft die het begrijpt. Refactoren betaalt het ene af; alleen menselijk leren betaalt het andere af, en een team kan het ene hebben zonder het andere.

Hoe meet je het? Er bestaat geen schone metriek, maar nuttige proxy's wel: het aandeel gemergede regels dat substantiële review kreeg, hoeveel modules een eigenaar hebben die ze zonder AI-hulp kan uitleggen, en tijd-tot-diagnose bij incidenten in door agents geschreven gebieden. Een botte auditvraag werkt goed: noem voor elk kritiek pad de persoon die het om 3 uur 's nachts zou kunnen debuggen met de model-API down.

Hoe betalen teams het af? Prospectief, een harde regel dat niets mergt tot een genoemde mens het kan uitleggen, wat review nu moet betekenen. Retrospectief, begeleid lezen van de hoogst-risicoregio's: een engineer werkt door de code, ondervraagt hem, schrijft de invarianten op, en wordt de facto eigenaar in plaats van in naam. Duur, wat het argument is om de schuld nooit in de eerste plaats op te bouwen.

Bronnen

1. Stack Overflow Developer Survey. "66% van de developers zegt dat hun grootste frustratie AI-oplossingen zijn die bijna goed zijn, maar niet helemaal." https://survey.stackoverflow.co/2025/ai. Geraadpleegd augustus 2026.
2. GitClear. "Analyse van 153 miljoen gewijzigde regels projecteerde dat codechurn (regels teruggedraaid of bijgewerkt binnen twee weken) in 2024 zou verdubbelen versus de pre-AI-baseline van 2021." https://www.gitclear.com/coding_on_copilot_data_shows_ais_downward_pressure_on_code_quality. Geraadpleegd augustus 2026.
3. Stack Overflow Developer Survey. "45,2% van de developers rapporteert dat het debuggen van AI-gegenereerde code meer tijd kost dan het debuggen van hun eigen code." https://survey.stackoverflow.co/2025/ai. Geraadpleegd augustus 2026.