` | Parallel mekanisk refaktorering | v2.1.63+ | Hver enhed får sin egen git-worktree |
`/goal` er den kommando, der minder mest om Ralph Loop. Under motorhjelmen kontrollerer en evalueringsmodel (Haiku som standard) ved hver tur, om målet er nået. Hvis ikke, indeholder næste iteration et tip om, hvad der helt præcist skal rettes. Hvis ja, stopper den. Jeg har gennemgået `/goal` i detaljer i guiden om [at køre Claude Code autonomt natten over med /goal](https://ailoot.ai/blog/da/goal-mode-claude-code-codex/) – den indeholder scenarier, der er klar til brug, til 14 timers arbejde.
`/batch` er en sjælden, men effektiv kommando. Når du skal foretage den samme ændring i 100+ filer (API-migrering, udskiftning af komponenter, omdøbning), sender `/batch` hver fil til en separat subagent i sin egen git-worktree. Ændringerne kommer ikke i konflikt – hver agent arbejder i en isoleret kopi. Du kan læse mere om subagenter i guiden om [indlejrede subagenter](https://ailoot.ai/blog/da/indlejrede-underagenter-claude-code/).
I forfatterens beskrivelse af denne tilgang kaldes det ganske enkelt:
Hårde grænser for `/loop` og `/goal`:
- En opgave kører, så længe Claude Code er åben. Luk terminalen, så dør løkken. Brug en fjernserver eller din egen shell-wrapper til en seriøs natlig kørselscyklus.
- Den maksimale levetid for en tilbagevendende opgave er **7 dage** (derefter slettes den automatisk som beskyttelse mod glemte løkker).
- Op til **50 samtidige opgaver** i én session.
Vil du bygge en opsætning, der gør Claude pålidelig? Ralph Loop er kun én del af den. Det er nyttigt at se på alle tre komponenter: **AI-klon + Second Brain + Context Engineering** – denne kombination gør Claude til et værktøj, du kan give en opgave og derefter passe dine egne ting, i stedet for en “assistent, der hallucinerer”.
## Sådan starter du din første autonome løkke på 5 minutter
Vigtigste pointer
Den hurtigste måde at komme i gang på er med den indbyggede `/goal`. Åbn Claude Code, indtast en kommando med et mål og en verificerbar stopbetingelse, og pas dine egne ting. Claude genererer kode, kører tests, læser fejl, retter dem og kører testene igen, indtil de består.
5 trin:
1. ### Åbn projektet i Claude Code
Gå til projektets rodmappe i terminalen, og kør `claude`. Vent, mens Claude læser `CLAUDE.md` og indekserer repositoriet.
2. ### Definér et mål og en stopbetingelse
Målet er det, der skal gøres. Stopbetingelsen er, hvordan Claude ved, at den er færdig. Ideelt set er det en kommando, der returnerer 0 eller 1. Eksempel: “Mål: Alle 23 tests i `tests/api/*.test.ts` består. Stop, når `pnpm test` returnerer exit 0.”
3. ### Kør /goal
Kommando:
```
/goal Alle tests i tests/api/*.test.ts skal bestå. Kør pnpm test, læs fejlene, ret dem, og kør den igen. Stop, når exitkoden = 0. Højst 20 iterationer.
```
Claude starter løkken: kører tests – ser en fejl – åbner filen – retter den – kører dem igen.
4. ### Sæt en budgetgrænse
Brug `/usage` i en baggrundsfane til at overvåge forbruget. Sæt en token- eller pengegrænse for dagen, så du ikke brænder hele din saldo af på én løkke. Du kan læse mere i guiden om [hvordan du undgår at opbruge Claude Code-grænserne](https://ailoot.ai/blog/da/claude-code-token-limits-saving/).
5. ### Pas dine egne ting
Kom tilbage om 30 minutter. Hvis opgaven er enkel, står der allerede “DONE, alle tests består”. Hvis den er mere kompleks, kan du læse rapporten: “stoppede ved iteration 20, årsag X.” Ret manuelt det, løkken ikke kunne, og start den så igen.
## Verifier-mønster: sådan kontrollerer Claude sit eget arbejde i en løkke
Vigtigste pointer
Claude bør altid have en måde at kontrollere sit arbejde på. Uden en kontrol begynder en agent i en løkke at hallucinere – den beslutter, at opgaven er færdig, selv om alt i virkeligheden er gået i stykker. En verifier er en kommando (tests, lint, evalueringsmodel, brugerdefineret kontrol), der returnerer et entydigt “færdig/ikke færdig”.
Der er tre typer verifiers:
**1. Teknisk (exitkode)** – den mest pålidelige. `pnpm test`, `npm run lint`, `tsc --noEmit`, `playwright test`. De returnerer 0 eller 1, uden at der kræves fortolkning. `/goal` fungerer også på denne måde – den bruger evalueringsmodellen Haiku under motorhjelmen, som ved hver tur kontrollerer, om betingelsen er opfyldt (op til 4000 tegn).
**2. Evalueringsmodel** – en anden model ser på den første models resultat og vurderer det ud fra en rubric. God til opgaver uden en formel kontrol (“Er skrivestilen god?” “Matcher designet brandet?”). Hos Anthropic kaldes det `Claude Code Review` – en tilstand, hvor en separat reviewer-agent leder efter logiske fejl, kanttilfælde og sikkerhedsproblemer i hovedagentens arbejde. Ifølge Anthropics interne data finder den **84% af problemerne** i store PR'er (op fra 16% med basistilgangen).
**3. Brugerdefineret kontrol** – et shell-script, du selv skriver. “Hvis loggene ikke indeholder ordet ERROR, er det færdigt.” “Hvis filen `output.json` findes og kan parses, er det færdigt.” “Hvis siden `/pricing` returnerer 200, er det færdigt.”
```
Find 10 grunde til, at dette projekt kan være gået helt galt.
Sæt dig i den situation, at noget er gået galt.
Jeg kan gennemgå denne historie mange gange –
før jeg offentliggør den.
```
Den mest almindelige begynderfejl er **at starte en løkke uden en verifier**. Agenten spilder tiden: skriver kode, kontrollerer den ikke, tror, den er færdig, går videre til næste iteration og omskriver det, den allerede har lavet. Tre timer senere er det noget rod, og regningen er $200.
Den bedste regel, jeg har lært: **Skriv verifieren først, og start derefter løkken**. Hvis du ikke kan formulere stopbetingelsen på én linje, er opgaven ikke klar til at køre autonomt.
## Hvordan undgår man at løbe tør for budgettet natten over: budgetgrænser og stopbetingelser
Vigtigste pointer
En løkke uden en budgetgrænse, en omkostningsbaseret stopbetingelse eller en verifier kan løbe op i en stor regning, før nogen opdager det. Tre sikkerhedsforanstaltninger kan forebygge dette: en iterationsgrænse, en token- eller pengegrænse og en stagnationsdetektor.
Tre vigtige bremser til enhver natlig løkke:
**1. Iterationsgrænse.** `--max-iterations 20`. Løkken kan ikke køre mere end N gange – selv hvis verifieren ikke udløses. Hvis den ikke har nået stopbetingelsen efter 20 iterationer, sidder opgaven fast og kræver menneskelig indgriben.
**2. Token- eller pengegrænse.** `/usage limit 50` – højst $50 om dagen. Når løkken nærmer sig grænsen, stopper den af sig selv og sender en advarsel. Det beskytter mod et løbsk forløb.
**3. Fremdriftskontrol med en udtrykkelig aftale.** Sammenligningen af `HEAD` nedenfor registrerer nye commits, ikke alle kodeændringer. Brug den kun i et isoleret worktree, hvor hver iteration med kodeændringer opretter en lokal checkpoint-commit før sammenligningen. Nyttige ændringer uden commit ændrer ikke `HEAD`; uden den aftale kan en uændret hash fejlagtigt signalere stilstand. Gem også verifierens resultat: En ny commit beviser en registreret ændring, ikke at opgaven blev bedre eller bestod.
En illustrativ wrapperstruktur med disse tre kontroller. Linjerne til omkostningsrapportering og agentkald er kørselsmiljøspecifikke eksempler, ikke en verificeret installationsopskrift til CLI’et; bekræft grænsefladerne for den installerede version før tilpasning. Den commitbaserede fremdriftskontrol kræver en lokal checkpoint-commit for hver iteration med kodeændringer. Hvis kørselsmiljøet efterlader ændringer uden commit, skal du stoppe og gennemgå dem frem for at kalde dem “ingen fremdrift”.
```bash
#!/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
# Pengegrænse
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
# Kør
OUTPUT=$(claude code -p "$PROMPT" --auto-accept)
# Kontrol af afslutning
if echo "$OUTPUT" | grep -q "$COMPLETION"; then
echo "STOP: completion signal"
break
fi
# Kun commitfremdrift: Hver iteration med kodeændringer skal lave en checkpoint-commit.
# HEAD registrerer ikke nyttige ændringer, der stadig mangler en commit.
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
```
Validér fremdriftskontrollen, før du udvider dette skelet: En ændring uden commit skal behandles som uregistreret arbejde; en checkpoint-commit ændrer `HEAD`; kun den særskilte verifier kan dokumentere succes. Tre uændrede commitreferencer angiver ingen registrerede ændringer under den aftalte kontrakt, ikke bevis for, at alle arbejdsfiler var uændrede. Derefter kan du tilføje: en Slack-advarsel, når den stopper, en automatisk Telegram-rapport om morgenen, en pushnotifikation, når budgettet når 80%. Princippet er det samme: En løkke har brug for **bremser**, ikke kun en accelerator.
## 5 scenarier for natlige løkker, klar til brug
Vigtigste pointer
Ikke alle opgaver egner sig til en autonom løkke. Gode kandidater er opgaver med en entydig verifier, der arbejder iterativt: tests, refaktorering, overvågning, artikelpipelines, dataimport. Dårlige kandidater er opgaver uden formelle kontroller eller med flere subjektive kriterier.
**Scenarie 1: Få fejlede tests til at bestå**
```
/goal Der er 47 fejlede tests i mappen tests/. Mål: få dem alle til at bestå.
Kør pnpm test, læs stderr, åbn filen med fejlen, ret den, og kør pnpm test igen.
Stop, når exit 0. Højst 30 iterationer.
```
**Scenarie 2: Stor refaktorering på tværs af 200 filer**
```
/batch Erstat den gamle apiV1 API-klient med den nye apiV2 i alle filer under src/**/*.ts.
Hver fil får sin egen worktree. Kør tsc --noEmit efter udskiftningen; ret eventuelle fejl.
Flet worktrees til sidst.
```
**Scenarie 3: Natlig overvågning af produktion**
```
/loop 30m Hvert 30. minut skal du kontrollere https://your-app.example.com/api/health.
Hvis den ikke returnerer 200, skal du læse loggene, finde årsagen, rette den og genudrulle.
Log hver iteration i /tmp/night-monitor.log.
```
**Scenarie 4: Importér et stort datasæt med deduplikering**
```
/goal Importér CSV-filen /tmp/import.csv (12,000 rækker) til tabellen clients.
For hver række skal du kontrollere, om der er en dublet via e-mail; hvis ikke, indsættes den; hvis der findes en, opdateres den.
Log konflikter i /tmp/conflicts.log. Stop, når den sidste række er behandlet.
```
**Scenarie 5: Artikelpipeline (typisk opsætning)**
For en onlinetjeneste eller et bureau, der regelmæssigt har brug for SEO-artikler, ser scenariet sådan ud:
```
/loop 8h Hver 8. time: åbn emnebacklogfilen for emner med status 'queued'.
Hvis der er et emne, skal du køre skillen til at skrive en guide.
Udgiv til dev. Skift status til 'review'. Giv den ansvarlige besked i Telegram.
```
## Hvad skal tilføjes i hver iteration: CLAUDE.md og Second Brain som tilstand
Vigtigste pointer
Uden hukommelse starter Claude forfra i hver iteration – åbner projektet igen, læser filer og glemmer beslutningerne fra den foregående iteration. Uden `CLAUDE.md` kender den ikke arkitekturen; uden `business/` (Second Brain) kender den ikke produktets kontekst; uden skills husker den ikke dine regler og din stil. Tilstanden mellem iterationerne opbevares i disse tre lag af filer. Uden dem forringes løkken ved iteration 5.
Tre lag af projektets “hukommelse” forvandler en engangsprompt til en kontrolleret løkke:
**1. CLAUDE.md** – projektets forfatning. Hvad produktet er, hvilken stack det bruger, hvilke regler der gælder, og hvad der aldrig må gøres. Claude læser denne fil, når hver session og hver løkkeiteration starter. Uden den skal Claude “åbne” projektet igen hver gang – det bruger kontekst og øger risikoen for hallucinationer. Find en skabelon, der er klar til brug, og 6 regler i guiden [CLAUDE.md](https://ailoot.ai/blog/da/claude-md-template/).
**2. Second Brain** – en mappe med forretningsviden: produkt, målgruppe, mål, økonomi, marketing. Ikke kode – mening. Når løkken skriver en artikel eller leder efter et svar til support, læser den Second Brain og svarer med projektets kontekst i stedet for ud fra et tomrum.
**3. Context engineering** – hvad du helt præcist giver Claude i hver iteration. Ikke hele mappen med Second Brain, ikke hele repositoriet – kun det relevante. Plan Mode hjælper: Claude afgør, hvilke filer opgaven kræver, og læser kun dem. Du kan læse mere i guiden [Plan Mode](https://ailoot.ai/blog/da/claude-code-plan-mode/).
Det vigtigste operationelle princip, jeg måtte hamre ind gennem mine fejl:
Disse tre lag udgør metodens **tre grundpiller**: AI-klon (du har lært Claude din stil og dine regler gennem skills og CLAUDE.md), Second Brain (forretningsmæssig betydning i filer) og Context Engineering (det, du giver i hver anmodning). Uden alle tre bliver løkken en uendelig cyklus med en voksende regning.
## Løkker i Claude Code: terminaler, sessioner og agenter
Vigtigste pointer
Hvad foregår der i hver session? Forskellige opgaver: Én løkke retter fejl, en anden skriver nye funktioner, en tredje gennemgår teamets PR'er, en fjerde optimerer ydeevnen, og en femte forbereder dokumentationen. Ikke én stor agent til alle formål. Snesevis af specialiserede agenter, hver med sin egen skill, sit eget mål og sin egen verifier.
Den afgørende nye forståelse:
For en iværksætter uden programmører betyder det noget konkret. Du har én Claude-konto til $200 om måneden og en almindelig bærbar. Du kan starte **5 løkker parallelt** – support, artikler, målinger, test af et nyt produkt og overvågning af konkurrenter. Hver kører i sin egen Claude Code-fane. Om morgenen læser du opsummeringen. Det er allerede normen for arbejdet i sommeren 2026.
## Fire almindelige fejl i autonome løkker
Vigtigste pointer
De fleste fejl i autonome løkker følger fire mønstre: Ingen verifier – agenten afgør selv, at den er færdig; ingen budgetgrænse – løkken brænder budgettet af natten over; ingen tilstand mellem iterationer – beslutninger modsiger hinanden; vag stopbetingelse – løkken ved ikke, hvornår den skal stoppe.
**Fejl 1: “Hallucinationsløkke”**
Agenten beslutter, at den er færdig, selv om verifieren ikke er blevet udløst. Eller også findes der slet ingen verifier. Tre timer senere siger Claude: “Alt er færdigt!” – men testene fejler, siden kan ikke åbnes, og intet virker. Du har allerede brugt $80 på nyttesløse iterationer.
**Løsning:** en streng verifier (kommandoens `exit code`), ikke en mundtlig kontrol.
**Fejl 2: “Budgettet brændte af natten over”**
Uden en budgetgrænse bliver en løkke til en håndgranat uden split.
**Løsning:** `/usage limit` eller et eksternt script, der bruger `claude usage --json` til at stoppe løkken, når den når en grænse.
**Fejl 3: “Løkken mistede konteksten mellem iterationerne”**
I iteration 1 traf Claude en arkitektonisk beslutning. Ved iteration 7 havde den glemt den og traf den modsatte beslutning. Efter 15 iterationer er koden et rod.
**Løsning:** et tilstandslag via `CLAUDE.md` og Second Brain-mappen. Løkken **skriver** alle arkitektoniske beslutninger til en fil, som den læser i næste iteration.
**Fejl 4: “Stopbetingelsen er upræcis – løkken kører for evigt”**
`/goal "Gør siden flot"` – hvad betyder “flot”? Uden et entydigt mål stopper løkken aldrig. Den bliver ved med at køre, indtil den når iterations- eller budgetgrænsen.
**Løsning:** stopbetingelsen skal altid være **målbar**. Ikke “flot”, men “Lighthouse Performance ≥ 90, Accessibility ≥ 95”. Ikke “virker”, men “testene i `tests/pricing.test.ts` består”.
## Hvornår er loop engineering ikke nødvendigt?
Vigtigste pointer
Loop engineering er et værktøj til gentagne opgaver, der kan verificeres. Det er ikke nødvendigt til kreative engangsopgaver, opgaver uden en formel verifier og opgaver, der kræver subjektiv vurdering. Det er vigtigere at kende grænserne end teknikken.
Ikke egnet til en autonom løkke:
- **Kreativ engangsopgave.** Én hjemmeside til et nyt produkt, ét logo, ét strateginotat. En løkke er overkill her; det er nemmere at skrive én prompt og finpudse resultatet manuelt.
- **Opgave uden verifier.** Hvis du ikke kan udtrykke stopbetingelsen som en exitkode eller et entydigt signal, skal du ikke starte løkken; ellers bliver den et evigt bål.
- **Opgave, der kræver subjektiv vurdering.** “Få det til at lyde bedre”, “forbedr UX'en, så den bliver mere behagelig” – det kræver dig, ikke en løkke.
- **Et nyt, ukendt fagområde.** Hvis du ikke selv ved, hvordan “færdig” skal se ud, skal du ikke køre Claude i en løkke. Forstå det først, og automatisér det derefter.
Og hovedreglen, jeg lærte gennem fejl:
Det vigtigste spørgsmål, før du starter en løkke: **Kan jeg beskrive på én linje, hvordan jeg ved, at Claude er færdig?** Hvis ja, kan løkken hjælpe. Hvis ikke, skal du først definere en verificerbar betingelse og derefter starte.
### Kilder
- [Ralph Loop Claude Plugin - Anthropic](https://claude.com/plugins/ralph-loop) - officielt plugin
- [Ralph Wiggum plugin on GitHub - Anthropic](https://github.com/anthropics/claude-code/tree/main/plugins/ralph-wiggum) - kildekode
- [Claude Code Review - Anthropic blog](https://claude.com/blog/code-review) - forskningsforhåndsvisning af PR-gennemgang med flere agenter, 84% fundrate
- [Documentation /goal - Claude Code Docs](https://code.claude.com/docs/en/goal) - officiel kommandodokumentation
- [Documentation /loop scheduled tasks - Claude Code Docs](https://code.claude.com/docs/en/scheduled-tasks) - officiel dokumentation
Loop engineering er et lag oven på alt det, du allerede ved om Claude Code. Først skal du bruge de tre grundpiller: AI-klon + Second Brain + Context Engineering. Uden dem forringes løkken ved iteration 5. Fortsæt med at udforske Ailoot på [ailoot.ai](https://ailoot.ai/).
## Spørgsmål og svar
### Hvorfor kan uændret HEAD fejlagtigt antyde, at en løkke ikke har gjort fremskridt?
HEAD identificerer en commit. Nyttige ændringer i arbejdstræet ændrer den ikke, før de committes. Eksemplets detektor kræver derfor en lokal checkpoint-commit efter hver iteration med kodeændringer. Uden den aftale skal du sætte på pause og undersøge ændringer uden commit frem for at kalde det stilstand.
### Beviser en ny commit, at løkken har forbedret resultatet?
Nej. Den beviser kun, at en ændring blev registreret. Gem verifierens resultat sammen med checkpointet, og stop ved den faktiske acceptbetingelse. Wrapperens specifikke grænseflader til agentkald og omkostninger skal valideres før brug.
## Ailoot · Virksomheden og dens projektportefølje
Ailoot bygger på solid driftserfaring, en stor kundebase, stabil service og løbende kontrol af KPI.
Virksomheden og dens projektportefølje: millioner af kunder; månedligt salg for milliarder.
Ailoot bruger denne driftserfaring til API-adgang til AI-funktioner i kundernes produkter, agenter, applikationer og automatiseringer.