Claude Code ’s nachts: loop engineering en Ralph Loop in 2026

Loop engineering is een aanpak waarbij je Claude Code niet telkens handmatig een prompt geeft, maar een lus bouwt. De lus ontvangt je taak, zet een stap, controleert het resultaat en beslist zelf of hij doorgaat of stopt. Deze gids laat zien hoe je in één avond je eerste Ralph Loop instelt, zodat die elke dag voor je werkt.

Ailoot-referentiedocumentatie: ailoot.ai/docs/.

Wat is loop engineering en waarom zou het je iets moeten kunnen schelen?#

Acht maanden zonder code met de hand te schrijven. Heel Claude Code, waar je nu mee werkt, is door Claude Code zelf geschreven — in lussen die het team heeft gebouwd.

En de tweede uitspraak maakt de schaal duidelijk:

Achter deze uitspraken schuilt een nieuwe ingenieursrol: je bent de architect van lussen, geen toetsenbordbediener.

Doe het vandaag één keer en elke dag groeit het aantal leads, worden artikelen automatisch gepubliceerd, handelt de bot correspondentie af en ligt het metriekrapport om 9 uur ’s ochtends op je bureau. Je bouwt het, en het werkt elke dag zonder jou.

Als je Claude Code nog steeds opent, een prompt schrijft, wacht, leest en nog een prompt schrijft, mis je de grootste verschuiving van 2026. Modellen zijn krachtig genoeg geworden om zonder toezicht in lussen te werken.

Hoe Ralph Loop verschilt van een gewone Claude Code-aanvraag#

At its core, de techniek bestaat uit een eenvoudige bash-lus rond een agent:

De oorspronkelijke code waarmee de hele golf begon:

while :; do cat PROMPT.md | claude-code ; done

Eén prompt in een bestand, met een oneindige lus eromheen. En de meest openhartige opmerking van de auteur:

Anthropic heeft dezelfde logica verpakt in de ralph-loop-plugin en in de opdrachten /loop, /goal en /batch in Claude Code — die zijn direct in de terminal beschikbaar, zonder scripts. Alleen al het feit dat Anthropic een plugin voor oneindig opnieuw prompten uitbracht, leidde tot een discussie in GitHub Issue #23084 over de vraag of dat eerlijk is tegenover het model. De discussie is nog open; de plugin werkt.

Drie ingebouwde Claude Code-opdrachten: /loop, /goal, /batch#

/goal lijkt het meest op Ralph Loop. Onder de motorkap controleert een evaluator-model (standaard Haiku) bij elke beurt of het doel is bereikt. Zo niet, dan bevat de volgende iteratie een aanwijzing over wat er precies moet worden aangepast. Zo ja, dan stopt het. Ik heb /goal uitgebreid besproken in de gids over Claude Code ’s nachts autonoom laten werken met /goal — daarin staan kant-en-klare scenario’s voor 14 uur werk.

/batch is een zeldzame maar krachtige opdracht. Als je dezelfde wijziging in meer dan 100 bestanden moet doorvoeren (API-migratie, component vervangen, hernoemen), stuurt /batch elk bestand naar een afzonderlijke subagent in zijn eigen git-worktree. De wijzigingen botsen niet — elke agent werkt in een geïsoleerde kopie. Lees voor meer informatie over subagents de gids over geneste subagents.

In de beschrijving van deze aanpak door de auteur wordt het eenvoudigweg zo genoemd:

Strikte limieten voor /loop en /goal:

• Een taak draait zolang Claude Code geopend is. Sluit de terminal en de lus stopt. Gebruik voor een serieuze nachtelijke cyclus een externe server of je eigen shell-wrapper.
• Een terugkerende taak kan maximaal 7 dagen actief blijven (daarna wordt die automatisch verwijderd om vergeten lussen te voorkomen).
• Maximaal 50 gelijktijdige taken in één sessie.

Wil je een configuratie bouwen waarmee Claude betrouwbaar werkt? Ralph Loop is daar maar één onderdeel van. Het is nuttig om alle drie de onderdelen te bekijken: AI-kloon + Second Brain + Context Engineering — deze combinatie verandert Claude van een “assistent die hallucineert” in een tool waaraan je een taak kunt geven, waarna je verder kunt met je eigen werk.

Zo start je je eerste autonome lus in 5 minuten#

5 stappen:

1. Open het project in Claude Code

   Ga in de terminal naar de hoofdmap van het project en voer claude uit. Wacht tot Claude CLAUDE.md heeft gelezen en de repository heeft geïndexeerd.

2. Bepaal een doel en een stopvoorwaarde

   Het doel beschrijft wat er moet gebeuren. De stopvoorwaarde beschrijft hoe Claude weet dat het klaar is. Idealiter is dat een opdracht die 0 of 1 retourneert. Voorbeeld: “Doel: alle 23 tests in tests/api/*.test.ts moeten slagen. Stop wanneer pnpm test exitcode 0 retourneert.”

3. Voer /goal uit

   Opdracht:

   /goal Alle tests in tests/api/*.test.ts moeten slagen. Voer pnpm test uit, lees de fouten, los ze op en voer de tests opnieuw uit. Stop wanneer de exitcode = 0. Maximaal 20 iteraties.
   

   Claude start de lus: voert tests uit — ziet een mislukking — opent het bestand — lost het probleem op — voert ze opnieuw uit.

4. Stel een budgetlimiet in

   Gebruik /usage in een achtergrondtabblad om het verbruik bij te houden. Stel een dagelijkse token- of geldlimiet in, zodat je niet je volledige saldo aan één lus besteedt. Meer informatie vind je in de gids over voorkomen dat je de Claude Code-limieten opgebruikt.

5. Ga verder met je werk

   Kom na 30 minuten terug. Bij een eenvoudige taak staat er dan al “DONE, all tests pass”. Is de taak ingewikkelder, lees dan het rapport: “gestopt bij iteratie 20, reden X”. Los handmatig op wat de lus niet kon en start die daarna opnieuw.

Verificatiepatroon: hoe Claude zijn eigen werk in een lus controleert#

Er zijn drie soorten verifiers:

1. Technisch (exitcode) — het betrouwbaarst. pnpm test, npm run lint, tsc --noEmit, playwright test. Ze retourneren 0 of 1; interpretatie is niet nodig. /goal werkt ook zo — onder de motorkap gebruikt het het evaluator-model Haiku, dat bij elke beurt controleert of aan de voorwaarde is voldaan (maximaal 4000 tekens).

2. Evaluator-model — een tweede model bekijkt het resultaat van het eerste model en beoordeelt het aan de hand van een rubric. Geschikt voor taken zonder formele controle (“Is de schrijfstijl goed?” “Past het ontwerp bij het merk?”). Bij Anthropic heet dit Claude Code Review — een modus waarin een afzonderlijke reviewer-agent het werk van de hoofdagent controleert op logische fouten, randgevallen en beveiligingsproblemen. Volgens interne gegevens van Anthropic vindt het 84% van de problemen in grote PR’s (tegenover 16% met de basismethode).

3. Aangepaste controle — een shellscript dat je zelf schrijft. “Als de logs het woord ERROR niet bevatten, is het klaar.” “Als het bestand output.json bestaat en parseerbaar is, is het klaar.” “Als de pagina /pricing 200 retourneert, is het klaar.”

In de aanpak van de auteur bevatten de skills na elke fase een afzonderlijke adversariële controle voor Claude. Hier is een promptsjabloon dat ik in CLAUDE.md of in een opdracht zet:

Bedenk 10 redenen waarom dit project helemaal mis kan zijn gegaan. 
Stel je voor dat er iets fout is gegaan. 
Ik kan dit verhaal vaak opnieuw doorlopen - 
voordat ik het openbaar maak.

De meest voorkomende beginnersfout is een lus starten zonder verifier. De agent draait in kringetjes: schrijft code, controleert die niet, denkt dat het klaar is, gaat naar de volgende iteratie en herschrijft wat hij al had gedaan. Drie uur later is het een puinhoop en bedraagt de rekening $200.

De beste regel die ik heb geleerd: schrijf eerst de verifier en start daarna de lus. Als je de stopvoorwaarde niet in één regel kunt formuleren, is de taak niet klaar voor autonomie.

Hoe je voorkomt dat een loop duizenden dollars in één nacht kost: budgetlimieten en stopvoorwaarden#

Drie essentiële remmen voor elke nachtelijke lus:

1. Iteratielimiet. --max-iterations 20. De lus kan niet meer dan N keer draaien — zelfs als de verifier niet wordt geactiveerd. Als de stopvoorwaarde na 20 iteraties niet is bereikt, zit de taak vast en is menselijke tussenkomst nodig.

2. Token- of geldlimiet. /usage limit 50 — niet meer dan $50 per dag. Wanneer de limiet in zicht komt, stopt de lus vanzelf en stuurt die een melding. Dit beschermt tegen een scenario waarin de loop het budget in één nacht opgebruikt.

3. Voortgangscontrole met een expliciete afspraak. De onderstaande vergelijking van HEAD detecteert nieuwe commits, niet alle codewijzigingen. Gebruik haar alleen in een geïsoleerde worktree waar elke iteratie die code wijzigt vóór de vergelijking een lokale checkpointcommit maakt. Nuttige niet-gecommitte wijzigingen veranderen HEAD niet; zonder die afspraak kan een ongewijzigde hash een onterecht stagnatiesignaal zijn. Bewaar ook het resultaat van de verifier: een nieuwe commit bewijst een vastgelegde wijziging, niet dat de taak is verbeterd of geslaagd.

Een illustratieve wrapperstructuur met deze drie controles. De regels voor kostenrapportage en agentaanroep zijn runnerspecifieke voorbeelden, geen geverifieerd CLI-installatierecept; controleer die interfaces voor de geïnstalleerde versie voordat je ze aanpast. Vereis voor de voortgangscontrole via commits een lokale checkpointcommit voor elke iteratie die code wijzigt. Laat de runner bewerkingen ongecommit achter, stop dan voor beoordeling in plaats van ze “geen voortgang” te noemen.

#!/bin/bash
PROMPT="$1"
MAX_ITER=20
MAX_COST_USD=50
COMPLETION="DONE"
PREV_HASH=""
STAGNATION=0

for i in $(seq 1 $MAX_ITER); do
  # Geldlimiet
  CURRENT_COST=$(claude usage --json | jq '.cost_usd')
  if (( $(echo "$CURRENT_COST > $MAX_COST_USD" | bc -l) )); then
    echo "STOP: budget cap $MAX_COST_USD reached"
    break
  fi

  # Uitvoeren
  OUTPUT=$(claude code -p "$PROMPT" --auto-accept)

  # Voltooiing controleren
  if echo "$OUTPUT" | grep -q "$COMPLETION"; then
    echo "STOP: completion signal"
    break
  fi

  # Alleen commitvoortgang: elke codewijzigende iteratie moet een checkpointcommit maken.
  # HEAD detecteert geen nuttige bewerkingen die ongecommit blijven.
  CURRENT_HASH=$(git rev-parse HEAD 2>/dev/null)
  if [ "$CURRENT_HASH" = "$PREV_HASH" ]; then
    STAGNATION=$((STAGNATION + 1))
    if [ "$STAGNATION" -ge 3 ]; then
      echo "STOP: stagnation 3 iterations"
      break
    fi
  else
    STAGNATION=0
  fi
  PREV_HASH="$CURRENT_HASH"
done

Valideer de voortgangscontrole voordat je dit skelet uitbreidt: behandel een bewerking zonder commit als niet-vastgelegd werk; een checkpointcommit verandert HEAD; alleen de afzonderlijke verifier kan succes vaststellen. Drie ongewijzigde commits betekenen volgens deze afspraak dat geen wijzigingen zijn vastgelegd, niet dat alle werkbestanden ongewijzigd zijn gebleven. Daarna kun je toevoegen: een Slack-melding wanneer de lus stopt, een automatisch Telegram-rapport in de ochtend, een pushmelding wanneer het budget 80% bereikt. Het principe is hetzelfde: een lus heeft remmen nodig, niet alleen een gaspedaal.

5 kant-en-klare scenario’s voor nachtelijke lussen#

Scenario 1: falende tests laten slagen

/goal Er zijn 47 falende tests in de map tests/. Doel: zorg dat ze allemaal slagen.
Voer pnpm test uit, lees stderr, open het bestand met de fout, los die op en voer pnpm test opnieuw uit.
Stop wanneer de exitcode 0 is. Maximaal 30 iteraties.

Scenario 2: grote refactoring in 200 bestanden

/batch Vervang de oude apiV1 API-client door de nieuwe apiV2 in alle bestanden onder src/**/*.ts.
Elk bestand krijgt een eigen worktree. Voer na de vervanging tsc --noEmit uit; los eventuele fouten op.
Voeg de worktrees aan het einde samen.

Scenario 3: de productieomgeving ’s nachts monitoren

/loop 30m Controleer elke 30 minuten https://your-app.example.com/api/health.
Als die geen 200 retourneert, lees dan de logs, zoek de oorzaak, los die op en implementeer opnieuw.
Log elke iteratie naar /tmp/night-monitor.log.

Scenario 4: een grote dataset importeren en ontdubbelen

/goal Importeer het CSV-bestand /tmp/import.csv (12,000 rijen) in de tabel clients.
Controleer voor elke rij op duplicaten op basis van e-mail; voeg de rij in als er geen duplicaat is, en werk de bestaande rij bij als die er wel is.
Log conflicten naar /tmp/conflicts.log. Stop wanneer de laatste rij is verwerkt.

Scenario 5: artikelproces (typische configuratie)

Voor een online dienst of bureau dat regelmatig SEO-artikelen nodig heeft, ziet het scenario er zo uit:

/loop 8h Elke 8 uur: open het backlogbestand voor onderwerpen met de status 'queued'.
Voer de skill voor het schrijven van een gids uit als er een onderwerp beschikbaar is.
Publiceer naar dev. Wijzig de status in 'review'. Breng de verantwoordelijke op de hoogte via Telegram.

Wat je in elke iteratie moet aanleveren: CLAUDE.md en Second Brain als status#

Drie lagen projectgeheugen veranderen een eenmalige prompt in een gecontroleerde lus:

1. CLAUDE.md — de grondwet van het project. Wat het product is, welke stack wordt gebruikt, wat de regels zijn en wat nooit mag gebeuren. Claude leest dit bestand bij de start van elke sessie en elke iteratie van de lus. Zonder dit bestand moet Claude het project elke keer opnieuw “openen” — dat kost context en vergroot het risico op hallucinaties. In de gids CLAUDE.md vind je een kant-en-klaar sjabloon en 6 regels.

2. Second Brain — een map met bedrijfskennis: product, doelgroep, doelen, economie en marketing. Geen code, maar betekenis. Wanneer de lus een artikel schrijft of een antwoord zoekt voor support, leest hij de Second Brain en reageert hij vanuit de projectcontext, niet vanuit het niets.

3. Context engineering — wat je Claude precies in elke iteratie geeft. Niet de hele Second Brain-map en niet de volledige repository — alleen wat relevant is. Plan Mode helpt daarbij: Claude bepaalt welke bestanden de taak nodig heeft en leest alleen die. Meer informatie vind je in de gids Plan Mode.

Het belangrijkste operationele principe dat ik er door fouten in moest hameren:

Deze drie lagen vormen de drie pijlers van de methodologie: AI-kloon (je hebt Claude je stijl en regels geleerd via skills en CLAUDE.md), Second Brain (zakelijke betekenis in bestanden) en Context Engineering (wat je in elk verzoek aanlevert). Zonder alle drie wordt de lus een eindeloze cyclus met een steeds hogere rekening.

Parallel werken met terminals, sessies en agents#