Hoe je werkwijze verandert als AI erbij komt

Voor wie? Developers die AI-tools al gebruiken — of overwegen te gebruiken — en merken dat de kwaliteit en snelheidswinst tegenvallen, of die zich afvragen hoe je dit goed inbedt in een teamcodebase.

Kort: AI-tools veranderen niet alleen wat je bouwt, maar hoe je het bouwt. De developers die er het meeste uithalen, passen hun werkproces aan in plaats van dezelfde stappen sneller uit te voeren. Dat proces werken we concreet door in de workshop Werkwijze met AI.

Je opent een AI-tool, schrijft een vage prompt, en krijgt code terug die er plausibel uitziet. Je plakt het erin, het werkt niet helemaal, je stuurt nog een prompt, de derde poging werkt. Vijftien minuten later heb je iets dat door de tests heen komt, maar je hebt weinig idee of de structuur klopt.

Dit is vibe coding. Het is verleidelijk, en het levert op korte termijn iets op. Op de langere termijn bouw je een systeem dat je niet volledig begrijpt en niet kunt debuggen als het complex gedrag vertoont.

De verschuiving die wél werkt is een andere: AI inzetten op de stappen waar het sterk is, en je eigen cognitieve ruimte bewaren voor de stappen waar jij sterk bent.

Waar AI sterk is, en waar jij het moet overnemen

AI-tools zijn genuineerd goed in een specifieke categorie van taken: boilerplate genereren, bekende patronen implementeren (auth, CRUD, validatie), documentatie schrijven vanuit bestaande code, eerste drafts van tests bouwen op basis van een implementatie, en code uitleggen die je niet kent.

Dat is een nuttige lijst. Maar er is ook een andere lijst.

Architectuurbeslissingen met lange termijnimplicaties, begrijpen van de bedrijfscontext en domeinlogica, beoordelen of een oplossing de juiste abstractie kiest, debugging van onverwacht gedrag in complexe systemen — en het inschatten van de kwaliteit van AI-gegenereerde code zelf. Dat zijn taken waarbij een AI-tool je een richting geeft, maar waarbij jij de beslissing draagt.

Het probleem ontstaat als je die grens niet trekt. Als je een AI-tool vraagt om een architectuurkeuze te maken en het antwoord overneemt zonder het te doordenken, heb je niet de tweede lijst gedelegeerd. Je hebt hem gewoon niet gedaan.

Specs schrijven in plaats van direct prompts

AI-tools produceren betere output als ze een duidelijke specificatie krijgen. Dat is geen geheim, maar de consequentie wordt onderschat.

Een goede spec schrijven voor een feature kost tien tot twintig minuten. Die twintig minuten leveren betere code op dan een vage prompt plus drie iteratieronden — en ze dwingen je ook je eigen gedachten te ordenen over wat je precies wil bouwen. Dat bijkomend voordeel is misschien wel even waardevol als de code die eruit komt.

Een spec hoeft niet formeel te zijn. Het kan een kort tekstblok zijn: welk probleem los je op, wat zijn de randgevallen, welke beperkingen gelden er, welke aangrenzende systemen zijn er. Genoeg context zodat iemand die jouw codebase niet kent er iets bruikbaars mee kan doen — want dat is precies de positie van een AI-tool.

Review intensiever, niet minder

AI-gegenereerde code ziet er correct uit, ook als het dat niet is. De stijl klopt, de structuur is vertrouwd, de variabelenamen zijn beschrijvend. Maar de logica kan subtiele fouten bevatten die je pas ziet als je de code echt leest.

De richtlijn is eenvoudig: code die je niet zelf hebt geschreven vraagt een even zorgvuldige review als code van een junior developer. Niet om de tool te wantrouwen, maar omdat de verantwoordelijkheid voor wat er in de codebase terechtkomt bij jou ligt, ongeacht wie of wat het heeft geschreven.

Er is ook een ander risico. Als je minder code zelf schrijft en meer reviewt wat een AI heeft gegenereerd, wordt je eigen codeerervaring minder getraind. Dat heeft een effect op de kwaliteit van je reviews — want een goede review vereist dat je zelf in staat bent om hetzelfde te schrijven. Het is de moeite waard om bewust tijd te besteden aan taken zonder AI-hulp, niet als nostalgie, maar als kalibratie van je eigen vaardigheidsniveau.

Context bewaken

Een AI-tool werkt op wat je hem geeft. Hij kent je codebase niet, je architectuurbesluiten niet, je impliciete beperkingen niet. Als je hem de verkeerde bestanden geeft, of verouderde context, krijg je suggesties die technisch kloppen maar niet passen in je systeem.

Dat betekent in de praktijk: wees bewust van wat je in de context laadt. Voeg relevante bestanden toe — de interfaces die je gebruikt, de aangrenzende modules, de bestaande patronen. En verwijder verouderde context actief als een sessie lang wordt. Een AI-tool die op een lang gesprek zit met tien iteraties van hetzelfde bestand gaat slechter presteren dan één die een schone context krijgt met de juiste informatie.

Als het team verdeeld is

Als één developer AI-tools gebruikt en de rest niet, ontstaan er stijlverschillen en inconsistente kwaliteit in de codebase. Niet omdat AI-tools per definitie slechtere code produceren, maar omdat er geen gemeenschappelijke standaard is voor wanneer je wat reviewt en hoe je AI-assisted code documenteert.

Nuttige afspraken om te maken: welke tools zijn goedgekeurd voor gebruik in de codebase? Welke code-reviews zijn verplicht voor AI-gegenereerde stukken? Hoe markeer je onderdelen die door een AI zijn geschreven en niet door een teamgenoot volledig zijn doorgenomen?

Dit gaat niet over het blokkeren van AI-tools. Het gaat over het bewaken van de kwaliteitsstandaard die je als team hebt.

De kern

AI als vervanging voor begrip werkt niet bij complexe systemen. AI als versnelling voor begrip wel.

Het verschil zit in de volgorde: begrijp eerst wat je wil bouwen, gebruik dan de tool om het sneller te realiseren. Niet andersom.

De werkwijzeverschuiving — specs, context, review, teamafspraken — werken we concreet door in de workshop Werkwijze met AI. Twee dagen, hands-on, met je eigen projecten als materiaal.