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 de 9.600 sterren binnen twee maanden na de eerste verschijning (peildatum juli 2026) en toonde er ongeveer 11.600 op 2026-10-27, onder de regel "Stop prompting. Design the loop. Get a score." In juli 2026 groepeerde de README de verschuiving in zes bouwstenen: scheduling, worktrees, skills, plugins en connectors, sub-agents en duurzaam geheugen dat buiten het gesprek wordt bewaard. De huidige README bevat die lijst niet meer (gecontroleerd op 2026-10-27), maar houdt de status van de loop nog steeds bij in een bestand buiten het gesprek.

De repository noemt Boris Cherny, die Claude Code bij Anthropic leidt, als een van de inspiratiebronnen. Zijn veelgeciteerde uitspraak is:

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

Een tweede repository, AI-Builder-Club/skills, staat op bijna 1.300 sterren (peildatum 2026-10-27) en benoemt de twee rollen direct: een "codebase harness" dat een repository veilig maakt voor een agent om tests uit te voeren en te deployen, en een "loop engineer" die workflows bouwt die geactiveerd worden door een trigger, het werk uitvoeren en opschrijven wat ze hebben geleerd in een gedeeld bestand, zodat de volgende loop het kan lezen.

Geen van beide repositories heeft de praktijk 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 in de loop nu niet-deterministisch is, wat verandert wat de omliggende infrastructuur 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.

Geef de agent eerst een eigen gebruiker. Deze gebruiker maakt deel uit van de beveiligingsgrens en is daarom alleen eigenaar van /srv/agent en niets anders:

sudo useradd --system --home-dir /srv/agent --shell /usr/sbin/nologin agent
sudo chown -R agent:agent /srv/agent

Schrijf vervolgens de unit op /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 op /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 tijd in de toekomst en een LEFT-kolom die aftelt. Een leeg resultaat betekent dat de timer niet is ingeschakeld, omdat enable zonder --now de taak alleen voor de volgende boot inplant. TimeoutStartSec=1800 is belangrijker dan het lijkt. Een Type=oneshot-service wordt als 'startend' beschouwd totdat het script is afgesloten. Omdat systemd de start-timeout voor oneshot-units standaard uitschakelt, blijft een agent die wacht op invoer zonder deze regel voor eeuwig in de status 'activating' hangen. Elke volgende timer-tick vindt de unit dan nog steeds actief en start niets nieuws. Met deze regel beëindigt systemd de run na 30 minuten en markeert deze als mislukt. Als u de unit wijzigt naar het standaardtype Type=simple, dekt TimeoutStartSec de run zelf niet meer en is RuntimeMaxSec= de instelling die de duur beperkt. Lees een run uit met journalctl -u agent-loop.service -n 50.

Als u de loop liever via cron aanstuurt, voeg dan zelf een 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 onmiddellijk af met status 1 wanneer de lock aanwezig is, waardoor de tweede run geruisloos verdwijnt in plaats van te concurreren met de eerste. Dezelfde systemd service en timer configuratie is van toepassing op elke langlopende taak op de server, ongeacht of het een agent is of niet.

Boundary: geef elke run een eigen kopie

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

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 worktree, maar alleen als deze schoon is. Als de tree niet-gevolgde bestanden of gewijzigde gevolgde bestanden bevat, of submodules bevat, weigert git dit totdat u --force toevoegt. Daarom dwingt het onderstaande gate-script de verwijdering alleen af op het pad dat de run weggooit. git worktree prune wist 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 gaat ook over 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 logboek, 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 productietoegang verleent. Voor een hardere grens plaatst u de hele loop op een tijdelijke VM die u na elke run kunt vernietigen. Welk hulpmiddel u gebruikt, bepaalt ook een deel van de grens voordat u ook maar iets schrijft. Het is daarom de moeite waard om hoe Cowork's beheerde sandbox 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 wordt een typefout in een variabelenaam uitgebreid naar een lege string, waarna de opschoonactie op het verkeerde pad wordt uitgevoerd in plaats van dat het proces met een foutmelding stopt. De laatste regel bevat bewust geen --force: als de run niet-gevolgde of niet-gecommitteerde bestanden in de tree heeft achtergelaten, weigert git deze te verwijderen en beëindigt -e de run met een foutmelding na de push, in plaats van stilletjes werk te verwijderen dat niemand heeft gecommit.

Het if ! npm test-blok vormt de kern van het idee. De exitcode van een controle die u al vertrouwt, zoals uw testsuite of type checker, bepaalt of de branch wordt gepusht of vernietigd. Een loop zonder poort produceert werk waar niemand tijd voor heeft om te beoordelen; dat is erger 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 hoeveel code de agent heeft aangepast om dat punt te bereiken. Daarom is het zinvol om de controle te combineren met een vaste instructie zoals de regel die een agent dwingt de kleinst mogelijke wijziging door te voeren, waardoor de diff klein genoeg blijft om goedkoop te kunnen beoordelen.

Kies een poort die op eerlijke wijze faalt. Een testsuite die slaagt bij een lege diff leert de loop dat niets doen een succes is. Repositories met zwakke tests krijgen zwakke loops; daarom stellen trending repositories "maak de codebase agent-ready" vóór "schrijf de loop". Als u wilt weten of uw suite daadwerkelijk een regressie zou opvangen in plaats van alleen de regels uit te voeren, is mutation testing de controle die daar antwoord op geeft. En een agent die een opnieuw uitvoerbaar bewijsrapport teruggeeft in plaats van u te vragen de diff te lezen verandert dat antwoord in iets dat 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 loop-engineering repository somt acht productiepatronen op (peildatum 2026-10-27), en deze zijn eerder als menu dan als manifest te beschouwen. Dagelijkse triage. Een dunne loop die draait als GitHub Action en geen statusbestand bijhoudt. Een pull-request babysitter die toeziet op review-commentaren en deze beantwoordt. Een continuous-integration sweeper die mislukte builds oppakt. Een dependency sweeper. Een changelog-opsteller. Post-merge opschoning. Issue-triage.

Wat ze gemeen hebben, is een beperkte taak met een duidelijke voorwaarde. "Herstel de falende build" heeft een slaagconditie die de machine kan lezen. "Verbeter de codebase" heeft dat niet, dus dat wordt nooit een loop. Dat wordt een chaos met een planning.

Ze delen ook een schriftelijk verslag. Beide repositories verplaatsen de status uit het gesprek naar bestanden in de repository: wat er is gedraaid, wat het heeft gevonden, wat het heeft 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 verdwenen is 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 draaien, maar niets in die uitwisseling overleeft een van beide sessies, dus het bestand blijft 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

Is loop engineering anders dan prompt engineering?

Prompt engineering optimaliseert één bericht: formulering, voorbeelden en 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 verwerpt, en het budget dat de run beëindigt. U heeft nog steeds een goede prompt nodig binnen de loop. De prompt is echter niet langer hetgeen wat u dagelijks bijstuurt, omdat de controlemechanismen 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 account van de provider dekken elk onderdeel van de definitie. Frameworks voegen interfaces voor planning, gedeelde geheugenformaten en multi-agent routing toe, wat nuttig is zodra u meerdere loops draait. Ze zijn niet de vereiste instapdrempel voor de eerste loop.

Wat is een codebase harness?

Dit is de verzameling hulpmiddelen waarmee een agent in een repository kan werken zonder menselijke tussenkomst: een installatie met één commando, tests die non-interactief draaien en duidelijk falen, een linter, en een methode om wijzigingen te deployen of te previewen. 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 een 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 punten een limiet in. Stel TimeoutStartSec in op een Type=oneshot systemd-unit zoals hierboven, zodat een vastgelopen run wordt beëindigd (bij een Type=simple-service is het equivalent RuntimeMaxSec). 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, want een loop waarvan de kosten verdubbelen, is meestal een loop waarvan de scope stilletjes is verbreed.

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

Kies een taak met een machine-leesbare voorwaarde voor succes en een kleine impact bij fouten. Het repareren van een mislukte build, het bijwerken van een dependency en het genereren van een changelog zijn geschikt, omdat een testsuite of een diff het resultaat kan verifiëren. Open-eindig werk zoals refactoring of ontwerp is nog niet geschikt, omdat er niets is voor het controlemechanisme om te toetsen. Een loop zonder controle is een dure manier om technische schuld te creëren.