Ga naar inhoud
AI & Governance · 14 juli 2026 · 12 min leestijd

Never-skilling:
het risico dat niemand in je bedrijf meet

AI loste mijn bug op zonder dat ik begreep waarom. Onderzoek bij artsen en developers laat zien dat dit patroon een naam heeft: never-skilling. En het speelt nu in elk bedrijf dat AI inzet.

🤖 Agent-friendly (.md)
Illustratie bij artikel: Never-skilling: het risico dat niemand in je bedrijf meet

TL;DR

  • Never-skilling is nieuwer dan deskilling. Je verleert geen vaardigheid, je bouwt hem nooit op — omdat AI de taak al overneemt voordat je de kans kreeg om te leren.
  • Het onderzoek is hard. Anthropic liet 52 developers coderen met en zonder AI: de AI-groep scoorde twee cijferpunten lager, vooral op debugvragen, voor een tijdwinst van twee minuten.
  • Zelfs Anthropic zit op de curve. Meer dan 80% van hun eigen productiecode wordt inmiddels door Claude geschreven — hetzelfde patroon, bij de beste engineers ter wereld.
  • Geen enkele KPI meet dit. Terwijl doorlooptijd en klanttevredenheid omhooggaan, verdwijnt stilletjes de vakkennis die je nodig hebt zodra een dossier níét standaard is.

In mei 2026 zat ik drie uur vast op één bug in Cursor. De foutmelding wees naar iets wat volgens mij helemaal niet stuk kon zijn, en ik kwam er niet uit. Dus deed ik wat ik altijd doe. Ik gooide het probleem terug naar het model. Dat lukte niet. Ik schakelde naar een zwaarder model. Dat lukte ook niet. Uiteindelijk stapte ik over naar een andere provider, en daar werd hij gevonden en opgelost.

Die code draait nu gewoon. En als je mij vandaag vraagt wat er precies mis was, dan moet ik je het antwoord schuldig blijven. Ik weet het niet. Ik heb het nooit geweten.

Dat gaf me een ongemakkelijk gevoel, en ik ben er daarna over blijven nadenken. Niet omdat het misging, want het ging juist goed. Maar omdat ik voor het eerst scherp voelde dat ik een probleem had opgelost zonder het te begrijpen. Ik ben zelf een van de mensen die inmiddels dagelijks bouwen zonder developer-achtergrond, en dat werkt verrassend vaak. Alleen deze keer voelde het anders. En de vraag die ik mezelf stelde is de vraag die ik in deze blog wil beantwoorden.

Hoe erg is dat eigenlijk?

Wij snappen wel vaker niet wat we gebruiken

Laten we beginnen met de nuchtere kant, want die is er ook.

Begin eens bij je eigen telefoon. Vroeger kende ik een stuk of twintig telefoonnummers uit mijn hoofd. Die van thuis, die van mijn ouders, die van een paar vrienden. Vandaag ken ik er nul. Ik typ een naam in en ik druk op bellen. Is dat erg? Ik denk het niet. Ik heb er geen enkele last van, en de ruimte in mijn hoofd is aan iets anders besteed.

Zo zit het overal. Jij rijdt waarschijnlijk auto zonder dat je een motor kunt reviseren. Je vliegt naar Barcelona in een toestel dat het grootste deel van de vlucht door een computer wordt bestuurd, en de piloot voorin kan je de regelalgoritmes van dat systeem echt niet uittekenen. Je huisarts leest een bloeduitslag van een apparaat dat hij niet kan kalibreren. En de programmeurs van vroeger moesten hun computergeheugen nog met de hand opruimen, iets waar vandaag geen enkele ontwikkelaar meer naar omkijkt omdat de software dat zelf doet.

Dit is niet nieuw en het is ook geen ongeluk. Het is precies het mechanisme waarmee we vooruitgang boeken. Elke laag die je erbovenop legt, maakt de laag eronder onzichtbaar, en juist daardoor kunnen meer mensen meer doen. Een hele generatie vaardigheden is bij programmeurs verdampt, en niemand rouwt daar nog om.

Dus als je mij vraagt of het erg is dat ik niet weet wat mijn code precies doet, dan is het eerste eerlijke antwoord: op zichzelf niet. Ik gebruik een abstractielaag, net als iedereen. Wie daarover in paniek raakt, heeft niet goed gekeken naar hoe technologie altijd al heeft gewerkt.

Alleen klopt dat antwoord maar half. En de andere helft is degene waar het interessant wordt.

Waarom never-skilling iets anders is dan niet weten hoe je motor werkt

Kijk nog even naar dat telefoonnummer. Ik ken het niet meer uit mijn hoofd, en toch kan ik er altijd bij. Het staat in mijn toestel, het staat in de back-up, en als alles wegvalt kan ik het nog opzoeken. De kennis is niet weg, ze is opgeslagen op een plek waar ik hem terugvind. Dát is waarom het niet erg is.

Een abstractielaag is pas veilig als er aan drie voorwaarden is voldaan, en dat realiseerde ik me pas toen ik mijn eigen situatie ernaast legde.

De eerste voorwaarde is dat de laag zich voorspelbaar gedraagt. Je contactenlijst geeft elke keer hetzelfde nummer terug. Een taalmodel doet dat niet. Dat is nou juist de reden waarom ik van model kon wisselen en waarom het bij de derde poging ineens wel lukte. Ik heb geen betrouwbaar gereedschap gebruikt, ik heb een kansverdeling geraadpleegd tot er iets bruikbaars uit kwam.

De tweede voorwaarde is dat er ergens in de keten nog iemand zit die het wél begrijpt. Jij hoeft je motor niet te kunnen reviseren, want de monteur kan dat. De piloot hoeft de autopilot niet te kunnen programmeren, want er zit een team ingenieurs achter dat het systeem doorgrondt en er zit een onderzoeksraad achter die het uitpluist als het misgaat. De kennis is niet verdwenen, hij is verplaatst.

De derde voorwaarde is dat de faalmodus begrensd is. Als de autopilot uitvalt, neemt de piloot over, en die kan dat omdat hij verplicht met de hand blijft vliegen in de simulator. De luchtvaart is daar bijna obsessief in, en dat is geen toeval.

Mijn bug voldeed aan geen van die drie. De laag gedroeg zich niet voorspelbaar, want ik moest drie keer wisselen voordat er iets uit kwam. Er zat niemand onder de laag die het begreep, want dat had ik zelf moeten zijn. En de faalmodus was niet begrensd, want als geen van de modellen hem had gevonden, was ik simpelweg klaar geweest.

Het telefoonnummer dat ik vergeten ben, staat ergens. De oplossing van mijn bug staat nergens. Niemand weet hem, ik ook niet, en er is geen back-up waar ik hem uit kan halen.

Dat is geen abstractie meer. Dat is hoop.

En daar zit het verschil tussen niet weten hoe je motor werkt, en niet meer kunnen leren hoe je motor werkt. Voor dat tweede bestaat inmiddels een woord, en ik hoorde het voor het eerst in een theaterzaal.

De curve die ik in Leusden op het scherm zag

Op 7 juli zat ik bij het VIP re:Invent Congres. Erik Scherder stond op het podium, en op het scherm achter hem verscheen een grafiek die ik daarna niet meer uit mijn hoofd kreeg.

Scherder is hoogleraar neuropsychologie, en zijn boodschap ging over iets wat ik tot dat moment niet had meegewogen. Ik dacht namelijk dat dit een verhaal was over vaardigheden. Over kennis die je niet opdoet. Hij hield een verhaal over biologie.

Zijn punt is dat je hersenen mentale inspanning nodig hebben om in conditie te blijven. Doe je dat structureel niet meer, dan gaat de kwaliteit van de witte stof achteruit. Dat is het weefsel dat de verbindingen in je brein verzorgt, en het is geen abstract begrip maar meetbaar materiaal. Die achteruitgang kost je veerkracht, ze kost je het vermogen om kritisch te denken, en ze maakt je mentale filters botter.

En dan komt het onderdeel dat mij het meest raakte. Volgens Scherder kiest de mens vanuit een evolutionaire drang naar energiebesparing bijna altijd voor de weg van de minste weerstand. Denken kost energie, dus als er een gemakkelijker route is, nemen we die. Niet uit luiheid, maar omdat we zo gebouwd zijn. En AI is de gladste weg van de minste weerstand die ooit is aangelegd.

Ik zat drie uur op die bug. Op geen enkel moment heb ik overwogen om hem zelf te ontrafelen. Ik heb hem drie keer doorgegeven aan een machine. Dat voelde als efficiëntie. Volgens Scherder was het mijn brein dat de makkelijkste weg koos.

Erik Scherder over wat het uitbesteden van denkwerk doet met je hersenen.

De grafiek die hij liet zien, komt uit een artikel van Tyler Berzin en Eric Topol, gepubliceerd in The Lancet van 18 oktober 2025. Berzin is endoscopist in Boston, Topol is een van de bekendste stemmen over technologie in de geneeskunde. Hun vraag was simpel: hoe houden artsen hun vaardigheden op peil in een tijd waarin het algoritme meekijkt?

Zij onderscheiden drie manieren waarop het misgaat als je je denkwerk uitbesteedt.

De eerste is deskilling. Je kon het, en je verleert het omdat de machine het overneemt.

De tweede is mis-skilling. Je neemt de fouten en de vooroordelen van het systeem over en gaat ze zelf geloven.

De derde is de meest ongemakkelijke, en dat is never-skilling. Je bereikt het niveau nooit, omdat de machine er al was voordat jij het kon leren.

Mogelijke effecten van AI op vakvaardigheid in de tijd. Naar Berzin en Topol, The Lancet 2025.
De curve die ik op het scherm zag. Links de opbouw van vakbekwaamheid bij wie vóór AI is opgeleid. Rechts drie mogelijke paden daarna: AI maakt je beter, je verleert het langzaam, of je haalt de stippellijn nooit. Naar Berzin en Topol, The Lancet, 18 oktober 2025.

Op de grafiek zie je die drie als curves naast elkaar. De artsen die vóór AI zijn opgeleid, klimmen naar hun niveau en zakken daarna langzaam weg. En de artsen die ná AI zijn opgeleid, komen niet eens meer bij die stippellijn in de buurt. Ze halen het niveau nooit, want ze hebben het nooit hoeven halen.

Ik zat daar in die zaal en dacht: dat ben ik. Ik heb nooit met de hand leren debuggen. Ik heb het overgeslagen. Ik ben de groene lijn.

Volg mij op LinkedIn

Volg mijn updates over AI, strategie en ondernemen op LinkedIn

Van endoscopisten naar developers: hetzelfde patroon, twee sectoren

Nu is een grafiek in een presentatie nog geen bewijs, en ik ben de laatste die een mooi plaatje voor waarheid aanneemt. Dus ik ben gaan zoeken. En er ligt inmiddels aan beide kanten hard materiaal.

Voor de deskilling-kant is er een observationeel onderzoek van Budzyń en collega's, gepubliceerd in Lancet Gastroenterology and Hepatology (opent in nieuw venster)00133-5/abstract) in 2025. Zij volgden ervaren endoscopisten in meerdere ziekenhuizen die een tijdlang met AI-ondersteuning werkten bij coloscopieën, en daarna zonder. Toen die ondersteuning werd uitgezet, ging hun vermogen om poliepen te vinden meetbaar achteruit. Dus geen beginners, geen theorie, maar ervaren specialisten die iets kwijtraakten wat ze eerder wel konden. Alleen doordat ze het een poos niet meer zelf hoefden te doen.

En voor de never-skilling-kant is er sinds eind januari 2026 een onderzoek van Anthropic zelf (opent in nieuw venster), uitgevoerd door Judy Hanwen Shen en Alex Tamkin. Zij zetten 52 overwegend junior software engineers aan het werk met een Python-library die ze nog niet kenden. De helft mocht een AI-assistent gebruiken, de andere helft niet. Daarna kregen ze allemaal een toets over de concepten die ze net hadden toegepast.

De groep met AI scoorde vijftig procent. De groep die het met de hand had gedaan, scoorde zevenenzestig. Dat is een verschil van ongeveer twee volle cijferpunten, en het is statistisch significant.

Maar het detail dat er echt toe doet, staat verderop in het onderzoek. Het grootste gat tussen beide groepen zat namelijk bij de debug-vragen. Precies daar waar je moet kunnen zien dát iets fout is, en waarom. Precies de vaardigheid die je nodig hebt om AI-code te controleren. En precies de vaardigheid die ik zelf nooit heb opgebouwd.

De tijdwinst, tussen haakjes, was ongeveer twee minuten. Niet significant.

Twee minuten sneller. Twee cijferpunten dommer.

Waarom dit jouw bedrijf raakt en niet alleen artsen en programmeurs

Nu kun je dit lezen als een verhaal over artsen en programmeurs en denken dat het jou niet aangaat. Dat zou een vergissing zijn, en ik denk dat het een dure vergissing wordt.

Want de curve is niet medisch en niet technisch. De curve gaat over wat er gebeurt als iemand een taak nooit meer helemaal zelf hoeft te doen. En dat gebeurt op dit moment door je hele bedrijf heen.

Je acceptant die zijn risicobeoordeling laat voorbereiden door een model. Je schadebehandelaar die de eerste analyse van het dossier voorgeschoteld krijgt. Je marketeer die geen briefing meer uitschrijft maar een prompt. Je jongste medewerker die nog nooit een offerte helemaal vanaf nul heeft gemaakt, omdat er altijd al een concept was.

Die mensen worden er allemaal sneller van. En de meeste van hen komen er ook prima mee weg, want de meeste dossiers zijn standaard en de meeste beoordelingen zijn routine.

Tot het dossier binnenkomt dat níét standaard is.

Dat is het moment waarop je erachter komt of er in jouw organisatie nog iemand onder de laag zit. En hier komt het punt dat mij het meest bezighoudt: er is geen enkele KPI die dit meet. Je meet doorlooptijd, je meet klanttevredenheid, je meet kosten per dossier. Al die cijfers gaan de goede kant op als je AI inzet. Er is geen dashboard waarop staat: kunnen we het nog zonder.

In de meeste organisaties die ik van dichtbij zie, is dat gesprek nog niet één keer gevoerd. Niet in het MT, niet in de RvC, niet in het risicoverslag. Dit risico staat op geen enkele directietafel, en dat is opvallend, want het is precies het soort sluipend operationeel risico waar een toezichthouder over een paar jaar keihard naar gaat vragen. De EU AI Act eist al AI-geletterdheid van je personeel. De volgende vraag is logischerwijs of je personeel nog voldoende vakinhoudelijk is.

De paradox die Anthropic zelf publiceert

Nu wordt het pas echt ongemakkelijk, en dit is het stuk waarvan ik denk dat bijna niemand het heeft opgemerkt.

Want dezelfde organisatie die in januari publiceerde dat junior developers slechter leren met AI, publiceerde daarna een tweede stuk. Deze keer over zichzelf. Het heet When AI builds itself (opent in nieuw venster), het komt van het Anthropic Institute, en het gaat over de vraag hoe hard AI de ontwikkeling van AI versnelt.

De cijfers daarin zijn opmerkelijk. Sinds mei 2026 wordt meer dan tachtig procent van de code die Anthropic in productie zet, geschreven door Claude. Vóór de lancering van Claude Code in februari 2025 was dat een paar procent. De gemiddelde engineer merget nu ongeveer acht keer zoveel code per dag als in 2024, niet omdat hij harder typt, maar omdat hij vrijwel niets meer zelf typt. Hij stuurt aan en hij controleert.

Eén medewerker wordt in het stuk geciteerd met de opmerking dat hij al ongeveer vijf maanden geen regel code meer zelf heeft geschreven.

Dat is dus geen vibecoder zonder achtergrond zoals ik. Dat zijn de beste engineers ter wereld, bij het bedrijf dat het model zelf bouwt. En zij zitten op precies dezelfde curve.

Anthropic beschrijft ook waar dat naartoe gaat, en ze zijn daar eerlijk over. Zodra door AI geschreven code net zo goed is als door mensen geschreven code, stoppen mensen met schrijven en gaan ze alleen nog beoordelen. Dat is hun eigen woordkeuze. En daar staat meteen achteraan dat de menselijke beoordeling dan de flessenhals wordt, want een mens kan niet zo snel controleren als een model kan produceren.

Lees dat nog eens rustig door, want daar zit de knoop.

De toekomstige rol van de mens is beoordelen. Beoordelen betekent dat je moet kunnen zien dát iets fout is, en waarom. Dat is exact de vaardigheid die het eigen onderzoek van Anthropic aanwijst als de vaardigheid die het hardst achteruitgaat bij mensen die met AI leren werken. Het grootste gat in die toets zat bij de debug-vragen.

Wij zijn dus met z'n allen bezig een toekomst te bouwen waarin het enige wat de mens nog doet, precies het enige is wat de mens aan het verleren is.

Er staat in dat stuk nog een citaat van een medewerker dat ik niet meer uit mijn hoofd krijg. Hij vertelt dat op de dagen dat alles werkt, hij het gevoel heeft dat niets van wat hij doet er nog toe doet. En dat er ook dagen zijn dat alles kapotgaat, dat hij niet begrijpt waarom, en dat hij zich dan realiseert dat hij geen idee meer heeft waar hij eigenlijk mee bezig is geweest.

Dat is mijn bug. Alleen dan gezegd door iemand die er wél verstand van heeft.

Eerlijk is eerlijk: Anthropic verstopt dit niet. Ze schrijven het gewoon op, inclusief de kanttekeningen. Dat siert ze. Maar het maakt de conclusie niet anders. Het bedrijf dat de curve heeft gemeten, rijdt er zelf het hardst op vooruit.

Wat wél werkt, en dat is het opvallendste uit het onderzoek

Nu het goede nieuws, want dat zit in datzelfde Anthropic-onderzoek en het is naar mijn idee het belangrijkste stuk.

Niet iedereen in de AI-groep scoorde slecht. Sommigen scoorden juist hoog. En het verschil zat niet in hoeveel ze AI gebruikten, maar in hóé ze hem gebruikten.

De laagscoorders lieten de assistent gewoon het werk doen. Ze vroegen om code, plakten die erin en gingen door. De snelste groep in het hele onderzoek was tegelijk de domste groep in het hele onderzoek. Een andere groep gebruikte AI alleen om te debuggen zonder ooit te vragen waaróm iets stuk was, en die scoorde ook slecht.

De hoogscoorders deden iets anders. Zij vroegen door. Ze vroegen om uitleg bij de code die ze kregen. Ze stelden conceptuele vragen over hoe de library eigenlijk in elkaar zat. En de groep die alléén conceptuele vragen stelde, was niet alleen de best scorende groep, hij was ook nog eens sneller dan bijna alle andere groepen.

Zelfde tool. Zelfde tijd. Tegengestelde uitkomst.

En als je dit naast het verhaal van Scherder legt, dan valt alles op zijn plek. Vragen om code is de weg van de minste weerstand. Vragen waaróm die code werkt, is mentale inspanning. Het is dezelfde tool, alleen kies je in het ene geval voor de gladde route en in het andere geval voor de route waarop je brein nog iets te doen heeft. En het onderzoek laat zien dat die tweede route je niet eens tijd kost.

Dat verandert de vraag die jij als directeur moet stellen. Die vraag is niet of je AI toestaat, want dat schip is vertrokken. De vraag is of je enig idee hebt in welke modus je mensen hem gebruiken. En of je ze ooit hebt laten zien dat er een verschil is tussen "schrijf dit voor mij" en "leg uit waarom dit werkt".

Dat kost je vijf minuten in een teamoverleg. Het is de goedkoopste interventie die ik ken.

Terug naar mijn bug

Mijn code draait nog steeds. Ik weet nog steeds niet wat er mis was.

En na alles wat ik heb gelezen ben ik daar minder relaxed over dan toen ik eraan begon. Niet omdat het toen fout ging, maar omdat ik zie wat er gebeurt als die situatie zich honderd keer herhaalt. Bij mij, en bij iedereen die op dit moment een vak instapt waarin de machine er al stond.

Ik ga niet stoppen met vibecoden, dat zou een belachelijke conclusie zijn. Wat ik wel ga doen, is bij de volgende bug eerst vragen wat er aan de hand is voordat ik vraag of hij opgelost kan worden. Twee minuten langzamer. Twee cijferpunten slimmer. En volgens Scherder ook nog eens een brein dat iets te doen krijgt.

Dat is de hele les. De weg van de minste weerstand ligt er, hij is gratis, en hij is verleidelijk. Je hoeft hem alleen niet elke keer te nemen.

Bronnen