AI schrijft 90 procent van de code. Wat doet de engineer dan nog?

Vervangt AI software engineers? Wat ik hoor van ervaren engineers die zeggen dat AI inmiddels 90 procent van hun code schrijft, wijst de andere kant op. Hun werk verdwijnt niet, het verschuift een paar lagen omhoog: minder typen, meer oordeel, architectuur en verantwoordelijkheid. Voor werkgevers betekent dat vooral dat je anders naar je team en je werving moet kijken.

Vervangt AI software engineers echt?

"AI schrijft inmiddels 90 procent van mijn code." Die zin hoor ik de laatste tijd regelmatig. En niet van juniors die net een nieuwe tool hebben ontdekt, maar van engineers met vijftien of twintig jaar ervaring. Mensen die al meerdere technologische golven hebben zien komen en gaan, en die niet snel onder de indruk zijn.

De eerste reactie van de meeste mensen die dat horen, is voorspelbaar: dan word je dus overbodig. Als een model het grootste deel van het typewerk overneemt, waarom zou je dan nog een ervaren engineer betalen? Ik begrijp die gedachte, maar ik denk dat er precies het omgekeerde gebeurt. En eerlijk gezegd vind ik wat er wel gebeurt een stuk interessanter dan de discussie die er nu over gevoerd wordt.

Wat doet een software engineer nog als AI de code schrijft?

Wie zegt dat AI 90 procent van zijn code schrijft, zegt namelijk niet dat hij 90 procent minder werkt. Hij zegt dat zijn werk is verschoven. Als ik doorvraag bij de engineers die dit vertellen, blijft er een flink pakket over dat nog steeds van hen komt. Zij bepalen wat er gebouwd moet worden en beoordelen of wat eruit komt ook klopt. Zij weten wanneer een antwoord er goed uitziet maar het niet is. Zij bewaken de architectuur waarbinnen alles moet passen, en zij dragen de verantwoordelijkheid als het in productie omvalt.

Dat is niet minder engineering. Dat is engineering een paar lagen hoger. Het typen van regels code kostte altijd veel tijd, maar het was zelden het moeilijkste deel van het vak. Het moeilijke deel was het oordeel: welke keuze maak je, wat laat je weg, en wat gaat er over een jaar mis als je nu de makkelijke weg kiest? Dat oordeel kun je niet aan een model uitbesteden, omdat je juist dat oordeel nodig hebt om te zien of het model iets bruikbaars heeft opgeleverd.

Waarom heeft een AI-model een harness nodig?

In een van mijn gesprekken hierover viel me iets op wat ik sindsdien vaker terughoor. Het model zelf heeft ook een harness nodig. Iemand moet de context aanleveren, iemand moet de grenzen zetten en iemand moet de terugkoppeling organiseren, zodat je merkt wanneer het de verkeerde kant op gaat. Dat bouwt zichzelf niet.

Ik ben zelf geen engineer en ik ga hier geen technische handleiding schrijven. Maar wat ik van de mensen om me heen hoor, is helder: hoe beter die omgeving rond het model is ingericht, hoe meer je eruit haalt. Het inrichten van die omgeving is gewoon vakwerk, met alle keuzes en afwegingen die daarbij horen. Wie dat goed kan, maakt het verschil tussen een team dat af en toe slim een tool gebruikt en een team dat er structureel beter van wordt. In wat zeventig engineers echt bespreken als het over AI gaat zie je hoe dicht dit bij hun dagelijkse praktijk ligt.

Welke twee groepen engineers zie ik ontstaan?

Op dit moment zie ik een tweedeling ontstaan, en die is voor zowel engineers als werkgevers belangrijk om te snappen.

De ene groep gebruikt AI om sneller hetzelfde te doen. Dezelfde tickets, dezelfde features, alleen in minder tijd. Dat is echte winst, daar wil ik niet flauw over doen. Maar het is tijdelijke winst, want straks kan iedereen dat. Als iedereen dezelfde snelheidswinst heeft, onderscheidt het je niet meer.

De andere groep gebruikt AI om dingen te doen die eerst niet konden. Grotere systemen in je eentje dragen. Sneller door onbekend terrein bewegen, een domein of taal waar je eerder maanden voor nodig had. Meer verantwoordelijkheid pakken dan je functietitel suggereert. Die engineers worden niet alleen sneller, ze worden zwaarder in wat ze kunnen dragen.

De eerste groep wordt goedkoper. De tweede wordt schaarser. Dat is misschien wat kort door de bocht, maar zo zie ik het nu. Het verklaart ook waarom niet elke regel AI-ervaring op een cv evenveel waard is; daar ga ik verder op in bij welke AI-ervaring echt meer salaris oplevert.

Wat betekent AI in softwareontwikkeling voor werkgevers?

Als je engineers aanneemt, is het verleidelijk om naar AI te kijken als een manier om met minder mensen hetzelfde te doen. Dat kan, maar dan mis je volgens mij de grotere kans. De vraag die ik werkgevers zou meegeven is niet hoeveel sneller je team wordt, maar wat je team nu kan oppakken dat eerst buiten bereik lag. En vooral: wie is bij jullie degene die het oordeel levert over wat er uit die modellen komt? Als niemand die rol heeft, verplaats je het werk niet. Dan verplaats je het risico.

Het betekent ook dat je bij het werven van een software engineer andere vragen kunt stellen. Niet alleen welke tools iemand gebruikt, maar hoe iemand beoordeelt of de output deugt. Een korte checklist die ik zelf handig vind in gesprekken met kandidaten:

1. Vraag hoe iemand controleert of code die een model heeft geschreven ook echt klopt, en laat een concreet voorbeeld vertellen.
2. Vraag naar een keer dat een antwoord er goed uitzag maar het niet was. Hoe viel dat op?
3. Vraag waar iemands grens ligt in wat hij uit handen geeft, en waarom juist daar.
4. Vraag hoe iemand de context en de grenzen rond een model inricht, zodat het niet ongemerkt de verkeerde kant op gaat.
5. Vraag wat iemand nu kan dragen wat een jaar geleden nog buiten bereik lag.

Op die vragen hoor je het verschil tussen de twee groepen vrij snel. De ene kandidaat vertelt vooral over snelheid, de andere over oordeel en verantwoordelijkheid. Het helpt ook om vooraf intern scherp te hebben wat je eigenlijk zoekt, want een vacature die alles tegelijk vraagt trekt zelden de tweede groep aan. Daarover schreef ik in geen tekort aan engineers, wel aan bedrijven die weten wat ze vragen.

Hoe bereid je je als engineer voor op AI?

Ik weet niet hoe dit over drie jaar uitpakt. Niemand weet dat, en ik wantrouw iedereen die het wel zeker zegt te weten. Maar wat ik wel zie: de mensen die er nu het meest ontspannen onder zijn, zijn niet degenen die het negeren. Het zijn degenen die al aan het uitzoeken zijn waar hun werk naartoe verschuift. Die experimenteren, die hardop vragen stellen en die bewust nadenken over welk deel van het vak ze in handen willen houden.

Ben je engineer en wil je weten welke werkgevers deze verschuiving serieus nemen? Kijk dan eens bij de informatie voor engineers en kandidaten, of stuur me gewoon je verhaal.

Sparren over jullie situatie?

Ik ben oprecht benieuwd hoe dit bij jou zit. Leid je een team en vraag je je af welk profiel je nu eigenlijk nodig hebt, nu een groot deel van het typewerk verschuift? Dan denk ik graag mee in een vrijblijvend kennismakingsgesprek. Hoe wij software engineers en AI engineers werven, lees je op de pagina's per rol. En als engineer ben je net zo welkom: ik leer het meest van precies dit soort gesprekken.

Dus, eerlijk: hoeveel van je code komt er nu nog met de hand, en wat doet je team met de tijd die overblijft?