Hoe zie je wie er echt denkt?

Op dit moment zit er in jouw team minstens één engineer die werk oplevert dat hij niet kan reproduceren op een whiteboard.

De code compileert. De tests slagen. De PR is smetteloos. Het denkwerk was alleen nooit van hem, en dat weet hij niet. Van binnenuit voelt een geleende gedachte precies als een eigen gedachte.

Je komt erachter zodra iemand de cachevraag stelt. Het architectuurdiagram staat op het scherm, het ontwerp ziet er netjes uit en een staff engineer buigt naar voren:

Walk me through why you ruled out a write-through cache here. What happens when this specific node restarts under load?

De stilte die dan valt, hoort een ophaalstilte te zijn: de engineer die in zijn eigen mentale model zoekt naar de beperking die hij had overwogen, het alternatief dat hij had afgewogen, het tweede-orde-effect waar hij rekening mee hield toen hij de keuze maakte.

Nu is de stilte leeg.

Wrijving droeg het gebouw

Dit is geen grafrede op de goeie ouwe tijd van Stack Overflow-speurwerk.

AI is een fantastische vermenigvuldiger. Het is een onvermoeibare nachtelijke reviewer die je ontwerp om 1 uur ‘s nachts leest zonder te zeuren. Het is een sparringpartner die een tegenargument lang genoeg vasthoudt dat jij een echte verdediging kunt opbouwen. Het wijst je op het stuk dat je had overgeslagen. Engineers die het goed gebruiken zijn, op elke eerlijke maatstaf, scherper dan twee jaar geleden. Ik gebruik het. Jij gebruikt het. Dit stuk zou nep zijn als het deed alsof dat niet zo was.

Maar we hebben een categoriefout gemaakt. We dachten dat de wrijving van software engineering gewoon een snelheidslimiet was. Dat was ze niet.

Wrijving hield niet alleen de boel op, ze was dragend. Ze was een topografische kaart in real time die liet zien waar de moeilijke problemen zaten. We hebben de wrijving wegge-optimaliseerd en daarmee per ongeluk de kaart gewist.

Als een probleem echt moeilijk was, zat je drie uur naar een muur te staren, te zweten voor een whiteboard en aan je carrièrekeuzes te twijfelen. De wrijving was een kompas. Dezelfde wrijving die het werk zo ellendig maakte, dwong je om het model in je hoofd op te bouwen: de write-through-semantiek, de faalmodi, het read-after-write-venster. Je hield het allemaal in je schedel vast tot je het ontwerp kon verdedigen zonder het document open.

Het model hallucineert in twaalf seconden een perfect opgemaakt, syntactisch zoetgevooisd architectuurdocument. Je krijgt geen wrijving. Je krijgt een dopaminekick en een leugen. Je hebt het antwoord. Je hebt de spier niet.

De gebroken as

Een engineeringorganisatie is een steekproefprobleem. Je kunt niet elke toetsaanslag volgen, dus lees je de artefacten en leid je de cognitie daaruit af. Pull requests, designdocs, postmortems, af en toe een incidentreview. Dat zijn de meetinstrumenten. Performance reviews, kalibratie, promotiecriteria en sollicitatierondes rusten allemaal op de aanname dat artefact en cognitie uit dezelfde bron komen.

AI heeft de as tussen die twee wielen gebroken.

Output is nu een functie van drie variabelen, de engineer, het model en de prompt, en de artefacten vertellen je over alle drie door elkaar, zonder dat je het signaal kunt scheiden. Een nette PR past bij een doordachte engineer, bij een niet-doordachte engineer, of bij een tabblad dat iemand in de trein open liet staan. Het artefact komt nog steeds op tijd binnen. Het draagt alleen het signaal niet meer waarvoor je het las.

Dit telt het zwaarst voor de engineers die je wilt laten groeien. Een senior die vloeiende AI-output levert, is op zijn slechtst geleverd. De spier is er al, het model bestuurt alleen het toetsenbord. Een junior die hetzelfde oplevert, doet dat zonder ooit de spier te bouwen die het werk had moeten bouwen. Ze leveren de write-through cache op zonder ooit te modelleren wat er gebeurt als de node wegvalt. Ze leveren de read replica voor analytics op zonder ooit stil te staan bij het consistentievenster. Het artefact is prima. De architectuurintuïtie die eronder had moeten groeien, kwam nooit opdagen.

De METR-paradox

Hier is een getal dat engineering leaders in het gezicht zou moeten springen. METR deed in 2025 een zorgvuldige studie. Ervaren ontwikkelaars die AI-hulp gebruikten, voltooiden taken 19% trager dan zonder, terwijl ze dachten dat ze 20% sneller waren.¹ Junioren in onbekende code gaan in McKinsey’s aparte werk de andere kant op: 26 tot 39% sneller.²

De gradiënt loopt verkeerd om voor een organigram. Waarom lijken junioren op 10x engineers terwijl seniors vlak blijven?

De seniors zijn niet slechter met AI. Het werk waar AI bij helpt, is niet het werk dat zij deden. Hun bottleneck was nooit typen, het was beslissen wat je typt. De junioren lijken snel omdat hun bottleneck typen was, en typen is nu gratis. De productiefunctie is niet alleen beter geworden, ze is verplaatst. Ze is helemaal weg van het artefact. De junioren leveren output die er senior uitziet. Ze bouwen, op geen enkel meetbaar signaal, senior oordeelsvermogen op.

De junioren sluiten tickets zo snel dat het Jira-bord eruitziet als een gokkast die uitbetaalt. Het dashboard zegt dat ze 39% sneller zijn. Het dashboard is dolblij. Het dashboard hoeft alleen de state machine niet te onderhouden die ze zojuist hebben verzonnen.

Drie dingen gaan mis in je hoofd

Drie psychologische mechanismen slaan tegelijk aan als je vloeiende AI-output leest en voor je eigen gedachte aanziet. Ze zijn gedocumenteerd, tientallen jaren oud en niet verouderd.

De vloeiendheidsillusie. Mensen beoordelen hoe goed ze iets begrijpen aan hoe makkelijk het in hun hoofd opkomt.³ AI-output is maximaal makkelijk. Gepolijst, zelfverzekerd, gestructureerd op precies het niveau dat jij kunt opnemen. Het lezen geeft je het warme gevoel van begrip, zonder het werk te doen dat dat gevoel normaal oplevert.

De warmte van begrip is de bug.

Het verloren inspanningssignaal. Het grootste deel van je loopbaan was dit voelde moeilijk een bruikbare maat voor ik doe echt denkwerk. De wrijving deed de kalibratie voor je. Met het model in de lus is het denkwerk uitbesteed, maar de maat is niet opnieuw geijkt. Je levert iets op, het voelde makkelijk, je neemt aan dat het dus simpel was, terwijl het ook kan betekenen dat je niet hebt nagedacht.

Auteurschapsdrift. Onderzoek naar source monitoring is veertig jaar oud. Mensen kunnen ideeën die ze zelf bedachten niet betrouwbaar onderscheiden van ideeën die hun werden aangereikt.⁴ Op donderdag is de source-monitoringdrift compleet. De engineer kijkt naar een regexblok van 400 regels waar hij met het model aan “gepaird” heeft en denkt oprecht: Ja, ik herinner me hoe ik die negative lookbehind zorgvuldig in elkaar zette. Dat deed je niet. Je vroeg het promptvak om de foute tekens weg te laten gaan en nam het eerste snippet dat geen error gaf.

De cachevraag landt precies hierin. De engineer schreef de write-through-laag met een model in de lus. Het voelde makkelijk. De code compileert. De tests slagen. Maar hij is nooit stilgestaan bij wat er met de write onderweg gebeurt als de node wegvalt. Nooit bij wat de database ziet als de cache terugstormt, of wat het leespad teruggeeft tijdens het opwarmen. Hij heeft geen mentaal model om uit op te halen als iemand ernaar vraagt. Er is niets mis met de code. Er zit niets in het hoofd van de engineer.

Introspectie werkt niet meer

Het gecombineerde effect is het stuk dat je wakker moet houden.

De engineer die van verlengen naar vervangen is gekanteld, liegt niet als hij zegt dat hij erover nagedacht heeft. Hij voelde vloeiendheid. Het werk voelde makkelijk zoals goed begrepen werk makkelijk voelt. Hij herinnert zich de redenering als de zijne.

Het eigen verslag is onbetrouwbaar. Het artefact is onbetrouwbaar.

Wat overblijft, is wat hij koud kan doen als je ernaar vraagt.

Scepsis is geen wantrouwen tegen AI

Scepsis is in deze context geen wantrouwen tegen AI. Het is wantrouwen tegen het vloeiendheidssignaal. Het is de discipline om ik kan dit lezen en heb het gevoel dat ik het snap te scheiden van ik kan dit morgenochtend uit het niets maken. Dat was vroeger ongeveer hetzelfde. Nu niet meer.

Deze stap moet eerst gebeuren, in het hoofd van de engineer zelf, voordat een manager er iets nuttigs mee kan. Als de engineer het niet op zichzelf kan toepassen, redt geen reviewproces hem.

Scepsis, toegepast op jezelf

Koud reproduceren. Klap je laptop dicht. Loop naar het whiteboard. Reproduceer het ontwerp uit je hoofd, inclusief de alternatieven die je afwees. De stilte voordat je begint, is de data.
Jezelf tegenspreken. Pak de aanname waar je het minst gerust over bent en probeer die te breken zonder opnieuw te prompten. Als je eerste zet is om de chat te openen, heb je je antwoord.
De 10x-test. Wat verandert er als de loadaanname 10x verschuift? Als je antwoord ik vraag het het model is, is het model eigenaar van het ontwerp, niet jij.

En dan is er de versie van de cachevraag die je jezelf stelt, in je eigen hoofd, ‘s avonds laat in je eigen keuken:

Walk me through why I ruled out a message queue here. Wait. Did I rule that out? Or did the model just not mention it? Wait, am I the model?

Schrijf een keer per week de beslissingen op die je nam, in drie kolommen: de jouwe, die van het model en niet te scheiden. Die derde bak is de interessante. Het hoort niet de grootste te zijn.

De versie voor managers

De taak van de engineering manager is niet langer velocity bijhouden. Het is peilen hoe diep het zit.

Gespreksreview is het ontbrekende instrument. De data die de organisatie echt nodig heeft, drie momenten per kwartaal waarop deze engineer een niet-triviale beslissing verdedigde onder live vragen, staat in niemands agenda, in geen enkel reviewtemplate en op geen enkel dashboard. Ze bestaat alleen in de kamer, en alleen als iemand in die kamer eraan dacht om te vragen.

De uitwisseling om op te letten:

“Walk me through why you chose this specific database indexing strategy.”

Stilte.

“Okay, walk me through what an index is.”

Langere stilte.

Als een engineer het ontwerp niet kan verdedigen met zijn laptop dicht, heeft hij het niet geschreven.

Aannemen is veranderd

Het derde vlak waar dit landt is aannemen, en daar komen de gevolgen het snelst aan.

Ik ga ervan uit dat elke kandidaat AI gebruikt. Het cv ziet er geweldig uit, de take-home is schoon, en niets daarvan is nog een signaal. Ik toets niet meer op perfecte syntax of debugvaardigheid: het model kan beide, en de kandidaat weet dat ik dat weet.

Waar ik nu op toets, is beslissen voordat het model dat doet. De kandidaat die bij een ontwerpopdracht zegt “I need this, but I know this will happen, and if traffic doubles, this falls over here, so I’d actually do that instead”, is de kandidaat die de spier heeft gebouwd. De kandidaat die een schoon ontwerp reproduceert maar me niet kan vertellen wat er bij 10x kapotgaat, is de kandidaat die het model door de take-home heeft gedragen.

Het andere waar ik op toets, is het deel van het systeem dat het model niet kan zien. Het horizontaal schalende cluster achter de service. De cache die in de repo van een ander team staat. De downstream consumer die zes weken lang stilletjes een misvormd event wegslikt voordat iemand een pager krijgt. Het model is briljant binnen de codebase die het voor zich heeft. Het is blind voor het systeem eromheen. Dat geldt ook voor de kandidaat die alleen ooit met het model heeft gepaird.

Doen alsof helpt niet: ze gebruiken AI. Het interview gaat er niet meer over of ze een functie kunnen maken. Het gaat erom of ze het systeem in hun hoofd kunnen houden.

Het probleem van over drie jaar

Wat het systeem niet kan zien, kan het niet beoordelen. Wat het niet kan beoordelen, kan het niet op promoveren. Waar het niet op promoveert, selecteert het niet meer.

Dus gaan we promoveren op velocity. We bouwen een hele generatie staff engineers die alles kunnen opleveren en niets kunnen verdedigen. De burndown charts worden prachtig. De burndown charts worden het enige dat niet in brand staat.

De senior engineers die een ontwerp onder bevraging kunnen verdedigen, zijn niet weg: ze zijn nooit aangenomen. Hun opvolgers zien er op het dashboard hetzelfde uit. Ze kunnen de vraag alleen niet beantwoorden.

Draai het om op dit stuk

Je knikt mee. Het argument voelt juist. De logica klikte op zijn plek.

Maar onthoud de bug: de warmte is geen bewijs dat het argument klopt.

Dit stuk begon als onenigheid met Koshy John’s AI should elevate your thinking, not replace it, dat de persoonlijke-deugdversie van dit argument maakt. Hij heeft grotendeels gelijk. Delen van dit essay zijn met een model gebrainstormd. Sommige formuleringen kwamen te makkelijk. Er staan zinnen in die ik, morgen koud gevraagd, niet in dezelfde vorm zou kunnen reproduceren.

Ben ik een genie omdat ik dit zo kan verwoorden, of drukte ik gewoon op Regenerate tot de robot cynisch genoeg klonk?

Klap morgenochtend je laptop dicht en probeer deze stelling uit je hoofd te reproduceren. Loop de drie variabelen langs die de as braken. Loop het verschil langs tussen het argument van Koshy John en dit argument.

Als dat niet lukt, heb je het niet gedacht. Je hebt het alleen gelezen.

Maar de cache

Over drie jaar zijn onze engineeringdashboards helemaal groen. De velocity is door het dak. De organisatie ziet er op papier foutloos uit.

De cache staat dan wel in brand.

METR, Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity, July 2025. ↩
McKinsey, Unleashing developer productivity with generative AI, 2023. Meldt winst in taakvoltooiing voor minder ervaren ontwikkelaars van grofweg 26 tot 39%, afhankelijk van het soort taak. ↩
See Rozenblit, L. & Keil, F., The misunderstood limits of folk science: an illusion of explanatory depth, Cognitive Science, 2002. De vloeiendheid als maat voor begrip is een robuust effect in tientallen jaren onderzoek. ↩
Johnson, M. K., Hashtroudi, S. & Lindsay, D. S., Source monitoring, Psychological Bulletin, 1993. De fundamentele synthese. Het resultaat is de afgelopen jaren gerepliceerd en uitgebreid naar co-auteurschap van mens en AI. ↩