Claude Code przez noc: inżynieria pętli i Ralph Loop w 2026 roku

Dokumentacja referencyjna Ailoot: ailoot.ai/docs/.

Czym jest inżynieria pętli i dlaczego warto się nią zainteresować?#

W tym samym wpisie cytuje wiralowy tweet Petera Steinbergera (8 czerwca 2026 roku):

Druga wypowiedź pokazuje skalę:

Za tymi wypowiedziami kryje się nowa rola inżyniera: jesteś architektem pętli, a nie operatorem klawiatury.

Zrób to raz dzisiaj, a każdego dnia będzie przybywać potencjalnych klientów, artykuły będą publikowane automatycznie, bot będzie obsługiwał korespondencję, a raport z metrykami trafi na Twoje biurko przed 9 rano. Zbudujesz system, który będzie działał każdego dnia bez Ciebie.

Jeśli nadal otwierasz Claude Code, wpisujesz prompt, czekasz, czytasz i wpisujesz kolejny prompt, omija Cię największa zmiana 2026 roku. Modele stały się wystarczająco potężne, by pracować w pętlach bez nadzoru.

Czym Ralph Loop różni się od zwykłego polecenia dla Claude Code#

W swej istocie technika ta polega na prostej pętli bash wokół agenta:

Oryginalny kod, który zapoczątkował całą falę:

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

Jeden prompt w pliku i nieskończona pętla wokół niego. A najbardziej szczery komentarz autora:

Anthropic opakowało tę samą logikę wtyczką ralph-loop oraz poleceniami /loop, /goal i /batch w Claude Code — są dostępne bezpośrednio w terminalu, bez skryptów. Sam fakt, że Anthropic udostępniło wtyczkę do nieskończonego ponawiania promptów, wywołał dyskusję w GitHub Issue #23084 o tym, czy jest to uczciwe wobec modelu. Dyskusja trwa; wtyczka działa.

Trzy wbudowane polecenia Claude Code: /loop, /goal, /batch#

/goal jest poleceniem najbardziej zbliżonym do Ralph Loop. Pod maską model oceniający (domyślnie Haiku) sprawdza w każdej turze, czy cel został osiągnięty. Jeśli nie, następna iteracja otrzymuje wskazówkę, co dokładnie poprawić. Jeśli tak, pętla się zatrzymuje. Szczegółowo opisałem /goal w poradniku o autonomicznym uruchamianiu Claude Code przez noc za pomocą /goal — znajdziesz tam gotowe scenariusze na 14 godzin pracy.

/batch to rzadkie, ale potężne polecenie. Gdy musisz wprowadzić tę samą zmianę w ponad 100 plikach (migracja API, zamiana komponentów, zmiana nazw), /batch przekazuje każdy plik osobnemu subagentowi w jego własnym git worktree. Zmiany nie kolidują ze sobą, ponieważ każdy agent pracuje na odizolowanej kopii. Więcej o subagentach przeczytasz w poradniku o zagnieżdżonych subagentach.

W opisie autora to podejście nazywa się po prostu:

Twarde limity dla /loop i /goal:

• Zadanie działa tak długo, jak otwarty jest Claude Code. Zamknij terminal, a pętla przestanie działać. Przy poważnym cyklu nocnym użyj zdalnego serwera lub własnej otoczki shellowej.
• Maksymalny czas działania zadania cyklicznego to 7 dni (po tym czasie zostaje automatycznie usunięte, aby chronić przed zapomnianymi pętlami).
• W jednej sesji może działać jednocześnie maksymalnie 50 zadań.

Chcesz zbudować konfigurację, która sprawi, że Claude będzie niezawodny? Ralph Loop to tylko jeden z jej elementów. Warto uwzględnić wszystkie trzy składniki: klon AI + Second Brain + Context Engineering — to połączenie zmienia Claude z „asystenta, który halucynuje” w narzędzie, któremu możesz zlecić zadanie i zająć się swoimi sprawami.

Jak uruchomić pierwszą autonomiczną pętlę w 5 minut#

5 kroków:

1. Otwórz projekt w Claude Code

   W terminalu przejdź do katalogu głównego projektu i uruchom claude. Poczekaj, aż Claude odczyta CLAUDE.md i zaindeksuje repozytorium.

2. Określ cel i warunek zatrzymania

   Cel określa, co należy zrobić. Warunek zatrzymania mówi, skąd Claude będzie wiedział, że skończył. Najlepiej, jeśli jest to polecenie zwracające 0 lub 1. Przykład: „Cel: wszystkie 23 testy w tests/api/*.test.ts mają przejść. Zatrzymaj się, gdy pnpm test zwróci kod wyjścia 0.”

3. Uruchom /goal

   Polecenie:

   /goal All tests in tests/api/*.test.ts must pass. Run pnpm test, read the errors, fix them, and run it again. Stop when the exit code = 0. Maximum 20 iterations.
   

   Claude uruchamia pętlę: przeprowadza testy, wykrywa błąd, otwiera plik, poprawia go i ponownie uruchamia testy.

4. Ustaw limit budżetu

   W karcie działającej w tle użyj /usage, aby monitorować zużycie. Ustaw dzienny limit tokenów lub wydatków, żeby nie zużyć całego salda na jednej pętli. Więcej szczegółów znajdziesz w poradniku jak nie wyczerpać limitów Claude Code.

5. Zajmij się swoimi sprawami

   Wróć za 30 minut. Jeśli zadanie jest proste, powinien już wyświetlać się komunikat „DONE, wszystkie testy przechodzą”. Jeśli jest bardziej złożone, przeczytaj raport: „zatrzymano na iteracji 20, powód X”. Ręcznie popraw to, czego pętla nie zdołała zrobić, a potem uruchom ją ponownie.

Wzorzec weryfikatora: jak Claude sprawdza własną pracę w pętli#

Są trzy rodzaje weryfikatorów:

1. Techniczny (kod wyjścia) — najbardziej niezawodny. pnpm test, npm run lint, tsc --noEmit, playwright test. Zwracają 0 lub 1, bez potrzeby interpretacji. W ten sposób działa również /goal — pod maską korzysta z modelu oceniającego Haiku, który w każdej turze sprawdza, czy warunek został spełniony (do 4000 znaków).

2. Model oceniający — drugi model analizuje wynik pierwszego i ocenia go według kryteriów. To dobre rozwiązanie do zadań bez formalnej kontroli („Czy styl tekstu jest dobry?”, „Czy projekt pasuje do marki?”). W Anthropic nazywa się to Claude Code Review — tryb, w którym osobny agent recenzujący szuka błędów logicznych, przypadków brzegowych i problemów z bezpieczeństwem w pracy głównego agenta. Według wewnętrznych danych Anthropic wykrywa 84% problemów w dużych PR-ach (w porównaniu z 16% w podejściu bazowym).

3. Własna kontrola — skrypt shellowy, który piszesz samodzielnie. „Jeśli w logach nie ma słowa ERROR, zadanie jest gotowe”. „Jeśli plik output.json istnieje i można go sparsować, zadanie jest gotowe”. „Jeśli strona /pricing zwraca 200, zadanie jest gotowe”.

W podejściu autora umiejętności obejmują osobny, adwersarialny przegląd Claude po każdej fazie. Oto szablon promptu, który umieszczam w CLAUDE.md lub w poleceniu:

Znajdź 10 powodów, dla których ten projekt mógł pójść fatalnie źle.
Załóż, że coś poszło nie tak.
Mogę wielokrotnie przeanalizować ten scenariusz przed udostępnieniem go publicznie.

Najczęstszym błędem początkujących jest uruchomienie pętli bez weryfikatora. Agent kręci się w kółko: pisze kod, nie sprawdza go, uznaje zadanie za zakończone, przechodzi do kolejnej iteracji i przepisuje to, co już zrobił. Trzy godziny później panuje chaos, a rachunek wynosi $200.

Najlepsza zasada: najpierw napisz weryfikator, potem uruchom pętlę. Jeśli nie potrafisz opisać warunku zatrzymania jednym wierszem, zadanie nie jest jeszcze gotowe do autonomicznej realizacji.

Jak nie wydać tysięcy dolarów przez noc: limity budżetu i warunki zatrzymania#

Trzy niezbędne hamulce dla każdej nocnej pętli:

1. Limit iteracji. --max-iterations 20. Pętla nie wykona więcej niż N powtórzeń — nawet jeśli weryfikator się nie uruchomi. Jeśli po 20 iteracjach nie osiągnie warunku zatrzymania, zadanie utknęło i wymaga interwencji człowieka.

2. Limit tokenów lub wydatków. /usage limit 50 — maksymalnie $50 dziennie. Gdy pętla zbliży się do limitu, zatrzyma się sama i wyśle alert. Chroni to przed niekontrolowanym scenariuszem.

3. Sprawdzanie postępu z wyraźną umową. Poniższe porównanie HEAD wykrywa nowe commity, a nie wszystkie zmiany kodu. Używaj go tylko w izolowanym worktree, w którym każda iteracja zmieniająca kod zapisuje lokalny commit kontrolny przed porównaniem. Przydatne niezacommitowane zmiany nie zmieniają HEAD; bez tej umowy niezmieniony hash może fałszywie sygnalizować zastój. Zachowuj też wynik weryfikatora: nowy commit potwierdza zapis zmiany, a nie poprawę ani zaliczenie zadania.

Przykładowa struktura skryptu opakowującego z tymi trzema sprawdzeniami. Raportowanie kosztu i wywołanie agenta zależą od programu wykonawczego; nie jest to sprawdzona recepta instalacji CLI. Przed adaptacją potwierdź te interfejsy w zainstalowanej wersji. Sprawdzanie postępu przez commity wymaga lokalnego commita kontrolnego dla każdej iteracji zmieniającej kod. Gdy program zostawia niezacommitowane zmiany, zatrzymaj się do przeglądu zamiast oznaczać je jako „brak postępu”.

#!/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
  # Limit wydatków
  CURRENT_COST=$(claude usage --json | jq '.cost_usd')
  if (( $(echo "$CURRENT_COST > $MAX_COST_USD" | bc -l) )); then
    echo "STOP: osiągnięto limit budżetu $MAX_COST_USD"
    break
  fi

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

  # Sprawdzenie ukończenia
  if echo "$OUTPUT" | grep -q "$COMPLETION"; then
    echo "STOP: sygnał ukończenia"
    break
  fi

  # Tylko postęp commitów: każda iteracja zmieniająca kod musi zapisać commit kontrolny.
  # HEAD nie wykrywa przydatnych zmian pozostawionych bez commita.
  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: zastój przez 3 iteracje"
      break
    fi
  else
    STAGNATION=0
  fi
  PREV_HASH="$CURRENT_HASH"
done

Przed rozbudową szkieletu sprawdź wykrywanie postępu: edycję bez commita traktuj jako niezapisane zmiany robocze; commit kontrolny zmienia HEAD; tylko osobny weryfikator może potwierdzić sukces. Trzy porównania z niezmienionym HEAD oznaczają brak zapisanych zmian według tej umowy, a nie dowód niezmienności wszystkich plików roboczych. Następnie możesz dodać powiadomienie w Slacku po zatrzymaniu pętli, automatyczny raport w Telegramie rano oraz powiadomienie push, gdy budżet osiągnie 80%. Zasada jest taka sama: pętla potrzebuje hamulców, a nie tylko akceleratora.

5 gotowych scenariuszy nocnych pętli#

Scenariusz 1: przeprowadzenie nieudanych testów

/goal There are 47 failing tests in the tests/ directory. Goal: make them all pass.
Run pnpm test, read stderr, open the file with the error, fix it, and run pnpm test again.
Stop when exit 0. Max 30 iterations.

Scenariusz 2: duża refaktoryzacja obejmująca 200 plików

/batch Replace the old apiV1 API client with the new apiV2 in all files under src/**/*.ts.
Each file gets its own worktree. After the replacement, run tsc --noEmit; fix any errors.
Merge the worktrees at the end.

Scenariusz 3: nocne monitorowanie środowiska produkcyjnego

/loop 30m Every 30 minutes, check https://your-app.example.com/api/health.
If it doesn't return 200, read the logs, find the cause, fix it, and redeploy.
Log each iteration to /tmp/night-monitor.log.

Scenariusz 4: import dużego zbioru danych z deduplikacją

/goal Import the CSV file /tmp/import.csv (12,000 rows) into the clients table.
For each row, check for a duplicate by email; if none, insert it; if one exists, update it.
Log conflicts to /tmp/conflicts.log. Stop when the last row has been processed.

Scenariusz 5: przepływ artykułów (typowa konfiguracja)

W przypadku serwisu internetowego lub agencji, która regularnie potrzebuje artykułów SEO, scenariusz wygląda tak:

/loop 8h Every 8 hours: open the backlog file for topics with status 'queued'.
If a topic is available, run the skill for writing a guide.
Publish to dev. Change the status to 'review'. Notify the person responsible in Telegram.

Co przekazywać w każdej iteracji: CLAUDE.md i Second Brain jako stan#

Trzy warstwy „pamięci” projektu zmieniają jednorazowy prompt w kontrolowaną pętlę:

1. CLAUDE.md — konstytucja projektu. Zawiera informacje o produkcie, stosie technologicznym, zasadach i tym, czego nigdy nie wolno robić. Claude odczytuje ten plik na początku każdej sesji i każdej iteracji pętli. Bez niego musi za każdym razem „otwierać” projekt na nowo — zużywa wtedy kontekst, a ryzyko halucynacji rośnie. Gotowy szablon i 6 zasad znajdziesz w poradniku CLAUDE.md.

2. Second Brain — folder z wiedzą o firmie: produkcie, odbiorcach, celach, ekonomii i marketingu. Nie chodzi o kod, lecz o znaczenie. Gdy pętla pisze artykuł albo szuka odpowiedzi dla działu wsparcia, odczytuje Second Brain i odpowiada, uwzględniając kontekst projektu, zamiast działać w próżni.

3. Inżynieria kontekstu — określa, co dokładnie przekazujesz Claude'owi w każdej iteracji. Nie cały folder Second Brain ani całe repozytorium — tylko to, co jest istotne. Pomaga Plan Mode: Claude ustala, których plików potrzebuje do zadania, i czyta tylko te pliki. Więcej informacji znajdziesz w poradniku Plan Mode.

Najważniejsza zasada operacyjna, którą musiałem sobie wbić do głowy przez błędy:

Te trzy warstwy tworzą trzy filary tej metody: klon AI (uczysz Claude'a swojego stylu i zasad za pomocą umiejętności i CLAUDE.md), Second Brain (kontekst biznesowy zapisany w plikach) oraz Context Engineering (to, co przekazujesz w każdym żądaniu). Bez wszystkich trzech pętla staje się nieskończonym cyklem, a rachunek rośnie.

Co dzieje się w każdej sesji? Różne zadania: jedna pętla naprawia błędy, druga tworzy nowe funkcje, trzecia sprawdza PR-y zespołu, czwarta optymalizuje wydajność, a piąta przygotowuje dokumentację. To nie jeden duży agent do wszystkiego. To dziesiątki wyspecjalizowanych agentów, każdy z własną umiejętnością, celem i weryfikatorem.

Najważniejsza zmiana perspektywy:

Dla przedsiębiorcy bez programistów oznacza to coś konkretnego. Masz jedno konto Claude za $200 miesięcznie i zwykły laptop. Możesz uruchomić 5 pętli równolegle — obsługę klienta, artykuły, metryki, testowanie nowego produktu i monitorowanie konkurencji. Każda działa we własnej karcie Claude Code. Rano czytasz podsumowanie. To już standard pracy latem 2026 roku.

Cztery częste awarie autonomicznych pętli#

Awaria 1: „Pętla halucynacji”

Agent uznaje, że skończył, mimo że weryfikator się nie uruchomił. Albo w ogóle nie ma weryfikatora. Po trzech godzinach Claude mówi: „Gotowe!” — ale testy nie przechodzą, strona się nie otwiera i nic nie działa. Masz już $80 wydane na bezcelowe iteracje.

Rozwiązanie: rygorystyczny weryfikator (kod exit code polecenia), a nie słowna kontrola.

Awaria 2: „Budżet wypalony przez noc”

Bez limitu budżetu pętla staje się granatem bez zawleczki.

Rozwiązanie: /usage limit albo zewnętrzny skrypt korzystający z claude usage --json, który zatrzyma pętlę po osiągnięciu progu.

Awaria 3: „Pętla utraciła kontekst między iteracjami”

W iteracji 1 Claude podjął decyzję architektoniczną. Do iteracji 7 zapomniał o niej i podjął przeciwną decyzję. Po 15 iteracjach kod jest zlepkiem przypadkowych zmian.

Rozwiązanie: warstwa stanu oparta na CLAUDE.md i folderze Second Brain. Pętla zapisuje każdą decyzję architektoniczną do pliku, który odczyta w następnej iteracji.

Awaria 4: „Nieprecyzyjny warunek zatrzymania — pętla działa bez końca”

/goal "Make the page beautiful" — co oznacza „piękna”? Bez jednoznacznej miary pętla nigdy się nie zatrzyma. Będzie działać aż do osiągnięcia limitu iteracji lub budżetu.

Rozwiązanie: warunek zatrzymania zawsze musi być mierzalny. Nie „piękna”, lecz „Lighthouse Performance ≥ 90, Accessibility ≥ 95”. Nie „działa”, lecz „testy w tests/pricing.test.ts przechodzą”.

Kiedy inżynieria pętli nie jest potrzebna#

Autonomiczna pętla nie nadaje się do:

• Jednorazowego zadania twórczego. Jedna witryna dla nowego produktu, jedno logo, jedno memorandum strategiczne. Pętla jest tu przesadą; łatwiej napisać jeden prompt i dopracować wynik ręcznie.
• Zadania bez weryfikatora. Jeśli nie potrafisz wyrazić warunku zatrzymania jako kodu wyjścia lub jednoznacznego sygnału, nie uruchamiaj pętli — w przeciwnym razie będzie to niekończące się ognisko.
• Zadania wymagającego subiektywnej oceny. „Niech brzmi lepiej”, „popraw UX, żeby był przyjemniejszy” — do tego potrzebujesz siebie, a nie pętli.
• Nowej, nieznanej dziedziny. Jeśli sam nie rozumiesz, jak powinno wyglądać „gotowe”, nie uruchamiaj Claude'a w pętli. Najpierw zdobądź wiedzę, potem automatyzuj.

A oto główna zasada, której nauczyłem się na błędach:

Najważniejsze pytanie przed uruchomieniem pętli brzmi: Czy potrafię opisać jednym zdaniem, po czym poznam, że Claude skończył? Jeśli tak, pętla może pomóc. Jeśli nie, najpierw określ weryfikowalny warunek, a dopiero potem ją uruchom.

Inżynieria pętli to warstwa nakładana na wszystko, co już wiesz o Claude Code. Najpierw potrzebujesz trzech filarów: klonu AI + Second Brain + Context Engineering. Bez nich pętla zaczyna podupadać już przy 5. iteracji. Odkrywaj Ailoot dalej na ailoot.ai.