Ontwikkelaars die zijn begonnen met het gebruik van GitHub Copilot, ChatGPT of Cursor beschrijven vaak dezelfde honeymoonfase. Taken die voorheen twee uur duurden, kosten nu twintig minuten. Boilerplate verdwijnt met een druk op de tab-toets. Al snel begint er echter een stillere klacht naar boven te komen in forums en Slack-kanalen: uitputting. De tool schrijft de code, maar iets in het proces put je uit. Het probleem is niet de code zelf. Het is het werk dat gepaard gaat met het consumeren ervan.
De flessenhals waar niemand zich op voorbereidde
Decennialang was de beperkende factor in software engineering de typsnelheid. Hoe snel je ook dacht, je vingers en je kennis van syntaxis bepaalden het plafond. AI-assistenten hebben dat plafond doorbroken. Ze kunnen honderden regels over meerdere bestanden produceren voordat je het eerste blok hebt uitgelezen. Die snelheid klinkt als vrijheid, maar het creëert een onverwachte verkeersopstopping. Plotseling is het langzaamste deel van de pijplijn je vermogen om te lezen, te begrijpen en te verifiëren wat er zojuist op het scherm is verschenen. Je bent een fulltime code-reviewer van je eigen project geworden, behalve dat de auteur een algoritme is dat nooit slaapt en nooit moe wordt.
Deze omkering van arbeid verandert de textuur van een codesessie. In plaats van af te wisselen tussen creatie en lichte verificatie, zit je vast in een langdurige validatiemodus. En validatie is geen passief lezen. Het is een actieve, met achterdocht doordrenkte analyse. Elke variabelenaam, elke randvoorwaarde en elk importstatement moet een mentale filter passeren, omdat de AI geen verantwoordelijkheid draagt. De AI wordt niet om 3 uur 's nachts gebeld als de productie-job faalt.
Waarom je brein tegen een muur loopt
De vermoeidheid is geen luiheid. Het is een voorspelbare botsing tussen een overvloed aan output en de beperkte menselijke bandbreedte.
Volume-overbelasting. Een typische AI-suggestie kan een volledige React-component bevatten, inclusief de styling-logica, utility-functies en unit tests, allemaal in één keer. Je werkgeheugen kan maar een beperkte hoeveelheid informatie tegelijk vasthouden. Wanneer het scherm volstroomt met tientallen nieuwe regels, moet je brein deze ofwel comprimeren tot abstracte patronen, of ze sequentieel scannen. Beide strategieën kosten veel aandacht. Na het beoordelen van verschillende van deze blokken, treedt de mentale variant van spierpijn op. Je leest wel, maar je begrijpt het niet meer echt.
Het vertrouwensgat. AI-gegenereerde code ziet er gezaghebbend uit. De inspringing is perfect. Variabelennamen zijn logisch. Commentaar verschijnt zelfs op de juiste plaatsen. Maar gezag is niet hetzelfde als nauwkeurigheid. De code kan een verouderde API gebruiken, een edge case met null-inputs missen of een subtiele SQL-injectievector introduceren. Omdat je weet dat dit kan gebeuren, kun je niet vluchtig lezen. Je moet elk return-statement en elke logische vertakking inspecteren met de waakzaamheid van een security audit. Dat niveau van nauwgezetheid, urenlang volgehouden, is cognitief kostbaar. Het is dezelfde reden waarom beveiligingsmedewerkers op luchthavens in korte shifts werken: aanhoudende waakzaamheid neemt snel af.
Mismatch in workflow. De meeste ontwikkelomgevingen en teamprocessen gaan nog steeds uit van een menselijk ritme van schrijven en testen. De codebase groeit op menselijk tempo en code reviews vinden plaats in geplande batches. Wanneer AI in die pijplijn wordt geforceerd, raakt de flow gefragmenteerd. Je genereert twintig regels, pauzeert om te verifiëren, vraagt om een revisie, verifieert opnieuw, gaat naar de volgende functie en verliest de draad van de bredere architectuur. Het constante schakelen tussen creatieve generatie en sceptische validatie zorgt voor wrijving. Je IDE is ontworpen voor auteurs, niet voor redacteuren die onder een constante deadline werken.
De uitputtingsloop
Deze factoren voeden een cyclus die verergert naarmate de dag vordert.
De assistent spuugt in enkele seconden een feature-implementatie uit. Vervolgens besteed je vijftien minuten aan het traceren van imports, het controleren van type-compatibiliteit en het uitvoeren van mentale simulaties van edge cases. Tegen de derde of vierde ronde dooft je focus. Je begint snippets te accepteren die "er grotendeels goed uitzien". Fouten glippen erdoorheen. Om dit te compenseren, vertraag je, wat de snelheid die je in eerste instantie won, tenietdoet. Je eindigt de dag met meer ruwe code dan gebruikelijk, maar met minder vertrouwen in de code en een hoofdpijn die suggereert dat je harder hebt gewerkt, niet slimmer.
Wanneer snelheid gevaarlijk wordt
Als dit patroon een gewoonte wordt, reikt de schade verder dan een slechte middag.
Burn-out komt stilletjes. Het uit zich als een gevoel van tegenzin bij het openen van een project, of het onvermogen om nog naar een ander pastelkleurig codeblok te kijken zonder irritatie. Wanneer het primaire hulpmiddel dat je zou moeten helpen de primaire bron van vermoeidheid wordt, volgt er wrok.
Then there is skill atrophy. The muscle of translating intent into syntax weakens when you stop doing it. You might still architect systems well, but the granular fluency — knowing why a certain loop structure feels off, or recalling how a specific library behaves under load — fades when an autocomplete layer handles the details. Over time, you risk becoming a passive curator rather than an active engineer.
The most immediate danger, however, is sloppy deployment. Under pressure to maintain velocity, and exhausted by hours of reading machine output, developers sometimes deploy code they have not fully validated.