AI coding tools zijn overal. Cursor, GitHub Copilot, Claude Code — de kans is groot dat jouw development team er al mee werkt. De vraag is niet meer of je ze gebruikt, maar hoe.
Na het afgelopen jaar intensief werken met agentic coding tools ontdekten we bij Kabisa iets wat ons verraste: sneller code produceren is makkelijk. Sneller de juiste code produceren is een compleet ander verhaal.
Het verschil tussen AI tooling gebruiken en AI tooling goed gebruiken is groter dan je denkt. We maakten kostbare fouten, ontdekten patronen die ons werk fundamenteel veranderden, en leerden dat de tool zelf niet het verschil maakt, de discipline eromheen wel.
Dit is wat we leerden. Wat niet werkte. En wat wel.
Wat werkt niet?
Vage opdrachten, vage resultaten
Een agentic coding tool — een AI die zelfstandig code schrijft, test en aanpast — begint elke sessie met een schone lei. Geen geheugen van vorige gesprekken, geen impliciete kennis over je project. Geef je een vage opdracht, dan vult hij de gaten zelf in.
Bij een kleine codebase merk je dat nauwelijks. Maar zodra je project groeit, wordt het een probleem. Wij zagen een agent die bij elke sessie een andere teststrategie hanteerde. De ene keer unit tests, de andere keer integration tests, soms helemaal geen tests. Niet omdat de tool slecht was, maar omdat wij niet verteld hadden wat we verwachtten.
De eeuwige ja-knikker
AI agents zijn beleefd. Te beleefd. Bijna elk antwoord begint met “You’re absolutely right!”, ook als je er volledig naast zit. De agent bevestigt je aannames, bouwt voort op je foute redenering, en levert overtuigend klinkende code op die de verkeerde kant op gaat.
Dit is gevaarlijker dan het klinkt. Je voelt je productief. De code compileert. De tests slagen. Maar je hebt het verkeerde gebouwd, en de agent heeft je daar vrolijk bij geholpen.
Complexiteit als oplossing
“Dit kan beter!” hoor je vaak van een AI agent. En technisch heeft hij vaak gelijk: er is altijd een elegantere abstractie mogelijk. Maar niet alles wat technisch beter is, is ook daadwerkelijk beter.
Wij zagen een agent die voor drie configuratie-opties een volledig plugin-systeem voorstelde met dependency injection en event-driven architecture. Technisch indrukwekkend. Praktisch volkomen overdreven. Een AI agent optimaliseert voor technische elegantie, niet voor onderhoudbaarheid of time-to-market. Die afweging moet je zelf maken.
Bouwen zonder spelregels
Zonder expliciete projectregels interpreteert elke agent elke sessie opnieuw hoe je project werkt. Welke libraries gebruik je? Hoe ga je om met foutafhandeling? Welke code-conventies volg je? De agent raadt het wel, en raadt het elke keer anders.
Dit is het meest onderschatte probleem. Het voelt alsof je elke dag een nieuwe developer onboardt die geen documentatie heeft gelezen.
Wat werkt wel?
Een contract met je AI
De grootste verandering was simpel: opschrijven hoe we werken. Instructies die de agent bij elke sessie leest leggen we vast welke technologie stack we gebruiken, welke teststrategieën, welke code-conventies, welke commando’s. Geen documentatie voor mensen, maar een instructieset voor de AI.
Denk aan het als een onboarding-document voor een developer die geen impliciete kennis heeft. “Schrijf code in Ruby, volg de Airbnb style guide.” “Nieuwe features volgen het hexagonal architecture pattern.” “Gebruik Sidekiq voor achtergrondtaken, geen Active Job.”
Het resultaat: de agent gedraagt zich consistent. Minder aannames, meer voorspelbaar gedrag, kortere prompts, en vooral minder correcties achteraf. Het verschil tussen een junior die elke dag opnieuw moet leren hoe het team werkt, en een senior die de conventies kent.
Eerst denken, dan bouwen
In plaats van de agent direct code te laten schrijven, dwingen we hem eerst een gestructureerd proces te doorlopen. Begrijpen wat er gevraagd wordt. De bestaande codebase analyseren. Gerichte vragen stellen over details die je zelf niet had bedacht. Drie verschillende oplossingsrichtingen uitwerken. En pas dan de eerste regel code schrijven.
Dit kost 10 tot 15 minuten per taak voordat er code verschijnt. Dat voelt als vertraging. Maar die investering bespaart correctierondes achteraf. De eerste versie is vaker goed. En je vangt het over-engineering probleem op, omdat je bewust kiest uit meerdere oplossingsrichtingen in plaats van de eerste de beste te accepteren.
Specialisten in plaats van generalisten
In plaats van één AI agent alles te laten doen, werken we met sub-agents — gespecialiseerde agents met een specifieke rol en duidelijke beperkingen. Een code explorer die de codebase analyseert maar niets mag aanpassen. Een architect die oplossingen ontwerpt. Een reviewer die achteraf de kwaliteit controleert.
Die reviewer is cruciaal. Hij vangt de confirmation bias op. Waar de eerste agent klakkeloos meeging met jouw redenering, kijkt de reviewer met frisse ogen naar het resultaat. Een ingebouwd controlemechanisme.
Herhaalbare kwaliteit door skills
Een skill is een voorgedefinieerde expertise die een agent automatisch activeert bij bepaalde taken. Denk aan een front-end design skill die precies weet welk design system je project gebruikt, of een database skill die weet hoe je schema eruitziet.
Het verschil met handmatig instructies geven: skills zijn consistent. Ze werken elke keer hetzelfde, ongeacht wie in het team de agent aanstuurt. Dat maakt de output voorspelbaar en de kwaliteit herhaalbaar, onafhankelijk van hoe ervaren je bent met de tooling.
Kleine taken, scherpe context
Een AI agent presteert het best binnen een beperkt blikveld. Hoe meer je in één sessie propt, hoe voller de context loopt en hoe vager de antwoorden worden. Wij noemen dat uit de ‘smart zone’ raken: het punt waarop de agent details mist, eerdere instructies vergeet of de draad kwijtraakt.
De oplossing is dezelfde als bij mensen: knip grote taken op in kleine, afgebakende stukken. Een taak die binnen een overzichtelijke context past, houdt de agent scherp. En het voordeel reikt verder dan de AI alleen. Kleine taken zijn ook voor jezelf behapbaar, en voor je teamgenoten makkelijker te volgen en te reviewen. Een kleine, duidelijke wijziging begrijpt iedereen, of het nu een mens of een agent is die ernaar kijkt.
Wat levert dit voor jou op?
De rekensom is simpel. Tijd investeren in vragen stellen vooraf bespaart correctierondes achteraf. Expliciete projectregels betekenen dat de agent consistent bouwt. Gespecialiseerde agents vangen elkaars blinde vlekken op.
Het verschil merkten we snel. Minder heen-en-weer met de agent. Minder tijd kwijt aan het bijsturen van output. Code die sneller door review komt omdat de conventies al kloppen. Niet spectaculair, wel consistent.
En misschien wel het belangrijkste: technische expertise wordt niet minder belangrijk, maar juist belangrijker. Iemand moet de ja-knikker doorzien. Iemand moet herkennen wanneer een elegante abstractie in werkelijkheid over-engineering is. Iemand moet beoordelen of “technisch beter” ook echt beter is voor dit project. Een AI versnelt een goede developer, hij vervangt er geen.
Het verschil zit niet in welke tool je gebruikt. Het zit in de discipline eromheen. Goede context, een gestructureerd proces, en de bereidheid om kritisch te blijven op wat AI oplevert.
Bij Kabisa investeren we daar bewust in. Wil je sparren over hoe AI tooling jouw ontwikkelingsproces kan verbeteren? Neem contact met ons op.
PS: tegen de tijd dat je dit leest, is deze post alweer twee weken oud, en in AI-jaren dus volledig achterhaald. De helft van wat hierboven staat doen we inmiddels alweer net iets anders. Maar de discipline eromheen? Die veroudert niet ;)
