Loop Engineering voorbij de hype

Wat is Loop Engineering?

Loop Engineering is het ontwerpen van systemen die AI-agents zelfstandig door een gecontroleerde werkcyclus leiden. In plaats van een agent steeds handmatig te prompten, ontwerp je de stappen, context, kwaliteitsgates en stopvoorwaarden waarmee die agent aantoonbaar naar een doel toewerkt.

Voor softwareontwikkeling betekent dit: niet simpelweg “maak deze feature”, maar een proces waarin een wijziging wordt gepland, gespecificeerd, geïmplementeerd, getest, gereviewd en pas daarna opgeleverd. De ontwikkelaar ontwerpt dus niet alleen de prompt, maar de loop die het werk betrouwbaar maakt.

Van vibe coding naar engineering

Loop Engineering ontstaat als antwoord op de grenzen van vibe coding.

Vibe coding is een informele manier van ontwikkelen waarbij je in natuurlijke taal beschrijft wat je wilt en een AI-model de code laat genereren. Het is krachtig voor prototypes, verkenningen en kleine, afgebakende hulpmiddelen. Maar in een gedeelde codebase of bedrijfskritisch systeem is “prompt, accepteer en probeer opnieuw” geen ontwikkelproces.

Daar lopen teams al snel tegen dezelfde vragen aan:

De overgang is daarom niet van “geen AI” naar “AI”, maar van prompt & hope naar specify & verify. Vibe coding blijft nuttig als verkenningsmodus. Loop Engineering voegt de discipline toe die nodig is om AI betrouwbaar in een team en richting productie te gebruiken.

Spec-Driven Development

Een goede loop begint niet met automatiseren, maar met duidelijk maken wat “goed” betekent. Daar komt Spec-Driven Development (SDD) in beeld.

Bij SDD is de specificatie de bron van waarheid. Vóór AI code schrijft, legt het team vast wat de bedoeling is en welke grenzen gelden. Code is dan niet de enige plek waar kennis over de verandering bestaat, maar een gecontroleerde uitkomst van een gedeeld contract.

Een bruikbare specificatie bevat bijvoorbeeld:

De relatie tussen beide begrippen is eenvoudig:

Spec-Driven Development bepaalt wat het juiste resultaat is. Loop Engineering organiseert hoe AI daar gecontroleerd naartoe werkt.

Acceptatiecriteria zijn daarmee niet alleen eisen voor de uiteindelijke oplossing; zij worden de stopvoorwaarden van de loop. Als een criterium niet aantoonbaar is gehaald, gaat de taak terug naar analyse, implementatie of menselijke beoordeling.

Hoe werkt de ontwikkellus?

Een lus/loop is een herhaalbaar proces met een doel, context, actie, verificatie en een besluit over de volgende stap. De precieze invulling verschilt per team, maar voor softwareontwikkeling is dit een bruikbaar basispatroon:

Plan → Specificeer → Implementeer → Verifieer → Review → Opleveren
                       ↑                         │
                       └──── herstel / bijsturen ─┘

1. Plan

De agent verzamelt de relevante context: de change request, bestaande code, architectuurafspraken, documentatie, afhankelijkheden en risico’s. Het resultaat is geen code, maar een voorstel voor de aanpak.

2. Specificeer

Het team maakt expliciet wat er moet veranderen. Een goede specificatie bevat doel, scope, niet-doelen, acceptatiecriteria, technische grenzen en eventuele security- of compliance-eisen.

Dit sluit aan op Spec-Driven Development: de specificatie is het gedeelde contract tussen business, ontwikkelaar, reviewer en AI-agent.

3. Implementeer

De AI-agent voert een afgebakende wijziging uit. Dat kan code, tests, configuratie, documentatie of een combinatie daarvan zijn. Belangrijk is dat de agent binnen de afgesproken scope blijft en zijn tussenresultaten vastlegt.

4. Verifieer

De verandering wordt gecontroleerd met objectief bewijs. Afhankelijk van de taak kan dat bestaan uit unit- en integratietests, linting, statische analyse, securityscans, contracttests of een gecontroleerde gebruikersacceptatie.

Een test die werkelijk slaagt is sterker dan een agent die zegt: “Dit lijkt correct.”

5. Review

Een onafhankelijke reviewer beoordeelt of de wijziging aan de specificatie voldoet, of de gekozen oplossing past binnen de architectuur en of het bewijs toereikend is.

De maker en controleur moeten hierbij niet dezelfde rol hebben. Een AI-agent die zijn eigen oplossing beoordeelt, kan nuttige feedback geven, maar mag niet de enige kwaliteitsgate zijn.

6. Opleveren, herhalen of escaleren

Pas wanneer de vooraf bepaalde kwaliteitsgates zijn gehaald, kan werk worden opgeleverd. Bij een fout, onvoldoende bewijs of conflicterende context keert de loop terug naar een eerdere stap of wordt deze geëscaleerd naar een mens.

Die expliciete stop- en escalatievoorwaarden zijn essentieel. Autonomie zonder grenzen is geen automatisering, maar uitgesteld handwerk.

Een voorbeeld

Stel: een team wil een exportfunctie toevoegen aan een klantportaal.

Een losse prompt zou kunnen zijn: “Voeg een knop toe waarmee klanten hun gegevens naar CSV kunnen exporteren.” De AI kan daar snel een werkende eerste versie van maken. Maar vragen over autorisatie, privacy, logging, het exportformaat en foutafhandeling komen dan vaak pas ná de implementatie.

In een spec-driven loop begint het team anders:

Specificatie:
- Alleen gebruikers met rol Beheerder mogen exporteren
- Alleen vooraf toegestane velden mogen worden geëxporteerd
- Iedere export wordt gelogd
- De autorisatie-, inhouds- en loggingtests moeten slagen

Loop:
1. Agent analyseert huidige autorisatie en datamodel
2. Team beoordeelt het wijzigingsplan
3. Agent implementeert binnen de afgesproken scope
4. Tests leveren bewijs voor ieder acceptatiecriterium
5. Reviewer beoordeelt spec, code en testresultaten
6. Wijziging wordt geaccepteerd, hersteld of geëscaleerd

De AI blijft snel. Maar de mens en het team houden de regie over intentie, risico en kwaliteit.

De technische bouwstenen

Loop Engineering is meer dan een lange prompt. Een bruikbare implementatie bestaat doorgaans uit de volgende onderdelen:

BouwsteenFunctie in de loop
Doel en triggerBepaalt wanneer de loop start, bijvoorbeeld een issue, pull request of geplande controle
SpecificatieLegt doel, scope, kwaliteitscriteria en grenzen vast
ContextGeeft de agent relevante code, documentatie, regels, eerdere besluiten en taakstatus
Skills of instructiesBeschrijven hoe een terugkerende taak moet worden uitgevoerd
State of geheugenBewaart voortgang, artefacten, testresultaten, open vragen en beslissingen tussen stappen
ToolsGeven gecontroleerde toegang tot repository, terminal, tests, issue tracker of externe systemen
VerificatiegatesLeveren onafhankelijk bewijs, zoals geslaagde tests, scans of policychecks
Review en escalatieZorgen dat een mens beslist bij twijfel, risico of onvoldoende bewijs
ObservabilityMaakt zichtbaar wat de agent deed, waarom hij een besluit nam en waar een loop vastloopt

Voor veel teams is een kleine, enkelvoudige loop de beste start. Denk aan het voorbereiden van een pull request, het aanvullen van tests, het classificeren van issues of het controleren van verouderde documentatie. Voeg autonomie alleen toe wanneer de uitkomsten aantoonbaar betrouwbaar en herstelbaar zijn.

Kennis als geheugen

Een agent kan alleen goed handelen op basis van de context die beschikbaar is. Als architectuurkeuzes, domeinregels, incidenten en reviewbesluiten verspreid staan over chats, issues en pull requests, moet elke nieuwe agent die kennis opnieuw zien te reconstrueren.

Daarom hoort bij volwassen Loop Engineering een blijvende kennislaag:

Een llm-wiki kan beginnen als goed gestructureerde Markdown met bronverwijzingen, metadata en links tussen gerelateerde onderwerpen. Als die kennis groeit, kan een kennisgraaf helpen om relaties, overlap, tegenstrijdigheden en relevante context beter vindbaar te maken.

Het doel is niet om een perfecte encyclopedie te bouwen. Het doel is dat een volgende ontwikkelaar of AI-agent niet telkens opnieuw hoeft te raden waarom iets zo is ontworpen.

Naar Graph Engineering

Loop Engineering gaat uit van één gecontroleerde cyclus. Dat is voor veel taken precies wat je nodig hebt.

Soms wordt het werk echter complexer. Een agent moet dan bijvoorbeeld eerst informatie verzamelen, een tweede agent laat een plan maken, een derde implementeert, een vierde voert onafhankelijke verificatie uit en een vijfde beoordeelt de risico’s. Wanneer taken parallel lopen, gespecialiseerde context of andere tools nodig hebben, ontstaat een uitvoerbare graaf: Graph Engineering.

Een kennisgraaf en een uitvoerbare graaf zijn niet hetzelfde:

KennisgraafUitvoerbare graaf
Organiseert wat het systeem weetOrganiseert wie of wat het werk doet
Bevat concepten, bronnen, feiten en relatiesBevat rollen, stappen, tools, routes en beslisregels
Voorbeeld: llm-wiki met gekoppelde architectuurkennisVoorbeeld: planner → implementer → verifier → reviewer
Bouwt gedeeld geheugen opStuurt gecontroleerde uitvoering aan

Graph Engineering is daarmee een logische vervolgstap op Loop Engineering, niet een vervanging ervan. Begin met één agent en één heldere loop. Verdeel het pas over meerdere gespecialiseerde agents wanneer er een concrete reden is:

De waarde zit niet in het aantal agents, maar in heldere verantwoordelijkheden, goede context en harde verificatie. Maak dus geen graaf om de graaf: voor één doel, één domein en één duidelijk stopcriterium is één goed ingerichte loop meestal beter.

De ontwikkellijn

Vibe coding
    ↓
Spec-Driven Development
    ↓
Loop Engineering
    ↓
llm-wiki en kennisgraaf
    ↓
Graph Engineering

Loop Engineering is de stap waarop AI-ondersteund ontwikkelen volwassen wordt. Niet omdat de agent meer autonomie krijgt, maar omdat het team expliciet maakt wat het doel is, welke context nodig is, welk bewijs telt en wanneer een mens moet ingrijpen.

Zo verandert AI van een losse promptmachine in een gecontroleerd onderdeel van je ontwikkelproces: snel waar het kan, zorgvuldig waar het moet.

Van begrip naar praktijk

Wil je Loop Engineering niet alleen begrijpen, maar ook toepassen in je eigen ontwikkelteam?

In de driedaagse opleiding AI-native softwareontwikkeling werk je met Spec-Driven Development, gecontroleerde AI-loops, llm-wiki’s, kennisgrafen en agent-workflows. Je oefent met specificeren, implementeren, verifiëren en reviewen — en vertaalt de aanpak naar een haalbare pilot voor jouw organisatie.

Bekijk de opleiding AI-native softwareontwikkeling →

Verder lezen