Loop Engineering vs Prompt Engineering: De Waarheid

Loop Engineering vs Prompt Engineering: De Waarheid

Een vriend stuurde me vorige week een link met één regel erbij: "prompt engineering is dood." Het artikel eronder beweerde dat loop engineering het had vervangen — dat het schrijven van prompts nu een beginnersvaardigheid was, en het echte spel het bouwen van loops was die AI op de automatische piloot laten draaien.

Ik heb het hele ding twee keer gelezen. Toen opende ik mijn terminal, keek naar de loop die ik twee weken eerder had gebouwd om een traag Python-script te optimaliseren, en realiseerde me dat het artikel het precies andersom had.

Dit is het ding over het loop engineering vs prompt engineering debat dat bijna niemand hardop zegt: een loop is prompts. Het zijn prompts die keer op keer worden uitgevoerd, verpakt in structuur en een manier om te controleren of ze werkten. Elimineer het prompt-ontwerp en de loop wordt niet slimmer — hij wordt zelfverzekerd, duur fout op schaal. Dus als je je zorgen maakt dat je de memo hebt gemist en alles moet weggooien wat je over prompting hebt geleerd, ontspan. Dat hoeft niet. Maar je hebt wel een tweede vaardigheid nodig die erop gestapeld wordt, en daar gaat dit over.

Ik zal loop engineering correct definiëren, de vijf componenten doorlopen die een loop daadwerkelijk laten werken (de meeste uitleg stopt bij vier en mist degene die je portemonnee redt), je de vijf niveaus van succescriteria laten zien die bepalen of een loop überhaupt de moeite waard is om te bouwen, en je het exacte vierstappenpad geven dat ik gebruik om een eenmalige prompt om te zetten in een zelfverbeterend systeem. Er is een uitgewerkt LinkedIn-artikel voorbeeld met een echt vervelend probleem erin gebakken, omdat de makkelijke voorbeelden tegen je liegen.

Laat me beginnen met het ontkrachten van de kop die dit allemaal begon.

Vervangt loop engineering prompt engineering?

Nee. Loop engineering vervangt prompt engineering niet — het stapelt erop, omdat een loop gewoon prompts zijn die herhaaldelijk worden uitgevoerd met ondersteuning, succescriteria en een stopconditie. Betere prompts maken betere loops; slechtere prompts maken een loop die sneller faalt en meer kost.

Dat is de featured-snippet versie. Nu het deel dat ertoe doet.

Wanneer je een enkele prompt schrijft, optimaliseer je één verzoek aan een model. Je krijgt één kans, je leest de output, je past aan. Wanneer je een loop bouwt, optimaliseer je het systeem dat die prompt uitvoert — wat er tussen de aanroepen gebeurt, hoe het zijn eigen werk controleert, en wanneer het besluit te stoppen. Dat zijn oprecht verschillende vaardigheden. Maar het zijn geen substituten. Het zijn lagen.

Denk er mechanisch over na. De uitvoeringsfase van elke loop is een prompt. Als die prompt vaag is, erft elke iteratie de vaagheid — en nu betaal je voor tien vage iteraties in plaats van één. Er is een uitspraak uit het loop-engineering discours van 2026 die me bijbleef: prompt engineering faalt stilletjes — je krijgt een slecht antwoord en gaat verder — terwijl loop engineering luid en duur faalt als je de faalscenario's niet net zo zorgvuldig hebt ontworpen als het succespath. Een loop versterkt alles wat je erin stopt. Rommel-prompt, versterkte rommel.

Dus de mensen die prompt engineering dood verklaren zijn als iemand die rekenkunde overbodig verklaart omdat ze spreadsheets hebben ontdekt. De spreadsheet voert de rekenkunde duizend keer automatisch uit. Het bevrijdt je niet van het begrijpen wat de rekenkunde doet. Sterker nog, de hefboom maakt de fundamenten belangrijker, omdat fouten nu cumuleren.

Onthoud die gedachte — "loops versterken" — want het is de rode draad door elk onderdeel hieronder.

Wat loop engineering werkelijk betekent

Loop engineering is het bouwen van loops die prompts herhaaldelijk itereren, met toegevoegde ondersteuning en expliciete succescriteria, zodat een taak automatisch en efficiënt wordt voltooid zonder dat je bij elke stap moet meekijken.

Dat is het. Het woord "loop" doet hier echt werk. Je vraagt de AI niet om iets één keer te doen. Je construeert een cyclus: het handelt, je controleert of het geslaagd is, en als dat niet zo is, gaat het opnieuw — gewapend met wat het leerde van de vorige poging. De kunst zit in de ondersteuning rond de handeling, niet in de handeling zelf.

Ik wil precies zijn over het verschil met een paar dingen waarmee mensen het verwarren, omdat het contrast scherper maakt wat loop engineering is.

"Auto research"-systemen — degene die eropuit gaan en informatie verzamelen richting een doel — vereisen strikte, goed gedefinieerde succescriteria om te functioneren. Richt ze op een vaag doel en ze dwalen of stoppen willekeurig. Loop engineering deelt die eis voor duidelijke criteria maar gaat verder: het opereert over een lange horizon met voortdurende zelfverbetering, niet een enkele onderzoekssprint.

De /goal-achtige functie in tools zoals Claude Code voert een optimalisatie binnen één sessie uit. Je geeft het een controleerbaar doel, het werkt toe naar dat doel binnen één sessie, en het stopt wanneer het doel is bereikt. Dat is een prachtige, strak afgebakende loop — en ik gebruik het constant — maar het is een sprint. Echte loop engineering is de marathonversie: het persisteert over sessies heen, registreert wat er is gebeurd, en gebruikt die geschiedenis om het de volgende keer beter te doen. De enkele sessie optimaliseert; de geëngineerde loop leert.

Dat onderscheid — sessie versus lange horizon, optimaliseren versus leren — is waar statusbeheer zijn waarde bewijst. Daar komen we nog op terug.

Voor nu, het mentale model: prompt engineering schrijft de zet. Loop engineering bouwt de machine die de zet uitvoert, het resultaat beoordeelt, en beslist of hij opnieuw moet worden uitgevoerd. Als je de diepere anatomie-les wilt over hoe die machines zijn bedraad, heb ik de trigger/actie/stopconditie-structuur uitgebreid beschreven in mijn volledige gids over het ontwerpen van agent-loops — dit stuk is de strategische laag erboven.

De vijf componenten van een loop (niet vier)

De meeste uitleg over loop engineering geeft je vier fasen. Vier fasen geven je een loop die werkt totdat hij niet stopt. Dus ik geef je er vijf, en de vijfde is degene die ik op de rug van ieders hand zou tatoeëren voordat ze een loop onbeheerd laten draaien.

Hier is de volledige anatomie.

Laat me elk onderdeel de aandacht geven die het verdient, want het verschil tussen een speelgoedloop en een productieloop zit volledig in hoe serieus je deze behandelt.

Trigger: hoe de loop start zonder jou

De triggerfase is wat een loop een loop maakt in plaats van een fancy commando dat je steeds opnieuw uitvoert. Een cron-schema dat om 9:00 uur afgaat. Een webhook die afgaat wanneer een pull request wordt geopend. Een bestandswatcher die afgaat wanneer een CSV in een map landt. Het punt is dat jij niet de trigger bent. Op het moment dat een mens elke run handmatig moet starten, heb je een tool gebouwd, geen autonome loop — en dat is prima, maar weet welke je bouwt.

De triggerfase is ook waar de meeste mensen per ongeluk een afhankelijkheid van zichzelf insmokkelen. "Het draait automatisch — ik hoef alleen eerst de nieuwe gegevens erin te plakken." Dat is niet automatisch. Wees er eerlijk over van het begin, want een half-geautomatiseerde loop heeft al het faaloppervlak van automatisering en geen van de vrijheid.

Uitvoering: waar prompt engineering leeft

Dit is de motor, en het is een prompt. Of preciezer, in 2026 is het meestal een skill — een herbruikbare, benoemde functie die een goed geteste prompt en een gedefinieerd outputformaat omvat. De uitvoeringsfase is precies waar de "prompt engineering is dood"-groep het meest ongelijk heeft, want deze fase is waar al je prompt-vakmanschap wordt ingezet. Een skill die "AI-nieuws onderzoekt en een artikel schrijft" is een prompt met een functietitel.

Hoe beter deze prompt is ontworpen, hoe minder werk elke andere component hoeft te doen. Een scherpe uitvoeringsprompt produceert consistente, gestructureerde output, wat verificatie triviaal maakt. Een slordige produceert output die van run tot run sterk varieert, wat verificatie een nachtmerrie maakt en statusbeheer bijna zinloos. Loops belonen goed prompting en straffen slecht prompting — op volume.

Verificatie: de werkelijke bottleneck

Hier is een waarheid die ik te lang nodig had om te internaliseren: de verificator, niet het model, is de bottleneck in elke loop. De kernvaardigheid van loop engineering is het schrijven van het ding dat beslist of de output goed genoeg is om te stoppen.

Als je succescriterium is "is de runtime van het Python-script onder de 200ms gedaald?" — gefeliciteerd, je verificator is een stopwatch en een if-statement. Objectief. Goedkoop. Betrouwbaar. Als je succescriterium is "is dit LinkedIn-artikel beter?" — nu moet je verificator een subjectieve vraag beantwoorden, en subjectieve verificators zijn waar loops komen te sterven. We besteden een hele sectie hieraan omdat het de belangrijkste voorspeller is van of je loop zal werken.

Statusbeheer: het verschil tussen herhalen en leren

Statusbeheer is wat een loop onderscheidt die 100 keer hetzelfde doet van een loop die het de 100ste keer beter doet dan de eerste. Je registreert de output en het resultaat van elke iteratie — in een database, een logbestand, een JSON-bestand, ergens duurzaam — en je voedt die geschiedenis terug in de volgende uitvoering.

Zonder status is een loop een goudvis. Het wordt elke cyclus wakker zonder geheugen, doet dezelfde aanroep, krijgt hetzelfde resultaat. Met status kan de uitvoeringsprompt zeggen: "Hier zijn de laatste tien artikelen die je schreef en hoe elk presteerde. Doe meer van wat werkte." Dat is zelfverbeterende AI — geen magie, gewoon geheugen plus een feedbacksignaal. Statusbeheer is de onglamoureuze component die "zelfverbetering" een daadwerkelijk mechanisme maakt in plaats van een modewoord.

Stopcriteria: de component die je geld bespaart

En hier is de vijfde, degene die de viersfase-uitleg overslaat. Stopcriteria bepalen wanneer de loop eindigt. Twee schone manieren om te beëindigen: het succescriterium is bereikt, of een harde iteratielimiet is bereikt — "probeer maximaal 8 keer, geef dan op en vertel het me."

Waarom is dit niet-onderhandelbaar? Omdat een loop zonder stopconditie en een iets-te-optimistische succescontrole een machine is om je API-budget om te zetten in niets. Ik heb een loop zien besluiten dat het "nooit helemaal klaar" was, met een vaag succescriterium, en iteratie na iteratie door malen, elke keer het model aanroepend, elke keer geld kostend, geen van allen ooit een doel bevredigend dat nooit controleerbaar was. De weggelopen loop is geen hypothetisch scenario. Het is de standaard faalstand waartegen je moet ontwerpen.

Bouw de stopcriteria eerst, eerlijk gezegd, voordat je een loop vertrouwt met je credentials. Je toekomstige zelf, kijkend naar de rekening, zal dankbaar zijn.

Dat zijn de vijf. Nu de vraag die bepaalt of je de loop überhaupt moet bouwen.

Loop engineering is geen one-size-fits-all

Het verleidelijke aan loops is dat ze universeel toepasbaar aanvoelen. Alles wat je herhaaldelijk doet, kun je toch zeker loopen. Maar loops hebben een harde vereiste waaraan niet elke taak kan voldoen, en het forceren leidt tot de slechtste loops — degene die er geautomatiseerd uitzien maar stilletjes drift produceren.

De vereiste is deze: je hebt een succescriterium nodig dat de loop daadwerkelijk kan controleren.

Loops schitteren wanneer succes objectief en meetbaar is. "Verminder de runtime van dit Python-script" is het perfecte loop-doel. Waarom? Omdat de verificator een benchmark is. De loop voert het script uit, timet het, vergelijkt met de vorige run, en weet — zonder enige ambiguïteit — of het verbeterd is. Elke iteratie produceert een getal, het getal gaat in de status, en de loop kan de gradiënt beklimmen richting "sneller" zonder ooit een mens iets te vragen. Onmiddellijke, objectieve, betrouwbare feedback. Dat is loop-hemel.

Vergelijk dat nu met: "schrijf een LinkedIn-artikel van betere kwaliteit." Wat is de verificator? "Beter" volgens wie? Dezelfde AI die het schreef? Dat is een model dat zijn eigen huiswerk nakijkt — en een enkele modelinstantie lijdt aan bevestigingsbias; het zal graag zijn eigen output een 9 geven en het ding missen dat het middelmatig maakt. Er is gepubliceerd werk uit 2026 over precies deze zelf-attributiebias: AI-monitors zijn mild voor zichzelf. Dus je loop "verbetert" het artikel elke cyclus volgens zijn eigen oordeel terwijl een menselijke lezer geen verschil ziet, of erger, het ziet vervlakken terwijl het een proxy voor kwaliteit optimaliseert die het niet echt kan meten.

Dit is de centrale beoordelingscall van loop engineering, en ik zal het duidelijk zeggen: voordat je een loop bouwt, vraag je af of je een verificator kunt schrijven die je echt zou vertrouwen. Als dat niet kan, is de loop niet het antwoord — tenminste niet een volledig autonome. Voor vage doelen heb je twee eerlijke opties, en ze zijn de brug naar het loopbaar maken van subjectieve taken.

De eerste is mens-in-de-loop verificatie: de loop draait, produceert output, en pauzeert voor een mens om goed te keuren of af te wijzen voordat de iteratie als succes telt. Langzamer, maar de verificator is een echte mens die kwaliteit kan beoordelen. De tweede is een aparte AI-beoordelaar — één model doet het werk, een ander model evalueert het. De scheiding is enorm belangrijk, want het doorbreekt het nakijk-je-eigen-huiswerk-probleem. De werker mag zichzelf niet beoordelen.

Zelfs met een aparte beoordelaar, blijf wantrouwend. Een AI die subjectieve kwaliteit evalueert is nog steeds een AI, met eigen vooroordelen over hoe "goed" eruitziet. Gebruik het voor triage en om het duidelijk slechte aan het licht te brengen, maar voor alles met hoge inzet, behoud een menselijk controlepunt. Het doel is niet om mensen te verwijderen — het is om mensen te verwijderen uit de saaie, controleerbare beslissingen en ze te behouden voor de oordeelsbeslissingen.

Als je liever iemand hebt die dit soort mens-in-de-loop of beoordelaar-gebaseerde workflow met je opzet in plaats van het vanaf nul te bouwen, neem ik precies dit soort opdrachten aan — je kunt zien wat ik heb gebouwd op fiverr.com/s/EgxYmWD. Voor iedereen die het zelf bouwt, is de volgende sectie het framework dat ik gebruik om er te komen.

De Hero's Journey: vier stappen naar een loop-engineered oplossing

Je begint niet met het bouwen van een loop. Dat is de fout. Je begint met bewijzen dat de taak überhaupt met de hand mogelijk is, en je verdient je weg naar automatisering in vier stappen. Ik noem het de Hero's Journey omdat elke stap een level-up is, en een level overslaan is hoe je eindigt met een geautomatiseerde manier om het verkeerde heel snel te doen.

Stap 1 — Handmatige uitvoering: bewijs dat het met de hand werkt

Voordat je een loop bouwt, doe de taak zelf, in de chat, door de AI handmatig te prompten. Wil je een loop die AI-onderzoek omzet in LinkedIn-artikelen? Prompt eerst de AI om het één keer te doen. Lees de output. Is het echt goed? Kan een mens betrouwbaar een goed resultaat krijgen van een goede prompt?

Als je niet één goed resultaat handmatig kunt krijgen, heb je geen reden om het honderd keer te automatiseren. Deze stap is de realiteitscheck. Het is ook waar je prompt engineering wordt gesmeed — elke verfijning die je hier maakt wordt de basis waarop de hele loop staat. Haast je niet.

Stap 2 — Codificeer tot een skill

Zodra de handmatige prompt betrouwbaar werkt, kapsul het in. Zet de prompt-plus-outputformaat om in een benoemde, herbruikbare skill — een functie die je kunt aanroepen in plaats van de prompt opnieuw te typen. Dit is skill-codificatie, en het is het moment waarop je eenmalige actie een bouwsteen wordt.

Codificeren dwingt discipline af. Om een skill te maken, moet je precies definiëren wat erin gaat en precies wat eruit komt. Die structuur is precies waar de verificatie- en statuscomponenten later op leunen. Een vage prompt weerstaat codificatie; een scherpe klapt netjes in een skill. (Als je de uitgebreide versie van deze stap wilt, heb ik een complete uitleg over het bouwen van agent-skills in Claude Code geschreven die hier aansluit.)

Stap 3 — Automatiseer de skill

Voeg nu de trigger toe. Plan de skill, of koppel het aan een webhook, zodat het zonder jou draait. Op dit punt heb je automatisering: de skill gaat vanzelf af en produceert output. Let op wat je nog niet hebt — verbetering. Een geautomatiseerde skill herhaalt. Het leert niet. Het is een goudvis met een agenda.

Veel waardevolle automatiseringen stoppen precies hier, en dat is legitiem. Als de taak niet profiteert van leren — het moet gewoon betrouwbaar volgens schema worden uitgevoerd — is Stap 3 je eindstreep. Voeg geen loop toe alleen om je geavanceerd te voelen. Toen ik mijn eerste echte loop van begin tot eind bouwde, was de moeilijkste discipline het weerstaan van de drang om meteen naar Stap 4 te springen voordat de automatisering in Stap 3 zelfs maar stabiel was.

Stap 4 — Voeg zelfverbetering toe met loop engineering

Hier wordt het een echte loop. Je definieert de succescriteria, implementeert statustracking — log elke output en het resultaat ervan — en bouw het feedbackmechanisme dat die geschiedenis gebruikt om de volgende run beter te maken. Voor het LinkedIn-geval betekent dat engagement scrapen, loggen, en "hier is wat eerder goed presteerde" terugvoeren in de uitvoeringsprompt.

Dit is de stap die automatisering omzet in zelfverbeterende AI. En het is ook de stap waar alles wat we bespraken over verificatie bijt: als je succescriterium vaag is, is Stap 4 waar de loop stilletjes ontspoort. Dus je arriveert hier nadat je al hebt besloten — eerlijk — of de taak een betrouwbare verificator kan ondersteunen. De Journey front-loadt die beslissing met opzet.

Vier stappen. Handmatig, codificeren, automatiseren, verbeteren. Elk een controlepunt. Laat me nu een echt voorbeeld erdoorheen laten lopen, inclusief het deel dat ieders schone tutorial weglaat.

Een uitgewerkt voorbeeld: de LinkedIn-artikel loop (en zijn lelijke probleem)

Laten we de loop bouwen die iedereen wil — een AI die elke dag een LinkedIn-artikel schrijft en plaatst en er steeds beter in wordt — en laten we eerlijk zijn over waarom het moeilijker is dan de demo's suggereren.

Hier is het ontwerp, gekoppeld aan de vijf componenten:

• Trigger: een dagelijkse geplande run om 9:00 uur.
• Uitvoering: een skill die het AI-nieuws van de dag onderzoekt en een artikel schrijft in mijn stem.
• Verificatie: succes = aantal likes dat het artikel verdient, gescrapt van het bericht en gelogd.
• Status: een database van elk eerder artikel en hoe het presteerde, teruggevoed om het volgende te sturen.

Op papier, prachtig. Het succescriterium is zelfs numeriek — likes zijn een getal, geen gevoel. Maar voer het uit en je stuit op het probleem dat het Python-voorbeeld nooit heeft: tijdsvertraging.

Wanneer ik de runtime van een Python-script optimaliseer, is de feedback onmiddellijk. Voer het script uit, krijg de milliseconden, weet onmiddellijk of iteratie N iteratie N-1 versloeg. De loop kan snel klimmen omdat de verificator nu antwoord geeft.

De LinkedIn-loop heeft die luxe niet. Het artikel wordt om 9:00 uur gepubliceerd. De likes die je vertellen of het werkte bestaan nog niet. Ze druppelen binnen over uren, soms dagen. Dus het verificatiesignaal voor het artikel van vandaag is niet beschikbaar wanneer de run van morgen start. Je loop wil leren van resultaten die nog niet zijn gebeurd.

Dit breekt de naïeve enkele loop, en de oplossing is om de tijdlijn te splitsen. Je draait een vertraagde of parallelle scraping-loop — een aparte cyclus waarvan de enige taak is om gepubliceerde artikelen 24 of 48 uur later te herbezoeken, de engagement te scrapen, en het in de status te schrijven. De schrijfloop draait dagelijks; de meetloop loopt erachteraan en vult de resultaten achteraf in. Pas wanneer een artikel is "gerijpt" wordt zijn prestatie een trainingssignaal voor toekomstige artikelen.

Dat is de echte vorm van een zelfverbeterende contentloop, en het is significant complexer dan het Python-geval. Dezelfde vijf componenten, maar de verificatie- en statusmachinerie moet rekening houden met de kloof tussen doen en weten. De feedback van de Python-loop is onmiddellijk en objectief, dus het is enorm veel makkelijker om end-to-end te automatiseren. De feedback van de LinkedIn-loop is vertraagd en lawaaierig — likes hangen af van timing, publiek en geluk evenzeer als kwaliteit — dus zelfs met een numeriek criterium vecht je tegen signaalvertraging en verstorende variabelen.

De les generaliseert: wanneer je een loop ontwerpt, breng niet alleen in kaart of het successignaal objectief is, maar of het op tijd beschikbaar is om de volgende iteratie aan te sturen. Een numeriek criterium dat je pas volgende week kunt lezen is nog steeds een verificatieprobleem. Dit is het soort detail dat een loop die werkt in een demo onderscheidt van een die werkt in productie — en het is precies de afweging die de meeste "bouw een AI die voor je post" gidsen volledig overslaan.

Dus hoe redeneer je over dit alles voordat je bouwt? Je rangschikt je succescriterium.

De vijf niveaus van verificatie, gerangschikt

Het lot van elke loop wordt bepaald door één ding: hoe controleerbaar het succescriterium is. Na genoeg van deze te hebben gebouwd, denk ik over succescriteria op een vijfpuntsschaal, van "loop dit onmiddellijk" tot "automatiseer dit niet volledig." Hier is de ladder, van best naar slechtst.

1. Deterministisch / regelgebaseerd. De output slaagt voor een harde regel of niet. Tests slagen of falen. Het bestand compileert of niet. De JSON komt overeen met het schema of wordt afgewezen. Dit is de gouden standaard — de verificator is code, het is objectief, het is onmiddellijk, en er valt niet over te discussiëren. Als je taak hier landt, loop het zonder aarzeling.

2. Numeriek / metriekgebaseerd. Succes is een meetbaar getal dat je in een richting wilt duwen. Runtime in milliseconden. Likes. Conversieratio. Tokenkosten. Bijna net zo goed als niveau één, als het getal betrouwbaar is en snel beschikbaar. De LinkedIn-loop leeft hier — numeriek, maar naar beneden getrokken door de tijdsvertraging en ruis die we net bespraken.

3. Aparte AI-beoordelaar. Geen schone regel of getal, dus een ander model evalueert de output aan de hand van een rubric. Bruikbaar voor semi-subjectieve taken, maar je vertrouwt nu op het oordeel van één AI over het werk van een andere, en je moet alert blijven op de eigen vooroordelen van de beoordelaar. Goed voor filteren en triage, wankel voor definitieve beslissingen met hoge inzet.

4. Mens-in-de-loop. Succes is subjectief genoeg dat een persoon moet beslissen. De loop draait, pauzeert dan voor menselijke goedkeuring voordat de iteratie als succesvol telt. Betrouwbaar, want de verificator is een echt mens — maar langzaam, en het begrenst hoe autonoom de loop kan zijn. Gebruik het wanneer kwaliteit oprecht menselijk oordeel vereist.

5. Vaag / zelf-beoordeeld subjectief. "Maak het beter," beoordeeld door dezelfde AI die het maakte. Dit is het laagste niveau en, eerlijk gezegd, de gevarenzone. Het model kijkt zijn eigen huiswerk na, bevestigingsbias sluipt erin, en de loop optimaliseert een proxy die het niet echt kan meten. Vermijd het bouwen van volledig autonome loops hier. Als je in deze ruimte moet opereren, trek het de ladder op — voeg een menselijk controlepunt toe (niveau 4) of tenminste een aparte beoordelaar (niveau 3).

De aanbeveling die hieruit volgt is simpel. Mik zo hoog mogelijk op de ladder. Ontwerp je taak zodat succes regelgebaseerd of numeriek is, zelfs als dat betekent dat je het doel herdefinieert. Lukt dat niet? Doe dan niet alsof een niveau-vijf criterium goed genoeg is — voeg expliciet menselijke validatie of een aparte evaluator toe, en vertrouw nooit uitsluitend op dezelfde AI om zowel subjectieve kwaliteit te genereren als te beoordelen. Het niveau dat je eerlijk kunt bereiken vertelt je niet alleen hoe je de loop moet bouwen, maar of je het autonoom zou moeten bouwen.

Die ene vraag — "op welk niveau zit mijn succescriterium?" — zal je meer verspilde loops besparen dan elk ander advies in dit artikel.

Wat dit betekent voor hoe je daadwerkelijk zou moeten werken

Stap terug en het beeld is duidelijk: de loop engineering vs prompt engineering framing is een valse keuze. Het was nooit het een dat het ander verving. Het is een stack.

Prompt engineering is het fundament — de vaardigheid om één goede output te krijgen van één goed verzoek. Loop engineering is de verdieping die erop is gebouwd — de vaardigheid om die output herhaaldelijk uit te voeren, te beoordelen, te onthouden en te verbeteren, allemaal zonder jou aan het stuur. Je hebt beide nodig. De persoon die alleen kan prompten zit vast aan dingen met de hand doen. De persoon die probeert te loopen zonder solide prompting automatiseert chaos. De persoon die beide kan, bouwt systemen die echt zichzelf draaien en beter worden terwijl ze slapen.

En het ding dat ik het meest wil dat je meeneemt is geen techniek. Het is een gewoonte van eerlijkheid. Voordat je een loop bouwt, stel de ongemakkelijke vragen: Kan ik een verificator schrijven die ik echt zou vertrouwen? Is mijn successignaal objectief, en is het op tijd beschikbaar om de volgende iteratie aan te sturen? Heb ik een echte stopconditie gebouwd, of ben ik één vage controle verwijderd van een weggelopen rekening? De meeste mislukte loops falen bij die vragen, niet bij de code.

Als je de fundamenten onder dit alles wilt leren — prompting, skills en loop engineering samen, op de manier waarop ze daadwerkelijk passen — heb ik een Claude Code masterclass samengesteld die precies deze progressie doorloopt. Het is dezelfde Hero's Journey, van begin tot eind onderwezen.

Dus, is prompt engineering dood? Ga kijken naar de uitvoeringsfase van de beste loop die je je kunt voorstellen. Precies daar, het echte werk doend, zit een prompt. Het is nooit ergens heen gegaan. We hebben het alleen geleerd om zelf te draaien — en te onthouden wat er de vorige keer gebeurde.

De echte vraag was nooit "loops of prompts." Het is dit: van alle dingen die je keer op keer doet, welke hebben een succescriterium dat je oprecht zou vertrouwen aan een machine om te controleren? Beantwoord dat eerlijk, en je weet precies welke taken je moet loopen — en welke nog steeds jou nodig hebben.

Veelgestelde Vragen

Is prompt engineering achterhaald vanwege loop engineering?

Nee. Loop engineering vervangt prompt engineering niet — het is ervan afhankelijk. De uitvoeringsfase van een loop is een prompt die herhaaldelijk wordt uitgevoerd, dus zwakke prompts produceren zwakke loops op schaal. Beide zijn vereiste vaardigheden die stapelen in plaats van concurreren. Zie de openingssecties hierboven voor de volledige mechanische uitleg.

Wat is het verschil tussen loop engineering en prompt engineering?

Prompt engineering optimaliseert een enkel verzoek aan een model; loop engineering optimaliseert het systeem dat die prompt herhaaldelijk uitvoert — inclusief triggers, verificatie, status en stopcriteria. Prompting schrijft de zet; loop engineering bouwt de machine die de zet uitvoert en het resultaat beoordeelt.

Wanneer zou ik loop engineering niet moeten gebruiken?

Vermijd volledig autonome loops wanneer succes subjectief is en alleen kan worden beoordeeld door dezelfde AI die de output produceerde, aangezien dat bevestigingsbias en weggelopen iteraties uitnodigt. Voor vage doelen, voeg een mens-in-de-loop controlepunt of een aparte AI-beoordelaar toe. Zie de vijf-niveaus verificatieladder hierboven.

Wat zijn de componenten van een AI-agent loop?

Een complete loop heeft vijf componenten: een trigger die hem automatisch start, een uitvoeringsfase die het werk doet (meestal via een skill), een verificatiefase die succescriteria controleert, statusbeheer dat resultaten registreert en ervan leert, en stopcriteria die de loop beëindigen bij succes of na een harde iteratielimiet.

Hoe voorkom ik dat een AI-loop eindeloos draait?

Definieer expliciete stopcriteria voordat je hem uitvoert: beëindig wanneer het succescriterium is bereikt, en voeg een harde limiet op iteraties toe als vangnet. Een loop met een vage succescontrole en geen iteratielimiet is de standaard oorzaak van weggelopen API-kosten. Voor de volledige anatomie, zie mijn gids over het ontwerpen van agent-loops.

Laten We Samenwerken

Op zoek naar het bouwen van AI-systemen, het automatiseren van workflows, of het opschalen van je technische infrastructuur? Ik help je graag.

• Fiverr (maatwerk builds & integraties): fiverr.com/s/EgxYmWD
• Portfolio: mejba.me
• Ramlit Limited (enterprise oplossingen): ramlit.com
• ColorPark (design & branding): colorpark.io
• xCyberSecurity (beveiligingsdiensten): xcybersecurity.io