Van Prompt Engineering naar Loop Engineering — waarom agentic AI pas werkt in gecontroleerde loops

Prompt engineering optimaliseert een losse interactie. Je schrijft een betere prompt, je krijgt een beter antwoord. Dat schaalt lineair: tien taken betekenen tien prompts, tien beoordelingen, tien correctierondes. Jij bent de orchestrator, de kwaliteitscontroleur, het geheugen en de escalatielijn.

Twee recente publicaties stellen dat de volgende stap niet "betere prompts" is, maar een fundamenteel andere besturingslaag. Latent.Space positioneert "Loopcraft" als de verschuiving van human-in-the-loop prompting naar loop-designed orchestration. Daniel Moka vertaalt dat in een concrete engineering discipline: een agent die werkt, controleert, faalt, leert en opnieuw probeert, zonder dat jij elke tussenstap opnieuw hoeft te prompten.

Samen schetsen ze een operationeel model voor agentic software engineering dat verder gaat dan "agents die code schrijven". De kernvraag verschuift van "welke agent is het slimst?" naar "welke loop heeft welk doel, welke verificatie, welke state en welke guardrails?"

De verschuiving: van prompten naar loops ontwerpen

Het Latent.Space-artikel haalt Peter Steinberger, Boris Cherny en Andrej Karpathy aan als signalen dat de leverage verschuift van individuele prompts naar gestapelde agent-loops. De meest bruikbare samenvatting staat in één zin: wie effectief agents wil inzetten, moet leren wanneer je "naar beneden" gaat in de loop voor betrouwbaarheid, en wanneer je "omhoog" gaat in de loop voor schaal en leverage.

Latent.Space noemt dit "stacking loops": meerdere cycli boven elkaar plaatsen. Een discovery-loop vindt werk. Een planning-loop vertaalt signalen naar taken. Een execution-loop voert uit. Een verification-loop controleert. Een memory-loop onthoudt. Een governance-loop bewaakt de grenzen.

Een klassieke agent-workflow ziet er zo uit:

Mens → prompt → agent → output → mens beoordeelt → nieuwe prompt

Een loop-based workflow ziet er zo uit:

Doel → planner → agent(s) → verifier → state update → volgende actie → escalatie bij onzekerheid

Addy Osmani beschrijft "loop engineering" als het vervangen van jezelf als degene die steeds de agent prompt, door een systeem dat dat voor je doet. Zo'n loop bestaat typisch uit automations, worktrees, skills, plugins en connectors, sub-agents en externe memory en state.

De zes lagen van een volwassen loop-architectuur

Een complete Loopcraft-architectuur heeft minimaal zes lagen:

Discovery-loop. Scant issues, logs, repositories, CI-failures, documentatie, security findings of backlog-items. Doel: werk vinden zonder dat jij alles hoeft aan te wijzen.

Planning-loop. Vertaalt ruwe signalen naar uitvoerbare taken, inclusief scope, constraints, acceptatiecriteria en afhankelijkheden.

Execution-loop. Laat een coding-, research- of ops-agent werken in een geïsoleerde context, idealiter per taak in een eigen git worktree of sandbox.

Verification-loop. Een aparte agent of rule-based harness controleert output. Niet dezelfde agent die de wijziging maakte. Dit is cruciaal: makers beoordelen hun eigen werk structureel te positief. Osmani benadrukt dit maker-checker patroon expliciet.

Memory-loop. Resultaten, besluiten, mislukte pogingen, openstaande risico's en next steps worden buiten de chat opgeslagen. Osmani noemt externe state de ruggengraat van long-running agents: het model zelf onthoudt tussen runs niets betrouwbaar.

Governance-loop. Bepaalt wanneer een agent autonoom mag handelen, wanneer read-only nodig is, wanneer approval required is, en wanneer escalatie naar een mens nodig is.

De praktische vertaling: Daniel Moka's Loop Engineering 101

Waar Latent.Space het concept strategisch positioneert, vertaalt Daniel Moka het naar een concrete engineering discipline. Zijn infographic en artikel op Craft Better Software beschrijven een loop als een cyclisch agentproces met vijf stappen:

1. Discover: vind wat nodig is
2. Plan: breek het doel op in stappen
3. Execute: voer het werk uit
4. Verify: controleer resultaat tegen doel
5. Iterate: repareer de gaten en herhaal

De kernzin uit de infographic is sterk: "A loop is an agent that works, checks, and retries by itself without you prompting each step." Dat is exact de verschuiving van chatbotgebruik naar agentic software engineering.

Moka maakt een belangrijk onderscheid tussen open en closed loops:

Open loops zijn exploratief. Agents zoeken vrij, ontdekken routes, proberen dingen uit en gebruiken veel context. Krachtig voor research, spike-opdrachten, root-cause analyse en architectuurverkenning. Het risico is drift: de agent raakt off-topic, verbrandt tokens en produceert AI-slop.

Closed loops zijn bounded. Ze hebben een duidelijk doel, vaste stappen en harde validatiechecks. Beter voor teams, CI/CD, testreparatie, dependency updates, refactoring, documentatie-drift en kleine bugfixes.

De vuistregel: 80 procent closed loop, maximaal 20 procent open loop. Open loops zijn nuttig voor discovery en planning, maar execution moet gesloten, auditeerbaar en begrensd zijn.

Single-agent loop versus fleet loop

Moka maakt een pragmatisch onderscheid dat direct toepasbaar is:

Een single-agent loop is goedkoop, eenvoudig en vaak voldoende. Eén agent voert iteratief dezelfde taak uit: reproduceer bug, schrijf failing test, fix code, run tests, herhaal.

Een fleet loop gebruikt meerdere gespecialiseerde agents onder orkestratie. Dat is zwaarder, maar nodig wanneer maker en checker gescheiden moeten zijn, of wanneer planning, implementatie, security review en documentatie apart belegd moeten worden.

Praktische verdeling:

Single-agent loops (laag risico, hoge herhaalbaarheid): README- en documentatie-updates, lint-fixes, kleine dependency updates, testreparaties, en issue triage.

Fleet loops (hoger risico, maker-checker scheiding verplicht): refactoring, security hardening, nieuwe integraties, policy-wijzigingen, en alles met mutating infrastructuur-acties.

De governance-regel: single-agent mag voorstellen en kleine patches maken. Fleet-loop is verplicht bij security, infrastructuur, authenticatie, data, policies en productie-impact.

De quality gate: het verschil tussen productiviteit en technische schuld

Moka's infographic bevat pseudo-code die vier volwassen patronen illustreert:

goal = load("VISION.md")
rules = load("RULES.md")

while True:
    work = maker.run(goal, rules)
    review = checker.run(work, tests)

    if review.passed:
        ship(work)
        break

    rules.append(review.reason)

Het doel staat op disk, niet in de chat. Versioneerbaar. Maker en checker zijn gescheiden. Geen self-review bias. De gate bepaalt of iets door mag, niet de agent zelf. Fouten worden omgezet in nieuwe regels. De loop is zelflerend.

Maar die laatste regel is ook het grootste risico: rules.append(review.reason) mag nooit ongecontroleerd gebeuren. Anders bouw je een systeem dat permanent leert van ruis, toevallige failures of foutieve reviewer-output.

Een goede quality gate bestaat uit zaken waar de agent niet over kan onderhandelen: compiler en type system, unit tests (inclusief integration, mutation en property-based), linters en static analyzers, dependency scanning en secret scanning, CI-status, en policy-as-code.

Voor gereguleerde omgevingen komen daar bij: OWASP ASVS controls voor web- en API-wijzigingen, OAuth2/OIDC regression checks bij authenticatie-wijzigingen, SBOM en dependency provenance, SAST/DAST waar passend, container image scanning, Infrastructure-as-Code scanning, en een verplichte audit-log bij iedere mutating actie.

De kwaliteitsgate moet deterministisch zijn. Een LLM-reviewer is aanvullend, niet doorslaggevend.

Self-learning loops: drie soorten memory, drie governance-niveaus

Het self-learning aspect is interessant maar governance-gevoelig. Moka zegt terecht: een loop verbetert alleen als hij lessen meeneemt en eraan gehouden wordt. Maar in enterprise-omgevingen moet je onderscheid maken tussen drie soorten memory:

Memory type	Voorbeeld	Governance
Operational memory	"Deze test faalt vaak door X"	Mag semi-automatisch
Engineering rule	"Gebruik altijd pattern Y in module Z"	Review vereist
Policy rule	"Agent mag compose recreate uitvoeren"	Altijd human approval

Self-learning mag automatisch voorstellen doen, maar niet automatisch policy- of securityregels wijzigen. Dat moet via PR, review en audit.

De vijf kritische risico's van loop-based systemen

De risico's worden juist groter wanneer loops beter worden:

Unattended failure. Een slechte prompt geeft één slecht antwoord. Een slechte loop produceert structureel slechte output op schaal.

Comprehension debt. Osmani waarschuwt: hoe sneller loops code produceren die je niet zelf hebt geschreven, hoe groter het gat wordt tussen wat het systeem doet en wat jij begrijpt.

Token burn en cost runaway. Loop-based systemen kunnen veel parallelle sub-agents, evaluaties en retries starten. Zonder budget-gates wordt dit snel economisch onhoudbaar.

Policy drift. Als loops zelf skills, prompts, configuraties of memory aanpassen, kan het systeem langzaam afwijken van de oorspronkelijke governance-intentie.

False verification. Een verifier-agent is nuttig, maar geen formeel bewijs. Voor security, privacy en productiecode blijven tests, policy-as-code, static analysis, dependency scanning en human approval nodig.

Het implementatiepad: begin met één high-signal loop

Start niet met "multi-agent alles". Start met één high-signal loop. De beste eerste kandidaat is een doc-drift-and-small-fix-loop: detecteer documentatie-drift, detecteer kleine test- en lint-failures, maak een voorstel of PR, en merge nooit automatisch.

Waarom deze loop: laag risico, hoge herhaalbaarheid, goede "done"-criteria, goedkoop om fout werk weg te gooien, en perfect om maker-checker, memory en gates te testen.

Daarna pas uitbreiden naar: repo maintenance loop, skill quality loop, integratie-validatie loop, security regression loop, kennis-synchronisatie loop, en policy drift loop.

De belangrijkste ontwerpprincipe: maak loops niet "slim". Maak ze begrensd. Een goede loop is niet een agent die alles mag proberen. Een goede loop is een klein, herhaalbaar, observeerbaar systeem met harde stopcondities, expliciete memory en een onverhandelbare quality gate.

Wat dit betekent

Loopcraft en Loop Engineering zijn geen hypewoorden. Het is een serieus architectuurpatroon voor agentic engineering. De kern is: agents worden pas echt nuttig wanneer je ze in gecontroleerde, observeerbare, herhaalbare loops plaatst.

De verschuiving is fundamenteel. Prompt engineering vraagt: "Hoe krijg ik een beter antwoord?" Loop engineering vraagt: "Hoe ontwerp ik een systeem dat herhaaldelijk goede beslissingen neemt, fouten detecteert, state behoudt en gecontroleerd opschaalt?"

Voor enterprise-omgevingen is dat tweede veel belangrijker. Het past beter bij DevSecOps, SRE, SOC automation, compliance engineering en AI governance. Het sluit aan op de agentic delivery control plane die de software-engineering rol herdefinieert, de runtime governance architectuur die formele primitieven levert voor agent-controle, en het OWASP agentic control plane dat de security-dimensie toevoegt.

Moka's model is zo bruikbaar omdat het de hype rond "AI coding while you sleep" terugbrengt naar software engineering discipline. De onderliggende boodschap is niet: laat agents autonoom code shippen. De boodschap is: automatiseer reproduceerbare grind, maar behoud eigenaarschap over merge, release en productie-impact.

De volgende volwassenheidsstap in agentic engineering is niet meer tools toevoegen. Het is loops standaardiseren, meten, auditen en stapelen.

---

Gebaseerd op: Latent.Space, "Loopcraft" (2026): strategische positionering van loop-designed orchestration als opvolger van prompt engineering, met bijdragen van Peter Steinberger, Boris Cherny en Andrej Karpathy. Daniel Moka, "Loop Engineering 101" (2026): praktische engineering discipline voor agentic loops met vijfstaps-cyclus, open/closed loop onderscheid, en quality gate patterns. Addy Osmani, "Loop Engineering": operationele definitie van loops als automations, worktrees, skills, plugins, sub-agents en externe state.