Waarom Ik Gestopt Ben Met Prompten En Ben Begonnen Met Lussen Bouwen

Vorige maand deelde Peter Steinberger een tweet die miljoenen Views kreeg: "Je zou geen AI-agents meer moeten beprompten. Je zou lussen moeten ontwerpen die jouw agents aansturen." Ongeveer tegelijkertijd zei Boris Cherny—de maker van Claude Code—iets vergelijkbaars op Acquired Unplugged: "Ik prompt Claude niet meer. Ik heb lussen draaien. Die promptten Claude."

En toen deed het internet wat het internet altijd doet: iedereen ging ruziën, niemand had een werkend voorbeeld gezien, en het hele gesprek verdween in abstractie.

Zelf draai ik al een paar maanden echte lussen. Niet omdat ik voorop loop—ik was gewoon zat met al dat handmatige controlewerk en heb het geautomatiseerd. Wat ik ontdekte? De lus-mentaliteit is geen geavanceerde techniek voor AI-powerusers. Het is een logische evolutie die ontstaat zodra je stopt met het behandelen van AI agents als geavanceerde knip-en-plak machines en ze gaat zien als systemen die kunnen monitoren, beslissen en namens jou actie ondernemen.

De Drie Soorten "Lussen" Waar Niemand Het Eens Over Is

Hier gaat het mis in dit gesprek: als mensen "lus" zeggen, kunnen ze één van drie dingen bedoelen, en die verschillen maken veel uit.

Type één: de autonome taak-lus—letterlijk "blijf doorgaan tot het klaar is." Denk aan Geoffrey Huntley's Ralph-script (while :; do cat PROMPT.md | claude-code; done), of het /goal commando dat Codex en Claude Code nu standaard hebben. Dit is de "zet het aan en loop weg"-modus.

Type twee: de geplande of event-gedreven lus—werk dat draait terwijl jij niet achter je bureau zit. Peter Steinberger's eigen HEARTEBEAT.md in OpenClaw is het schoolvoorbeeld: een checklist die de agent elke dertig minuten opnieuw bekijkt. Afstammelingen van dit patroon zijn Codex automations en Claude Code's geplande routines.

Type drie: orkestratie fan-out—dynamische workflows met meerdere agents die tegelijk draaien. Claude Code's map/reduce-stijl operaties vallen hieronder. Dit lijkt meer op het actor-model dan op een simpele lus.

Mijn visie? Steinberger en Cherny beschrijven type twee, ingebed in type één. De lussen die ik draai zijn gepland en event-gedreven aan de buitenkant, en een aantal daarvan voert experiment-stijl innerlijke lussen uit zodra ze getriggerd worden. Die combinatie—daar zit de echte winst.

De PR Babysitter: Mijn Toegangspoort Tot Lus-Design

Ik had al AI code review op elke pull request. Claude reviewde eerst, toen Codex' ingebouwde review, en daarna een custom GitHub Action waar ik precies controleerde wat het model zag—volledige conversatie-context plus de patch diff.

Mijn echte workflow was belachelijk: PR indienen, wachten tot reviews binnenkwamen, en dan review-comments copy-pasten naar de agent. Soms plakte ik screenshots. Het was handmatig, repetitief, en zielig.

Op een dag vroeg ik mijn agent: "Kan je niet gewoon de gh-client gebruiken en de review-status checken?" Het kon. Dus vanzelfsprekend vroeg ik: "Kan je niet gewoon blijven checken en me vertellen wanneer het klaar is?"

Die ene vraag veranderde mijn hele workflow. De agent houdt nu in de gaten of de review-status verandert, haalt nieuwe context op, analyseert de feedback, en doet het daadwerkelijke werk om het aan te pakken. De lus eindigt zodra hij een triage-beslissing neemt: accepteer de feedback, duw terug, of eskaleer naar mij.

Dit patroon generaliseert prachtig: let op state changes in externe systemen, word wakker als ze gebeuren, haal verse context, analyseer, handel, en triage. Zodra je deze vorm herkent, zie je hem overal. Het Codex-team levert zelf een babysit-pr skill, en Claude Code's documentatie noemt PR babysitting nu als hoofdgebruik voor hun /loop commando.

Inner Loops: De Agent Zijn Eigen Experimenten Laten Draaien

Er is nog een lus-patroon dat ik later waardeerde: de experiment-lus. Andrej Karpathy's autoresearch-concept bracht me op dit idee—veel iteraties draaien, resultaten meten, behouden wat werkt. Ik richtte dit op een trage Python-path en draaide 49 experimenten in een uur, waardoor p95 latency daalde van 339ms naar 34ms voor zo'n $24.

Dezelfde aanpak werkt voor lastigere problemen: debugging van agent-gedrag in productie. Als er iets misgaat—een rare trace in Braintrust, gebruikersfeedback in Slack, of iets dat ik zelf tegenkom—spin ik een worktree op, plak de trace erin, en roep de test-lus aan.

Wat deze lus anders maakt: het dwingt een discipline af waar het model's naïve intuïtie tegen vecht. Zonder toezicht zal een model "nooit X, Y, Z doen" hardcoderen in de system prompt en overfitten op die ene trace die je liet zien. De skill's references destilleren het onderzoek waarom dat faalt, en het lus-contract vereist een hypothese en een test-matrix.

Ik heb drie cases nodig: de originele falende case, een vergelijkbare positieve die dezelfde path zou moeten nemen, en een tegenvoorbeeld dat een andere path zou moeten nemen. Drie of vier probes draaien tegelijk tegen lokaal dev, waarbij de exacte user context uit de trace wordt gereconstitueerd. Elke run wordt gescoord op tool calls, latency, input-token delta en correctheid. Het model kan niet vals spelen door te onthouden—het moet daadwerkelijk begrijpen.

Wat Er Echt Verandert Als Je Lussen Bouwt

De grootste verschuiving is niet technisch—het is conceptueel. Als je een agent beprompt, ben jij nog steeds de bestuurder. Jij bent het gaspedaal, de navigator, de kwaliteitscontroleur. Lussen draaien dat om. Jij wordt de architect van systemen die zichzelf aansturen.

Dit betekent niet dat volledige autonomie het doel is. Ik sta nog steeds bij de triage-poort voor alles wat belangrijk is. De lussen regelen het saaie werk, het monitoren, de herhaling. Ik behandel de oordelen die er echt toe doen.

De tweede verschuiving is dat lussen je dwingen expliciet te zijn over succescriteria. Een goede lus heeft heldere exit-condities, heldere beslispunten, heldere eskalatiepaden. Je kunt geen lus bouwen zonder te definiëren wat "klaar" betekent. Die discipline sijpelt door naar alles anders.

Derde: lussen zijn combineerbaar. De PR babysitter werkt naast de experiment-lus. Geplande checks triggeren on-call responses. Je begint een bibliotheek te bouwen van gedragingen die samenwerken in plaats van een berg losse prompts.

De Praktische Startplek

Wil je experimenteren met lussen? Begin met iets dat je al slecht geautomatiseerd hebt. Je hebt waarschijnlijk een GitHub Action die iets op een schema draait, of een Claude Code-sessie die je handmatig opnieuw draait, of een review-proces waarbij je outputs tussen tools copy-pastet.

Pak de irritantste. Vraag jezelf af: welke state change wacht ik eigenlijk op? Welke context heeft de agent nodig als die change gebeurt? Welke beslissing moet het nemen?

Bouw dan de lus. Hij hoeft niet elegant te zijn. Hij moet werken, en hij moet jou terug in controle van je eigen tijd brengen.

De volledige configs, skills en CI-workflow achter de lussen die ik draai staan in een publieke snapshot repo: camwest/agent-skills. Het is geen gepolijst product—het is een werkend systeem dat meegroeit met wat ik leer. Dat is het punt. Lussen zijn geen bestemming; ze zijn een praktijk.

Het discourse rond AI agents verdrinkt in abstractie. Hier is de concrete versie: stop met prompten, begin met lussen bouwen, en kijk wat er gebeurt als je de machine het monitoren laat afhandelen terwijl jij de betekenis bepaalt.