De weerstand bij developers is persoonlijk. De blokkades in bedrijven zijn structureel. Beide zijn echt. Maar onder dat alles zit liminaliteit, een drempel. De vraag is wat je ermee doet.
Als developer: begin aan de zijkant
Je kent het wel. Even wat data migreren. Een CSV omzetten naar een ander formaat omdat de klant het natuurlijk weer anders aanlevert. Testdata genereren. Een API even snel aanroepen om te kijken of die externe service doet wat de documentatie beweert. Dat scriptje om die ene database-query te draaien die je iedere maand nodig hebt, maar waarvoor je iedere keer opnieuw de syntax moet opzoeken.
Dit soort klusjes horen bij het vak, maar ze zijn niet het vak. Vroeger deed je het handmatig, want het schrijven van een tool ervoor kostte meer tijd dan het probleem zelf. Of je had ergens nog een oud script liggen dat je half kon hergebruiken, als je nog wist waar het stond en hoe het ook alweer werkte.
Dit is waar je begint. Niet met je core product. Niet met die feature waar de klant op wacht. Met de rommel eromheen. De randjes. De irritaties. Vraag de AI om dat scriptje te schrijven. Kijk wat eruit komt. Werkt het? Mooi. Werkt het niet? Dan heb je in vijf minuten geleerd waar de grenzen liggen, zonder dat er iets op het spel stond.
Dit is de veilige instap. Je bouwt vertrouwen op, in kleine stapjes, zonder risico. En voor je het weet gebruik je het voor meer.
Als bedrijf: begin met je fundering
Voordat we het over AI-strategieën hebben, moet ik iets benoemen dat zelden op de agenda staat maar alles blokkeert. Veel bedrijven willen AI inzetten, maar kunnen het niet. Niet vanwege AI, maar omdat hun eigen systemen niet op orde zijn.
Ik werk regelmatig met codebases die in de loop der jaren zijn uitgegroeid tot iets wat niemand meer volledig overziet. Monolieten van honderdduizenden regels code. Geen plugin-structuur, gewoon alles op een hoop. De CI-pipeline heeft vijftien stappen waarvan de helft niemand meer kan uitleggen. De testcoverage staat op papier op 98%, maar nieuwe code wordt helemaal niet getest. De deployment gaat via SSH en een handmatige git pull. De security policies staan op “nee” zonder dat iemand weet waarom.
Dit is geen uitzondering. Dit is de norm bij een verrassend groot deel van de bedrijven die ik van binnen zie.
AI versterkt wat er is. Als wat er is een rommeltje is, versterkt AI de rommel. Je kunt niet verwachten dat een AI zinvol werk doet op een codebase waar de tests niet draaien, de linter crasht, en niemand met vertrouwen kan zeggen wat er gebeurt als je op deploy drukt. Dat is geen AI-probleem. Dat is een hygiëneprobleem.
Wil je AI serieus inzetten? Begin dan niet met AI. Begin met je fundering. Zorg dat je codebase leesbaar is. Zorg dat je tests draaien. Zorg dat je deployment geautomatiseerd en herhaalbaar is. Zorg dat je weet wat je hebt. Pas dan heeft het zin om er een AI op los te laten.
Een paar veilige startpunten voor het bedrijf
Documentatie laten maken
Niemand schrijft graag documentatie. En dus is het altijd verouderd, incompleet, of simpelweg niet aanwezig. Dit is het laaghangende fruit. Zet een AI op je codebase en laat hem beschrijven wat er is. Hoe de modules samenwerken. Wat de belangrijkste flows zijn. Waar de configuratie zit.
Het mooie is: dit raakt niks aan je productie. Geen risico. Gewoon output die er eerst niet was en nu wel. En als bonus: de developer die het moet reviewen, leert meteen of de AI de codebase echt begrijpt. Dat is je graadmeter voor hoeveel je de AI kunt vertrouwen met andere taken. Begin hier. Het kost een middag en levert direct waarde.
Proof of concepts en MVP’s
Een idee valideren, een eerste versie bouwen, kijken of iets werkt. Daar is AI perfect voor. Je hoeft niet meteen een schaalbare architectuur. Je wilt gewoon zien of het concept klopt. Geen dagen meer besteden aan iets waarvan je na twee weken hoort: “Toch maar niet.” Bouw het in een middag, laat het zien, en ga pas bouwen als het groen licht krijgt.
Interne tools
Ieder bedrijf heeft ze: vervelende handmatige processen. Excel-sheets die heen en weer gemaild worden. Data die van het ene systeem naar het andere geknipt en geplakt wordt. Vroeger was het bouwen van een interne tool om dit op te lossen een project. Nu niet meer. Een simpele tool die twee systemen koppelt? Een dashboard dat data visualiseert? Dit is precies waar AI-assisted development uitblinkt. Maar laat het door iemand bouwen die weet wat hij doet. De snelheid van AI maakt het niet minder nodig om na te denken over validatie, testen en edge cases.
De developer is weg
Iedere ondernemer zal dit herkennen. Je hebt een held-developer. Alles gemaakt. Iedereen is ervan afhankelijk. Behalve dat dit een rode vlag is die je had moeten voorkomen.
Het onvermijdelijke staat te gebeuren. Een mooiere kans ergens anders? Hoe dan ook: hij vertrekt. Een maand uitwerktijd. Niet genoeg om een vervanger te vinden en alle kennis goed overgedragen te krijgen. Laat dit nou een ultieme case zijn voor AI. Zet Claude op je codebase. Laat hem de structuur doorgronden. En laat je nieuwe developer met Claude praten om te begrijpen hoe dingen in elkaar steken. De overdracht was nog nooit zo smooth.
De junior
Dit is het hoofdstuk dat ik het liefst zou overslaan. Want ik heb geen goed antwoord. Maar het is misschien wel het belangrijkste, omdat het gaat over de toekomst van ons vak.
De junior developer stapt op dit moment de industrie in op een uniek ongelukkig moment. De regels zijn aan het veranderen, maar niemand weet nog naar wat.
Het oude pad was duidelijk. Je begint onderaan. Je schrijft simpele code. Je maakt fouten. Je leert van die fouten. Langzaam bouw je de bagage op die je nodig hebt om complexe problemen aan te kunnen. Maar dat pad staat onder druk.
De junior die AI gebruikt wordt nu al afgeschoten. En terecht, in zekere zin. De senior ziet het meteen: dit heeft iemand niet zelf geschreven. Code die werkt, maar waarvan de junior niet snapt waarom. Hoe kun je iemand vertrouwen die niet begrijpt wat hij oplevert?
Maar de junior die geen AI gebruikt? Die is hopeloos langzaam vergeleken met wat er mogelijk is. En leert vaardigheden die over vijf jaar misschien irrelevant zijn.
Het is een dubbele bind. Gebruik je AI, dan leer je het vak niet echt. Gebruik je geen AI, dan leer je een vak dat aan het verdwijnen is. We weten nog niet hoe het nieuwe leerpad eruitziet. Ik denk dat we de junior nodig hebben om dat nieuwe pad te vinden. Het is hun wereld straks. Niet de onze.
Tot slot: AI is een versterker
AI is een versterker. Niet meer, niet minder. Het versterkt wat je erin stopt. Bullshit in, bullshit out. Maar het werkt ook andersom. Kennis erin, betere output eruit. Ervaring erin, sneller resultaat eruit.
Tegen een developer zeg ik: wat het voor jou genereert, had je ook zelf moeten kunnen maken. Dan zit je goed. Dat is niet elitair. Dat is de dev mindset: het probleemoplossend vermogen en de denkwijze die nodig zijn om AI werkelijk als verlengstuk van je eigen skills te gebruiken.
De developers die door de weerstand gaan, die hun bagage meenemen in plaats van achterlaten, die gaan het verschil maken. Niet ondanks AI, maar met AI.
Maar ik wil hier niet eindigen met alleen een verhaal over productiviteit. Ja, je wordt sneller. Maar dat is niet het einddoel. Productiviteit is een middel, geen bestemming. De echte vraag is: wat doe je met die vrijgekomen tijd? Met die vrijgekomen energie? Als AI het stampwerk overneemt, wat blijft er dan voor jou over?
Misschien is dat het mooiste aan deze transitie. Niet dat we meer kunnen doen, maar dat we eindelijk de ruimte krijgen om na te denken over wat we eigenlijk zouden moeten doen. Om te bouwen wat er echt toe doet. Om de problemen aan te pakken waar we voorheen geen tijd voor hadden, of die te complex leken om überhaupt te beginnen.
Er is geen zijlijn. De trein rijdt. Het is tijd om in te stappen.