Loop Engineering: Hoe ontwerp je Agent Loops

Loop Engineering: Hoe ontwerp je Agent Loops

De eerste keer dat ik een loop bouwde zonder echte stopconditie, kostte het me $12 en draaide het 28 minuten voordat ik het afbrak. De agent was niet kapot. Hij deed precies wat ik hem vertelde: doorgaan tot de taak "voltooid" is. Het probleem was dat ik "voltooid" nooit had gedefinieerd op een manier die een machine kon controleren. Dus bleef hij genereren, bleef hij verfijnen, bleef hij tokens verbranden — steeds weer met zichzelf instemmen terwijl mijn portemonnee stilletjes leegliep. Die ene slechte run leerde me meer over loop engineering dan welke tutorial dan ook.

Dit is de verschuiving die nu plaatsvindt, en de meeste bouwers hebben het nog niet bijgebeend. De vaardigheid die ertoe doet in 2026 is niet het schrijven van een slimme prompt. Het is het schrijven van de loop die het model voor je aanstuurt — en precies weten hoe die loop beslist dat hij klaar is. Boris Cherny, de maker en leider van Claude Code bij Anthropic, zei het onomwonden op het podium bij Acquired Unplugged op 2 juni 2026: "Ik prompt Claude niet meer. Ik heb loops draaien die Claude prompten en uitzoeken wat te doen. Mijn taak is het schrijven van loops."

Dat is geen wegwerpzin. Dat is een functieomschrijving die in realtime verandert.

Een korte opmerking voordat we diep gaan, want twee dingen delen hetzelfde woord. Als je de hands-on, dit-is-wat-brak review wilt van de skill die loop-bouwen productiseert, heb ik dat apart behandeld in mijn analyse van Anthropic's Launch Your Agent skill en de op hol geslagen agent-run die het produceerde. Die post is een tool review. Deze gaat over de engineering eronder — de discipline van het ontwerpen van de loop zelf, in welk gereedschap je hem ook giet. De twee zijn verwant, niet hetzelfde. Lees deze voor het waarom en de vorm; lees die voor het hoe het voelde om te draaien.

Aan het einde hiervan kun je een loop ontwerpen met een echte, controleerbare stopconditie — en, net zo belangrijk, weet je wanneer een loop helemaal het verkeerde instrument is. Dat tweede deel is waar de meeste mensen zich branden.

Wat is loop engineering?

Loop engineering is de praktijk van het ontwerpen van de trigger, actie en stopconditie van een autonome agent-loop zodat deze kan draaien, zijn eigen werk kan verifiëren en kan stoppen op objectieve criteria — in plaats van te vertrouwen op een enkele door mensen geschreven prompt. Het behandelt de loop, niet de prompt, als de werkeenheid.

Denk na over hoe je AI coding agents hebt gebruikt. Je schrijft een prompt. Je leest de output. Je schrijft nog een prompt. Jij bent de loop. Je ogen zijn de verificatiestap, je oordeel is de stopconditie, en je vingers zijn het ding dat de volgende iteratie opnieuw triggert. Loop engineering verplaatst alle drie uit je hoofd naar code.

Cherny beschreef zijn eigen evolutie in drie fases, en het past naadloos op wat de meeste serieuze bouwers meemaken. Ongeveer een jaar geleden schreef hij code met de hand, met autocomplete die aan de randen hielp. Toen schakelde hij over naar het parallel draaien van vijf tot tien Claude-sessies, waarbij hij elk handmatig promptte — tabbladen wisselen als een snelkeukenkok. Nu schrijft hij loops die Claude voor hem prompten; een paar honderd agents lezen zijn GitHub, zijn Slack en zijn Twitter, en beslissen wat ze vervolgens bouwen. De mens ging van code typen, naar prompts typen, naar het typen van de machinerie die prompts typt.

De term zelf kristalliseerde zich uit begin juni 2026 — "schrijf loops, geen prompts" — en als je het kader eenmaal hebt geïnternaliseerd, kun je het niet meer onzien. Peter Steinberger, die OpenClaw bouwde (de meest gesterde nieuwe repo in de GitHub-geschiedenis), postte het op 7 juni 2026 nog scherper: "Je zou coding agents niet meer moeten prompten."

Sterke claim. Grotendeels juist. Maar "grotendeels" doet zwaar werk, en we komen nog bij waar het breekt.

De redeneer → actie → observeer → evalueer cyclus

Elke agent-loop, ontdaan tot op het bot, is hetzelfde vierslag-ritme dat zich herhaalt. De namen variëren — sommigen zeggen Waarnemen/Beslissen/Handelen/Observeren, sommigen zeggen Observeren/Denken/Handelen/Verifiëren — maar de muziek is identiek. Ik denk erover na als: redeneer → actie → observeer → evalueer de stopconditie, dan terug naar het begin.

Redeneer: de agent bekijkt de huidige staat en beslist wat hij vervolgens doet. Actie: hij voert een bewerking uit — schrijft een bestand, draait een commando, roept een API aan. Observeer: hij vangt op wat er veranderd is — de commando-output, de fout, de nieuwe bestandsinhoud, de screenshot. Evalueer: hij toetst die observatie aan de stopconditie. Klaar? Stoppen. Niet klaar? Opnieuw redeneren met de nieuwe informatie in de hand.

De naamgevingsoorlog doet er niet toe. Wat ertoe doet is de vierde slag. De meeste mislukte loops die ik heb gezien — inclusief mijn $12-ramp — hebben een sterke redeneer-actie-observeer cyclus en een nep evaluatiestap. De agent observeert zijn eigen output en vraagt zichzelf: "Goed genoeg?" En natuurlijk zegt hij ja, want hij beoordeelt zijn eigen huiswerk zonder beoordelingsschema. Een loop zonder iets dat terugduwt is gewoon de agent die steeds weer met zichzelf instemt.

Het hele spel is die vierde slag echt maken.

Daarom ontwerp ik loops nu achterstevoren. Voordat ik de trigger schrijf, voordat ik een enkele actie schrijf, schrijf ik de stopconditie op en stel ik één vraag: welk concreet ding in de wereld vertelt me dat dit klaar is, dat de agent niet kan faken? Een test die slaagt. Een type-checker die groen wordt. Een CI-pipeline die van rood naar groen gaat. Een HTTP 200 van een endpoint dat een minuut geleden nog 500 was. Als ik dat ding niet kan benoemen, bouw ik de loop nog niet. De loop is niet klaar — de definitie is niet klaar.

Dus laten we de anatomie goed uiteenzetten, want elk van de drie delen heeft zijn eigen faalwijzen.

Trigger, actie, stopconditie: de anatomie van een agent-loop

Een loop heeft precies drie dragende delen. Krijg er één verkeerd en het hele ding wankelt.

De trigger is wat de loop op gang brengt. Het kan een menselijk commando zijn ("refactor deze module"), een schema (elke vijftien minuten), een gebeurtenis (een nieuw GitHub-issue, een Slack-bericht, een falende test in CI), of een andere agent die werk overdraagt. Cherny's setup van een paar honderd agents wordt getriggerd door zijn eigen activiteit — zijn commits, zijn berichten, zijn posts worden signalen die agents oppikken en op handelen. De trigger beantwoordt: wanneer heeft deze loop het recht om te bestaan en tokens uit te geven?

De actie is de set bewerkingen die de agent mag uitvoeren binnen elke iteratie. Dit is waar je de explosieradius tekent. Een actie kan zijn "bestanden bewerken in deze directory en de testsuite draaien." Het kan zijn "een afbeelding genereren en opslaan." Hoe strakker en specifieker de actieruimte, hoe voorspelbaarder de loop. Hoe vager — "doe wat nodig is" — hoe creatiever, en hoe gevaarlijker. De meeste token-verslindende uitlopers die ik heb gezien komen van een actieruimte die te breed was voor het vermogen van de stopconditie om een verkeerde afslag te vangen.

De stopconditie is de verificatiepoort — de objectieve criteria voor "klaar." Dit is het deel dat iedereen onderbouwt. Het moet iets zijn dat extern is aan de eigen mening van de agent. Matthew Berman, die de Loop Library lanceerde op 18 juni 2026, kadert verificatie helder: het kan zijn "een slagende unit test, een groene CI-pipeline, of een LLM die zegt 'ja, dat is compleet.'" Let op de volgorde van vertrouwen daar. Een unit test is een feit. Een groene pipeline is een feit. Een LLM die voltooiing beoordeelt is een mening — nuttig, maar de zwakste van de drie, en degene die het meest waarschijnlijk slechte kwaliteit afstempelt.

Hier is de ontwerpillustratie die ik in mijn hoofd bewaar. Stel dat ik een loop wil die falende tests in een repo fixt. Trigger: een geplande run, of een push die CI rood maakt. Actie: lees de falende test, bewerk de bron, draai de suite opnieuw — en alleen die bewerkingen. Stopconditie: de volledige suite slaagt, punt. Die laatste clausule is het hele punt. De loop kan geen overwinning claimen door zichzelf te vertellen dat de code er correct uitziet. Hij claimt overwinning wanneer npm test met exitcode nul eindigt. De test is het ding in de loop dat nee kan zeggen. Zonder iets dat nee kan zeggen, heb je geen loop — je hebt een dure ja-knikker.

Dat onderscheid — tussen een stopconditie die een feit is en een die een mening is — blijkt het hele spel te zijn. Wat me brengt bij het deel waar niemand genoeg over praat.

Waarom verificatiegetrouwheid een loop maakt of breekt

Niet alle stopcondities zijn gelijk, en het verschil tussen een goede en een slechte is de belangrijkste voorspeller van of een loop iets nuttigs produceert of iets dat slechts af lijkt.

Ik noem dit verificatiegetrouwheid: hoe getrouw je stopconditie meet wat je werkelijk belangrijk vindt. Hoge getrouwheid betekent dat de poort het echte doel controleert. Lage getrouwheid betekent dat de poort een proxy controleert die makkelijk te bevredigen en makkelijk te misleiden is.

Bermans Loop Library is een goudmijn om dit in actie te zien, en ik wil hier precies zijn — dit zijn loops die hij en zijn bijdragers gebouwd en getest hebben, niet loops die ik persoonlijk heb gedraaid. Maar ze illustreren het getrouwheidsprobleem beter dan wat ik zou kunnen construeren.

Neem zijn thumbnail-creatie loop. De opzet: genereer tien thumbnails, score ze tegen MrBeast-stijl referentiethumbnails, itereer op de top drie. Ongeveer 27 minuten per run. De trigger en actie zijn scherp. Maar de stopconditie? "Score ze tegen MrBeast-thumbnails." Dat is subjectief. Er is geen npm test voor "is deze thumbnail overtuigend." De verificatie is een LLM die naar een afbeelding kijkt en een esthetische mening vormt, en esthetische meningen zijn wankel. De loop draait, hij produceert thumbnails, maar de "klaar"-definitie is zacht — wat betekent dat de loop kan convergeren naar iets dat het model denkt dat goed is terwijl een menselijke maker het er volledig mee oneens kan zijn. Lage getrouwheid is geen bug in de code. Het is een bug in wat "klaar" betekent.

Kijk nu naar zijn three.js-loop — het bouwen van een 3D-vliegtuig met three.js, ongeveer 37 minuten, met iteratieve visuele verificatie door te renderen in een browser. Hogere getrouwheid dan thumbnails, omdat de agent daadwerkelijk de scène kan renderen en ernaar kan kijken bij elke iteratie. Maar het kreeg de doorzichtige transparantie toch niet volledig goed. De verificatie kon bevestigen "er bestaat een vliegtuig en het rendert," maar "de transparantie ziet er goed uit" was moeilijker vast te pinnen op een objectieve controle. De loop kwam dichtbij. Dichtbij is niet klaar.

Dan is er de Beatles Abbey Road-recreatie in HTML/CSS — gelimiteerd tot acht pogingen, ongeveer zeven iteraties daadwerkelijk gedraaid, geverifieerd door screenshot-vergelijking. Het verbeterde stapsgewijs bij elke doorgang en eindigde verre van perfect. En eerlijk gezegd is dat voorbeeld het meest leerzame van de drie, omdat het de limiet van de loop zo duidelijk laat zien. Screenshot-verificatie is middelmatige getrouwheid: het kan vangen "de layout is breed gezien verkeerd" maar worstelt met "dit specifieke verloop is iets te veel af." De harde limiet van acht pogingen is de onbezongen held hier — het is een secundaire stopconditie die een oneindige, onbevredigbare jacht voorkomt. Wanneer je primaire verificatie vaag is, is een harde iteratielimiet wat voorkomt dat de loop mijn $12-ramp wordt.

De les stapelt zich netjes op. Objectieve stopcondities (een slagende test, een exitcode, een HTTP-status) produceren loops die je kunt vertrouwen om onbeheerd te draaien. Subjectieve stopcondities (ziet dit er goed uit, is dit overtuigend) produceren loops die een mens in de stoel nodig hebben, of op zijn minst een harde pogingslimiet zodat ze snel falen in plaats van duur falen.

Als je één regel wilt uit dit hele gedeelte: stem de autonomie van de loop af op zijn verificatiegetrouwheid. Hoge-getrouwheidspoort? Laat hem draaien. Lage-getrouwheidspoort? Limiteer de pogingen en houd een hand op de noodknop.

Tot nu toe hebben we het gehad over één agent in één loop. Maar de krachtigste patronen — en degene die Cherny daadwerkelijk draait — betreffen agents die elkaar controleren.

Maker-checker en geneste vloten: opschalen voorbij een enkele loop

Een enkele agent die redeneer-actie-observeer-evalueer doet, werkt prima voor begrensde taken. De interessante architectuur begint wanneer je het maken scheidt van het controleren — en wanneer loops loops gaan spawnen.

Het maker-checker patroon is de schoonste upgrade die je kunt maken voor een loop met lage getrouwheid. In plaats van één agent die zowel het werk produceert als beoordeelt of het klaar is (het huiswerk-beoordelingsprobleem), splits je de rollen. Eén agent maakt — schrijft de code, genereert het ontwerp, maakt de tekst. Een tweede, aparte agent controleert — scoort het, beoordeelt het tegen criteria, jaagt op de fout. De hele taak van de checker is redenen vinden om nee te zeggen. Omdat hij het werk niet heeft geproduceerd, heeft hij geen ego geïnvesteerd in het klaar noemen. Die scheiding is wat de loop een echte tegenstander geeft, en een loop met een echte tegenstander is een loop die daadwerkelijk op kwaliteit kan convergeren.

Ik leun hier nu voortdurend op. Wanneer een stopconditie subjectief moet zijn — zeg, "is dit API-ontwerp schoon" — vraag ik de maker niet om zichzelf te beoordelen. Ik start een tweede agent met een scherp beoordelingsschema en een mandaat om streng te zijn. De outputkwaliteit springt omhoog, omdat er nu iets in de loop zit dat gebouwd is om terug te duwen.

Dan zijn er geneste vloten — managers die sub-agents aansturen, loops die loops orkestreren. Dit is wat Cherny's "paar honderd agents die mijn GitHub en Slack lezen en beslissen wat te bouwen" eigenlijk is. Een toplevel loop observeert zijn activiteit en redeneert over prioriteiten. Het stuurt sub-loops aan om specifieke builds te doen. Elke sub-loop heeft zijn eigen trigger, actieruimte en stopconditie, en rapporteert terug. De stopconditie van de manager-loop is niet "heb ik code geschreven" — het is "heeft mijn vloot de juiste dingen verscheept." Het is loops helemaal naar beneden, met verificatiepoorten op elke laag.

Als je probeert iets op deze schaal te architectureren, verdienen de orkestratiepatronen hun eigen diepgaande behandeling — ik heb beschreven hoe je managers, sub-agents en de berichtenuitwisseling ertussen structureert in mijn analyse van Claude Code agent swarm-architectuur. De korte versie: geneste vloten vermenigvuldigen zowel je doorvoer als je faaloppervlak. Elke laag die een echte stopconditie mist, is een laag waar slechte kwaliteit kan binnenkomen en onopgemerkt omhoog kan propageren.

En het harnas onder dit alles doet er meer toe dan de agents zelf. De manier waarop Anthropic zijn langlopende agent-harnas ontwerpt — hoe staat persistent blijft over iteraties, hoe context beheerd wordt zodat de loop niet verdrinkt in zijn eigen geschiedenis — heeft fundamenteel gevormd hoe ik denk over loop-duurzaamheid; ik heb dat uitgepakt in mijn stuk over Anthropic's agent harnas-ontwerp. Een loop is alleen zo goed als het harnas waarin hij draait.

Als je instemmend zit te knikken en denkt "geweldig, ik ga alles loopen" — stop. Dit is precies waar ik op de rem moet trappen, want de belangrijkste loop-engineeringvaardigheid is weten wanneer je er geen moet bouwen.

Wanneer je GEEN loop moet schrijven

Hier is de ongemakkelijke data die de "stop met prompten, begin met loopen"-menigte graag overslaat. Een onderzoek uit 2025 onder 306 professionals vond dat 68% van de productie-agents tien stappen of minder draait voordat een mens ingrijpt. Lees dat nog eens. De agentsystemen die daadwerkelijk werken in productie zijn geen autonome zwermen van tweehonderd. Ze zijn klein. Ze worden begeleid. Ze draaien een handvol stappen en dan neemt een mens het stuur over.

Dat is geen falen van de technologie. Dat is de technologie die wordt gebruikt door mensen die op de harde manier hebben geleerd waar loops breken.

De faalwijze heeft nu een naam: agent slop. Het is wat je krijgt wanneer je automatiseert voorbij het punt waar je nog kunt instaan voor de output. De loop blijft produceren, het volume blijft stijgen, en de kwaliteit degradeert stilletjes omdat er niets in het systeem was gebouwd om de afdrijving te vangen. Je eindigt met duizend commits die je niet kunt vertrouwen en niet hebt gelezen. Slop is geen slechte code — het is oncontroleerbare code, sneller gegenereerd dan enig mens het kan verifiëren.

Dus hier is mijn eerlijke checklist voor wanneer je de loop helemaal moet overslaan:

Sla het over als je een solo-bouwer bent op een consumentenplan. Loops geven tokens uit bij elke iteratie, en een op hol geslagen loop op een gemeten plan is een echte rekening. (Vraag me hoe ik het weet — $12 in 28 minuten, en dat was een kleine.) Als je kostenbewust bent, wordt de wiskunde van autonome loops snel lelijk. Ik heb de volledige tokeneconomie uiteengezet in mijn gids voor AI-agent kostenoptimalisatie, en de kop is simpel: zonder een harde poort falen loops stilletjes en blijven ze uitgeven. Stil falen plus gemeten facturering is de slechtste combinatie in dit hele veld.

Sla het over als je code geen geautomatiseerde verificatie heeft. Geen tests, geen type checker, geen CI? Dan is je enige mogelijke stopconditie de mening van een LLM — de laagste-getrouwheidspoort die er is. Je hebt geen loop; je hebt een dure manier om plausibel ogende diffs te genereren. Bouw eerst de tests. De verificatie-infrastructuur is de loop-infrastructuur. Een loop zonder een harde poort om terug te duwen is de agent die steeds weer met zichzelf instemt, en dat is precies de slop-machine.

Sla het over als je echte knelpunt reviewcapaciteit is, niet typesnelheid. Deze is subtiel en vangt goede engineers. Loops maken productie sneller. Ze doen niets voor review. Als je al verdrinkt in PR's die je niet snel genoeg kunt reviewen, helpt het toevoegen van een loop die tien keer meer code genereert niet — het begraaft je. De beperking is gewoon verplaatst. Je hebt het deel geoptimaliseerd dat niet het probleem was. Voordat je een loop bouwt, vraag jezelf eerlijk: is typen mijn knelpunt, of is vouchen mijn knelpunt? Als het vouchen is, maakt een loop het erger.

Het verenigende principe: een loop is alleen zo betrouwbaar als het ding erin dat nee kan zeggen. Geen test, geen typecontrole, geen echte fout om op te reageren — geen loop. Gewoon een agent die naar zichzelf knikt terwijl de meter loopt.

Wat dit daadwerkelijk verandert aan je werk

Dus waar laat dit je praktisch, deze week?

De eerlijke lezing van de "schrijf loops, geen prompts"-beweging is dat het richtingsmatig correct en tactisch overdreven is. De toekomst is oprecht loops — Cherny heeft geen ongelijk dat zijn baan nu het schrijven van de machinerie is, niet de prompts. Maar het getal van 68% is de realiteitscheck: de loops die contact met productie overleven zijn klein, bewaakt en begeleid. De droom van een vloot van tweehonderd agents die onbeheerd draait is echt voor de mensen die kogelvrije verificatie rond elke laag hebben gebouwd. Voor alle anderen is het een slop-generator met een creditcard.

Wat ik vandaag daadwerkelijk zou doen: neem één repetitieve taak die je met een AI-agent doet — degene waarbij je steeds dezelfde soort prompt blijft typen. Schrijf eerst de stopconditie op, voor al het andere. Maak het een feit, geen mening: een test, een exitcode, een statuscontrole. Als je dat feit niet kunt benoemen, heb je net ontdekt dat de taak niet loop-klaar is, en heb je jezelf een les van $12 bespaard. Als je het wel kunt benoemen, heb je het moeilijkste deel van de loop al gebouwd. De trigger en actie zijn de makkelijke helft.

Het mentale model dat ik wil dat je meeneemt is klein genoeg om op een sticky note te passen: een loop is een machine om redeneer-actie-observeer te herhalen totdat een ding dat nee kan zeggen ja zegt. Ontwerp dat "ding dat nee kan zeggen" eerst. Al het andere is leidingwerk.

Die op hol geslagen loop die me $12 kostte was geen falen van de agent. Het was een falen van definitie — ik bouwde het leidingwerk voordat ik de poort bouwde. Bouw eerst de poort. Dan kun je de loop laten draaien, en daadwerkelijk vertrouwen wat hij je overhandigt wanneer hij stopt.

Veelgestelde vragen

Wat is loop engineering?

Loop engineering is de discipline van het ontwerpen van de trigger, actie en stopconditie van een autonome agent zodat deze kan draaien, zijn eigen output kan verifiëren en kan stoppen op objectieve criteria — in plaats van afhankelijk te zijn van een enkele door mensen geschreven prompt. De werkeenheid verschuift van de prompt naar de loop zelf. Voor de volledige anatomie, zie de sectie trigger/actie/stopconditie hierboven.

Is loop engineering hetzelfde als prompt engineering?

Nee. Prompt engineering optimaliseert een enkele instructie die je aan het model geeft; loop engineering optimaliseert de machinerie die het model herhaaldelijk prompt en beslist wanneer het werk klaar is. Zoals Boris Cherny het zei: "Mijn taak is het schrijven van loops" — de prompt wordt een intern detail van de loop, niet het ding dat je met de hand maakt.

Wanneer moet je geen agent-loop gebruiken?

Sla een agent-loop over als je een solo-bouwer bent op een consumentenplan (tokenkosten stapelen zich op bij elke iteratie), als je code geen geautomatiseerde verificatie heeft (tests, types, CI) om als objectieve stopconditie te dienen, of als je echte knelpunt reviewcapaciteit is in plaats van typesnelheid. Een onderzoek uit 2025 onder 306 professionals vond dat 68% van de productie-agents tien stappen of minder draait voordat een mens ingrijpt — klein en begeleid verslaat autonoom en oncontroleerbaar.

Wat is het maker-checker patroon bij AI-agents?

Het maker-checker patroon splitst een agent-loop in twee rollen: één agent produceert het werk en een aparte agent beoordeelt het tegen criteria. Omdat de checker de output niet heeft gemaakt, heeft hij geen reden om het af te stempelen — wat de loop een echte tegenstander geeft die kan terugduwen. Het is de schoonste oplossing voor loops waarvan de stopconditie anders subjectief zou zijn.

Wat maakt de stopconditie van een agent-loop betrouwbaar?

Verificatiegetrouwheid. Een objectieve poort — een slagende unit test, een groene CI-pipeline, een HTTP 200 — is een feit dat de agent niet kan faken, zodat de loop onbeheerd kan draaien. Een subjectieve poort, zoals een LLM die beoordeelt of een afbeelding "er goed uitziet," is een mening die makkelijk te misleiden is, dus het heeft een mens in de stoel nodig of een harde limiet op pogingen. Stem de autonomie van de loop af op hoe getrouw zijn poort het echte doel meet.

Laten we samenwerken

Wilt u AI-systemen bouwen, workflows automatiseren of uw technische infrastructuur opschalen? Ik help graag.

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