Claude Code Just Made Subagents Feel Obsolete

O czym jest ten film

1. Claude Code dostał możliwość wysyłania wiadomości między osobnymi sesjami — funkcję znaną wcześniej z Codeksa.
2. Narzędzie SendMessage, zarezerwowane dotąd dla subagentów, obsługuje teraz również komunikację między pełnoprawnymi sesjami.
3. ListAgents pokazuje wszystkie sesje Claude Code widoczne na maszynie (i zdalnie), wraz z ich nazwami.
4. Sesje nazywa się przez > przy starcie albo /rename w trakcie pracy.
5. Autor pokazuje przekazywanie zadania („handoff”) z sesji monitorującej logi produkcyjne do świeżej sesji naprawczej w nowym worktree.
6. Drugie zastosowanie: przebudowa własnych skills — jedna sesja przekazuje drugiej cel skilla, bez opisu strategii, żeby ta wymyśliła nowe podejście.
7. Terminal cmux udostępnia CLI, dzięki czemu Claude Code sam tworzy workspace’y i dzieli panele; autor spiął to własnym skillem peer sessions.
8. Ten sam mechanizm działa międzynarzędziowo — Codex może sterować sesjami Claude Code przez wspólny socket.
9. Przewaga paneli nad subagentami: widać całą ścieżkę pracy i można wrócić z pytaniem uzupełniającym; subagent znika po zakończeniu.
10. Komunikacja działa też między maszynami (lokalna sesja ↔ sesja przez SSH na serwerze) — wymaga włączonego trybu remote control.

Redakcyjne tłumaczenie

Nowa funkcja: sesje rozmawiają ze sobą

Dziś rano Claude Code skopiował moją ulubioną funkcję z Codeksa — sesje Claude Code mogą teraz wysyłać wiadomości jedna do drugiej. Omówię wszystko, co się z tym wiąże, bo jeśli jesteś podobny do mnie i spędzasz po dziesięć godzin dziennie w Claude Code, to każda drobna nowość usprawniająca przepływ pracy z czasem procentuje.

Przykład z życia. Miałem tutaj sesję Claude Code, która przez dwanaście godzin monitorowała logi produkcyjne, żeby upewnić się, że przy wdrożeniu zupełnie nowej funkcji nie stanie się nic dramatycznego. Wychwyciłem dwa drobne problemy warte naprawienia. Zamiast poprawiać je w tej samej sesji, mogę je naprawić w zupełnie nowej i zrobić porządne przekazanie zadania między nimi.

Dzielę więc panel skrótem Command+D. Korzystam z terminala o nazwie cmux — link znajdziesz pod filmem. Uruchamiam Claude’a w nowym panelu i nadaję sesji nazwę: claude --name worker fix. Kiedy teraz w lewym panelu wywołam ListAgents, dostanę listę wszystkich subagentów w tej sesji oraz wszystkich innych działających sesji Claude Code. Widzę, że mam uruchomionych 108 sesji — wiele z nich chodzi na kontenerach w chmurowych piaskownicach, stąd taka liczba. Na samej górze widnieje worker fix, uruchomiony trzynaście sekund temu.

(Informacja dodatkowa: worktree to mechanizm Gita pozwalający mieć kilka katalogów roboczych podpiętych do jednego repozytorium — każdy na innej gałęzi. Dzięki temu równoległe sesje agenta nie wchodzą sobie w drogę na plikach.)

Mówię więc: „wyślij wiadomość do sesji worker fix, żeby wprowadziła poprawkę i otworzyła nowy pull request, korzystając ze świeżego worktree”. Po naciśnięciu entera Claude Code użyje narzędzia SendMessage — tego samego, które wcześniej służyło wyłącznie do komunikacji z subagentami i między agentami w zespołach agentów — ale tym razem, żeby wysłać wiadomość do innej sesji. Widzimy, że wiadomość dotarła. Po drugiej stronie pojawia się informacja o wdrożeniu szyfrowania i sesja zabiera się do pracy nad problemem. Mogłem też dopisać: „kiedy tamta sesja skończy, niech odeśle wiadomość, że gotowe”.

Przebudowa skills przez zderzenie z drugą sesją

Innym zastosowaniem tej funkcji było u mnie przerobienie części moich skills pod modele generacji Claude 5. Mówi się, że skills albo należy skasować, albo napisać od nowa. Ja lubię pracować wstecz — od celu skilla. Mam zresztą o tym osobne wideo w mojej Agentic Coding School, pod tytułem „Goal In, Strategy Out”.

W praktyce otwieram drugą sesję po prawej stronie i mówię do lewej: „przekaż cel tego skilla sesji o nazwie remaking skill. Powiedz jej, żeby nie wywoływała tego skilla i żeby nie opisywać niczego poza celem. Zobaczmy, czy wymyśli zupełnie nową strategię osiągnięcia tego samego”. Lewa sesja wysyła więc do prawej opis: oto co próbujemy osiągnąć, nie uruchamiaj istniejącego skilla, sprawdź, czy da się zrobić to lepiej.

Takich prób mogę mieć wiele naraz — mogę je podglądać i śledzić na bieżąco, co robią. Może wyjdzie z tego lepszy skill, a może z testu A/B okaże się, że agent w ogóle już tego skilla nie potrzebuje. Da się to pociągnąć dalej: rozgałęzić na trzy czy cztery strategie, uruchomić kilka sesji Claude Code w osobnych panelach, kazać im podążać za tym samym celem, a potem przepisać skilla, którego używam codziennie.

cmux i skill „peer sessions”: Claude zarządza własnym warsztatem

Uciążliwość tego przepływu pracy polega na tym, że nowy panel muszę otwierać ręcznie. Byłoby znacznie lepiej, gdyby Claude Code robił to sam. Dlatego tak lubię cmux — daje CLI, które pozwala Claude Code’owi zarządzać własną przestrzenią roboczą: uruchamiać panele, workspace’y, dzielić widoki. Mam o cmuksie osobne, w pełni bezpłatne wideo w Agentic Coding School — nie trzeba nawet zakładać konta. Link pod filmem. Jeśli się spodoba, znajdziesz tam pozostałe klasy; obecnie jest ich około 350 lekcji o agentowym kodowaniu.

Skoro cmux udostępnia komendy w rodzaju cmux new workspace czy dzielenia panelu, to Claude Code może je wywoływać, uruchomić nową sesję w nowym panelu, a potem wysyłać do niej i odbierać od niej wiadomości. Domyślnie oczywiście nie wie, jak to zrobić — dlatego napisałem skilla o nazwie peer sessions. Uczy on Claude Code’a łączenia nowej zdolności komunikacyjnej z CLI cmuksa.

Uruchamiam więc świeżą sesję, wywołuję /peer sessions i mówię: „dla wszystkich otwartych pull requestów otwórz nowy panel i zrób code review każdego z nich w osobnym worktree”. Claude Code tworzy sobie nowy workspace, uruchamia kilka sesji równolegle, wysyła do nich wiadomości, dopytuje i odbiera odpowiedzi. Widać, że powstał nowy workspace z trzema panelami obok siebie, a on wysyła do nich polecenia po kolei: zrób ten przegląd kodu, popraw tamto. Na samym dole widać instrukcję: „kiedy skończysz, odeślij mi wiadomość tą drogą” — mamy uruchomiony socket, na który można odesłać odpowiedź.

Co ciekawe, tego samego socketu można użyć z innymi narzędziami agentowymi — działa też z Codeksem. W ten sposób Claude sam zarządza uruchamianiem kolejnych instancji siebie. To odpowiednik sytuacji, w której kopiowałem polecenie, wklejałem je do Codeksa i podmieniałem słowo „panel” na „wątek”. W Codeksie wiadomo, że z jednego koordynatora można rozwidlić wiele wątków — teraz Claude może pełnić rolę koordynatora, wysyłać wiadomości do innych sesji i je odbierać.

Codex sterujący sesjami Claude Code

Zróbmy to samo od drugiej strony. Wywołuję /peer sessions i pytam: „jakie sesje działają na mojej maszynie?”. Odpowiedź: masz uruchomione 31 sesji Claude Code, 24 z nich są osiągalne, 27 nieosiągalnych, bo chodzą na starszej wersji Claude Code.

(Informacja dodatkowa: liczby w tym miejscu nie sumują się — autor odczytuje je z ekranu na żywo. Istotny jest sam mechanizm: sesje na starszych wersjach Claude Code nie są widoczne dla nowej funkcji wiadomości.)

Mówię więc: „przejdź do sesji worker fix i każ jej przesłać raport z postępów — co dokładnie się wydarzyło”. Widać, że wiadomość poszła do tamtej sesji Claude Code z prośbą o precyzyjny raport, a odpowiedź wraca z powrotem. To kolejny sposób na to, żeby Codex i Claude rozmawiały ze sobą.

Po co panele, skoro są subagenci

Pewnie myślisz: po co mi to, skoro mogę odpalić claude -p albo codex exec w trybie bezgłowym, albo po prostu użyć subagentów? Wielka przewaga prawdziwych paneli polega na tym, że łatwo wrócić do wcześniejszej sesji z pytaniem uzupełniającym. Łatwiej się tym zarządza i widać całą ścieżkę, którą agent przeszedł. Przy subagentach dopytanie jest trudne — subagent zwykle znika z widoku, kiedy skończy pracę. Wielu ludzi przy swoich zadaniach woli mieć wiele osobnych paneli, bo widzą pełny przebieg i mogą swobodnie kontynuować rozmowę.

Jeden ze sposobów kontynuacji: znów użyć skilla peer sessions i powiedzieć „uruchom kilka nowych sesji i przygotuj mi artefakty, które pomogą zrozumieć kluczowe technologie użyte w tym rozwiązaniu, wyjaśnione na kilku poziomach trudności, z interaktywnymi diagramami”. Kiedy powstanie nowy workspace i wszystkie artefakty, mogę wejść do każdej sesji z osobna, dopytać, podyskutować. Będę tego używał coraz częściej, zwłaszcza przy poznawaniu nowych technologii, które mnie interesują — bo tak jak teraz, gdy powstają cztery sesje generujące artefakty, nie mam tego wszystkiego zagraconego w jednej sesji.

Fazy planu i stacked PR-y

Kolejny przepływ pracy warty rozważenia: jeśli lubisz realizować plany albo specyfikacje etapami, możesz połączyć to z nową funkcją stacked pull requests na GitHubie, gdzie jeden PR jest nadbudowany nad poprzednim.

(Informacja dodatkowa: stacked PR to łańcuch pull requestów, w którym każdy kolejny bazuje na gałęzi poprzedniego, zamiast bezpośrednio na gałęzi głównej. Pozwala recenzować duże zadanie w małych, kolejnych porcjach.)

Otagowuję plan — powiedzmy plan dodania uwierzytelniania dwuskładnikowego do aplikacji — i piszę: „użyj stacked PR-ów GitHuba; każdą fazę tego planu zrealizuj w nowym panelu, a po zakończeniu fazy uruchom kolejny panel i otwórz w międzyczasie pull request jako stacked PR”. Podaję też link do dokumentacji stacked PR, żeby wiedział, jak to działa — to na tyle nowa funkcja, że pewnie nie ma jej jeszcze w danych treningowych. Można na to zrobić osobnego skilla. Agent przechodzi przez cały proces, tworząc nowy panel dla każdej fazy planu, a ja mogę szybko wrócić do każdego z nich i dopytać. To niezły sposób na podzielenie pracy na fazy i skoordynowanie ich, jeśli lubisz tak pracować.

Rozmowa między maszynami

Bardzo ciekawa rzecz: sesje Claude’a mogą komunikować się między różnymi maszynami. Mam tutaj sesję lokalną, a ten projekt jest wdrożony na tamtym serwerze. Loguję się więc szybko po SSH na serwer i uruchamiam tam Claude’a. Nadaję mu nazwę przez /rename — niech się nazywa Hetzner example. Do lokalnej sesji mówię: „porozmawiaj z sesją Hetzner example i zapytaj ją o specyfikację sprzętu”. Obie sesje rozmawiają ze sobą mimo tego, że działają na różnych urządzeniach. Oznacza to, że koordynator może siedzieć na jednym urządzeniu, a koordynowana sesja na innym, i mogą wymieniać się informacjami w obie strony.

Za pierwszym razem nie zadziałało — okazało się, że nie miałem włączonego trybu remote control. Włączam go, wywołuję ListAgents i powinienem zobaczyć pozostałe sesje. Wysyłam wiadomość ponownie i tym razem sesja przez remote control zostaje wykryta. Wiadomość dociera: po drugiej stronie pojawia się „message from peer” i pytanie, czy wykonać polecenie. Przełączam tamtą sesję w tryb automatyczny. Miła rzecz: tryby uprawnień danej sesji dobrze przenoszą się między sesjami. Agent pobiera specyfikację i odsyła ją do sesji lokalnej — i mam ją u siebie.

To bywa naprawdę przydatne, bo czasem chcemy uzgodnić jakąś konfigurację między dwoma serwerami, czyli między dwiema sesjami działającymi na różnych maszynach. Może chodzić o kontrakt API, o strategię testowania, albo po prostu o zrzucenie ciężkiej roboty na zdalną sesję. Możliwości jest mnóstwo i uważam, że ten dość fundamentalny prymityw odblokowuje bardzo wiele z nich.

Co dalej

Da się na tym zbudować masę rzeczy: Codex albo Grok Code zarządzający wszystkimi sesjami Claude Code, wielu koordynatorów rozsianych po różnych urządzeniach, harmonogramy uruchamiane cyklicznie, które automatycznie tworzą nowy panel, wykonują jakąś pracę, a ty tylko przewijasz i sprawdzasz, czy wszystko wygląda w porządku.

Sam będę sporo eksperymentował, a przepływy pracy, przy których ostatecznie zostanę, opiszę w mojej Agentic Coding School. Jeśli chcesz poznać każdą funkcję Claude Code i Codeksa, a także budowanie oprogramowania z agentami działającymi w pętlach — mnóstwo technik z zakresu inżynierii agentowej, inżynierii kontekstu i inżynierii promptów — to jest to prawdopodobnie najbardziej zaawansowany i kompletny zestaw zajęć, jaki znajdziesz w sieci na ten temat. Wypuściłem właśnie zupełnie nową klasę o budowaniu agentów w Slacku, bo coraz więcej swojej pracy przenoszę właśnie do Slacka. Dziś sporo moich rutynowych zadań dzieje się tam — i taką zmianę widzę też w całej branży, dlatego zrobiłem o tym osobne zajęcia. Link znajdziesz pod filmem; po zapisaniu się i dołączeniu do Discorda możesz zadawać pytania mnie i innym uczestnikom.

10 najważniejszych takeaways — z kontekstem zastosowania

1.SendMessage działa już między sesjami, nie tylko z subagentami

Na czym polega: narzędzie wysyłania wiadomości, dotąd zarezerwowane dla komunikacji z subagentami, obsługuje teraz również inne uruchomione sesje Claude Code. Sesje widzisz przez ListAgents.

Jak stosować: nazwij sesje sensownie (claude --name worker-fix przy starcie, /rename w trakcie), a potem po prostu poproś jedną sesję, żeby przekazała zadanie drugiej po nazwie.

Na co uważać: sesje na starszych wersjach Claude Code są niewidoczne dla tego mechanizmu — autor miał ich w danym momencie więcej niż osiągalnych. Przed budowaniem workflow zaktualizuj wszystkie instancje.

2.Handoff zamiast dokładania pracy do przeciążonej sesji

Na czym polega: długo żyjąca sesja (np. monitorująca logi produkcyjne przez 12 godzin) wykrywa problem, ale nie naprawia go u siebie — przekazuje zadanie świeżej sesji.

Jak stosować: sesję obserwacyjną trzymaj w roli obserwatora; naprawę zlecaj nowej sesji z instrukcją „nowy worktree, nowy PR”. W poleceniu dopisz prośbę o odesłanie wiadomości po zakończeniu.

Na co uważać: bez wymogu osobnego worktree równoległe sesje będą się nawzajem nadpisywać w tym samym katalogu roboczym.

3.„Goal in, strategy out” jako metoda przebudowy skills

Na czym polega: żeby sprawdzić, czy istniejący skill jest jeszcze potrzebny, przekazujesz drugiej sesji wyłącznie cel — z wyraźnym zakazem zaglądania do skilla i bez podpowiadania strategii.

Jak stosować: przy przechodzeniu na nową generację modeli uruchom to dla swoich najczęściej używanych skills; porównaj strategię, którą model wymyśli sam, ze swoją.

Na co uważać: zanieczyszczenie promptu. Jeśli w opisie celu przemycisz kroki starej strategii, dostaniesz jej kopię, a nie niezależną propozycję. Wynik traktuj jako materiał do testu A/B, nie jako gotowy werdykt.

4.Panele biją subagentów tam, gdzie potrzebna jest kontynuacja

Na czym polega: subagent po zakończeniu znika z widoku i trudno go dopytać. Sesja w panelu zostaje — widać całą jej ścieżkę i można wrócić z pytaniem.

Jak stosować: wybieraj panele do zadań eksploracyjnych i takich, w których będziesz dyskutować z wynikiem. Subagentów i tryb bezgłowy (claude -p, codex exec) zostaw do zadań zamkniętych, gdzie liczy się tylko rezultat.

Na co uważać: panele są droższe uwagowo — każdy to osobny kontekst do przejrzenia. Nie rozgałęziaj się szerzej, niż jesteś w stanie faktycznie przeczytać.

5.Claude może sam zarządzać swoim warsztatem — jeśli dostanie CLI

Na czym polega: cmux udostępnia komendy typu „nowy workspace” czy „podziel panel”, więc agent może sam tworzyć sobie panele zamiast czekać, aż zrobisz to ręcznie.

Jak stosować: wybieraj terminal/multiplekser sterowalny z linii poleceń; wtedy „uruchom trzy sesje i rozdziel im pracę” staje się jednym poleceniem.

Na co uważać: to zależność od konkretnego narzędzia zewnętrznego, nie funkcja Claude Code. Bez takiego CLI cała reszta workflow nadal działa — po prostu panele otwierasz sam.

6.Model domyślnie nie zna nowych narzędzi — trzeba go nauczyć skillem

Na czym polega: autor napisał skilla peer sessions, który łączy nową zdolność wysyłania wiadomości z komendami cmuksa. Bez niego Claude nie wie, jak to zestawić.

Jak stosować: kiedy łączysz dwie świeże rzeczy, spisz procedurę w skillu raz i wywołuj ją przez /. Odruch „napiszę to w prompcie za każdym razem” nie skaluje się.

Na co uważać: skill jest tak dobry, jak Twoje rozumienie obu narzędzi — a przy szybko zmieniających się funkcjach szybko się dezaktualizuje.

7.Przy bardzo świeżych funkcjach dostarczaj dokumentację w prompcie

Na czym polega: przy stacked PR-ach GitHuba autor świadomie podał link do dokumentacji, bo funkcja jest zbyt nowa, żeby znaleźć się w danych treningowych modelu.

Jak stosować: wprowadzając funkcję nowszą niż kilka miesięcy, załącz link albo wklej fragment dokumentacji. Jeśli robisz to regularnie — zamknij to w osobnym skillu.

Na co uważać: bez tego model będzie halucynował „prawdopodobne” API zamiast przyznać, że czegoś nie zna.

8.Fazy planu × stacked PR-y = przeglądalne duże wdrożenie

Na czym polega: każda faza planu realizowana w osobnym panelu, a pomiędzy fazami otwierany PR nadbudowany nad poprzednim.

Jak stosować: sprawdza się przy wielofazowych wdrożeniach w rodzaju dodania 2FA — recenzent dostaje serię małych, uporządkowanych PR-ów zamiast jednego molocha.

Na co uważać: stosy PR-ów są wrażliwe na zmianę kolejności i na poprawki w środku stosu — poprawka we wczesnym PR-ze wymusza przebazowanie kolejnych.

9.Komunikacja między maszynami wymaga włączonego remote control

Na czym polega: sesja lokalna może rozmawiać z sesją uruchomioną przez SSH na zdalnym serwerze. Autorowi nie działało to za pierwszym razem właśnie z powodu wyłączonego trybu remote control.

Jak stosować: włącz remote control po obu stronach, potwierdź widoczność przez ListAgents, dopiero potem wysyłaj wiadomość. Nadaje się do uzgadniania kontraktu API czy strategii testów między środowiskami albo do zrzucania ciężkich obliczeń na zdalną maszynę.

Na co uważać: tryby uprawnień przenoszą się między sesjami — zdalna sesja przełączona w tryb automatyczny wykona przysłane polecenie bez pytania. Na maszynie produkcyjnej to poważne ryzyko.

10.Ten sam socket łączy różne narzędzia agentowe

Na czym polega: kanał komunikacji nie jest zamknięty w Claude Code — Codex (a zdaniem autora również Grok Code) może pełnić rolę koordynatora sterującego sesjami Claude Code.

Jak stosować: wybierz jedno narzędzie na koordynatora, a resztę traktuj jako wykonawców — dzięki temu nie musisz porzucać narzędzia, w którym pracuje Ci się najwygodniej.

Na co uważać: to zestaw dopiero powstających prymitywów. Autor sam zaznacza, że wciąż eksperymentuje — nie warto jeszcze budować na tym krytycznej automatyki bez nadzoru człowieka.