# Agentisk kunstig intelligens i Claude Code: Ralph Loop gjennom natten
> Slik kjører du Claude Code i en autonom sløyfe: Ralph Loop, /loop, /goal, /batch. Ferdige scenarioer og beskyttelse mot å bruke opp tokens i 2026.
Source: https://ailoot.ai/blog/nb/claude-code-loop-engineering/
Canonical: https://ailoot.ai/blog/nb/claude-code-loop-engineering/
Language: nb
Publisher: Ailoot (https://ailoot.ai/)
Translation: guide-168
Revision: sha256-1e33f8957d46ef2640ac7fa7eb37f6d84ea2c67f4b0d06ebe8a21824ca7b2dcb
Hovedpunkter
Loop engineering er en tilnærming der du ikke gir Claude Code en prompt manuelt hver gang, men bygger en sløyfe. Sløyfen mottar oppgaven din, tar et steg, kontrollerer resultatet og avgjør selv om den skal fortsette eller stoppe. Denne veiledningen viser hvordan du setter opp din første Ralph Loop på én kveld, slik at den jobber for deg hver dag.
Ailoots referansedokumentasjon: [ailoot.ai/docs/](https://ailoot.ai/docs/).
## Hva er loop engineering, og hvorfor bør du bry deg?
Hovedpunkter
Loop engineering endrer rollen din. Før satt du og ga agenten instrukser: «gjør X, rett Y, sjekk Z». Nå skriver du et lite system som gjør dette for deg i en sløyfe: sender inn en oppgave – får et resultat – sjekker det – avgjør hva det skal gjøre videre. Du slutter å skrive, og agenten fortsetter å produsere.
Og den andre uttalelsen forklarer omfanget:
Bak disse uttalelsene ligger en ny ingeniørrolle: Du er arkitekten bak sløyfene, ikke en som sitter ved tastaturet.
Gjør det én gang i dag, så øker antallet leads hver dag, artikler publiseres automatisk, boten håndterer korrespondanse, og rapporten med måleverdier ligger på skrivebordet ditt innen kl. 9. Du bygger det, og det jobber hver dag uten deg.
Hvis du fortsatt åpner Claude Code, skriver en prompt, venter, leser og skriver en ny prompt, går du glipp av den største endringen i 2026. Modellene har blitt kraftige nok til å jobbe i sløyfer uten tilsyn.
## Slik skiller Ralph Loop seg fra en vanlig Claude Code-forespørsel
Hovedpunkter
En vanlig Claude Code-forespørsel er engangsbasert: Du skriver «gjør X», Claude gjør det, og chatten avsluttes. Ralph Loop gjør det samme, men i en sløyfe: Hver gang Claude prøver å avslutte, fanger en hook opp avslutningen og sender prompten din inn på nytt. Filene Claude allerede har opprettet, blir liggende, slik at hver nye iterasjon bygger videre på den forrige. Sløyfen stopper når den får et fullføringssignal (Claude skriver ut ordet «DONE») eller når iterasjonsgrensen er nådd.
Kjernen i teknikken er en enkel bash-sløyfe rundt en agent:
Den opprinnelige koden som satte i gang hele bølgen:
```bash
while :; do cat PROMPT.md | claude-code ; done
```
Én prompt i en fil og en uendelig sløyfe rundt den. Og forfatterens mest åpenhjertige kommentar:
Anthropic pakket den samme logikken inn i `ralph-loop`-pluginen og kommandoene `/loop`, `/goal` og `/batch` i Claude Code – de er tilgjengelige rett i terminalen uten skript. At Anthropic lanserte en plugin for uendelig ny prompting, utløste en diskusjon i GitHub Issue \#23084 om hvorvidt dette er rettferdig overfor modellen. Diskusjonen er åpen; pluginen fungerer.
## Tre innebygde Claude Code-kommandoer: /loop, /goal, /batch
Hovedpunkter
Claude Code v2.1+ har tre kommandoer for ulike nivåer av autonomi. `/loop` gjentar en oppgave med et bestemt intervall (hver time, daglig, overvåking). `/goal` jobber trinnvis til en evalueringsmodell sier «done». `/batch` utfører en stor, mekanisk endring ved hjelp av parallelle worktree-agenter. Hver av dem har sitt eget bruksområde.
| Kommando | Når du bør bruke den | Versjon | Grense |
|----|----|----|----|
| `/loop 30m ` | Gjenta med et intervall (overvåking, polling) | v2.1.72+ | 7 dager, 50 oppgaver per økt |
| `/goal ` | Jobb til et mål er nådd (verifikator-mønster) | v2.1.139+ | Betingelsen kan være opptil 4000 tegn |
| `/batch ` | Parallell, mekanisk refaktorering | v2.1.63+ | Hver enhet får sin egen git-worktree |
`/goal` er kommandoen som ligner mest på Ralph Loop. Under panseret sjekker en evalueringsmodell (Haiku som standard) ved hver tur om målet er nådd. Hvis ikke, får neste iterasjon et hint om nøyaktig hva som må rettes. Hvis målet er nådd, stopper den. Jeg har dekket `/goal` i detalj i veiledningen om [å kjøre Claude Code autonomt gjennom natten med /goal](https://ailoot.ai/blog/nb/goal-mode-claude-code-codex/) – den inneholder ferdige scenarioer for 14 timers arbeid.
`/batch` er en sjelden, men kraftig kommando. Når du må gjøre den samme endringen i over 100 filer (API-migrering, utskifting av komponenter, navneendring), sender `/batch` hver fil til en egen subagent i sin egen git-worktree. Endringene kommer ikke i konflikt – hver agent jobber i en isolert kopi. Les veiledningen om [nestede subagenter](https://ailoot.ai/blog/nb/claude-code-nested-subagents/) for mer om subagenter.
I forfatterens beskrivelse av denne tilnærmingen kalles det ganske enkelt:
Strenge grenser for `/loop` og `/goal`:
- En oppgave kjører så lenge Claude Code er åpen. Lukk terminalen, så stopper sløyfen. For en ordentlig nattlig syklus bør du bruke en ekstern server eller din egen shell-wrapper.
- En gjentakende oppgave kan maksimalt vare i **7 dager** (etter det slettes den automatisk for å beskytte mot glemte sløyfer).
- Opptil **50 samtidige oppgaver** i én økt.
Vil du bygge et oppsett som gjør Claude pålitelig? Ralph Loop er bare én del av det. Det er nyttig å se på alle tre komponentene: **AI-klone + Second Brain + Context Engineering** – denne kombinasjonen gjør Claude fra en «assistent som hallusinerer» om til et verktøy du kan gi en oppgave og så fortsette med ditt eget arbeid.
## Slik starter du din første autonome sløyfe på 5 minutter
Hovedpunkter
Den raskeste måten å komme i gang på er med den innebygde kommandoen `/goal`. Åpne Claude Code, skriv inn en kommando med et mål og en kontrollerbar stoppbetingelse, og fortsett med ditt eget arbeid. Claude genererer kode, kjører tester, leser feil, retter dem og kjører testene på nytt til de består.
5 trinn:
1. ### Åpne prosjektet i Claude Code
Gå til prosjektets rotmappe i terminalen og kjør `claude`. Vent til Claude har lest `CLAUDE.md` og indeksert repositoriet.
2. ### Definer et mål og en stoppbetingelse
Målet er det som skal gjøres. Stoppbetingelsen beskriver hvordan Claude vet at det er ferdig. Ideelt sett er den en kommando som returnerer 0 eller 1. Eksempel: «Mål: Alle 23 testene i `tests/api/*.test.ts` skal bestå. Stopp når `pnpm test` returnerer exit 0.»
3. ### Kjør /goal
Kommando:
```
/goal Alle tester i tests/api/*.test.ts må bestå. Kjør pnpm test, les feilene, rett dem og kjør testene på nytt. Stopp når exit-koden = 0. Maksimalt 20 iterasjoner.
```
Claude starter sløyfen: kjører tester – oppdager en feil – åpner filen – retter den – kjører testene på nytt.
4. ### Sett en budsjettgrense
Bruk `/usage` i en bakgrunnsfane for å følge med på forbruket. Sett en token- eller pengegrense for dagen, så du ikke bruker opp hele saldoen på én sløyfe. Du finner mer informasjon i veiledningen om [hvordan du unngår å bruke opp Claude Code-grensene](https://ailoot.ai/blog/nb/claude-code-token-limits-saving/).
5. ### Fortsett med ditt eget arbeid
Kom tilbake om 30 minutter. Hvis oppgaven er enkel, vil det allerede stå «DONE, all tests pass». Hvis den er mer komplisert, kan du lese rapporten: «stoppet ved iterasjon 20, årsak X». Rett manuelt det sløyfen ikke klarte, og start den på nytt.
Under panseret er dette en godt bygget sløyfe med et verifikator-mønster.
## Verifikator-mønster: slik kontrollerer Claude sitt eget arbeid i en sløyfe
Hovedpunkter
Claude bør alltid ha en måte å kontrollere arbeidet sitt på. Uten en kontroll begynner en agent i en sløyfe å hallusinere – den bestemmer at oppgaven er ferdig selv om alt egentlig er ødelagt. En verifikator er en kommando (tester, lint, evalueringsmodell, egendefinert kontroll) som returnerer et entydig «ferdig/ikke ferdig».
Det finnes tre typer verifikatorer:
**1. Teknisk (exit-kode)** – den mest pålitelige. `pnpm test`, `npm run lint`, `tsc --noEmit`, `playwright test`. De returnerer 0 eller 1 uten at resultatet må tolkes. `/goal` fungerer også slik – den bruker evalueringsmodellen Haiku under panseret, som sjekker ved hver tur om betingelsen er oppfylt (opptil 4000 tegn).
**2. Evalueringsmodell** – en annen modell vurderer resultatet fra den første modellen opp mot en vurderingsrubrikk. Passer godt for oppgaver uten en formell kontroll («Er skrivestilen god?» «Passer designet til merkevaren?»). Hos Anthropic kalles dette `Claude Code Review` – en modus der en separat reviewer-agent ser etter logiske feil, randtilfeller og sikkerhetsproblemer i hovedagentens arbeid. Ifølge interne data fra Anthropic finner den **84 % av problemene** i store PR-er (mot 16 % med grunnlinjetilnærmingen).
**3. Egendefinert kontroll** – et shell-skript du skriver selv. «Hvis loggene ikke inneholder ordet ERROR, er oppgaven ferdig.» «Hvis filen `output.json` finnes og kan parses, er oppgaven ferdig.» «Hvis siden `/pricing` returnerer 200, er oppgaven ferdig.»
I forfatterens tilnærming inkluderer ferdighetene en separat adversariell gjennomgang for Claude etter hver fase. Her er en promptmal jeg legger i `CLAUDE.md` eller i en kommando:
```
Finn 10 grunner til at dette prosjektet kan ha gått galt.
Sett deg i en situasjon der noe har gått galt.
Jeg kan gå gjennom dette forløpet mange ganger -
før jeg lanserer det for offentligheten.
```
Gjennomfør en sikkerhetsgjennomgang etter hver fase. Hver gang du er ferdig med kode, må du si «sikkerhetsgjennomgang».
Den vanligste nybegynnerfeilen er **å starte en sløyfe uten en verifikator**. Agenten går i ring: skriver kode, sjekker den ikke, tror den er ferdig, går videre til neste iterasjon og skriver om det den allerede gjorde. Tre timer senere er alt et rot, og regningen er på $200.
Den beste regelen: **skriv verifikatoren først, og start deretter sløyfen**. Hvis du ikke kan formulere stoppbetingelsen på én linje, er oppgaven ikke klar for autonom kjøring.
## Slik unngår du å bruke opp tusenvis av dollar i løpet av natten: budsjettgrenser og stoppbetingelser
Hovedpunkter
En sløyfe uten budsjettgrense, kostnadsbasert stoppbetingelse eller verifikator kan påføre store kostnader før noen oppdager det. Tre sikkerhetstiltak kan forhindre dette: en iterasjonsgrense, en token- eller pengegrense og en stagnasjonsdetektor.
Tre viktige bremser for enhver nattlig sløyfe:
**1. Iterasjonsgrense.** `--max-iterations 20`. Sløyfen kan ikke kjøre mer enn N ganger – selv om verifikatoren ikke utløses. Hvis stoppbetingelsen ikke er nådd etter 20 iterasjoner, har oppgaven kjørt seg fast og trenger menneskelig inngripen.
**2. Token- eller pengegrense.** `/usage limit 50` – maksimalt $50 om dagen. Når grensen nærmer seg, stopper sløyfen av seg selv og sender et varsel. Dette beskytter mot en løpsk situasjon.
**3. Fremdriftskontroll med en tydelig kontrakt.** Sammenligningen av `HEAD` nedenfor oppdager nye commits, ikke alle kodeendringer. Bruk den bare i et isolert worktree der hver iterasjon som endrer kode, lager en lokal checkpoint-commit før sammenligningen. Nyttige endringer uten commit endrer ikke `HEAD`; uten kontrakten kan en uendret hash gi et falskt stagnasjonssignal. Behold også verifikatorresultatet: En ny commit beviser en registrert endring, ikke at oppgaven er forbedret eller bestått.
En illustrerende wrapper-struktur med disse tre kontrollene. Linjene for kostnadsrapportering og agentkall er eksempler som avhenger av kjøreprogrammet, ikke en verifisert CLI-oppskrift. Bekreft grensesnittene for installert versjon før tilpasning. Fremdriftskontrollen basert på commits krever en lokal checkpoint-commit for hver kodeendrende iterasjon. Hvis kjøreprogrammet lar endringer stå uten commit, stopp for gjennomgang fremfor å kalle 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
# Pengegrense
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
# Kjør
OUTPUT=$(claude code -p "$PROMPT" --auto-accept)
# Kontroller fullføring
if echo "$OUTPUT" | grep -q "$COMPLETION"; then
echo "STOP: completion signal"
break
fi
# Bare commit-fremdrift: hver kodeendrende iterasjon må lage en checkpoint-commit.
# HEAD oppdager ikke nyttige endringer som ennå ikke er committet.
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
```
Kontroller fremdriftsmålingen før du utvider skjelettet: En endring uten commit må behandles som uregistrert arbeid; en checkpoint-commit endrer `HEAD`; bare den separate verifikatoren kan fastslå at resultatet er vellykket. Tre uendrede commit-hasher betyr ingen registrerte endringer under den angitte kontrakten, ikke bevis for at alle arbeidsfiler er uendret. Deretter kan du legge til et Slack-varsel når sløyfen stopper, en automatisk Telegram-rapport om morgenen og et push-varsel når budsjettet når 80 %. Prinsippet er det samme: En sløyfe trenger **bremser**, ikke bare en gasspedal.
## 5 ferdige scenarioer for nattlige sløyfer
Hovedpunkter
Ikke alle oppgaver egner seg for en autonom sløyfe. Gode kandidater er oppgaver med en entydig verifikator som kan løses iterativt: tester, refaktorering, overvåking, artikkelprosesser og dataimport. Dårlige kandidater er oppgaver uten formelle kontroller eller med flere subjektive kriterier.
**Scenario 1: Få tester som feiler, til å bestå**
```
/goal Det er 47 tester som feiler i tests/-katalogen. Mål: få dem alle til å bestå.
Kjør pnpm test, les stderr, åpne filen med feilen, rett den og kjør pnpm test på nytt.
Stopp når exit-koden er 0. Maks 30 iterasjoner.
```
**Scenario 2: Stor refaktorering på tvers av 200 filer**
```
/batch Bytt ut den gamle apiV1 API-klienten med den nye apiV2 i alle filer under src/**/*.ts.
Hver fil får sin egen worktree. Kjør tsc --noEmit etter utskiftingen; rett eventuelle feil.
Slå sammen worktree-ene til slutt.
```
**Scenario 3: Overvåking av produksjonsmiljøet gjennom natten**
```
/loop 30m Sjekk https://your-app.example.com/api/health hvert 30. minutt.
Hvis den ikke returnerer 200, les loggene, finn årsaken, rett den og distribuer på nytt.
Loggfør hver iterasjon i /tmp/night-monitor.log.
```
**Scenario 4: Importer et stort datasett med deduplisering**
```
/goal Importer CSV-filen /tmp/import.csv (12,000 rader) til clients-tabellen.
Kontroller hver rad for duplikater basert på e-post; hvis det ikke finnes et duplikat, sett inn raden, og hvis det finnes ett, oppdater den.
Loggfør konflikter i /tmp/conflicts.log. Stopp når den siste raden er behandlet.
```
**Scenario 5: Artikkelprosess (typisk oppsett)**
For en nettjeneste eller et byrå som regelmessig trenger SEO-artikler, ser scenarioet slik ut:
```
/loop 8h Hver 8. time: åpne backlog-filen for emner med status 'queued'.
Hvis et emne er tilgjengelig, kjør ferdigheten for å skrive en veiledning.
Publiser til dev. Endre status til 'review'. Varsle den ansvarlige personen på Telegram.
```
## Hva du bør gi hver iterasjon: CLAUDE.md og Second Brain som tilstand
Hovedpunkter
Uten minne begynner Claude hver iterasjon fra bunnen av – åpner prosjektet på nytt, leser filer og glemmer beslutningene fra forrige iterasjon. Uten `CLAUDE.md` kjenner det ikke arkitekturen; uten `business/` (Second Brain) kjenner det ikke produktkonteksten; uten skills husker det ikke reglene og stilen din. Tilstanden mellom iterasjonene beholdes i disse tre fillagene. Uten dem begynner sløyfen å forringes innen iterasjon 5.
Tre lag med prosjektminne gjør en engangsprompt om til en kontrollert sløyfe:
**1. CLAUDE.md** – prosjektets grunnlov. Hva produktet er, hvilken stack det bruker, hvilke regler som gjelder, og hva som aldri må gjøres. Claude leser denne filen når hver økt og hver sløyfeiterasjon starter. Uten den må Claude «åpne» prosjektet på nytt hver gang – det bruker opp kontekst og øker risikoen for hallusinasjoner. Finn en ferdig mal og 6 regler i [CLAUDE.md](https://ailoot.ai/blog/nb/claude-md-template/)-veiledningen.
**2. Second Brain** – en mappe med forretningskunnskap: produkt, målgruppe, mål, økonomi og markedsføring. Ikke kode, men mening. Når sløyfen skriver en artikkel eller leter etter et svar til kundestøtte, leser den Second Brain og svarer ut fra prosjektkonteksten, ikke ut fra et tomrom.
**3. Context engineering** – hva du gir Claude i hver iterasjon. Ikke hele Second Brain-mappen, ikke hele repositoriet – bare det som er relevant. Plan Mode hjelper: Claude avgjør hvilke filer oppgaven trenger og leser bare dem. Du finner mer informasjon i [Plan Mode](https://ailoot.ai/blog/nb/claude-code-plan-mode/)-veiledningen.
Det viktigste operasjonelle prinsippet jeg måtte hamre inn gjennom feil:
Disse tre lagene utgjør metodikkens **tre grunnpilarer**: AI-klone (du har lært Claude stilen og reglene dine gjennom skills og CLAUDE.md), Second Brain (forretningskunnskap i filer) og Context Engineering (det du gir i hver forespørsel). Uten alle tre blir sløyfen en uendelig syklus med en voksende regning.
## Slik jobber du med parallelle sløyfer om natten
Hovedpunkter
Hva skjer i hver økt? Ulike oppgaver: Én sløyfe retter feil, en annen skriver nye funksjoner, en tredje vurderer teamets PR-er, en fjerde optimaliserer ytelsen, og en femte forbereder dokumentasjon. Ikke én stor agent for generelle formål. Dusinvis av spesialiserte agenter, hver med sin egen skill, sitt eget mål og sin egen verifikator.
Den viktigste omformuleringen:
For en gründer uten programmerere betyr dette noe konkret. Du har én Claude-konto til $200 per måned og en vanlig bærbar datamaskin. Du kan starte **5 sløyfer parallelt** – kundestøtte, artikler, måleverdier, testing av et nytt produkt og overvåking av konkurrenter. Hver av dem kjører i sin egen Claude Code-fane. Om morgenen leser du sammendraget. Dette er allerede normen for arbeid sommeren 2026.
## Fire vanlige feil i autonome sløyfer
Hovedpunkter
De fleste feil i autonome sløyfer følger fire mønstre: ingen verifikator – agenten avgjør selv at den er ferdig; ingen budsjettgrense – sløyfen bruker opp budsjettet i løpet av natten; ingen tilstand mellom iterasjonene – beslutningene motsier hverandre; uklar stoppbetingelse – sløyfen vet ikke når den skal stoppe.
**Feil 1: «Hallusinasjonssløyfe»**
Agenten bestemmer seg for at den er ferdig selv om verifikatoren ikke er utløst. Eller så finnes det ingen verifikator i det hele tatt. Tre timer senere sier Claude: «Alt er ferdig!» – men testene feiler, siden åpnes ikke, og ingenting fungerer. Du har allerede brukt $80 på unyttige iterasjoner.
**Løsning:** en streng verifikator (kommandoens `exit code`), ikke en muntlig kontroll.
**Feil 2: «Brukte opp budsjettet gjennom natten»**
Uten en budsjettgrense blir en sløyfe en håndgranat uten sikringspinne.
**Løsning:** `/usage limit` eller et eksternt skript som bruker `claude usage --json` til å stoppe sløyfen når den når en terskel.
**Feil 3: «Sløyfen mistet konteksten mellom iterasjonene»**
I iterasjon 1 tok Claude en arkitekturbeslutning. Innen iterasjon 7 hadde den glemt den og tatt den motsatte beslutningen. Etter 15 iterasjoner er koden et eneste rot.
**Løsning:** et tilstandslag via `CLAUDE.md` og Second Brain-mappen. Sløyfen **skriver** hver arkitekturbeslutning til en fil som den leser i neste iterasjon.
**Feil 4: «Stoppbetingelsen er upresis – sløyfen kjører for alltid»**
`/goal "Gjør siden vakker"` – hva betyr «vakker»? Uten et entydig mål vil sløyfen aldri stoppe. Den fortsetter til den når iterasjons- eller budsjettgrensen.
**Løsning:** Stoppbetingelsen må alltid være **målbar**. Ikke «vakker», men «Lighthouse Performance ≥ 90, Accessibility ≥ 95». Ikke «fungerer», men «testene i `tests/pricing.test.ts` består».
## Når du ikke trenger loop engineering
Hovedpunkter
Loop engineering er et verktøy for gjentakende oppgaver som kan verifiseres. Det er unødvendig for kreative engangsoppgaver, oppgaver uten en formell verifikator og oppgaver som krever subjektiv vurdering. Det er viktigere å kjenne grensene enn å kunne teknikken.
Dette egner seg ikke for en autonom sløyfe:
- **En kreativ engangsoppgave.** Én nettside for et nytt produkt, én logo, ett strateginotat. En sløyfe er overkill her; det er enklere å skrive én prompt og forbedre resultatet for hånd.
- **En oppgave uten verifikator.** Hvis du ikke kan uttrykke stoppbetingelsen som en exit-kode eller et entydig signal, bør du ikke starte sløyfen – ellers blir det et evig bål.
- **En oppgave som krever subjektiv vurdering.** «Få det til å høres bedre ut», «forbedre brukeropplevelsen så den blir mer behagelig» – dette krever deg, ikke en sløyfe.
- **Et nytt og ukjent fagområde.** Hvis du selv ikke forstår hvordan «ferdig» skal se ut, bør du ikke kjøre Claude i en sløyfe. Skaff deg først forståelse, og automatiser deretter.
Og hovedregelen jeg lærte gjennom feil:
Det viktigste spørsmålet før du starter en sløyfe: **Kan jeg beskrive på én linje hvordan jeg vet at Claude er ferdig?** Hvis ja, kan sløyfen være til hjelp. Hvis ikke, må du først definere en verifiserbar betingelse og deretter starte.
### Kilder
- [Ralph Loop Claude Plugin - Anthropic](https://claude.com/plugins/ralph-loop) - offisiell 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 av PR-gjennomgang med flere agenter, 84 % treffrate
- [Documentation /goal - Claude Code Docs](https://code.claude.com/docs/en/goal) - offisiell dokumentasjon for kommandoen
- [Documentation /loop scheduled tasks - Claude Code Docs](https://code.claude.com/docs/en/scheduled-tasks) - offisiell dokumentasjon
Loop engineering er et lag oppå alt du allerede kan om Claude Code. Først trenger du de tre grunnpilarene: AI-klone + Second Brain + Context Engineering. Uten dem forringes sløyfen innen iterasjon 5. Fortsett å utforske Ailoot på [ailoot.ai](https://ailoot.ai/).
## Spørsmål om denne veiledningen: Agentisk kunstig intelligens i Claude Code: Ralph Loop gjennom natten
### Hvorfor kan uendret HEAD feilaktig tyde på at en sløyfe står stille?
HEAD identifiserer en commit. Nyttige endringer i arbeidsmappen endrer ikke HEAD før de committes. Eksempeldetektoren krever derfor en lokal checkpoint-commit etter hver kodeendrende iterasjon. Uten denne kontrakten må du stanse og undersøke ucommittet arbeid fremfor å kalle det stagnasjon.
### Beviser en ny commit at sløyfen har forbedret resultatet?
Nei. Den beviser bare at en endring er registrert. Behold verifikatorresultatet sammen med sjekkpunktet, og stopp ved det faktiske akseptansekriteriet. Wrapperens grensesnitt for agentkall og kostnad avhenger av kjøreprogrammet og må valideres før bruk.
## Ailoot · Selskapet og dets prosjektportefølje
Ailoot bygger på etablert driftserfaring, en stor kundebase, stabil tjeneste og løpende KPI-kontroll.
Selskapet og dets prosjektportefølje: millioner av kunder; månedlig salg for milliarder.
Ailoot bruker denne driftserfaringen til API-tilgang til AI-funksjoner i kundenes produkter, agenter, applikasjoner og automatiseringer.