Als AI het juniorwerk doet, hoe ontwikkelen we dan de seniors van morgen?

AI kan een implementatie genereren, onbekende code uitleggen en een fix voorstellen. Voor iemand die een carrière in softwareontwikkeling start, creëert dat kansen.

Voor werkgevers roept het ook een ongemakkelijke vraag op.

Als een ervaren developer met AI werk kan afhandelen dat voorheen aan een junior werd toegewezen, zullen bedrijven dan nog mensen aannemen aan het begin van hun carrière? En welke waarde kunnen die mensen brengen terwijl ze aan het leren zijn?

Bij HumanInTech geloven we dat er een sterk argument is om juniors te blijven aannemen en ontwikkelen. Maar dat argument moet praktisch zijn. Bedrijven hebben mensen nodig die vandaag bijdragen, terwijl ze de expertise opbouwen die ze morgen nodig zullen hebben.

Recent onderzoek helpt zowel de kans als het risico te verklaren.

Meer software produceren, die software begrijpen en professioneel oordeelsvermogen ontwikkelen zijn verschillende uitkomsten. We moeten ruimte maken voor alle drie.

De druk op startersbanen verdient aandacht

Stanford-onderzoekers analyseerden Amerikaanse loongegevens tot juni 2026. Ze rapporteerden dat de werkgelegenheid onder werknemers van 22-25 jaar in beroepen die sterk aan AI zijn blootgesteld 19% onder het niveau lag dat zou volgen uit gelijke tred houden met minder blootgestelde leeftijdsgenoten. Het verschil ontstond vooral doordat minder jonge mensen werden aangeworven.

De auteurs beschrijven dit als observationeel bewijs, geen causale schatting. Ze vonden ook geen wijdverspreide, verdringing van banen in de hele economie. Dit zijn Amerikaanse bevindingen over beroepen, geen meting van de aanwerving van junior developers in België.Bron: Stanford Digital Economy Lab, herzien augustus 2026.

De werkgelegenheidsgrafiek reconstrueert de gerapporteerde vergelijking als een index: 100 voor de vergelijkingsbenchmark en 81 voor het gerapporteerde relatieve werkgelegenheidsniveau. Het toont niet aan dat 19% van de junior developers hun baan verloor.

Voor werkgevers roept dit een vraag op die verder gaat dan ontslagen: wat gebeurt er wanneer de eerste kans zich nooit voordoet?

Een bedrijf kan zijn ervaren developers behouden en tegelijk beslissen geen nieuwe junior aan te werven. Die keuze kan begrijpelijk zijn binnen een bepaald budget. Herhaald over organisaties heen, zou het de route kunnen vernauwen waardoor mensen het beroep betreden.

We kunnen niet beloven dat de aanwerving van juniors onveranderd zal blijven. We kunnen wel beslissen of onze eigen organisaties een zinvol pad naar het werk bieden.

AI kan ook minder ervaren developers productiever maken

Er is ook bewijs voor kansen.

Drie gerandomiseerde veldexperimenten met 4.867 developers bij Microsoft, Accenture en een Fortune 100-bedrijf vonden een geschatte 26,08% toename in voltooide taken met een AI-codeerassistent. Minder ervaren developers toonden hogere adoptie en grotere productiviteitswinsten. De gepoelde schatting had aanzienlijke onzekerheid, weergegeven in de grafiek.Bron: Cui en collega's, juni 2025.

Voltooide taken meten de productie. Ze tonen niet aan dat leerresultaten, betrouwbaarheid of commerciële waarde even sterk verbeteren.

De implicatie voor aanwerving is het overwegen waard. Werkgevers kunnen AI gebruiken om een junior sneller een waardevolle bijdrage te laten leveren, met passend toezicht.

Dat stelt geen universeel rendement op het aannemen van juniors vast. Het daagt wel de aanname uit dat de productiviteitsvoordelen van AI uitsluitend toebehoren aan ervaren developers.

De praktische vraag wordt: welke nuttige verantwoordelijkheden kan een junior aan met deze tools en de juiste ondersteuning?

Welke waarde kan een junior vandaag brengen?

Een geloofwaardig antwoord moet verder gaan dan enthousiasme, frisse perspectieven of een lager salaris. Een junior kan bijdragen door concreet werk waarvan de scope aansluit bij de vaardigheden die de junior aan het opbouwen is.

• Problemen onderzoeken: een fout die af en toe optreedt reproduceren en vastleggen onder welke omstandigheden dat gebeurt, waardoor het team bruikbaar bewijs krijgt.
• Afgebakende verbeteringen leveren: validatie, toegankelijkheid of foutafhandeling verbeteren met review, waarbij echte gebruikersproblemen worden opgelost.
• Gedrag verifiëren: een door een klant gerapporteerd defect omzetten in een regressietest om te helpen voorkomen dat dezelfde fout terugkeert.
• Kennis verduidelijken: onboarding-instructies testen en ontbrekende stappen documenteren, waardoor het team minder afhankelijk wordt van informele uitleg.
• Opvolging met gebruikers: controleer of een geleverde wijziging de oorspronkelijke moeilijkheid oplost, en verbind technische levering met het beoogde resultaat.
• Domeinkennis opbouwen: leer de regels en uitzonderingen achter een bedrijfsworkflow, en ontwikkel het vermogen om steeds beter geïnformeerde beslissingen te nemen.

Dit zijn voorbeelden van hoe we werk zouden structureren, eerder dan bevindingen die door de studies zijn gemeten.

Neem een klant die meldt dat een bestelling soms verdwijnt van een scherm. Een junior kan onderzoeken welke gebruikers getroffen zijn, de volgorde reproduceren en bepalen of de informatie ontbreekt, vertraagd is of verkeerd wordt weergegeven.

Een senior moet misschien helpen bij het interpreteren van het bewijs of het kiezen van de oplossing. Maar het onderzoek zelf brengt het werk vooruit. Het leren gebeurt door nuttige bijdrage.

Snellere afronding garandeert geen dieper begrip

Een apart experiment illustreert waarom output alleen een onvolledige maatstaf is.

Onderzoekers rekruteerden 52 voornamelijk junior engineers om te werken met een onbekende Python-bibliotheek. De AI-ondersteunde groep scoorde gemiddeld 50% op een kennistoets direct na de opdracht, vergeleken met 67% zonder AI: een verschil van 17 procentpunten. Het tijdvoordeel was niet statistisch significant.

Dit was een klein, kortetermijnexperiment. Het bewijst geen langetermijnverlies van vaardigheden. Verkennende analyse associeerde het zoeken naar uitleg en conceptuele vragen met sterker leren, maar bewees niet dat die gedragingen het veroorzaakten. Bron: Shen en Tamkin, januari 2026.

Dit experiment onderzocht het leren gebruiken van een nieuwe bibliotheek. Het meet iets anders dan het productiviteitsexperiment op de werkvloer; de resultaten zijn niet rechtstreeks vergelijkbaar.

Onze interpretatie is dat bedrijven begrip naast levering moeten beoordelen. Een afgerond ticket vertelt ons niet of de auteur de oplossing kan uitleggen of de fout kan onderzoeken.

Juniors moeten nog steeds programmeren leren

AI neemt de noodzaak niet weg om control flow, data, permissies, concurrency, testen en foutafhandeling te begrijpen.

Stel je voor dat een assistent code genereert die een betalingsverzoek opnieuw probeert na een timeout.

De code compileert. De happy-path test slaagt. Maar de betalingsprovider heeft de transactie misschien verwerkt voordat de verbinding mislukte. Opnieuw proberen zou de klant dubbel kunnen belasten.

Om dat gevaar te herkennen, moet een ontwikkelaar kunnen redeneren over onzekerheid: wat is er op afstand gebeurd, wat weet de lokale applicatie en welke acties zijn veilig om te herhalen.

Elke regel persoonlijk typen is geen voorwaarde voor dat begrip. Oefenen met redeneren over code wel.

Die oefening moet soms inhouden dat je zonder AI werkt. Kan de junior de uitvoering traceren, een fout uitleggen of een klein stukje logica zelfstandig implementeren?

Het moet ook inhouden dat je met AI werkt. Kunnen ze de suggestie in vraag stellen, een ongeteste aanname identificeren en het resultaat verifiëren? Beide oefeningen onthullen iets nuttigs.

Gedeelde code review kan levering en leren verbinden

Code samen met een senior reviewen is een praktische manier om oordeelsvermogen te ontwikkelen.

De senior kan de eigen redenering zichtbaar maken:

• Wat trok hun aandacht?
• Welke aanname zou kunnen falen?
• Wat zouden de gevolgen zijn?Welke onderbouwing is nodig om de wijziging met vertrouwen te aanvaarden?

De junior moet deelnemen voordat ze het antwoord krijgen.

Voor het betalingsvoorbeeld zou de senior kunnen vragen: "Als het verzoek een timeout krijgt, weten we dan of de betaling is gebeurd?"

Laat de junior die vraag door het systeem volgen. Vraag hen dan om de gevaarlijke situatie in een test te reproduceren en een oplossing te onderzoeken.

Het resultaat is een gereviewde wijziging, een concrete demonstratie van het risico en een principe dat ze elders kunnen toepassen.

Review alleen is niet genoeg

Er is een beperking aan leren door uitleg: een probleem herkennen nadat iemand het identificeert is makkelijker dan het zelf vinden.

Juniors hebben kansen nodig om hypotheses te vormen, beslissingen te nemen en te ontdekken waar hun redenering vastloopt.

Een kleine feature kan die ervaring van begin tot eind bieden. Met ondersteuning kan een junior de requirement verduidelijken, een aanpak voorstellen, die implementeren, reageren op review en het gedrag na deployment opvolgen.

De verantwoordelijkheid moet groeien naarmate hun competentie groeit.

We moeten ook vermijden om juniors eindeloos verificatiewerk toe te wijzen terwijl we elke ontwerpbeslissing en interessant onderzoek voor seniors reserveren. Dat helpt misschien om de backlog van vandaag weg te werken, maar het biedt een smal pad naar onafhankelijkheid.

Mentoring heeft een business case nodig, en tijd

Werkgevers mogen vragen wat deze aanpak kost.

Een junior heeft feedback nodig. Reviews kosten tijd. Sommige taken moeten worden herwerkt. AI laat die kosten niet verdwijnen.

De nuttige vergelijking is de bijdrage van het hele team over tijd: opgeleverde verbeteringen, tijd voor begeleiding, fouten, groeiende onafhankelijkheid en kennis die gedeeld wordt over mensen heen.

Een praktische aanpak kan het volgende omvatten:Een vaste mentor met tijd die expliciet voor begeleiding is vrijgemaakt.

• Een initiële set nuttige taken met beheersbare consequenties.
• Gedeelde reviews die redenering en correctheid onderzoeken.
• Regelmatige kansen om code zelfstandig te debuggen en uit te leggen.
• Geleidelijk bredere verantwoordelijkheid naarmate het begrip verbetert.

Vooruitgang moet zichtbaar worden. Identificeert de junior risico's vroeger? Hebben ze minder hulp nodig bij vertrouwd werk? Kunnen ze uitleggen wat ze getest hebben en wat onzeker blijft? Worden ze betrouwbaar in een deel van de applicatie?

Er is geen universeel tijdschema. Er moet wel een bewust opgebouwd groeitraject zijn.

Als iedereen alleen seniors aanwerft, waar komt ervaring dan vandaan?

Een organisatie kan redelijkerwijs een ervaren aanwerving nodig hebben voor een veeleisend project. Het kan ook op een bepaald moment geen mentoring-capaciteit hebben.

Maar een duurzame strategie om alleen ervaren mensen aan te werven hangt af van andere werkgevers die ze blijven ontwikkelen.

Senioriteit groeit door kansen om beslissingen te nemen, consequenties te ondervinden en feedback te ontvangen. Die kansen wegnemen terwijl je een onbeperkt aanbod van ervaren engineers verwacht is een fragiele aanname.

Juniors ontwikkelen geeft een bedrijf ook de kans om productkennis op te bouwen en verantwoordelijkheid te verdelen binnen het eigen team. Retentie is nooit gegarandeerd, maar ervaren mensen rekruteren brengt ook onzekerheid met zich mee.

De beslissing moet rekening houden met zowel de onmiddellijke delivery-behoeften als de capaciteiten die de organisatie over enkele jaren wil hebben.

De kans is om te verbeteren hoe we mensen ontwikkelen

Bij HumanInTech geloven we dat bedrijven AI moeten omarmen en tegelijk bewust aandacht besteden aan hoe developers leren.

Juniors kunnen waarde brengen door implementatie, onderzoek, verificatie en een groeiend begrip van de business. Ervaren collega's kunnen die bijdrage laten groeien door hun oordeel uit te leggen en kansen te creëren om het te oefenen.

Het onderzoek geeft ons redenen om zowel productiviteit als leren serieus te nemen. Onze verantwoordelijkheid is om dat te vertalen naar de manier waarop we werk organiseren.

Als we willen dat de seniors van morgen weloverwogen beslissingen nemen, moeten we de juniors van vandaag kansen geven om het te ontwikkelen.