Als AI de juniorrollen overneemt, waar komen de seniors dan vandaan?

Er zit een stille tegenstrijdigheid in hoe we over AI in softwareontwikkeling praten.

Aan de ene kant is er enthousiasme over het vervangen van juniorwerk. Boilerplate, simpele features, kleine bugfixes — precies het werk dat vroeger je instap was, wordt nu steeds vaker door AI gedaan. Dat scheelt tijd, drukt de kosten en laat teams sneller werken, zo gaat het argument. Daar valt weinig tegenin te brengen.

Maar er blijft een ongemakkelijke vraag in de lucht hangen: als er minder mensen op juniorniveau beginnen, waar komen de senior developers dan later vandaan? Want senior engineers verschijnen niet kant-en-klaar. Ze worden gevormd, over jaren, vaak juist door het soort werk dat nu wegautomatiseert.

Veel werk aan het begin van je loopbaan oogt van buitenaf niet indrukwekkend. Kleine bugs oplossen, repetitieve code schrijven, je een weg zoeken door systemen die je niet kent, en langer met een probleem blijven zitten dan je lief is omdat je de sluiproutes nog niet kent.

Het gaat traag, en het is af en toe frustrerend. Maar het bouwt iets op waar geen shortcut voor bestaat: context.

Je begint patronen te herkennen. Je ziet hoe kleine beslissingen doorwerken in grotere systemen. Je krijgt gevoel voor waar dingen stukgaan, en waarom. Dat haal je niet uit het bestuderen van architectuurplaten. Verdwijnen die ervaringen — of worden ze samengeperst tot iets lichters — dan is het niet vanzelfsprekend wat ervoor in de plaats komt.

Er verschuift iets subtiels in hoe developers met code omgaan. In plaats van alles zelf te schrijven, bestaat het werk steeds vaker uit beoordelen, bijstellen en bijsturen wat AI produceert. Dat is een andere manier van denken. Je beoordeelt een uitkomst in plaats van hem stap voor stap op te bouwen.

Voor ervaren developers kan dat efficiënt zijn. Zij hebben al een mentaal model om tegenaan te houden. Voor iemand die net begint, ligt dat anders. Code beoordelen veronderstelt dat je weet hoe “goed” eruitziet. Het veronderstelt dat je edge cases ziet, afwegingen begrijpt en aanvoelt wanneer er iets niet klopt. Precies de vaardigheden die een junior nog aan het opbouwen is.

Wordt “controleren wat de AI schreef” de hoofdtaak, dan bestaat het risico dat mensen leren om oplossingen te accepteren of bij te schaven zonder ze werkelijk te doorgronden.

Er speelt ook een pijplijnprobleem waar weinig over gesproken wordt. Juniorrollen zijn altijd meer geweest dan goedkope handjes. Het waren instappunten. Plekken waar mensen voor het eerst in aanraking komen met echte systemen, echte beperkingen en echte gevolgen. Krimpen die rollen fors, dan wordt de weg het vak in smaller.

Bedrijven nemen misschien nog steeds juniors aan, maar minder, en meer “AI-ondersteund”. Of ze verwachten dat nieuwe mensen al met meer ervaring binnenkomen, waarmee de last elders komt te liggen — bij eigen projecten, onbetaald werk of toch al overvolle opleidingstrajecten. Hoe dan ook wordt het systeem minder vergevingsgezind.

Het is verleidelijk om te denken dat dit zichzelf wel oplost. Dat mensen zich gewoon op een andere manier ontwikkelen, of dat AI de route naar senior op de een of andere manier versnelt.

Tot op zekere hoogte misschien. Maar ervaring gaat niet alleen over blootstelling aan oplossingen. Het gaat over problemen tegenkomen in rommelige, onvoorspelbare omstandigheden, beslissingen nemen met halve informatie, en vervolgens met de gevolgen leven. Dat soort leren laat zich niet makkelijk samenpersen.

Je kunt delen ervan versnellen. Je kunt herhaling wegnemen. Maar of je het volledig kunt overslaan en toch op dezelfde plek uitkomt, is nog maar de vraag.

Het kan best zijn dat de juniorrol niet zozeer verdwijnt als wel van vorm verandert. In plaats van zich op implementatie te richten, besteden beginnende developers hun tijd misschien meer aan systemen doorgronden, AI-output valideren en dichter tegen product en design aan werken. De instapeis verschuift dan van “kun je dit schrijven” naar “kun je hierover redeneren”. In theorie klinkt dat veelbelovend.

In de praktijk hangt het sterk af van hoe teams dat werk inrichten. Zonder bewuste inspanning belanden juniors makkelijk in een passieve rol — toekijken hoe systemen draaien, wijzigingen nakijken, maar nergens genoeg eigenaarschap over een probleem hebben om echte diepgang op te bouwen.

Leunt het vak straks meer op AI en minder op klassiek juniorwerk, dan moet er iets anders voor in de plaats komen.

Begeleiding wordt belangrijker, niet minder belangrijk. Systemen moeten uitgelegd worden, niet alleen gebruikt. Beslissingen moeten zichtbaar zijn, niet verstopt in gegenereerde code. Teams moeten ruimte maken om te leren, ook als snelheid de standaarddruk is.

Dat vraagt om opzet. Laat je het op zijn beloop, dan optimaliseert het systeem waarschijnlijk op kortetermijnefficiëntie. Minder juniors, meer output, sneller leveren. De langetermijneffecten — op vaardigheden, op de kwaliteit van systemen, op de beschikbaarheid van ervaren engineers — laten langer op zich wachten.

Er is nog geen sluitend antwoord. AI verandert nu al hoe software gemaakt wordt, en een deel van die veranderingen is oprecht nuttig. Ze negeren slaat nergens op. Tegelijk drijft het vak nog altijd op mensen die systemen diep begrijpen, die in dubbelzinnige situaties knopen doorhakken en die anderen kunnen begeleiden. Die mensen komen niet uit de lucht vallen. Brokkelt de route die ze voortbracht af, dan is het de moeite waard om je nu al af te vragen wat ervoor in de plaats komt — voordat het gat pijnlijk zichtbaar wordt.

Want tegen de tijd dat je merkt dat je te weinig senior engineers hebt, is het al te laat om ze op te leiden.