Waarom 'overkill'-vaardigheden leiden tot AI-workslop in plaats van Deep Work

Ik ben altijd op zoek naar manieren om mijn proces te optimaliseren. En om eerlijk te zijn: precies dat gedrag is wat ertoe leidt dat ik tegenwoordig AI-workslop produceer.

De term is niet van mij. Onderzoekers van BetterUp Labs en het Social Media Lab van Stanford introduceerden het begrip in de Harvard Business Review in september 2025. Het verwijst naar door AI gegenereerd werk dat er gepolijst uitziet, maar inhoudelijk niets bijdraagt aan de voortgang van de taak. Uit hun onderzoek bleek dat 40% van de Amerikaanse kantoormedewerkers met dergelijke output te maken had gekregen, en dat elke instantie gemiddeld twee uur reparatiewerk kostte.

Ik test veel plugins en vaardigheden: RPI-workflows, gstack, de Claude Code-setup van Garry Tan, en drieentwintig vaardigheden die rollen vervullen als CEO, designer, engineering manager, QA-lead en release engineer. Ik heb zelfs mijn eigen 'decision-ledger'-vaardigheid gebouwd. Er zijn gevallen waarin niets hiervan productief is, en gevallen waarin het actief complexiteit toevoegt.

Terugblikkend naar een paar jaar geleden, voordat AI verscheen: ik was een van die ontwikkelaars die voor grote bedrijven werkten. En ik was een van die ontwikkelaars die nooit begrepen waarom er tien mensen in een vergadering nodig waren om de kleur van een UI-knop te bepalen.

Vandaag de dag betrap ik mezelf erop dat ik me precies zo gedraag. Dat komt door twee redenen:

1. Ik weet dat AI een workflow nodig heeft, anders krijg je 'slop' en beslissingen zonder context.
2. Ik denk dat mijn proces vanaf de eerste regel van mijn specificatie perfect moet zijn, anders ziet het project er AI-gegenereerd uit en is de code waardeloos.

Beide aannames zijn tot op zekere hoogte waar; ik heb ze zelf ervaren.

De pijn van het lanceren van een SaaS met AI als ontwikkelaar

Ik lanceerde Getzatjob, mijn eerste AI-SaaS, om aan een specifieke behoefte te voldoen: het identificeren van sterke en zwakke punten voor een sollicitatie en het vinden van de juiste positionering in het cv om door ATS-screenings te komen. Terugkijkend was dit project mijn zandbak. Het werd snel een stapel AI-gecodeerde functies die ik zelf nooit wilde lezen, en in het begin bleef ik mezelf vertellen: "het maakt niet uit". Dat was echte vibe coding, en eerlijk gezegd is dat pijnlijk. En de UI was ook niet best.

Ik ontwikkelde het door een reeks prompts af te vuren zonder ooit iets te verifiëren, met "het werkt prima" als enige argument. Pas toen de eerste golf bugs kwam, realiseerde ik me dat het product een puinhoop was en dat het vanaf de allereerste regel code herstructureerd (refactoring) moest worden.

Toen ik besloot om Getzatjob V2 te bouwen — nu Applyzi genoemd — begon ik gstack te gebruiken en gaf ik de tool veel meer informatie over mijn manier van coderen. Mijn motto was: ik wil een product waarvan ik de code begrijp, gecodeerd op de manier waarop ik het zelf zou doen, en dat er goed genoeg uitziet zodat een recruiter bij een AI-bedrijf zou denken: "deze persoon levert een product met de kwaliteit die wij van ons eigen team zouden verwachten."

Op die manier had ik plezier in het werk.

Het andere grote verschil was het tempo van levering. Bij Getzatjob stond 80% van het project in minder dan 24 uur. Dat is de belofte die je op sociale media ziet. Geweldig. Maar daarna kostte het me weken om functies te stapelen en garbage-code te dupliceren bovenop luie prompting.

Bij Applyzi duurde het drie tot vier weken van planning en controle over elke functie, waarbij ik meer credits uitgaf om React-componenten herbruikbaar te maken. Precies zoals ik dat vroeger deed. Het kostte me vooraf meer tijd, maar na drie maanden is het project onderhoudbaar en schaalbaar, en ben ik niet bang om delen ervan zelf opnieuw te coderen.

Wanneer workslop in beeld komt

Ik moest een functie ontwikkelen voor een project van een klant waar ik sinds 2021 aan werk, lang voor de AI-hype. De taak was: wat data toevoegen aan een bestaand scherm en één extra scherm toevoegen. Vijf of zes bestanden waren beïnvloed. Mijn gebruikelijke workflow bij UI-integraties is als volgt: ik maak een screenshot van Figma (geen Figma Premium, dus geen MCP) en geef dit aan Claude.

Daarna ga ik naar mijn git-geschiedenis in VS Code, bekijk de gewijzigde bestanden, lees ze, voeg handmatige correcties toe en ben klaar. Totaal dertig minuten: tien minuten AI en twintig minuten polijsten. In plaats van een uur als ik het volledig handmatig had gedaan.

Als experiment probeerde ik nu de RPI-methode: Research → Plan → Implement, met een validatiepoort bij elke fase. RPI is niet één prompt; het verdeelt drieentwintig agent-vaardigheden over deze fasen. Op papier is het een goede workflow. In de praktijk was het voor mijn zes bestanden pure overkill. De AI besteedde minuten aan het identificeren van "pain points" in het project, las de volledige codebase, sprak zichzelf gaandeweg tegen en leverde uiteindelijk dit op:

Bestand	Regels	Inhoud
pm.md	730	12 user stories, 19 acceptatiecriteria, 8 gearbiteerde PO-vragen
ux.md	813	3 flows, 14 states, 40 i18n keys
eng.md	1385	API-contract, types, echte code, 12 risico's
PLAN.md	490	5 fasen, 44 taken

Dat zijn drieduizend vierhonderd achttien regels aan planning. Het eigen oordeel van de AI: medium complexiteit, 13 nieuwe bestanden, 9 gewijzigde bestanden, zeven tot tien mandagen werk.

Ik had het in dertig minuten opgeleverd door zes bestanden aan te passen.

Kijk eens naar wat de researchfase daadwerkelijk doet: een requirement-parser, een productmanager, een UX-designer, een technisch CTO-adviseur, een senior software engineer en een documentatieschrijver. Zes rollen om data aan één scherm toe te voegen.

Ik deed een stap terug en zei tegen mezelf: dit is de vergadering met tien mensen voor de kleur van een knop. Niet dezelfde ruimte, wel dezelfde foutmodus. Meer rollen en meer artefacten dan de beslissing vereiste.

De HBR-definitie gaat over werk dat aan een collega wordt overhandigd. In mijn geval werd het aan mijzelf overhandigd, door mezelf. Daarom wil ik de definitie iets verbreden: frameworks zoals RPI of gstack produceren hetzelfde resultaat wanneer ze worden ingezet voor een probleem dat te klein voor hen is. Analyse die niemand nodig had, planning die niemand zal lezen, en kosten voor het opruimen die betaald worden door de enige persoon in de kamer. De site die je nu leest is gebouwd met Claude zonder enige extra vaardigheden, geen RPI, geen gstack, niets. Het had ze niet nodig; het toevoegen ervan zou precies dit resultaat hebben opgeleverd.

Het lezen van het AI-rapport was pijnlijker dan het zelf schrijven van de code.

Om duidelijk te zijn: ik zeg niet dat de tooling slecht is. RPI en gstack zijn virtuele engineeringteams, en een virtueel engineeringteam is precies wat nodig is voor een volledige herbouw van een product. Dat is wat Applyzi succesvol maakte. Zes bestanden aanpassen is geen productherbouw. Hetzelfde ritueel, maar de verkeerde probleemgrootte.

Boris Cherny, de maker van Claude Code, zegt dat hij inmiddels over het algemeen vertrouwt op het model om de juiste commando's uit te voeren en de juiste wijzigingen aan te brengen, en dat hij alleen naar het uiteindelijke resultaat kijkt. Vertrouw op de AI.

Maar als je dezelfde discussies tot het einde leest, is de belangrijkste tip altijd hetzelfde: zorg dat Claude een manier heeft om zijn werk te verifiëren. Vertrouwen sluit controle dus niet uit. Het betekent simpelweg dat de controle bestaat uit verificatie, en niet uit een plan van vijftig pagina's dat geschreven is voordat er één regel code staat.

AI-processen zijn non-deterministisch, net als AI zelf. Er is geen enkele manier van werken die bij elk project past; dat wordt ook door het Claude Code-team bevestigd. Boris beschrijft zijn eigen setup zelfs als "verrassend vanilla". De persoon die de tool heeft gebouwd, past hem nauwelijks aan. Ondertussen stapelde ik RPI bovenop vaardigheden bovenop plugins voor een wijziging in zes bestanden.

Mijn project uit 2021, handmatig gebouwd zonder AI, heeft geen complexe AI-workflow nodig. Het heeft een prompt nodig, een screenshot en menselijke controle vóór de commit.

Deep Work is relevanter vandaag dan toen het verscheen

Het boek van Cal Newport komt nu harder aan dan toen het werd gepubliceerd. Mensen doen meer dan ze zouden moeten doen, en meer dan ze daadwerkelijk kunnen.

Het beste voorbeeld is LinkedIn. Open je feed, kijk naar de laatste vijf posts en vertel me hoeveel er met de hand zijn geschreven en echte informatie bevatten van iemand die een vaardigheid beheerst. AI geeft mensen de illusie van productiviteit: AI-geschreven posts, gecategoriseerd onder "expertise delen".

Zoals ik al zei: de tien mensen in de kamer voor de kleur van een knop hadden geen AI nodig om daar te komen. Maar AI vergroot het canvas voor dat soort werk.

Niets hiervan betekent dat AI alleen maar ruis toevoegt. Het stelt me ook in staat om dingen te bouwen die ik anders nooit zou zijn begonnen, omdat ze teveel tijd zouden kosten. Bijvoorbeeld een motion design-stuk om een functie van mijn SaaS uit te leggen, dankzij Hyperframes. Ik zou nooit aan short-form content zijn begonnen als AI me niet had kunnen helpen met het schrijven van het script en het genereren van het motion design. Dat deel is echt, en dat is geen workslop.

De juiste vraag om jezelf te stellen is: zal de taak die ik met AI uitvoer over dertig dagen nog steeds relevant zijn? Doe ik iets wat ik ook zonder AI zou hebben gedaan? Neem afstand en kijk hoe je het project bouwt, en vraag jezelf tegelijkertijd af waarom je het bouwt.

***

Bronnen

• Kate Niederhoffer, Gabriella Rosen Kellerman, Angela Lee, Alex Liebscher, Kristina Rapuano en Jeffrey T. Hancock, AI-Generated “Workslop” Is Destroying Productivity, Harvard Business Review, 22 september 2025. Onderzoek uitgevoerd door BetterUp Labs met Stanford’s Social Media Lab.
• Shan Raisshan, claude-code-best-practice. De RPI-workflow en de citaten van Boris Cherny.
• Garry Tan, gstack.
• Cal Newport, Deep Work, Grand Central Publishing, 2016.
• HeyGen, hyperframes.