Beste jonge developer,

Je staat aan het begin van je carrière en je hebt het vast al een keer of tien gehoord: dat programmeren als vak aan het verdwijnen is, dat de agents het overnemen, dat je net op het verkeerde moment bent ingestapt. Het is een vervelend bericht om te krijgen als je net je eerste regels productiecode hebt geschreven en eindelijk het gevoel had dat je ergens kwam.

En ja, de spelregels zijn inderdaad veranderd. De carrièrepaden die mijn generatie kent bestaan uit eerst jaren ploeteren als junior, daarna langzaam opklimmen naar medior, dan pas mogen meepraten over architectuur. Die regels gelden niet meer. Dit is een nieuw speelveld.

Maar hier is wat niemand je vertelt: dat speelveld is voor iedereen nieuw. De senioren om je heen zitten met twintig jaar spiergeheugen dat ze nu moeten ombuigen. Ze moeten gewoontes áfleren. Jij niet. Jij begint blanco, op precies het moment dat blanco beginnen een voordeel is. Je bent niet te laat. Je bent vroeg.

Waar je je uren in steekt

Vroeger maakte je vlieguren door veel te typen. Hoe meer code door je vingers ging, hoe beter je werd. Dat klopte ook, toen.

Er zullen genoeg mensen zijn die je aanraden om vooral veel met de hand te blijven typen. Luister naar ze, want ze hebben geen ongelijk: zelf code uitschrijven heeft echt waarde, je leert er dingen van die je anders mist.

Maar ze hebben ook niet helemaal gelijk. Die waarde is relatief kleiner geworden dan elk uur dat je in agentic coding steekt. Investeer je tijd daarom nu vooral in het leren samenwerken met agentic tools. Niet omdat handmatig coderen waardeloos is geworden, maar omdat de schaarste verschoven is: er zijn straks zat mensen die een agent kunnen aanzetten, en weinigen die er goed mee kunnen sturen.

Ieder uur dat je investeert in agentic coding is meer waard dan ieder uur dat je investeert in handmatig leren coderen. Jij gaat geselecteerd worden op je agentic coding skills, niet op je handmatige coding skills.

Verander daarom ook hóe je leert. Stop met die generieke cursus "React voor beginners" waar je een to-do-app bouwt die niemand ooit zal gebruiken. Laat je agent in plaats daarvan een hyper-specifieke tutorial schrijven voor jóuw codebase, jóuw feature, jóuw bug. Je hebt nu een privédocent die elk onderwerp kan toespitsen op exact het probleem dat voor je neus ligt. Dat is een luxe die mijn generatie niet had, en het is verspilling om hem niet te gebruiken.

De houding die je nodig hebt

Het makkelijkste wat je kunt doen, is de gevaarlijkste gewoonte: alles klakkeloos accepteren wat de agent voorstelt. Het ziet er goed uit, het draait, klaar. Doe dat niet.

Vraag je agent altijd waarom hij iets op een bepaalde manier heeft gedaan. Waarom deze datastructuur, waarom hier de grens getrokken, waarom niet de andere oplossing? Zonder die houding bouw je nooit echt begrip op. Dan ben je geen developer maar een doorgeefluik dat op enter drukt. Het begrip dat je vroeger opdeed door zelf vast te lopen, doe je nu op door scherpe vragen te stellen. Het is dezelfde nieuwsgierigheid, alleen via een andere route.

Gebruik je agent daarom ook als sparringpartner, niet alleen als uitvoerder. Vraag hem expliciet om jóu te challengen: op performance, op security, op architectuur, op de trade-offs die je maakt. Een agent die alleen maar "ja" zegt is gezelschap, geen collega. Dwing hem het oneens met je te zijn.

En geloof omgekeerd ook niet blind wat je agent zegt. De huidige generatie coding agents geeft regelmatig onjuiste informatie; sommige zijn zelfs ronduit lui en leugenachtig. Challenge daarom terug en eis bijvoorbeeld dat hij een experiment opzet waarmee een theorie daadwerkelijk wordt bewezen. Je zult merken dat als jij je laat uitdagen én je je agent terug uitdaagt, jullie samen meer en beter werk verzetten dan wanneer je alles maar voor zoete koek van elkaar aanneemt.

En leer denken als een architect. Je hoeft niet langer elk technisch detail uit je hoofd te kennen. Dat mag je loslaten. Wat blijft, en wat steeds belangrijker wordt, zijn de concerns, de trade-offs en de architecturale keuzes. Wáár hoort iets thuis, wat zijn de gevolgen van deze beslissing over een half jaar, welke complexiteit haal je je op de hals. Dáár zit de waarde die een agent (nog) niet van je overneemt.

Je zult wellicht niet alles meteen kunnen plaatsen, omdat je spiergeheugen nog niet is getraind op deze concepten. Maar het creëert wel voor jezelf een kapstok waarmee je ervaring en intuïtie kunt ontwikkelen.

Wat je wordt

Hier moet ik een advies geven dat misschien tegen je opleiding ingaat. Word een generalist. Brede kennis van veel verschillende domeinen is op dit moment waardevoller dan het diep uitgraven van één specialisme. De agent levert de diepte op aanvraag; jij levert het overzicht en het oordeel om die diepte op de juiste plek in te zetten. Een T-vorm waarbij de horizontale streep breed is, is meer waard dan een smalle, diepe paal.

En je rol verschuift. Grof gezegd word jij verantwoordelijk voor de werkvoorbereiding aan de voorkant en de afronding aan de achterkant: het scherp krijgen van wat er moet gebeuren, en het beoordelen en bijschaven van wat er uitkomt. De implementatie er tussenin gebeurt steeds vaker grotendeels onbemand door agents. Je bent minder de metselaar en meer degene die de tekening maakt en daarna de muur keurt. Dat is geen degradatie. Dat is meer verantwoordelijkheid, niet minder.

Het nieuwe ambacht

Er is ook gewoon nieuw vakmanschap te leren, en daar kun je vandaag al aan beginnen. Maak je codebase agent-friendly. Begin met een CLAUDE.md of AGENT.md die een duidelijke routekaart van je project bevat: waar hoort welke code thuis, wat zijn de conventies, wat moet de agent weten voordat hij iets aanraakt.

Houd dat document strak. De verleiding is groot om er een encyclopedie van te maken met elke denkbare regel erin, maar dat werkt averechts. Niemand leest een handleiding van veertig pagina's, een agent net zomin. Voeg pas een extra regel toe als iets herhaaldelijk misgaat. Laat het document groeien uit de fouten die je daadwerkelijk tegenkomt, niet uit de fouten die je je inbeeldt.

Je zult merken dat dit soort feed forward-instructies redelijk werkt, maar zijn grenzen kent: je kunt nu eenmaal niet vooraf elke fout opschrijven. Daarom wil je daarnaast betrouwbare, deterministische feedbackmechanismen bouwen. Denk aan een testsuite, een linter of een CI-pipeline die hard terugkoppelt wat een document nooit kan afdwingen. Je vlieguren helpen je om dit soort afwegingen op waarde te schatten en te weten wanneer je welk mechanisme inzet.

Tot slot

Ik ga je niet wijsmaken dat het simpel is, of dat de onrust die je voelt onterecht is. Er verandert echt iets fundamenteels, en het is logisch dat dat schuurt.

Maar onthoud dit: de toekomst is niet aan de beste handmatige programmeur. Die titel is uitgespeeld. De toekomst is aan de ontwikkelaar die het beste kan samenwerken met agents: die de goede vragen stelt, de juiste afwegingen maakt en het overzicht bewaart. Dat is een vak dat je kunt leren. En je staat aan het begin, zonder ballast, op precies het goede moment.

Succes. We hebben je nodig.