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 tests komt, maar je weet niet of de structuur klopt.

Dit is vibe coding. Verleidelijk op korte termijn, maar je bouwt systemen die je niet volledig begrijpt en niet kunt debuggen als ze complex gedrag vertonen.

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 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 gevolgen, bedrijfscontext en domeinlogica, juiste abstracties kiezen, debuggen van onverwacht gedrag, en de kwaliteit van AI-code inschatten. Dit zijn taken waarbij AI een richting geeft, maar jij beslist.

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 kost ongeveer 15 minuten. Die tijd levert betere code op dan vage prompts plus iteraties, en dwingt je je gedachten te ordenen. Dat bijkomend voordeel is minstens zo waardevol als de code.

Een spec hoeft niet formeel te zijn. Kort tekstblok: probleem, randgevallen, beperkingen, aangrenzende systemen. Genoeg context zodat iemand jouw codebase niet kent er iets mee kan doen, want dat is exact de positie van een AI-tool.

Review intensiever, niet minder

AI-gegenereerde code ziet er correct uit, ook als het dat niet is. Stijl en structuur kloppen; variabelenamen zijn beschrijvend. Maar logica kan subtiele fouten bevatten.

De richtlijn: code die je niet zelf schreef vraagt zorgvuldige review, net als code van een junior developer. Je bent verantwoordelijk voor wat in de codebase terechtkomt, ongeacht wie het schreef.

Er is ook een risico. Als je minder code zelf schrijft en meer reviewt, raakt je codeerervaring ondergetraind. Dat schendt review-kwaliteit, want goede review vereist dat je hetzelfde zelf kunt schrijven. Besteed bewust tijd aan taken zonder AI-hulp, als kalibratie van je eigen vaardigheden.

Context bewaken

Een AI-tool werkt op wat je hem geeft. Hij kent je codebase, architectuurbesluiten, impliciete beperkingen niet. Verkeerde bestanden of verouderde context levert technisch correcte maar onpassende suggesties op.

In de praktijk: wees bewust van context. Voeg relevante bestanden toe (interfaces, modules, patronen) en verwijder verouderde context actief. Een AI-tool op een lang gesprek presteert slechter dan één met schone context en 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; AI als versnelling voor begrip wel.

Begrijp eerst wat je bouwt, gebruik dan AI om het sneller te realiseren.

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.