dAInosaur

The Dainosaur – Hoofdstuk 1

Waarom een dinosaurus over AI schrijft

Ik ben op 1 juli 1999 begonnen met werken in de IT. Daardoor heb ik daadwerkelijk op oudejaarsavond 1999 bij een bank op locatie gezeten als onderdeel van een rapid response-team voor de Millennium Bug. Gelukkig hadden we die nacht niets te doen. Waarom zou ik dan een blogreeks als deze beginnen? Niet om op te scheppen. Het is context voor alles wat hierna volgt. Het betekent dat ik de dotcom-boom én de crash heb meegemaakt, ERP-implementaties die fortuinen kostten en middelmatige resultaten opleverden, SOA, microservices, de cloud en agile-transformaties die er op de een of andere manier voor zorgden dat goede engineers de helft van hun week besteedden aan vergaderingen over vergaderingen. Elk van die golven kwam met een stapel whitepapers, een conferentie-keynote met een hockey-stick-grafiek en een leger consultants dat klaarstond om je de toekomst te verkopen. Mijn littekenweefsel heeft inmiddels zelf littekenweefsel. En dat levert iets nuttigs op: een uiterst gevoelige onzin-detector.

Toen AI mainstream begon te worden, was mijn eerste reactie daarom niet verwondering. Het was afwachten. Meer specifiek: laten we eerst eens zien wat dit ding daadwerkelijk kan voordat ik enthousiast word. Want ik had een referentiekader. Jaren aan moeizaam opgebouwde ervaring, patronen die zijn ingesleten door echte projecten, het soort intuïtie dat je alleen ontwikkelt door beslissingen te nemen, te zien hoe ze uitpakken en vervolgens met de gevolgen te leven. Ik dacht oprecht – en ik ben hier eerlijk over – dat geen enkel taalmodel daarbij in de buurt zou komen. Een senior architect met een carrière vol ervaring en instinct tegenover een bijzonder zelfverzekerde tekstgenerator? Ik wist waar ik mijn geld op zou inzetten.

Maar ik had ongelijk. Meer ongelijk dan ik had verwacht, en op manieren die ik niet had zien aankomen. Die verschuiving van scepticus naar iemand die inmiddels volledig inzet op AI is waar ik over wil schrijven. Verwacht dus geen tutorials, geen “top 5 prompts voor architecten”, geen benchmarks, toolvergelijkingen of screenshots van iets dat me afgelopen dinsdag heeft verbaasd. Daar is al meer dan genoeg content over beschikbaar, en een deel daarvan is oprecht goed.

Ik wil het hebben over de daadwerkelijke ervaring van het inzetten van AI in serieus werk op senior niveau: de frictie, niet de functionaliteiten. De momenten waarop het helpt op manieren die je niet had verwacht, en de momenten waarop het je met groot zelfvertrouwen een compleet verkeerde kant op stuurt. De vraag wat je vertrouwt en wat je controleert, en hoe dat verandert wanneer je je professionele identiteit jarenlang hebt opgebouwd rondom het kennen van de antwoorden. Wat gebeurt er met je vakmanschap wanneer een tool ineens delen daarvan begint uit te voeren? Wanneer maakt ervaring je beter in het gebruik van AI, en wanneer maakt diezelfde ervaring je juist trager in het aanpassen aan verandering? Dit zijn geen theoretische vragen. Ze komen voorbij in echte opdrachten, echte beslissingen en in die stille momenten aan het einde van een werkdag waarop je jezelf afvraagt of je vandaag daadwerkelijk iets hebt toegevoegd, of slechts een bijzonder dure autocomplete hebt aangestuurd.

Ik schrijf dit voor mensen die niet nieuw zijn in deze industrie. Als je net begint: welkom! Maar ik ga ervan uit dat je een referentiekader hebt dat is opgebouwd uit jaren ervaring, het ontwikkelen van intuïtie en het meemaken van mislukkingen op manieren die niemand had voorspeld. Architecten, senior engineers en consultants met sterke meningen én voldoende zelfreflectie om die ter discussie te stellen. Mensen die door een verkooppraatje heen prikken, maar toch nieuwsgierig blijven naar wat erachter zit. Mensen die daadwerkelijk iets te verliezen hebben in hoe dit zich ontwikkelt. Niet alleen hun carrière, maar ook hun vak. Herken je jezelf in die beschrijving, blijf dan vooral lezen.

Hoewel jonge professionals niet de primaire doelgroep van deze reeks zijn, werk ik juist vaak met mensen die net de industrie binnenkomen, en daar haal ik veel plezier uit. Zij kijken anders naar dingen. Ze stellen vragen die ik jaren geleden ben gestopt met stellen, en vaak hebben ze daar volledig gelijk in. Een van mijn motto’s is: “Je kunt altijd en van iedereen iets nieuws leren.” Dat meen ik oprecht. De keerzijde is dat ik de meeste fouten die zij nog gaan maken zelf al een keer heb gemaakt. Ik weet hoe sommige van die verhalen aflopen. Die combinatie van openheid voor nieuwe ideeën en patronen die zijn opgebouwd door ervaring maakt een senior professional daadwerkelijk waardevol in plaats van alleen duur.

Als ik naar mezelf kijk binnen dat geheel, gevormd door jaren aan beslissingen en de gevolgen daarvan, dan herken ik de dinosaurus. Niet als belediging, maar als een eerlijke beschrijving. Ik ben ouder dan het grootste deel van de technologie waarop we vandaag draaien, maar tegelijkertijd volledig overtuigd van de waarde van AI. Vandaar de titel: The Dainosaur. Dinosaur, AI, samengevoegd tot één woord. De woordspeling spreekt voor zich.

Mijn doel is om meedogenloos eerlijk te zijn over mijn reis richting AI: de twijfel, de weerstand en de momenten waarop ik vol vertrouwen ergens van overtuigd was en vervolgens ontdekte dat ik ernaast zat. Als jij momenteel vastloopt, AI actief afwijst of ergens in dat ongemakkelijke middengebied zit waarin je voelt dat het misschien echt iets is, maar je nog niet volledig kunt instappen: ik ben daar geweest. Ik herken die worsteling. En ik ga je niet vertellen dat het eenvoudig was of dat die twijfels onzinnig waren. Dat waren ze niet. Maar ik heb uiteindelijk wel de sprong gemaakt, en ik ben vandaag oprecht productiever dan daarvoor. Niet doordat ik alles wat ik in tientallen jaren heb opgebouwd heb weggegooid en vervangen door AI, maar doordat ik beide heb gecombineerd. De ervaring en de intuïtie blijven. AI versterkt het werk; het vervangt niet de persoon die het werk uitvoert. Dat onderscheid is belangrijk voor mij, en ik vermoed dat het voor jou ook belangrijk is.

 

The Dainosaur – Hoofdstuk 2

De teugels loslaten

Mijn eerste serieuze ervaring met AI-ondersteuning was prima. Niet baanbrekend, niet teleurstellend. Gewoon prima. Het deed dingen. Soms waren die dingen nuttig. Soms zaten ze dicht tegen nuttig aan, maar was er nog behoorlijk wat opschoning nodig. De output was competent genoeg om serieus te nemen en tegelijkertijd onvoorspelbaar genoeg om me nerveus te maken. En die nervositeit had een heel specifieke oorzaak: ik kon niet goed bepalen hoe ik de controle moest houden.

Dat is geen klein ding voor iemand die jarenlang van controle een professionele deugd heeft gemaakt. Wanneer ik zeg dat ik jarenlang volgens best practices heb gewerkt, dan bedoel ik dat letterlijk. Patronen, principes en structuur zijn de hulpmiddelen waar ik naar grijp wanneer complexiteit dreigt te veranderen in chaos. Ik heb uitgesproken opvattingen over lagen in een architectuur, over verantwoordelijkheden, naamgevingsconventies en over waarom je absoluut geen businesslogica in je UI-componenten stopt. Dat is geen starheid; dat is discipline die is ontstaan door te zien wat er gebeurt wanneer mensen die principes negeren.

Toen ik serieus met AI ging werken, was mijn instinct daarom hetzelfde als bij elk ander complex systeem: ik moet de regels begrijpen, ik moet weten wat ik kan verwachten en ik moet de output kunnen beheersen. En daar zit precies het probleem. AI is niet deterministisch. Dezelfde input kan verschillende resultaten opleveren. Dat is geen bug waarvoor ik een supportticket kan aanmaken. Zo werkt het systeem nu eenmaal, en daar moeten we mee leren omgaan.

Ik zal eerlijk zijn over hoeveel moeite ik daarmee had. Niet lang, maar wel oprecht. Het voelde alsof ik een deel van mijn werk overdroeg aan iets dat alle kanten op kon gaan. Je zet een doel uit, verwacht een bepaalde route en krijgt vervolgens een bijzonder zelfverzekerde “collega” die een compleet andere weg kiest en soms uitkomt op een bestemming waar je helemaal niet naartoe wilde. Elke senior architect heeft wel een verhaal over een junior die het juiste probleem oploste op volledig de verkeerde manier. Je weet precies welke gezichtsuitdrukking daarbij hoort. Dat was een tijdlang mijn interne gezichtsuitdrukking.

Wat uiteindelijk veranderde, was geen enkel groot inzicht of specifiek moment. Het was een optelsom van ervaringen. Hoe meer ik met AI-agents werkte aan echte taken, met echte belangen en echte consequenties, hoe vaker ik iets begon op te merken waar ik niet naar op zoek was geweest. Die niet-deterministische aard produceerde niet alleen fouten. Ze produceerde ook nieuwe invalshoeken. Benaderingen waar ik zelf niet aan had gedacht. Vragen over requirements die ik in mijn hoofd al had afgevinkt. Oplossingen die werkten, maar via een route tot stand kwamen die ik zelf nooit zou hebben gekozen, omdat mijn ervaring me had geleerd dat die route een doodlopende weg was.

Soms had mijn ervaring gelijk en zat de agent ernaast. Maar soms had ik een optie uitgesloten op basis van aannames die inmiddels niet meer klopten, terwijl de agent die aannames simpelweg niet had geërfd. Die keek anders naar het probleem.

Dat woord – kijken – markeert achteraf een belangrijke verschuiving in mijn denken. Ik gebruikte het niet bewust. Het verscheen vanzelf. En toen ik het opmerkte, besefte ik dat er iets was veranderd in de manier waarop ik met AI omging. Ik was de AI-agent gaan zien als iets dat naar het probleem keek. Niet als een gereedschap dat instructies uitvoerde. Niet als een paard dat ik moest africhten en strak aan de teugels moest houden om niet uit het zadel geworpen te worden. Maar als een perspectief. Een virtuele collega met brede context, andere instincten en zonder het littekenweefsel dat mij snel maakt, maar me soms ook blind maakt.

Dat is de collega die de voor de hand liggende vraag stelt die jij al jaren niet meer stelt, omdat je denkt het antwoord al te kennen. Alleen blijkt soms dat je dat antwoord helemaal niet kent, of dat de context inmiddels veranderd is.

Voor de duidelijkheid: ik vermenselijk AI niet. Ik weet heel goed wat het is. Het leeft niet, het heeft geen meningen en het ligt ’s nachts niet wakker van mijn architectuurproblemen. Maar wanneer ik diep in een flow zit en de interactie goed werkt, dan lijkt de functionele ervaring sterk op samenwerken. Dat is simpelweg de eerlijkste beschrijving. Het een “collega” noemen is geen overtuiging; het is het woord dat het dichtst in de buurt komt van hoe de interactie voelt wanneer alles goed loopt. Ik ben gestopt met me daartegen te verzetten.

Er is nog een andere rol waarin AI terecht is gekomen, een rol die ik nooit had voorspeld: die van rubber duck.

Senior engineers kennen het principe. Je legt een probleem hardop uit aan een levenloos object en juist door het uit te leggen wordt de oplossing zichtbaar. De eend zegt niets terug. Dat hoeft ook niet.

De AI-rubber-duck reageert wél. Dat maakt hem tegelijkertijd nuttiger én minder nuttig, afhankelijk van wat je nodig hebt. Wanneer de reactie slecht is, negeer ik die. Wanneer de reactie goed is, steel ik het idee en bouw ik daarop verder. Hoe dan ook blijft hetzelfde gelden: het helder formuleren van een probleem zodat een ander ermee aan de slag kan, is vaak al de helft van het werk.

Dat is geen nieuwe wijsheid. Het blijkt alleen dat AI een bijzonder betrokken rubber duck is.

Ik zeg niet dat de agent altijd gelijk heeft. Dat heeft hij niet. Hij zit met een mate van zelfvertrouwen fout die een mens waarschijnlijk zijn baan zou kosten. Ik controleer nog steeds. Ik stel nog steeds kritische vragen. Ik gebruik nog steeds dezelfde professionele instincten die ik zou toepassen op het werk van iedere collega.

Alleen gebruik ik ze tegenwoordig anders.

Ik benader AI zoals ik een slimme collega benader van wie ik het oordeel respecteer, maar van wie ik de blinde vlekken heb leren herkennen. Niet zoals ik een proces probeer te beheersen dat binnen strikte grenzen moet blijven.

Dat verschil is in de praktijk enorm belangrijk.

De persoon die probeert het paard te temmen, is voortdurend in gevecht met het dier. De persoon die samenwerkt met een vaardige maar eigenzinnige collega, voert een gesprek.

De situatie is hetzelfde. Het resultaat totaal anders.

Jarenlange ervaring gecombineerd met een hulpmiddel dat een brede blik heeft en geen geërfde aannames kent, blijkt een verrassend sterke combinatie. Mijn ervaring vertelt me welke oplossingen eerder hebben gefaald en waarom. De agent komt met opties die ik zelf niet had bedacht, legt requirements bloot die ik had gemist en zegt af en toe iets dat in eerste instantie onjuist klinkt, totdat ik er tien seconden over nadenk en besef dat het niet fout is – alleen anders dan hoe ik het zelf zou hebben geformuleerd.

Die combinatie is oprecht waardevol. Niet op een manier van: “Wauw, AI is geweldig.” Maar op een manier van: “Dit maakt me beter in het daadwerkelijke werk.”

En dat is, wat mij betreft, de enige vorm van nuttigheid die er echt toe doet.

The Dainosaur – Hoofdstuk 3

Context is het vakmanschap

Voordat ik zelf serieus met AI aan de slag ging, keek ik vooral toe. Een collega die een agentische workflow demonstreerde, een paar YouTube-video’s van mensen die indrukwekkende dingen deden met AI. Mijn reactie was niet meteen: “Dit heb ik nodig!” Het leek meer op lichte paniek. Niet de dramatische variant. Meer de stille variant die je gevoel van competentie uitdaagt. Het soort gevoel dat je krijgt wanneer je een ruimte binnenloopt en merkt dat iedereen iets lijkt te begrijpen wat jij nog niet begrijpt. Je staat op het punt iets nieuws te leren.

Het speelveld leek enorm. Overal waren modellen: verschillende aanbieders, verschillende formaten, verschillende afwegingen, nieuwe releases om de paar weken. Er waren tools, LLM’s, agents, sub-agents, skills, frameworks, orchestratielagen, prompt-engineeringgidsen, RAG-architecturen, system prompts, regels, hooks, MCP-servers, agent-teams, enzovoort. En sinds ik dit schrijf zijn er waarschijnlijk alweer nieuwe dingen bijgekomen. Mensen op internet hadden overal uitgesproken meningen over. Voor elk onderdeel bestond wel een YouTube-tutorial, gevolgd door een tweede video die uitlegde waarom de eerste inmiddels achterhaald was. Het voelde alsof ik aan een tweede carrière moest beginnen. En ik heb er al één.

De impliciete boodschap leek te zijn dat je dit allemaal moest begrijpen voordat je er iets nuttigs mee kon doen. Dat productief werken met AI betekende dat je eerst het volledige ecosysteem moest beheersen. Voor iemand die is opgegroeid in een tijd waarin het adopteren van een nieuwe tool meestal neerkwam op één keer de handleiding lezen en daarna gewoon aan de slag gaan, voelde dat buiten proportie. De investering leek groter dan de opbrengst nog voordat je was begonnen. Dat patroon had ik eerder gezien in de industrie. Meestal betekent het dat een ecosysteem nog niet volwassen is. Dus ik parkeerde het in die categorie en wachtte af.

Wat ik uiteindelijk ontdekte, door ermee te werken in plaats van ernaar te kijken, is dat de instapdrempel veel lager ligt dan vaak wordt voorgesteld. Niet nul, maar de YouTube-rabbithole is een slechte graadmeter voor wat daadwerkelijk belangrijk is. De modellen, de tools en de frameworks bestaan inderdaad, en ze verschillen ook echt van elkaar. Maar dat is niet de beperkende factor.

De beperkende factor is iets veel vertrouwders.

Context, instructies, duidelijkheid over wat je wilt, wat je niet wilt, welke regels gelden en wat een goed resultaat precies inhoudt. De AI kent jouw probleem niet. Ze kent je beperkingen niet. Ze weet niet welke beslissingen al genomen zijn en welke nog openstaan. Ze weet niet wat voor jou betekent dat iets “af” is. Als je dat niet expliciet, volledig en voldoende gestructureerd uitlegt, krijg je een generiek antwoord op een generieke versie van je probleem. Dat is prima wanneer je een generiek probleem hebt. Maar meestal hebben we die niet.

Dat is geen openbaring over AI. Het is een openbaring over communicatie. De mensen die het meeste uit AI halen, zijn niet per se degenen die de meeste LLM’s kennen of de beste toolstack hebben. Het zijn de mensen die precies genoeg kunnen verwoorden wat ze nodig hebben, zodat een intelligent systeem er daadwerkelijk mee aan de slag kan. Dat is een andere vaardigheid. En tot mijn verrassing bleek ik die grotendeels al te bezitten dankzij mijn ervaring.

Ik ben van nature en uit overtuiging georganiseerd. Ik documenteer beslissingen. Ik schrijf niet alleen op wat er gekozen is, maar ook waarom, welke alternatieven zijn overwogen en afgewezen en welke aannames een rol spelen. Wanneer ik aan een systeem werk, laat ik een spoor achter. Niet omdat iemand dat van mij verlangt, maar omdat ik genoeg ongedocumenteerde rommel heb moeten opruimen om te weten wat het alternatief kost. Arc42 is mijn favoriete template voor softwarearchitectuurdocumentatie: gestructureerd, volledig en expliciet over context, beperkingen en kwaliteitsdoelen. Sommige mensen vinden het zwaar. Ik vind het verhelderend. Het invullen van het template dwingt je om onder ogen te zien wat je eigenlijk nog niet weet.

Werken met AI heeft al die gewoontes versterkt en me scherper gemaakt op waarom ze belangrijk zijn. Een goed geschreven context – wat ik tegenwoordig een system prompt of instructieset voor een agent zou noemen – is in wezen exact dezelfde discipline. Hier is het domein. Hier is het doel. Hier zijn de beperkingen. Dit vind ik belangrijk en dit niet. Dit ziet eruit als een goed resultaat en dit diskwalificeert een resultaat. Hoe beter je dat opschrijft, hoe beter de output. Niet een beetje beter. Dramatisch beter. Het verschil tussen een nuttig antwoord en een antwoord dat je tijd en tokens verspilt, is vrijwel altijd terug te voeren op wat je de AI hebt meegegeven om mee te werken.

Ik ben de term context engineering gaan gebruiken, omdat het daadwerkelijk engineering is. Het is niet prompten in de informele betekenis van het woord: een vraag stellen en kijken wat er terugkomt. Het is een doelbewuste manier van werken waarbij je de informatieomgeving ontwerpt waarin de AI opereert. Skills, instructies, beperkingen, voorbeelden en outputformaten vormen samen de architectuur. Het model zelf is slechts de runtime. De meeste mensen besteden hun energie aan het kiezen van de runtime. De mensen die serieuze resultaten behalen, ontwerpen de architectuur.

Er loopt een directe lijn van jarenlang duidelijke architectuurdocumenten schrijven naar hier goed in zijn. Hetzelfde instinct dat ervoor zorgt dat je documenteert waarom je een event-driven aanpak hebt afgewezen, omdat iemand daar over zes maanden opnieuw naar gaat vragen en jij het dan niet meer weet, zorgt er ook voor dat je een agent duidelijke instructies geeft in plaats van hem alles te laten afleiden uit impliciete aannames, tenzij je bewust wilt experimenteren. Dezelfde discipline die ervoor zorgt dat je Arc42-documentatie actueel houdt, zorgt er ook voor dat je contextbestanden onderhoudt wanneer een project zich ontwikkelt. Dit zijn geen nieuwe vaardigheden verpakt in nieuwe terminologie. Het zijn dezelfde vaardigheden, toegepast op een nieuw oppervlak.

Maar het beheersen van de input alleen is niet genoeg. Je moet ook de output beheersen die de AI produceert. Net zoals je in een team code reviews uitvoert op het werk van collega’s. Als je daar onvoldoende aandacht aan besteedt, betaal je uiteindelijk een prijs die gemakkelijk onzichtbaar blijft totdat je hem voelt. Wanneer de output goed is en het tempo hoog ligt, ontstaat de verleiding om te accepteren en door te gaan. De review wordt een snelle scan. Die scan wordt een vluchtige blik. En voordat je het weet, zet je dingen naar productie die je eigenlijk nooit echt hebt gecontroleerd of begrepen.

Dat probleem is niet uniek voor AI. Het gebeurt ook wanneer mensen code kopiëren van Stack Overflow, code van collega’s overnemen of open-sourcebibliotheken gebruiken zonder ze daadwerkelijk te bekijken. AI maakt het alleen moeilijker om kritisch te blijven, omdat de output er verzorgd uitziet en meestal correct genoeg is om een oppervlakkige inspectie te doorstaan. Het risico is niet dat AI ongelijk heeft. Het risico is dat jij ophoudt de persoon te zijn die kan herkennen wanneer dat zo is. Veelvuldig gebruik van AI zonder kritisch na te denken over wat het produceert, kan ongemerkt de redeneervaardigheden aantasten die een senior professional juist waardevol maken. Dat soort achteruitgang merk je pas wanneer je die vaardigheden nodig hebt en ontdekt dat ze zijn verzwakt. Blijf dus oefenen. Blijf grondig reviewen. Niet alleen als kwaliteitscontrole, maar als discipline. Een oplossing kritisch lezen, aannames ter discussie stellen, herkennen wat ontbreekt of wat beter kan: dat blijft leren. Het tempo verandert misschien, maar de verantwoordelijkheid niet.

De mensen die volgens mij het meest worstelen met AI, worstelen niet omdat de technologie ingewikkeld is. Ze worstelen omdat ze nooit expliciet hebben hoeven maken wat ze normaal impliciet laten. Ervaren professionals beschikken vaak over de meeste impliciete kennis en hebben daardoor ook het meeste te winnen bij het leren zichtbaar maken ervan. Dat is het echte werk. Niet leren welk model deze week bovenaan een benchmark staat, maar leren om helder en volledig te formuleren wat je daadwerkelijk nodig hebt.

De instapdrempel blijkt uiteindelijk vooral betaald te worden in duidelijkheid. En dat is een valuta die ik al jarenlang aan het opbouwen ben.

The Dainosaur – Hoofdstuk 4

De ruisvloer

The Dainosaur – Hoofdstuk 5

Vol erin, met open ogen

Ik wil deze reeks afsluiten door te delen hoe ik AI tegenwoordig in de praktijk gebruik. Geen demo, geen use case van een conferentieslide, maar de werkelijke invulling van een werkdag waarin AI onderdeel is van het proces.

Uiteraard gebruik ik het voor programmeren. Specificaties, tests, implementaties, het volledige spectrum. Ik gebruik het voor het schrijven van documentatie over bestaande en nieuwe systemen, wat een van de meest onderschatte toepassingen blijkt te zijn zodra je beseft hoeveel documentatie nooit wordt geschreven omdat “het te veel tijd kost” of “toch niemand het gaat lezen”. Overigens leest AI de architectuurprincipes en beperkingen die je meegeeft daadwerkelijk en past ze toe waar nodig – een droom voor iedere architect. Ik gebruik het wanneer ik systemen beoordeel die ik nog niet eerder heb gezien: geef het de codebase, stel de juiste vragen en je kunt sneller dan met welke andere methode dan ook een werkbaar begrip opbouwen van de architectuur, technische schuld en verborgen aannames van een systeem. Ik gebruik het voor moderniseringstrajecten: het opstellen van een verdedigbare roadmap voor bestaande systemen en het bepalen hoe je daar komt zonder alles af te breken en opnieuw te beginnen. Ik gebruik het als een tweede brein om georganiseerd te blijven. Ik gebruik het voor het maken van outlines, visuals en presentaties voor conferenties. Ik gebruik het ook voor nevenprojecten. Voor greenfield-ontwikkeling, brownfield-herschrijvingen en migraties naar volledig andere technologiestacks. Daar kom ik later nog op terug.

Mijn belangrijkste tools op dit moment zijn Claude Code (via de CLI en de VS Code-plugin) en GitHub Copilot in VS Code. Ik wissel regelmatig tussen verschillende LLM’s: Claude Sonnet en Opus, GPT en Gemini. Ik heb nog niet ontdekt welke “de beste” is. Sterker nog, ik weet niet eens of dat wel een zinvolle vraag is. Het hangt ervan af. Ze hebben verschillende karakters, verschillende sterke punten en verschillende manieren waarop ze fouten maken. Regelmatig wisselen houdt je beeld van de modellen eerlijk. Wanneer je te lang bij één model blijft, ga je onbewust om de zwakke punten heen werken zonder dat je het doorhebt, en uiteindelijk zie je de beperkingen niet meer. Variatie is een vorm van kalibratie die ik iedereen zou aanraden.

We naderen langzaam het einde van deze reeks. Nu ik de inslag van de AI-meteoriet heb overleefd en merk dat ik floreer in dit nieuwe AI-tijdperk, is het tijd om mijn kijk te delen op het goede, het slechte en het lelijke.

Het goede is echt goed. Ik voel me productiever dan op enig ander moment in mijn carrière, en ik zeg dat terwijl de lat al behoorlijk hoog lag. Dingen waar ik vroeger veel tijd aan kwijt was om op internet op te zoeken – exacte syntaxis, methodesignatures, specifieke bibliotheekdetails, flags die ik twee keer per jaar gebruik – zijn nu binnen enkele seconden opgelost. Ik ben gestopt met me daar schuldig over te voelen. Een tijdlang deed ik dat wel. Het voelde alsof ik een zwakte toegaf. Alsof ik deze dingen uit mijn hoofd zou moeten weten. Alsof het gebruik van AI valsspelen was. Maar dat was mijn ego dat sprak. Wat ik daadwerkelijk weet, is hoe systemen werken, waar risico’s zitten, welke patronen de werkelijkheid overleven en welke alleen functioneren onder ideale omstandigheden. De syntaxis is bijzaak. En als AI zich bezighoudt met de bijzaken, kan ik mijn tijd besteden aan het deel dat daadwerkelijk beoordelingsvermogen vereist. Dat is geen afsnijden van bochten. Dat is een efficiënte inzet van middelen.

Wat mij het meest heeft verrast, is hoe overdraagbaar ervaring wordt over technologische grenzen heen wanneer AI onderdeel is van het proces. Ik begrijp patronen. Ik heb die patronen toegepast zien worden in Java, C#, Python, Go, JavaScript en vrijwel alles daartussenin. Ik kan de vorm van een oplossing herkennen in iedere programmeertaal, omdat de vorm belangrijker is dan de woorden. AI verzorgt de woorden. Die combinatie van mijn patroonherkenning en de syntaxiskennis van AI maakt het mogelijk om productief te werken in technologiestacks waar ik nooit eerder mee gewerkt heb. En op een niveau dat ik in dezelfde tijd zelfstandig nooit had kunnen bereiken.

Een concreet voorbeeld. Enige tijd geleden schreef ik een applicatie die door mijn vrouw wordt gebruikt. Zij doet aan digitaal scrapbooken, een hobby waarbij duizenden mappen met grafische elementen worden georganiseerd in zogenaamde creatieve kits. Het aantal bestanden groeit sneller dan welk logisch archiefsysteem dan ook kan bijhouden. Ik bouwde voor haar een desktopapplicatie in .NET WPF om die kits te organiseren en doorzoekbaar te maken. De applicatie draaide uitsluitend op Windows, wat jarenlang een terugkerende klacht was van scrapbookvriendinnen die inmiddels waren overgestapt naar Mac. Ik wilde dat probleem al jaren oplossen.

Met behulp van AI heb ik de volledige applicatie opnieuw gebouwd als een React- en TypeScript-applicatie in een Electron-shell. Ik heb minimale ervaring met die stack. Toch heb ik alle functionaliteit in ongeveer anderhalve dag gerealiseerd, pakketten gemaakt voor zowel Windows als macOS en tegelijkertijd een aantal nieuwe functies toegevoegd waar mijn vrouw al langer om vroeg. En ik heb het op de juiste manier gedaan: door de specificaties uit de bestaande codebase te halen en die als input te gebruiken voor de nieuwe applicatie, geautomatiseerde tests toe te voegen voor kwaliteitscontrole en documentatie en een helpfunctie op te nemen. Alles werkte probleemloos.

Daarnaast heb ik een conversietool gebouwd om bestanden uit de oude versie van de applicatie om te zetten naar het formaat van de nieuwe versie. Ook hier blonk AI uit. De oude applicatie sloeg gegevens op in een binair bestand via .NET binary serialization. Microsoft raadt het gebruik daarvan inmiddels af vanwege de beveiligingsrisico’s, dus de herschrijving van de applicatie was sowieso noodzakelijk. De migratietool moest die binaire bestanden kunnen omzetten naar het nieuwe NDJSON-formaat van de nieuwe applicatie. Omdat deze converter maar tijdelijk nodig zou zijn, heb ik hem volledig op basis van AI gebouwd. Ik gaf de AI beide codebases en vroeg om een converter. In één keer produceerde het een .NET-consoleapplicatie die de conversie correct uitvoerde. Het voegde zelfs invoervalidatie toe: wanneer je geen invoerbestand opgeeft, krijg je een duidelijke foutmelding met uitleg. Na afloop toont het statistieken over het aantal geconverteerde mappen en kits. Die laatste twee functies had ik niet eens gevraagd. Ze verschenen gewoon. Dat is de kracht waar ik het over heb. Geen magie en geen autonomie, maar een hulpmiddel dat, wanneer je het voldoende context geeft, werk levert op een niveau dat de benodigde inspanning met een orde van grootte kan verkleinen.

Dan is er het slechte, en dat is reëel genoeg om te benoemen. Een van mijn zorgen is de tokeneconomie. De input die je aan een LLM geeft en de output die het genereert worden opgedeeld in tokens. Elke interactie verbruikt dus tokens. En tokens kosten daadwerkelijk geld via de abonnementsmodellen van AI-aanbieders. Stel dat ik midden in een betaalde opdracht zit en afhankelijk ben van AI-ondersteund werk om binnen de afgesproken planning te leveren. Wat gebeurt er als mijn tokenbudget opraakt? Heb ik middelen om dat budget aan te vullen? En als dat niet zo is, ben ik dan nog in staat om het werk handmatig af te maken binnen de resterende tijd en het resterende budget? Dit is geen hypothetische situatie. Het is een afhankelijkheid die ik zelf heb geïntroduceerd in mijn professionele dienstverlening. En zoals iedere afhankelijkheid brengt ook deze risico’s met zich mee.

Het beheren van context is een directe manier om dat risico te beperken. De omvang van een gesprek – hoeveel informatie je aan het model geeft – en de duur van een sessie hebben meetbare invloed op het tokenverbruik. Mensen die de contextwindow behandelen als een stortplaats en complete codebases, lange gespreksgeschiedenissen en allerlei losse bestanden toevoegen in de hoop dat AI het zelf wel uitzoekt, verbruiken tokens in een tempo dat ze vaak pas opmerken wanneer de rekening komt of het budget op is. Context engineering betekent bewust kiezen wat je wel en niet toevoegt, verwijderen wat niet langer relevant is en lange sessies opdelen in gerichte gesprekken. Dat is niet alleen een kwestie van prestaties, maar ook van kostenbeheersing. De discipline voelt verrassend vertrouwd zodra je haar herkent: hetzelfde denken dat je toepast bij het afbakenen van een query, het ontwerpen van een minimale interface of het formuleren van een prompt die een precies antwoord oplevert in plaats van een uitgebreid antwoord. Het model heeft niet alles nodig. Het heeft de juiste dingen nodig. Leren dat onderscheid te maken hoort bij professioneel werken met AI en bepaalt rechtstreeks hoe ver je daadwerkelijk komt met je tokenbudget.

Ik volg ook de ontwikkelingen rond het lokaal draaien van modellen en het gebruiken van private infrastructuur. Ik heb zelfs gefantaseerd over een aanpak waarbij inferentie wordt verdeeld over beschikbare GPU-capaciteit: ongebruikte gaminghardware in woningen die niets staat te doen tussen speelsessies door. Iedereen die zich SETI@home nog herinnert begrijpt onmiddellijk wat ik bedoel. Ik zit niet diep genoeg in de infrastructuurkant om te weten of dit mogelijk is, of misschien zelfs al bestaat. Ik heb collega’s die daar veel meer verstand van hebben en vertrouw op hun oordeel als het gaat om de technische details. Het stelt me gerust dat het bedrijf waar ik werk al actief onderzoekt hoe een soevereine oplossing voor het draaien van LLM’s eruit kan zien. Wat ik namelijk wel weet, is dat het behandelen van cloudgebaseerde LLM-toegang als oneindig betrouwbaar dezelfde fout is die we vroeger maakten bij on-premises systemen voordat we hun faalpatronen goed begrepen. Redundantie is geen paranoia. Het is architectuur en risicomanagement.

Het lelijke is een zorg voor de langere termijn, en ik ben daar voorzichtig mee omdat ik geen expert ben op het gebied van modeltraining. Maar het is wel iets dat in mijn achterhoofd speelt. De modellen van vandaag zijn zo goed omdat ze grotendeels zijn getraind op code die door mensen is geschreven. Door echte engineers die nieuwsgierig waren, nieuwe dingen probeerden, opkomende libraries en patronen adopteerden nog voordat ze volledig volwassen waren en vervolgens blogden over wat werkte en wat niet werkte. Stel je nu voor wat er gebeurt wanneer een steeds groter deel van de code op internet wordt gegenereerd door AI. AI die voornamelijk patronen hergebruikt uit de trainingsdata in plaats van nieuwe patronen uit te vinden. Het feit dat mensen schreven over hun experimenten, inclusief de dingen die niet werkten, is precies wat die trainingsdata zo waardevol maakt. Als toekomstige trainingsdata voornamelijk uit AI-output bestaat, zullen nieuwe patronen, nieuwe libraries en echte innovaties dan nog wel voldoende terechtkomen in de modellen? Of gaan modellen steeds meer zichzelf weerspiegelen, steeds beter worden in het reproduceren van wat ze al kennen en tegelijkertijd minder gevoelig worden voor wat daadwerkelijk nieuw is?

Ik heb deze zorg eens besproken met een collega van Info Support die al jarenlang praktijkervaring heeft met AI en van wie ik het oordeel op dit gebied serieus neem. Hij wees erop dat tooling zich juist ontwikkelt in een richting die dit probleem adresseert. Moderne AI-agents zijn steeds beter in staat om documentatie te doorzoeken, package registries te raadplegen en actuele online bronnen te gebruiken als onderdeel van hun redeneerproces. Ze zijn dus niet uitsluitend afhankelijk van wat tijdens de training in het model is gestopt. Een model dat release notes kan opzoeken, een migratiehandleiding kan lezen en die kennis direct binnen dezelfde sessie kan toepassen, is wezenlijk anders dan een model dat volledig bevroren is in de tijd. Dat neemt mijn zorg niet volledig weg. De vraag of werkelijk nieuwe ideeën zich snel genoeg verspreiden naar deze systemen blijft wat mij betreft open. Maar het plaatst de discussie wel in een ander perspectief. De wisselwerking tussen de wereld en het model is mogelijk sterker dan het klassieke beeld van statische trainingsdata suggereert. Dat stelt me enigszins gerust. Ik ben benieuwd hoe dit zich verder ontwikkelt.

Dat brengt ons aan het einde van deze reeks. Ik hoop dat je met plezier hebt gelezen. Tot slot wil ik graag delen waarom ik de behoefte voelde om dit te schrijven.

Er bestaat een enorme hoeveelheid content over hoe je AI gebruikt. Tutorials, feature-overzichten, promptgidsen, benchmarkvergelijkingen en frameworkreviews. Een deel daarvan is uitstekend en ik heb er zelf veel van geleerd. Wat ik veel moeilijker kon vinden, waren eerlijke verhalen over de menselijke ervaring van het adopteren van AI als senior professional: de aarzeling, de weerstand en de momenten waarop je professionele identiteit botst met iets dat delen van jouw werk kan uitvoeren en je moet bepalen wat dat betekent. De interne onderhandeling tussen scepsis en oprechte nieuwsgierigheid. Het ongemak van ontdekken dat je ongelijk had over iets waar je juist heel zeker van was. De aanpassing in hoe je naar je eigen expertise kijkt wanneer een hulpmiddel terrein betreedt dat voorheen volledig van jou was en waarvoor je erkenning kreeg. Dat is de ervaring die ik wilde beschrijven, omdat bijna niemand het daarover heeft. Terwijl juist die ervaring bepaalt of iemand AI daadwerkelijk adopteert of vanaf de zijlijn blijft toekijken in de hoop dat het vanzelf weer verdwijnt. En mensen in die laatste categorie verschijnen meestal in tweetallen, waarbij ze elkaar vanaf veilige afstand versterken in hun scepsis, net als Waldorf en Statler op het balkon van The Muppet Show. En ja, het feit dat ik naar The Muppet Show verwijs zegt waarschijnlijk alles wat je moet weten over mijn leeftijd én over de titel van deze reeks.

Als je tot hier bent gekomen, ben je waarschijnlijk geen toeschouwer. Je bevindt je ergens op dit pad. Misschien sta je nog aan het begin. Misschien ben je halverwege. Misschien gebruik je AI al volop en vergelijk je ervaringen met anderen. Misschien zit je nog in die onzekere fase waarin je jezelf afvraagt: AI is misschien echt, maar hoe verbind ik me eraan? Of misschien voelt het alsof alle productiviteitsverhalen voor andere mensen gelden. Of je hebt het gevoel dat nog even wachten misschien verstandiger is. Als dat herkenbaar klinkt, wil ik je rechtstreeks iets meegeven: ik heb precies op dat punt gestaan. De scepsis was niet onredelijk. De aarzeling was niet irrationeel. De standaarden lagen niet te hoog. De lat lag precies waar hij moest liggen, en AI is eroverheen gekomen. Voor mij viel het oordeel uiteindelijk positief uit. Niet omdat AI indrukwekkend is in demonstraties, maar omdat het daadwerkelijk nuttig is in echt werk, met echte problemen en echte consequenties. Dat onderscheid – indrukwekkend versus nuttig – is uiteindelijk het enige onderscheid dat een senior professional werkelijk interesseert. Het heeft me behoorlijk wat tijd gekost om dat oordeel eerlijk te vormen. Ik deel het hier in de hoop dat het voor iemand anders de weg iets korter maakt.