O czym jest ten film
- Największym utrapieniem w „vibe codingu” jest panowanie nad wieloma agentami działającymi jednocześnie.
- Autor zwykle prowadzi 3–5 agentów naraz i twierdzi, że powyżej trzech ręczne zarządzanie robi się męczące.
- Narzędzia natywne (przeskakiwanie między zakładkami terminala) słabo się do tego nadają.
- Umiejętność sprawnego, ręcznego prowadzenia kilku agentów to warunek wstępny przed automatycznymi „pętlami” w tle.
- Prezentowane narzędzie to Super Engineering — będące w fazie alpha rozwiązanie do zarządzania wieloma agentami.
- Kluczowy mechanizm: każde nowe zadanie odpala się w osobnym work tree, czyli izolowanej kopii projektu.
- Narzędzie podłącza się do istniejącej instalacji Claude Code i korzysta z subskrypcji Claude Max — bez dodatkowych opłat.
- Wskaźniki statusu (pomarańczowy znacznik = potrzebny input) pozwalają szybko wyłapać, który agent czeka na człowieka.
- Twoje istniejące skille, pluginy i workflowy działają „out of the box”.
- Alternatywy to Conductor (ładniejsze UI, gorszy onboarding) oraz podejście Cursora i IDE Anti-Gravity.
Redakcyjne tłumaczenie
Problem: panowanie nad wieloma agentami naraz
Jednym z moich największych utrapień przy „vibe codingu” jest utrzymanie kontroli nad wszystkim, co jest właśnie budowane albo poprawiane. Zwykle pracuję z trzema do pięciu agentami jednocześnie — w każdym momencie coś robią, a pilnowanie tego wszystkiego i dopychanie każdego wątku do przodu potrafi być naprawdę uciążliwe. Nie ma zbyt wielu dobrych, natywnych narzędzi, które by w tym pomagały.
Szczególnie jeśli jesteś początkujący albo po prostu masz mało czasu, śledzenie tych wszystkich rzeczy — przeskakiwanie między zakładkami w terminalu, próba przypomnienia sobie, w której rozmowie byłeś i co się gdzie działo — bywa mocno obciążające mentalnie. Efekt jest taki, że w praktyce trzymasz się jednego czatu naraz. Ale prędzej czy później zechcesz wyjść poza to i robić więcej w czasie, który masz. Trafiłem dziś na bardzo nowe narzędzie, które pomaga rozwiązać ten problem, i właśnie temu przyjrzymy się w tym materiale. W opisie zostawię link, jeśli chcesz bardziej szczegółowy przewodnik po tego typu narzędziu.
Gdzie takie narzędzia leżą na skali autonomii AI
Zanim przejdę do samego narzędzia, chcę wyjaśnić, gdzie moim zdaniem plasują się tego typu rozwiązania na gradiencie korzystania z AI do faktycznego budowania rzeczy — kiedy w ogóle powinieneś po nie sięgać.
(Informacja dodatkowa: autor odwołuje się do popularnej koncepcji „poziomów autonomii agentowej” — od AI jako asystenta podpowiadającego kod, przez coraz większą samodzielność, aż po w pełni autonomiczne pętle działające w tle.)
Nie będę wchodził w każdy poziom, bo część z nich jest mniej lub bardziej istotna w zależności od tego, czy jesteś zawodowym programistą. Ogólny sens jest taki: na początkowych etapach dopiero uczymy się używać AI do budowania i stopniowo dajemy mu coraz więcej autonomii, starając się przy tym — na ile potrafimy — uczyć się i weryfikować to, co powstaje. W pewnym momencie dochodzisz jednak do etapu, na którym prowadzisz kilka sesji jednocześnie. I wtedy zaczyna się robić naprawdę trudno.
Wiele osób przedstawia to jako coś banalnego — jakby „Hermes” siedział sobie i drukował ci dziesięć milionów dolarów, podczas gdy ty nic nie robisz i niczym nie zarządzasz. Ale to nie jest prawdziwy obraz sytuacji. Zarządzanie tym bywa trudne, zwłaszcza gdy siedzisz w terminalu i próbujesz przeskakiwać między wątkami, żeby sprawdzić, co jest gotowe, i popychać każdy do przodu. To potrafi być mnóstwo pracy.
Kiedy dochodzisz do momentu, w którym prowadzisz — powiedziałbym — więcej niż trzy takie rzeczy naraz (w artykule mówią o dziesięciu, ale realnie już powyżej trzech robi się ciężko), musisz najpierw opanować ten etap. Trzeba być naprawdę dobrym w ręcznym prowadzeniu trzech–pięciu agentów, zanim w ogóle pomyśli się o tych autonomicznych pętlach, które ludzie odpalają w tle i już nawet do nich nie zaglądają. Trzeba mocno rozumieć, jak wygląda zarządzanie tym ręcznie, zanim zbudujesz coś, co robi to automatycznie.
Do czego realnie przydaje się 3–5 agentów naraz
Zanim spojrzymy na narzędzie — kiedy w praktyce chciałbyś prowadzić trzy do pięciu agentów jednocześnie? Kilka przykładów:
- Jeden agent w osobnym work tree szuka nowych błędów, diagnozuje je i automatycznie wprowadza poprawki.
- Inny prowadzi audyty wydajności nowego kodu — z pull requestów albo tego, co zostało już zmergowane do bazy kodu.
- Bardzo lubię też czystą eksplorację nowych funkcji, na które mam pomysł: co byłoby potrzebne, żeby to faktycznie zrobić, jak podobne rzeczy rozwiązują konkurenci, jakie są wszystkie aspekty do rozważenia.
- Samo budowanie zupełnie nowych rzeczy, gdy mamy już solidny plan — czasem kilka agentów buduje różne fragmenty.
- Przeglądy bezpieczeństwa to kolejny dobry przykład.
Ta lista nawet nie jest wyczerpująca — w takim kontekście łatwo mieć już pięć albo więcej takich zadań w toku.
Narzędzie: Super Engineering
Skoro tak, to jak łatwiej zapanować nad tym wszystkim? Narzędzie, które w tym pomaga, nazywa się Super Engineering. To alpha, więc wyszło stosunkowo niedawno. Jest kilka innych narzędzi, które próbują robić to samo, ale doświadczenie z tym akurat podoba mi się najbardziej. Chodzi o to, żeby zarządzać wszystkimi tymi agentami kodującymi w sposób pozbawiony tarcia.
Zasada działania jest taka: najpierw podłączasz swoje repozytorium — jeśli pracujesz na swoim komputerze, podpinasz konkretny projekt do narzędzia. Potem, za każdym razem, gdy chcesz zrobić coś nowego, odpalasz nowy work tree.
(Informacja dodatkowa: work tree — mechanizm Gita pozwalający mieć wiele niezależnych kopii roboczych tego samego repozytorium jednocześnie, każdą na innej gałęzi.)
Work tree można traktować jak izolowaną kopię projektu, w której robisz cokolwiek chcesz, nie ruszając pracy toczącej się gdzie indziej. A potem — zależnie od tego, jak lubisz prowadzić swój proces — przeglądasz to, co zostało zrobione, i faktycznie to wdrażasz.
Demonstracja: jak to działa w praktyce
Jesteśmy w Super Engineering; mam tu wczytanych kilka projektów, nad którymi codziennie pracuję. Ten konkretny podłączyłem do mojej instancji Claude Code, więc korzysta po prostu z mojego planu Claude Max. Mogę używać go dokładnie tak, jak używałbym Claude Code. Mam do wyboru interfejs czatu albo interfejs terminala — tu jest czat — i mogę wywoływać własne komendy, tak samo jak w Claude Code.
W tym przypadku używam Open Spec, żeby kontynuować budowę refaktoryzacji agenta, którą prowadzę. Narzędzie ruszyło i robi całość: wywołuje subagentów, gdy trzeba, wykonuje pracę zakodowaną w moich workflowach, przeprowadza kontradyktoryjne przeglądy — wszystko, co jest częścią mojego procesu.
(Informacja dodatkowa: Open Spec to podejście/narzędzie do prowadzenia pracy agenta na bazie wcześniej wygenerowanej specyfikacji funkcji.)
Teraz mogę spokojnie napisać na przykład: „uruchom komendę sync and archive” — i skoro ukończyłem tę funkcję, narzędzie zsynchronizuje wszystkie zmiany, a następnie je zarchiwizuje. Ale gdybym w trakcie chciał odpalić jakąś inną pracę, wystarczy kliknąć przycisk „new work tree”. I już jestem w odizolowanej wersji projektu — cokolwiek tu zrobię, nie wejdzie w konflikt z tym, co dzieje się w work tree od usprawnień agenta.
Mogę więc na przykład powiedzieć: „odpal przegląd bezpieczeństwa skupiony na uwierzytelnianiu i autoryzacji” — i agent rusza do pracy. Mogę też dodać: „zbadaj wymagania techniczne skanera kodów kreskowych w aplikacji” — bo to aplikacja fitnessowo-żywieniowa, która skanuje kody kreskowe produktów. Wszystkie te zadania dzieją się we własnych, odizolowanych środowiskach, a my dostajemy ładne wskaźniki, gdy coś nas potrzebuje. Ten pomarańczowy znacznik oznacza, że potrzebny jest input — mogę wejść i doprecyzować, o co dokładnie mi chodzi. W tym przypadku chciałem przeaudytować cały projekt.
Praca równolegle w wielu projektach
Robimy to w obrębie jednego projektu, ale mogę mieć tu też inne projekty i pracować w nich równolegle. Ten jest prywatnym repozytorium, które udostępniam ludziom w mojej płatnej społeczności — to zestaw własnych workflowów i skilli do developmentu oraz pluginów go-to-market.
(Informacja dodatkowa: go-to-market — działania związane z wprowadzaniem produktu na rynek.)
Gdybym chciał dalej rozwijać te rzeczy, mając równocześnie w toku całą resztę, odpalam kolejny work tree i daję mu dowolne zadanie. Mogę wkleić opinię użytkownika o rozszerzeniu i kilka przypadków brzegowych, w których coś nie działa jak trzeba — i narzędzie zaczyna to diagnozować oraz naprawiać.
Widać, że pozostałe work tree wciąż działają i przetwarzają, i nic od nas w tej chwili nie potrzebują. Skaner kodów kreskowych prowadzi swoje badania, usprawnienia agenta wciąż wykonują ten sync i archiwizację, a agent od przeglądu bezpieczeństwa sprawdza wszystkie endpointy i API. To naprawdę wygodny sposób zarządzania tym wszystkim — w tym momencie mam cztery subagenty pracujące jednocześnie. Wszelkie skille, pluginy czy systemy, które już masz na swoim komputerze do zarządzania tego typu pracą, zadziałają z takimi narzędziami od ręki.
Mamy tu też kilka checkpointów, w których ktoś nas o coś pyta. Ten fix już wypchnęliśmy, ale użytkownik zgłasza, że problem dalej występuje. Musimy sprawdzić, czy to problem po stronie użytkownika (nie ma aktualnej wersji pluginu), czy raczej nasze commity jakoś nie trafiły do głównego projektu. Nie wiem — to trzeba zbadać. I tak po prostu przeskakuję między wątkami, odpowiadam na pojawiające się pytania i dopycham wszystko do przodu.
W kontekście skanera kodów kreskowych agent zdążył już poznać kontekst mojego projektu i opisał ogólne podejście do implementacji takiej funkcji. Mógłbym to teraz rozwinąć narzędziem w stylu compound engineering i pobrainstormować, albo użyć czegoś jak Open Spec, żeby wygenerować specyfikację. Jest wiele dróg — i właśnie dlatego lubię to narzędzie: jest całkowicie niezależne od tego, jaki masz stack technologiczny i jak lubisz robić rzeczy. Po prostu wykonuje wszystko tak, jak chcesz.
Alternatywy i dlaczego akurat to narzędzie
Jak mówiłem, to nie jedyne narzędzie tego typu. Inną opcją jest Conductor — działa podobnie, ale onboarding podobał mi się mniej i wydał mi się trochę mylący; dlatego pokazuję wam Super Engineering. To nowy paradygmat. Gdybyśmy spojrzeli na Cursora, to jego podejście; podobnie IDE Anti-Gravity — pomagają orkiestrować wiele agentów działających naraz i budują narzędzia, by robić to skuteczniej.
To, co lubię w Super Engineering, to fakt, że działa natywnie z naszymi subskrypcjami Claude Max czy Codex. Nie jesteśmy zamknięci w modelu, w którym — jak przy Cursorze — trzeba płacić osobną opłatę za dostęp do platformy. Te rozwiązania są open source i można ich używać od ręki, żeby uzyskać podobną funkcjonalność. To bardzo mocne narzędzie, jeśli chcesz podnieść swoje umiejętności pracy z takimi agentami.
Powiem szczerze, że Conductor ma nieco ładniejszy UI — polecam więc pobrać jedno z tych narzędzi i przetestować je samemu. Jeśli chcesz pełny przewodnik po Super Engineering, link znajdziesz w opisie.
10 najważniejszych takeaways — z kontekstem zastosowania
1.Opanuj ręczne prowadzenie 3–5 agentów, zanim sięgniesz po automatyzację
Na czym polega: Zanim uruchomisz autonomiczne pętle działające w tle, musisz najpierw sprawnie zarządzać kilkoma agentami ręcznie i rozumieć, jak wygląda ten proces.
Jak stosować: Zacznij od dwóch–trzech równoległych zadań, wyrób sobie rutynę przeglądania i dopychania każdego z nich, a dopiero potem zwiększaj liczbę i myśl o automatyzacji.
Na co uważać: Nie daj się marketingowej narracji „ustaw i zapomnij”. Bez doświadczenia w ręcznym nadzorze automatyczne pętle będą generować pracę, której nie umiesz zweryfikować.
2.Powyżej trzech agentów naraz ręczne śledzenie przestaje wystarczać
Na czym polega: Autor wskazuje, że około 3 równoległych wątków to próg, powyżej którego przeskakiwanie po zakładkach terminala staje się realnym obciążeniem.
Jak stosować: Potraktuj tę liczbę jako sygnał, że czas wprowadzić narzędzie do orkiestracji, zamiast liczyć na własną pamięć i dyscyplinę.
Na co uważać: Próg jest indywidualny — dla mniej doświadczonych może być niższy. Nie zwiększaj liczby agentów tylko dlatego, że narzędzie na to pozwala.
3.Work tree jako fundament bezkonfliktowej pracy równoległej
Na czym polega: Każde nowe zadanie odpalasz w osobnym work tree — izolowanej kopii projektu, w której zmiany nie kolidują z resztą.
Jak stosować: Dla każdego niezależnego zadania (nowa funkcja, audyt, przegląd) twórz oddzielny work tree, żeby agenci nie nadpisywali sobie nawzajem pracy.
Na co uważać: Izolacja ułatwia start, ale kiedyś trzeba zmiany zmergować. Pilnuj, czy commity faktycznie trafiają do głównej gałęzi — autor sam natrafił na przypadek, gdzie fix nie dotarł do produkcji.
4.Super Engineering to alpha — traktuj z ostrożnością
Na czym polega: Prezentowane narzędzie jest we wczesnej fazie rozwoju (alpha), mimo że robi dobre wrażenie.
Jak stosować: Przetestuj je na projekcie pobocznym, zanim wpuścisz do krytycznego workflowu; porównaj z alternatywami jak Conductor.
Na co uważać: Alpha oznacza możliwe błędy, zmiany API i brak stabilności. Nie polegaj na nim jako jedynym narzędziu w produkcji.
5.Integracja z Claude Max/Codex zamiast osobnej opłaty za platformę
Na czym polega: Narzędzie „podpina się” pod istniejącą instalację Claude Code i korzysta z twojej subskrypcji, zamiast wymuszać dodatkowy abonament jak Cursor.
Jak stosować: Jeśli już płacisz za Claude Max lub Codex, wybieraj rozwiązania open source, które te subskrypcje wykorzystują, by nie płacić podwójnie.
Na co uważać: Korzystanie z jednego planu przez wielu równoległych agentów może szybko zjadać limity użycia — obserwuj zużycie i ewentualne throttlowanie.
6.Twoje istniejące skille i workflowy działają od ręki
Na czym polega: Skille, pluginy i systemy, które masz już skonfigurowane na komputerze do Claude Code, współpracują z tym narzędziem bez dodatkowej konfiguracji.
Jak stosować: Zanim zbudujesz nowy proces, sprawdź, czy narzędzie do orkiestracji nie odziedziczy po prostu tego, co masz — subagentów, przeglądów kontradyktoryjnych, komend jak sync/archive.
Na co uważać: „Działa od ręki” nie znaczy „działa idealnie” — zweryfikuj, że twoje niestandardowe workflowy zachowują się tak samo jak w czystym Claude Code.
7.Wskaźniki statusu pozwalają wyłapać agenta, który czeka na człowieka
Na czym polega: Interfejs pokazuje sygnalizatory (np. pomarańczowy znacznik = potrzebny input), dzięki którym widać, który wątek wymaga twojej decyzji.
Jak stosować: Używaj tych wskaźników jako kolejki zadań — obsługuj najpierw agentów oznaczonych jako „czekający”, by nie blokowali dalszej pracy.
Na co uważać: Wizualne wskaźniki redukują chaos, ale nie zastępują weryfikacji merytorycznej odpowiedzi. Nie klikaj „dalej” bezrefleksyjnie, gdy agent prosi o input.
8.Konkretne role dla równoległych agentów
Na czym polega: Autor pokazuje sensowny podział pracy: szukanie i naprawa błędów, audyty wydajności, eksploracja nowych funkcji, budowa fragmentów po planie oraz przeglądy bezpieczeństwa.
Jak stosować: Przydzielaj agentom wyraźnie oddzielone role, zamiast dawać kilku z nich to samo zadanie — łatwiej wtedy śledzić postęp i wyniki.
Na co uważać: Zadania eksploracyjne (research) i budujące dają różnej jakości wyniki — research zwykle wymaga jeszcze twojej decyzji o kierunku, zanim ruszysz z implementacją.
9.Narzędzie jest agnostyczne wobec stacku i procesu
Na czym polega: Super Engineering nie narzuca technologii ani sposobu pracy — możesz łączyć je z Open Spec, „compound engineering” czy własnymi metodami.
Jak stosować: Traktuj je jako warstwę orkiestracji nad swoim istniejącym procesem, a nie jako zamiennik metodyki — dopasuj do tego, co już masz.
Na co uważać: Elastyczność oznacza też, że narzędzie nie narzuci dobrych praktyk. Jakość wyniku zależy od twojego procesu, nie od samego orkiestratora.
10.Porównaj alternatywy: Conductor, Cursor, Anti-Gravity
Na czym polega: To rozwiązanie wpisuje się w szerszy trend — Conductor (ładniejszy UI, słabszy onboarding) oraz podejścia w Cursorze i IDE Anti-Gravity robią rzecz podobną.
Jak stosować: Pobierz przynajmniej dwa narzędzia i przetestuj je na własnym projekcie, oceniając onboarding, UI i integrację z twoją subskrypcją.
Na co uważać: Wybór autora jest subiektywny i częściowo związany z jego płatną społecznością. Nie kieruj się wyłącznie jego rekomendacją — model cenowy i lock-in (jak osobna opłata w Cursorze) mogą przeważyć na twoją korzyść inaczej.