AI-coding-agents goed aansturen: hoe u Claude Code als een regisseur dirigeert

De meeste mensen bedienen AI-coding-agents als een gokautomaat: verzoek erin gooien, aan de hendel trekken, op het beste hopen. Voor een snel concept volstaat dat. Voor alles wat betrouwbaar moet draaien, is het een recept voor frustratie. De doorslaggevende omslag: van gebruiker regisseur worden – de agent dirigeren dus, in plaats van hem te zien improviseren.

Dat geldt voor Claude Code, omdat dat momenteel het meest verbreide gereedschap is – maar net zo goed voor elk ander AI-gereedschap. En het geldt niet alleen voor programmeren: wie eenmaal begrepen heeft hoe je een agent netjes aanstuurt, kan er offertes mee calculeren, rapporten opstellen of hele bedrijfsprocessen automatiseren. Een achtergrond in software engineering is daarvoor niet nodig.

Van „vibe coding“ naar gestructureerd werken

De meest voorkomende fout heeft een naam: „vibe coding“. Je formuleert een verzoek, laat de agent lopen en controleert het resultaat nauwelijks. Precies de twee stappen die serieusheid uitmaken ontbreken – de planning vooraf en de validatie achteraf.

Een eenvoudig beeld is de bouw van een boomhut. Eerst tekent u een schets, bedenkt u hoeveel hout u waar nodig hebt en haalt u het juiste gereedschap. Staat de hut, dan zet u er niet zomaar de kinderen in – u test eerst of hij het houdt. Dezelfde discipline vraagt de omgang met coding-agents.

Dat wordt belangrijk omdat de modellen tot vleierij neigen. Vraagt u „Ziet dit er goed uit?“, dan komt er graag een „ja“, zonder dat het plan werkelijk kritisch is getoetst. Omgekeerd beweren modellen af en toe dat iets klaar is terwijl dat niet zo is. U hebt dus een eigen, onafhankelijke methode nodig om beide te controleren. Het proces heeft vier stappen:

• Plannen – met de nodige context vaststellen wat er gebouwd moet worden en hoe succes er concreet uitziet.
• Bouwen – de uitvoering zo ver mogelijk aan de agent delegeren.
• Verifiëren – een heldere, eigen manier hebben om het resultaat te toetsen.
• Systeem verbeteren – de vaak over het hoofd geziene vierde stap: uit elke doorloop een blijvende verbetering afleiden.

Verificatie: bewijs in plaats van bewering

Verificatie betekent in de kern: „Bewijs me dat het werkelijk klaar is.“ Bij programmeren zijn dat tests en linting – maar het principe laat zich op bijna alles overdragen. Voorbeeld zonder code: de agent maakt een diagram en rendert dat vervolgens als afbeelding. Omdat moderne modellen afbeeldingen uitstekend lezen, kan de agent zijn eigen werk bekijken, overlappingen herkennen en die zelfstandig in meerdere doorlopen verhelpen. De aanvankelijke fouten doen er niet toe; alleen het eindresultaat telt.

Het effect is meetbaar: zonder controlemechanisme ligt het eerste resultaat misschien op 65 tot 70 van de 100 punten. Met een ingebouwde controle is al bij de eerste poging ongeveer 92 mogelijk. Perfect is het zelden meteen – daar gaat het ook niet om. Het gaat erom de agent een kader te geven waarmee hij zijn werk zelf controleert. De leidende vraag luidt steeds: hoe kan de agent het resultaat toetsen zoals een echte gebruiker dat zou doen? Een blik op de gegenereerde code alleen volstaat nooit.

Wat is een „harness“?

Een harness is de schil om het AI-model heen – de gereedschappen en de context waar het model bij kan, zodat het weet waaraan het werkt. Stel het u voor als een lagenmodel: in het centrum staat het model als het eigenlijke „brein“. Daaromheen legt u een gereedschap als Claude Code. En daarbovenop bouwt u uw eigen laag – configuratie, Skills, hooks en koppelingen met CRM of takenbeheer. Juist die bovenste laag maakt van een generiek gereedschap uw systeem.

Planning: de onderschatte stap

De meesten plannen veel te weinig. Met coding-agents besteedt u meer tijd aan plannen dan aan bouwen, omdat u de uitvoering grotendeels uit handen geeft – het succes hangt daarmee rechtstreeks samen met de kwaliteit van het plan. Beproefd is één enkel document dat het doel beschrijft:

• Wat bouwen we – en waarom?
• Hoe ziet succes er concreet uit?
• Waaraan herkent de agent dat het werk klaar en correct is?
• Bij technische taken: welke plekken in het bestaande systeem moeten daadwerkelijk worden aangeraakt?

Het typische verloop: eerst context en relevante documenten verzamelen, dan onderzoeken, en daaruit samen met de agent het plan ontwikkelen. Heel belangrijk: laat de agent veel vragen stellen, zodat hij niet talloze aannames doet over het gewenste resultaat. Pas als hij gericht heeft doorgevraagd, zijn mens en agent het eens over wat er gedaan wordt en hoe het wordt getoetst.

Zich zeker voelen, ook zonder code te kunnen lezen

Hoe krijg je vertrouwen in code die je zelf niet leest? Er zijn twee wegen. Ten eerste: vraag de agent het geschrevene uit te leggen. Code oogt aanvankelijk intimiderend, maar leest na de eerste horde bijna als Engels. Ten tweede, als u helemaal niet wilt leren programmeren: vertrouwen ontstaat via de validatiestrategie. Juist daar ligt het verschil met vibe coding – u klemt de uitvoering tussen een zorgvuldig plan en een even zorgvuldige controle waarbij u zelf betrokken bent. Groen licht krijgt de agent pas als helder gedefinieerd is hoe hij aantoont dat het werk klaar is.

Context is schaars: de „dumb zone“

Bij het plannen is het belangrijkste de context te sturen, want de aandacht van een model is een schaarse hulpbron. Er circuleert het misverstand dat het niet uitmaakt hoeveel je de agent aandoet, omdat moderne modellen enorme contextcapaciteit hebben. De cijfers zijn indrukwekkend – maar er zijn twee beperkingen.

Ten eerste is de context sneller opgebruikt dan je denkt: leest de agent meerdere Skills of grotere hoeveelheden code, dan zijn er in een oogwenk tienduizenden tot honderdduizenden tokens verbruikt. Ten tweede is er de „dumb zone“. In het voorste deel van het contextvenster oogt het model scherp en op de hoogte van zijn kunnen. Overschrijdt het gesprek een bepaalde drempel, dan kantelt het: het model oogt overladen, ziet dingen over het hoofd en maakt fouten die bij verse context nooit waren voorgekomen.

Daarom moet u zorgvuldig afwegen wat u de agent vooraf geeft en wat hij zo nodig zelf mag ontdekken. Precies dat is de kracht van Skills: ze stellen procedures en best practices beschikbaar, maar het model beslist zelf wanneer het welke informatie nodig heeft. Kiep niet alles in één keer erin. Heel vaak ligt het probleem niet aan het model, maar aan de manier waarop de context gevuld wordt. Het grote contextvenster geeft dus een bedrieglijke zekerheid – het kritieke punt bereikt u het liefst helemaal niet.

Meerdere sessies orkestreren

Omdat de „dumb zone“ bestaat, kunt u grote taken niet in één enkele sessie gooien. Het antwoord is een workflow van meerdere agentsessies: één agent plant, geeft het document door aan een tweede voor de uitvoering, die schrijft een uitvoeringsrapport, en een derde valideert en toetst het werk. Bewerkelijk, maar voor productierijpe software of bedrijfskritische automatiseringen simpelweg nodig.

Het beeld daarvoor is een lopende band: elke agent doet één ding echt goed en draagt zijn resultaat zo over dat de volgende genoeg context heeft om te begrijpen wat er gedaan is, wat nog openstaat en wat zijn eigen taak is.

Een voorbeeld uit de B2B-praktijk: het opstellen van offertes, bijvoorbeeld in de bouw- of drukbranche. Zulke calculaties zijn bewerkelijk – inspanning schatten, materiaal bepalen, prijzen opzoeken, leveranciers kiezen. Hier bouwt men een workflow van gespecialiseerde agents: een controleert de voorraad, een vergelijkt prijzen, een ontwerpt de PDF. Aan het eind staat een validatie – bijvoorbeeld een berekening die toetst of de gewenste marge wordt gehaald. Wie het eigen werk serieus bekijkt, ziet snel dat het in veel kleine deeltaken uiteen te leggen is – en juist die opdeling levert direct enorme hefboomwerking op.

Veiligheid hoort in de techniek, niet in de prompt

Een bijzonder bedrieglijke zekerheid betreft de rechten. Velen geloven dat hun prompts bescherming genoeg zijn. Dat zijn ze niet. Zegt u tegen een agent dat hij nooit een database mag wissen, dan kan het toch gebeuren. Verbiedt u hem het wissen van een map, dan schrijft hij mogelijk een script dat precies dat doet.

De enige houdbare grondhouding luidt daarom: alles wat de agent kan lezen of aanraken, raakt hij vroeg of laat ook aan – zelfs ongevraagd. Rechten moeten technisch worden afgedwongen: via strak begrensde sleutels of doordat bepaalde dingen simpelweg onbereikbaar zijn. Een echt voorbeeld toont de valkuil: een agent begreep een regel op zijn takenlijst verkeerd – en verstuurde daarop een e-mail met een kortingscode naar de volledige verzendlijst, hoewel die er nooit uit had mogen gaan.

Een beproefd middel zijn hooks – kleine stukjes code die bij een bepaalde gebeurtenis worden uitgevoerd, bijvoorbeeld vlak voordat de agent een gereedschap gebruikt. Zo kunt u controleren of een commando netelig is en het blokkeren. Dezelfde hooks laten zich gebruiken om het systeem zelfstandig te verbeteren – bijvoorbeeld door aan het eind van elke sessie automatisch een samenvatting in een daglogboek te schrijven.

Van elke fout een blijvende upgrade

Misschien wel het belangrijkste is de systeemevolutie. Doet zich een probleem voor, los het dan niet gewoon op en ga verder – gebruik het samen met de agent als aanleiding om te vragen wat er verbeterd kan worden zodat het niet terugkeert. Misschien ontstaat er een nieuwe regel in uw configuratie, een extra planningsdocument of een aangepaste Skill. Zo wordt van elke bug een blijvende upgrade gemaakt.

Hebt u dit systeem eenmaal gevestigd, dan verwelkomt u fouten bijna. En voordat ze überhaupt optreden, helpt een eenvoudige vraag die bijna niemand durft te stellen: „Wat zou hier mis kunnen gaan?“ Laat de agent gericht randgevallen construeren en de toepassing met problematische invoer proberen te breken. Breekt er iets, dan hoort het terug in de controlelus: probleem vinden, verhelpen en – heel belangrijk – opnieuw testen. Misschien heeft de correctie het probleem helemaal niet opgelost.

De juiste houding tegenover het gereedschap

Behandel het gereedschap als een mentor – de slimste mens ter wereld die tegelijk uw beste vriend is. Het lacht u niet uit als u iets ogenschijnlijk doms vraagt. Maar niet alles leent zich als vraag: door de vleierij is het netelig een model naar zijn mening te vragen. Uitstekend leent het zich daarentegen om te begrijpen hoe iets werkt, of waar er empirische gegevens zijn – bij randgevallen werkt een automatisering met een bepaalde invoer, of nu juist niet. Geen grijs gebied. Wie een tweede perspectief nodig heeft, laat twee modellen tegen elkaar aantreden: het ene bouwt, het andere speelt in een aparte sessie de advocaat van de duivel in plaats van kritiekloos te prijzen.

Conclusie: denk als een productmanager

Het centrale advies tot slot: hoe technisch onderlegd u ook bent – beschouw uzelf als productmanager voor uw agent. U hoeft niet te beschrijven hoe iets gebouwd wordt. Maar u moet de visie vormgeven: wat bouwen we, en waarom? Geef het gereedschap het waarom mee – dat bepaalt het hoe verrassend sterk.

Dat is de eerlijke kern voorbij de hype: AI-agents zijn geen gokautomaat en geen wondermiddel. Ze zijn een krachtig gereedschap dat precies zo goed wordt als het kader dat u het geeft. Goede plannen, heldere toetscriteria en de discipline om van elke fout te leren – dat brengt u verder dan elk nieuw model. Begin klein: schrijf een van uw processen uit, ontleed het in deeltaken en definieer waaraan u herkent dat het resultaat klopt. De rest kunt u delegeren.

Bron: Dit artikel is gebaseerd op de video How to Build Effective Claude Code Agents in 2026 van Nate Herk | AI Automation. De inhoud is zelfstandig bewerkt en geduid voor de Nederlandstalige lezers.