De Ralph Wiggum prompt techniek

Stel je voor dat je ’s avonds een taak aan je AI-codeeragent geeft en de volgende ochtend wakker wordt met werkende code. Geen handmatig bijsturen, geen eindeloos ga door typen in de terminal. Dat is precies wat de Ralph Wiggum techniek belooft en in de praktijk ook steeds vaker waarmaakt. Het is een van de meest besproken technieken in de wereld van agentic coding. De naam alleen al zorgt voor een glimlach.

Wie heeft het bedacht en waar komt de naam vandaan?

De techniek is bedacht door Geoffrey Huntley, een Australische ontwikkelaar die bekendstaat om zijn experimentele aanpak van softwareontwikkeling. Hij publiceerde zijn methode officieel in juli 2025 in een blogpost, maar demonstreerde de techniek al eerder op meetups en livestreams. Huntley bouwde de techniek aanvankelijk als een eenvoudige bash-loop en gebruikte ze om zijn eigen programmeertaal, genaamd Cursed Lang, te bouwen. Dat project werd drie keer herschreven, eerst in C, dan in Rust en uiteindelijk in Zig, volledig aangestuurd door de techniek die hij zelf had bedacht.

De naam komt van Ralph Wiggum, een bijfiguur uit de animatieserie The Simpsons. Ralph is het zoontje van politiechef Clancy Wiggum en staat bekend als het domste, meest naïeve personage van de serie. Hij zegt dingen die nergens op slaan, geeft nooit op en lijkt volledig onbewust van zijn eigen beperkingen. Dat is precies de filosofie achter de techniek. Naïeve, hardnekkige volharding. De AI-agent stopt niet bij de eerste tegenslag, vraagt niet om bevestiging en geeft niet op. Hij blijft gewoon doorgaan, net als Ralph.

Die naamkeuze is niet toevallig. Huntley heeft veel aandacht besteed aan de branding en het verhaal achter de techniek. Zelfs mensen die de technische details missen, onthouden de naam en de filosofie erachter.

Wat is de Ralph Wiggum techniek precies?

In zijn meest basale vorm is de Ralph Wiggum techniek een while-loop in bash die een AI-codeeragent zoals Claude Code herhaaldelijk dezelfde prompt geeft totdat een bepaalde voltooiingsbelofte wordt uitgesproken. De agent werkt een taak af, rapporteert zijn voortgang, en de loop start opnieuw met een frisse context. Zo werkt elke iteratie in een schoon contextvenster, zonder de ballast van eerdere conversaties.

Een vereenvoudigd voorbeeld van de originele bash-implementatie ziet er zo uit:

while true; do
  claude --dangerously-skip-permissions "$(cat prompt.md)"
done

De agent leest de prompt, voert zijn taak uit, en de loop begint opnieuw. Pas wanneer de agent een specifieke voltooiingszin uitvoert, zoals “COMPLETE” of een vooraf gedefinieerde belofte, stopt de loop.

Wat de techniek onderscheidt van simpelweg een agent lang laten lopen, is het principe van één doel per contextvenster. Huntley vergelijkt contextvensters met arrays in C of C++. Hoe minder je in die array stopt, hoe minder het venster hoeft te schuiven en hoe beter de resultaten. Als je een agent vraagt om tien dingen tegelijk te doen, raakt hij verward en produceert hij slechtere code. Als je hem vraagt om één ding te doen, het te committen en dan opnieuw te starten, blijft hij scherp.

Hoe werkt het technisch?

De kern van de techniek draait om drie elementen: een goede specificatie, een implementatieplan en een heldere voltooiingsbelofte.

De specificatie en het implementatieplan

Voordat je de loop start, zorg je voor een gedetailleerde beschrijving van wat er gebouwd moet worden. Dit is geen optionele stap. Huntley benadrukt dat een slechte specificatie catastrofale gevolgen heeft. Eén fout in een specificatie staat gelijk aan duizenden regels verkeerde code, omdat de agent die fout in elke iteratie opnieuw maakt.

Het implementatieplan is een bestand, vaak plan.md of een JSON-bestand, met een lijst van taken. Elke taak heeft een status: geslaagd of niet geslaagd. De agent kiest bij elke iteratie de hoogstprioritaire taak die nog niet geslaagd is, werkt die af, markeert hem als geslaagd en maakt een git-commit. Zo bouw je een traceerbare geschiedenis op van wat er gedaan is.

Het contextvenster als array

Een van de meest waardevolle inzichten van Huntley is dat je het contextvenster moet behandelen als een array met beperkte ruimte. Elke token die je erin stopt, is ruimte die je niet meer hebt voor het eigenlijke werk. Daarom raadt hij aan om aan het begin van elke loop een compacte index van de specificaties te injecteren, zodat de agent weet wat er bestaat zonder alles te hoeven inladen.

Dit noemt hij “deliberate malicking”: bewust en doelgericht alloceren van context. Hoe minder ruis in het venster, hoe beter de agent presteert. Er is zelfs een “domme zone” in het contextvenster: als je te veel tokens gebruikt, degradeert de kwaliteit van de output merkbaar. Je wilt altijd in de “slimme zone” blijven.

De voltooiingsbelofte

De loop stopt pas wanneer de agent een specifieke zin uitvoert. Die zin is de voltooiingsbelofte. Een voorbeeld van zo’n belofte:

“Ik beloof dat de taak volledig is afgerond. Alle vereisten zijn geïmplementeerd en geverifieerd. Relevante tests zijn uitgevoerd en slagen. De implementatie is schoon en productieklaar.”

Moderne modellen zoals Claude Opus of GPT-5 zijn zeer betrouwbaar in het niet liegen over deze belofte. Ze zullen de loop niet vroegtijdig verlaten door de belofte nep uit te voeren als de taak nog niet klaar is. Dat maakt de techniek robuust.

Wat zijn de resultaten in de praktijk?

De techniek heeft indrukwekkende resultaten opgeleverd. Tijdens een Y Combinator hackathon gebruikte een team de methode om zes repositories in één nacht te bouwen, waaronder een volledige refactoring van een Python-project naar TypeScript. Een andere ontwikkelaar leverde een contract ter waarde van 50.000 dollar af voor slechts 297 dollar aan API-kosten. En Huntley zelf bouwde een volledige programmeertaal in drie maanden, volledig aangestuurd door zijn eigen techniek.

Huntley berekende dat de economische kostprijs van softwareontwikkeling met deze aanpak is gedaald tot minder dan 11 dollar per uur aan API-kosten, terwijl de output meerdere dagen of zelfs weken aan werk kan vertegenwoordigen in een periode van 24 uur.

Hoe haal je er het meeste uit?

Begin met de screwdriver, niet de jackhammer

Huntley waarschuwt expliciet: spring niet meteen naar de krachtigste versie van de techniek. Leer eerst hoe je de agent handmatig aanstuurt, begrijp hoe contextvensters werken en experimenteer met kleine taken. Pas als je die basis beheerst, heeft het zin om de loop volledig autonoom te laten draaien.

Schrijf goede specificaties

Dit is de meest kritische factor. Neem de tijd om je specificaties te genereren via een gesprek met de AI, review ze zorgvuldig en pas ze aan waar nodig. Huntley genereert zijn specificaties niet handmatig, hij laat de AI ze opstellen op basis van een gesprek en corrigeert daarna. Slechte specificaties leiden gegarandeerd tot slechte output, ongeacht hoe goed de loop is opgezet.

Houd taken klein en afgebakend

Elke iteratie van de loop moet één duidelijke, afgebakende taak uitvoeren. Grote taken leiden tot een vol contextvenster, wat de kwaliteit van de output verlaagt. Kleine taken betekenen ook dat de agent na elke iteratie een git-commit maakt, wat je een traceerbare geschiedenis geeft en het makkelijker maakt om fouten terug te draaien.

Bouw feedbackloops in

De techniek werkt het best wanneer de agent zijn eigen werk kan verifiëren. Dat betekent: laat tests draaien na elke wijziging, gebruik browser-automatisering om visuele output te controleren en zorg dat de agent toegang heeft tot de testresultaten. Als de tests falen, weet de agent dat hij verder moet werken. Als ze slagen, kan hij de taak als voltooid markeren.

Gebruik een sandbox

Wanneer je de loop volledig autonoom laat draaien, geef je de agent veel permissies. Dat is noodzakelijk, maar ook risicovol als je het op je lokale machine doet. Gebruik een geïsoleerde omgeving, zoals een cloud-VM of een sandbox-configuratie, zodat de blast radius beperkt blijft als er iets misgaat.

Stel een maximumaantal iteraties in

Zonder limiet kan de loop eindeloos doorgaan en je API-budget opslokken. Stel altijd een maximum in, bijvoorbeeld 10 tot 20 iteraties, zeker in het begin. Als de taak niet klaar is na die iteraties, kun je de loop opnieuw starten met bijgestelde specificaties.

Wees aanwezig als toeschouwer

De meest ervaren gebruikers van de techniek laten de loop niet blind draaien. Ze kijken toe zoals je naar een open haard kijkt: niet ingrijpend, maar oplettend. Je merkt patronen op, ziet waar de agent vastloopt en leert hoe je je prompts en specificaties kunt verbeteren. Huntley noemt dit “human on the loop” in plaats van “human in the loop”: je stuurt de loop aan, maar je bent er niet voortdurend actief bij betrokken.

De bash-loop versus de officiële plugin

Anthropic heeft een officiële Ralph Wiggum-plugin uitgebracht voor Claude Code. Die plugin werkt via een stop-hook in plaats van een externe bash-loop. Het verschil is fundamenteel: de bash-loop start elke iteratie met een volledig nieuw contextvenster, terwijl de plugin binnen hetzelfde contextvenster blijft werken. Dat betekent dat context zich opstapelt, compactie optreedt en de agent na verloop van tijd minder scherp wordt.

Huntley en andere ervaren gebruikers geven de voorkeur aan de originele bash-implementatie, juist omdat die het principe van één doel per schoon contextvenster respecteert. De plugin is een goede instap voor beginners, maar mist de essentie van wat de techniek zo krachtig maakt.

Meer dan een bash-loop

De Ralph Wiggum techniek is uiteindelijk meer dan een technische truc. Het is een andere manier van denken over softwareontwikkeling: niet als een lineair proces waarbij een mens elke stap goedkeurt, maar als een iteratief systeem waarbij de mens de loop ontwerpt en bewaakt. De ontwikkelaar wordt geen uitvoerder meer, maar een architect van het proces zelf. En dat vereist een andere set vaardigheden: goede specificaties schrijven, contextvensters begrijpen en feedbackloops inbouwen.