Playbook: Loop Engineering. Stop met je AI steeds opnieuw aanzetten.
Loop engineering, uitgelegd voor wie met Copilot, Claude of ChatGPT werkt. Wat het is, waarom het nu opkomt en hoe je er vandaag zelf één opzet.
Je typt een vraag in Copilot, Claude of ChatGPT, je leest het antwoord, je ziet wat er mist en je vraagt opnieuw. En nog een keer, tot het klopt. Herken je dat? Bij elke ronde ben jij de motor. Jij zet de AI aan, jij controleert de uitkomst, jij stuurt bij. Loop engineering is het idee dat je die motor-rol overdraagt aan een systeem dat zichzelf op koers houdt tot het doel bereikt is. Grote kans dat je er nog nooit van hebt gehoord. De mensen die AI-tools bouwen praten al weken nergens anders over, met een hoop hype eromheen. In dit playbook lees je wat het is, waarom het nu opkomt en hoe je zelf je eerste loop opzet, zonder een regel code. Je leest ook waarom je de zware versie uit al die verhalen waarschijnlijk niet nodig hebt.
De vier tredes die je al half beklommen hebt
Loops zijn de bovenste trede van een ladder die je waarschijnlijk al half beklommen hebt. Onderaan staat de chatbot. Je stelt een vraag, je krijgt een antwoord en jij doet er iets mee. Dat is Copilot Chat, Claude of ChatGPT zoals de meeste mensen het gebruiken.
Een trede hoger staat de agent. Die wacht niet op elke losse instructie, hij voert een hele taak zelf uit. Claude Cowork of Copilot Cowork die een document opstelt terwijl jij koffie haalt, dat is een agent.
Daarboven de workflow. Dezelfde stappen, elke keer op dezelfde manier, met rails eromheen zodat het voorspelbaar blijft. Denk aan een vaste route die een mail binnenkrijgt, er iets mee doet en het ergens neerzet.
En de bovenste trede is de loop, het Engelse woord voor een lus. Een systeem dat een taak blijft herhalen tot een doel bereikt is en dat de bijstuur-rol overneemt die jij nu zelf speelt. Ervaren bouwers zeggen inmiddels dat hun werk vooral draait om loops schrijven. Een prompt is een losse opdracht. Een loop is een taak die vanzelf doorloopt tot het doel gehaald is.
De meeste mensen die ik in workshops tegenkom zitten op de onderste twee tredes, in Copilot of gewoon ChatGPT. Ze denken dat die bovenste trede sciencefiction is, terwijl ze de bouwstenen vaak al in handen hebben.
En waarom nu? Anthropic schreef onlangs dat we op weg zijn naar het punt waarop AI zijn eigen opvolger bouwt en traint, het sluiten van de loop. Naar eigen zeggen shippen hun engineers per kwartaal inmiddels acht keer zoveel code als voor 2025. Zover hoeft het voor jou niet te gaan. Het laat wel zien hoe hard dit nu gaat.
Een loop werkt als een thermostaat
Een loop klinkt technisch en je hebt er thuis eentje hangen. Een thermostaat. Je zet hem op 20 graden en vanaf dat moment doet hij steeds hetzelfde rondje. Hij meet de temperatuur, hij zet de verwarming aan als het te koud is en hij controleert of het doel gehaald is. Zodra het 20 graden is gaat de verwarming uit. Dat is een loop.
Elke loop, hoe simpel of ingewikkeld ook, heeft dezelfde drie onderdelen:
Een trigger. Iets dat de loop op gang brengt. Bij de thermostaat is dat de temperatuur die zakt. Bij AI is dat een vast tijdstip, een gebeurtenis zoals een binnenkomende mail, of een mens die op start drukt.
Een verifieerbaar doel. Een eindpunt waarvan je kunt vaststellen of het gehaald is. Bij de thermostaat is dat 20 graden. Bij AI is dat "alle bonnetjes hebben een categorie" of "het rapport heeft vier ingevulde secties".
Een stop. Het punt waarop de loop zichzelf uitzet. De thermostaat zet de verwarming uit als het doel bereikt is. Zonder stop blijft je AI doorstoken en dat kost geld.
Onder de motorkap draait de AI daarin een klein rondje. Verkennen wat er moet gebeuren, het doen, controleren of het klopt en herhalen tot het klaar is. Je hoeft dat rondje niet zelf te programmeren. Je hoeft alleen te weten dat het er is.
De vuistregel is simpel. Kun je een taak afvinken met ja of nee, dan kun je er een loop van maken. Kun je dat niet, dan is het meestal nog geen klus voor een loop.
Drie tijdschalen en waarom je meestal de kleinste kiest
Loops bestaan op verschillende tijdschalen en daar zit meteen de meeste verwarring. De verhalen die je online ziet gaan over agents die dagenlang doordraaien. Dat is de zwaarste variant en je hebt hem zelden nodig.
Denk aan drie maten:
De minuten-loop. Een tekst die zichzelf een paar keer langs een checklist legt voordat jij hem ziet. Klaar in de tijd dat je koffie inschenkt.
De uren-loop. Een afgebakende klus die van begin tot eind wordt afgemaakt. Bijvoorbeeld bij het ontwikkelen en testen voor een interne tooling. Onlangs heb ik zo’n loop zelf laten draaien. Ruim zeven uur non-stop op één klus, van het eerste plan tot een afgerond project.
De dagen-loop. Onderhoud dat blijft lopen. Een wekelijkse check of er documenten verlopen, of een postvak dat elke ochtend wordt voorgesorteerd.
Hoe langer een loop draait, hoe meer hij kost en hoe groter de kans dat hij ergens de verkeerde kant op gaat zonder dat je het ziet. Daarom hebben de meeste taken, tegen alle hype in, genoeg aan één klein rondje op de kleinste schaal. Een leger aan agents dat de klok rond draait is spectaculair om te lezen en zelden wat jouw werkweek nodig heeft. Begin klein en schaal pas op als je snapt wat er gebeurt.
Waarom dit je werkweek raakt, ook als je zelf nooit een loop bouwt
Misschien denk je nu dat je zelf toch geen loops gaat bouwen. Prima. Toch raakt dit je werk, om drie redenen.
Ten eerste ga je dit steeds vaker tegenkomen. Een collega, je IT-afdeling of een leverancier bouwt zoiets en jij moet kunnen beoordelen of het deugt. Als je snapt hoe een loop werkt zie je meteen of er een fatsoenlijke stop en controle in zitten, of dat iemand een blanco cheque heeft uitgeschreven.
Ten tweede zie je waar het misgaat voordat het misgaat. Denk aan een loop zonder rem, een te vaag doel of een AI die zijn eigen werk goedkeurt. Dat zijn de plekken waar het duur wordt en je herkent ze straks.
Ten derde verandert je rol. Het knelpunt gaat van zelf doen naar de loop bewaken. Of je nu terugkerend uitzoekwerk hebt als uitvoerend medewerker, een go of no-go geeft als manager of aansprakelijkheid moet beleggen als beleidsmaker, juist dan wordt jouw oordeel waardevoller. De machine doet het werk. Jij bewaakt of het klopt.
En er is één ding dat bepaalt of een loop slaagt of stukloopt. De controle of het werk goed is. Verificatie, heet dat. Het klinkt saai en het is precies het onderdeel dat de loop laat slagen. Verificatie werkt in lagen. Een model dat zijn eigen huiswerk nakijkt is de valkuil waar bijna iedereen in trapt.
Je eerste loop in drie vragen
Voordat je iets opzet teken je een loop uit op papier. Dat kost vijf minuten en het bespaart je een hoop verbrande tokens. Beantwoord deze drie vragen voor een taak die elke week terugkomt:
1. Welke terugkerende taak kost me elke week tijd?
(bijvoorbeeld: bonnetjes sorteren, mail voorsorteren,
een vast rapport maken)
2. Hoe zou iemand anders kunnen zien dat die taak goed af is?
(dat is je verifieerbare doel, zo concreet mogelijk)
3. Wanneer moet het systeem stoppen en mij erbij halen?
(een maximum, een budget, of een menselijk akkoord
voor het de deur uit gaat)Kun je die drie invullen, dan heb je de ruggengraat van een loop te pakken. Kun je vraag 2 niet beantwoorden, dan is je taak nog te vaag en dat is waardevolle informatie. Dan is het nog geen klus voor een loop.
Dit is de light versie. De volledige aanpak staat hieronder.
De rest van dit playbook is voor premium lezers. Hieronder zet je je eerste loop op. De drie soorten triggers en waar je ze vindt, de vijf niveaus van verificatie en waarom een model nooit zijn eigen werk moet beoordelen, de rem tegen een leeglopend budget, een kopieerbare rapportage-loop en de plekken waar loops ontsporen.
