Akademia · Pętle

Pętle: /goal i /loop. Agent pracuje, aż cel osiągnięty.

Najwięcej daje nie pojedyncze polecenie, tylko agent prowadzony w pętli. Dwie komendy: /goal — pracuje, aż osiągnie cel, oraz /loop — powtarza zadanie co zadany czas. Spinają je wzorzec checklisty: plik z zadaniami, który agent sam odhacza.

Ostatnia aktualizacja:

Dwa monitory z terminalami wykonującymi zapętlone zadania agenta, puste krzesło — praca bez człowieka
/goalpętla do celu — kończy, gdy warunek spełniony
/loop 5mpowtarza zadanie co interwał (granularność 1 min)
Checklista = pamięć[ ] → [x] jako stan między iteracjami

01 / Dwie pętle · Czym są i dlaczego działają

Dwie pętle, dwa zastosowania.

Pojedynczy prompt kończy się, gdy agent uzna, że skończył. Pętla kończy się, gdy warunek jest spełniony — to cała różnica i cały powód, dla którego pętle działają.

/goal — pętla do celu

/goal uruchamia agenta w trybie zadaniowym: dostaje cel i pracuje w kółko, aż go osiągnie. Idealny do zadań, które da się rozbić na listę kroków o jasnym warunku zakończenia: „zrób wszystko z listy", „napraw, aż testy przechodzą", „uzupełnij brakujące pliki".

Sedno: definiujesz cel i warunek osiągnięcia celu, nie pojedynczą czynność. Spełnienie warunku ocenia po każdej turze osobny mały, szybki model (domyślnie Haiku) i zwraca tak/nie z uzasadnieniem. Agent, który wykonuje pracę, nie ocenia jej sam.

/loop — powtarzanie co interwał

/loop 5m sprawdź status builda powtarza to samo polecenie co zadany czas — tu co 5 minut. Sprawdza się przy monitorowaniu i pracy reaktywnej: „zerkaj na nowe zgłoszenia", „pilnuj kolejki, aż się opróżni". Bez podanego interwału pętla sama dobiera tempo — częściej, gdy coś się dzieje, rzadziej, gdy cisza. Działa, dopóki jej nie zatrzymasz albo nie wygaśnie.

  • /goal — gdy znasz cel, ale nie wiesz, ile kroków zajmie. Kończy się sam.
  • /loop <czas> — gdy chcesz cyklicznie coś sprawdzać lub dorzucać po kawałku w równych odstępach.

02 / Filozofia · Praca to pisanie pętli

Nie promptujesz. Piszesz pętle.

Boris Cherny, twórca Claude Code, ujął to wprost: „I don't prompt Claude anymore. I have loops that are running. My job is to write loops." Ewolucja wygląda tak: najpierw kod z autouzupełnianiem, potem promptowanie kilku agentów równolegle, na końcu pętle, które promptują same. Anatomia dobrej pętli to kontekst + cel + definicja sukcesu — agent iteruje i sam ocenia wyniki, aż przejdą test.

Builder / tester / reviewerTrzech agentów zamiast jednego
Sesja, która sama pisze, testuje i recenzuje własny kod, to student oceniający swój egzamin. Rozdziel role na osobnych agentów — weryfikacja przez odrębnego recenzenta wyraźnie podnosi jakość pierwszego podejścia.
Każ mu udowodnićDefinition of done w pętli
Plan → zmiana → testy → podsumowanie, co padło → poprawka. Agent nie raportuje „zrobione" — pokazuje zielone testy. Dokładnie dlatego warunek w /goal piszesz tak, żeby dało się go zweryfikować z transkryptu.
Kontekst to RAMStrefa głupienia zaczyna się wcześniej, niż myślisz
Okna kontekstu mają po 1M tokenów, ale realna jakość degraduje się już około 250 tysięcy. CLAUDE.md poniżej 300 linii, /clear między zadaniami, a po dwóch nieudanych próbach — /clear zamiast trzeciej.
Zakładaj najgorszeBezpieczeństwo pętli
Agent zrobi wszystko, co może przeczytać lub dotknąć. Zakazy w promptach nie wystarczą — agent potrafi napisać skrypt, który je obejdzie. Uprawnienia ustawiaj na poziomie systemu: hooki, sandbox, sekrety w vaultach zamiast w plikach.

03 / Dalej · Część praktyczna

Dalej: gotowe wzorce do wdrożenia.

Konfiguracja

Parametry i zasady obu komend

Wymagane wersje i limity, twardy limit tur, przerywanie i wznawianie — plus cztery zasady, żeby pętla nie zwariowała.

Wzorzec

Checklista TODO.md, którą agent sam odhacza

Plik z checkboxami jako plan, pamięć i warunek końca w jednym — z gotowym promptem do skopiowania i wyjaśnieniem, dlaczego ewaluator go „widzi".

Pętle samodoskonalące

Agent, który sam sprawdza i poprawia

Mechanika w trzech krokach i dwa wdrożenia z projektów: optymalizacja JavaScriptu i komunikacja z drukarką w embedded.

04 / Konfiguracja · Parametry i zasady

Zanim puścisz agenta samego.

/goal w szczegółach

Wymagania i sterowanie: /goal wymaga Claude Code w wersji v2.1.139 lub nowszej; działa też nieinteraktywnie (claude -p "/goal …") i przeżywa --resume sesji. /goal clear przerywa bieżący cel, a samo /goal bez argumentu pokazuje status — liczbę tur, zużyte tokeny i uzasadnienie ostatniej oceny.

/loop w szczegółach

Interwał jest opcjonalny: /loop <prompt> bez czasu sam dobiera odstęp (od 1 minuty do 1 godziny), a po wykonaniu zadania potrafi sam zakończyć pętlę. Samo /loop bez argumentów odpala wbudowany prompt utrzymaniowy (albo Twój plik .claude/loop.md): dociąga niedokończoną robotę, pilnuje PR-a bieżącej gałęzi i sprząta kod.

Wymagania: /loop stoi na cronie, więc stały interwał ma granularność 1 minuty (sekundy zaokrąglają się w górę). Zadania są przypięte do sesji: wygasają po 7 dniach, maksymalnie 50 na sesję. Klawisz Esc kasuje najbliższe wybudzenie. Wymaga Claude Code w wersji v2.1.72 lub nowszej.

Jasny warunek końcaBez tego pętla się nie zatrzyma
Zawsze podaj mierzalny warunek osiągnięcia celu — „wszystkie checkboxy [x]", „testy zielone", „brak plików bez nagłówka". Inaczej agent będzie kręcił się w nieskończoność. Dorzuć też twardy limit: oficjalnie wystarczy dopisać do warunku or stop after 20 turns. Cały warunek może mieć do 4000 znaków.
Małe, atomowe zadaniaJedno zadanie = jeden checkbox
Rozbij cel na kroki, które da się wykonać i odhaczyć pojedynczo. Łatwiej wznowić po przerwie i widać realny postęp.
Checklista to stanPlik przeżywa restart
Trzymanie postępu w pliku (a nie w pamięci sesji) sprawia, że pętlę można przerwać i wznowić — agent czyta, co już odhaczone, i rusza dalej.
/loop do monitoringu, /goal do robotyDobierz pętlę do zadania
Powtarzalne sprawdzanie stanu → /loop. Doprowadzenie zadania do końca → /goal. Można je łączyć: /loop pilnuje, a po wykryciu zmiany odpala pracę.

05 / Wzorzec · Checklista jako pamięć

Plik z checkboxami, który agent sam odhacza.

Najprostszy sposób, żeby pętla wiedziała, co już zrobiła, a co zostało — to plik z listą zadań i checkboxami. Agent po każdym wykonanym zadaniu zamienia [ ] na [x]. Plik jest jednocześnie planem, pamięcią i warunkiem zakończenia: cel osiągnięty, gdy wszystkie pozycje są zaznaczone.

Przykładowy TODO.md:

# Lista zadań do wykonania

- [ ] 1. Utwórz plik `hello.txt` z tekstem "Hello SZRON"
- [ ] 2. Utwórz plik `data.json` z obiektem {"version": 1}
- [ ] 3. Dopisz do `hello.txt` drugą linię z aktualną datą
- [ ] 4. Utwórz `README.md` z nagłówkiem "# Demo /goal"
- [ ] 5. Policz pliki w katalogu i zapisz liczbę do `count.txt`

I prompt, który uruchamia całość:

/goal wykonaj po kolei każdy task z TODO.md, po wykonaniu
zamień [ ] na [x] przy tym tasku; po każdej turze wypisz w
odpowiedzi aktualną listę checkboxów; cel osiągnięty gdy w
tym wypisie wszystkie checkboxy są zaznaczone [x]

Dlaczego to działa: ewaluator /goal nie czyta plików ani nie uruchamia komend — ocenia wyłącznie transkrypt rozmowy. Dlatego warunek pisz tak, by dało się go udowodnić z odpowiedzi agenta: każ mu po każdej turze wypisać stan checklisty (ile [ ], ile [x]) wprost w odpowiedzi. To, czego nie widać w transkrypcie, dla ewaluatora nie istnieje. Ty w każdej chwili widzisz postęp w tym samym pliku.

06 / Pętle samodoskonalące · Agent uczy się z błędów

Sprawdza, poprawia, iteruje — aż kod działa.

Ten sam wzorzec w wersji, którą wdrażamy w zespołach jako pętle samodoskonalące (Self-Improving Loops): agent nie oddaje kodu po pierwszym podejściu, tylko sam go uruchamia, czyta wyniki i poprawia. /goal plus checklista z poprzedniej sekcji to jego gotowa implementacja.

01 · Sprawdza

Uruchamia i weryfikuje

Agent uruchamia kod i testy, weryfikuje działanie narzędziami MCP (ChromeDevTools, Playwright).

02 · Poprawia

Automatycznie

Naprawia błędy, optymalizuje wydajność, refaktoruje kod — bez interwencji człowieka.

03 · Powtarza

Aż działa

Iteruje, dopóki nie osiągnie celu i wszystkie testy nie przejdą.

Optymalizacja JavaScript„Ten mechanizm działa wolno. Spraw, żeby przyspieszył."
5× przyspieszenie w 3 minuty — z profilowaniem przez ChromeDevTools MCP.
Drukarka RS232 (embedded)„Potrzebujemy komunikacji z drukarką przez RS232."
1,5 dnia zamiast miesiąca — Rust + STM32 z toolchainem Keil.

Jak wdrażamy ten wzorzec w całych zespołach — na stronie transformacji AI dla programistów.

Wdrożenie u Was

Chcecie, żeby Wasz zespół tak prowadził agentów?

Pętle, checklisty i AGENTS.md jako kontrakt zespołu wdrażamy na Waszym kodzie — w ramach dwóch kwartałów transformacji. Audyt 90 minut wystarczy, żeby sprawdzić, czy ma to u Was sens.