Claude Code per naktį: loop engineering ir Ralph Loop 2026 m.

Ailoot informacinė dokumentacija: ailoot.ai/docs/.

Kas yra loop engineering ir kodėl tai turėtų rūpėti?#

Tame pačiame įraše jis cituoja išpopuliarėjusį Peterio Steinbergerio tviterio įrašą (2026 m. birželio 8 d.):

Antrasis teiginys paaiškina mastą:

Už šių teiginių slypi naujas inžinieriaus vaidmuo: esate ciklų architektas, o ne klaviatūros operatorius.

Padarykite tai vieną kartą šiandien, ir kasdien daugės potencialių klientų, straipsniai bus skelbiami automatiškai, botas tvarkys susirašinėjimą, o metrikų ataskaita pasieks jūsų stalą iki 9 val. Sukuriate sistemą, ir ji kasdien dirba be jūsų.

Jei vis dar atidarote Claude Code, parašote nurodymą, laukiate, skaitote ir parašote kitą nurodymą, praleidžiate didžiausią 2026 m. pokytį. Modeliai tapo pakankamai galingi, kad veiktų ciklais be priežiūros.

Kuo Ralph Loop skiriasi nuo įprastos Claude Code užklausos#

Ši technika yra paprastas bash ciklas aplink agentą:

Pradinis kodas, sukėlęs visą šią bangą:

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

Vienas nurodymas faile ir begalinis ciklas aplink jį. O štai atviriausias autoriaus komentaras:

Anthropic tą pačią logiką įdiegė papildinyje ralph-loop ir Claude Code komandose /loop, /goal bei /batch — jas galima naudoti tiesiog terminale, be scenarijų. Vien tai, kad Anthropic išleido begalinio pakartotinio nurodymų pateikimo papildinį, sukėlė diskusiją „GitHub Issue #23084“ apie tai, ar tai sąžininga modelio atžvilgiu. Diskusija tebevyksta; papildinys veikia.

Trys integruotos Claude Code komandos: /loop, /goal, /batch#

/goal labiausiai primena Ralph Loop. Viduje vertinimo modelis (pagal numatytuosius nustatymus Haiku) kiekviename ėjime tikrina, ar tikslas pasiektas. Jei ne, kitai iteracijai pateikiama užuomina, ką tiksliai pataisyti. Jei taip, darbas sustabdomas. Išsamiai apie /goal rašiau vadove apie autonominį Claude Code paleidimą per naktį naudojant /goal — jame pateikti paruošti naudoti 14 valandų darbo scenarijai.

/batch — reta, bet galinga komanda. Kai reikia atlikti tą patį pakeitimą daugiau nei 100 failų (API migracija, komponentų pakeitimas, pervadinimas), /batch kiekvieną failą perduoda atskiram subagentui jo paties git worktree. Pakeitimai nesikerta — kiekvienas agentas dirba izoliuotoje kopijoje. Daugiau apie subagentus skaitykite vadove apie įdėtinius subagentus.

Autorius šį metodą apibūdina paprastai:

Griežti /loop ir /goal apribojimai:

• Užduotis vykdoma tol, kol Claude Code yra atidarytas. Uždarykite terminalą ir ciklas sustos. Rimtam naktiniam ciklui naudokite nuotolinį serverį arba savo shell wrapper.
• Maksimali pasikartojančios užduoties trukmė yra 7 dienos (po to ji automatiškai pašalinama kaip apsauga nuo pamirštų ciklų).
• Vienoje sesijoje gali būti iki 50 vienu metu vykdomų užduočių.

Kaip per 5 minutes paleisti pirmą autonominį ciklą#

5 žingsniai:

1. Atidarykite projektą Claude Code

   Terminale pereikite į projekto šakninį katalogą ir paleiskite claude. Palaukite, kol Claude perskaitys CLAUDE.md ir suindeksuos saugyklą.

2. Apibrėžkite tikslą ir sustabdymo sąlygą

   Tikslas nusako, ką reikia atlikti. Sustabdymo sąlyga nusako, kaip Claude supras, kad baigė. Geriausia, jei tai komanda, grąžinanti 0 arba 1. Pavyzdys: „Tikslas: turi praeiti visi 23 testai faile tests/api/*.test.ts. Sustokite, kai pnpm test grąžins exit 0.“

3. Paleiskite /goal

   Komanda:

   /goal Turi praeiti visi testai faile tests/api/*.test.ts. Paleiskite pnpm test, perskaitykite klaidas, jas ištaisykite ir paleiskite dar kartą. Sustokite, kai išėjimo kodas = 0. Daugiausia 20 iteracijų.
   

   Claude pradeda ciklą: paleidžia testus — pamato nesėkmę — atidaro failą — pataiso — paleidžia juos dar kartą.

4. Nustatykite biudžeto ribą

   Fone atidarytame skirtuke naudokite /usage ir stebėkite sąnaudas. Nustatykite dienos tokenų arba pinigų limitą, kad per vieną ciklą neišeikvotumėte viso savo likučio. Daugiau informacijos rasite vadove apie tai, kaip neišeikvoti Claude Code limitų.

5. Užsiimkite savo reikalais

   Grįžkite po 30 minučių. Jei užduotis paprasta, jau matysite „DONE, visi testai praėjo“. Jei ji sudėtingesnė, perskaitykite ataskaitą: „sustabdyta per 20 iteraciją, priežastis X“. Rankomis pataisykite tai, ko ciklui nepavyko atlikti, ir paleiskite jį iš naujo.

Tikrintuvo šablonas: kaip Claude ciklu tikrina savo darbą#

Yra trys tikrintuvų tipai:

1. Techninis (išėjimo kodas) — patikimiausias. pnpm test, npm run lint, tsc --noEmit, playwright test. Jie grąžina 0 arba 1, todėl nieko nereikia interpretuoti. Taip pat veikia ir /goal — viduje naudojamas Haiku vertinimo modelis, kuris kiekviename ėjime tikrina, ar įvykdyta sąlyga (iki 4000 simbolių).

2. Vertinimo modelis — antras modelis peržiūri pirmojo modelio rezultatą ir įvertina jį pagal kriterijus. Tinka užduotims, kurių neįmanoma patikrinti formaliai („Ar rašymo stilius geras?“ „Ar dizainas atitinka prekės ženklą?“). Anthropic tai vadina Claude Code Review — režimu, kai atskiras peržiūros agentas pagrindinio agento darbe ieško loginių klaidų, ribinių atvejų ir saugumo problemų. Remiantis vidiniais Anthropic duomenimis, jis aptinka 84 % problemų dideliuose PR (palyginti su 16 % taikant bazinį metodą).

3. Pasirinktinė patikra — jūsų pačių parašytas shell script. „Jei žurnaluose nėra žodžio ERROR, užduotis atlikta.“ „Jei failas output.json egzistuoja ir jį galima išanalizuoti, užduotis atlikta.“ „Jei puslapis /pricing grąžina 200, užduotis atlikta.“

Autoriaus metode įgūdžiai apima atskirą priešišką Claude patikrą po kiekvieno etapo. Štai nurodymo šablonas, kurį įrašau į CLAUDE.md arba komandą:

Raskite 10 priežasčių, dėl kurių šis projektas galėjo visiškai žlugti. 
Įsivaizduokite, kad kažkas nutiko ne taip. 
Šią istoriją galiu peržiūrėti daugybę kartų – 
prieš paskelbdamas ją viešai.

Dažniausia pradedančiųjų klaida — paleisti ciklą be tikrintuvo. Agentas sukasi vietoje: rašo kodą, jo netikrina, mano, kad baigė, pereina prie kitos iteracijos ir perrašo tai, ką jau padarė. Po trijų valandų viskas virsta chaosu, o sąskaita siekia $200.

Geriausia taisyklė, kurią išmokau: pirmiausia parašykite tikrintuvą, o tada paleiskite ciklą. Jei negalite vienu sakiniu nusakyti sustabdymo sąlygos, užduotis dar neparuošta autonominiam vykdymui.

Kaip neišleisti tūkstančių dolerių per naktį: biudžeto ribos ir sustabdymo sąlygos#

Trys būtini stabdžiai kiekvienam naktiniam ciklui:

1. Iteracijų limitas. --max-iterations 20. Ciklas negali veikti daugiau nei N kartų — net jei tikrintuvas nesuveikia. Jei po 20 iteracijų nepasiekta sustabdymo sąlyga, užduotis įstrigo ir reikia žmogaus įsikišimo.

2. Tokenų arba pinigų limitas. /usage limit 50 — ne daugiau kaip $50 per dieną. Artėdamas prie ribos ciklas sustoja pats ir išsiunčia įspėjimą. Taip apsisaugoma nuo nekontroliuojamo scenarijaus.

3. Pažangos patikra su aiškiu susitarimu. Toliau pateiktas HEAD palyginimas aptinka naujus įrašus, o ne visus kodo pakeitimus. Jį naudokite tik izoliuotoje darbo kopijoje, kur kiekviena kodą keičianti iteracija prieš palyginimą išsaugo vietinį kontrolinio taško įrašą. Naudingi neįrašyti pakeitimai nekeičia HEAD; be tokio susitarimo nepakitęs maišos kodas gali klaidingai signalizuoti stagnaciją. Taip pat išsaugokite tikrintuvo rezultatą: naujas įrašas įrodo užfiksuotą pakeitimą, bet ne užduoties pagerėjimą ar sėkmę.

Pavyzdinė wrapper struktūra su šiomis trimis patikromis. Išlaidų ataskaitos ir agento iškvietimo eilutės yra konkrečiam vykdytojui skirti pavyzdžiai, o ne patikrintas CLI diegimo receptas; prieš pritaikydami patvirtinkite šias įdiegtos versijos sąsajas. Įrašais pagrįstai pažangos patikrai reikalaukite vietinio kontrolinio taško įrašo po kiekvienos kodą keičiančios iteracijos. Jei vykdytojas palieka neįrašytų pakeitimų, sustokite peržiūrai, užuot vadinę tai pažangos nebuvimu.

#!/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
  # Pinigų limitas
  CURRENT_COST=$(claude usage --json | jq '.cost_usd')
  if (( $(echo "$CURRENT_COST > $MAX_COST_USD" | bc -l) )); then
    echo "STOP: pasiekta biudžeto riba $MAX_COST_USD"
    break
  fi

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

  # Užbaigimo patikra
  if echo "$OUTPUT" | grep -q "$COMPLETION"; then
    echo "STOP: užbaigimo signalas"
    break
  fi

  # Tik įrašų pažanga: kiekviena kodą keičianti iteracija turi išsaugoti įrašą.
  # HEAD neaptinka naudingų pakeitimų, kurie dar neįrašyti.
  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: stagnacija 3 iteracijas"
      break
    fi
  else
    STAGNATION=0
  fi
  PREV_HASH="$CURRENT_HASH"
done

Prieš plėsdami šį karkasą patikrinkite pažangos patikrą: pakeitimą be įrašo reikia laikyti neužfiksuotu darbu; kontrolinio taško įrašas pakeičia HEAD; tik atskiras tikrintuvas gali patvirtinti sėkmę. Trys nepakitę įrašai pagal nurodytą susitarimą reiškia, kad neužfiksuota pakeitimų, bet neįrodo, kad visi darbiniai failai liko tokie patys. Vėliau galite pridėti „Slack“ įspėjimą ciklui sustojus, automatinę rytinę ataskaitą per „Telegram“ ir push pranešimą, kai biudžetas pasiekia 80 %. Principas tas pats: ciklui reikia stabdžių, ne vien greičio pedalo.

5 paruošti naudoti naktinių ciklų scenarijai#

1 scenarijus: pataisykite, kad nepraeinantys testai praeitų

/goal Kataloge tests/ yra 47 nepraeinantys testai. Tikslas: priverskite juos visus praeiti.
Paleiskite pnpm test, perskaitykite stderr, atidarykite failą su klaida, ją pataisykite ir vėl paleiskite pnpm test.
Sustokite, kai išėjimo kodas bus 0. Daugiausia 30 iteracijų.

2 scenarijus: didelis 200 failų refaktoringas

/batch Visuose failuose, esančiuose po `src/**/*.ts`, seną apiV1 API klientą pakeiskite nauju apiV2.
Kiekvienam failui priskirkite atskirą worktree. Pakeitę paleiskite tsc --noEmit; ištaisykite visas klaidas.
Pabaigoje sujunkite worktree.

3 scenarijus: naktinis produkcinės aplinkos stebėjimas

/loop 30m Kas 30 minučių patikrinkite https://your-app.example.com/api/health.
Jei atsakymas nėra 200, perskaitykite žurnalus, raskite priežastį, ją ištaisykite ir įdiekite iš naujo.
Kiekvieną iteraciją įrašykite į /tmp/night-monitor.log.

4 scenarijus: didelio duomenų rinkinio importavimas pašalinant dublikatus

/goal Importuokite CSV failą /tmp/import.csv (12,000 eilučių) į lentelę clients.
Kiekvienoje eilutėje pagal el. paštą patikrinkite, ar yra dublikatas; jei nėra, įterpkite, o jei yra, atnaujinkite.
Konfliktus įrašykite į /tmp/conflicts.log. Sustokite apdoroję paskutinę eilutę.

5 scenarijus: straipsnių procesas (tipinė sąranka)

Internetinei paslaugai ar agentūrai, kuriai reguliariai reikia SEO straipsnių, scenarijus atrodytų taip:

/loop 8h Kas 8 valandas atidarykite užduočių sąrašo failą ir raskite temas, kurių būsena yra 'queued'.
Jei tema yra, paleiskite vadovų rašymo įgūdį.
Paskelbkite dev. Pakeiskite būseną į 'review'. Praneškite atsakingam asmeniui per Telegram.

Ką pateikti kiekvienoje iteracijoje: CLAUDE.md ir Second Brain kaip būsena#

Trys projekto „atminties“ sluoksniai vienkartinį nurodymą paverčia valdomu ciklu:

1. CLAUDE.md — projekto konstitucija. Kas yra produktas, koks jo technologijų rinkinys, kokios taisyklės ir ko niekada negalima daryti. Pradėdamas kiekvieną sesiją ir kiekvieną ciklo iteraciją Claude perskaito šį failą. Be jo Claude kaskart turi „iš naujo atidaryti“ projektą — eikvojamas kontekstas ir didėja haliucinacijų rizika. Paruoštą šabloną ir 6 taisykles rasite vadove CLAUDE.md.

2. Second Brain — verslo žinių aplankas: produktas, auditorija, tikslai, ekonomika, rinkodara. Ne kodas — prasmė. Kai ciklas rašo straipsnį arba ieško atsakymo klientų aptarnavimui, jis perskaito Second Brain ir atsako remdamasis projekto kontekstu, o ne iš tuštumos.

3. Context engineering — ką tiksliai pateikiate Claude kiekvienoje iteracijoje. Ne visą Second Brain aplanką, ne visą saugyklą — tik tai, kas aktualu. Padeda Plan Mode: Claude nustato, kurių failų reikia užduočiai, ir perskaito tik juos. Daugiau informacijos rasite vadove Plan Mode.

Pagrindinis praktinis principas, kurį teko įsisąmoninti per klaidas:

Be visų trijų sluoksnių ciklas virsta nesibaigiančiu ciklu, kurio sąskaita nuolat auga.

Kas vyksta kiekvienoje sesijoje? Skirtingos užduotys: vienas ciklas taiso klaidas, kitas rašo naujas funkcijas, trečias peržiūri komandos PR, ketvirtas optimizuoja našumą, penktas rengia dokumentaciją. Ne vienas didelis bendrosios paskirties agentas. Dešimtys specializuotų agentų, kiekvienas turintis savo skill, tikslą ir tikrintuvą.

Svarbiausias požiūrio pokytis:

Verslininkui, neturinčiam programuotojų, tai reiškia štai ką. Turite vieną Claude paskyrą už $200 per mėnesį ir įprastą nešiojamąjį kompiuterį. Galite paleisti 5 ciklus lygiagrečiai — klientų aptarnavimo, straipsnių, metrikų, naujo produkto testavimo ir konkurentų stebėjimo. Kiekvienas veikia atskirame Claude Code skirtuke. Ryte perskaitote santrauką. 2026 m. vasarą tai jau yra įprastas darbo būdas.

Keturios dažnos autonominių ciklų nesėkmės#

1 nesėkmė: „Haliucinacijų ciklas“

Agentas nusprendžia, kad baigė, nors tikrintuvas nesuveikė. Arba tikrintuvo išvis nėra. Po trijų valandų Claude sako: „Viskas atlikta!“ — bet testai nepraeina, puslapis neatsidaro ir niekas neveikia. Jau išleidote $80 beprasmiškoms iteracijoms.

Sprendimas: griežtas tikrintuvas (komandos exit code), o ne žodinis patvirtinimas.

2 nesėkmė: „Biudžetas išeikvotas per naktį“

Be biudžeto ribos ciklas yra granata be žiedo.

Sprendimas: /usage limit arba išorinis scenarijus, naudojantis claude usage --json, kuris sustabdo ciklą pasiekus ribą.

3 nesėkmė: „Tarp iteracijų ciklas prarado kontekstą“

1 iteracijoje Claude priėmė architektūrinį sprendimą. Iki 7 iteracijos jis jį pamiršo ir priėmė priešingą sprendimą. Po 15 iteracijų kodas yra betvarkė.

Sprendimas: būsenos sluoksnis per CLAUDE.md ir Second Brain aplanką. Ciklas įrašo kiekvieną architektūrinį sprendimą į failą, kurį perskaito kitoje iteracijoje.

4 nesėkmė: „Sustabdymo sąlyga neaiški — ciklas veikia amžinai“

/goal "Padaryk puslapį gražų" — ką reiškia „gražų“? Neturėdamas aiškios metrikos, ciklas niekada nesustos. Jis veiks, kol pasieks iteracijų arba biudžeto limitą.

Sprendimas: sustabdymo sąlyga visada turi būti išmatuojama. Ne „gražus“, o „Lighthouse Performance ≥ 90, Accessibility ≥ 95“. Ne „veikia“, o „testai faile tests/pricing.test.ts praeina“.

Kada loop engineering nereikalingas#

Autonominis ciklas netinka:

• Vienkartinei kūrybinei užduočiai. Viena svetainė naujam produktui, vienas logotipas, vienas strateginis memorandumas. Ciklas čia būtų perteklinis; paprasčiau parašyti vieną nurodymą ir rezultatą patobulinti rankomis.
• Užduočiai be tikrintuvo. Jei negalite sustabdymo sąlygos išreikšti išėjimo kodu arba nedviprasmišku signalu, nepradėkite ciklo, kitaip tai taps nesibaigiančiu laužu.
• Užduočiai, kuriai reikia subjektyvaus vertinimo. „Padaryk, kad skambėtų geriau“, „pagerink UX, kad juo būtų maloniau naudotis“ — tam reikia jūsų, o ne ciklo.
• Naujai, nepažįstamai sričiai. Jei patys nesuprantate, kaip turi atrodyti „atlikta“, neleiskite Claude veikti ciklu. Pirma išsiaiškinkite, o tada automatizuokite.

Ir pagrindinė taisyklė, kurią išmokau per klaidas:

Pagrindinis klausimas prieš paleidžiant ciklą: Ar galiu vienu sakiniu apibūdinti, kaip suprasiu, kad Claude baigė? Jei taip, ciklas gali padėti. Jei ne, pirmiausia apibrėžkite patikrinamą sąlygą ir tik tada pradėkite.

Loop engineering yra sluoksnis, papildantis visa tai, ką jau žinote apie Claude Code. Be visų trijų sluoksnių ciklas pradeda prastėti jau per 5 iteraciją. Toliau susipažinkite su Ailoot svetainėje ailoot.ai.