O autorze

Jakub Stankowski – programista .NET i Angular od 2018 roku. Pracował nad projektami frontendowymi, backendowymi i fullstackowymi, przestrzegając zasad czystego kodu, DRY i stosując CQRS. Ma również doświadczenie jako trener programowania.

Od 2023 roku intensywnie pracuje z Claude AI oraz metodą Spec-Driven Development (SDD) – produkcyjnym workflow do pracy z AI opartym na zasadzie: najpierw specyfikacja, potem implementacja. Na ProgramujZAI.pl dzieli się praktyczną wiedzą o tym, jak programować z AI bez chaosu w kodzie.

Poznaj Jakuba →

Claude Code w 2026 roku ma trzy nowe funkcje, które realnie zmieniają codzienną pracę programisty: komendę /loop do automatycznego monitorowania zadań, tryb multi-agent (subagenci i agent teams) do równoległej pracy nad kodem oraz rozbudowany zestaw komend sterujących sesją. Poniżej pokazuję, jak z nich korzystam, kiedy się sprawdzają, a kiedy generują niepotrzebny koszt tokenów.

Komenda /loop automatyzuje monitorowanie i naprawianie zadań bez Twojego udziału

/loop pozwala uruchomić dowolny prompt cyklicznie, bez ręcznego odpalania go za każdym razem. Działa to na trzy sposoby, w zależności od tego, co podasz po komendzie.

• Stały interwał — np. /loop 5m sprawdź czy deployment się zakończył uruchamia prompt co 5 minut, aż go zatrzymasz.
• Interwał wybierany przez Claude — jeśli pominiesz czas (/loop sprawdź czy CI przeszło), Claude sam dobiera odstęp między iteracjami: krótszy, gdy coś się dzieje (np. build trwa), dłuższy, gdy jest cisza.
• Wbudowany prompt konserwacyjny — samo /loop bez argumentów każe Claude kontynuować niedokończoną pracę, doglądać PR-a (komentarze, failujące CI, konflikty) i robić porządki, gdy nic innego nie czeka.

Domyślne zachowanie /loop możesz nadpisać plikiem .claude/loop.md — wtedy zamiast wbudowanego promptu konserwacyjnego Claude wykonuje Twoje własne instrukcje przy każdej iteracji. To wygodne, gdy chcesz, żeby dana gałąź projektu miała swój stały rytuał sprawdzania (np. „sprawdź testy, jeśli czerwone — napraw i wypchnij minimalną poprawkę”).

Pętla działa tylko, dopóki sesja jest otwarta i bezczynna — zamknięcie terminala ją zatrzymuje, chyba że wcześniej odeślesz sesję w tło komendą /background. Zadania cykliczne wygasają automatycznie po siedmiu dniach, co chroni przed zapomnianą pętlą działającą w nieskończoność. Zatrzymanie pojedynczej pętli w trakcie oczekiwania to po prostu Esc.

Subagenci i agent teams to dwa różne modele pracy wieloagentowej w Claude Code

Multi-agent w Claude Code nie oznacza jednego mechanizmu — to dwa osobne narzędzia do różnych sytuacji, i mylenie ich prowadzi do niepotrzebnych kosztów tokenów.

Subagenci — szybcy pomocnicy, którzy raportują wynik do głównej sesji

Subagent dostaje własne okno kontekstu, wykonuje konkretne zadanie (np. przeszukanie kodu, analizę logów, uruchomienie testów) i zwraca skondensowany wynik do głównej rozmowy. Nie rozmawia z innymi subagentami — komunikuje się wyłącznie z sesją, która go wywołała. To najtańszy sposób na odciążenie głównego kontekstu przy zadaniach, gdzie liczy się wynik, a nie dyskusja.

Agent teams — niezależne instancje, które komunikują się między sobą

Agent teams to funkcja eksperymentalna (włączana zmienną CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1), w której jedna sesja pełni rolę lead, a pozostałe — teammates — pracują jako w pełni niezależne instancje Claude Code, każda z własnym oknem kontekstu. Teammates widzą wspólną listę zadań, sami przydzielają sobie kolejne pozycje i wysyłają wiadomości bezpośrednio do siebie nawzajem, bez pośrednictwa lead-a. To model przydatny tam, gdzie wartość bierze się z konfrontacji różnych perspektyw — np. trzech teammate’ów badających tę samą hipotezę błędu z różnych stron i próbujących obalić nawzajem swoje teorie.

Koszt jest tu istotny: agent teams zużywają wielokrotnie więcej tokenów niż pojedyncza sesja, bo każdy teammate to osobna instancja modelu z własnym kontekstem. Sensowny punkt startowy to 3–5 teammate’ów i zadania na tyle duże, że koordynacja się opłaca — przy prostych, sekwencyjnych zmianach subagent albo zwykła sesja wystarczą.

Top 10 komend Claude Code, które warto znać w codziennej pracy

Poniższa lista to komendy, po które sięgam najczęściej — od inicjalizacji projektu po wysyłkę zmian.

• /init — generuje startowy plik CLAUDE.md na podstawie analizy repozytorium; punkt wyjścia dla każdego nowego projektu.
• /plan — przełącza sesję w tryb planowania przed dużą zmianą: Claude analizuje kod i proponuje podejście, zanim cokolwiek zedytuje.
• /loop — opisane wyżej cykliczne uruchamianie promptu; sprawdza się przy pilnowaniu długich buildów i PR-ów.
• /batch — rozbija dużą zmianę obejmującą cały codebase na 5–30 niezależnych jednostek i uruchamia dla każdej osobnego subagenta w izolowanym git worktree.
• /code-review — sprawdza bieżący diff pod kątem błędów logicznych i okazji do uporządkowania kodu; z flagą --fix od razu aplikuje poprawki.
• /model — przełącza model AI i zapisuje wybór jako domyślny dla nowych sesji.
• /effort — ustawia poziom wysiłku rozumowania modelu (low/medium/high/xhigh/max); przydatne, gdy zadanie wymaga głębszej analizy niż zwykle.
• /context — wizualizuje zużycie okna kontekstu jako kolorową siatkę, z podpowiedziami co je najbardziej obciąża.
• /compact — kompresuje dotychczasową rozmowę, żeby zwolnić miejsce w kontekście, opcjonalnie z instrukcją, na czym skupić podsumowanie.
• /permissions — zarządza regułami allow/ask/deny dla narzędzi; im lepiej skonfigurowane, tym mniej pytań o zgodę przerywa pracę.

Jeśli szukasz jeszcze bardziej podstawowego zestawu na start, rozwijałem ten temat wcześniej w artykule o 6 komendach Claude Code — tam skupiam się na absolutnym minimum na pierwszą sesję.

Połączenie /loop, subagentów i konkretnych komend tworzy pełny workflow Spec-Driven Development

Te trzy funkcje najlepiej działają razem, nie osobno. W praktyce mój workflow przy większej zmianie wygląda tak: najpierw piszę specyfikację i wchodzę w /plan, żeby Claude zaproponował podejście, zanim dotknie kodu — to fundament Spec-Driven Development, o którym pisałem szerzej we wcześniejszym artykule.

Po zatwierdzeniu planu, jeśli zmiana obejmuje wiele niezależnych plików, oddaję ją do /batch — każda jednostka pracy trafia do osobnego subagenta w swoim worktree, więc nie ma konfliktów przy edycji tych samych plików. Gdy implementacja rusza, odpalam /loop 10m sprawdź czy testy przechodzą i dokończ otwarte wątki, żeby nie musieć ręcznie wracać co chwilę do terminala. Na koniec /code-review --fix łapie oczywiste potknięcia, zanim w ogóle otworzę PR-a.

Do agent teams sięgam rzadziej i świadomie — głównie przy code review z kilku niezależnych perspektyw (bezpieczeństwo, wydajność, pokrycie testami) albo przy debugowaniu, gdzie kilka konkurencyjnych hipotez trzeba zweryfikować równolegle. Dla codziennej, sekwencyjnej pracy nad jedną funkcją to za duży młotek.

Najczęstsze błędy przy pracy z multi-agentami w Claude Code

Największym błędem jest włączanie agent teams tam, gdzie wystarczy subagent lub zwykła sesja — koszt tokenów rośnie liniowo z liczbą teammate’ów, a przy prostych zadaniach koordynacja pochłania więcej czasu, niż oszczędza.

Drugi częsty problem to konflikty plikowe — dwóch teammate’ów edytujących ten sam plik nadpisuje sobie zmiany nawzajem. Rozwiązanie jest proste: dziel pracę tak, żeby każdy agent miał wyłączność na swój zestaw plików, tak jak robi to automatycznie /batch dzięki osobnym worktree.

Trzeci błąd to zbyt duże zadania na jednego teammate’a — agent pracujący zbyt długo bez checkpointu zwiększa ryzyko, że jego praca pójdzie w złym kierunku, zanim zdążysz zareagować. Lepiej dzielić na mniejsze, samodzielne jednostki, które dają jasny efekt końcowy.

FAQ — najczęstsze pytania o nowe funkcje Claude Code

Czym różni się /loop od agent teams?
/loop uruchamia jeden prompt cyklicznie w tej samej sesji, podczas gdy agent teams to wiele niezależnych instancji Claude Code pracujących równolegle i komunikujących się między sobą. To dwa różne mechanizmy: pierwszy dotyczy czasu, drugi — równoległości.

Czy subagenci mogą tworzyć własne subagenty?
Tak, subagent może zlecać zadania kolejnym subagentom, tworząc łańcuch delegacji. W agent teams jest to zablokowane — teammate nie może spawnować własnych teammate’ów, tylko lead zarządza całym zespołem.

Ile kosztuje praca z agent teams?
Znacząco więcej niż pojedyncza sesja, bo każdy teammate to osobna instancja modelu z własnym oknem kontekstu i zużyciem tokenów rosnącym proporcjonalnie do liczby agentów. Warto zaczynać od 3–5 teammate’ów i zwiększać liczbę tylko wtedy, gdy zadanie faktycznie zyskuje na równoległości.

Czy /batch nadaje się do dużych refaktoryzacji?
Tak, to jego główne zastosowanie — rozbija zmianę na 5–30 niezależnych jednostek, z których każda dostaje osobnego subagenta w izolowanym git worktree, testy i osobny pull request. Wymaga repozytorium git.

Czy /loop działa po zamknięciu terminala?
Nie w standardowym trybie — pętla działa tylko, gdy sesja jest otwarta i bezczynna. Jeśli potrzebujesz zadania działającego niezależnie od Twojego terminala, lepszym wyborem są Routines uruchamiane w chmurze Anthropic albo zaplanowane zadania w Claude Code Desktop.

Podsumowanie: trzy nowe funkcje, jeden cel — mniej ręcznej roboty

/loop, subagenci i agent teams to nie gadżety, tylko konkretne narzędzia do konkretnych sytuacji: automatyzacji powtarzalnego monitorowania, szybkiego delegowania pojedynczych zadań i równoległej pracy nad złożonymi problemami. Klucz to dobór właściwego narzędzia do skali zadania — subagent do szybkiej delegacji, agent teams do prawdziwie równoległej eksploracji, a /loop do wszystkiego, co wymaga cyklicznego sprawdzania bez Twojego udziału. W połączeniu z podejściem Spec-Driven Development te funkcje realnie skracają czas między pomysłem a działającym kodem.

Jeśli wdrażasz ten workflow u siebie i chcesz zobaczyć go na żywo, zapraszam na mój kanał YouTube, gdzie pokazuję konkretne sesje z Claude Code, oraz na standev.it/ai-workflow-bonus, gdzie znajdziesz darmowy bonus do newslettera o pracy z AI.