Agent, który nie czeka na mnie

Sześć minut po tym, jak przekazałem pracę, Dispatcher wysłał mi dokument Word z pięcioma pytaniami i siedmioma decyzjami, które już podjął. W tym czasie już budował. Ta część jest o agencie, który zbudował trzy funkcje z części 1, i o kompromisie, na który poszedłem świadomie: szybkość teraz, poprawki później.

Krok 3: Dispatcher nie czeka na mnie

Gdy zakres jest ustalony, przekazuję pracę Dispatcherowi, agentowi AI, którego zbudowałem na Superpowers i na własnym doświadczeniu w dostarczaniu oprogramowania. Planuje pracę i kieruje innymi agentami; więcej o nim niżej. Działa we własnej sesji, dzieli pracę na pakiety i równolegle uruchamia subagentów, którzy piszą kod. Rzadko rozmawiam z nim bezpośrednio. Rozmawiam z jedną główną sesją, a ona przekazuje Dispatcherowi instrukcje.

Ustawiłem Dispatchera tak, żeby nie zatrzymywał się i nie czekał na mnie. Każdą decyzję podejmuje sam według własnej rekomendacji, pytania zapisuje w dokumencie Word i od razu zaczyna budować. Sześć minut po starcie dokument był gotowy: pięć pytań i siedem już podjętych decyzji, każda z alternatywami.

Od tej chwili praca idzie dwoma torami. Agent buduje. Obok niego ja czytam dokument, przeglądam jego wybory i wpisuję odpowiedzi w szare pola. Gdy odsyłam dokument, agent zmienia kurs w kodzie, który jest już w połowie napisany. W tym przebiegu moje odpowiedzi zmieniły cztery jego rekomendacje, w tym jedną, która podwoiła dzienny budżet asystenta. Przykład takiego dokumentu, z moimi odpowiedziami, jest na końcu tej części.

Gdy chcę wiedzieć, jak idzie, pytam. Dispatcher sam nie pisze kodu; robią to jego subagenci i raportują do niego, więc zawsze zna stan każdego pakietu. Mogę poprosić o status albo o zrzuty ekranu tego, co już zbudowano. W tym przebiegu poprosiłem o zrzuty panelu administracyjnego i strony artykułu i dostałem pięć, na danych testowych, jeszcze w trakcie pracy.

Uwaga: decyzje, których nikt nie podjął. Agent najpierw decyduje, a potem pyta, i dlatego jest szybki. To znaczy też, że spóźniona odpowiedź kosztuje przeróbkę, a pominięta odpowiedź zamienia się w decyzję, której nikt nie podjął. Ustal, o czym agent może decydować sam, prowadź pisemny rejestr decyzji, które podjął, a pomysły, które przychodzą w trakcie, odkładaj do backlogu. Ten rejestr zwraca się później: za każdym razem, gdy uchylam któreś z jego założeń, agent uczy się, jak decyduję, i z czasem mniej jego decyzji wymaga mojego przeglądu.

Agent uczy się, jak decyduję

W krótkiej przerwie w tym przebiegu poszedłem o krok dalej. Dispatcher porównuje teraz decyzje, które podjął, z tymi, które zostawiłem albo zmieniłem. W pierwszym pełnym przeglądzie przeszedł przez 22 wcześniejsze decyzje: w 16 przypadkach zdecydował tak jak ja, w 6 inaczej. Z tych pomyłek wyciągnął dwie lekcje o tym, jak decyduję. Jedna z nich: gdy wybiera najprostszą opcję, ja zwykle chcę pełniejszego zakresu. Nie przyjął tych lekcji sam. Zapytał mnie o każdą: czy ma obowiązywać we wszystkich projektach, tylko w tym, czy wcale?

Rejestr decyzji ma więc drugie zastosowanie. Jest moim zapisem, a jednocześnie materiałem, z którego agent się uczy. Każdy delivery manager będzie wkrótce musiał odpowiedzieć na nowe pytanie: kto zatwierdza to, czego agent nauczył się o tym, jak podejmujesz decyzje?

Porażka 2: link, którego nikt nie chciał

Dispatcher zwykle wysyła mi zrzuty ekranu stron razem z kolejną rundą pytań. Tym razem miałem wolną chwilę, więc poprosiłem o nie, gdy budowa jeszcze trwała. Na stronie artykułu znalazłem link "Read in Polish", którego nie powinno tam być; tę rolę pełni już przełącznik języka w nagłówku. Powiedziałem o tym Dispatcherowi.

Jego odpowiedź zmieniła obraz sytuacji. Strona była już na produkcji, wdrożona o 16:25, zanim zobaczyłem choć jeden zrzut. Była ukryta za flagą sekcji, starym trikiem z tradycyjnego wytwarzania oprogramowania, więc żaden odwiedzający jej nie widział. A link nie był błędem subagenta: prosił o niego opis zadania napisany przez samego Dispatchera. Poprawka trafiła do pakietu, który już pracował nad stroną artykułu, a Dispatcher zapisał porażkę razem z jej przyczyną.

Nie uważam za porażkę tego, że agent wdrożył przed moim przeglądem; tak to zaprojektowałem. Zbudowałem Dispatchera tak, żeby pracował, aż skończy, sam podejmował decyzje i pozwalał mi je poprawiać później. Nauczyłem się tego na własnej skórze. Wcześniej budowałem funkcje, odpowiadając co kilka minut na kolejne pytanie, i nie mogłem skupić się na niczym innym. Teraz Dispatcher pracuje, a na końcu każdej rundy pokazuje mi, co zbudował, i wypisuje każdą podjętą decyzję. Link "Read in Polish" i tak wyszedłby w tym przeglądzie, a flaga trzymała niedokończoną pracę z dala od odwiedzających.

Uwaga: przegląd po wydaniu, z założenia. Gdy pozwalasz agentowi najpierw decydować i wdrażać, zyskujesz skupienie, a płacisz poprawkami później. To działa tylko z zabezpieczeniami: flagami funkcji, żeby odwiedzający nie widzieli nieprzejrzanej pracy, pisemną listą każdej decyzji agenta i przeglądem implementacji, który naprawdę się odbywa. Jeśli twoje środowisko wymaga większej stabilności, niech agent wydaje na środowisko testowe albo stagingowe, a nie na produkcję. Ja też mam środowisko testowe, w którym agenci testują własną pracę. Zdecyduj, którego używasz, przed pierwszym przebiegiem.

Czym jest Dispatcher

Dispatcher to sposób pracy, który zbudowałem dla Claude Code na Superpowers (część 3 wyjaśnia, jak agenci planują) i na tym, czego nauczyłem się, budując z nim oprogramowanie. To zestaw pisemnych instrukcji, "skill", który zamienia jedną sesję AI w kogoś, kto prowadzi całą rundę pracy. Rozmawiam z jedną sesją, a praca toczy się za nią równolegle.

Jak to działa w skrócie:

1. Zbiera. Daję mu każdy pomysł na tę rundę.
2. Dzieli. Czyta kod, dzieli pomysły na pakiety pracy i rozpisuje zależności między nimi.
3. Decyduje albo pyta. Tam, gdzie jedna opcja jest wyraźnie lepsza, decyduje, buduje ją i zapisuje decyzję z alternatywami, żebym mógł ją później odwrócić. Do mnie trafia tylko to, czego nie może wiedzieć (strategia, pieniądze, konta, fakty o mnie), wszystko naraz, w jednym dokumencie.
4. Uruchamia. Każdy pakiet trafia do własnego subagenta na własnej gałęzi. Wiele może działać naraz; granicą są komputer, budżet i sam kod. Ile jest niezależnych funkcji i ilu agentów może pracować na tych samych plikach, zanim zaczną sobie przeszkadzać? Tysiąc agentów na jednym pliku nie ma sensu.
5. Integruje. Otwiera pull requesty, czeka na automatyczne testy, scala, wdraża, sprawdza produkcję i wycofuje wydanie, jeśli któryś test nie przejdzie.
6. Raportuje. Wraca dopiero wtedy, gdy wszystko jest skończone albo zablokowane.

Działa tak, bo moja uwaga jest najrzadszym zasobem w tym procesie. Pytania przychodzą w jednej paczce zamiast w strumieniu przerwań. Decyzje nie czekają na mnie, gdy odpowiedź jest jasna, ale każda jest zapisana. Niektóre rzeczy zawsze zostają przy mnie: hasła, płatności, wiadomości wysyłane w moim imieniu i konta zewnętrzne.

Dzięki temu mogę długo pracować w skupieniu, a każda decyzja jest zapisana.

Nie jestem już zawodowym programistą i są lepsze narzędzia do pisania kodu niż moje. Jeśli ci się przyda, skorzystaj z uproszczonej wersji poniżej.

Gdybym prowadził twój zespół

Uzgodniłbym krótką listę decyzji, które agent może podejmować sam, a wszystkie pozostałe kazałbym zbierać w jednym dokumencie na rundę. Przeglądałbym też ten rejestr decyzji co tydzień, a nie tylko wtedy, gdy coś się zepsuje.

Do pobrania

Bez linków do repozytorium, danych serwera i wewnętrznych ścieżek, po angielsku:

• Przykład: pytania Dispatchera (PDF, 148 KB). Dokument, który Dispatcher napisał sześć minut po starcie przebiegu: pięć pytań, siedem już podjętych decyzji i moje odpowiedzi.
• Uproszczony skill Dispatchera (MD, 6 KB). Ogólna wersja instrukcji, na których działa Dispatcher, do dopasowania do własnego projektu.