Een developer postte onlangs op Reddit dat hij vergeten was hoe je een Laravel API bouwt. Geen exotische edge case. Een standaard REST-endpoint. Het soort ding dat hij honderden keren eerder had gedaan. "Ik heb hiervoor gestudeerd," schreef hij. "Ik ben al jaren software engineer en het voelt alsof ik terug ben bij af."
Dit is geen losstaand verhaal. 404 Media kopte vorige week met "Software Developers Say AI Is Rotting Their Brains." Het stuk staat vol engineers die hetzelfde zeggen in andere woorden: er glijdt iets weg, en ze merken het pas als de AI er even niet is.
Het gesprek hierover wordt meestal ingekaderd als "vaardigheidsverlies." Zoals telefoonnummers vergeten na de komst van smartphones. Een klein ongemak. Je kunt het altijd opzoeken.
Die framing is gevaarlijk verkeerd.
Het gaat niet om schrijven, het gaat om lezen
De vaardigheid die je verliest is niet het schrijven van code. Je kunt nog steeds typen. Je kunt nog steeds documentatie lezen. Je kunt nog steeds een project opzetten uit je hoofd als het moet.
Wat je verliest is het vermogen om code kritisch te lezen. Om naar een functie te kijken en te voelen, nog voordat je de logica hebt gevolgd, dat er iets niet klopt. Dat instinct is geen magie. Het is patroonherkenning, opgebouwd door duizenden uren bugs schrijven, ze vinden, en begrijpen waarom ze er waren.
Als je stopt met bugs schrijven, stop je met dat instinct opbouwen.
Anthropic publiceerde eerder dit jaar een studie die dit concreet maakt. Ze gaven 52 engineers een nieuwe library om te leren. De helft gebruikte AI. De andere helft codeerde handmatig. Daarna testten ze het begrip.
De AI-groep scoorde 17% lager. Maar hier is het belangrijke deel: het grootste verschil zat bij debugging-vragen. Niet syntax. Niet API-kennis. Debugging. De specifieke vaardigheid om naar code te kijken en te begrijpen waarom het fout gaat.
De developers die de AI hun code lieten schrijven, konden de problemen erin niet vinden.
Waarom reviewen niet hetzelfde is als schrijven
Er is een veelgehoord verweer: "Ik review nog steeds alle output van de AI." Alsof het lezen van code achteraf dezelfde spieren traint als het zelf schrijven.
Dat doet het niet.
Wanneer je code schrijft, bouw je een mentaal model van intentie. Je weet waarom elke regel er staat, want jij hebt hem daar gezet. Je weet welke edge cases je hebt overwogen en welke je hebt overgeslagen. Je weet waar de draken zitten omdat je zelf door het bos hebt gelopen.
Wanneer je code reviewt die iemand anders schreef, of dat nou een collega is of een AI, dan match je patronen tegen ervaring. Maar als je zes maanden geleden gestopt bent met die ervaring opbouwen, dan ligt je patronenbibliotheek stil. Je leest met de ogen van gisteren.
Dit is waarom ik hetzelfde principe blijf herhalen: als je niet kunt uitleggen wat de code doet zonder het regel voor regel te lezen, had je het niet moeten accepteren. Niet omdat de AI het fout had. Maar omdat jij niet kunt zien of dat zo is.
Het 43%-probleem
Een Lightrun-onderzoek uit 2026 laat zien dat 43% van AI-gegenereerde codewijzigingen handmatig gedebugged moet worden in productie. Niet in testing. In productie. Nadat het door QA en staging is gekomen.
Denk na over wat dat betekent. Dit zijn geen voor de hand liggende bugs. Ze slagen voor tests. Ze komen door code review. Ze zien er correct uit. Ze breken pas onder real-world condities die niemand had voorzien, omdat niemand de code goed genoeg begreep om ze te voorzien.
De briljante papegaai schrijft plausibele code. Code die er goed uitziet. Code die de geurtest doorstaat van een reviewer die het niet zelf schreef. Maar plausibel is niet correct. En als je debugging-instinct is afgestompt, merk je het verschil niet tot je pager afgaat om 3 uur 's nachts.
Zo ontstaan lavalagen. Niet door overduidelijk slechte code, maar door code die subtiel fout is op manieren die niemand in het team nog kan diagnosticeren.
Het autopilot-probleem
De luchtvaart heeft dit tientallen jaren geleden al uitgevogeld. Piloten die te veel op de automatische piloot vertrouwen verliezen situational awareness. Ze reageren trager op noodgevallen. Ze missen waarschuwingssignalen. De FAA verplicht handmatige vlieguren specifiek om dit te voorkomen.
Software kent geen zulke verplichting. Niemand eist dat je 20% van je werktijd handmatig code schrijft om je debugging-instinct te onderhouden. Niemand test of je nog een stack trace kunt volgen zonder het aan Claude te vragen.
En anders dan in de luchtvaart, waar een crash direct zichtbaar is, zijn de gevolgen van verloren situational awareness in code stil. De bugs stapelen zich op. De lavalaag wordt dikker. En op een dag staar je naar een productie-storing in code die elke geautomatiseerde check heeft doorstaan, en je kunt oprecht niet uitvogelen wat er mis is.
Wat je er daadwerkelijk aan doet
Ik ga je niet vertellen dat je moet stoppen met AI. Die trein is vertrokken. En de productiviteitswinst is echt voor de juiste taken.
Maar er is een verschil tussen AI als gereedschap en AI als kruk. De grens is simpel:
- Schrijf de logica eerst zelf. Gebruik AI voor boilerplate, scaffolding en repetitieve patronen. Niet voor de stukken die denken vereisen.
- Als je het niet kunt uitleggen, wijs het af. Niet "ik kan het lezen en het ziet er goed uit." Kun je uitleggen waarom het doet wat het doet? Kun je voorspellen waar het breekt?
- Debug soms handmatig. Wanneer iets kapot gaat, weersta de neiging om de foutmelding in een AI te plakken. Volg het zelf. Bouw die spier weer op.
- Schrijf expres bugs. Serieus. Implementeer iets fout en zoek dan de bug. Zo bouw je debugging-instinct op.
De developer die vergat hoe je een Laravel API bouwt, verloor die vaardigheid niet van de ene op de andere dag. Hij verloor het per geaccepteerde suggestie. Elke keer dat de AI iets schreef wat hij zelf had kunnen schrijven, sloeg hij een herhaling over van de oefening die de vaardigheid in leven houdt.
AI maakt je geen slechtere schrijver.
Het maakt je een slechtere lezer. En in dit vak is lezen de moeilijkere vaardigheid.