Jak budują agenci: od specyfikacji do produkcji bez przekazywania pracy

Pierwszy pull request tego dnia został otwarty o 15:04 i scalony o 15:12, bez żadnego człowieka po drodze. Ta część wyjaśnia, jak to działa: jak agenci planują, jak pracują równolegle i nie wchodzą sobie w drogę, co im wolno, a czego nie, i jak kod trafia na produkcję bez przekazywania pracy między ludźmi. To najbardziej techniczna część serii. Jeśli coś brzmi zbyt technicznie, poproś asystenta na tej stronie, żeby wyjaśnił dowolny akapit prostymi słowami.

Najpierw plan: specyfikacje, testy i weryfikacja

Wywiad z części 1 uzupełnia to, czego AI nie wie. Dalej chodzi o metodę. Moi agenci korzystają z Superpowers, otwartego zestawu skilli dla agentów programujących. Wspólnie wypracowują projekt, piszą plan złożony z małych zadań ze ścieżkami plików i sprawdzeniami, piszą testy przed kodem, do każdego zadania uruchamiają świeżego subagenta i weryfikują wynik, zanim uznają cokolwiek za gotowe.

W tym przebiegu, zanim powstał jakikolwiek kod, Dispatcher wysłał trzech subagentów tylko do odczytu, żeby przestudiowali kod: stronę i wyszukiwanie, asystenta i jego koszty oraz panel administracyjny z CI i wdrożeniem. Na podstawie ich ustaleń w cztery minuty napisał dwa dokumenty: szkic formatu pliku artykułu i wspólną specyfikację dla wszystkich trzech funkcji, z pierwszymi ponumerowanymi decyzjami. Każdy późniejszy plan się do nich odwołuje.

Świeży subagent do każdego zadania to też mój sposób na zarządzanie kontekstem. Pamięć robocza agenta jest ograniczona, a im więcej w niej trzyma, tym gorzej i drożej pracuje. Każdy subagent dostaje więc tylko to, czego potrzebuje jego zadanie: opis, specyfikację i potrzebne pliki, a nie całą rozmowę. To, co musi przetrwać, jest zapisane w plikach (plany, decyzje, status), a nie w czyjejś pamięci. Główna sesja pozostaje mała, bo ciężka praca dzieje się gdzie indziej.

Ta struktura pozwala kilku agentom pracować równolegle bez nadzoru. Każdy dostaje pisemne specyfikacje, testy, które określają, kiedy praca jest skończona, i kroki do sprawdzenia wyniku. Ja skupiam się na specyfikacjach, testach i sprawdzeniach.

Żeby zobaczyć, jak to działa, zacznij od wpisu Jessego Vincenta What a year z października 2026, napisanego na pierwsze urodziny projektu i wydanie Superpowers 7.0, a potem zajrzyj do repozytorium.

Uwaga: brak definicji ukończenia. Agenci są tak dobrzy, jak definicja ukończenia, którą dostają. Plan bez testów pozwala równoległym agentom produkować wiarygodnie wyglądający kod, którego nikt nie sprawdził. Proś o specyfikację i testy, a nie tylko o demo. Ich przegląd to zadanie liderów technicznych i starszych specjalistów. Nie muszą sami pisać planów, projektów i testów, ale muszą je przejrzeć, uzupełnić luki i wziąć za nie odpowiedzialność. Delivery, program i project managerowie nadal odpowiadają za całość.

Wielu agentów, jeden właściciel integracji

Pracę podzielono na cztery pakiety: wspólne fundamenty, sekcję artykułów, panel administracyjny i asystenta. Każdy pakiet trafił do subagenta z samodzielnym opisem: planem, decyzjami i ich brzmieniem, zasadami projektu i metodami do użycia. Każdy pracował we własnej kopii repozytorium, na własnej gałęzi, więc równoległa praca nigdy nie dotykała tych samych plików na dysku. Fundamenty poszły pierwsze, a pozostałe trzy ruszyły, gdy tylko pozwoliły na to zależności.

Osobna praca oznacza też osobne sesje. Gdy agent z części 1 uwierzył nieaktualnemu dokumentowi, poprawka nie powstała w sesji, w której pracowałem. Na moje polecenie ta sesja przygotowała osobną na poprawkę i przekazała jej pracę, żebym mógł skupić się na głównym zadaniu. Główna sesja nie zapełnia się niezwiązaną pracą, a ta druga robi jedną rzecz. Wyczucie, kiedy zadanie zasługuje na własną sesję albo subagenta, przychodzi z praktyką.

Gdy ta druga sesja skończyła, nie pozwoliłem jej samej scalić zmian. Poprosiłem ją, żeby zapisała, co ustaliliśmy, zadała otwarte pytania, przekazała wszystko Dispatcherowi i się zamknęła.

Dwóch agentów zmieniających równolegle ten sam kod zderzy się ze sobą. Przy jednym Dispatcherze jest jeden właściciel scalania, a jeśli pojawi się konflikt, agent, który go rozwiązuje, ma pełny kontekst obu zmian. Mimo to równoległe pakiety w tym przebiegu zderzyły się kilka razy na wspólnej liście otwartych spraw, a jedno automatyczne scalenie stanęło, dopóki konflikt nie został rozwiązany.

To samo dotyczy zespołu. Jeśli każdy programista uruchamia własnych agentów na tym samym kodzie, będą sobie nawzajem nadpisywać pracę. Ja ten układ prowadziłem sam; dla zespołu najpierw przetestowałbym taki model:

• Wiele sesji albo programistów zasila jednego Dispatchera. Każda sesja przekazuje zadanie z już rozstrzygniętymi pytaniami i zamyka się, gdy jej specyfikacja jest kompletna.
• Pytanie zatrzymuje jedną gałąź, a nie cały przebieg. Gdy Dispatcher potrzebuje odpowiedzi, czeka tylko ten pakiet; reszta idzie dalej.
• Jeden dokument na koniec. Gdy każdy pakiet jest skończony albo zablokowany, zespół dostaje jeden dokument: podjęte decyzje (każdą można jeszcze zmienić), otwarte pytania i blokery oraz zadania, które może wykonać tylko człowiek, na przykład utworzenie sekretów albo zapłata za narzędzie.
• Jeden właściciel integracji. Wszyscy pracują równolegle na własnych gałęziach, a scala Dispatcher. Może ostrzec, że dana funkcja jest już w toku, i uruchamiać jedna po drugiej funkcje, które prawdopodobnie się zderzą.

Uwaga: agenci zderzają się w tym samym kodzie. Równolegli agenci mnożą nie tylko wynik pracy, ale też konflikty przy scalaniu. Zdecyduj, kto jest właścicielem integracji, zanim dodasz kolejnych agentów. Kierowanie pracy między agentów i ludzi tak, żeby się nie zderzali, to dziś podstawowa umiejętność zarówno inżynierów, jak i delivery managerów.

Co wolno agentowi

Pierwsze pytanie, jakie słyszę od innych delivery managerów, dotyczy kontroli: pozwalasz agentowi wdrażać na produkcję? Tak, w granicach zasad, które sam zapisałem w instrukcjach projektu dla agentów. Są krótkie:

• Bez pytania: scalić własny pull request, gdy wszystkie testy są zielone, wdrożyć główną gałąź na serwer skryptem wydania projektu, uruchomić testy na produkcji, przywrócić poprzednie wydanie, jeśli któryś test nie przejdzie, oraz czytać stan serwera i logi. Płatny test asystenta strony na prawdziwym modelu może kosztować najwyżej 0,50 USD za uruchomienie.
• Tylko za moją zgodą: wszystko, co dotyka sekretów albo konfiguracji serwera, konta zewnętrzne, wydatki powyżej tego limitu, wiadomości wysyłane w moim imieniu, teksty prawne i włączanie funkcji dla odwiedzających.
• Zawsze na piśmie: każda decyzja dostaje numer w rejestrze decyzji, razem z alternatywami. Każdy pull request wypisuje nowe zdania, które zobaczą odwiedzający. Każde działanie na serwerze trafia do podsumowania sesji, a Dispatcher prowadzi plik statusu z własnymi błędami.

Bardziej przydatny od zasad jest ten zapis. Gdy coś pójdzie źle, widzę, który agent co zrobił, kiedy i dlaczego, bez pytania kogokolwiek.

Bramki: CI, automatyczne scalanie i testy na produkcji

Tego delivery manager zwykle nie widzi: co dzieje się między "zatwierdzone" a "na produkcji". Po kolei:

• Wszystko zapisane. Kod jest w gałęziach i pull requestach, decyzje w ponumerowanym rejestrze, postęp i blokery w pliku statusu, dalsze kroki w otwartych sprawach, a nowe pomysły w backlogu. Mogę otworzyć każde z nich w dowolnej chwili.
• CI jako bramka. Zanim otworzy pull request, każdy subagent uruchamia lokalnie testy projektu: lint, typy, testy jednostkowe i build produkcyjny. Potem CI uruchamia je jeszcze raz, razem z kontrolami treści: żadnych półpauz, żadnych zakazanych zwrotów, żadnej liczby bez źródła. Dwa błędy w pakiecie fundamentów wyłapano, zanim pull request w ogóle powstał: pętlę w parserze list, przez którą procesowi testów skończyła się pamięć, i narzędzie do edycji, które w teście zamieniło znak ucieczki na zakazaną półpauzę.
• Automatyczne scalanie po zielonych testach. Pull request oznaczony do automatycznego scalenia scala ostatni krok CI, ale tylko wtedy, gdy wszystko jest zielone. Pierwszy otwarto o 15:04 i scalono o 15:12 bez człowieka po drodze. Po scaleniu wszystkie testy przechodzą jeszcze raz na głównej gałęzi, z tymi samymi ustawieniami co produkcja. Dopiero gdy i ten przebieg jest zielony, kod można wdrożyć.
• Wdrożenie z testami na produkcji. Na serwer trafia tylko zielona główna gałąź. Agent wdraża ją skryptem wydania i uruchamia stałą listę 294 testów na prawdziwej stronie. Jeśli któryś nie przejdzie, przywraca poprzednie wydanie i to zgłasza. Niedokończone funkcje zostają za flagą.

O 16:49 wszystkie trzy funkcje działały na produkcji za flagą:

Gdy wszystkie pakiety były gotowe, Dispatcher zamknął przebieg krótką wiadomością i pełnym raportem: co trafiło na produkcję, każde nowe zdanie widoczne dla odwiedzających, decyzje, które mogę jeszcze zmienić, jedno otwarte pytanie i jego własne porażki z przyczynami.

Zielone bramki powiedziały mi, że kod działa. Nie mogły mi powiedzieć, czy to jest to, czego chciałem. To sprawdzenie zostaje przy człowieku i o tym jest część 4.

Gdybym prowadził twój zespół

Zapisałbym uprawnienia agenta na jednej stronie, tak jak zrobiłem tutaj, i dał je do zatwierdzenia liderowi technicznemu zespołu. Postawiłbym też warunek: zanim jakikolwiek agent dostanie prawo do wdrażania, muszą działać testy na produkcji i automatyczne wycofanie.

Do pobrania

• Przykład: raport Dispatchera (po angielsku) (PDF, 688 KB). Raport zamykający pierwszy przebieg: co trafiło na produkcję, nowe zdania na stronie, decyzje, które mogę jeszcze zmienić, i porażki Dispatchera z przyczynami. Bez linków do repozytorium, danych serwera i wewnętrznych ścieżek.