# Technische schuld AI: twee verschillende problemen

URL: https://codebasechat.com/nl/journal/technische-schuld-ai-twee-problemen
Type: blog
Locale: nl
Published: 2026-07-14
Updated: 2026-07-14

---

> Technische schuld door AI splitst zich in twee: code schuld (wat linters vangen) en cognitieve schuld (wat teams vergeten). Juniors betalen deze schuld het snelste.

Technische schuld AI is niet wat je denkt: niet alleen de rommel die een linter aanwijst. De ene helft ziet er perfect uit in de pull request, haalt review, en duikt zes weken later op als niemand kan uitleggen waarom een verandering op plek A drie onverwachte dingen ergens anders brak. Die tweede helft is waar de meeste teams niets mee meten.

## Technische schuld door AI is twee verschillende problemen, niet één

Vraag vijf engineering managers naar hun definitie van technische schuld door AI en je krijgt vijf antwoorden. Maar ze clusteren in twee heel verschillende bakken.

De eerste is code schuld: duplicatie, inconsistente patronen, code die technisch correct is maar ongewenst bereik toevoegt. Dit is waar statische analysegereedschappen voor gebouwd zijn.

De tweede is cognitieve schuld: de kloof tussen hoe snel code gegenereerd wordt en hoe snel het team daadwerkelijk een gedeeld mentaal model bouwt van wat het doet. Sonars 2026 developer survey toont aan dat 88% van ontwikkelaars minstens één negatief effect van AI op technische schuld ervaart, en 53% zeggen dat AI code genereert die correct lijkt maar verborgen gebreken verbergt. Dat is code schuld. Wat de survey niet volledig vangt, is het tweede soort. [LeadDev's rapportage erover](https://leaddev.com/ai/ai-coding-creates-two-kinds-of-debt-youre-only-measuring-one) is wat wij als de scherpste behandeling hebben gelezen.

Drie teams van de vijf vermengen de twee. Dit is wat de andere twee anders doen: zij monitoren code schuld met tooling, en zij monitoren cognitieve schuld via gesprekken.

## Code schuld: code die er goed uit ziet maar verkeerd is

Code schuld is de bekende soort. AI-gegenereerde code dupliceert logica die al drie bestanden verder bestaat, omdat de assistent niet weet dat die logica daar is tenzij hij in context zit. Sonars survey geeft er een getal op: 40% van ontwikkelaars zegt dat AI de schuld heeft verhoogd door overbodige of duplicatieve code te genereren.

De gevaarlijke variant is niet de code die er verkeerd uitziet. Het is de code die er juist uitziet. Een functie slaagt voor zijn tests, handelt het happy path netjes af, en leest als iets wat een senior engineer zou schrijven, behalve dat hij stilletjes een edge case wegvalt die de originele implementatie afdekte. Review vangt typo's. Review is veel slechter in het herkennen van een plausibel ogende functie die subtiel incompleet is.

`// AI-gegenereerd: slaagt tests, ziet er schoon uit
function getActiveUsers(users) {
  return users.filter(u => u.status === "active");
}

// Wat het origineel afdekte, drie bestanden verderop:
function getActiveUsers(users) {
  return users.filter(u => u.status === "active" && !u.deletedAt);
}`Niets hier gooit een error. Niets faalt CI. De kloof verschijnt pas als een soft-verwijderde gebruiker drie weken later in een rapport opnieuw verschijnt, en wie opgebeld wordt moet grepppen, blame controleren, en rond vragen om te ontdekken welke versie correct is en waarom. Die grep-en-vraag-lus is de werkelijke kost, en deze is meetbaar in uren, niet in een vaag gevoel dat iets voelt alsof het mis gaat.

Docs-as-code gereedschappen die naast de repo zitten in plaats van in een aparte wiki verminderen hoe vaak die lus zich voordoet, omdat de redenering achter een functie één klik van de functie zelf verwijderd is in plaats van in iemands geheugen.

![Close-up van handen op een toetsenbord met een rood-en-groen code diff zichtbaar op het vervagen scherm erachter](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/codebasechat/2026-07/eaeaef-inline1.webp)

## Cognitieve schuld: wanneer het team het plot kwijtraakt

Dr. Margaret-Anne Storey, professor informatica aan de Universiteit van Victoria, muntte "cognitieve schuld" uit in oktober 2025 na te zien dat haar studenten snel schepen met AI en dan moeite hadden om op hun eigen feedback in te gaan. Haar diagnose: de studenten waren de code niet kwijtgeraakt, ze waren kwijtgeraakt waar zij aan bouwden en waarom, en wie op het team wat wist.

Dat raamwerk leent van Peter Naurs oude betoog dat software niet echt de code is, het is de gedeelde theorie in de hoofden van de mensen die het bouwden. Wanneer code sneller gegenereerd wordt dan het team die theorie kan opbouwen, vormt de theorie zich nooit. Je kunt een schone, volledig geteste codebase hebben en toch significante cognitieve schuld hebben als de mensen die het hebben gemerged het niet volledig kunnen uitleggen, of als slechts één persoon het kan.

Dit is het deel dat standaard AI technische schuld metrics helemaal missen, omdat dashboards de code monitoren, niet het begrip. De vraag die waard is om in je volgende retro te stellen is bot: zet een architectuurdiagram omhoog en vraag wie op het team elke box kan uitleggen. Als het antwoord is "één persoon, en die is volgende week met vakantie," hebt je cognitieve schuld ongeacht wat je linter zegt.

Een levende interne wiki lost cognitieve schuld niet zelf op. Het geeft het team een plaats om het "waarom" op te schrijven voordat het alleen in iemands hoofd leeft, wat een begin is.

![Drie engineers staan aan een whiteboard en schetsen samen een systeemarchitectuur diagram](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/codebasechat/2026-07/e90110-inline2.webp)

## Waarom code review niet meekant met generatiesnelheid

Hier is het mechanische probleem onder beide soorten schuld: AI laat één engineer een week code genereren voor het middageten, maar review capaciteit is niet meegerekend. De knelpunt verplaatste zich van schrijven naar lezen, en lezen is het deel dat niemand versneld heeft.

Dit is waar de tool vergelijking eigenlijk belangrijk wordt, en het waard is om specifiek te zijn in plaats van vaag. Copilot en Cursor zijn snel in het genereren van code in het bestand dat u al open hebt, wat precies waarom zij goed zijn in het produceren van meer code dan een team kan reviewen. Cody en Continue.dev leunen meer op retrieval over de repo voordat zij genereren, wat helpt de duplicatie-issue hierboven te vermijden, maar geen van hen vervangt de menselijke stap van beslissen of nieuwe code aansluit hoe het systeem werkt. Geen van hen vertelt je of de persoon die de PR merged werkelijk begrijpt wat veranderd is, dat is een ander vraag dan of de diff syntactisch goed is.

Vraag-je-codebase tools bestaan vanwege deze kloof specifiek: de snelste manier om AI-gegenereerde code goed te reviewen is om in gewone taal te kunnen vragen, "waar anders bestaat dit patroon," of "wat handelt al dit geval af," voordat je de merge goedkeurt. Die vraag kostte een senior engineer vroeger twintig minuten grepppen en blame. Dat zou niet moeten.

Er is ook een repo-grootte-effect waard om te noemen. Op een service van 5.000 regels kan één reviewer het meeste van het systeem in zijn hoofd houden, dus een plausibele functie springt eruit omdat het niet aansluit het mentale model van de reviewer. Op een monorepo van 80.000 regels aangeraakt door zes teams, houdt geen enkele reviewer meer dat mentale model, dus plausibele code zeilt erdoor simpelweg omdat niemand in de kamer de context heeft om op te merken dat het verkeerd is. Hoe groter de repo, hoe meer de review knelpunt vertrouwt op tooling in plaats van één senior engineer geheugen.

## Juniors betalen deze schuld het eerst en het snelst

Antropic voerde in januari 2026 een gecontroleerde studie uit, een gerandomiseerde proef met 52 junior developers, en vond dat zij die AI assistants gebruikten 17% lager scoorden op code comprehension tests, ruwweg twee lettergrades. Infobips interne engineering team, sinds 2022 een stagiaire-programma draaiend over 225 stagiaires, zag hetzelfde patroon in echt longitudinaal data: pre-AI cohorten groeide gemiddeld 2,50 punten in zelf-ingeschat technisch vaardigheden over een stagiaire; AI-era cohorten groeiden 1,56.

Het mechanisme is niet AI-gebruik zelf. Twee stagiaires in Infobips meest recente cohort gebruikten AI op dezelfde frequentie, met tegengestelde resultaten. Een stelde vervolgvragen en kon volledig uitleggen wat de AI produceerde; hun groei was de hoogste in de cohort. De ander accepteerde output met minimale review, behandelde het als black box, en groeide nul. Het gereedschap was identiek. De relatie ermee was niet.

Pairing sessies en architectuur walkthroughs opnemen en later doorzoekbaar maken, geeft juniors iets waar zij naar kunnen teruggaan in plaats van dezelfde vraag opnieuw aan wie beschikbaar is. Het zal een mentor niet vervangen, maar het verlaagt de kost van twee keer vragen.

![Een senior engineer wijst op een laptop scherm terwijl een junior engineer overleunt om mee te volgen](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/codebasechat/2026-07/ec3aa0-inline3.webp)

## Sla het "Ban AI for Juniors" fix over

Elke roundup op dit onderwerp landt uiteindelijk op dezelfde aanbeveling: AI-toegang beperken voor junior engineers totdat zij het hebben "verdiend." Sla dit over. Het sluit niet aan wat teams die het probleem daadwerkelijk hebben gemeten, en het verhandelt één faalmode voor een ander, even reëel; juniors die de tools niet kunnen gebruiken die hun team verzonden kunnen achterlopen op een ander, even reëel. wat voor Infobip in plaats werkte, was opeenvolging, niet ban: probeer het probleem eerst, controleer met AI seconde, zodat de gewoonte van onafhankelijk denken zich vormt voor AI de standaard zet wordt. Zij voegden AI-vrije checkpoints in, niet als straf maar als ijking, zodat zowel stagiair als mentor weet waar vaardigheid werkelijk staat. Mentors schoven ook op van pull requests reviewen naar procesvolging: wie vroeg wat, wie zat vast waar, wie legde hun eigen verandering uit zonder hulp.

Tevreden zijn scoren stegen de hele tijd dat vaardigheidgroei daalde, wat de echte waarschuwing in hun data is: als je alleen monitort hoe mensen zich voelen over de tools, dan zul je dit niet zien komen. Twintig procent van stagiaires in Infobips meest recente cohort wist niet wat van een junior engineer op hun niveau werd verwacht in de eerste plaats, wat zelfbeoordeling dicht bij betekenisloos maakte. Je kunt een kloof niet meten tegen een referentiepunt dat niemand heeft opgeschreven.

## Wat wij werkelijk zouden veranderen deze sprint

Begin met de retro vraag hierboven: wie kan elk deel van het systeem uitleggen, hardop, nu. Die enkele vraag oppervlakkig meer cognitieve schuld in tien minuten dan enig dashboard.

Voor code schuld, houdt statische analyse in het spel. [Sonars 2026 developer survey](https://www.sonarsource.com/blog/how-ai-is-redefining-technical-debt/) toont 70% van ontwikkelaars al te gebruiken, en teams die het runnen rapporteren significant betere resultaten op rework kosten dan teams die het overslaan. Dit is geen controversiële aanbeveling, het is gewoon iets wat teams overslaan als ze snel gaan omdat de AI output klaar leek.

De moeite die AI verwijdert van code schrijven verdwijnt niet. Sonar noemt dit de "grote moeite verschuiving": het verschijnt later opnieuw, in schuld beheren en AI output corrigeren. De terugkerende delen van die triage automatiseren, vlaggen stale PRs, routering review verzoeken, vervolgingen jagen, vrijmaken senior tijd voor het deel dat werkelijk een mens vereist: beslissen of het team begrijpt wat het zojuist heeft verzonden.

Meeting traject, niet tevredenheid. Een team dat zich goed voelt over AI en zijn eigen architectuur niet in zes maanden kan uitleggen heeft geen tijd bespaard. Het heeft het geleend, tegen een rente die niemand opgeschreven heeft.

## FAQ

### Wat is het verschil tussen code schuld en cognitieve schuld?

Code schuld is wat linters vangen: duplicatie, inconsistente patronen, verborgen bugs. Cognitieve schuld is de kloof tussen hoe snel AI code genereert en hoe snel je team het daadwerkelijk begrijpt. Een schone codebase kan nog steeds cognitieve schuld hebben als niemand kan uitleggen wat het doet.

### Waarom kunnen teams AI-gegenereerde code niet goed reviewen?

Code review is een leesknelpunt, geen schrijfknelpunt. AI genereert een week code in één ochtend, maar review capaciteit groeide niet mee. Bovendien ziet plausibele code die subtiel verkeerd is er perfect uit in een pull request. Review mist het.

### Waarom raken juniors technische schuld door AI sneller?

Juniors die AI gebruiken zonder het uit te vragen scoren lager op code comprehension tests. Twee interns gebruikten AI op dezelfde frequentie: één stelde vervolgvragen en groeide; de ander accepteerde output als black box en groeiden helemaal niet.

### Moet je AI verbieden voor juniors?

Nee. Wat werkelijk hielp is opeenvolging, niet ban: probeer het probleem eerst, use AI tweede. Voeg AI-vrije checkpoints in niet als straf maar als ijking. Mentors schoven ook op van PR review naar procesvolging: wie vroeg wat, wie legde hun eigen werk uit zonder hulp.

### Hoe meet je of je team cognitieve schuld heeft?

Zet een architectuurdiagram omhoog in je retro. Vraag wie elk deel kan uitleggen, hardop, nu. Als het antwoord 'één persoon' of 'niemand' is, hebt je cognitieve schuld.

### Welke tools helpen tegen code schuld door AI?

Statische analyse (Sonar gebruikers rapporteren significante rework verbesseringen). Docs-as-code tools zodat reasoning naast code leeft in plaats van in iemands geheugen. Ask-your-codebase tools zodat review sneller kan bepalen: 'waar anders bestaat dit patroon.'

### Hoe groot is de impact van technische schuld door AI?

Sonars 2026 survey: 88% van entwickelaars ervaart minstens één negatief effect; 53% zegt AI genereert code die correct lijkt maar verborgen gebreken verbergt; 40% zegt AI verhoogde schuld via duplicatie. Maar 93% ervaart ook positieve effecten.