Een paar weken terug schreef ik dat de sector zijn eigen zaaigoed opeet: de vraag naar engineers bleef overeind, het aannemen van juniors stortte in, en stilletjes stopte het vak met investeren in het proces waar seniors uit voortkomen.
Dat stuk eindigde met één zin advies voor wie net begint. De instroom is smaller geworden, maar hij is er nog. Daarna ging ik weer over tot de orde van de dag. Ik sta zelf niet op dat smalle stuk, en dat maakt zo'n zin makkelijk opschrijven.
Eén zin is geen plan. Dit is de rest. Als ik vandaag tweeëntwintig was, met een agent binnen handbereik en een arbeidsmarkt die er zo uitziet, wat zou ik dan als eerste leren?
De cijfers zijn niet subtiel. Onder afgestudeerde informatici ligt de werkloosheid op 6,1%, bijna twee keer zo hoog als onder afgestudeerde filosofen. Het aantal juniorvacatures daalde met zo'n 30% in een jaar. En dan het cijfer waar iedereen wakker van zou moeten liggen: 57% van de ondervraagde managers vertrouwt het werk van AI meer dan dat van een stagiair of een pas afgestudeerde.
Dat is de lat. En die ligt bij een machine.
Het advies dat iedereen geeft is twee weken waard
Zoek op juniorvaardigheden voor 2026 en je krijgt elke keer hetzelfde rijtje. Leer prompt engineering. Leer agents aansturen. Word vloeiend in Copilot, Cursor, Claude Code. Wees "tweetalig" in zelf schrijven en laten schrijven.
Die tools doen er echt toe. Wie in 2026 binnenkomt zonder een agent te kunnen bedienen, is als iemand die in 2010 binnenkwam zonder met git te kunnen werken, en die zou ik ook niet aannemen. Leer ze dus. Het kost je twee weken.
En dan? Iedereen heeft diezelfde twee weken besteed. Handigheid met tools is niet schaars en heeft een genadeloos korte houdbaarheid: de helft van wat er in 2023 over prompten geschreven is klopt nu niet meer, omdat de modellen zelf veranderd zijn. Je bouwt geen loopbaan op het onderdeel dat de volgende lichting het makkelijkst kopieert en dat met één release note achterhaald kan zijn.
De vaardigheden waar je je eerste twee jaar aan moet besteden, hebben precies de omgekeerde eigenschappen: ze kosten tijd, je kunt ze niet faken, en ze worden juist meer waard naarmate er meer gegenereerde code rondgaat. Het zijn er vier.
1. Debuggen, want dat kun je niet wegprompten
Genereren is inmiddels de goedkope helft van het werk. Uitzoeken waarom het gegenereerde ding niet werkt is de dure helft, en die is duur gebleven.
Debuggen laat zich om een specifieke reden niet automatiseren: het is geen tekstprobleem. Je hebt er een model van een draaiend systeem voor nodig, van deze deployment, deze data, deze lelijke wisselwerking tussen een cache en een tijdzone om drie uur 's nachts. Het model heeft een miljoen bugmeldingen gelezen en noemt keurig de vijf statistisch waarschijnlijkste oorzaken. Het kan niet meekijken terwijl je staging-omgeving zich misdraagt en daar een onderbuikgevoel bij krijgen.
Dat gevoel is precies waar het om draait. Het ontstaat doordat je het vaak genoeg mis had, met een stack trace voor je neus. Elk uur dat je met de hand naar de oorzaak zoekt, stort je op een rekening waar niemand anders geld op kan zetten.
Praktisch: pak één bug per week en gooi hem nergens in een chatvenster. Lees de trace van boven naar beneden. Bedenk een hypothese, schrijf hem op, test hem dan pas. Zo bouw je dat instinct op: door op papier ongelijk te krijgen.
2. Code lezen, want je doet het tien keer zo vaak als schrijven
Robert Martin schatte de verhouding tussen lezen en schrijven op ongeveer tien staat tot één, en dat was decennia voordat een machine duizend plausibele regels kon produceren terwijl jij koffie haalt. Inmiddels is het meeste wat je leest code die je niet zelf schreef, en dat is de lastigste soort. Die komt ook nog eens sneller binnen dan ooit.
En het schrijven waarmee je vroeger je leesinstinct opbouwde, is nou net het deel dat je hebt uitbesteed.
De trainingsroutine daarvoor schreef ik gisteren, dus die herhaal ik hier niet: beter leren code lezen bevat de oefeningen, elke dag een merged PR, voorspellen voordat je runt, en code uitleggen zonder de AI. Doe ze. Twintig minuten.
Neem uit dit hele stuk desnoods alleen deze gewoonte mee. Dit is de vaardigheid die bepaalt of je de bug vindt in code die je niet zelf schreef, en dat is inmiddels het grootste deel van je werkzame leven.
3. Datamodellering, want dat kan de agent niet terugdraaien
Deze ontbreekt in elk lijstje dat ik ben tegengekomen. Toch is dit degene waar ik het hardst voor zou pleiten.
Vraag een agent om een functie die je niet bevalt, en je gooit hem weg. Vraag een agent om een schema dat je niet bevalt, zet het live, stop er achttien maanden productiedata in, en je zit er jaren aan vast. Migraties zijn duur, backfills zijn riskant, en elke service eromheen is inmiddels om die vorm heen gegroeid.
Code is nu goedkoop genoeg om weg te gooien. Data is dat nooit geweest.
Leer dus waar normaliseren voor dient. Leer waarom elke nullable kolom een beslissing is die je later terugziet. Leer wat een foreign key je oplevert en wat een index kost bij writes. Leer het moment herkennen waarop een "flexibele" JSON-blob een bekentenis is dat niemand wist wat die entiteit nou was.
Agents zijn hier goed in op kleine schaal en gedachteloos zodra het groter wordt. Ze sturen op de opdracht die ze net gekregen hebben. De vorm waar jij over drie jaar nog in zit als iemand een rapport wil dat al die data omspant, valt buiten hun blikveld.
Wie daar wél over nadenkt, is schaars. En je leert het uit boeken die al oud waren toen ik begon.
4. Eén taal diep, niet vijf oppervlakkig
De verleiding is nu enorm. De agent schrijft prima Go, jij kent geen Go, dus je shipt Go. Doe dat bij vier stacks en je hebt een cv dat breed oogt en een hoofd dat nergens grip op heeft.
Diepte maakt lezen snel, en snel lezen maakt reviewen mogelijk. Zodra je één taal echt kent, springen de patronen eruit: dat is een retry-loop, dat lekt, daar zit een race te wachten. Reviewers die patronen zien, halen de fouten eruit. Reviewers die elke regel eerst in hun hoofd moeten vertalen, raken hun geduld kwijt en keuren het dan maar goed.
Die patronen neem je bovendien mee naar de volgende taal. Leer concurrency één keer goed en je herkent het overal.
Kies de taal die in jouw vakgebied echt gebruikt wordt en ga onder de tutorial-laag: geheugen, typesysteem, standard library, wat de runtime nou eigenlijk doet.
Wat ik zou overslaan
Frameworktoerisme. Een weekendproject in elk nieuw ding dat voorbijkomt stapelt niet op. Eén echt systeem, van idee tot productie, leert je meer dan een dozijn starter-templates, want daar krijg je gebruikers, een storing om drie uur 's nachts en een migratie voor je kiezen.
Ik zou ook die cursus prompt engineering overslaan. Prompten doet er wel degelijk toe, maar je koopt daar een cursus voor iets dat je in een middag afkijkt bij een collega.
De herhalingen komen niet meer vanzelf
Dit is het ongemakkelijke stuk, en het geldt of je nu drie maanden bezig bent of vijftien jaar.
De oude leerweg werkte omdat het werk zelf je dwong te oefenen. Je moest de codebase lezen om er iets in te veranderen. Je moest bij die bug blijven zitten, want om twee uur 's nachts was er niemand aan wie je het kon vragen.
Niemand had dat leerplan bedacht. Het werk leverde het bij toeval op.
De agent haalde dat toeval weg. Er is nu altijd iemand aan wie je het kunt vragen, altijd meteen een plausibel antwoord, en de weg van de minste weerstand slaat elke herhaling over die vroeger je oordeel opbouwde. Je kunt tegenwoordig een jaar lang features shippen en er bijna niets van leren, en dat lukte vroeger niet.
Die herhalingen moet je dus zelf inplannen. Stel je eigen regels op en houd je eraan: eerst twintig minuten zelf, dan pas vragen. Lees de diff voor je hem accepteert. En ship nooit code die je niet kunt uitleggen, wat ophoudt een leus te zijn zodra iemand je in een postmortem vraagt waarom die retry-logica dat deed.
Gebruik de agent als leermeester in plaats van als snoepautomaat. Vraag hem waarom de code deze vorm heeft. Spreek hem tegen. Hetzelfde gereedschap, nu gericht op wat jij ervan overhoudt.
Het goede nieuws dat de cijfers verbergen
Alles hierboven is zwaarder dan het in 2019 was. Het levert ook meer op, juist omdat de meeste mensen het niet gaan doen. Je concurrent is niet het model. Je concurrenten zijn een lichting die te horen krijgt dat handigheid met de tools het hele vak is, en dat grotendeels gelooft.
Debuggen, lezen, datamodellering en echte diepte in één taal waren vóór dit alles al waardevol. Wat er veranderd is: er is een groter tekort aan die vaardigheden ontstaan op precies het moment dat de markt extra ging betalen voor oordeelsvermogen. Dat is een vervelende constatering over hoe deze sector met nieuwe mensen omgaat, en heel nuttig om te weten als je er zelf een bent.
Aan de ladder ontbreekt de onderste sport. Niemand zet hem er dit jaar terug.
Dan bouw je je eigen houvast, uit de dingen die niemand voor je kan genereren.