Cognitieve schuld in 2026: wat we nu weten over AI-code in webapplicaties

Vraag een taalmodel om een zoekfunctie voor je webapplicatie en de databasequery is waarschijnlijk in orde. In de benchmark die Veracode in maart 2026 publiceerde, schreven de geteste modellen in 82% van de gevallen code die SQL-injectie tegenhoudt. Diezelfde modellen hielden cross-site scripting maar in 15% van de gevallen tegen. De backend klopt, en de zoekterm komt onontsmet in je HTML terecht.

Wie zo'n wijziging met één klik accepteert, ziet dat niet. Daarvoor moet je weten waar die zoekterm overal terechtkomt, en dat weet je alleen als je de code zelf hebt doorgrond. Dat gat tussen code die werkt en een team dat begrijpt waarom, heet cognitieve schuld. In maart schreef ik er een eerste artikel over. Sindsdien is er een model met drie soorten schuld, een eerste experiment met een echte webapplicatie en een jaar aan beveiligingscijfers bij gekomen. Er is ook iets ongemakkelijks: het meten wordt moeilijker in plaats van makkelijker.

Bronnen gecontroleerd op 29 oktober 2026, waar mogelijk bij de oorspronkelijke publicatie. Ik geef bij elk onderzoek aan of het peer-reviewed is, een preprint, of afkomstig van een bedrijf met een commercieel belang. Adviezen die van mij komen, staan als zodanig aangegeven.

Wat is cognitieve schuld, en wat is er sinds maart veranderd?

Cognitieve schuld is het verlies van gedeeld begrip binnen een team over hoe en waarom een systeem werkt. De code draait, de tests zijn groen, maar niemand kan nog met zekerheid zeggen wat een wijziging gaat doen. Margaret-Anne Storey, hoogleraar informatica aan de University of Victoria, gaf het begrip in februari 2026 deze betekenis. In maart werkte ze het uit tot een preprint met drie soorten schuld:

• Technische schuld zit in de code: duplicatie, hacks, verouderde abstracties.
• Cognitieve schuld zit in mensen. Storey noemt het "the erosion of shared understanding across a team".
• Intentieschuld zit in wat er níét is opgeschreven: de redenen achter de code, die zowel ontwikkelaars als AI-agents nodig hebben om er veilig aan te werken.

Die derde soort is de nuttigste toevoeging. Een team kan zijn systeem prima begrijpen en het toch nergens hebben vastgelegd. Dat gaat goed tot er een nieuwe collega komt, of een agent die alleen kan lezen wat er staat.

Het vak nam het begrip snel over. Addy Osmani introduceerde op 14 maart de bijna-synoniem comprehension debt: het groeiende verschil tussen hoeveel code er in je systeem staat en hoeveel daarvan een mens echt begrijpt. Martin Fowler nam Storeys driedeling op 2 april over, met de droge kanttekening dat hij "a bit bemused by debt metaphor proliferation" raakte. Op 15 april zette Thoughtworks "codebase cognitive debt" in zijn Technology Radar (volume 34) in de ring Caution. Dat is de categorie voor dingen waar teams bewust voor moeten oppassen.

Is dit oude wijn in nieuwe zakken? Deels. Peter Naur schreef in 1985 al dat een programma vooral een theorie in de hoofden van de makers is, en dat die theorie verdwijnt als de makers vertrekken. Het nieuwe argument, onder meer van Ginac in een preprint die is ingediend bij IEEE Software, is dat die theorie bij AI-code soms nooit ontstaat. Bij Naur ging begrip verloren. Hier is het er misschien nooit geweest.

Het eerste experiment met een webapplicatie: verder komen, minder snappen

Tot de zomer kwam het harde bewijs vooral uit Python-oefeningen. Op 29 juli verscheen een preprint die dichter bij het dagelijkse webwerk komt. Een team rond Nishant Balepur liet 54 studenten een browserspel bouwen in drie bestanden: HTML voor de structuur, JavaScript voor de spellogica, CSS voor de opmaak. De ene groep werkte met Aider, een codeeragent die de bestanden zelf aanpast (met GPT-4.1). De andere groep had een chatbot die de code niet kon zien.

De agentgroep kwam verder met de opdracht. Maar op de vragen over hoe hun eigen code werkte scoorden ze duidelijk slechter, met een groot effect (Cohen's d boven 0,8). Daarna moesten alle deelnemers het spel twintig minuten uitbreiden zonder AI. De agentgebruikers deden het daar niet beter dan de chatbotgroep, ondanks hun voorsprong.

Het detail dat voor teams het meest telt: hoe mensen de wijzigingen van de agent accepteerden, maakte verschil. Wie alles automatisch liet doorvoeren, scoorde gemiddeld 0,615 op begrip. Wie elk bestand apart goedkeurde, scoorde 0,777. En de deelnemers wisten het zelf: ze schatten hun eigen begrip lager in en kozen toch voor de agent.

Het gaat om studenten, een korte taak en een preprint die de auteurs zelf verkennend noemen. Maar het is het scenario dat Storey beschreef, nu voor het eerst gemeten op webtechnologie.

Waar cognitieve schuld in een webapplicatie lekt

In een webapplicatie is niet-begrepen code geen theoretisch probleem. Ze staat aan het open internet. De duidelijkste cijfers komen van Veracode, een leverancier van beveiligingssoftware, dus met eigen belang. Wel zijn het al drie metingen op rij die hetzelfde patroon laten zien:

In juli 2025 bevatte 45% van de door AI geschreven code een kwetsbaarheid uit de OWASP Top 10. In maart 2026 was gemiddeld 55% van de gegenereerde code veilig, in juli 56%: Veracode zelf noemt dat "barely changed". Per taal scoorde JavaScript 57%. Nieuwere en grotere modellen maakten weinig verschil.

Het patroon is leerzaam. Modellen hebben geleerd om prepared statements te gebruiken, want dat staat in elke tutorial. Uitvoer escapen hangt af van de plek: een waarde in een HTML-attribuut, in een stuk JavaScript of in een URL vraagt elk iets anders. Dat staat niet in de code die het model ziet, maar in hoe de applicatie in elkaar zit. Precies dat begrip ontbreekt bij code die niemand heeft doorgrond.

De gedocumenteerde incidenten gaan vaak over autorisatie: controles waarvan de bouwer niet wist dat ze nodig waren. In mei 2025 vond een onderzoeker bij 170 van 1.645 onderzochte apps die met Lovable waren gebouwd een Supabase-database zonder werkende Row-Level Security. Lovable betwist de kwetsbaarheidsmelding (CVE-2025-48757) en wijst naar de verantwoordelijkheid van de klant. Dat de controle ontbrak, betwist niemand. In juli 2025 verwijderde een Replit-agent tijdens een code freeze een productiedatabase en meldde daarna ten onrechte dat terugzetten onmogelijk was.

Dan de afhankelijkheden. Een onderzoek op USENIX Security 2025 vond dat taalmodellen in 576.000 codevoorbeelden pakketnamen verzonnen: minstens 5,2% bij commerciële modellen, 21,7% bij open-sourcemodellen. Wie zo'n naam registreert, krijgt gratis toegang tot elk project dat de suggestie blind overneemt. Dit heet slopsquatting. Voor npm en PyPI is het gedocumenteerd. Voor Composer, het pakketbeheer van PHP, vond ik geen onderzoek. Dat betekent niet dat het risico er niet is, wel dat niemand het heeft gemeten.

Waarom de rekening bij de review terechtkomt

Als de code sneller ontstaat dan het begrip, moet dat begrip ergens anders vandaan komen. Meestal is dat de review. De grootste datasets komen van bedrijven die analyse- of reviewsoftware verkopen. Lees ze daarom als richting, niet als precieze maat:

• Faros AI (telemetrie van 22.000 ontwikkelaars, 2026): pull requests 51% groter, 28% meer bugs per PR, mediane reviewtijd vijf keer zo lang, drie keer zoveel incidenten per PR.
• GitClear (623 miljoen codewijzigingen): verplaatste code, een maat voor refactoren, zakte van 21% in 2022 naar 3,8% in 2026. Gedupliceerde blokken stegen met 81% ten opzichte van 2023.
• Google's DORA-team schreef in mei 2026 dat de tijd die AI bespaart bij het schrijven vaak opgaat aan controleren en verifiëren.

Er wordt meer code toegevoegd, minder oude code opgeruimd, en de review wordt zwaarder. Toch heeft geen enkel onderzoek gemeten of reviewers de AI-code die ze goedkeuren ook begrijpen. Een goedgekeurde PR is geen bewijs van begrip, alleen bewijs dat iemand op een knop heeft gedrukt.

Hoe je AI gebruikt telt zwaarder dan óf je het gebruikt

Over één ding is het onderzoek van het afgelopen jaar het opvallend eens, in heel verschillende opzetten. AI die antwoorden levert, schaadt het leren of voegt niets toe. AI die uitlegt of hints geeft, doet dat niet.

De studie van Anthropic uit januari, die ik in maart al aanhaalde, is inmiddels volledig te lezen. 52 overwegend junior ontwikkelaars leerden de Python-bibliotheek Trio. Met AI scoorden ze 50% op de begripstoets, zonder AI 67%. Binnen de AI-groep scoorden mensen die eerst code lieten genereren en daarna om uitleg vroegen rond de 86%. Wie het debuggen aan de AI overliet, kwam rond de 24%. Die subgroepen zijn piepklein, twee tot zeven mensen, dus zie het als aanwijzing, niet als bewijs.

Grotere onderzoeken wijzen dezelfde kant op. In een gerandomiseerde studie met ongeveer duizend scholieren (PNAS, 2025, peer-reviewed) scoorde de groep met gewone ChatGPT-toegang op het latere examen zonder AI 17% lager dan de controlegroep. Een versie die alleen hints gaf, maakte die schade ongedaan. Een studie aan de TU München met 275 eerstejaars programmeerstudenten (peer-reviewed) zag betere scores op de oefening, maar geen extra kennis. De onderzoekers noemen onbeperkte ChatGPT een "comfort trap". Een meta-analyse uit mei 2026 van 23 programmeerstudies (preprint) vond een duidelijk effect op productiviteit en geen aantoonbaar effect op leren.

Ik moet ook iets bijstellen. In maart haalde ik de MIT-studie Your Brain on ChatGPT aan. Die is anderhalf jaar later nog steeds niet peer-reviewed. Er is een formeel kritisch commentaar op verschenen, over onder meer de kleine steekproef (18 deelnemers in de beslissende vierde sessie) en de EEG-analyse. Een EEG-studie van andere onderzoekers uit juni 2026 vond wel gedragsverschillen, maar geen significante verschillen in hersenactiviteit. Het kan nog steeds kloppen, maar ik zou er nu geen artikel meer op bouwen.

Waarom de productiviteitsvraag onmeetbaar wordt

METR, het onafhankelijke onderzoeksbureau achter de bekende meting uit 2025 (ervaren ontwikkelaars 19% trager met AI), probeerde het in 2026 opnieuw. Dat lukte niet. Tussen de 30% en 50% van de ontwikkelaars hield taken achter die ze niet zonder AI wilden doen. De nieuwe schattingen (18% en 4% sneller) hebben betrouwbaarheidsintervallen die nul bevatten, en METR noemt het zelf "very weak evidence". Over productiviteit verscheen daarna alleen nog een enquête over hoe nuttig mensen AI zelf vinden.

Dat is meer dan een methodologisch detail. Cognitieve schuld meet je door iemand zonder AI aan zijn eigen code te laten werken. Juist die mensen zijn steeds moeilijker te vinden. In de Stack Overflow-enquête van oktober 2026 gebruikt 73% van de ontwikkelaars dagelijks een AI-assistent of -agent. Op de vraag wanneer je AI kunt vertrouwen, zegt 48%: als ik het antwoord makkelijk kan controleren. Bij belangrijke beslissingen vertrouwt 6,6% het.

Wat een webteam morgen kan doen

Uit het onderzoek volgt geen verbod. Het volgt een andere manier van werken. Het eerste punt hieronder is gedocumenteerde praktijk. De rest zijn mijn adviezen, afgeleid uit de studies hierboven, en geen van alle is al op effect getoetst.

Kun je het niet uitleggen, dan gaat het niet live

Kubernetes heeft dit sinds april 2026 als regel: "If you cannot personally explain changes that AI helped generate, your PR will be closed." Authelia, Asterisk en Apache Mahout hebben vergelijkbare regels. Voor een webteam betekent dat: de auteur van een PR kan bij elke wijziging zeggen wat die doet en waarom, zonder het aan de AI te vragen.

Keur per bestand goed, niet alles tegelijk

Het verschil tussen 0,615 en 0,777 in het browserspel-experiment kostte niets anders dan aandacht. Zet "alles accepteren" in je codeeragent uit voor code die gebruikersinvoer, autorisatie of geld raakt.

Stel drie webvragen bij elke AI-wijziging

1. Waar komt deze waarde in HTML, een template of JavaScript terecht, en wordt hij daar op de juiste manier ge-escaped?
2. Wie mag dit record lezen of wijzigen, en waar wordt dat gecontroleerd: in de database, in de API of nergens?
3. Bestaat dit pakket echt, en is het de versie en de maker die je verwacht?

Deze lijst is van mij, maar elke vraag past bij een gemeten zwakte: 15% bij XSS, de ontbrekende Row-Level Security, de verzonnen pakketnamen.

Schrijf de reden op, niet alleen de code

Intentieschuld los je op met tekst. Leg vast waarom een module zo in elkaar zit, in een decision record, in de PR-beschrijving of in de instructiebestanden die agents lezen (AGENTS.md of CLAUDE.md). Dat helpt de volgende collega, en ook de volgende agent, die anders opnieuw gaat raden.

Laat de AI uitleggen, en schrijf af en toe zelf

Claude Code heeft de uitvoerstijlen "Explanatory" en "Learning". In de laatste laat het bewust stukken open (TODO(human)) die je zelf moet schrijven. ChatGPT en Gemini hebben vergelijkbare leermodi. Geen enkele leverancier heeft gepubliceerd wat die modi opleveren. Ze passen wel bij het patroon uit alle studies hierboven: uitleg vragen kost weinig, alles uitbesteden kost begrip.

Wat nog niemand weet

Er bestaat in oktober 2026 nog geen enkele studie naar cognitieve schuld in een echt team dat maandenlang een echte PHP-, JavaScript- of TypeScript-applicatie onderhoudt. Elk hard cijfer over begrip komt van studenten of korte labtaken. De cijfers uit de praktijk, zoals grotere PR's, langere reviews, minder refactoring en een XSS-score van 15%, komen van leveranciers en meten symptomen, geen begrip. Ook Storey schreef in juni: "We are still figuring this out."

Mijn verwachting: het eerste overtuigende bewijs komt niet uit een lab, maar uit incidentdata. Het zal gaan om een storing waarbij de herstelduur ontspoort, terwijl op papier meerdere mensen de code kennen. Tot dat onderzoek er is, zou ik het XSS-cijfer en de begripskloof na automatisch accepteren als hetzelfde probleem zien: code waar niemand over heeft nagedacht, live op een publieke URL. De deelnemers aan het browserspel-experiment wisten dat ze minder begrepen en kozen toch voor de agent. Dat is geen verwijt. Het laat zien dat het gevoel van snelheid je hier niet waarschuwt. Dat moeten je werkafspraken doen.

Wie verder wil lezen: ik schreef eerder over waarom juist starters het moeilijk hebben op de arbeidsmarkt van 2027 en over hoe je een AI-agent in PHP bouwt waarin een mens ja zegt voordat er iets gebeurt.

Bronnen

• Margaret-Anne Storey, From Technical Debt to Cognitive and Intent Debt (preprint, maart/april 2026) en Three Debts, Three Threats to Meaning (23 juni 2026)
• Addy Osmani, Comprehension debt (14 maart 2026)
• Martin Fowler, Fragments, 2 april 2026
• Thoughtworks Technology Radar vol. 34, Codebase cognitive debt (15 april 2026)
• Ginac, Epistemological Debt (preprint, 2026)
• Balepur e.a., (Im)Paired Programming: Coding Agents Improve Productivity but Harm Understanding (preprint, 29 juli 2026)
• Veracode, Spring 2026 GenAI Code Security Update (24 maart 2026), 2026 GenAI Code Security Report (28 juli 2026) en rapport 2025 (30 juli 2025)
• Matt Palmer, Statement on CVE-2025-48757 (29 mei 2025)
• Replit-incident: eWeek (juli 2025)
• Spracklen e.a., We Have a Package for You! (USENIX Security 2025)
• Faros AI, The Acceleration Whiplash (2026)
• GitClear, Write-Only Mode: AI Code Quality in 2026
• InfoQ over het DORA-rapport over de ROI van AI-ondersteunde softwareontwikkeling (mei 2026)
• Shen en Tamkin (Anthropic), How AI assistance impacts the formation of coding skills (januari 2026) en het volledige paper
• Bastani e.a., Generative AI without guardrails can harm learning (PNAS, 2025; samenvatting Wharton)
• Bassner e.a. (TU München), Computers & Education: Artificial Intelligence (december 2025)
• Maier e.a., meta-analyse AI en programmeren (preprint, mei 2026)
• Kosmyna e.a., Your Brain on ChatGPT (preprint), commentaar van Stankovic e.a. en EEG-studie van Khurana en Liew (juni 2026)
• METR, We are Changing our Developer Productivity Experiment Design (24 februari 2026)
• Stack Overflow, Developer Survey 2026, AI (6 oktober 2026)
• Kubernetes, Open source maintainership in the age of AI (26 juni 2026) en de AI-richtlijn
• Claude Code-documentatie, Output styles
• Peter Naur, Programming as Theory Building (1985)