Kilku agentów AI w jednym projekcie: jak sprawić, żeby nie wchodzili sobie w drogę

Skąd biorą się konflikty

Z jedną sesją agenta kodującego sprawa jest prosta: jedno okno terminala, jedna rozmowa i jedno zadanie. Gdy uruchamiasz kilka sesji naraz w tym samym repozytorium, mogą pojawić się cztery kłopoty:

• Te same pliki. Sesje uruchomione w jednym katalogu pracują na tych samych plikach. Jedna może nadpisać pracę drugiej, a testy jednej mogą nie przechodzić z powodu niedokończonych zmian drugiej.
• Ta sama praca. Dwie sesje dostały podobne polecenia i obie robią to samo, każda po swojemu.
• Zła kolejność. Agent zaczyna pracę, która potrzebuje wyniku innej, jeszcze niedokończonej. Buduje na przykład ekran, który korzysta z jeszcze nieistniejącego API, i zgaduje, jak to API będzie wyglądać.
• Brak obrazu całości. Zadania znajdują się tylko w oknach terminala. Po godzinie trudno powiedzieć, która sesja robi co i co jest gotowe do sprawdzenia.

Wspólne pliki rozdziela osobny katalog dla każdej sesji. Podwójnej pracy i złej kolejności zapobiegają dwie zasady: jedna sesja realizuje jeden plan, a zależności między planami pokazują, co może ruszyć od razu. Obraz całości daje jedno miejsce, w którym te plany są zapisane.

Każda sesja we własnym katalogu

Każdej sesji, która zmienia kod, daj osobną kopię roboczą. Git ma do tego worktree: dodatkowy katalog roboczy tego samego repozytorium, z własnymi plikami i własną gałęzią, ale ze wspólną historią. Zakładasz go jednym poleceniem w katalogu projektu:

git worktree add -b backend ../sklep-backend

Sesja uruchomiona w ../sklep-backend pracuje na własnej kopii plików, więc jej zmiany nie trafiają do innych katalogów. Domyślnie Git nie pozwoli otworzyć tej samej gałęzi w dwóch katalogach naraz, dlatego każdy katalog ma swoją. Gałąź z każdego katalogu łączysz potem tak jak każdą inną.

Worktree to świeża kopia: nie ma w nim plików ignorowanych przez Git, na przykład .env, ani zainstalowanych zależności. Przygotuj je w każdym katalogu osobno.

Osobny katalog rozdziela pliki, ale nie mówi, która sesja ma robić co. Do tego potrzebne są plany.

Jedna sesja, jeden plan

Zadanie dla agenta zapisz jako plan: krótki dokument, który mówi, co trzeba zrobić, czego nie zmieniać i po czym poznać, że praca jest skończona. Takie podejście, w którym opis pracy powstaje przed kodem, nazywa się spec-driven development. Co wpisać do planu, żeby agent nie musiał zgadywać, opisuje wpis Jak napisać plan, który agent AI zrealizuje bez zgadywania.

Jedna sesja bierze jeden plan, realizuje go i zgłasza, co zrobiła. Kolejny plan dostaje nowa sesja albo ta sama po wyczyszczeniu rozmowy. Ta zasada daje trzy rzeczy:

• Skupiony agent. Agent ma przed sobą jeden cel i jeden opis gotowej pracy, a nie polecenia zebrane z całego dnia. Do modelu przy każdym zapytaniu trafia cała dotychczasowa rozmowa, a rozmowa o jednym zadaniu daje lepsze odpowiedzi i mniej kosztuje.
• Jasny odbiór. Gotowa praca odpowiada jednemu planowi, więc sprawdzasz ją według tego, co plan zapowiadał.
• Brak podwójnej pracy. Każdy plan ma jedną sesję, która go realizuje, więc dwie sesje nie zrobią tego samego.

Plan potrzebuje też granic: napisz, której części kodu dotyczy. Po granicach widać, czy dwa plany mogą iść równolegle, czy jeden musi zaczekać na drugi.

Zależności ustalają kolejność

Zależność to jedno zdanie: plan B czeka na plan A. Dopóki A nie jest zrealizowany, B nie powinien ruszyć. Agent nie musi wtedy zgadywać, czy praca, której potrzebuje, jest już gotowa.

Z zależności widać też, ile pracy może iść równolegle:

• Plany, które na nic nie czekają, są gotowe do podjęcia. Każdy z nich może dostać inna sesja.
• Plany, które czekają, ruszają dopiero po zrealizowaniu swoich poprzedników.
• Plan, na który czeka wiele innych, to wąskie gardło. Od niego warto zacząć, bo odblokuje najwięcej pracy.

Rozpisując pracę, staraj się, żeby jak najwięcej planów na nic nie czekało, a łańcuchy zależności były krótkie. Im więcej planów gotowych naraz, tym więcej sesji ma co robić. Długiego łańcucha nie przyspieszy nawet kilku agentów AI, bo każde ogniwo czeka na poprzednie.

Zależność warto zapisać także wtedy, gdy dwa plany nie potrzebują nawzajem swoich wyników, ale zmieniają ten sam plik. Inaczej ich zmiany mogą się zderzyć przy łączeniu gałęzi.

Krok po kroku

1. Rozpisz pracę na plany. Każdy ma jeden cel, granice i opis gotowej pracy.
2. Przy każdym planie zapisz, na co czeka. Sprawdź, które plany są gotowe do podjęcia.
3. Dla każdej sesji, którą chcesz uruchomić, załóż osobny katalog i gałąź.
4. Daj każdej sesji jeden gotowy plan.
5. Gdy sesja skończy plan, sprawdź pracę i połącz gałąź. Zobacz, które plany się odblokowały, i daj je wolnym sesjom.

Zarządzanie zadaniami agentów AI w featureloom

featureloom to tablica planów, z którą łączysz Claude Code, Codex albo Cursor przez zdalny serwer MCP. Tak połączonego asystenta AI featureloom nazywa konsolą. Zarządzanie zadaniami agentów AI wygląda w nim tak jak w krokach wyżej, tylko plany i zależności są zapisane na tablicy, a nie w oknach terminala.

• Plany i zależności. Plan to dokument na tablicy kanban. Na ekranie planu rozwijasz Zależności, naciskasz Dodaj zależność, wybierasz Czeka na… i znajdujesz plan, na który ma czekać. Zależności, przez którą dwa plany czekałyby na siebie nawzajem, featureloom nie przyjmie. Ekran Kolejność pokazuje, które plany epiku są gotowe do podjęcia, a plan oznaczony Wąskie gardło odblokuje najwięcej innych.
• Gotowe prompty. Każda nowa organizacja ma prompty Planista i Realizator. Planista mówi agentowi, że jeden plan to jedna praca, którą jedna sesja agenta zrealizuje w całości, i każe zapisać kolejność zależnościami. Realizator prowadzi agenta przez jeden plan, od wzięcia do zgłoszenia realizacji.
• Następny gotowy plan. Po poleceniu featureloom realizator bez numeru planu agent pyta featureloom o następny plan. Dostaje z kolumny oznaczonej stanem backlog najbliższy w kolejności tablicy plan, który na nic nie czeka i za który nie odpowiada ktoś inny. Planu, który czeka, konsola nie rozpocznie: serwer odmówi i poda numery planów, na które ten plan wciąż czeka.
• Dwie sesje, ten sam plan. Dwie konsole, które zapytają o następny plan w tej samej chwili, mogą dostać ten sam plan, ale podejmie go tylko jedna. Druga dostaje odmowę z nazwą tej, która go realizuje, i może zapytać o następny.
• Praca poprzedników. Polecenie z numerem planu, na przykład featureloom realizator FAK-15, daje agentowi w jednym wywołaniu prompt, cały plan i dokumenty zrealizowanych planów, na które ten plan bezpośrednio czeka.
• Kto co robi. Karta planu w realizacji pokazuje osobę, jej konsolę i krótki opis, który konsola może sama podać. Realizator każe agentowi podać go przy starcie: nazwę sesji albo komputer, repozytorium i gałąź. Gdy agent poda gałąź, a każdy katalog ma swoją, z karty od razu widać, w którym katalogu trwa praca.

Domyślne połączenie Claude Code to jedna konsola dla wszystkich katalogów na Twoim koncie systemu, więc agenci z każdego katalogu podpisują plany tą samą nazwą. Żeby ich rozróżnić, połącz osobną konsolę dla każdego katalogu. W menu otwórz Integracje, na karcie Twoje konsole naciśnij Połącz konsolę i wybierz Claude Code. W oknie naciśnij Pokaż zaawansowane i skopiuj polecenie przyciskiem Kopiuj polecenie dla katalogu. Wklej je w zwykłym terminalu systemu, a nie w oknie Claude Code, w katalogu, w którym uruchamiasz tę konsolę, na przykład w sklep-backend. Nazwę nowej konsoli, na przykład backend, zmienisz na karcie Twoje konsole. Taką konsolę uruchamiaj zawsze w jej katalogu: uruchomiona w innym, także w podkatalogu, nie zobaczy połączenia.

Szczegóły znajdziesz w samouczkach Twoje konsole i Epiki i Kolejność, a pracę całego zespołu opisuje strona Zespół z kilkoma agentami.