Het tijdperk van de prompt is voorbij. Welkom bij loop engineering

Een Oostenrijkse ontwikkelaar liet zijn AI 90 minuten lang zelfstandig bier brouwen. Een andere bouwer typte één zin, ging koffie zetten en kwam terug bij drie afgewerkte pull requests. Wat ze gemeen hebben: niemand zat te prompten. Dit is de verschuiving waar de hele AI-wereld het deze zomer over heeft.

In de tweede week van juni 2026 herschikte één idee hoe een groot deel van de techwereld over AI praat. Het begon met een bericht van Peter Steinberger — de Oostenrijker achter OpenClaw, het open-source agentproject dat React voorbijstreefde als snelst groeiende repo op GitHub. Hij schreef twaalf woorden:

"You shouldn't be prompting coding agents anymore. You should be designing loops that prompt your agents."

Het bericht haalde naar verluidt 6,5 miljoen views in nog geen 24 uur. Een paar dagen eerder had Boris Cherny, de bedenker van Claude Code bij Anthropic, op een podium vrijwel hetzelfde gezegd: hij prompt Claude niet meer zelf. Hij heeft loops draaien die Claude aansturen en zelf bepalen wat er moet gebeuren. Zijn werk, zei hij, is het schrijven van loops.

Twee uitspraken. Miljoenen views. En een week lang ruzie op de tijdlijn, want bijna niemand kon uitleggen wát een loop nou eigenlijk is.

Hoog tijd om dat helder te krijgen — want achter de hype zit een echte verschuiving die raakt aan hoe ieder bedrijf, van eenpitter tot multinational, de komende jaren met AI gaat werken.

Van "schrijf de perfecte prompt" naar "bouw het systeem dat prompt"

Twee jaar lang was de manier om iets uit een AI-agent te halen simpel: schrijf een goede prompt, lees wat eruit komt, typ het volgende. Jij was het gereedschap aan het vasthouden — beurt na beurt. De vaardigheid heette prompt engineering: de juiste woorden vinden zodat het model op koers bleef.

Loop engineering draait dat om. Je taak is niet langer het schrijven van de prompt die de klus afmaakt. Je taak is het ontwerpen van het systeem dat zélf bepaalt welke prompt er volgt, hem uitvoert, het resultaat leest en beslist of het doorgaat — zonder een mens aan het toetsenbord.

De analogie die het beste blijft hangen: prompt engineering is schaken — één weloverwogen zet tegelijk. Loop engineering is het bouwen van de schaakcomputer. Je definieert het doel, stelt de regels op en laat de machine spelen.

Het is nuttig om te zien dat dit geen plotselinge sprong is, maar de vierde stap in een gestage migratie naar buiten:

1. Prompt engineering (2022–2024) — de kunst van de juiste woorden.
2. Context engineering (2025) — alles wat het model ziet op het moment van uitvoeren: gespreksgeschiedenis, opgehaalde documenten, tooluitvoer. Shopify-CTO Tobi Lütke gaf de definitie die bleef hangen: zorg dat het model alle context heeft om de taak plausibel op te kunnen lossen.
3. Harness engineering (begin 2026) — de hele omgeving van scaffolding, tools en feedback rondom één agent.
4. Loop engineering (juni 2026) — de cyclus die de agent áándrijft. Elke laag verpakt de vorige zonder hem te vervangen.

Waarom nu? Omdat de onderliggende agents eindelijk goed genoeg werden. Tegen midden 2026 kunnen agents lang genoeg zelfstandig draaien — en goed genoeg herstellen van hun eigen fouten — dat het knelpunt verschoof. Als één agent-run een uur duurt en tientallen bestanden raakt, is de hoogste hefboom niet meer een scherpere prompt schrijven. Het is een loop ontwerpen die de agent productief, geverifieerd en op koers houdt — ook terwijl jij slaapt.

De grootvader van alle loops: een bash-script genaamd Ralph

Voordat iemand het "loop engineering" noemde, was er Ralph. In juli 2025 beschreef ontwikkelaar Geoffrey Huntley hoe hij een coding-agent in een doodgewone while-loop draaide: voer steeds dezelfde prompt tegen een geschreven specificatie, laat de agent één taak oppakken en uitvoeren, start dan een verse instantie en voer exact diezelfde prompt opnieuw.

In Huntley's eigen woorden: "Ralph is een bash-loop." Elke iteratie reset de context naar een vaste set ankerbestanden. De voortgang leeft op schijf en in git, niet in een steeds langer wordend gesprek. De agent doet één afgebakende eenheid werk per ronde, valideert, en stopt.

Het verbluffende detail: Huntley bouwde met Ralph een complete programmeertaal voor ongeveer 297 dollar aan API-kosten — een getal dat sindsdien eindeloos rondgaat in vakkringen. Het bewees dat een belachelijk simpel systeem, mits goed ontworpen, echt werk kan afleveren.

Sindsdien is het wel iets serieuzer geworden. In een gedocumenteerd experiment draaide één goal-gedreven loop 25 uur onafgebroken, verbruikte 13 miljoen tokens en produceerde 30.000 regels code. En een open-source project genaamd Gas Town coördineert inmiddels 20 tot 30 agents tegelijk via een "burgemeester"-agent, met patrouille-agents die continu loops draaien en hun staat in git bewaren zodat het werk een crash overleeft.

De anatomie van een loop: vier moves, plus geheugen

Strip de jargon en een loop is vier bewegingen op herhaling:

Ontdek → plan → voer uit → verifieer → (herhaal tot een conditie waar is.)

Vroeger was jij die loop. Jij stond tussen de stappen van de agent in: je las de output, ving de fout, besloot wat er daarna gebeurde. Loop engineering is uit die binnenste cyclus stappen en omhoog gaan naar het ontwerpen van de baan waarop de agent rijdt.

Een loop die echt onbewaakt draait, heeft volgens de inmiddels gangbare indeling (van AI-leider Addy Osmani) vijf bouwstenen plus één geheugen:

• Automations — geplande taken die op een vast ritme afgaan en zelf werk ontdekken. Dit is de hartslag: zonder schema heb je een eenmalige sessie, mét schema gebeurt het werk of je nu de laptop opent of niet.
• Worktrees — geïsoleerde werkomgevingen zodat meerdere agents elkaars werk niet overschrijven.
• Skills — vastgelegde projectkennis, zodat de agent niet elke keer koud begint en gokt.
• Connectors (MCP) — de koppeling met je echte gereedschap: je issuetracker, je database, Slack.
• Sub-agents — scheid de maker van de controleur. Het model dat het werk maakte, is veel te mild om zijn eigen huiswerk te beoordelen.

En dan de zesde, de spil: het geheugen. Een simpel markdownbestand of een bord in je projecttool dat buiten één gesprek leeft. Het model vergeet alles tussen runs, dus wat moet overleven, leeft op schijf. De agent vergeet, het geheugen niet.

Die laatste regel is belangrijker dan hij klinkt. Het geheugenbestand wordt namelijk óók je logboek: als jij 's ochtends bij de "menselijke poort" gaat zitten, lees je niet het volledige transcript van elke run — je leest de samenvatting van wat er klaar is, wat loopt en wat een mens nodig heeft.

Vier patronen die 95% van de praktijk dekken

Volgens een analyse van Agent Shortlist zijn vrijwel alle productie-loops een variant van vier patronen — en de meeste werkstromen combineren er twee of drie:

1. De heartbeat. De agent wordt elk vast interval wakker (elke 5 minuten, elk uur, elke dienst), checkt of er werk is, handelt of slaapt. Klassiek voorbeeld: een support-agent die elke 10 minuten de wachtrij checkt.
2. De cron. Verankerd aan tijd, niet aan toestand. Elke vrijdag om 16:00 draait de wekelijkse analyse — of iemand erom vraagt of niet. De kracht is voorspelbaarheid.
3. De event-trigger (webhook). De agent reageert op iets wat gebeurt: een nieuw ticket landt, een mail komt binnen. De kracht is realtime-reactie.
4. De goal-loop. De agent krijgt een doel ("maak een concurrentieanalyse van de top vijf spelers") en blijft proberen tot een eigen succescheck waar is. De kracht is onbegrensde inzet op een goed gedefinieerd doel — maar dit is ook het duurste en gevaarlijkste patroon.

Wat dit in de praktijk oplevert — buiten de codewereld

Loop engineering ontstond bij programmeurs, maar de patronen zijn breed toepasbaar. Een greep uit werkstromen die bedrijven vandaag al draaien:

• Klantenservice die op events reageert. Een ticket landt binnen, de agent leest het, classificeert het, schrijft een concept en besluit zelf: versturen of escaleren naar een mens.
• Error-sweeps op productielogs. Een typische productieomgeving genereert honderden logregels per dag, grotendeels onschuldig. Een loop trieert ze elk uur, onderdrukt vals alarm dat anders je kanalen verstopt, en opent alleen voor echte anomalieën een ticket met een Slack-melding.
• Leadkwalificatie in bulk. De agent verrijkt elke binnenkomende lead, scoort tegen je ideale klantprofiel, schrijft een korte samenvatting in het CRM en triggert de juiste vervolgstap — en loopt door tot elke lead behandeld is, ook als het volume piekt.
• Concurrentiemonitoring. Wekelijks checkt een loop of concurrenten nieuwe content of prijzen hebben gepubliceerd en levert een digest die het team in dertig seconden leest in plaats van drie uur compileren.
• Datakwaliteit bewaken. De agent loopt records langs, corrigeert lage-risico-problemen automatisch (formattering, dubbelingen) en escaleert de risicovolle gevallen met een voorgestelde fix.

Het ontwerpprincipe dat overal terugkomt: handel de duidelijke gevallen automatisch af, escaleer de twijfelgevallen, en leg altijd vast wat er is gedaan.

Het "super-individu": wat OpenClaw liet zien

Geen verhaal over loops zonder de man die het balletje aan het rollen bracht. Steinbergers eigen geschiedenis is een case op zich. Hij bouwde dertien jaar lang PDF-software (PSPDFKit, dat hij in 2021 voor ruim 100 miljoen euro verkocht). Na een periode van "founder-depressie" begon hij in 2025 weer te tinkeren — en bouwde in november 2025 in ongeveer een uur een prototype dat OpenClaw zou worden.

Wat eronder zit, is technisch niet bijzonder: het roept gewoon de Claude-API aan, draait op een open-source framework en op gewone servers. En tóch lukte het één persoon om in een paar weken iets te bouwen dat de aandacht trok van de CEO's van OpenAI, Meta én Microsoft (Satya Nadella belde naar verluidt persoonlijk). In februari 2026 ging Steinberger naar OpenAI; OpenClaw bleef open source onder een onafhankelijke stichting.

Maar het interessantste zijn de dingen die gewone mensen ermee bouwden. Op een conferentie in Wenen ontmoette Steinberger een man van 60, een bier-sommelier die nog nooit een regel code had geschreven. Die koppelde OpenClaw via Bluetooth aan zijn brouwinstallatie, stuurde één prompt — en de agent draaide zelfstandig het hele brouwproces van 90 minuten: temperatuurcurves, hoptoevoegingen, alles. Daarna stelde de agent voor om er maar een website bij te bouwen, voegde betalingen toe, en er ontstond een echt product. Een andere gebruiker liet zijn agent autodealers afbellen om de beste prijs voor een truck te onderhandelen. In Shenzhen stonden mensen in de rij bij het Tencent-kantoor om hun "lobster" geïnstalleerd te krijgen — de stad geeft er zelfs subsidie voor.

Dit is wat commentatoren het "super-individu" gingen noemen: één mens die met goed ontworpen loops het werk van een heel team aankan.

De keerzijde: waar loops stuklopen

Hier wordt het eerlijk. Steinberger zelf waarschuwt het scherpst. Ontwikkelaars trappen makkelijk in de val van een illusie van productiviteit — het voelt alsof je opschiet, terwijl het project niet vooruitkomt. "Zonder visie en zonder te weten wat je bouwt, produceer je rommel," zei hij. Met AI kun je nu "alles bouwen", maar ideeën en smaak zijn de sleutel. Hij moest zichzelf uiteindelijk dwingen te stoppen met het constante mee-programmeren — niet omdat het niet nuttig was, maar omdat het zó nuttig was dat het verslavend werd.

Drie problemen worden bovendien scherper naarmate de loop beter werkt, niet makkelijker:

De verifieerder is het echte knelpunt — niet het model. Een treffende opmerking uit de junidiscussie: een loop ontwerpen is de helft; de andere helft is iets in de loop stoppen dat nee kan zeggen — een test, een typecheck, een echte fout. Een loop zonder tegenkracht is de agent die in herhaling met zichzelf instemt. Daarom scheid je de maker van de controleur, en geef je de goal-loop een conditie die de agent ook echt kan toetsen.

Je begrip verdampt als je het toelaat. Hoe sneller de loop dingen oplevert die jij niet zelf maakte, hoe groter het gat tussen wat er bestaat en wat jij nog snapt. Een soepele loop laat dat gat sneller groeien.

De comfortabele houding is de gevaarlijke. Als de loop zichzelf draait, is het verleidelijk om geen mening meer te hebben en aan te nemen wat eruit komt. Dezelfde handeling — de loop ontwerpen — is de remedie als je het met oordeelsvermogen doet, en het gaspedaal naar de afgrond als je het doet om niet te hoeven nadenken.

En dan de kosten. Een geplande loop met een verifieerder na elke beurt verbrandt razendsnel tokens; agents verbruiken al snel een veelvoud van een gewone chat, in multi-agent-opstellingen nog meer. Het hoofdfalen van loop engineering is dan ook kosten die op hol slaan. Vier controles die in elke productie-loop horen:

• Een iteratie-cap (bijvoorbeeld maximaal 50 cycli). Goal-loops stoppen niet vanzelf.
• Een dagbudget-cap op tokens per werkstroom per dag.
• Een succesconditie die de agent zelf kan evalueren.
• Een rate limit — een webhook-storm die tienduizend events in een minuut binnenduwt, kan tienduizend agent-runs starten en je budget in een uur opmaken.

Twee mensen, dezelfde loop, tegengesteld resultaat

De scherpste observatie uit alle stukken die we erop nalazen: twee mensen kunnen exact dezelfde loop bouwen en volkomen tegengestelde uitkomsten krijgen.

De een gebruikt hem om sneller te gaan op werk dat hij diep begrijpt. De ander gebruikt hem om dat begrip juist te vermijden. De loop kent het verschil niet. Jij wel.

Dát maakt loop-ontwerp moeilijker dan prompt engineering, niet makkelijker. Het punt van Cherny is nooit geweest dat het werk lichter werd. Het is dat het hefboompunt is verschoven.

Hoe begin je?

Voor wie hiermee aan de slag wil, drie nuchtere lessen uit de praktijk:

1. Begin smal. Pak één terugkerend, goed begrepen proces — niet je meest complexe. Bouw daar één loop omheen, krijg hem werkend, en breid pas dan uit. Alles tegelijk willen automatiseren is de snelste weg naar een loop die overal stilletjes lekt.
2. Bouw eerst de tegenkracht. Een loop zonder verifieerder is een agent die met zichzelf instemt. Bepaal vóór je begint hoe "goed" en "klaar" eruitzien, en wie of wat dat toetst.
3. Hou de mens op de plekken die ertoe doen. Niet als vangnet voor als de agent faalt, maar als bewuste ontwerpkeuze: de agent handelt af wat redeneerbaar is, de mens handelt af wat autoriteit, context of verantwoordelijkheid vereist — en alles wat onomkeerbaar is.

Het tijdperk van de losse prompt is daarmee niet voorbij; prompten blijft nuttig. Maar het zwaartepunt verschuift, en de bouwstenen liggen voor iedereen klaar — van de eenpitter met een brouwketel tot de onderneming met honderd processen.

Bouw de loop. Maar bouw hem als iemand die van plan is de engineer te blíjven, niet alleen degene die op start drukt.

// Over de auteur

Remy Gieling

Mede-oprichter, AI-expert & bestseller-auteur

Tech-expert (1988) gespecialiseerd in kunstmatige intelligentie en mede-oprichter van ai.nl, The Automation Group, Proxies en eBrain.ai. Oud-hoofdredacteur van diverse zakenmerken en daardoor een geoefend verteller op het podium en in de media. Verzorgt jaarlijks 150+ AI-keynotes in binnen- en buitenland en is gastdocent aan Nyenrode. Co-auteur van zeven boeken, waaronder 'Handboek AI Strategie' en 'AI Agents', en bekend als presentator op radio en RTL Z. Reist langs de labs van OpenAI, Nvidia en Tencent en vertaalt de nieuwste doorbraken naar inzichten die leiders direct kunnen toepassen.

LinkedIn