Cognitieve schuld: als je team de eigen AI-code niet meer begrijpt

Stel: op vrijdagmiddag faalt een betaalkoppeling. De logs wijzen naar een module die drie maanden geleden grotendeels door een AI-assistent is geschreven. De code is netjes, de tests waren groen, de review is goedgekeurd. Alleen kan niemand in het team uitleggen waarom de retry-logica zo in elkaar zit. Wat een fix van een uur had moeten zijn, wordt een middag reverse-engineeren van je eigen systeem.

Voor dat gat is sinds begin 2026 een naam in omloop: cognitieve schuld.

Wat is cognitieve schuld?

Cognitieve schuld is het groeiende verschil tussen hoe een systeem in elkaar zit en hoe goed het team begrijpt hoe en waarom het zo werkt. De software draait, maar niemand kan nog met zekerheid uitleggen waarom, of voorspellen wat een wijziging doet.

De term in deze betekenis komt van Margaret-Anne Storey, hoogleraar informatica aan de University of Victoria, die onderzoekt hoe ontwikkelaars complexe systemen begrijpen. In februari 2026 beschreef ze studententeams in een ondernemerschapsvak die met AI snel features opleverden. Rond week zeven of acht liep één team vast: kleine wijzigingen braken onverwacht iets anders. Het lag niet aan rommelige code, schreef ze, maar aan het feit dat niemand kon uitleggen waarom bepaalde ontwerpkeuzes waren gemaakt of hoe de onderdelen moesten samenwerken.

Het woord dook eerder al op, in een studie van het MIT Media Lab uit juni 2025 met de titel Your Brain on ChatGPT. Die ging over essays schrijven, niet over code. Deelnemers die ChatGPT gebruikten, lieten in EEG-metingen de zwakste verbindingen tussen hersengebieden zien, voelden zich het minst eigenaar van hun tekst en konden er minder goed uit citeren. Het mechanisme is hetzelfde: werk uitbesteden bespaart nu moeite, en de rekening komt later.

Waarom technische schuld de verkeerde vergelijking is

Technische schuld zit in de code: duplicatie, een tijdelijke hack, een abstractie die niet meer past. Die kun je zien. Linters, reviews en statische analyse wijzen haar aan. Storey vat het verschil zo samen: technische schuld zit in de code, cognitieve schuld zit in mensen.

Daardoor kan code met veel cognitieve schuld er perfect uitzien. AI levert vaak nette, consistente code op. Geen enkele tool slaat alarm, want technisch is er niets mis. Het probleem is dat niemand het ontwerp nog bezit.

De productiviteitsillusie

Ontwikkelen met AI voelt snel. Pull requests volgen elkaar op, de sprintcijfers zien er goed uit. Maar gevoel en meting lopen hier aantoonbaar uiteen. In een gerandomiseerde studie van onderzoeksorganisatie METR (begin 2025) schatten ervaren open-source-ontwikkelaars achteraf dat AI hen 20% sneller had gemaakt. Gemeten waren ze 19% trager.

Dat bewijst niet dat AI traag maakt. METR schreef in februari 2026 zelf dat een vervolgmeting lastig te interpreteren is, omdat veel ontwikkelaars niet meer zonder AI wilden werken. Wat de studie wel laat zien: je eigen gevoel van snelheid is een slechte meetlat. Cognitieve schuld maakt dat gevaarlijker, want de snelheid zie je meteen en de kosten pas bij het eerste serieuze incident.

Hoe merk je dat je team cognitieve schuld opbouwt?

Er bestaat geen meter voor. Wel zijn er signalen die logisch volgen uit de definitie:

• Incidenten duren langer. Niet omdat de bug moeilijker is, maar omdat eerst iemand moet uitzoeken wat de code eigenlijk doet. Je herstelduur (MTTR) loopt op terwijl de codekwaliteit op papier gelijk blijft.
• De plak-en-hoop-lus. De code faalt, de foutmelding gaat de AI in, de voorgestelde fix gaat erin, er verschijnt een nieuwe fout. Dat ligt niet aan de AI, maar aan het gebrek aan context om te zien of een fix de oorzaak raakt of alleen het symptoom.
• Kleine wijzigingen, grote bijwerkingen. Precies wat Storey's team rond week zeven meemaakte. Op een gegeven moment voelt herschrijven als de enige uitweg.
• "Vraag het maar aan de AI" als standaardantwoord op vragen over je eigen systeem.

Waarom juniors het meeste risico lopen

Programmeren leer je door te worstelen: een stacktrace lezen, een executiepad volgen, zelf de bug vinden. Neemt AI die stappen over, dan leer je minder dan je denkt.

Daar is inmiddels onderzoek naar. Anthropic liet in januari 2026 in een gerandomiseerde studie 52 overwegend junior ontwikkelaars een voor hen onbekende Python-bibliotheek (Trio) leren, met en zonder AI-hulp. Direct daarna scoorde de AI-groep gemiddeld 50% op een begripstoets, de groep zonder AI 67%. De AI-groep was zo'n twee minuten sneller klaar, een verschil dat statistisch niet significant was. Het grootste gat zat bij de debugvragen: precies de vaardigheid die je nodig hebt als er iets stukgaat.

Het interessantste zit in de details. Wie AI alles liet doen, scoorde het laagst. Wie AI vooral conceptuele vragen stelde, of eerst code liet genereren en daarna om uitleg vroeg, scoorde goed. Hetzelfde gereedschap, en het gebruik bepaalde of er iets bleef hangen.

Je merkt het verschil op het moment dat er geen assistent naast je zit, bijvoorbeeld in een technisch sollicitatiegesprek waarin je een trade-off moet uitleggen of een architectuurkeuze moet verdedigen.

Hoe voorkom je cognitieve schuld?

AI weglaten is geen serieuze optie. De vraag is hoe je het gebruikt. Storey stelt onder meer voor dat minstens één teamlid elke AI-gegenereerde wijziging volledig begrijpt voordat die live gaat, dat je vastlegt waarom iets veranderde en niet alleen wat, en dat je in reviews en retrospectives bewust tijd neemt om het gedeelde begrip op peil te houden. Daarnaast drie concrete gewoontes.

Review alsof je een junior bent

Bij een gewone review vraag je: werkt het, en voldoet het aan onze standaarden? Bij AI-code komt daar een vraag bij: begrijp ik het? Drie toetsvragen voordat je iets accepteert:

1. Kan ik deze code aan een collega uitleggen?
2. Snap ik waarom voor deze opzet is gekozen, en niet voor een andere?
3. Zou ik dit om drie uur 's nachts kunnen debuggen zonder AI?

Eén keer "nee" betekent: nog niet klaar.

Neem een kwartier

Is een stuk gegenereerde code niet meteen duidelijk, neem dan bewust een kwartier om het te doorgronden. Dat is een vuistregel, geen gemeten optimum. Maar een kwartier nu is goedkoper dan een middag tijdens een incident. De regel eronder: als je het niet kunt uitleggen, ben je er geen eigenaar van.

Laat AI uitleggen, niet alleen bouwen

Vraag waarom een patroon is gekozen, welke edge cases er zijn, wat het kost aan performance en welke alternatieven er waren. Dat is het gebruik dat in de studie van Anthropic de hoogste scores opleverde.

Snelheid zonder begrip is geleende tijd. De teams die er over een paar jaar goed voor staan, zijn niet de teams die de meeste code genereren. Het zijn de teams die hun systeem nog altijd beter begrijpen dan het model dat het hielp schrijven.

Bronnen

• Margaret-Anne Storey: Cognitive Debt (9 februari 2026)
• Margaret-Anne Storey: What I'm Hearing About Cognitive Debt (So Far) (18 februari 2026)
• MIT Media Lab: Your Brain on ChatGPT (juni 2025)
• Anthropic: How AI assistance impacts the formation of coding skills (januari 2026)
• METR: Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity
• METR: We are Changing our Developer Productivity Experiment Design (februari 2026)