De Ralph Wiggum Lus, Vanuit Eerste Principes

Als je meer dan een paar uur een AI-coderingsagent hebt gebruikt, ken je de “muur”: de agent boekt zichtbare vooruitgang, stagneert dan — en je eindigt met het zelf aanpassen en afronden van het werk.

Zoals AI-ingenieurs vaak geneigd zijn te doen, dook er een patroon op om dat probleem op te lossen: laat de agent gewoon herhaaldelijk externe controles uitvoeren tot de taak daadwerkelijk slaagt.

De aanpak sloeg zo hard aan dat het een naam kreeg — Ralph Wiggum.

En de meme bleef hangen omdat het patroon werkt. Tegen eind 2025 had Anthropic het officieel geformaliseerd in een officiële Claude Code plugin.

Ralph vertegenwoordigt een verschuiving in hoe ontwikkelaars bestaande hulpmiddelen gebruiken. In plaats van AI-systemen te behandelen als interactieve assistenten, worden ze uitgevoerd als langlopende processen, geleid door tests, linters en expliciete stopvoorwaarden.

Dus deze korte gids is de praktische versie. We zullen zien wat Ralph daadwerkelijk is, waarom het werkt, hoe het zich verspreidde, en wat er veranderde toen het werd geproductiseerd.

Wat Is “Ralph” Eigenlijk?

In de kern is dit wat Ralph is: laat een agent in een lus draaien, controleer de uitvoer tegen iets wat niet kan liegen zoals een test, een linter, een typechecker; en blijf loopen tot het slaagt.

Dat is het.

Het oorspronkelijke voorbeeld dat Geoffrey Huntley in juli 2025 deelde was opzettelijk direct:

while :; do cat PROMPT.md | npx --yes @sourcegraph/amp ; done

Claude Codevarianten volgen dezelfde vorm, gewoon met meer veiligheidsmaatregelen. Maar het principe verandert niet: voer een vastgezette prompt in bij de agent herhaaldelijk totdat de externe realiteit zegt dat je klaar bent.

De lus zelf is bijna irrelevant, en wat telt is het contract:

• De toestand leeft in de repo: Bestanden, verschillen, logboeken, git geschiedenis; alles wat duurzaam is, komt hier.
• Voltooiing leeft buiten het model: Tests, linters, typecheckers; de agent beslist niet wanneer het klaar is; het harnas doet dat.
• De agent is vervangbaar: Het is een werker die herhaaldelijk wordt opgeroepen totdat de poort slaagt; als het vandaag traag of dom is, vervang het dan morgen door iets snellers.

Op deze manier gezien, wordt Ralph een ontwerpprincipe: stop met het vragen aan het model om te weten wanneer het klaar is. Verwacht niet dat het beperkingen onthoudt bij context resets.

Bouw in plaats daarvan het systeem zodanig op dat het model op die manieren niet kan falen.

Waarom Houdt de Lus Stand?

Een paar redenen:

1. Contextvensters Gedragen Zich Als Buffers

Huntley presenteert vaak contextvensters op laag niveau:

“Denk als een C of C++ ingenieur. Contextvensters zijn arrays.”

Ze hebben een vaste grootte; ze schuiven; ze overschrijven; ze vergeten.

Lange sessies gaan uit van continuïteit die niet bestaat, dus het behandelen van de buffer als duurzaam geheugen leidt tot afwijkingen, gemiste beperkingen en inconsistent gedrag.

Ralph leunt naar de realiteit van het systeem. In plaats van te doen alsof het contextvenster stabiel is, beschouwt hij het als wegwerpbaar.

De krasruimte van de agent wordt tussen iteraties gereset, terwijl de blijvende staat op schijf bewaard blijft. De repository hoopt waarheid op over meerdere uitvoeringen. Dit maakt het opnieuw starten van de agent routine in plaats van verspillend; elke lus begint opnieuw maar bouwt voort op wat daadwerkelijk is bewaard.

2. Externe Controles Overstijgen Intern Redeneren

Veel agentframeworks reageren op mislukkingen door structuur toe te voegen binnen het model: planners, samenvattingen, interne staat en reflectielussen.

Ralph bewaart de intelligentie buiten de agent. Het is afhankelijk van:

• Een vastgezette specificatie die niet verschuift
• Concreet bewijs van de laatste uitvoering
• Een deterministische poort die succes evalueert

De agent beslist niet wanneer het werk klaar is – het harnas doet dat.

Dit is waarom Ralph uitblinkt in mechanisch werk: refactoren, migraties, opruimen, conformiteitstaken… Overal waar succes gemeten kan worden door een script in plaats van beoordeling, wordt iteratie betrouwbaar.

Het model kan niet onder de vereisten uitkomen omdat de vereisten buiten zijn redenering liggen.

3. Verdichting Erodeert Beperkingen

Een terugkerende kritiek van Huntley richt zich op samenvatting en compactheid.

Wanneer een systeem het model vraagt te beslissen wat belangrijk genoeg is om te bewaren, gaat informatie verloren — beperkingen versoepelen, randgevallen verdwijnen, en spelden vallen uit.

Ralph omzeilt dit door invoer letterlijk te houden:

• De specificaties blijven letterlijk in plaats van samengevat, 
• De foutuitvoer blijft rauw en ongefilterd; en 
• Geheugenbeheer gaat nooit over in het model.

Het harnas behoudt de getrouwheid; de agent werkt erin, beperkt door wat er daadwerkelijk is in plaats van wat het model denkt dat er zou moeten zijn.

Dus, Hoe Verspreidde Het Idee Zich?

De tijdlijn is behoorlijk samengeperst.

• 19 Juni 2025: Op een meetup in San Francisco met ongeveer 15 ingenieurs die agentic coding bespreken, demonstreert Huntley Ralph, Cursed (de programmeertaal die door Ralph wordt gebouwd), en livestreamt autonoom coderen ‘s nachts terwijl hij slaapt in Australië. De kamer heeft een ongemakkelijk gesprek over hoe gemakkelijk het is om 80%-90% van een SaaS te kopiëren en hoeveel soorten werk op het punt staan volledig te verdwijnen.
• Juli 2025: Huntley publiceert de originele blogpost met de basis bash-loopstructuur. Het stuk bevat een lichtgewicht voorbeeldprompt en een verzoek: “je zou waarschijnlijk de cursed lang repo op github kunnen vinden als je ernaar zocht, maar deel het alsjeblieft nog niet.”
• Augustus 2025: De YC agents hackathon vindt plaats — teams draaien Claude Code in continue loops. Het resultaat is 6 repositories die ‘s nachts worden uitgebracht. Dexter Horthy voert een experimentele Ralph-loop uit op een React codebase refactor. In meer dan 6 uur ontwikkelt het een volledig refactorplan en voert het uit.
• September 2025: Huntley lanceert officieel Cursed Lang, de programmeertaal die Ralph heeft gebouwd. Het bestaat in drie implementaties (C, Rust, Zig), heeft een standaardbibliotheek en een stage-2 compiler geschreven in Cursed zelf.
• Oktober 2025: Dexter presenteert Ralph op Claude Code Anonymous in San Francisco. De vraag uit het publiek: “Dus raad je dit aan?” Zijn antwoord: “Domme dingen kunnen verrassend goed werken. Wat kunnen we verwachten van een slimme versie?”
• December 2025: Anthropic brengt een officiële Ralph Wiggum plugin uit. De plugin neemt Huntley’s bash-loop en formaliseert deze met Stop Hooks en gestructureerde foutgegevens.
• Januari 2026: Huntley en Horthy houden een diepgaande YouTube-discussie waarin ze de originele bash-loop Ralph-implementatie vergelijken met de Anthropic stop-hook-implementatie.

Bash-loop Ralph Vs. Plugin Ralph

De originele Ralph is een 5-regelige bash-lus. Je cat een promptbestand, stuurt het door naar Claude, controleert of de output slaagt voor je test, en lussen totdat het dat doet. Alles staat op schijf, alles is zichtbaar. Als er iets breekt, kun je precies zien waarom.

De Anthropic-plugin keert dat model om, dus in plaats van de lus van buitenaf uit te voeren, installeert het een Stop Hook in je Claude-sessie. Wanneer Claude probeert te stoppen, onderschept de haak dit, controleert je voltooiingsvoorwaarden en voert dezelfde prompt opnieuw in als er werk overblijft. De bestanden die Claude heeft gewijzigd, zijn er nog steeds.

De git-geschiedenis is er nog steeds, maar de harnasmechanica is nu ondoorzichtig — verborgen in een markdown-statusbestand, gevoelig voor rechten, gemakkelijk te beschadigen als je niet weet wat je doet.

Dit is de klassieke abstractie-afweging.

De plugin verlaagt de adoptiekosten. Je hoeft geen bash te schrijven en je hoeft niet na te denken over loops. Maar naarmate het mechanisme verborgen wordt, wordt het oorspronkelijke inzicht makkelijker te missen.

De bash-loopversie dwingt je om het harnas te ontwerpen. De pluginversie laat je die stap overslaan, wat prima is totdat je een randgeval tegenkomt en niet kunt zien wat er daadwerkelijk gebeurt.

Dexter Horthy heeft het getest en ontdekte dat het op cryptische wijzen faalt, tenzij je “–dangerously-skip-permissions” gebruikt. De plugin installeert hooks op vreemde plaatsen, gebruikt ondoorzichtige staatbestanden, en als je het markdown-bestand verwijdert voordat je het stopt, breek je Claude in die repo totdat je de plugin volledig uitschakelt.

Dus, wat is de les? Beide werken, maar om verschillende redenen. De bash-lus werkt omdat het simpel en transparant is. De plugin werkt wanneer de abstractie niet iets cruciaals verbergt.

Wat Leer Je Van Het Uitvoeren?

Ralph gaat uit van afstand tussen de mens en de agent. Je zit niet in de sessie en leidt deze niet. In plaats daarvan zet je het in werking, loop je weg, inspecteer je de artefacten als het klaar is, en pas je de beperkingen aan voor de volgende iteratie.

Interactie vindt plaats op het niveau van de harnas — de prompt, de tests, de stopvoorwaarden — niet binnen het gesprek.

Na verloop van tijd wordt een patroon zichtbaar: de meeste storingen zijn geen modelstoringen; het zijn storingen in de uitrusting.

De specificatie was vaag, de test was te algemeen, of de voltooiingsvoorwaarde beschreef niet daadwerkelijk wat “klaar” betekent.

Zodra je dit een paar keer ziet, verandert je instinct. Je stopt met vragen “hoe maak ik Claude slimmer?” en begint met vragen “hoe maak ik de beperkingen strakker?”

Hier worden specificaties cruciaal.

Specificaties Als Besturingsoppervlakken

Huntley herkadert specificaties niet als documentatie maar als vaste controle-invoer. Je produceert ze door gesprekken met Claude, bewerkt ze doelbewust totdat ze precies zijn en dan zet je ze vast. Eenmaal vastgezet, veranderen ze niet meer gedurende de hele lus.

Dit is belangrijk omdat specificaties tegelijkertijd drie dingen doen:

1. Ze binden wat de agent kan verzinnen: Zonder een strakke specificatie voegt Claude defensieve lagen, abstracties of functies toe die je nooit hebt gevraagd, waardoor de reikwijdte bij elke iteratie uitbreidt. 
2. Ze verankeren zoeken en ophalen: Zodat de agent geen nieuwe vereisten hallucineert.
3. Ze stabiliseren gedrag over runs: Elke iteratie lost hetzelfde probleem op, niet een iets andere interpretatie ervan.

Als je specificatie vaag is over wat “klaar” betekent, zal de agent het elke keer anders interpreteren. Je eindigt met afwijkingen, reikwijdte-uitbreiding en iteraties die elkaar tegenspreken.

Hoe Voer Je De Loop Verantwoord Uit?

Een minimale Ralph-configuratie ziet er vaak als volgt uit:

MAX_ITERS=30
for i in $(seq 1 $MAX_ITERS); do
  cat PROMPT.md | claude
  if ./ci.sh; then exit 0; fi
done
exit 1

De mechanica van de lus is veel minder belangrijk dan de regels eromheen:

• Houd de specificatie onveranderlijk; pas deze niet aan tijdens de lus op basis van wat Claude doet. 
• Codeer voltooiing als uitvoerbare controles.
• Handhaaf iteratielimieten en tijdslimieten zodat de lus niet eeuwig kan draaien en door je tokenbudget heen brandt. 
• Bewaar logboeken en verschillen zodat je kunt inspecteren wat er misging als dat gebeurt. 

Verder heeft de operationele praktijk een aantal heuristieken onthuld die van belang zijn:

• Geef de voorkeur aan kleine, regelmatige verschillen boven grote herbewerkingen, omdat grote veranderingen fouten vergroten en moeilijker te debuggen zijn. 
• Voer opnieuw uit op de huidige hoofdversie in plaats van opnieuw te baseren, omdat samenvoegconflicten iteraties verspillen.
• En vermijd het gebruik van Ralph voor verkennend werk, omdat als je geen duidelijke acceptatietests hebt, je alleen maar een chaotische lus krijgt die dingen verzint die je niet hebt gevraagd.

De beperking is de functie.

De Loop Is de Les

Toen Ralph grip kreeg, ontstonden er variaties. Sommige teams bouwden gestructureerde externe lussen rondom gereedschap-oproepende agenten. Anderen voegden afzonderlijke verifieercomponenten toe: een ander model dat de output van de werker controleert voordat de lus besluit te eindigen. Deze uitbreidingen werken, ja, maar alleen als ze het oorspronkelijke inzicht respecteren.

De regel is eenvoudig: verificatie moet deterministisch blijven, en samenvattingen mogen nooit de primaire invoer vervangen.

• Als je een verificateur toevoegt, moet deze concrete zaken controleren: testen slagen, linter sluit netjes af, git diff komt overeen met de verwachtingen. 
• Als je gestructureerde buitenlussen toevoegt, moeten ze nog steeds de ruwe uitvoer en ruwe logboeken zien, niet een opgeschoonde samenvatting van wat er misging. 

Huntley’s kernargument is dat softwareontwikkeling als beroep effectief dood is, maar software-engineering — de praktijk van het goed bouwen van systemen — leeft meer dan ooit.