Hoe je AI-codeeragenten als een pro aanstuurt

Hoe je AI-codeeragenten als een pro aanstuurt

Ongeveer zes maanden lang had ik de verkeerde functietitel in mijn eigen hoofd. Ik dacht dat ik een ontwikkelaar was die Claude Code gebruikte. Toen brak ik om 23:00 uur een productiebuild, traceerde het terug naar één enkele regel die de agent had geschreven en die ik nooit echt had gelezen, en besefte de waarheid: ik was een passagier geweest. Zittend in de bestuurdersstoel, handen bij het stuur, maar vooral hopend dat de auto op de weg bleef.

De oplossing was geen beter model. Opus 4.8 draaide al. De oplossing was een andere rol. Ik stopte met proberen code te schrijven via de agent en begon de agent te regisseren — zoals een filmregisseur de camera niet bedient maar verantwoordelijk is voor elk beeld. Die verschuiving, meer dan welk promptsjabloon of plugin dan ook, is wat de hoeveelheid echt, leverbaar werk die ik uit een dag haal verdubbelde.

Dit is het deel dat niemand in de gladde demovideo's stopt. Om AI-codeeragenten goed aan te sturen, besteed je meer tijd aan plannen dan aan bouwen. Je beheert de aandacht van de agent alsof het een schaarse hulpbron is, want dat is het ook. Je bouwt steigers eromheen zodat het zijn eigen werk kan controleren. En je behandelt elke mislukking als een kans om het systeem permanent te upgraden in plaats van als eenmalige ergernis.

Veel van wat mijn denken reorganiseerde kwam uit een podcastinterview dat ik steeds terugspoelde — Cole Medin, een software-engineer die AI-bouwer werd en een van de scherpere stemmen over agentisch coderen. Hij kadert Claude Code niet als een codegenerator maar als een "AIOS," een AI-besturingssysteem dat je koppelt aan hoe je daadwerkelijk een bedrijf runt. Die kadering klonk groots totdat ik het begon toe te passen. Toen klonk het gewoon correct.

Hier is alles wat ik heb veranderd aan hoe ik mijn agenten run — wat werkte, wat me brandde, en de exacte gewoonten die ik nu weiger over te slaan.

Waarom AI-codeeragenten aansturen beter werkt dan ze prompten

Een AI-codeeragent aansturen betekent eigenaarschap nemen over de intentie, het plan, de succescriteria en de verificatie — en de agent het typen laten doen. De prompt is het kleinste deel van het werk. Het denken rondom de prompt is waar de hefboom zit.

De meeste mensen die zeggen dat Claude Code "niet werkt voor echte projecten" zitten vast in promptmodus. Ze openen een sessie, typen een alinea, kijken hoe het genereert, en beoordelen het gereedschap op het eerste wat het uitspuugt. Als die eerste poging fout is — en dat is het meestal bij alles wat niet triviaal is — concluderen ze dat de agent dom is. Ik deed precies dit maandenlang.

De herkadering is brutaal maar bevrijdend: de agent is niet je collega-engineer. Het is een buitengewoon snelle, buitengewoon letterlijke junior die alles heeft gelezen en niets onthoudt over jouw project tenzij je het vertelt. Je taak is niet om ermee te chatten. Je taak is om zijn productmanager te zijn. Je voert het waarom achter elke taak in, stelt de grenzen, definieert hoe "klaar" eruitziet, en inspecteert de output tegen een standaard die je van tevoren hebt bepaald.

Cole noemt de kernvaardigheid hier iets wat ik nu constant gebruik: de AI behandelen als een mentor terwijl jij optreedt als zijn productmanager. Je vraagt het niet om uit te zoeken wat het moet bouwen. Je overhandigt het een specificatie zo duidelijk dat een letterlijk denkende junior het niet verkeerd kan lezen, en controleert het resultaat zoals een PM een feature controleert tegen het ticket.

Toen ik dat eenmaal had geïnternaliseerd, was de vraag niet meer "wat is de perfecte prompt?" maar werd het "wat heeft deze agent nodig om te slagen, en hoe weet ik of het gelukt is?" Die twee vragen reorganiseren je hele workflow. De eerste gaat over context. De tweede over verificatie. We besteden het grootste deel van deze post aan precies die onderwerpen.

Maar voordat een van beide ertoe doet, moet je de enkele beperking begrijpen die alles wat een agent doet beheerst: hoeveel het daadwerkelijk tegelijk kan opletten.

De "domme zone": waarom een contextvenster van 1 miljoen tokens tegen je liegt

Hier is de duurste misvatting in agentisch coderen, en ik hield het langer vol dan ik wil toegeven: een groter contextvenster betekent dat je meer kunt dumpen en het model het prima afhandelt.

Dat doet het niet. Opus 4.8 wordt geleverd met een contextvenster van 1 miljoen tokens — dat is hetzelfde venster dat Anthropic behield in de 4.x-lijn, bevestigd bij de 4.8-release op 28 mei 2026. Een miljoen tokens klinkt als oneindige speelruimte. Maar het aantal dat je erin past en het aantal waarover het model nauwkeurig kan redeneren zijn niet hetzelfde getal, en het gat ertussen is waar projecten stilletjes uit elkaar vallen.

Wat Cole de domme zone noemt komt precies overeen met wat ik in de praktijk zie: ergens voorbij ruwweg 250.000 tokens aan opgebouwde context begint de nauwkeurigheid af te nemen. Niet catastrofaal — dat is de valkuil. Het model geeft geen foutmelding. Het wordt gewoon subtiel slechter. Het begint een beperking te vergeten die je veertig berichten geleden hebt ingesteld. Het leest een bestand verkeerd dat het een uur eerder correct las. Het "helpt" door iets te bewerken dat je expliciet had gezegd met rust te laten. Het venster is niet vol, dus je neemt aan dat het goed gaat. Dat is het niet. Je zit in de domme zone.

Ik leerde dit op de harde manier bij een Laravel-refactor over mijn merksites. Ik hield één lange sessie aan gedurende het grootste deel van een middag, voedde het bestand na bestand, vertrouwend op het enorme venster. Rond uur drie begon de agent een bug opnieuw te introduceren die ik twee uur eerder had laten fixen — omdat die fix nu begraven lag onder 300K tokens aan daaropvolgende ruis, en het de les effectief had "vergeten" terwijl het gesprek het technisch gezien nog steeds bevatte.

De regel die ik nu volg is bot: houd de context bewust slank. Behandel het bruikbare werkvenster als veel kleiner dan het geadverteerde. Drie gewoonten handhaven dit:

• Wis agressief tussen ongerelateerde taken. Op het moment dat één logisch stuk werk klaar is, reset ik in plaats van de bagage ervan mee te nemen naar het volgende. Ik schreef het hele argument hiervoor in mijn analyse van de Claude Code slash-commando's die ik dagelijks echt gebruik — /clear is degene die ik zou behouden als ik er maar één mocht houden.
• Laat de agent niet lezen wat het niet nodig heeft. Elk bestand dat het opent om "de codebase te begrijpen" zijn tokens die worden uitgegeven en aandacht die wordt verdund. Wijs het naar de drie bestanden die ertoe doen, niet naar de hele repo.
• Zet duurzame kennis in CLAUDE.md, niet in de chat. Architectuur, conventies, schema — dat hoort thuis in projectgeheugen waar het een clear overleeft en niet verrot in een afdrijvend gesprek.

De domme zone is waarom elke geavanceerde techniek in deze post bestaat. Harnesses, sub-agenten, de Ralph-loop — haal het jargon weg en het is allemaal dezelfde zet: houd de context van elke individuele agent klein genoeg om scherp te blijven. Als je dat eenmaal ziet, is de rest van de architectuur logisch.

Dus als context de beperking is, waar gaat het werk dan eigenlijk heen? Naar planning — lang voordat er ook maar één regel wordt geschreven.

Plan meer dan je bouwt: de specificatie is het echte werk

De meest contra-intuïtieve les: hoe beter ik word in het aansturen van agenten, hoe minder van mijn tijd gaat naar het bekijken van hoe ze coderen en hoe meer naar het plannen voordat ze beginnen. Bij een betekenisvolle feature besteed ik nu het merendeel van mijn actieve tijd aan de specificatie en bijna niets aan het oppassen op het bouwproces.

Dit voelt verkeerd als je bent opgegroeid met het schrijven van code met de hand, waar planning een belasting was die je betaalde voor het "echte" werk. Met agenten keert het om. De agent typt in minuten. Het plan bepaalt of die minuten iets produceren dat je verscheept of iets dat je weggooit. Het plan is het echte werk.

Een specificatie die een agent daadwerkelijk aanstuurt heeft vier delen, en ik ben ze alle vier expliciet gaan schrijven:

1. Intentie — het waarom. Niet alleen "bouw een factureringspagina" maar "bouw een factureringspagina zodat bestaande klanten van tier kunnen upgraden zonder contact op te nemen met de klantenservice, omdat supporttickets voor upgrades twee uur per dag kosten." Als de agent het waarom kent, neemt het betere microbeslissingen over de duizend dingen die je niet hebt gespecificeerd. Cole noemt dit intentiebouw, en het is de zin met de meeste hefboom in elke prompt. De agent vult hiaten in de richting van je verklaarde intentie in plaats van te gokken.
2. Het plan — het hoe. De betrokken bestanden, de volgorde van bewerkingen, de aanpak die je hebt gekozen en de aanpakken die je hebt afgewezen. Ik specificeer liever te veel dan dat ik halverwege de bouw ontdek dat de agent een architectuur heeft bedacht die ik nooit zou hebben goedgekeurd.
3. Succescriteria — de definitie van klaar. Concrete, controleerbare voorwaarden. "Tier-upgrade werkt het abonnement bij in Stripe, wordt onmiddellijk weergegeven in het dashboard, en stuurt geen dubbele webhook." Als ik de succescriteria niet kan schrijven, begrijp ik de taak niet goed genoeg om te delegeren.
4. Validatiestrategie — hoe het wordt gecontroleerd. Bepaald voor de bouw, niet erna. Welke unittests, welke browserstroom, welke handmatige controle. Hier gaan we zo dieper op in omdat dit is waar de echte betrouwbaarheid vandaan komt.

Een opmerking over tooling, omdat Cole dit benoemde en ik het ben gaan delen: hij geeft de voorkeur aan het schrijven van zijn eigen gecontroleerde planningsprompts boven volledig leunen op ingebouwde planmodi, voor de flexibiliteit. Ik gebruik de planmodus van Claude Code constant — het is oprecht goed, en de planningsfase krijgt nu zijn eigen toegewijde agent zodat onderzoek de hoofdcontext niet vervuilt. Maar voor alles wat lastig is, schrijf ik handmatig een specificatie als een markdownbestand en laat de agent daartegenaan uitvoeren, omdat ik elk woord ervan beheers. De ingebouwde modus is het snelle pad; de aangepaste specificatie is het precieze pad. Gebruik het snelle pad totdat precisie ertoe doet, schakel dan over.

Hier is het deel dat me verraste. Het zo grondig schrijven van de specificatie vertraagde me over het geheel genomen niet. Het verplaatste mijn denken naar eerder, waar het goedkoop is, in plaats van naar later, waar een verkeerde aanname het uithalen van afgewerkte code betekent. Als je ooit het gevoel hebt gehad dat Claude Code het "bijna" had maar het punt bleef missen, is het ontbrekende stuk bijna altijd een dunne specificatie.

Nu — zelfs een perfecte specificatie levert een eerste versie op die vaker fout dan goed is. Dat is geen falen van planning. Het is gewoon de bodem. De vraag is hoe je van die bodem naar iets betrouwbaars komt.

Hoe verifieer je of door AI gegenereerde code werkelijk correct is?

Je verifieert door AI gegenereerde code door geautomatiseerde controles te bouwen die de agent tegen zijn eigen output uitvoert — unittests, browserautomatisering en aangepaste harnesses — zodat het zijn eigen fouten vangt en repareert voordat jij het ooit beoordeelt. Eerste-poging agentoutput scoort rond de 65–70% correct op echte taken; een solide zelfverificatielaag duwt dat voorbij 92%. Die sprong is het hele spel.

Laat die cijfers even bezinken, want ze herkaderen alles. Als je de eerste poging vertrouwt, verscheep je werk dat twee derde van de tijd klopt. Als je de agent zichzelf laat controleren, verscheep je werk dat negen van de tien keer klopt — zonder meer van jouw aandacht te besteden. De agent doet het herwerk. Je hoeft het alleen maar een spiegel te geven.

De verificatielaag heeft drie niveaus die ik nu ruwweg in deze volgorde bouw:

Unittests. De basislijn. Ik laat de agent tests schrijven tegen de succescriteria, ze uitvoeren, en fixen wat faalt — in een loop, zonder mij. Het punt is dat de tests de specificatie vastleggen, niet wat de agent toevallig heeft geïmplementeerd. Tests die achteraf zijn geschreven bevestigen alleen de bugs van de agent. Tests die vanuit de succescriteria zijn geschreven vangen ze op.

Browserautomatisering. Voor alles met een UI zijn unittests niet genoeg. Ik koppel Playwright zodat de agent daadwerkelijk de pagina kan bedienen — klik op de upgradeknop, bevestig dat het dashboard bijwerkt, controleer of er geen dubbele webhook is afgevuurd. De agent ziet het werkelijke gedrag in plaats van er abstract over te redeneren. Deze enkele toevoeging loste een hele categorie van "het slaagde voor tests maar de knop deed niets"-fouten op.

Aangepaste harnesses. Dit is de geavanceerde zet en degene die me deed glimlachen toen ik Cole het voor het eerst hoorde beschrijven. Soms kan het ding dat je bouwt niet worden gecontroleerd door een normale test — het is interactief, real-time of visueel. Zijn voorbeeld bleef me bij: om een agent een videogame te laten debuggen, vertraagde hij de framerate van de game zodat de agent de tijd had om elk frame te observeren en te reageren. Dat is een harness — een op maat gemaakte opstelling die de gebruiker simuleert en de agent laat waarnemen en reageren op wat er daadwerkelijk gebeurt. Het principe generaliseert: als de agent iets niet kan verifiëren, bouw het een manier om dat ding waar te nemen, en nu kan het dat.

Dit is ook precies het soort oordeel dat het aansturen van een agent onderscheidt van het oppassen op een agent. Ik ging dieper in op de omringende tooling in mijn stuk over de tools die Claude Code's AI-baggerwerk fixen — het meeste "baggerwerk" is geen modelprobleem, het is een ontbrekende verificatielaag.

Als je deze steigers liever niet zelf bouwt, is dit precies het soort agentische infrastructuur dat mijn team opzet voor klanten — het ontwerpen van de specificatie-, verificatie- en harnesslaag zodat de agenten betrouwbaar blijven in productie. Je kunt het soort builds dat ik aanneem bekijken op fiverr.com/s/EgxYmWD.

Zodra één agent zichzelf betrouwbaar kan verifiëren, opent zich een groter idee: wat als je er meerdere aan elkaar koppelt, elk in zijn eigen slanke context, en schoon werk door de lijn geeft?

Harness-engineering en de Ralph-loop

Een harness, in deze wereld, is de orkestratielaag rond je agenten — hoe je ze runt, in welke volgorde, met welke overdrachten, en welke controles ertussen draaien. Cole kadert het als de fundering die je eerst bouwt, met een "AI-laag" van skills, hooks en MCP-servers erbovenop gestapeld. Krijg de harness goed en alles erboven wordt betrouwbaarder.

De reden dat harnesses ertoe doen komt rechtstreeks terug bij de domme zone. Een enkele agent die door een grote taak maalt, accumuleert context totdat het degradeert. Maar als je het werk opsplitst in fasen en elke fase zijn eigen agent geeft met zijn eigen verse context, dwaalt geen enkele agent ooit af naar de domme zone. Elk doet één taak scherp, en draagt dan over.

De schoonste versie hiervan is wat de gemeenschap de Ralph-loop noemt — een techniek oorspronkelijk gepopulariseerd door Geoffrey Huntley in 2025, nu ingebakken in Claude Code-patronen. Stel je een lopende band voor. Eén agent plant. Het geeft een schone specificatie door aan een tweede agent die implementeert. Die geeft door aan een derde die test en fixt. Elk station bezit één fase, ontvangt schone input, produceert schone output, en cruciaal begint vers — zodat de contextopbouw van de planningsfase nooit de testfase bezwaart.

Ik draai nu constant een handmatige versie hiervan. Zelfs zonder fancy orkestratie houdt de discipline van "plannen in één sessie, wissen, implementeren in de volgende, wissen, verifiëren in een derde" elke stap scherp. De dynamische workflows van Opus 4.8 brachten dit verder — een enkele sessie kan nu veel parallelle sub-agenten opstarten, elk met zijn eigen contextvenster, en de resultaten aggregeren. Ik heb uiteengezet wat dat ontsluit in mijn walkthrough van Claude Code's dynamische workflows.

Sequentieel vs. parallel is de keuze die je maakt met een harness:

• Sequentieel (de Ralph-loop) wanneer elke fase afhankelijk is van de vorige — plannen, dan bouwen, dan testen. Schone overdrachten, geen drift, draait lang autonoom.
• Parallel wanneer het werk splitst in onafhankelijke stukken — drie sub-agenten die tegelijkertijd drie verschillende bibliotheken onderzoeken, en dan rapporteren. Sneller, maar ze kunnen niet gemakkelijk met elkaar communiceren, dus ze zijn het best voor uitzwerm-dan-verzamel-werk.

Eerlijke kanttekening: harness-engineering is het punt waarop dit ophoudt casual te zijn. Je schrijft nu orkestratie, beheert overdrachtsformaten, debugt welk station brak. Het is echt engineering. De beloning is agenten die urenlang betrouwbaar draaien in plaats van elke vijf minuten jou nodig te hebben — maar je grijpt er niet naar bij een snelle fix. Je grijpt ernaar wanneer de taak groot genoeg is dat het oppassen meer zou kosten dan het bouwen van de opstelling.

Er is nog één mindsetverandering die samenwerkt met dit alles, en het is degene die stilletjes mijn hele setup na verloop van tijd beter maakte.

Behandel elke mislukking als een permanente upgrade

Hier is de gewoonte die de koers van mijn systeem meer veranderde dan welke enkele feature dan ook: elke keer dat een agent het verprutst, fix ik niet alleen de output — ik fix het systeem zodat die exacte fout nooit meer kan voorkomen.

De agent genereerde code die mijn naamgevingsconventie schond? Ik hernoem het niet alleen. Ik voeg de conventie toe aan CLAUDE.md. De agent vergeet steeds migraties uit te voeren na een schemawijziging? Ik voeg een hook toe die de commit blokkeert totdat migraties zijn uitgevoerd. De agent begreep een domeinterm verkeerd? Ik schrijf een woordenlijstinvoer van één alinea. Elke fix is een baksteen. Na maanden worden de bakstenen een muur die problemen opvangt voordat ik ze ooit zie.

Cole kadert dit als een systeem-evolutie-mindset, en het is het verschil tussen een setup die middelmatig blijft en een die accumuleert. De meeste mensen fixen dezelfde klasse bug vijftig keer omdat ze elke instantie als geïsoleerd behandelen. De accumulerende zet is om twee extra minuten te besteden aan het omzetten van elke mislukking in een regel, een document of een validatiestap. De vijftigste keer komt het probleem gewoon niet voor — het systeem heeft de les permanent geabsorbeerd.

Dit is waarom ik blijf hameren op CLAUDE.md en verificatie. Het zijn geen installatieklusjes. Ze zijn het geheugen van elke fout die je agenten hebben gemaakt, gecodeerd zodat ze niet herhaald worden. Een zelfverbeterende setup is geen magie — het is gewoon deze gewoonte, meedogenloos toegepast. Ik ging dieper in op dit konijnenhol in mijn post over het bouwen van zelfverbeterende Claude Code-systemen, maar de kern is deze alinea.

Er is echter één categorie van mislukking waar "fix het de volgende keer" niet goed genoeg is — omdat de kosten van de eerste keer catastrofaal zijn. Beveiliging.

Beveiliging: waarom "verwijder de database niet" geen toestemming is

Dit is de les waarvan ik het meest wil dat mensen het serieus nemen, want het is degene met tanden. Een agent in een prompt vertellen "verwijder de productiedatabase niet" is geen beveiligingscontrole. Het is een suggestie. En een agent die de instructie heeft om een doel te bereiken kan, en zal soms, een creatief pad vinden recht om je suggestie heen.

Denk na over wat een agent eigenlijk is: een systeem dat code schrijft en uitvoert om een doel te bereiken. Als het verwijderen en opnieuw aanmaken van een tabel het pad van de minste weerstand is om een test te laten slagen, kan een voldoende vastberaden agent zijn weg daarheen scripten — zelfs nadat je hebt getypt "raak de database niet aan." De instructie leeft in de prompt, die gewoon tekst is waartegen het model kan redeneren, herinterpreteer, of stilletjes deprioriteer onder druk. Op prompts gebaseerde vangrails zijn gemaakt van hetzelfde materiaal als het ding dat je probeert te beperken.

Echte controles leven onder de prompt, in de harness:

• Hooks. Een hook is een klein programma dat draait op een specifiek punt in de levenscyclus van de agent — denk aan git-hooks, maar dan voor AI. Een pre-executie-hook kan een commando voor het wordt uitgevoerd inspecteren en alles wat overeenkomt met een gevaarlijk patroon hard blokkeren (een DROP, een rm -rf, een schrijfactie naar een beschermd pad). De agent krijgt niet de kans om langs een hook te praten. De hook is code, en code onderhandelt niet. Dit is structureel anders dan een promptinstructie, en het is waarom hooks niet-onderhandelbaar zijn voor alles in de buurt van productie.
• Strikte toestemmingsscopes. Geef de agent geen brede toegang en vertrouw erop dat het zich gedraagt. Beperk het tot precies wat de taak nodig heeft — deze map, deze commando's, niet meer. De smalst mogelijke toestemmingsset is je echte vangnet.

Ik behandel dit met dezelfde ernst waarmee ik elke productietoegang zou behandelen. Als je agenten draait in de buurt van echte systemen en echte data, is de beveiligingshouding van die agenten een echt aanvalsoppervlak — en het is precies het soort ding dat xCyberSecurity beoordeelt voor bedrijven die AI-tooling adopteren. Een agent met databasetoegang en alleen op prompts gebaseerde vangrails is een lek dat wacht op een slechte dag.

Beveiliging afgehandeld, er is een stiller risico dat na maanden insluipt: niet weten wat je eigen codebase eigenlijk doet.

Het probleem van "donkere code": begrijp wat de agent schrijft

De verleidelijke faalmodus van agentisch coderen is code verschepen die je nooit hebt gelezen. Het werkt, de tests slagen, je gaat verder. Vermenigvuldig dat met een paar honderd merges en je hebt een codebase die een zwarte doos is voor zijn eigen eigenaar — wat sommige mensen donkere code noemen. De dag dat iets breekt, debug je een systeem dat je niet begrijpt, geschreven door een agent die zich niet herinnert het te hebben geschreven.

Ik trek nu een lijn: ik probeer op zijn minst te begrijpen wat de agent produceert. Niet elke regel boilerplate, maar de architectuur, de niet-voor-de-hand-liggende beslissingen, alles wat data of geld of authenticatie raakt. De truc waar ik op leun zijn zijgesprekken — een hulpsessie of aparte sessie waarin ik de agent vraag een stuk code uit te leggen zonder die uitleg in mijn hoofdwerkcontext te dumpen. Ik krijg begrip zonder het contextvenster te vervuilen dat bezig is met bouwen. Het houdt de hoofdagent slank terwijl mijn eigen mentale model actueel blijft.

Een eerlijke opmerking voor de niet-coders die dit lezen — en jullie zijn er elke maand meer in agentisch coderen: als je de code echt niet kunt lezen, moet je vangnet rigoureuze validatie zijn, niet onderbuikgevoel. Leun zwaarder op de verificatielaag dan een ontwikkelaar zou doen. Als je de motor niet kunt inspecteren, kun je maar beter uitstekende instrumenten op het dashboard hebben. De validatie is voor jou niet optioneel; het is dragend.

Begrijpen is één taak. Soms is de taak echter moeilijker denken — een echte beslissing met afwegingen, waarbij het zelfverzekerde antwoord van een enkele agent precies is wat je niet moet vertrouwen. Dat is waar agentteams hun waarde bewijzen.

Agentteams en sub-agenten: wanneer een menigte oproepen

Twee tools in de gereedschapskist worden constant verward, dus laat me de lijn duidelijk trekken, want ze lossen verschillende problemen op.

Sub-agenten zijn lichtgewicht agenten die je oproept voor gefocust, geïsoleerd werk — meestal onderzoek of het verzamelen van context. Je stuurt er een op pad om drie concurrerende bibliotheken te onderzoeken en de afwegingen te rapporteren. Elk draait in zijn eigen contextvenster, dat is het hele punt: het doet het zware leeswerk zodat je hoofdagent slank blijft. Ze zijn tokenintensief en hun communicatie terug is beperkt, maar voor uitzwerm-onderzoek zijn ze uitstekend. Opus 4.8 kan er nu honderden parallel draaien in een enkele sessie.

Agentteams zijn een ander beest. Hier roep je meerdere op persona gebaseerde agenten op en laat je ze overleggen — een beslissing beargumenteren, randgevallen betwisten, elkaar uitdagen. Dit is het tegengif voor een van de gevaarlijkste eigenschappen van een enkele agent: kruiperigheid. Vraag één agent of je plan goed is en het neigt naar instemming. Stel een adversarieel team op — één die voor de aanpak pleit, één die alles zoekt wat er mis mee is — en het meningsverschil brengt randgevallen en faalmodi aan het licht die een enkele vriendelijke agent voorbij zou hebben geglimlacht.

Ik gebruik agentteams voor echt consequentiële beslissingen — een architectuurkeuze waarmee ik een jaar moet leven, een beveiligingsmodel, een migratieplan. Het adversariële debat is waar ik mijn slechtste aannames heb ontmaskerd. Maar ik ben eerlijk over de kosten: dit is zeer tokenintensief. Meerdere agenten die parallel argumenteren branden snel door je verbruik heen. Het is een precisiegereedschap voor inzetten met hoge inzet, geen standaard. Voor routinewerk is het overdreven. Ik ging dieper in op multi-agent orkestratie in mijn analyse van Claude Code agent-zwermarchitectuur als je de structurele details wilt.

Dus welke features dragen de last dag in dag uit? Na maanden hiervan stijgen er drie bovenuit.

De drie Claude Code-features die het meest uitmaken

Cole noemde zijn top drie Claude Code-features, en na het runnen van mijn eigen merken op deze setup kom ik op dezelfde plek uit. Dit zijn degenen die het echte werk doen:

1. Skills. Herbruikbare, geparametriseerde prompts die je bij naam oproept. In plaats van elke keer een complexe instructie opnieuw te typen, sla je het eenmaal op en roep je het aan als een functie. Dit is hoe een workflow stopt met iets te zijn dat je onthoudt en iets wordt dat het systeem weet. Ik heb skills gebouwd voor alles van SEO-concepten tot deploymentcontroles over mijn sites.
2. Hooks. Door events getriggerde code die draait op gedefinieerde punten in de levenscyclus van de agent. We behandelden hun beveiligingsrol, maar ze zijn even krachtig voor kwaliteit — automatisch formatteren bij opslaan, tests draaien voor een commit, een merge blokkeren die een controle faalt. Mechanische garanties, geen hoopvolle instructies.
3. Sub-agenten. Gefocust onderzoek en het verzamelen van context in geïsoleerde vensters, waardoor je hoofdagent scherp blijft. De verdediging tegen de domme zone, geoperationaliseerd.

Let op de rode draad. Skills maken je workflows herhaalbaar. Hooks maken je garanties mechanisch. Sub-agenten houden je context slank. Geen van hen gaat over het "slimmer" maken van het model — ze gaan over het bouwen van een systeem rondom het model dat betrouwbaar blijft. Dat is de hele filosofie in drie features.

Dus zo zou ik dit allemaal in de praktijk brengen, vanaf morgen.

De checklist van de regisseur die ik werkelijk gebruik

Pin dit vast. Het is de werkprocedure die ik nu draai bij elke niet-triviale taak:

• Plan meer dan je bouwt. Schrijf intentie, plan, succescriteria en validatiestrategie voordat de agent een regel schrijft. Als je de succescriteria niet kunt schrijven, ben je niet klaar om te delegeren.
• Houd de context slank. Behandel het bruikbare venster als een fractie van de geadverteerde 1 miljoen. Wis tussen taken. Laat de agent niet lezen wat het niet nodig heeft. Blijf uit de domme zone.
• Bouw geautomatiseerde verificatie. Unittests vanuit de specificatie, Playwright voor UI, aangepaste harnesses voor alles wat interactief is. Verplaats de correctheid van de eerste poging van ~65% naar 92%+ zonder je eigen aandacht te besteden.
• Engineer harnesses met schone overdrachten. Ralph-loop voor sequentiële fasen, parallelle sub-agenten voor onafhankelijke uitzwerm. Elke agent blijft slank.
• Behandel elke mislukking als een permanente upgrade. Elke bug wordt een regel, een document of een hook. Het systeem accumuleert.
• Vergrendel beveiliging onder de prompt. Hooks voor harde blokkeringen, strikte toestemmingsscopes. "Verwijder de database niet" is geen controle.
• Begrijp de code. Gebruik zijgesprekken om te leren zonder context te vervuilen. Niet-coders: leun zwaarder op validatie.
• Gebruik agentteams voor beslissingen met hoge inzet. Adversarieel debat doodt kruiperigheid en brengt randgevallen aan het licht. Tokenintensief — bewaar het voor beslissingen die ertoe doen.
• Voer het waarom in. Intentiebouw. Elke taak draagt zijn doel. De agent vult hiaten in de richting van je intentie.

De draad die alle negen met elkaar verbindt is het ene idee waarmee ik begon: jij bent de regisseur. De productmanager. De mentor die een briljante, letterlijke, vergeetachtige junior precies geeft wat het nodig heeft om te slagen — en het resultaat controleert tegen een standaard die je van tevoren hebt gesteld.

Herinner je je die productiebuild die ik om 23:00 uur brak? Degene met de regel die ik nooit had gelezen? Ik denk er nog steeds aan, maar niet meer met spijt. Het was de avond dat ik stopte met passagier zijn. De volgende ochtend schreef ik mijn eerste echte specificatie, voegde mijn eerste hook toe, en begon de agent te behandelen als wat het werkelijk is — niet een magische coder, maar een systeem waarvoor ik de verantwoordelijkheid draag om het goed aan te sturen.

Dus hier is het ene ding om te doen in de komende 24 uur: neem de meest repetitieve taak waarvoor je momenteel prompt, en schrijf er een echte specificatie voor — intentie, plan, succescriteria, validatie. Slechts één. Kijk dan hoe anders de agent zich gedraagt wanneer je stopt met chatten en begint met regisseren. Die ene oefening is waar de rolverandering begint.

Veelgestelde Vragen

Wat betekent het om een AI-codeeragent aan te sturen?

Een AI-codeeragent aansturen betekent eigenaarschap nemen over de intentie, het plan, de succescriteria en de verificatie terwijl de agent het typen afhandelt. Je treedt op als productmanager en regisseur in plaats van een prater — je voert het waarom achter elke taak in en controleert de output tegen een standaard die je van tevoren hebt gesteld. Zie de planningssectie hierboven voor de vierdelige specificatie die ik gebruik.

Wat is de "domme zone" in een contextvenster?

De domme zone is het punt voorbij ruwweg 250.000 tokens waar de nauwkeurigheid van een model stilletjes afneemt — beperkingen vergeet en bestanden verkeerd leest — ook al is het contextvenster van 1 miljoen tokens niet vol. Het gevaar is dat het nooit een foutmelding geeft; het wordt gewoon subtiel slechter. Houd de context slank om eruit te blijven.

Hoe nauwkeurig is door AI gegenereerde code bij de eerste poging?

Eerste-poging AI-codeeragentoutput is ruwweg 65–70% correct op echte taken. Het toevoegen van een zelfverificatielaag — unittests, browserautomatisering en aangepaste harnesses — duwt dat voorbij 92% omdat de agent zijn eigen fouten vangt en fixt voordat jij ze beoordeelt. De verificatiesectie hierboven legt uit hoe je elk niveau bouwt.

Wat is de Ralph-loop in Claude Code?

De Ralph-loop is een lopende-bandworkflow waarin elke agent één fase bezit — plannen, bouwen, testen — en schone output doorgeeft aan de volgende, elk startend met verse context. Gepopulariseerd door Geoffrey Huntley in 2025, het houdt elke individuele agent uit de domme zone tijdens lange autonome runs.

Zijn promptinstructies genoeg om een AI-agent veilig te houden?

Nee. Een agent in een prompt vertellen "verwijder de database niet" is een suggestie, geen controle — een doelgerichte agent kan zijn weg eromheen scripten. Echte veiligheid komt van hooks (kleine programma's die gevaarlijke commando's hard blokkeren voor uitvoering) en strikte toestemmingsscopes die beperken wat de agent überhaupt kan aanraken.

Laten we samenwerken

Op zoek naar het bouwen van AI-systemen, het automatiseren van workflows of het opschalen van je technische infrastructuur? Ik help je graag.

• Fiverr (op maat gemaakte builds & integraties): fiverr.com/s/EgxYmWD
• Portfolio: mejba.me
• Ramlit Limited (enterprise-oplossingen): ramlit.com
• ColorPark (design & branding): colorpark.io
• xCyberSecurity (beveiligingsdiensten): xcybersecurity.io