Stel je voor: je hebt een hele carrière gebouwd rondom het ontwikkelen van software. Dat is geen klein ding. Om het te leren kostte jarenlange opleidingen en werkervaring. Wat het betekent is dat alle developers door de pijn van het leren gegaan zijn. Vastzitten, denken dat je het nooit zal begrijpen, fouten maken die er in productie uit komen.
En dan, ineens, in een ongelooflijk korte tijd, verandert je hele wereld. Een AI die sneller en beter kan programmeren dan ik? Natuurlijk voelt dat als een dreiging. Volstrekt legitiem. Onder dreiging zullen onze verdedigingsmechanismen automatisch in werking treden. En zoals wij allemaal herkennen we ons vast in een of meerdere van deze personificaties.
De activist
Minstens een developer in je team zal een wat meer activistisch gemotiveerde weerstand hebben tegen het gebruik van AI. De activist is geen eenduidig wezen. De complot-activist die roept dat AI gemaakt is om ons te beheersen, voelt een andere weerstand dan de klimaatactivist, die zich zorgen maakt over de energie en het water. Niet zelden is dit gebundeld in een persoon.
Ik sympathiseer met de activist. Ik was er zelf ook een. Ik begrijp de mindset en daarom kan ik uit persoonlijke herinnering vertellen: argumenten hebben geen zin. Misschien hebben ze wel gelijk. Wie ben ik om daar iets over te vinden?
De vraag die ik de activist zou willen stellen is niet “heb je gelijk?” maar “wat doe je ermee?” Want de trein rijdt. Je kunt ervoor gaan liggen, of je kunt proberen hem een betere richting te geven. Niet gebruiken terwijl anderen het wel doen, is ook een keuze. Het is er eentje waar karakter voor nodig is. Maar het is geen neutrale positie. Er is geen zijlijn.
De skepticus
Gezond, zou ik willen zeggen. Skeptisch zijn is geen zwakte. Het is een vaardigheid. In een wereld vol hype en overpromises is dat precies wat we nodig hebben. Maar gebruik het als een kracht, niet als een excuus. Er is een verschil tussen “ik geloof het pas als ik het zie” en “ik weiger ernaar te kijken.” De eerste leidt tot kritisch onderzoek. De tweede tot stilstand.
En laat ik eerlijk zijn: je hebt gelijk over veel van je bezwaren. AI maakt domme fouten. Het hallucineert functies die niet bestaan. Het produceert code die compileert maar de verkeerde kant op gaat.
Een concreet voorbeeld dat ik hoorde: een pipeline met twee stappen. De eerste stap ging goed. De tweede stap, een cruciale verbeterstap, gaf een foutmelding. Hoe had de AI dit “opgelost”? Met een try-except die de foutmelding stilletjes opslokte, zodat de pipeline tot het einde kwam. De hele tweede stap werd simpelweg overgeslagen. Een fout die een mens hopelijk nooit zou maken.
De scepticus die ik het meest respecteer is niet degene die aan de zijlijn blijft staan met armen over elkaar. Het is degene die zijn twijfels meeneemt in het experiment. Die kritisch kijkt, bijstuurt, en uiteindelijk leert hoe je dit ding naar je hand zet. Die heeft iets wat de enthousiaste early adopter vaak mist: de discipline om kwaliteit te eisen.
De controlfreak
Door iedere letter zelf te programmeren ontstaat er een gevoel van controle. Ik leg het zelf wel eens uit als een kaart die ik in mijn hoofd heb. Software is in veel opzichten een structuur met hiërarchie en gedeelde verantwoordelijkheden. Die mentale kaart helpt om te zien hoe dingen bij elkaar komen.
Dit is misschien wel het lastigste punt voor mij persoonlijk. Ben ik zelf een controlfreak? Misschien. Maar zijn we dat niet allemaal in meer of mindere mate? Ik merk dat de kaart in mijn hoofd minder goed tot stand komt. Dat is logisch.
Maar laat me eerlijk zijn: hoeveel van die controle was echt, en hoeveel was een illusie? Codebases groeien. Teams wisselen. Na een jaar werkt niemand meer alleen aan iets. Die kaart in je hoofd was altijd al incompleet. Je had alleen niet door hoeveel je miste, omdat niemand het je vertelde.
Verschuif je controle van de code naar de instructies. Wie de AI het beste kan sturen, heeft de meeste grip op het resultaat. Dat is een andere vorm van controle, maar het is nog steeds controle.
De drukke
De permanent opgejaagde developer die nergens anders tijd voor heeft dan het opleveren van nieuwe features. De backlog is eindeloos. De deadlines stapelen zich op.
Hier zit de paradox waar ik even bij stil wil staan. Je hebt geen tijd om te leren hoe je sneller kunt werken, omdat je te druk bent met werken. Het is alsof je zo hard aan het zagen bent dat je geen tijd hebt om je zaag te slijpen. Ondertussen wordt de zaag steeds botter.
Heel eerlijk: ik ben hier niet kapot van. Als ontwikkelaar heb je de verantwoordelijkheid om bij te blijven. Het vak zal blijven bewegen, met of zonder jou.
Het goede nieuws voor de drukke: de instap hoeft niet groot te zijn. Neem dat ene vervelende scriptje dat je iedere maand handmatig doet. Laat de AI het schrijven. Kost je een half uur. Als het werkt, heb je die halfuur iedere maand terug. Dat is geen investering in AI. Dat is gewoon slim werken. En als dat eenmaal loopt, komt de rest vanzelf.
De perfectionist
Niet alles wat de AI genereert is zoals je het zelf gedaan zou hebben. Precies zoals de eerstvolgende andere developer het ook anders gedaan zou hebben. Al jaren heerst er in teams een drang om dit zoveel mogelijk te voorkomen. De ene linting tool na de andere scant code op stijl en inconsistenties.
Maar hoe ver moeten we daar nou echt in gaan? Hoeveel linters, pipelines, reviews en controle over welke punt exact waar hoort, heb je werkelijk nodig? Ben je niet door aan het schieten?
Ook dit is een verlangen dat ontstaan is in de tijd dat het alleen maar mensen waren die aan het project werkten, met mensen-mogelijkheden en mensen-gebreken. Dit is nu aan het veranderen. De vraag is niet meer: hoe zorg ik dat alle mensen dezelfde stijl aanhouden? De vraag is: hoe zorg ik dat de AI consistent goede code oplevert?
Gebruik die aandacht voor detail waar het echt telt: in de instructies aan de AI. De perfectionist die zijn standaarden vertaalt naar AI-instructies, die heeft straks de schoonste codebase van allemaal.
De manager
De developer heeft heel wat acceptatiewerk te doen, dat is duidelijk. Maar de manager heeft een ander probleem, eentje waar minder over gesproken wordt: de onmogelijkheid om te controleren wat waar is.
Een developer zegt: “Dat kan niet met AI, te risicovol met de security keys.” Of: “AI-gegenereerde code is onveilig, dat wil je niet in productie.” Of simpelweg: “Dat werkt niet voor ons type project, te complex.” Wat doe je dan als manager? Je kunt het niet verifiëren. Je hebt niet de technische achtergrond om te beoordelen of dit klopt.
Een architect met zestien jaar ervaring vertelde me over de argumenten die hij hoort: “Dat AI volop hallucineert. Dat AI te veel werk doet en zo tech debt toevoegt. Dat AI alleen maar zegt wat je wil horen. Dat 95% van de AI-processen in bedrijven faalt. Dat je lui bent als je AI gebruikt. Dat AI alle gegevens doorlekt.” De vraag is: welke van deze argumenten zijn oprecht, en welke zijn angst verpakt in technisch jargon?
Mijn advies aan de manager: zoek een tweede mening, van een ervaren developer buiten het team. Niet om je developer te wantrouwen. Maar om het gesprek te openen. Haal er een externe blik bij. Een andere developer die het wel gebruikt. Een consultant die kan helpen de claims te toetsen. Het gaat erom dat je als manager de verantwoordelijkheid hebt om te zorgen dat jullie de juiste keuzes maken.
De verborgen adopters
Er is nog een groep die ik niet onbenoemd wil laten, omdat het bestaan ervan iets veelzeggends vertelt over de huidige cultuur rondom AI in veel bedrijven.
Developers die het wel gebruiken, maar het niet durven te zeggen. Die in hun vrije tijd meer programmeren dan op hun werk, omdat ze met AI meer plezier beleven dan aan Netflix. Die geheime clubjes hebben van developers over verschillende landen en bedrijven die wel AI op de juiste manieren gebruiken, maar het verborgen houden omdat het anders voor conflicten met anti-AI-collega’s leidt.
Denk daar even over na. Ervaren developers die een tool hebben gevonden waarmee ze maanden aan senior development-werk in dagen kunnen doen, maar het alleen voor side-projecten gebruiken. Niet omdat de tool niet werkt. Niet omdat het te risicovol is. Maar omdat de sociale dynamiek op het werk het niet toelaat.
Dat is een enorm verlies voor de bedrijven waar deze mensen werken. De productiviteitswinst is er al. De kennis is er al. Maar het wordt niet ingezet waar het het meest nodig is, omdat de cultuur het blokkeert.
Al deze archetypen, van de activist tot de verborgen adopter, laten hetzelfde zien: de weerstand is menselijk, begrijpelijk, en diep geworteld. Maar er is een woord voor de fase waar we collectief inzitten. En dat woord helpt om te begrijpen waarom het zo ongemakkelijk voelt.