Wat is loop engineering? Definitie en uitleg

Wat loop engineering betekent

Loop engineering is het ontwerpen van de herhalende cyclus waarin een AI-agent werkt: wat de agent activeert, welke onderdelen de agent mag aanraken, hoe de uitvoer wordt gecontroleerd en waardoor de cyclus stopt. Prompt engineering bepaalt de inhoud van één bericht aan een model. Loop engineering bepaalt het proces dat duizenden berichten verstuurt terwijl u slaapt. De werkeenheid verschuift van de prompt naar de loop.

Kort gezegd: u schrijft niet langer alleen instructies, maar een besturingssysteem. De agent heeft nog steeds goede instructies nodig, maar die vormen één onderdeel van een cyclus die volgens een schema wordt uitgevoerd, in een geïsoleerde kopie van uw code werkt, het resultaat met een test controleert en stopt wanneer het budget op is.

Waarom de term in 2026 opdook

De naam krijgt momenteel publiekelijk vaste betekenis. De GitHub-repository cobusgreyling/loop-engineering bereikte binnen twee maanden na de eerste publicatie 9,600 sterren (stand van juli 2026), met de slogan "Stop prompting. Design the loop. Get a score." De repository brengt deze ontwikkeling terug tot zes bouwblokken: planning, worktrees, skills, plugins en connectors, sub-agents en duurzame opslag van geheugen buiten het gesprek.

De repository citeert Boris Cherny, die bij Anthropic Claude Code leidt:

Ik geef Claude geen prompts meer. Ik heb loops draaien die Claude prompts geven.

Een tweede repository, AI-Builder-Club/skills, heeft ongeveer 1,100 sterren (stand van juli 2026) en benoemt de twee rollen rechtstreeks: een "codebase harness" dat een repository veilig maakt voor een agent om tests uit te voeren en deployments te doen, en een "loop engineer" die workflows bouwt die door een trigger worden geactiveerd, het werk uitvoeren en hun leerpunten naar een gedeeld bestand schrijven, zodat de volgende loop deze kan lezen.

Geen van beide repositories heeft deze werkwijze bedacht. Iedereen die ooit een nightly build, een linter in continuous integration of een cron job heeft uitgevoerd die een ticket opent, herkent de structuur. Nieuw is dat de worker in de loop nu niet-deterministisch is. Daardoor moet de omliggende infrastructuur andere taken uitvoeren.

De vier onderdelen van een lus

Elke werkende lus heeft deze vier onderdelen. Een lus die er één overslaat, is de lus die u om 3am wakker maakt.

• Trigger. De gebeurtenis die een uitvoering start: een timer, een webhook, een nieuwe pull request of een waarschuwing.
• Afbakening. De bestanden, referenties en netwerken waartoe de agent tijdens die uitvoering toegang heeft.
• Verificatie. Een controle met een exit code die bepaalt of de uitvoer van de uitvoering wordt behouden of verwijderd.
• Budget. De limiet voor tokens, tijd en geld die een uitvoering beëindigt, ongeacht of deze is geslaagd.

Lees deze vier onderdelen opnieuw als vragen. Dan hebt u een ontwerpbeoordeling voor elke agent die u onbeheerd wilt laten draaien.

Trigger: wat de agent activeert

Een timer is de eenvoudigste trigger. Op een Linux-server is een systemd-timer hiervoor beter dan cron, omdat deze logt, opnieuw probeert volgens uw instellingen en geen tweede exemplaar start van een unit die nog actief is. Die laatste eigenschap voorkomt de meest voorkomende overlapfout in agentlussen: twee uitvoeringen die 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 moet een kolom NEXT tonen met een tijdstip in de toekomst en een kolom LEFT die aftelt. Een leeg resultaat betekent dat de timer niet is ingeschakeld, omdat enable zonder --now alleen voor de volgende boot wordt gepland. TimeoutStartSec=1800 is belangrijker dan het lijkt: een agent die blijft hangen terwijl deze op invoer wacht, houdt de unit anders voor onbepaalde tijd actief. De timer wordt dan nooit opnieuw geactiveerd. Lees een uitvoering met journalctl -u agent-loop.service -n 50.

Als u de lus vanuit cron aanstuurt, voegt u zelf een overlapbeveiliging toe, omdat cron zonder problemen een tweede exemplaar start:

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

flock -n wordt onmiddellijk afgesloten met status 1 wanneer de lock in gebruik is. De tweede uitvoering verdwijnt dan stilletjes in plaats van tegelijk met de eerste te werken. Dezelfde instelling van een systemd-service en timer is van toepassing op elke langlopende taak op de server, ongeacht of het om een agent gaat.

Grens: geef elke uitvoering een eigen kopie

Een agent die uw werkboom bewerkt, kan uw niet-vastgelegde werk verliezen. Git worktrees lossen dit efficiënt op: elke uitvoering krijgt een eigen directory en een eigen branch, terwijl één objectopslag 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 geeft één regel per worktree weer met het pad, de commit en de branch. Wanneer de uitvoering eindigt, verwijdert git worktree remove /srv/agent/work/triage-01 de directory en verwijdert git worktree prune vermeldingen waarvan de directory is verdwenen. Parallelle lussen zijn vanaf dat moment veilig, omdat twee agents op twee branches in twee directories elkaar niet kunnen overschrijven.

De grens heeft ook betrekking op referenties. Een lus die zonder toezicht wordt uitgevoerd, bevat tokens met een lange geldigheidsduur. Elke uitvoering kan zo'n token in een logboek, een commit of een modelcontext lekken. Beperk het token tot de ene repository die door de lus wordt gebruikt. Houd het token waar mogelijk buiten de omgeving die de eigen shell van de agent ziet. Lees hoe u referenties buiten AI-agents houdt voordat u een lus toegang tot productie geeft. Voor een strengere scheiding voert u de volledige lus uit op een tijdelijke VM die u na elke uitvoering kunt vernietigen.

Verificatie: de poort die de lus veilig maakt

Dit is het onderdeel dat een lus onderscheidt van een cron job die opdrachten uitvoert. De uitvoer van de agent is een voorstel. De poort neemt de beslissing.

#!/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 voert in dat script echt werk uit. Zonder -e wordt een mislukte git fetch genegeerd en gaat de uitvoering verder met een verouderde origin/main. Zonder -u wordt een typefout in een variabelenaam uitgebreid naar een lege tekenreeks. De opschoning wordt dan uitgevoerd op het verkeerde pad, in plaats van duidelijk te mislukken.

Het blok if ! npm test bevat het volledige concept. De afsluitcode van een controle die u al vertrouwt, zoals uw testpakket of typechecker, bepaalt of de branch wordt gepusht of verwijderd. Een lus zonder poort produceert werk dat niemand tijd heeft om te beoordelen. Dat is erger dan geen werk. Een lus met een poort produceert een branch die al aan dezelfde eisen voldoet als de branch van een menselijke bijdrager.

Kies een poort die eerlijk faalt. Een testpakket dat slaagt bij een lege diff leert de lus dat niets doen een succes is. Repositories met zwakke tests leveren zwakke lussen op. Daarom zetten populaire repositories "de codebase geschikt maken voor agents" vóór "de lus schrijven".

Budget: wat een uitvoering stopt

Een agent die eindeloos opnieuw probeert, kan onbeperkte kosten veroorzaken. Geef elke lus een maximale looptijd, die wordt afgedwongen door TimeoutStartSec hierboven; een maximumaantal pogingen in uw script; en een bestedingslimiet die door het provideraccount wordt afgedwongen. Leg vervolgens vast wat elke uitvoering heeft gekost. Zo ziet u dat een lus ontspoort voordat de factuur dat laat zien. Kostenbeheersing voor een altijd actieve agent-VPS behandelt de boekhoudkundige kant. De context beheren die een agent tussen beurten meedraagt behandelt de grootste afzonderlijke factor voor de kosten per uitvoering. Een lus die elke 30 minuten dezelfde repository opnieuw inleest, betaalt daar elke 30 minuten opnieuw voor.

Kosten zijn de reden dat lussen meestal beter zijn dan één lange sessie. Een uitvoering die met een lege context begint, één beperkte taak uitvoert en afsluit, houdt de context klein. Een sessie die acht uur open blijft, bevat alle eerdere fouten in de geschiedenis en betaalt bij elke beurt voor het volledige transcript.

De patronen die trending repositories vastleggen

De repository loop-engineering beschrijft zeven productiepatronen. Het is de moeite waard deze als een menu te lezen, niet als een manifest. Dagelijkse triage. Een pull-request-bewaker die controleert op reviewopmerkingen en daarop reageert. Een continuous-integration-opruimer die mislukte builds oppakt. Een afhankelijkhedenopruimer. Een opsteller van changelogs. Opruiming na het mergen. Issue-triage.

Wat deze patronen gemeen hebben, is een beperkte taak met een duidelijke poort. "Herstel de mislukte build" heeft een geslaagde voorwaarde die de machine kan lezen. "Verbeter de codebase" heeft die niet en wordt daarom nooit een loop. Het wordt een ongeordende taak met een planning.

Ze hebben ook een schriftelijk verslag gemeen. Beide repositories verplaatsen de status uit het gesprek 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. Daardoor kan een tweede loop voortbouwen op het werk van de eerste, in plaats van dit opnieuw te ontdekken. Zo kunt u een agent ook achteraf controleren, omdat de context van het model verdwijnt zodra de uitvoering eindigt.

Waar lussen mislukken

De oorzaken zijn eenvoudig en komen bij verschillende teams steeds terug.

• Geen controlepunt. De uitvoer stapelt zich op, niemand beoordeelt deze, het vertrouwen verdwijnt en de lus wordt uitgeschakeld.
• Overlapping. Twee uitvoeringen op één branch of twee agents in één working tree veroorzaken conflicten die de agent vervolgens probeert op te lossen.
• Stille afwijking. De lus blijft slagen omdat de controle niet streng genoeg is om te mislukken.
• Onbegrensde scope. Een trigger die bij elke commit in een drukke repository wordt geactiveerd, leidt binnen een dag tot een kostenprobleem.

Voor elk probleem geldt dezelfde oplossing: beperk de taak, maak de controle strenger en log de uitvoering. Als u de voorwaarde voor slagen niet in één zin kunt beschrijven, is de taak nog niet klaar om te worden geautomatiseerd.

Aan de slag zonder de terminologie

U hebt geen framework nodig. Een kleine Linux-server die altijd actief is, een git-repository waarvan de testsuite faalt wanneer dat hoort, één systemd-timer en één shellscript met daarin een if vormen samen een complete cyclus. Dit is echt waar de meeste mensen moeten beginnen, omdat u de ontwerpvragen beantwoordt door het geheel uit te voeren in plaats van door een tool te kiezen. Zodra één cyclus stabiel is, bestaat het uitvoeren van een tweede cyclus meestal uit een extra timer en een extra worktree. Zie hoe u een coding AI-agent op een VPS uitvoert voor de basisconfiguratie en de huidige self-hosted AI-agentopties als u de agent zelf wilt uitvoeren op hardware die u beheert.

FAQ

Is loop-engineering anders dan prompt-engineering?

Prompt-engineering optimaliseert één bericht: formulering, voorbeelden en uitvoerindeling. Loop-engineering optimaliseert de cyclus rond het bericht: de trigger die een run start, de sandbox waarin deze wordt uitgevoerd, de controle die de uitvoer accepteert of afwijst en het budget dat de cyclus beëindigt. Binnen de loop hebt u nog steeds een goede prompt nodig. De prompt is niet langer het onderdeel dat u dagelijks bijstelt, 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 shellscript dat eindigt met een testopdracht en een bestedingslimiet voor het provideraccount dekken alle onderdelen van de definitie. Frameworks voegen interfaces voor planning, indelingen voor gedeeld geheugen en routering voor meerdere agents toe. Dat is nuttig zodra u meerdere loops uitvoert. Ze zijn geen vereiste om met de eerste loop te beginnen.

Wat is een codebase-harnas?

Het is de verzameling voorzieningen waarmee een agent zonder aanwezige menselijke gebruiker in een repository kan werken: installatie met één opdracht, tests die niet-interactief worden uitgevoerd en duidelijk mislukken, een linter en een manier om een wijziging te implementeren of vooraf te bekijken. De term komt voort uit dezelfde golf van repositories uit 2026 als loop-engineering. De praktische test is eenvoudig: als een nieuwe menselijke bijdrager niet met één opdracht van clone naar geslaagde tests kan gaan, kan een agent dat ook niet.

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

Stel op drie plaatsen limieten in. Stel TimeoutStartSec in op de systemd-unit, zodat een vastgelopen run wordt beëindigd. Beperk het aantal retries in het script, in plaats van te blijven herhalen tot succes. Stel een harde bestedingslimiet in voor het API-account, omdat dat de enige limiet is waar de agent niet omheen kan redeneren. Registreer vervolgens de kosten per run, omdat een loop waarvan de kosten verdubbelen meestal een loop is waarvan de reikwijdte ongemerkt groter is geworden.

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

Kies een taak met een machinaal leesbare slaagvoorwaarde en een klein impactgebied. Het herstellen van een mislukte build, het bijwerken van een dependency en het opnieuw genereren van een changelog komen hiervoor allemaal in aanmerking, omdat een testsuite of een diff het resultaat kan aantonen. Niet-afgebakend werk, zoals refactoring of ontwerp, komt hier nog niet voor in aanmerking, omdat de gate niets heeft om te controleren. Een loop zonder gate is een dure manier om reviewachterstand te genereren.