AI-coderen zal expertise belemmeren

"We zien een toekomst waarin intelligentie een nutsvoorziening is zoals elektriciteit of water, en mensen het bij ons per meter kopen en gebruiken voor alles waar ze het voor willen gebruiken." — Sam Altman, OpenAI

In mijn vorige artikel, Agentic Coding is a Trap, besprak ik de "paradox van de bekwame orchestrator". Hierbij zijn de vaardigheden die nodig zijn om AI-agents voor het coderen aan te sturen, precies dezelfde vaardigheden die kunnen afnemen door het voortdurende gebruik van diezelfde AI-agents. Expertise was hierbij grotendeels de differentiator; hoe ervarener een ontwikkelaar is, hoe kleiner de kans op vaardigheidsatrofie, omdat de kennis na jaren van ervaring de kans heeft gehad om te stollen.

Als je nu om je heen kijkt, zie je dat de overgrote meerderheid van de mensen die het meeste voordeel halen uit deze modellen, zij zijn die jaren, zo niet decennia, ervaring in het vak hebben (wat uiteraard voorafgaat aan AI-tooling). En elke veteraan in de industrie zal je hetzelfde vertellen: de basis van deze kennis komt voort uit het daadwerkelijk doen van het werk.

Ontwikkelaars die het vak zijn binnengekomen rond de komst van LLM's bevinden zich in een positie waarin ze niet profiteren van die langdurige ervaring, maar waarin ze worden aangemoedigd (en soms gedwongen) om hun inspanningen te versnellen met behulp van code-assistenten. Juist deze tools vereisen echter een geschiedenis van expertise om ze effectief en verantwoord te kunnen hanteren.

Voor die demografische groep is dit een ongemakkelijke positie; het creëert een scenario waarin een novice over vaardigheden op expertniveau moet beschikken om de tools te kunnen benutten en het tempo in de industrie bij te houden.

De "Expert-Novice"

We sturen mensen in de industrie momenteel zeer tegenstrijdige signalen. Er wordt erin gehamerd dat je "achterblijft" bij je collega's als je geen AI-tools gebruikt. "AI zal je niet vervangen, maar iemand die AI gebruikt wel," is sinds 2023 een mantra.

Tegelijkertijd wordt er echter beweerd dat de manier om de beste resultaten uit deze modellen te halen, is door hoger abstract denkvermogen toe te passen. "Vibe coding" is een doodlopende weg; je moet "hoger in de stack" gaan zitten en robuuste specificaties opstellen, architectureren met goede design patterns en de output altijd nauwgezet controleren, zodat je nooit iets verscheept dat je niet begrijpt.

De vaardigheden om dit te doen zijn echter het resultaat van iemand die in de loop der tijd de wrijving en uitdagingen heeft ervaren die culmineren in "goede smaak".

Dit leidt tot een nieuwe situationele paradox: als deze tools expertise vereisen, maar de tools tegelijkertijd de wrijving kunnen omzeilen die juist die expertise cultiveert, wat is dan het pad om expert te worden zodat men deze tools effectief kan gebruiken?

Zelfvertrouwen zonder begrip

Er is de hoop dat deze modellen het leren zullen versnellen terwijl ze worden gebruikt voor code-generatie. Junior-ontwikkelaars zouden met hetzelfde gewicht en zelfvertrouwen kunnen werken als ervaren rotten, dankzij hun "persoonlijke AI-tutor". Kennis van syntax wordt steeds minder belangrijk, en elke kennisleemte of ambiguïteit wordt opgevuld door de AI-tool. De diepere mechanica van de code blijven geabstraheerd, aangezien de ontwikkelaar hoger in de stack opereert.

JetBrains, een grote speler in developer tools, heeft onlangs een studie voltooid onder junior- en beginnende ontwikkelaars. Ze analyseerden nauwgezet hun individuele gedrag in live coding-sessies en testten hun vermogen om te leren coderen met AI-tooling bij verschillende graden van assistentie. Hun belangrijkste conclusie was stellig en contra-intuïtief:

"Deelnemers dachten dat het was als het hebben van een persoonlijke tutor. Uit de data in ons onderzoek ... zagen we dat ze GenAI-tools in feite niet als een persoonlijke tutor gebruikten. Sterker nog, het tegendeel was waar."

De deelnemers die zwaar leunden op AI-assistentie:

• Sloegen vaak cruciale planningsfasen over, omdat ze ontdekten dat Copilot dit voor hen had gedaan in plaats van dat ze er zelf over hadden nagedacht.
• Eindigden met een "illusie van competentie" in plaats van echt begrip.

Daartegenover stonden de deelnemers die hun gebruik van AI beperkten:

• Slaagden omdat ze "negatieve expertise" hadden ontwikkeld — het vermogen om incorrecte of onbehulpzame GenAI-suggesties te negeren — waardoor ze zich konden concentreren op het schrijven van hun eigen oplossingen in plaats van zich te laten misleiden.
• Waren in staat om GenAI te gebruiken om te versnellen, waarbij ze code creëerden die ze al van plan waren te maken.

De beginnende ontwikkelaars die het meest onbeperkt en zelfverzekerd AI gebruikten, "hadden cruciale stappen in het probleemoplossingsproces van programmeren overgeslagen en waren nu verloren."

Het is dan ook niet verrassend dat de beginnende ontwikkelaars die het beste presteerden, degenen waren die AI-codeassistentie sterk beperkten of volledig negeerden.

Omgekeerd leren

Door de zelfgestuurde aard van LLM's geldt: hoe meer ervaring je hebt, hoe meer voordeel ze bieden, omdat je de output nauwkeurig kunt sturen, controleren en verifiëren. Hoe minder kennis je hebt, hoe meer ze je kunnen misleiden. Interactie met LLM's om nieuwe vaardigheden te leren neemt de vorm aan van een "omgekeerd leermodel"; een rolomkering waarbij de student aanvankelijk de mentor stuurt, de mentor reageert, en de student vervolgens de mentor opnieuw stuurt.

Dit proces is precair; LLM's zijn ongelooflijk gevoelig voor de vorm van de prompt. Wanneer je nieuwe domeinen verkent, weet je niet wat je niet weet, en het meegaande ontwerp van een LLM kan je doen geloven dat je meer weet dan je in werkelijkheid doet.

Als je terrein verkent dat zelfs maar enigszins onbekend is, weet je vaak niet eens welke vragen je moet stellen om het model naar de beste antwoorden te leiden. Het begint te voelen als een kompas dat altijd naar het noorden wijst, ongeacht waar jij suggereert dat het noorden is.

Uit dezelfde JetBrains-studie bleek dat zelfs de best voorbereide studenten werden ontspoord door de AI-assistentie vanwege dit type leermodel. Eén deelnemer toonde goede fundamentele planning en gewoonten, maar "sloeg plotseling cruciale probleemoplossende planningsfasen over, sprong direct naar het coderen en werd door Copilot verleid om snel code te produceren," om vervolgens op de LLM te moeten vertrouwen om de fout te herstellen die de LLM in eerste instantie had geïntroduceerd.

AI-modellen missen oordeelsvermogen, empathie en pedagogische intentie. De geboden oplossingen zijn niet geworteld in ervaring, maar in patronen in de trainingsdata (LLM's zijn in essentie ongelooflijk complexe patroon-interpolatoren).

De oneindige antwoordenmachine is verleidelijk en staat erom bekend verslavend te zijn. Het kan snel ontsporen, vooral voor onervaren ontwikkelaars. Zodra je diep genoeg in een gegenereerde oplossing zit, ben je vaak afhankelijk van de AI-tool om de klus ook af te maken, waardoor de wrijving bij het oplossen van problemen wordt omzeild die nodig is voor de vorming van een mentaal model (en om eerlijk te zijn, senior ontwikkelaars zijn hier ook gevoelig voor).

Wrijving is een feature

Expertise en meesterschap ontstaan niet puur door observatie en dialoog, maar door ervaring, herhaling en vallen en opstaan; je moet falen om te slagen. Als ik wilde leren koken, zou ik een Master Chef kunnen kijken werken en eindeloos vragen kunnen stellen. Na een maand zou ik in staat zijn om de perfecte medium-rare ribeye te beschrijven, maar ik zou nooit weten hoe het is om er een te bakken, en ik zou hem bij mijn eerste poging bijna zeker overbakken.

Coderen kent eindeloze momenten van het opsporen van obscure fouten zonder logbestand ter hulp, het ervaren van subtiele prestatieverschillen tussen bepaalde methoden, of het moeten herschrijven van een aanpak wanneer duidelijk wordt dat deze niet schaalbaar is.

Deze toegepaste wrijving is precies wat "ontwikkelaarsintuïtie" (of "smaak") opbouwt. De Duitsers hebben hier een prachtig woord voor: Fingerspitzengefühl. Het is het spiergeheugen dat wordt geactiveerd wanneer een ontwikkelaar naar iets kijkt en denkt: "ja... dit gaat waarschijnlijk problemen veroorzaken." Door de mechanica van de worsteling te vermijden, wordt deze intuïtie nooit opgebouwd.

In een grootschalige studie uit 2025 van UPenn, Generative AI without guardrails can harm learning, volgden onderzoekers 1.000 studenten die een LLM gebruikten om wiskunde te leren. Ze ontdekten dat studenten AI als kruk gebruikten en uiteindelijk 17% slechter presteerden dan studenten met enkel een tekstboek (en net als in de JetBrains-studie dachten de studenten die AI gebruikten dat ze uitblonken).

LLM's hoeven echter niet alleen code te genereren.

Wanneer ze worden ingezet als Socratische sparringpartners in plaats van antwoordgeneratoren, tonen studies aan dat "dialogische AI-systemen reflectief, kritisch en onafhankelijk denken zinvol kunnen stimuleren".

In diezelfde UPenn-studie testten ze ook een "Tutor"-versie waarbij studenten om hulp vroegen en vervolgens het probleem onafhankelijk oplosten. De GPT-Tutor-groep presteerde verbazingwekkend genoeg 127% beter in de AI-ondersteunde oefensessie (hoewel ze, interessant genoeg, ongeveer hetzelfde scoorden op de toets als de tekstboekgroep).

Dit is effectief omdat het model niet langer wordt gebruikt als productiemiddel, waardoor het cognitieve werk terugverschuift naar het individu. Het is wanneer de wrijving nog aanwezig is, dat er een blijvende indruk ontstaat die leidt tot expertise.

Een studie van Anthropic uit 2026, How AI assistance impacts the formation of coding skills, kwam tot soortgelijke conclusies:

"Voor beginnende werknemers in software engineering of enige andere industrie, kan onze studie worden gezien als een klein bewijs voor de waarde van bewuste vaardigheidsontwikkeling met AI-tools. Cognitieve inspanning — en zelfs het pijnlijk vastlopen — is waarschijnlijk belangrijk voor het bevorderen van meesterschap."

Er schuilt een zekere ironie in: het meest productieve leren dat kan plaatsvinden met een AI-codingtool, is wanneer deze bijna niet wordt gebruikt om code te genereren.

Ineenstorting van de pipeline

Als LLM's code kunnen schrijven en debuggen, en agentische workflows systeemontwerp kunnen uitvoeren op basis van de overvloed aan patronen in de trainingsdata, wat is dan nog het doel van deze kennis? Programmeren zal volledig in natuurlijke taal gebeuren, en we kunnen het contact met de code loslaten omdat de modellen blijven verbeteren en elke kennisleemte of ambiguïteit opvullen. Ze zullen eventuele problemen debuggen en de complexiteit die ze zelf introduceren beheren.

De weddenschap van biljoenen dollars is: deze kennis zal niet meer uitmaken, omdat LLM's het gat opvullen en effectief de nieuwe generatie "ontwikkelaars" worden. Dit begint te doen denken aan de hoogmoed die eerdere no-code bewegingen en de dagdromen van CEO's dreef, in plaats van de realiteit op de werkvloer.

Coderen/programmeren/software is een unieke kruising van logica, wiskunde, probleemoplossing, kritisch denken, planning, communicatie en creativiteit. LLM's kunnen patronen detecteren op een schaal die geen mens ooit zou kunnen, maar patronen brengen je maar tot op zekere hoogte.

David Cramer, mede-oprichter van Sentry, verwoordde dit bondig in een recent interview:

"Ik denk dat er een type persoon is ... dat inherent gelooft dat LLM's genoeg zullen verbeteren om dit spul later terug te gaan repareren, dat het in staat zal zijn om alle troep die onderweg is opgestapeld op te ruimen. Ik denk niet dat dat waar is. Ik denk dat het een wetenschappelijk experiment is. Je wilt pronken dat je al je code kunt genereren en honderden dingen parallel kunt laten lopen; ik zal pronken door je te laten zien hoe kapot de code 100% van de tijd is."

Zal de pipeline instorten, of simpelweg veranderen?

Dat hangt er echt vanaf of we de nodige verschuiving maken naar een meer pedagogisch gebruik van deze systemen. Door te blijven focussen op en het promoten van AI-coding workflows die code-generatie prioriteren boven diepgaand begrip, kweken we niet de volgende generatie experts die de code die vandaag wordt gecreëerd, moeten erven.

Mijn aanpak: Eerst de wrijving

Joel Spolsky schrijft profetisch (al in 2002) in zijn Law of Leaky Abstractions:

"Code-generatietools die doen alsof ze iets abstraheren, lekken, net als alle abstracties. En de enige manier om competent met die lekken om te gaan, is door te leren hoe de abstracties werken ... abstracties besparen ons tijd bij het werken, maar ze besparen ons geen tijd bij het leren."

LLM's kunnen worden beschouwd als de ultieme lekkende abstractie.

Mijn advies is hier zeer vergelijkbaar met mijn eerdere voorschrift: als een ontwikkelaar een expert wil worden in programmeren, moet hij de pure code-generatiecapaciteiten van deze modellen grotendeels negeren en ze in plaats daarvan gebruiken voor interactieve documentatie, dynamische tutorial-generatoren en Socratische oefeningen.

Dit is natuurlijk geen wondermiddel: het gebruik van een AI-tool als tutor brengt eigen risico's met zich mee, aangezien het vatbaar is voor dezelfde hallucinaties als elke andere interactie, en het kan niet als enige leerbron worden gebruikt. Als je de nauwkeurigheid van de gegenereerde code niet correct kunt controleren, kun je ook de nauwkeurigheid van het gegenereerde concept niet controleren. Als je AI als mentor gebruikt, moet je de output nog steeds verifiëren aan de hand van officiële documentatie, menselijke collega's en feitelijk vallen en opstaan.

"Coderen is eigenlijk een geweldige manier om begrip te cementeren. Hoe meer je programmeert, hoe meer je het domein begrijpt waarin je werkt." — Kent Beck, creator van Test-Driven Development

Het kiezen van dit langzamere, meer bewuste pad is de beste manier om expertise op te bouwen, maar ik ben me ervan bewust hoe moeilijk dat is wanneer het omliggende ecosysteem actief tegenwerkt. AI wordt (vaak roekeloos) opgelegd in bedrijven en is ingebouwd in de meeste software-ontwikkelingstools en IDE's. Sommige bedrijven dwingen ontwikkelaars zelfs om AI te gebruiken voor alle coding-taken, ongeacht het ervaringsniveau; deze bedrijven zullen hun eigen lessen moeten leren.

Voor iedereen die een balans zoekt tussen diepgaand leren en productiviteit, zijn er kwalificerende vragen die je jezelf kunt stellen om ervoor te zorgen dat het gebruik van deze tools langetermijnvoordelen oplevert.

Mijn AI-assistentie checklist:

• Zou ik deze taak nog steeds kunnen volbrengen als ik geen toegang had tot een AI-tool?
• Gebruik ik het model om mijn begrip te verdiepen, of om het antwoord te versnellen?
• Als ik de gegenereerde output moest controleren en verifiëren, zou ik dan adequaat kunnen uitleggen wat er gebeurde?
• Als ik een nieuw concept leer, heb ik dan voldoende onderzoek gedaan om te weten welke vragen ik moet stellen?
• Heb ik de aanpak gecrossreferenced en geverifieerd via andere methoden (documentatie lezen, standaard zoektools, StackOverflow, Reddit)?
• Is dit een echt routinematige taak die al 100 keer is gedaan, of een taak die ergens in het proces executieve besluitvorming vereist?

Zelfs als ontwikkelaar met decennia aan ervaring, raadpleeg ik ze nog steeds constant in mijn dagelijkse werk, vooral wanneer ik iets nieuws probeer te leren (wat in dit vak nooit eindigt).

De sleutel is het herkennen van het verschil tussen cognitieve schuld en cognitieve ontlasting: cognitieve schuld is het afstaan van je oordeel en beslissingen, terwijl cognitieve ontlasting het delegeren van het mechanische of saaie werk is.

Zoals de Anthropic-studie vermeldde, is "pijnlijk vastlopen" een goed ding. Het vereist discipline en inspanning om niet terug te glijden naar het simpelweg genereren van antwoorden, die bovendien niet eens nauwkeurig hoeven te zijn. LLM's hebben de fundamenten van hoe we leren niet plotseling herschreven, maar ze hebben ons wel een nieuwe manier gegeven om dat te doen.

Intelligentie is geen handelswaar

De heroriëntatie die ik in de komende jaren hoop te zien, is het inzicht dat vaardigheden zich niet ontwikkelen zonder actieve participatie. Je moet direct en continu betrokken zijn om de essentiële wrijving te ervaren die culmineert in expertise (zelfs als dat betekent dat je langzamer gaat).

Als we gefixeerd blijven op regels code en verbruikte tokens terwijl de expertise-pipeline in de loop der jaren opdroogt, zou Sam Altmans visie om intelligentie per meter aan ons terug te verkopen werkelijkheid kunnen worden. Domeinkennis zou zeer schaars worden, en wie zich neerzet voor ontwikkelingswerk, zal een gevoel van verlamming ervaren als die persoon geen actief AI-tool-abonnement aan zijn zijde heeft.

"LLM's zijn een statische database van vaardigheden. Het zijn interpolatie-engines. Software engineering is echter een oefening in adaptatie en het oplossen van nieuwe problemen. Je kunt je niet door een volledig unieke systeemfout interpoleren." — François Chollet, creator van ARC-AGI Benchmark