Wat is loop engineering? Een duidelijke definitie

Wat loop engineering betekent

Loop engineering is de praktijk waarbij de herhalende cyclus wordt ontworpen waarin een AI-agent draait: wat de agent activeert, waar deze toegang toe heeft, hoe de output wordt gecontroleerd en wat de agent stopt. Prompt engineering vormt één bericht voor een model. Loop engineering vormt het proces dat duizenden berichten verstuurt terwijl u slaapt. De werkeenheid verschuift van de prompt naar de loop.

De korte versie: u stopt met het schrijven van instructies en begint met het schrijven van een controlesysteem. De agent heeft nog steeds goede instructies nodig, maar deze worden een onderdeel binnen een cyclus die volgens een schema draait, in een geïsoleerde kopie van uw code werkt, het eigen resultaat met een test bewijst en stopt wanneer het budget op is.

Waarom de term in 2026 verscheen

De naam wordt momenteel publiekelijk vastgelegd. De GitHub-repository cobusgreyling/loop-engineering passeerde binnen twee maanden na de eerste verschijning (peildatum juli 2026) de 9.600 sterren, onder de noemer "Stop prompting. Design the loop. Get a score." Het verzamelt de verschuiving in zes bouwstenen: planning, worktrees, vaardigheden, plugins en connectors, sub-agents en duurzaam geheugen dat buiten het gesprek wordt bewaard.

Het citeert Boris Cherny, die bij Anthropic leiding geeft aan Claude Code:

Ik prompt Claude niet meer. Ik heb loops draaien die Claude prompten.

Een tweede repository, AI-Builder-Club/skills, staat op bijna 1.100 sterren (peildatum juli 2026) en benoemt de twee rollen direct: een "codebase harness" dat een repository veilig maakt voor een agent om tests en deployments in uit te voeren, en een "loop engineer" die workflows bouwt die geactiveerd worden door een trigger, het werk uitvoeren en de opgedane kennis wegschrijven naar een gedeeld bestand zodat de volgende loop dit kan lezen.

Geen van beide repositories heeft deze werkwijze uitgevonden. Iedereen die wel eens een nightly build, een linter in continuous integration of een cron job die een ticket opent heeft gedraaid, kent de vorm al. Wat nieuw is, is dat de werker binnen de loop nu niet-deterministisch is, wat verandert wat de omliggende machinerie moet doen.

De vier onderdelen van een loop

Elke werkende loop bevat deze vier onderdelen. Een loop die er een mist, is de loop die u om 3 uur 's nachts wakker maakt.

• Trigger. De gebeurtenis die een run start: een timer, een webhook, een nieuwe pull request of een alert.
• Boundary. De bestanden, inloggegevens en het netwerk die de agent tijdens die run mag benaderen.
• Verification. Een controle met een exit code die bepaalt of de output van de run wordt bewaard of verwijderd.
• Budget. De limiet voor tokens, tijd en geld die een run beëindigt, ongeacht of deze is geslaagd.

Lees deze vier punten als vragen en u heeft een ontwerpbeoordeling voor elke agent die u onbeheerd wilt laten draaien.

Trigger: wat de agent activeert

Een timer is de meest eenvoudige trigger. Op een Linux-server geniet een systemd timer de voorkeur boven cron, omdat deze logging ondersteunt, retries volgens uw eigen voorwaarden toestaat en geen tweede exemplaar start van een unit die nog actief is. Die laatste eigenschap elimineert de meest voorkomende overlap-fout in agent-loops: twee processen die tegelijkertijd dezelfde branch bewerken.

Schrijf de unit naar /etc/systemd/system/agent-loop.service:

[Unit]
Description=Agent loop: triage open issues
After=network-online.target
Wants=network-online.target

[Service]
Type=oneshot
User=agent
WorkingDirectory=/srv/agent/repo
ExecStart=/srv/agent/bin/loop.sh
TimeoutStartSec=1800

En de timer naar /etc/systemd/system/agent-loop.timer:

[Unit]
Description=Run the triage loop every 30 minutes

[Timer]
OnBootSec=5min
OnUnitActiveSec=30min
Unit=agent-loop.service

[Install]
WantedBy=timers.target

sudo systemctl daemon-reload
sudo systemctl enable --now agent-loop.timer
systemctl list-timers agent-loop.timer

systemctl list-timers hoort een NEXT-kolom te tonen met een tijdstip in de toekomst en een LEFT-kolom die aftelt. Een leeg resultaat betekent dat de timer niet is ingeschakeld, omdat enable zonder --now de timer alleen voor de volgende boot inplant. TimeoutStartSec=1800 is belangrijker dan het lijkt: een agent die blijft hangen in afwachting van input houdt de unit anders voor eeuwig actief, waardoor de timer nooit meer opnieuw wordt geactiveerd. Bekijk een run met journalctl -u agent-loop.service -n 50.

Als u de loop toch vanuit cron aanstuurt, voeg dan uw eigen overlap-beveiliging toe, aangezien cron zonder problemen een tweede exemplaar start:

*/30 * * * * /usr/bin/flock -n /tmp/agent-loop.lock /srv/agent/bin/loop.sh

flock -n sluit direct af met status 1 wanneer de lock in gebruik is, waardoor de tweede run geruisloos verdwijnt in plaats van te concurreren met de eerste. Dezelfde systemd service en timer setup is van toepassing op elke langlopende taak op de server, ongeacht of het een agent betreft.

Boundary: geef elke run een eigen kopie

Een agent die uw werkmap bewerkt, is een agent die uw niet-gecommitteerde wijzigingen kan verliezen. Git worktrees lossen dit goedkoop op: elke run krijgt een eigen map en een eigen branch, waarbij één object store wordt gedeeld.

cd /srv/agent/repo
git worktree add -b loop/triage-01 /srv/agent/work/triage-01 origin/main
git worktree list

git worktree list print één regel per tree met het bijbehorende pad, de commit en de branch. Wanneer de run eindigt, verwijdert git worktree remove /srv/agent/work/triage-01 de map en wist git worktree prune de vermeldingen waarvan de map is verdwenen. Parallelle loops worden op dit punt veilig, omdat twee agents op twee branches in twee mappen elkaar niet kunnen overschrijven.

De boundary heeft ook betrekking op inloggegevens. Een loop die onbeheerd draait, bevat tokens met een lange levensduur, en elke run is een kans om er een te lekken naar een logbestand, een commit of een modelcontext. Beperk het token tot de ene repository die de loop aanraakt, houd het waar mogelijk buiten de omgeving die de shell van de agent zelf ziet, en lees hoe u geheimen buiten AI-agents houdt voordat u een loop toegang geeft tot productieomgevingen. Voor een strengere scheiding plaatst u de gehele loop op een wegwerp-VM die u na elke run kunt vernietigen. Welke tool u gebruikt, bepaalt ook een deel van de boundary voordat u ook maar iets schrijft; het is daarom de moeite waard om hoe de beheerde sandbox van Cowork zich verhoudt tot Claude Code op uw eigen machine te lezen voordat u beslist hoeveel isolatie u zelf moet bouwen.

Verificatie: de poort die de loop veilig maakt

Dit is het onderdeel dat een loop onderscheidt van een cron job die willekeurige opdrachten uitvoert. De output van de agent is een voorstel. De poort beslist.

#!/usr/bin/env bash
set -euo pipefail

repo=/srv/agent/repo
branch="loop/$(date -u +%Y%m%dT%H%M%SZ)"
tree="/srv/agent/work/$(basename "$branch")"

cd "$repo"
git fetch --quiet origin
git worktree add -b "$branch" "$tree" origin/main
cd "$tree"

# the agent's own command runs here, in non-interactive mode

if ! npm test; then
  echo "gate failed: discarding $branch" >&2
  cd "$repo"
  git worktree remove --force "$tree"
  exit 1
fi

git push origin "$branch"
cd "$repo"
git worktree remove "$tree"

set -euo pipefail verricht het eigenlijke werk in dat script. Zonder -e wordt een mislukte git fetch genegeerd en gaat de uitvoering door met een verouderde origin/main. Zonder -u expandeert een typefout in een variabelenaam naar een lege string, waardoor de opschoonactie op het verkeerde pad wordt uitgevoerd in plaats van dat het proces met een foutmelding stopt.

Het if ! npm test-blok vormt de kern van het concept. De exitcode van een controle die u al vertrouwt, zoals uw testsuite of typechecker, bepaalt of de branch wordt gepusht of verwijderd. Een loop zonder poort produceert werk dat niemand tijd heeft om te controleren; dat is slechter dan helemaal geen werk. Een loop met een poort produceert een branch die al aan dezelfde eisen voldoet als de branch van een menselijke bijdrager. Een geslaagde controle zegt niets over de omvang van de wijzigingen die de agent heeft doorgevoerd. Daarom is het raadzaam om de controle te combineren met een vaste instructie zoals de regel die een agent dwingt de kleinst mogelijke werkende wijziging te kiezen, waardoor de diff klein genoeg blijft om efficiënt te kunnen beoordelen.

Kies een poort die op een betrouwbare manier faalt. Een testsuite die slaagt bij een lege diff leert de loop dat niets doen een succes is. Repositories met zwakke tests resulteren in zwakke loops; daarom geven populaire repositories prioriteit aan "de codebase geschikt maken voor agents" boven "de loop schrijven". Als u wilt weten of uw suite daadwerkelijk een regressie zou detecteren in plaats van alleen de regels code uit te voeren, is mutation testing de controle die u dat antwoord geeft. En een agent die een opnieuw uitvoerbaar bewijsrapport overhandigt in plaats van u te vragen de diff te lezen zet dat antwoord om in iets wat u zelf kunt verifiëren.

Budget: wat een run stopt

Een agent die oneindig blijft proberen, leidt tot onbeperkte kosten. Voorzie elke lus van een tijdslimiet, afgedwongen door TimeoutStartSec hierboven; een teller voor het aantal pogingen in uw script; en een bestedingslimiet die is ingesteld via het account van de provider. Log vervolgens de kosten van elke run, zodat u een afwijking in de lus kunt opmerken voordat deze op de factuur verschijnt. Kostenbeheersing voor een altijd actieve agent-VPS behandelt de boekhoudkundige kant, en het beheren van de context die een agent tussen beurten meedraagt behandelt de belangrijkste factor voor de kosten per run. Een lus die elke 30 minuten dezelfde repository opnieuw inleest, betaalt daar namelijk elke 30 minuten voor.

Kosten zijn de reden waarom lussen meestal de voorkeur krijgen boven één lange sessie. Een run die fris begint, één specifieke taak uitvoert en afsluit, houdt de context beperkt. Een sessie die acht uur lang open blijft staan, sleept elke eerdere fout in de geschiedenis mee en betaalt bij elke beurt voor het volledige transcript.

De patronen die de trending repositories codificeren

De repository loop-engineering somt zeven productiepatronen op; beschouw deze eerder als een menu dan als een manifest. Dagelijkse triage. Een pull-request-beheerder die toeziet op review-commentaren en deze beantwoordt. Een continuous-integration-opschoner die mislukte builds oppikt. Een dependency-opschoner. Een opsteller voor changelogs. Opschoning na een merge. Issue-triage.

Wat ze gemeen hebben, is een beperkte taak met een duidelijk eindpunt. "Herstel de mislukte build" heeft een conditie voor succes die de machine kan uitlezen. "Verbeter de codebase" heeft dat niet, waardoor het nooit een loop wordt. Het wordt een rommelig proces met een planning.

Ze delen ook een schriftelijke vastlegging. Beide repositories verplaatsen de status uit de conversatie naar bestanden in de repository: wat er is uitgevoerd, wat er is gevonden en wat er is besloten. Dat bestand is het geheugen van de loop, en het is de reden waarom een tweede loop kan voortbouwen op het werk van de eerste in plaats van het opnieuw te moeten ontdekken. Het is ook de manier waarop u een agent achteraf controleert, aangezien de context van het model verdwijnt zodra de uitvoering stopt. Live coördinatie is een apart kanaal, en één Claude Code-sessie kan werk overdragen aan een andere op dezelfde machine terwijl beide nog actief zijn, maar niets van die uitwisseling overleeft de sessie. Daarom blijft het bestand het onderdeel dat u later terugleest.

Waar loops falen

De fouten zijn voorspelbaar en herhalen zich bij verschillende teams.

• Geen controle. De output hoopt zich op, niemand controleert deze, het vertrouwen verdwijnt en de loop wordt uitgeschakeld.
• Overlap. Twee runs op één branch, of twee agents in één werkmap, veroorzaken conflicten die de agent vervolgens probeert op te lossen.
• Stille drift. De loop blijft slagen omdat de controle te zwak is om te falen.
• Onbegrensde scope. Een trigger die bij elke commit in een drukke repository afgaat, verandert binnen een dag in een kostenprobleem.

Elk probleem heeft dezelfde oplossing: verklein de taak, verscherp de controle en log de uitvoering. Als u de voorwaarde voor succes niet in één zin kunt beschrijven, is de taak niet klaar om geautomatiseerd te worden.

Aan de slag zonder het jargon

U heeft geen framework nodig. Een kleine, altijd actieve Linux-server, een git-repository waarvan de testsuite faalt wanneer dat moet, één systemd-timer en één shell-script met een if erin vormen een complete lus. Dit is oprecht het punt waar de meeste mensen moeten beginnen, omdat de ontwerpvragen beantwoord worden door het systeem te draaien in plaats van door een tool te kiezen. Zodra één lus stabiel is, is het draaien van een tweede lus grotendeels een kwestie van een extra timer en een extra worktree. Zie hoe u een AI-codeeragent op een VPS draait voor de basisconfiguratie, en de huidige zelfgehoste AI-agentopties als u wilt dat de agent zelf op hardware draait die u beheert.

FAQ

Verschilt loop engineering van prompt engineering?

Prompt engineering optimaliseert één bericht: de formulering, voorbeelden en het uitvoerformaat. Loop engineering optimaliseert de cyclus rondom het bericht: de trigger die een run start, de sandbox waarin deze draait, de controle die de uitvoer accepteert of afwijst, en het budget dat de run beëindigt. U heeft nog steeds een goede prompt nodig binnen de loop. De prompt is niet langer hetgeen dat u dagelijks bijstuurt, omdat de gate en de trigger meer invloed hebben op het resultaat.

Heb ik een framework nodig om een agent loop te bouwen?

Nee. Een systemd timer, een git worktree per run, een shell script dat eindigt met een testcommando, en een bestedingslimiet op het provider-account dekken elk onderdeel van de definitie. Frameworks voegen planningsinterfaces, gedeelde geheugenformaten en multi-agent routing toe, wat nuttig is zodra u meerdere loops draait. Ze zijn geen instapvereiste voor de eerste loop.

Wat is een codebase harness?

Dit is het geheel aan zaken waarmee een agent in een repository kan werken zonder menselijke tussenkomst: een setup met één commando, tests die non-interactief draaien en duidelijk falen, een linter, en een manier om een wijziging te deployen of te bekijken. De term komt uit dezelfde golf van repositories uit 2026 als loop engineering. De praktische test is eenvoudig: als een nieuwe menselijke bijdrager niet met één commando van clone naar groene tests kan gaan, dan kan een agent dat ook niet.

Hoe voorkom ik dat een agent loop een hoge rekening veroorzaakt?

Stel limieten in op drie niveaus. Stel TimeoutStartSec in op de systemd unit zodat een vastgelopen run wordt beëindigd. Beperk het aantal retries binnen het script in plaats van te blijven loopen tot succes. Stel een harde bestedingslimiet in op het API-account, aangezien dat het enige plafond is waar de agent niet omheen kan onderhandelen. Log daarnaast de kosten per run, omdat een loop waarvan de kosten verdubbelen meestal een loop is waarvan de scope stilletjes is verbreed.

Welke taken zijn het meest geschikt om als eerste om te zetten naar een loop?

Kies een taak met een machineleesbare voorwaarde voor succes en een kleine impact bij fouten. Het repareren van een rode build, het updaten van een dependency en het regenereren van een changelog komen hiervoor in aanmerking, omdat een testsuite of een diff het resultaat kan verifiëren. Open taken zoals refactoring of ontwerp zijn nog niet geschikt, aangezien er niets is voor de gate om te controleren, en een loop zonder gate is een dure manier om review-schuld te genereren.