Handmatig prompten schaalt niet: ontwerp de loop die je AI-agent aanstuurt

Twee jaar lang gold steeds hetzelfde recept als je iets bruikbaars uit een coding agent wilde halen. Schrijf een goede prompt, geef genoeg context mee, lees wat eruit komt, typ de volgende stap. De agent was een tool en jij stuurde hem voortdurend aan, beurt voor beurt. Die modus verdwijnt niet, en voor los, eenmalig werk blijft hij prima. Maar mijn inschatting is dat het niet langer het meest waardevolle is wat je in een sessie kunt doen.

Wat ernaast komt te staan, en bij de teams die in 2026 het meeste uit Claude Code en Codex halen steeds vaker de hoofdrol pakt, is een klein systeem dat de agent voor je prompt. Het zoekt zelf werk op volgens een vast schema, verdeelt dat naar een worker en laat een aparte worker het controleren. Daarna schrijft het systeem het resultaat naar een memory file die de volgende run kan lezen, en morgen gebeurt hetzelfde nog eens. Jij ontwerpt dat systeem één keer. Daarna is het een geplande taak op de klok, in het vak een cron, die de agent prompt, en hoef jij er niet meer bij te zitten.

Ik noem dat voor mezelf al een paar maanden loop engineering. Hoe vaker ik zo'n loop op echt klantwerk draai, hoe duidelijker het wordt waar de hefboom is komen te liggen: een niveau boven de losse prompt, bij het systeem dat de prompts uitdeelt.

Van prompt naar loop: wat er precies verschuift

Voordat de onderdelen langskomen, eerst de verschuiving zelf. Handmatig prompten en een loop draaien vragen ander werk van je, en een andere rol.

Wat een loop eigenlijk bevat

Een loop bestaat uit vijf bewegende onderdelen en één stukje state. Zodra je ze kunt benoemen, zie je ze terug in elke tool. De discussie of Codex of Claude Code de juiste keuze is, wordt daarmee een stuk minder spannend: de vorm is in beide vrijwel gelijk.

Automations zijn het startsignaal. Dat kan een schema zijn, een cron, of een webhook: een seintje van een ander systeem dat er iets is gebeurd. Claude Code heeft daarbovenop /loop, dat een prompt op een vast ritme herhaalt. En beide tools hebben /goal, dat de agent laat doorwerken tot een voorwaarde die jij zelf hebt geschreven waar is. Dit maakt de loop wakker. Zonder dit ben jij degene die de run start, en dus nog steeds degene die de agent prompt.

Worktrees houden parallel werk uit elkaar. Draai twee agents in dezelfde checkout en ze schrijven vroeg of laat in hetzelfde bestand, waarna je de rest van de ochtend bezig bent met uitzoeken welke wijziging van wie was. Een git worktree is een aparte werkmap op een eigen branch, met een eigen index en een eigen HEAD, terwijl de geschiedenis van de repo gedeeld blijft. Twee agents in twee worktrees bewerken dus verschillende kopieën van hetzelfde bestand en overschrijven elkaar niet. Automatisch gaat dat nergens: in Claude Code zet je isolation: worktree op een sub-agent, in de Codex-app kies je een worktree per chat, en in de CLI van beide zet je hem zelf op.

Skills zijn de projectkennis, vastgelegd op een plek waar de agent ze kan lezen. In beide tools werkt dat met hetzelfde soort SKILL.md-mapformaat en hetzelfde triggermodel: de description bovenaan bepaalt wanneer de agent de skill oppakt. Daarover schreef ik vorige week al in je eerste AI-strategie is een skill library. Binnen een loop zorgen skills er ook voor dat je niet elke keer opnieuw moet betalen om dezelfde intentie uit te leggen. De loop start immers bij elke run koud op, en zonder de skill valt hij terug op een zelfverzekerde gok.

Connectors zijn waarmee de loop echte systemen bedient: koppelingen waarmee de agent zelf GitHub, Linear of je database kan aansturen. In het vak heten ze MCP-connectors, naar het Model Context Protocol, de open standaard waarop ze gebouwd zijn. Dezelfde server draait in Claude Code en in Codex, alleen de configuratie verschilt: JSON tegenover TOML. Binnen een loop doen connectors ertoe omdat de loop moet handelen, niet alleen praten. Zonder connectors eindigt een run met een voorstel dat jij nog moet uitvoeren. Met connectors opent de loop zelf de PR, koppelt hij het Linear-ticket en stuurt hij een bericht naar het kanaal zodra CI groen wordt.

Sub-agents zijn het nuttigste structurele element dat je in een loop kunt inbouwen, en het makkelijkst om over te slaan. Je splitst de agent die het werk opstelt van de agent die het beoordeelt. Een andere systeemprompt, vaak een ander model, en in Codex kun je per sub-agent ook een andere reasoning effort instellen. Het model dat een functie schreef, is veel te welwillend over de vraag of die functie klopt. Een verifier met een eigen systeemprompt vangt wat de schrijver zichzelf heeft wijsgemaakt. Binnen een loop, waar jij de run niet zelf bekijkt, is deze splitsing de belangrijkste reden dat je daadwerkelijk kunt weglopen.

En dan is er nog het zesde element, dat te simpel klinkt om ertoe te doen. Memory. Een markdown-bestand, een Linear-board, een piepklein SQLite-bestand, wat dan ook dat buiten het ene gesprek leeft. Tussen twee runs houdt de agent zelf niets vast; wat op schijf staat, blijft wel bestaan. Het state-bestand is het dragende onderdeel van elke langlopende loop die ik heb gebouwd. De loops die omvallen, falen meestal omdat iemand de state in de conversatiecontext probeerde te bewaren in plaats van daarbuiten.

Dit is eigenlijk geen tooling-discussie meer

Een jaar geleden betekende een loop een stapel bash-scripts die alleen jij zelf begreep, die op je laptop draaide, en die kapotging zodra je iets updatete. Wat me het meest verraste aan 2026 is dat de onderdelen nu gewoon in de producten zelf zitten. Claude Code en Codex hebben allebei alle vijf de blokken plus het memory-patroon, onder net iets andere namen en met andere details eromheen. Af of uniform is het nog niet. De implementaties lopen uiteen, en er komt elk kwartaal iets bij: /loop bestaat bijvoorbeeld wel in Claude Code en niet in Codex, waar je herhaling op een vast ritme regelt met scheduled tasks in de app. Maar de richting is onmiskenbaar en de vorm is in beide dezelfde.

De in-sessie-primitive die je moet kennen is /goal, en die zit in beide tools. Je schrijft een verifieerbare stopconditie ("alle tests in test/auth slagen en lint is schoon") en de agent blijft over meerdere beurten doorwerken tot die conditie gehaald is. Wie dat beoordeelt, verschilt per tool. Claude Code laat na elke beurt een apart, klein model oordelen of de conditie waar is, nog niet waar is, of onhaalbaar is geworden. Codex laat het werkende model zichzelf afvinken, maar wel tegen bewijs: gedraaide commando's, geslaagde tests, gewijzigde bestanden. In de Claude Code-variant zie je de maker-en-checker-splitsing toegepast op de stopconditie zelf, en dat maakt /goal op dit moment de nuttigste loop-primitive die in beide tools zit.

De implicatie is dat je kunt stoppen met discussiëren over welke tool. Kies degene die je team al gebruikt, en ontwerp een loop waarvan de vorm een overstap zou overleven. Mijn inschatting is dat de vijf blokken duurzamer zijn dan de producten eromheen.

Hoe mijn loop er elke ochtend echt uitziet

Dit is de vorm die al een paar maanden standhoudt in productie, bij twee van mijn projecten, en hij is opzettelijk onspectaculair. Het is één loop, één keer ontworpen, en sinds ik de skills schreef heb ik geen enkele afzonderlijke stap erin nog geprompt.

Stap voor stap, in praktische termen.

Om 06:00 start een cron een Claude Code-sessie op de repo, headless: zonder scherm en zonder iemand die meekijkt, in een eigen worktree. De sessie roept één skill aan, $triage-overnight. Die skill weet hoe hij de CI-fouten van gisteravond moet lezen. CI is de geautomatiseerde straat van tests en checks die bij elke codewijziging draait. Daarnaast leest hij de open Linear-tickets en de diff sinds de laatste geslaagde loop-run. Zijn bevindingen schrijft hij naar een findings.md-bestand in de root van de repo, als een korte gecategoriseerde lijst (broken-test, dependency-flag, bug-report, content-task).

Voor elke bevinding die het waard is om automatisch aan te pakken, opent de loop een geïsoleerde worktree. Binnen elke worktree stelt een maker-sub-agent de fix op. Een verifier-sub-agent met een eigen systeemprompt toetst dat concept aan de skill-bestanden van het project en aan de bestaande tests. Het oordeel van de verifier is de poort. Slaagt het concept, dan opent de loop via de GitHub-connector een PR: een pull request, een voorstel tot codewijziging dat jij kunt reviewen voordat het live gaat. Via de Linear-connector werkt hij het ticket bij. Zakt het concept, dan verhuist de bevinding naar een triage-inbox, zodat ik er later naar kan kijken.

Het allerlaatste dat de run doet is findings.md herschrijven met tellingen (done, escalated, in-progress, fresh) zodat de run van morgenochtend weet welke state hij heeft geërfd. De hele loop kost 25 tot 40 minuten, afhankelijk van hoeveel bevindingen het waard zijn om te proberen. Qua tokens kost het me ongeveer evenveel als een langlopend ChatGPT-gesprek, meer als er een sub-agent op een zwaar model draait.

De zwakke plek zie je al aankomen: de waarde van dit hele systeem zit in de verifier. Als die slordig is, verstuurt de loop om zes uur 's ochtends onbeheerd slordige PR's, precies het tegenovergestelde van wat ik wil. De verifier-prompt is het meest herziene stukje tekst in de loop, en dat hoort ook zo.

Het patroon dat drie iteraties overleefde

Ik heb loops zoals deze drie keer opnieuw gebouwd voor drie verschillende projecten, en de verrassende les is dat de ontwerpkeuzes die ertoe doen niet de voor de hand liggende zijn.

• Eén memory-bestand verslaat er vijf. Ik probeerde de state te verdelen over meerdere markdown-bestanden (één per bevindingstype) en de loop raakte steeds in verwarring over welk bestand leidend was. Alles samenvoegen tot één findings.md met gecategoriseerde secties maakte het geheel veel makkelijker te doorgronden.
• Skills worden geladen op basis van description, niet van naam. Een heldere, saaie description bovenaan de SKILL.md ("gebruik dit bij het trieren van nachtelijke CI-fouten, open Linear-tickets en recente commits") presteert beter dan een slimme naam. Beide tools kiezen skills automatisch door de description te matchen met de taak, dus een strakke description is een gratis upgrade.
• De verifier heeft een echte spec nodig. Tegen de verifier zeggen "check of de fix goed is" is nutteloos. Zeggen "de fix moet een regressietest bevatten, mag geen bestanden buiten de falende module aanraken, en moet npm run check doorstaan" is het verschil tussen een verifier die werk verzet en een verifier die alleen maar wat aanrommelt.
• Tokenkosten zitten in de verifier, niet in de maker. Verrassend genoeg vrat de verifier in mijn vroege loops het meeste budget op omdat hij bij elke run de volledige repo-context laadde. De verifier beperken tot het diff plus de relevante skill-bestanden verlaagde de kosten per run met ongeveer 70 procent zonder het resultaat te veranderen.
• De triage-inbox is de veiligheidsklep. De loop zal uiteindelijk een keer verkeerd oordelen. De triage-inbox is de plek waar dat terechtkomt. Als jouw loop geen human-gated inbox heeft, draai je geen loop: je draait een ongemodereerde autopublisher.

Voor wie dit nu interessant is, en voor wie nog niet

Een beslisser hoort hier twee vragen te stellen: wat levert dit op, en zijn wij er klaar voor? Het antwoord hangt vrijwel volledig af van wat er al ligt.

Een loop is nu interessant als je een eigen codebase hebt met terugkerend, controleerbaar werk eromheen: dagelijkse CI-triage, dependency-onderhoud, content-QA, rapportages. Softwarebedrijven, bureaus met meerdere klantrepo's, en eigenlijk elke organisatie waar een developer wekelijks uren kwijt is aan werk dat een checklist zou kunnen beschrijven. De winst zit in het terugwinnen van precies die uren, elke week opnieuw, en in het feit dat het werk blijft doorlopen als degene die het normaal doet vrij is.

Een loop is nog niet interessant als de basis ontbreekt, en veel bedrijven waar ik binnenkijk missen die basis nog. Geen tests, geen CI, tickets die in mailboxen leven, documentatie die alleen in hoofden zit. Een loop versterkt wat er ligt, inclusief de rommel. Zonder tests heeft de verifier niets om tegen te toetsen, en zonder ticketsysteem heeft de triage-skill niets om te lezen. De realistische eerste stap is dan de basis zelf: tests op de kernfunctionaliteit, CI die bij elke wijziging draait, en één plek waar werk wordt bijgehouden. Dat is geen omweg, want je hebt er ook zonder loop direct profijt van.

En als je helemaal geen eigen software hebt, is dit artikel vooral context voor gesprekken met je leveranciers. De vraag "draait hier een geautomatiseerde controle op, of kijkt er elke keer een mens naar" wordt de komende jaren een normale vraag om aan je bureau of softwarepartij te stellen.

Wat de loop nog steeds niet voor je doet

De loop verandert het werk, maar hij haalt de engineer er niet uit. Drie dingen worden juist scherper naarmate de loop beter wordt.

Verificatie blijft jouw taak. Een loop die onbeheerd draait, maakt ook onbeheerd fouten. De hele reden dat de maker-verifier-splitsing bestaat, is om de "het is klaar"-claim van de loop iets te laten betekenen. Zelfs met een sterke verifier blijft "klaar" een claim, nog geen bewijs. De PR moet nog steeds jouw review halen. De productiedeploy blijft een beslissing, en op een gegeven moment moet jij het diff kunnen lezen en ja kunnen zeggen.

Jouw begrip van de codebase erodeert nog steeds als je het laat gebeuren. Hoe sneller de loop code verstuurt die jij niet zelf hebt geschreven, hoe breder de kloof wordt tussen wat er in de repo staat en het mentale model dat jij daar daadwerkelijk van hebt. Er zijn twee manieren om daarmee om te gaan. De eerlijke: elke dag tien minuten de diffs blijven lezen die de loop verstuurt. De oneerlijke: stoppen met lezen en de kloof "leverage" noemen, tot aan de productiebrand die je niet kunt debuggen omdat je eigenlijk niet weet wat de loop de afgelopen zes maanden heeft gedaan.

Comfort is hier het gevaarlijkst. Wanneer een loop zichzelf draait, wordt het heel verleidelijk om geen mening meer te vormen over wat er wel of niet verstuurd moet worden, en gewoon aan te nemen wat er terugkomt. De loop ontwerpen werkt als tegengif zolang je er oordeel in stopt, en als versneller zodra je hem gebruikt om het nadenken over te slaan. Alleen jij kunt zien welke van de twee je aan het doen bent.

Wat ik dit kwartaal zou doen als ik nog niet was begonnen

De eerlijke volgorde om je eerste bruikbare loop te laten landen, met zo min mogelijk verspilde token-uitgaven.

1. Kies één terugkerende taak die je nu met de hand doet. Dagelijkse CI-triage, wekelijkse dependency-check, terugkerende content-QA. Iets waarvan je absoluut zou merken als een mens ermee stopte.
2. Schrijf eerst de skill, niet de automation. Een SKILL.md die vastlegt hoe jij de taak vandaag uitvoert. Voorbeelden, edge cases, het faalpatroon dat je al drie keer hebt betrapt. De skill is het dragende onderdeel.
3. Voeg de maker-verifier-splitsing toe voordat je parallellisme toevoegt. Eén worker, twee rollen, één worktree. Zorg dat de kwaliteit van één bevinding klopt voordat je opschaalt naar tien bevindingen per run.
4. Sluit één connector aan die je echt nodig hebt. De meeste loops hebben lange tijd maar precies één connector nodig: GitHub. Linear en Slack komen later. Weersta de drang om op dag één vijf integraties aan te sluiten.
5. Plan hem in. Een /loop op een vast ritme, of een GitHub Action met een cron plus workflow_dispatch, zodat je hem ook handmatig kunt starten. Dan overleeft de run het moment waarop jij je laptop dichtklapt.
6. Lees het memory-bestand elke ochtend gedurende de eerste twee weken. Dit is de niet-onderhandelbare stap. Sla je hem over, dan drijft de loop binnen twee weken af naar werk dat je niet meer kunt vertrouwen.

Waar ik uitkom

Prompt engineering was twee jaar lang de hefboom omdat de tools zichzelf nog niet konden inplannen, uitwaaieren naar geïsoleerde worktrees, of hun eigen output beoordelen. Dat kunnen ze nu wel. Goed prompten blijft een basisvaardigheid, net zoals goed kunnen zoeken dat ooit is geworden. Maar het volgende waar je goed in wilt worden, is het systeem dat boven de agent zit: de loop met zijn vijf onderdelen, en de state die tussen de runs blijft staan.

Bouw de loop, maar bouw hem als iemand die van plan is in de stoel te blijven zitten.

Als je een tweede paar ogen wilt op welke van je huidige handmatige workflows hier echt van zouden profiteren, of een echte draaiende loop wilt inspecteren, stuur me een bericht. Mail info@jermayads.nl of gebruik jermayads.nl/contact.