Claude Code éjszakára: loop engineering és Ralph Loop 2026-ban

Ailoot referencia-dokumentáció: ailoot.ai/docs/.

Mi az a loop engineering, és miért érdemes foglalkoznod vele?#

A második kijelentése pedig a léptéket magyarázza:

E kijelentések mögött egy új mérnöki szerep áll: te vagy a ciklusok tervezője, nem a billentyűzet kezelője.

Végezd el ma egyszer, és minden nap nőnek a leadek, automatikusan jelennek meg a cikkek, a bot kezeli a levelezést, a metrikajelentés pedig reggel 9-re az asztalodra kerül. Megépíted, és minden nap működik nélküled.

Ha még mindig megnyitod a Claude Code-ot, beírsz egy promptot, vársz, elolvasod az eredményt, majd írsz egy újabb promptot, akkor lemaradsz 2026 legnagyobb változásáról. A modellek már elég erősek ahhoz, hogy felügyelet nélkül, ciklusokban dolgozzanak.

Miben különbözik a Ralph Loop egy szokásos Claude Code-kéréstől?#

A technika alapja egy egyszerű bash ciklus egy ügynök körül:

Az eredeti kód, amely elindította az egész hullámot:

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

Egy prompt egy fájlban, körülötte egy végtelen ciklus. A szerző legőszintébb megjegyzése pedig:

Az Anthropic ugyanezt a logikát a ralph-loop pluginba, valamint a Claude Code /loop, /goal és /batch parancsaiba csomagolta – ezek közvetlenül a terminálban elérhetők szkriptek nélkül. Már az a tény is vitát váltott ki a GitHub Issue #23084 alatt, hogy az Anthropic végtelen újrapromptoláshoz adott ki plugint: vajon ez tisztességes-e a modellel szemben? A vita nyitott; a plugin működik.

Három beépített Claude Code-parancs: /loop, /goal, /batch#

A /goal a Ralph Loophoz leginkább hasonló parancs. A háttérben egy értékelő modell (alapértelmezés szerint Haiku) minden körben ellenőrzi, hogy teljesült-e a cél. Ha nem, a következő iteráció tippet kap arról, pontosan mit kell kijavítani. Ha igen, leáll. Részletesen bemutattam a /goal parancsot az éjszakai autonóm Claude Code-futtatás /goal segítségével című útmutatóban – kész forgatókönyveket is tartalmaz 14 órányi munkához.

A /batch ritkán használt, de hatékony parancs. Ha ugyanazt a módosítást kell elvégezned több mint 100 fájlban (API-migráció, komponenscsere, átnevezés), a /batch minden fájlt külön alügynöknek küld a saját git worktree-jében. A módosítások nem ütköznek, mert minden ügynök elszigetelt másolaton dolgozik. Az alügynökökről bővebben a beágyazott alügynökökről szóló útmutatóban olvashatsz.

A szerző megközelítésének leírásában ezt egyszerűen így nevezik:

A /loop és a /goal szigorú korlátai:

• A feladat addig fut, amíg nyitva van a Claude Code. Zárd be a terminált, és a ciklus leáll. Komoly éjszakai ciklushoz használj távoli szervert vagy saját shell wrappert.
• Egy ismétlődő feladat maximális élettartama 7 nap (ezután automatikusan törlődik, hogy ne maradjanak elfelejtett ciklusok).
• Munkamenetenként legfeljebb 50 egyidejű feladat futhat.

Így indítsd el az első autonóm ciklusodat 5 perc alatt#

5 lépés:

1. Nyisd meg a projektet a Claude Code-ban

   Lépj a terminálban a projekt gyökérkönyvtárába, és futtasd a claude parancsot. Várd meg, amíg Claude beolvassa a CLAUDE.md fájlt, és indexeli a tárolót.

2. Határozd meg a célt és a leállási feltételt

   A cél az, amit el kell végezni. A leállási feltétel pedig az, amiből Claude tudni fogja, hogy végzett. Ideális esetben ez egy 0 vagy 1 értékkel visszatérő parancs. Példa: „Cél: a tests/api/*.test.ts összes 23 tesztje sikeres legyen. Állj le, amikor a pnpm test 0 kilépési kódot ad vissza.”

3. Futtasd a /goal parancsot

   Parancs:

   /goal A tests/api/*.test.ts összes tesztjének sikeresnek kell lennie. Futtasd a pnpm test parancsot, olvasd el a hibákat, javítsd ki őket, majd futtasd újra. Akkor állj le, ha a kilépési kód = 0. Legfeljebb 20 iteráció.
   

   Claude elindítja a ciklust: futtatja a teszteket – hibát talál – megnyitja a fájlt – kijavítja – újra futtatja a teszteket.

4. Állíts be költségkeretet

   Egy háttérben lévő lapon használd a /usage parancsot a használat követésére. Állíts be napi token- vagy pénzkorlátot, hogy egyetlen ciklus ne használja fel az egész keretedet. Részletek a Claude Code-keret gyors kimerülésének elkerüléséről szóló útmutatóban.

5. Foglalkozz a dolgaiddal

   Térj vissza 30 perc múlva. Ha egyszerű a feladat, már ezt fogja írni: „DONE, minden teszt sikeres.” Ha összetettebb, olvasd el a jelentést: „leállt a 20. iterációnál, oka: X”. Amit a ciklus nem tudott megoldani, javítsd ki kézzel, majd indítsd újra.

A háttérben egy megfelelően felépített ciklus működik, verifier-mintával.

Verifier-minta: így ellenőrzi Claude a saját munkáját egy ciklusban#

Háromféle verifier létezik:

1. Technikai (kilépési kód) – a legmegbízhatóbb. pnpm test, npm run lint, tsc --noEmit, playwright test. Ezek 0 vagy 1 értékkel térnek vissza, értelmezés nélkül. A /goal is így működik – a háttérben a Haiku értékelő modell ellenőrzi minden körben, hogy teljesült-e a feltétel (legfeljebb 4000 karakter).

2. Értékelő modell – egy második modell megvizsgálja az első modell eredményét, majd egy rubrika szerint értékeli. Olyan feladatokhoz jó, amelyeknek nincs formális ellenőrzése („Jó az írás stílusa?” „Illik a terv a márkához?”). Az Anthropicnál ezt Claude Code Review néven hívják: olyan módról van szó, amelyben egy külön felülvizsgáló ügynök logikai hibákat, szélső eseteket és biztonsági problémákat keres a fő ügynök munkájában. Az Anthropic belső adatai szerint nagy PR-ekben a problémák 84%-át megtalálja (az alapmegközelítés 16%-os arányához képest).

3. Egyedi ellenőrzés – saját magad által írt shell-szkript. „Ha a naplókban nem szerepel az ERROR szó, kész.” „Ha az output.json fájl létezik és feldolgozható, kész.” „Ha a /pricing oldal 200-as választ ad, kész.”

A készségek közé tartozhat a Claude külön adverszárius ellenőrzése minden fázis után. Íme egy promptminta, amelyet a CLAUDE.md fájlba vagy egy parancsba szoktam tenni:

Keress 10 okot arra, hogy miért mehetett tönkre ez a projekt. 
Helyezd magad abba a helyzetbe, hogy valami félresiklott. 
Ezt a történetet sokszor végigvehetem - 
mielőtt nyilvánosságra hozom.

A kezdők leggyakoribb hibája, hogy verifier nélkül indítják el a ciklust. Az ügynök egy helyben toporog: kódot ír, nem ellenőrzi, késznek hiszi, továbblép a következő iterációra, majd újraírja azt, amit már megcsinált. Három órával később minden káosz, a számla pedig $200.

A legjobb szabály, amit megtanultam: először írd meg a verifiert, és csak utána indítsd el a ciklust. Ha a leállási feltételt nem tudod egy sorban megfogalmazni, a feladat még nem áll készen az autonóm végrehajtásra.

Hogyan ne költs el több ezer dollárt egyetlen éjszaka alatt: költségkorlátok és leállási feltételek#

Három alapvető fék minden éjszakai ciklushoz:

1. Iterációs korlát. --max-iterations 20. A ciklus nem futhat N alkalomnál többször – akkor sem, ha a verifier nem aktiválódik. Ha 20 iteráció után sem teljesült a leállási feltétel, a feladat elakadt, és emberi beavatkozásra van szükség.

2. Token- vagy pénzkeret. /usage limit 50 – legfeljebb napi $50. A keret közelében a ciklus magától leáll, és riasztást küld. Ez véd az elszabadult forgatókönyvektől.

3. Előrehaladás-ellenőrzés kifejezett működési szerződéssel. Az alábbi HEAD-összehasonlítás új commitokat érzékel, nem minden kódváltozást. Csak elkülönített worktree-ben használd, ahol minden kódmódosító iteráció helyi ellenőrzőpont-commitot rögzít az összehasonlítás előtt. A hasznos, nem commitolt szerkesztések nem változtatják meg a HEAD-et; e szerződés nélkül a változatlan hash téves stagnálási jelzés lehet. A verifier eredményét is őrizd meg: egy új commit rögzített változást bizonyít, nem javulást vagy sikeres teljesítést.

A három ellenőrzést szemléltető wrapper-váz. A költséglekérdezés és az ügynökindítás sorai futtatóspecifikus példák, nem ellenőrzött CLI-telepítési recept; átalakítás előtt igazold ezeket a felületeket a telepített verzióhoz. A commitalapú előrehaladás-ellenőrzéshez minden kódmódosító iteráció rögzítsen helyi ellenőrzőpont-commitot. Ha a futtató nem commitolt szerkesztéseket hagy, vizsgálat céljából állj le, ne minősítsd őket „előrehaladás hiányának”.

#!/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
  # Költségkorlát
  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

  # Futtatás
  OUTPUT=$(claude code -p "$PROMPT" --auto-accept)

  # Befejezés ellenőrzése
  if echo "$OUTPUT" | grep -q "$COMPLETION"; then
    echo "STOP: completion signal"
    break
  fi

  # Csak commitok: minden kódmódosító iteráció rögzítsen ellenőrzőpont-commitot.
  # A HEAD nem érzékeli a hasznos, nem commitolt szerkesztéseket.
  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

A váz bővítése előtt igazold az előrehaladás-ellenőrzést: a commit nélküli szerkesztést nem rögzített munkaként kell kezelni; az ellenőrzőpont-commit megváltoztatja a HEAD-et; sikert csak a külön verifier igazolhat. Három változatlan commit a megadott szerződés szerint nem rögzített változást jelez, nem bizonyítja az összes munkafájl változatlanságát. Ezután hozzáadhatsz például Slack-értesítést a leálláskor, reggeli automatikus Telegram-jelentést, vagy push-értesítést, amikor a keret eléri a 80%-ot. Az alapelv ugyanaz: egy ciklusnak fékekre van szüksége, nem csak gyorsítóra.

5 azonnal használható éjszakai ciklusforgatókönyv#

1. forgatókönyv: A hibás tesztek sikeressé tétele

/goal A tests/ könyvtárban 47 sikertelen teszt van. Cél: mindegyik menjen át.
Futtasd a pnpm test parancsot, olvasd el a stderr kimenetét, nyisd meg a hibás fájlt, javítsd ki, majd futtasd újra a pnpm test parancsot.
A 0-s kilépési kódnál állj le. Legfeljebb 30 iteráció.

2. forgatókönyv: Nagy refaktorálás 200 fájlon

/batch Cseréld le a régi apiV1 API-klienst az új apiV2-re a src/**/*.ts alatti összes fájlban.
Minden fájl saját worktree-t kap. A cserét követően futtasd a tsc --noEmit parancsot; javítsd ki a hibákat.
A végén egyesítsd a worktree-ket.

3. forgatókönyv: Éjszakai éles környezet-figyelés

/loop 30m 30 percenként ellenőrizd ezt: https://your-app.example.com/api/health.
Ha nem 200-as választ ad, olvasd el a naplókat, keresd meg az okot, javítsd ki, majd telepítsd újra.
Minden iterációt naplózz ide: /tmp/night-monitor.log.

4. forgatókönyv: Nagy adatkészlet importálása duplikációszűréssel

/goal Importáld a /tmp/import.csv fájlt (12,000 sor) a clients táblába.
Minden sornál ellenőrizd, van-e duplikáció az email alapján; ha nincs, szúrd be, ha van, frissítsd.
A konfliktusokat naplózd a /tmp/conflicts.log fájlba. Akkor állj le, ha az utolsó sor feldolgozása is befejeződött.

5. forgatókönyv: Cikkfolyamat (tipikus beállítás)

Egy olyan online szolgáltatás vagy ügynökség számára, amelynek rendszeresen szüksége van SEO-cikkekre, a forgatókönyv így néz ki:

/loop 8h 8 óránként: nyisd meg a backlog fájlt, és keresd meg a 'queued' állapotú témákat.
Ha van ilyen téma, futtasd az útmutató megírásához szükséges skillt.
Tedd közzé dev környezetben. Állítsd az állapotot 'review'-ra. Értesítsd a felelőst Telegramon.

Mit adj meg minden iterációban: a CLAUDE.md és a Second Brain mint állapot#

A projekt „memóriájának” három rétege az egyszeri promptot irányított ciklussá alakítja:

1. CLAUDE.md – a projekt alkotmánya. Mi a termék, milyen a stack, mik a szabályok, és mit tilos tenni. Claude minden munkamenet és ciklusiteráció indításakor elolvassa ezt a fájlt. Nélküle minden alkalommal „újra kell nyitnia” a projektet, ami kontextust fogyaszt és növeli a hallucináció kockázatát. Kész sablont és 6 szabályt találsz a CLAUDE.md útmutatóban.

2. Second Brain – az üzleti tudás mappája: termék, közönség, célok, gazdaságosság, marketing. Nem kód, hanem jelentés. Amikor a ciklus cikket ír, vagy támogatási kérdésre keres választ, beolvassa a Second Braint, és a projekt kontextusával, nem légüres térből válaszol.

3. Context engineering – pontosan azt adod meg Claude-nak minden iterációban, amire szüksége van. Nem a teljes Second Brain mappát, nem az egész tárolót, hanem csak a releváns részeket. A Plan Mode segít: Claude meghatározza, mely fájlokra van szüksége a feladathoz, és csak azokat olvassa el. További részletek a Plan Mode útmutatóban.

A fő működési elv, amelyet a saját hibáimból kellett megtanulnom:

Mindhárom réteg nélkül a ciklus végtelen körforgássá válik, egyre nagyobb számlával.

Mi található az egyes munkamenetekben? Különféle feladatok: az egyik ciklus hibákat javít, a másik új funkciókat ír, a harmadik a csapat PR-jeit ellenőrzi, a negyedik a teljesítményt optimalizálja, az ötödik pedig dokumentációt készít. Nem egyetlen nagy, általános célú ügynök. Tucatnyi specializált ügynök, mindegyik saját skillel, céllal és verifierrel.

A lényegi újragondolás:

Programozók nélküli vállalkozók számára ez kézzelfogható dolgot jelent. Van egy havi $200-os Claude-fiókod és egy átlagos laptopod. 5 ciklust futtathatsz párhuzamosan – ügyféltámogatást, cikkírást, metrikák követését, új termék tesztelését és versenytárs-figyelést. Mindegyik a saját Claude Code-lapján fut. Reggel elolvasod az összefoglalót. Ez 2026 nyarára már a munkavégzés normájává vált.

Az autonóm ciklusok négy gyakori hibája#

1. hiba: „Hallucinációs ciklus”

Az ügynök úgy dönt, hogy végzett, holott a verifier nem aktiválódott. Vagy egyáltalán nincs verifier. Három órával később Claude azt mondja: „Minden kész!” – de a tesztek hibásak, az oldal nem nyílik meg, és semmi sem működik. Már $80-t költöttél értelmetlen iterációkra.

Megoldás: szigorú verifier (a parancs exit code értéke), nem szóbeli ellenőrzés.

2. hiba: „Egy éjszaka alatt elégette a költségkeretet”

Költségkorlát nélkül a ciklus olyan, mint egy biztosítószeg nélküli gránát.

Megoldás: /usage limit vagy egy külső szkript, amely a claude usage --json segítségével leállítja a ciklust egy küszöbértéknél.

3. hiba: „A ciklus elveszítette a kontextust az iterációk között”

Az 1. iterációban Claude hozott egy architekturális döntést. A 7. iterációra elfelejtette, és az ellenkező döntést hozta. 15 iteráció után a kód egy nagy kupac.

Megoldás: állapotrögzítő réteg a CLAUDE.md és a Second Brain mappán keresztül. A ciklus fájlba írja minden architekturális döntését, amelyet a következő iterációban elolvas.

4. hiba: „Pontatlan a leállási feltétel – a ciklus örökké fut”

/goal "Tedd széppé az oldalt" – mit jelent az, hogy „szép”? Egyértelmű mérőszám nélkül a ciklus soha nem fog leállni. Addig fut, amíg el nem éri az iterációs vagy a költségkeretet.

Megoldás: a leállási feltételnek mindig mérhetőnek kell lennie. Ne az legyen, hogy „szép”, hanem „Lighthouse Performance ≥ 90, Accessibility ≥ 95”. Ne az, hogy „működik”, hanem „a tests/pricing.test.ts tesztjei sikeresek”.

Mikor nincs szükség loop engineeringre?#

Nem alkalmas autonóm ciklusra:

• Egyszeri kreatív feladat. Egy weboldal egy új termékhez, egy logó, egy stratégiai feljegyzés. Itt túlzás a ciklus; egyszerűbb megírni egy promptot, majd kézzel finomítani az eredményt.
• Verifier nélküli feladat. Ha nem tudod kilépési kóddal vagy egyértelmű jelzéssel megfogalmazni a leállási feltételt, ne indítsd el a ciklust, különben végtelen máglya lesz belőle.
• Szubjektív értékelést igénylő feladat. „Legyen jobban megfogalmazva”, „javítsd a UX-et, hogy kellemesebb legyen” – ezekhez te kellesz, nem egy ciklus.
• Új, ismeretlen terület. Ha te magad sem érted, hogyan néz ki a „kész”, ne futtasd Claude-ot ciklusban. Előbb értsd meg, aztán automatizáld.

És a fő szabály, amelyet a hibáimból tanultam meg:

A ciklus indítása előtti fő kérdés: Meg tudom fogalmazni egy sorban, honnan fogom tudni, hogy Claude végzett? Ha igen, a ciklus segíthet. Ha nem, előbb határozz meg ellenőrizhető feltételt, és csak utána indítsd el.

A loop engineering a Claude Code-ról már ismert tudásodra épülő réteg. Fedezd fel tovább az Ailootot itt: ailoot.ai.