Back to all posts

Kunnen We Nog Afstand Nemen van AI?

Kunnen We Nog Afstand Nemen van AI?

Begin 2026 liepen onderzoekers die het effect van AI op de productiviteit van ontwikkelaars wilden meten tegen een heel menselijk probleem aan: sommige ontwikkelaars wilden geen taken meer aannemen waarbij ze mogelijk zonder AI moesten werken.

De onderzoekers noemden het een selectiebias. Ik blijf erover denken als een kleine bekentenis.

Nog niet zo lang geleden was AI een experiment in een zijpaneel. We openden het als autocompletion faalde of als een reguliere expressie gênant werd. Nu is het voor veel ontwikkelaars simpelweg onderdeel van de ruimte. Het is er als we 's ochtends de editor openen, als we een repository erven die jaren niet is aangeraakt, en als een test laat op de avond rood wordt.

We kunnen het paneel sluiten. We kunnen de agent uitschakelen. We weten nog steeds hoe we moeten coderen.

Dus waarom voelt werken zonder AI nu al alsof we met één hand missen?

AI nam de pauzes over

AI kwam niet de softwareontwikkeling binnen met de aankondiging dat het ons zou vervangen. Het kwam als kleine verlichting, stap voor stap.

Het maakte de regel af die we toch al wilden schrijven. Daarna stelde het de test op die we steeds uitstelden. Het legde een onbekende functie uit, vertaalde een stacktrace naar gewoon Engels, en vond de configuratievlag die diep in de documentatie verstopt zat waar we niet opnieuw doorheen wilden.

Niets daarvan voelde als afhankelijkheid. Het voelde als momentum.

Maar denk aan de laatste keer dat je assistent offline ging. Het verontrustende was waarschijnlijk niet dat je de taal vergeten was. Het was de stilte voor de eerste stap. Je moest zelf bepalen waar je moest kijken. Je moest de onzekerheid alleen dragen. Je moest lang genoeg naar de fout staren tot er een theorie ontstond.

Die pauzes waren ooit normaal. Nu voelen ze als wrijving.

Misschien is dat wat AI het diepst heeft veranderd. Het heeft niet alleen veranderd hoe we antwoorden produceren. Het heeft veranderd hoe lang we bereid zijn alleen met een vraag te blijven.

De verlichting is echt

Het is makkelijk om over AI-afhankelijkheid te praten alsof ontwikkelaars discipline inruilen voor gemakzucht. Dat mist hoe het hulpmiddel voelt van binnenuit het werk.

Softwareontwikkeling bevat verrassend veel privé-schaamte. De senior engineer die de syntax van een basiscommando is vergeten. De nieuwe collega die bang is dat nog een vraag ieders twijfels bevestigt. De ontwikkelaar die in een tweede taal werkt en precies weet wat er mis is, maar het niet snel genoeg kan uitleggen. Degene die een tien jaar oude codebase binnenkomt waar elke belangrijke beslissing in iemand anders’ geheugen leeft.

AI is geduldig met al deze mensen.

Het zucht niet als de vraag herhaald wordt. Het zegt niet: “Dit zou je al moeten weten.” Het is beschikbaar om 2 uur ’s nachts, en het kan een leeg scherm omtoveren tot iets waarover je kunt discussiëren. Zelfs als het antwoord niet perfect is, verandert het hebben van een antwoord het emotionele gewicht van beginnen.

Dat doet ertoe. Soms lijkt productiviteit eigenlijk op verlichting: minder angst om vast te lopen, minder schaamte, minder eenzaamheid voor een machine die zichzelf niet uitlegt.

Voor veel ontwikkelaars heeft AI ook energie teruggebracht naar de delen van het werk die ze belangrijk vinden. Het kan boilerplate, repetitieve tests, migraties, en de honderdste variant van een API-client overnemen. Het hoofd komt minder moe aan bij het interessante probleem.

Dat moeten we niet afdoen als een shortcut. Een hulpmiddel dat mensen meer moed geeft om te verkennen, doet iets echt waardevols.

Het lastige is dat comfort en afhankelijkheid uit dezelfde wortel groeien.

We gebruiken wat we niet volledig vertrouwen

Ontwikkelaarsonderzoeken vinden steeds dezelfde vreemde relatie: we gebruiken AI voortdurend, terwijl we wantrouwig blijven over wat het ons geeft.

Die spanning is herkenbaar voor iedereen die een zelfverzekerd antwoord heeft zien instorten door een edge case. De code ziet er goed uit. De namen zijn netjes. De uitleg is rustig. Pas na de derde mislukte test merken we dat het model een methode heeft verzonnen, een bedrijfsregel verkeerd begreep, of een simpeler probleem oploste dan we eigenlijk hadden.

En toch, de volgende keer dat we vastlopen, vragen we weer.

Dit is geen hypocrisie. Vertrouwen is niet één ding.

We vertrouwen AI misschien niet om de eindbeslissing te nemen, maar wel om ons een eerste richting te geven. We vertrouwen de patch niet, maar wel het gesprek om de knoop in ons denken los te maken. We geloven het antwoord niet altijd, maar we geloven dat er iets op het scherm zal staan in plaats van niets.

AI is de collega geworden die we nooit direct naar main zouden laten mergen, maar die we toch missen zodra die de kamer verlaat.

We gaan sneller omdat de volgende stap snel verschijnt. We blijven verantwoordelijk om te controleren of het ons gewicht kan dragen.

Wat verdwijnt als de worsteling verdwijnt

Er is een bepaald soort kennis die alleen ontstaat door vast te zitten.

Voor AI kon een onbekende fout ons door de stacktrace sturen, naar de aanroeper, door de documentatie, en uiteindelijk naar een aanname waarvan we niet wisten dat we die hadden gemaakt. De route was inefficiënt. Maar zo werd de codebase een plek in plaats van een verzameling bestanden.

We herinneren ons de systemen die ons ooit weerstand boden.

De bug die een middag kostte leert ons waar de state echt leeft. Het productie-incident leert waarom een saaie beveiliging bestaat. De library die we drie keer verkeerd begrepen, wordt de library die we later aan iemand anders kunnen uitleggen.

Als AI de weerstand wegneemt, verdwijnt misschien ook het verhaal dat de les laat beklijven.

Een vroege studie naar ontwikkelaars die een onbekende library leerden, vond iets dat intuïtief waar voelt: mensen die de taak uitbesteedden, leerden minder dan mensen die AI gebruikten om conceptuele vragen te stellen en hun eigen begrip te testen. Het belangrijkste verschil was niet “AI of geen AI.” Het was of het hulpmiddel het denken verving of eraan deelnam.

Dit is vooral lastig voor junior ontwikkelaars. Ervaren engineers herkennen een verdachte abstractie omdat ze eerder de verkeerde abstractie hebben gebouwd. Ze voelen aan dat een nette patch niet in het systeem past omdat ze de littekens van het systeem kennen. Maar waar krijgt de volgende generatie dat instinct vandaan als elke ruwe rand gladgestreken wordt voordat ze hem aanraken?

Mentorschap was nooit alleen het overdragen van antwoorden. Het was de langzame overdracht van smaak: waar je je zorgen over moet maken, wanneer je moet stoppen, welk compromis duur wordt, en waarom een oplossing die werkt toch niet klaar is.

AI kan al deze ideeën uitleggen. Het kan nog niet het gevoel nabootsen van iemand die ervoor kiest naast je te blijven terwijl je ze leert.

De shortcut kan echt zijn. Begrip moet nog steeds de afstand overbruggen.

Code droeg vroeger vingerafdrukken

Er is nog een andere verandering die moeilijker te meten is omdat die tussen mensen leeft.

Door mensen geschreven code draagt vaak sporen van de auteur. Een vreemde helperfunctie komt misschien met een herinnering aan het incident dat hem nodig maakte. Een ongemakkelijke commentaarregel laat precies zien waar iemand onzeker was. Tijdens review inspecteren we niet alleen de wijziging; we reconstrueren het denkproces erachter. We stellen vragen, en iemand anders antwoordt vanuit het pad dat zij hebben afgelegd.

AI-gegenereerde code kan zonder dat pad arriveren.

Het kan gepolijst en technisch plausibel zijn, maar toch eigenaarsloos aanvoelen. De auteur kan uitleggen wat ze vroegen, maar niet altijd waarom het resultaat deze vorm kreeg. De reviewer doet dan werk dat vroeger deels bij de schrijver lag: intentie reconstrueren, aannames controleren, en de verborgen randen ontdekken van een beslissing die niemand zich meer herinnert te hebben genomen.

Dit is het ongemak onder veel community-discussies over AI-gegenereerde pull requests. De klacht is niet alleen dat de code slecht is. Slechte code is bekend. Het diepere ongemak is dat het sociale contract is veranderd.

Eén persoon kan nu in minuten een grote wijziging maken. Een ander moet nog steeds menselijke aandacht besteden om het te begrijpen. De tijdwinst aan het toetsenbord kan ongemerkt terugkomen in code review, onderhoud, beveiliging, of de nacht dat het systeem faalt en iemand moet uitleggen wat de gegenereerde patch probeerde te doen.

Code is altijd communicatie geweest. Als genereren bijna gratis wordt, wordt aandacht het schaarse deel—en aandacht is van mensen.

Misschien verschuift het ambacht

Voor sommige ontwikkelaars voelt dit alles niet als verlies. Het voelt als eindelijk mogen werken op het niveau dat ze altijd wilden.

Ze schrijven minder regels en besteden meer tijd aan het vormgeven van het probleem. Ze vergelijken verschillende ontwerpen voordat ze zich aan één binden. Ze denken na over de gebruiker, de architectuur, de faalmodi, en de grenzen die een agent niet mag overschrijden. Het ambacht verschuift van elk onderdeel maken naar het geheel regisseren.

Dat kan een echte evolutie zijn. We zijn geen ontwikkelaars minder geworden toen assemblers machinecode vervingen, of toen frameworks handgemaakte infrastructuur overnamen. Software is altijd omhoog bewogen via abstractie.

Maar elke abstractie hangt af van iemand die begrijpt wat eronder zit.

Een ontwikkelaar die AI aanstuurt, heeft nog steeds smaak nodig. Een reviewer heeft nog steeds een mentaal model nodig. Een architect moet nog steeds weten wat er gebeurt als het schone diagram een trage netwerkverbinding, een corrupte boodschap, een uitgeput team of een bange gebruiker ontmoet.

Als AI meer van de implementatie schrijft, wordt menselijk oordeel niet minder belangrijk. Het wordt makkelijker te negeren en moeilijker te ontwikkelen.

De hoopvolle versie van deze toekomst is er niet één waarin ontwikkelaars minder belangrijk zijn. Het is er één waarin we bewuster worden over wat alleen mensen kunnen dragen: context, zorg, twijfel, verantwoordelijkheid, en het vermogen te herkennen wanneer een technisch correct antwoord verkeerd is voor dit specifieke systeem en deze specifieke mensen.

Blijf, zonder te verdwijnen

Kunnen we nog afstand nemen van AI?

Individueel wel. We kunnen het paneel morgen sluiten. Professioneel is de vraag al ingewikkelder. Verwachtingen veranderen. Codebases vullen zich met gegenereerd werk. Nieuwe ontwikkelaars ontmoeten AI aan het begin van hun loopbaan, niet halverwege. Zelfs wie nooit een assistent gebruikt, zal steeds vaker code reviewen en onderhouden die door een AI is gemaakt.

Er is geen privéweg terug naar een industrie zonder AI.

Maar misschien is vertrekken de verkeerde maatstaf voor vrijheid. De betekenisvollere vraag is of we aanwezig kunnen blijven terwijl het hulpmiddel blijft.

Aanwezig blijven betekent de patch lezen, ook als elke test groen is. Het betekent vragen waarom het antwoord werkt. Het betekent weigeren te mergen wat we niet kunnen uitleggen. Het betekent junior ontwikkelaars tijd geven om te worstelen zonder die tijd als verspilling te zien, en reviewers waardering geven voor het onzichtbare werk van het beschermen van een systeem tegen plausibele fouten.

Het betekent ook momenten bewaren waarop geen assistent direct antwoordt—niet als ritueel, maar om ons eigen denken weer te horen.

De meesten van ons zullen AI blijven gebruiken. De verlichting is echt. De mogelijkheden zijn echt. Maar ook het ongemak, de afhankelijkheid, en de stille angst dat iets wat we waardeerden aan het werk misschien aan het verdwijnen is.

We hoeven niet te kiezen tussen ontkenning en overgave.

De toekomst van software wordt niet bepaald door welk percentage van de code AI schrijft. Ze wordt bepaald in kleinere momenten: of we begrijpen voordat we accepteren, of we onderwijzen in plaats van alleen een antwoord doorsturen, of we de aandacht van een ander beschermen, en of we nog steeds verantwoordelijkheid nemen als de gegenereerde code de echte wereld bereikt.

AI mag blijven.

Wij moeten zorgen dat wij dat ook doen.

Stay in the loop

// Get the latest insights on AI teammates and collaboration.