Hur gör man en Ralph Loop?

Tänk dig att du skriver en uppgiftslista, startar ett skript, går och lagar middag — och när du kommer tillbaka en timme senare är halva projektet implementerat, testat och committat. Inte för att du anställt någon, utan för att du satt en AI-agent i en loop och lät den jobba. Det är kärnan i det som kallas en Ralph Loop: en autonom AI-kodningsloop där Claude Code betar av uppgift efter uppgift, iteration efter iteration, tills jobbet är klart eller pengarna tar slut.

Tekniken introducerades av G. Huntley under hösten 2025. Den fick spridning snabbt — inte minst när Huntley demonstrerade att han hade byggt ett komplett kompilator-toolchain med den, till en bråkdel av vad ett konsultkontrakt hade kostat. I den här artikeln går jag igenom hur en Ralph Loop fungerar, vad som krävs för att den ska fungera bra, och vilka fallgropar man ska undvika.

Vem är Ralph Wiggum?

Geoffrey Huntley, australiensisk utvecklare och serieentreprenör, myntade termen Ralph Loop under hösten 2025. Han döpte tekniken efter Ralph Wiggum — den godhjärtade men kognitivt något begränsade karaktären från animationsserien The Simpsons. Ralphs signaturkvalitet är hans orubbliga envishet: han försöker, misslyckas, försöker igen, misslyckas på ett lite annorlunda sätt, och fortsätter tills saker till sist fungerar — eller tills någon annan ingriper.

Det är precis denna egenskap som Huntley ville fånga i en autonom AI-kodningsloop.

Jag gjorde inte först kopplingen till Simpsons, utan trodde att Wiggum var namnet på upphovspersonen (men det var ju Huntley). Jag tillhör en helt annan generation där uttryck som "götapetter" eller namn som Kalle Stropp eller Nisse Hult är direkt igenkännbara. Men när man väl förstår konceptet är Ralph en utmärkt metafor: enveten, välmenande, och kapabel att lösa problem genom ren iterativ uthållighet.

Termen spred sig snabbt i AI-communities tidigt under detta år, inte minst tack vare att Huntley demonstrerade hur han hade byggt CURSED — en komplett kompilator (tool chain) för ett esoteriskt programspråk inklusive standardbibliotek — autonomt med tekniken, till en kostnad av $297 istället för det $50 000-kontrakt han annars hade behövt betala.

Vad är en Ralph Loop?

En Ralph Loop är i sin enklaste form en autonom AI-kodningsloop: du ger Claude Code en uppgiftsbeskrivning, startar loopen, och återkommer senare till färdig kod. Varje iteration väljer LLM:en själv vad som är viktigast att göra härnäst, implementerar det, och sparar framstegen inför nästa varv.

Huntleys originalkommando är förbluffande enkelt:

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

En icke-terminerande bash-loop som vid varje iteration skickar innehållet i PROMPT.md, via en pipe, till claude och låter modellen göra sitt. Varje ny processstart innebär att kontextfönstret töms och Claude börjar om med friska ögon.

Två flaggor är värda att känna till direkt:

• -p / --print (print-läge): kör Claude Code i icke-interaktivt läge och skriver output till stdout — nödvändigt för att loopen ska fungera utan att hänga sig och vänta på tangentbordsinput.
• --permission-mode acceptEdits: instruerar Claude Code att automatiskt acceptera filändringar utan att fråga om lov. Utan den stannar loopen upp och väntar på ett svar som aldrig kommer.

while :; do claude --print --permission-mode acceptEdits "$(cat PROMPT.md)"; done

while :; do ... done är ett idiom i bash för en icke-terminerande loop. Kolon (:) är ett inbyggt kommando som alltid returnerar true, vilket gör att loopen aldrig avslutas av sig självt. Man bryter den med Ctrl-C, eller — bättre — via de brytvillkor vi diskuterar i nästa avsnitt.

Brytvillkor och max antal iterationer

En okontrollerad Ralph Loop är som att lämna en kran öppen: förr eller senare rinner antingen pengarna eller kontextfönstret slut. Frontier-modeller som Claude har ett kontextfönster på ungefär 170 000 tokens — och API-kostnader löper på per token.

Det finns tre mekanismer för att hålla loopen under kontroll.

Explicit avslutssignal

Det elegantaste sättet är att instruera LLM:en att skriva ett speciellt avslutsvärde när allt är klart. Vanligt förekommande är:

<promise>COMPLETE</promise>

Shell-skriptet fångar detta i utskriften, sätter en variabel och bryter loopen om brytfrasen finns med:

output=$(claude -p --permission-mode acceptEdits "$(cat PROMPT.md)")
echo "$output"
if echo "$output" | grep -q "<promise>COMPLETE</promise>"; then
    echo "Ralph loop is done."
    break
fi

Max antal iterationer

Som failsafe sätter man alltid ett tak på antalet varv. Tumregeln från communityn är max 35 iterationer — tillräckligt för de flesta projekt, men ändå ett skydd mot runaway-loopar som äter upp din API-budget.

MAX=35
for i in $(seq 1 $MAX); do
    echo "--- Iteration $i of $MAX ---"
    # ...
done

Backpressure — kvalitetsgrindar

Huntley använder begreppet backpressure: automatiserade kontroller som stoppar loopen om kvaliteten inte håller. I praktiken innebär det att kompilering, enhetstester och statisk analys körs efter varje iteration. Misslyckas detta, avbryts körningen och operatören (d.v.s. du) får gripa in.

Den professionella Ralph Loop-uppsättningen

Det enkla while-kommandot räcker för experiment. För ett riktigt projekt behöver man en mer strukturerad uppsättning bestående av fyra komponenter.

CLAUDE.md

CLAUDE.md är Claude Codes inbyggda mekanism för projektspecifika instruktioner — en fil som Claude läser automatiskt vid varje start. Här definieras projektets spelregler: kodstil, namngivningskonventioner, vilka kommandon som kör tester, vilka filer som aldrig ska röras.

# Projekt: MinApp

## Kodstil

- TypeScript strict mode
- Prettier med 2-space indentation
- Kommentarer på svenska

## Kommandon

- Tester: `npm test`
- Bygg: `npm run build`
- Lint: `npm run lint`

milestone-steps.md

Det här är uppgiftslistan — en checklista med allt som ska implementeras. LLM:en läser den, väljer en oavbockad uppgift, implementerar den och bockar av. I regel är detta en lista skapad efter att ha gjort en planering av projektet eller en viss milestone. Innehållet kan vara så enkelt som en punktlista, men är oftare en lista med en kortare beskrivning av vad som ska göras, med tillhörande information om dependencies, berörda delsystem med mera. En alternativ representation är GitHub Issues. En fördel i detta fall är att LLM:en kan skriva in en kommentar om vad denna utfört och länka till en commit.

# Milstolpar

- [x] Initialisera projektet
- [ ] Skapa databasschemat
- [ ] Implementera autentisering
- [ ] Bygg REST API för användare
- [x] Skriv integrationstester för API
- [x] Sätt upp CI/CD-pipeline

Observera att LLM:en rangordnar de olösta uppgifterna i prioritetsordning och väljer uppgiften som den tycker är viktigast för stunden.

way-of-working.md

Det här är den viktigaste filen — LLM:ens arbetsprocess. Utan tydliga instruktioner om hur modellen ska resonera och arbeta riskerar man att få kod som kompilerar men saknar tester, eller ändringar som inte är committade.

# Arbetssätt

## Val av uppgift

1. Läs milestone-steps.md
2. Välj den FÖRSTA oavbockade uppgiften
3. Markera den som pågående med [~] innan du börjar

## Implementation

1. Skriv testerna FÖRST (TDD)
2. Skriv implementationen
3. Kör testerna: `npm test`
4. Om testerna misslyckas: fixa och kör igen (max 5 försök)
5. Kör lint: `npm run lint`

## Avslut per iteration

1. Committa alla ändringar med ett beskrivande commit-meddelande
2. Bocka av uppgiften i milestone-steps.md
3. Om alla uppgifter är avbockade: skriv <promise>COMPLETE</promise>

Shell-skriptet

Först strukturen som pseudokod:

läs projektfiler (CLAUDE.md, milestone-steps.md, way-of-working.md)
för varje iteration upp till MAX:
    kör claude med projektfilerna som kontext
    fånga output
    om output innehåller COMPLETE → avsluta framgångsrikt
    om tester misslyckas → avsluta och rapportera felet
    vänta kort (undvik rate limiting)
rapportera slutresultat

Och sedan som körbart bash-skript:

#!/usr/bin/env bash
set -euo pipefail

MAX_ITERATIONS=35
ITERATION=0
LOG_FILE="ralph-$(date +%Y%m%d-%H%M%S).log"

PROMPT=$(cat <<'EOF'
Read @way-of-working.md for instructions on how to work.
Read @milestone-steps.md to see which tasks remain.
Choose and implement exactly ONE task. Commit when done.
If all tasks are checked off, write <promise>COMPLETE</promise>.
EOF
)

echo "Ralph Loop starting. Max $MAX_ITERATIONS iterations. Log: $LOG_FILE"

while [ $ITERATION -lt $MAX_ITERATIONS ]; do
    ITERATION=$((ITERATION + 1))
    echo "--- Iteration $ITERATION of $MAX_ITERATIONS ---" | tee -a "$LOG_FILE"

    OUTPUT=$(claude --print --permission-mode acceptEdits \
        "@CLAUDE.md @milestone-steps.md @way-of-working.md $PROMPT" \
        2>&1 | tee -a "$LOG_FILE")

    if echo "$OUTPUT" | grep -q "<promise>COMPLETE</promise>"; then
        echo "Ralph is done after $ITERATION iterations." | tee -a "$LOG_FILE"
        exit 0
    fi

    if ! npm test >> "$LOG_FILE" 2>&1; then
        echo "Tests failed after iteration $ITERATION. Ralph stopping." | tee -a "$LOG_FILE"
        exit 1
    fi

    sleep 2  # Avoid rate limiting
done

echo "Max iterations ($MAX_ITERATIONS) reached without COMPLETE signal." | tee -a "$LOG_FILE"
exit 2

Spara filen som afk-ralph.sh, kör chmod +x afk-ralph.sh, och starta med:

./afk-ralph.sh

AFK betyder Away From Keyboard, dvs du har gått på lunch eller något sådant.

/ralph-loop — det officiella pluginet

Anthropic har lanserat ett officiellt plugin för Ralph Loop, tillgängligt på claude.com/plugins/ralph-loop. Det erbjuder två kommandon:

/ralph-loop "din prompt" --max-iterations 35 --completion-promise "COMPLETE"
/cancel-ralph

Det smarta med pluginet är hur det löser sessionsproblemet: i stället för att köra allt inom samma konversation använder det en stop hook — en mekanism som fångar upp när Claude Code avslutar en session och automatiskt startar om den med samma prompt. Filändringar och git-historik bevaras mellan iterationerna, men kontextfönstret töms. Varje varv börjar alltså med friska ögon.

Varför ett naivt slash command inte räcker

Det är värt att förstå problemet som pluginet löser, eftersom det illustrerar en viktig egenskap hos Claude Code. Om man definierar ett eget /ralph-kommando utan sessionsomstart — eller bara kör loopen som ett långt samtal — uppstår tre konkreta problem:

Token-fönstret töms. Med ≈170 000 tokens att röra sig med, och kod, filer och resonemang som staplas på varandra, nås gränsen snabbare än man tror. En lång loop slutar abrupt — mitt i en implementation.

Resonemangen stelnar. Tidiga beslut i konversationen påverkar alla senare. En LLM som sett 40 000 tokens av en viss arkitekturlösning är kognitivt låst i den — den börjar försvara och förstärka sina egna tidigare val snarare än att ifrågasätta dem.

Felen multipliceras. I ett shell-skript startar varje iteration som en ny process — gör Claude Code ett misstag, rensas det bort ur kontexten vid nästa start. I ett naivt slash command ackumuleras misstagen och formar kommande svar.

Det officiella pluginet hanterar allt detta korrekt. Shell-skriptet i föregående avsnitt gör detsamma, fast på ett mer transparent och konfigurerbart sätt — och utan att behöva installera något.

Erfarenheter från praktiken

Communityn har hunnit samla en del lärdomar sedan Huntley introducerade tekniken.

Det mest citerade exemplet är hans eget: CURSED-kompilatorn. Under ett Y Combinator-hackathon skapade han och pushade kod till sex repositories på en natt. En som nämns ofta är ett team som lät Ralph köra i nästan tre timmar för att bygga en komplett thought-mapping-applikation — med kunskapspaneler, API-integration och nodlänkning — utan att någon rörde tangentbordet under tiden.

Utöver de spektakulära fallen har ett antal mönster kristalliserat sig:

Greenfield fungerar, befintliga kodbaser är svårare. Ralph är bäst på att bootstrappa nya projekt till ungefär 90% färdigställande. I en existerande kodbas med implicita konventioner och teknisk skuld tenderar loopen att introducera inkonsistenser som tar längre tid att rätta till än att ha skrivit koden manuellt.

Senioritetskravet är reellt. Huntley är tydlig på den punkten: Ralph kan ersätta juniorutvecklare på greenfield-arbete, men det kräver en erfaren ingenjör som skriver specifikationerna, tolkar felen och trimmar prompterna. "When Ralph generates wrong code, you update the signs, not the tool."

Planera mera. Man kan inte nog upprepa och understryka hur viktigt det är med planering. Spendera rejält med tid på att i plan mode diskutera med Claude om vad som ska utföras och hur detta ska gå till. Resultatet av planeringen blir uppgiftslistan. Som del av planeringen, definiera också hur varje uppgift ska formuleras (issue/step template). Samt, om den ska skrivas på fil eller tryckas upp till GitHub eller liknande (somliga använder verktyg som Linear, som har bra MCP-stöd).

Testerna är inte valfria. Utan backpressure i form av automatiserade tester tenderar loopen att producera kod som ser bra ut men är subtilt felaktig (eller helt uppåt väggarna 🤢). De som lyckats väl har strikta TDD-instruktioner i way-of-working.md och kör testerna efter varje iteration.

Logg-filen är din bäste vän. Att spara varje iterations output gör det möjligt att förstå vad som gick snett — och exakt var i processen man behöver justera prompterna.

Eventual consistency kräver tålamod. Ralph-loopen producerar ibland trasig kod under mellantillstånden. Det normala är att saker som inte fungerar i iteration 7 fungerar i iteration 12 — men det kräver att man motstår impulsen att gripa in och "hjälpa till" för tidigt. Att lita på processen är svårare än det låter.