AI verandert hoe ingenieurs ontwikkelen

Ongeveer een jaar geleden was een van de luidste debatten in de softwarewereld gericht op de toekomst van de junior ingenieur. Het argument klonk eenvoudig: als AI al veel junior-taken kan uitvoeren, waarom zou je dan nog junior-ingenieurs in dienst nemen en opleiden? En als bedrijven stoppen met het ontwikkelen van junior-talent, waar komen de senior-ingenieurs dan over vijf jaar vandaan?

Het was een serieus vraagstuk, en veel slimme mensen namen het serieus.

Toen was mijn antwoord dat andere beroepen al soortgelijke problemen hadden opgelost. Niemand studeert af in de medische faculteit en voert meteen onafhankelijk een openhartoperatie uit. Dokters brengen jaren door met schaduwen, stage lopen, residencies voltooien en oefenen onder supervisie voordat het systeem hen vertrouwt om alleen te opereren.

Hetzelfde patroon bestaat in het uitvoerend leiderschap. Niemand studeert af en leidt meteen een Fortune 500-bedrijf. Mensen beheren kleinere teams, dan grotere bedrijfseenheden, en verzamelen geleidelijk aan oordeel over tijd. Het pad wordt langer, praktischer en meer leerlinggericht naarmate de complexiteit van de rol toeneemt.

Ik denk nog steeds dat de ingenieursbranche in die richting beweegt. Maar de afgelopen maanden begon ik anders over het probleem na te denken vanwege drie ongerelateerde ervaringen die allemaal naar dezelfde conclusie wezen.

Drie voorbeelden

Een vriend van me heeft onlangs maanden besteed aan het voorbereiden van een Tsjechisch taalexamen. Hij en enkele van zijn collega’s hebben menselijke leraren ingehuurd en hebben echt geld geïnvesteerd in het proces. Hij is comfortabel geslaagd. De meesten van de anderen niet.

Het grootste verschil, volgens hem, was dat zijn primaire leraar eigenlijk ChatGPT was.

Hij kon studeren om 23.00 uur als hij dat wilde. Hij kon dezelfde conjugatie-oefening veertig keer herhalen zonder zich zorgen te maken over het verspillen van iemands geduld. Hij kon rollenspellen van zeer specifieke situaties, zoals het omgaan met een Tsjechische belastingambtenaar, en de sessie precies afstemmen op wat hij die dag moeilijk vond.

De menselijke leraren waren goed. Ze konden alleen de beschikbaarheid, herhaling en personalisatie niet evenaren.

Ik zie iets soortgelijks met mijn zoon en natuurkunde. Hij begrijpt het onderwerp al goed, dus hij gebruikt het niet om antwoorden te krijgen. Hij gebruikt het om zichzelf uit te dagen. Hij vraagt het om moeilijkere problemen te genereren, zijn aannamen te betwisten, uit te leggen waarom een benadering dichtbij was maar uiteindelijk verkeerd, en hem interactief te testen.

De meest vergelijkbare ervaring die ik kan bedenken is de ervaring die slimme kinderen vroeger hadden toen ze een oudere broer of zus hadden die natuurkunde studeerde. Behalve dat deze versie altijd beschikbaar is, nooit ongeduldig is en nooit zegt “vraag me later”.

Mijn neef, die nog op de middelbare school zit, heeft een klein hobbyproject gebouwd dat hij uiteindelijk commercieel wil maken. Ik heb hem geholpen een coderingsagent in te stellen en enkele workflows te automatiseren. Elke middag om vijf uur, terwijl hij zijn school afmaakt, scant een agent zijn codebasis en laat hij suggesties voor verbetering achter. Een keer per week wordt een andere workflow uitgevoerd en wordt marktonderzoek gedaan en worden nieuwe ideeën naar boven gehaald.

Hij vond het geweldig.

Op een gegeven moment maakte hij een grapje: “Als coderen zo eenvoudig is, ga ik door met ideeën.”

Ik zei tegen hem dat ideeën altijd een schaarse resource waren. Het verschil is nu dat uitvoering niet langer op dezelfde manier beperkt. Implementatie is namelijk dramatisch goedkoper geworden.

Snelere feedbackloops

Geen van deze voorbeelden gaat eigenlijk over het Tsjechisch, natuurkunde of codebeoordeling.

Ze zijn voorbeelden van zeer persoonlijke feedback die continu beschikbaar komt.

Historisch gezien leerden junior-ingenieurs deels door herhaling en deels door de nabijheid van ervaren mensen. Je schreef code, wachtte op beoordeling, kreeg feedback wanneer een senior eindelijk tijd had, en bouwde geleidelijk aan oordeel op over een periode van jaren van opgehoopte fouten.

AI verandert de feedbackloop zelf.

Een junior-ingenieur met een goed geconfigureerde AI-assistent krijgt nu veel van de dingen die eerder afhankelijk waren van de beschikbaarheid van een senior. Onmiddellijke codebeoordeling. Uitleg over waarom een ontwerpkeuze later problemen kan creëren. Verwijzingen naar soortgelijke patronen elders in de codebasis. Terugkoppeling wanneer je de meest voor de hand liggende implementatie kiest in plaats van de betere.

Het belangrijkste is dat de feedback aankomt terwijl de ingenieur nog steeds binnen het probleem zit, in plaats van twee dagen later wanneer de context is vervaagd.

Dat is belangrijk omdat de overgang van junior naar senior altijd grotendeels door oordeel werd gedreven. Oordeel is grotendeels patroonherkenning opgebouwd door herhaalde blootstelling aan fouten, compromissen en randgevallen. Hoe sneller iemand door die feedbackloops kan gaan, hoe sneller dat oordeel zich ontwikkelt.

De bandbreedtebeperking zat vroeger bij senior-ingenieurs. Nu zit die steeds meer bij de leerling.

De veiligheidsnet wordt beter

Er is nog een andere verschuiving die net zo belangrijk is.

Een junior-ingenieur die werkt met sterke AI-beoordelingsystemen, is aanzienlijk minder waarschijnlijk om per ongeluk een productiesysteem te beschadigen.

Veel klassieke fouten worden nu onmiddellijk gemarkeerd: hardcoded referenties, geslikt exceptions, onveilige queries, beveiligingsproblemen, voor de hand liggende architectonische problemen, slecht gescopeerde afhankelijkheden. Slechte pull-verzoeken worden steeds vaker gevangen voordat ze de laptop verlaten.

Dat verandert de basis voor junior-werk.

Historisch gezien ging een aanzienlijk deel van de tijd van senior-ingenieurs naar het beschermen van de organisatie tegen voorkombare fouten. AI-beoordelingslagen nemen steeds meer een deel van die last op, waardoor junior-ingenieurs onafhankelijker kunnen werken dan ze eerder konden.

Dat elimineert niet de behoefte aan mentorship of toezicht. Het verandert waar mentorship het meest waardevol wordt.

De kloof wordt groter

De optimistische versie van deze toekomst hangt sterk af van hoe de individuele ingenieur het systeem gebruikt.

Iemand die AI voornamelijk gebruikt als een shortcut om na te denken, zal waarschijnlijk meer code genereren terwijl hij weinig leert. Tien jaar geleden zou dezelfde persoon oplossingen van Stack Overflow hebben gekopieerd zonder ze te begrijpen. Het mechanisme is veranderd. Het onderliggende gedrag niet.

AI loste nooit het probleem van intellectuele passiviteit op.

Het meest interessante resultaat gebeurt wanneer ingenieurs actief omgaan met de feedback die ze ontvangen. Als iemand de beoordeling zorgvuldig leest, er tegenin gaat, follow-upvragen stelt, alternatieven test en soms ontdekt dat het model zelf verkeerd was, dan bouwt hij oordeel veel sneller op dan eerdere generaties konden.

De cognitieve inspanning is niet verdwenen. Die is eerder in de loop verschoven en is goedkoper om te herhalen.

Dat zal waarschijnlijk de kloof tussen zeer betrokken ingenieurs en niet-betrokken ingenieurs vergroten.

De meest belangrijke productiviteitsshifts werken op die manier. Lezen heeft de kloof tussen geletterde en analfabete bevolking vergroot. Het internet heeft de kloof tussen nieuwsgierige mensen en passieve mensen vergroot. AI lijkt hetzelfde patroon te volgen.

Productoordeel wordt belangrijker

De meest interessante vraag is niet langer of junior-ingenieurs verdwijnen. Het is wat junior-ingenieurs steeds meer bijdragen wanneer implementatie zelf gemakkelijker wordt.

Het antwoord begint er verrassend uitzien als wat sterke senior-ingenieurs al bijdragen: creativiteit, productgevoel, smaak, prioritering, oordeel en het vermogen om te identificeren wat er eigenlijk moet bestaan.

Ingenieursrollen bewegen steeds meer naar productgericht denken omdat implementatiefrictie blijft afnemen. Leidinggevende werkzaamheden zijn minder belangrijk dan het begrijpen of het systeem dat wordt gebouwd, het probleem oplost.

Systeemontwerp is nog steeds belangrijk. Naamgeving is nog steeds belangrijk. Productoordeel is nog steeds belangrijk. Het begrijpen van gebruikers is nog steeds belangrijk. Op sommige manieren worden die vaardigheden nog belangrijker omdat organisaties nu ideeën veel sneller kunnen testen dan eerder.

Een ingenieur die vanaf het begin met AI is opgeleid, zal waarschijnlijk heel anders denken dan iemand die vijftien jaar geleden is opgeleid.

Hij zal aannemen dat iteratie goedkoop is. Hij zal meerdere benaderingen snel protyperen in plaats van één enkele aanpak te bespreken voor dagen. Hij zal veel strakkere feedbackloops tussen gebruikers en implementatie verwachten omdat de kosten van het proberen van dingen blijft dalen.

Dat creëert een andere soort ingenieur, iemand die wordt gevormd door veel kortere cycli tussen idee en uitvoering.

Organisaties zullen moeten nadenken over het herschikken van het werven, evalueren, begeleiden en promoveren dienovereenkomstig. Maar software is al door soortgelijke transities gegaan: toen het web arriveerde, toen mobiel arriveerde, toen cloud-infrastructuur on-prem-systemen verving.

Elke verschuiving veranderde wat goed ingenieurswerk leek zonder de behoefte aan ingenieurs zelf te elimineren.

Operationele implicaties

Voor junior-ingenieurs is het advies niet bijzonder glamoureus.

Kies echte projecten. Gebruik AI als schaduwbeoordelaar terwijl je werkt. Lees de feedback zorgvuldig. Ga er soms tegenin. Stel follow-upvragen. Houd bij welke patronen achter de fouten zitten die het model vindt.

Dat is een van de snelste manieren om oordeel te ontwikkelen, veel sneller dan wachten tot een drukke senior-ingenieur eindelijk tijd heeft voor mentorship.

Voor managers verandert de bottleneck ook.

Junior-groei hing vroeger sterk af van hoeveel tijd senior-ingenieurs konden vrijmaken voor coaching. Steeds meer wordt de grotere hefboom de ontwerp van sterke leeromgevingen rond AI-gebruik: beoordelingsverwachtingen, escalatieregels, aanmoedigingspatronen, beveiligingsmaatregelen en projectselectie.

Organisaties die die systemen goed ontwerpen, zullen waarschijnlijk talent sneller ontwikkelen dan eerdere generaties konden.

En voor leidinggevende teams is het waarschijnlijk verstandig om te stoppen met het zien van junior-ingenieurs als primair vervangbare uitvoeringscapaciteit. In veel organisaties kunnen ze een van de goedkoopste bronnen van experimenten, energie en creatieve iteratie zijn.

Een andere generatie ingenieurs

Mijn vriend leerde Tsjechisch sneller omdat hij effectief een persoonlijke leraar in zijn zak had. Mijn zoon leert natuurkunde met een niveau van interactieve feedback dat ik nooit heb gehad. Mijn neef krijgt nu elke avond codebeoordelingen en marktonderzoek terwijl hij slaapt.

De volgende generatie ingenieurs zal de industrie betreden met continue coaching, onmiddellijke feedbackloops en dramatisch snellere cycli tussen inspanning en feedback.

Dat elimineert de junior-ingenieur niet. Het verandert hoe snel ze zich ontwikkelen en welke vaardigheden het meest belangrijk zijn onderweg.

De versie van de rol die veel mensen zijn opgegroeid, is waarschijnlijk aan het verdwijnen. Maar de vervanging kan blijken sneller te leren, beter gecoacht, experimenteler en productgerichter te zijn dan de vorige generatie ooit de kans had om te worden.