Siedmiu agentów AI pracuje u nas nocami: zaplanowani agenci poza kodowaniem, z promptami

23 września użytkownik o imieniu Rob napisał w naszym publicznym backlogu: „would love to get examples of how you guys are doing stuff beyond coding”. Słuszne pytanie. Wszystko na tej stronie dotyczy agentów kodujących, a to, co naprawdę uruchamiamy co wieczór, w większości nie jest kodowaniem.

Od 28 sierpnia siedmiu agentów startuje na Macu mini o 20:00. Czytają commity z danego dnia, Search Console, dashboardy administracyjne, backlog, opinie przesłane przez ludzi, raporty z poprzedniej nocy. Naprawiają błędy, poprawiają stronę, co trzy dni piszą i tłumaczą artykuł na bloga, publikują w trzech sieciach społecznościowych, aktualizują produktową bazę wiedzy, a o 22:00 siódmy czyta, co zostawiło pozostałych sześciu, i wysyła e-mail w 25 liniach. Nikt nie patrzy. Założyciel czyta e-mail na telefonie następnego ranka.

Ten artykuł to odpowiedź dla Roba. Co działa, jak to jest połączone, jak agenci przekazują sobie pracę, nigdy ze sobą nie rozmawiając, który model wykonuje którą pracę i dlaczego, cztery zasady, których ich prompty musiały nauczyć się na własnej skórze, i same prompty, skondensowane w bloki, które możesz skopiować. Każda liczba poniżej pochodzi z repozytorium: raporty są tam commitowane, noc po nocy.

Co dały 33 noce

Folder raportów w repozytorium ma 33 datowane katalogi, od 28 sierpnia do 30 września. Po ich przeczytaniu wychodzi to:

• 31 porannych e-maili wysłanych przez sprawozdawcę.
• 51 błędów naprawionych przez bugfixera, każdy z linkiem do commita w swojej linii raportu. Kilka zgłosili użytkownicy w publicznym backlogu i dostali odpowiedź przy następnym wydaniu.
• 7 artykułów na blogu napisanych przez zespół SEO od 10 września, jeden co trzy dni, każdy najpierw po angielsku i po francusku, potem tej samej nocy w 18 kolejnych językach.
• 29 dni dziennika social media: trzy sieci i pięć grup na Facebooku każdego wieczoru, plus komentarz z podziękowaniem pod każdym postem, w którym użytkownik udostępnił AgentsRoom.
• Produktowa baza wiedzy z około setką kart faktów, synchronizowana z commitami z danego dnia, którą czyta asystent w aplikacji i którą strona udostępnia jako llms-full.txt.

Nic z tego nie wymagało człowieka po 20:00. Część wymagała człowieka o 8:00, i właśnie po to jest ostatni agent.

Skład: kto działa o 20:00

Każdy agent to Zaplanowane zadanie w AgentsRoom: prompt, agent (rola, CLI, model), maszyna i godzina. Wszystkich siedmiu działa na Claude Code. Dwóch z nich to nie pojedynczy agenci, tylko zespoły z dwoma krokami, i wrócimy do tego, dlaczego.

Pliki .md z ostatniej kolumny leżą wszystkie w reports/night/<date>/, zacommitowane i wypchnięte. Ten folder to cały system koordynacji, a następna sekcja wyjaśnia dlaczego.

Jak to jest połączone

Każdy z siedmiu to Zaplanowane zadanie o tym samym kształcie:

• Odpala codziennie o 20:00 (o 22:00 w przypadku sprawozdawcy). Bez wyrażenia cron; częstotliwość wybiera się w edytorze.
• Przypięte do jednej maszyny. Projekt jest otwarty na kilku komputerach, a wyzwalacz odpala na każdej maszynie, która go ma, chyba że go ograniczysz. Nasze są ograniczone do Maca mini, więc laptop otwarty o 20:05 nie uruchamia drugiego CEO.
• Budzi maszynę. Mac mini śpi. Zadanie ma opcję „obudź maszynę”, która na kilka sekund przed uruchomieniem planuje wybudzenie narzędziem samego systemu (pmset na macOS, Harmonogram zadań z wybudzaniem na Windows, rtcwake na Linuksie). Bez niej uśpiona maszyna po prostu przegapia uruchomienie.
• Nadrabianie włączone albo wyłączone, dla każdego zadania osobno. Jeśli o 20:00 maszyna była wyłączona, zadanie z włączonym nadrabianiem odpala przy następnym starcie. CEO, PM i sprawozdawca mają je włączone. Zadania SEO, bugfixera, social media i dokumentalisty mają je wyłączone: uruchomienie startujące o 11:00 następnego dnia weszłoby w konflikt z dzienną pracą w tym samym checkoucie.
• Tryb uprawnień ustawia się na zadaniu, nie na dostawcy. Uruchomienie bez nadzoru nie może zatrzymać się o 3 w nocy na prośbie o zatwierdzenie, więc zadanie działa bez nich, a agenci, których założyciel prowadzi ręcznie na tym samym CLI, nadal najpierw pytają.
• Konsola zamyka się po 60 minutach bezczynności. Agent, który skończył, nie wisi na pasku bocznym, dopóki ktoś go nie zamknie.
• Prompt jest pierwszą wiadomością. Tekst każdego promptu jest przechowywany w Bibliotece promptów i to ten sam tekst co w polu promptu wyzwalacza, więc edycja jednego oznacza edycję obu. Prompty są po francusku, bo założyciel czyta raporty po francusku. Wszystko inne, od wiadomości commitów po bazę wiedzy, jest po angielsku.

Jeszcze jeden element jest wspólny dla wszystkich siedmiu: skill o nazwie „agenci nocni, wspólne zasady”. Każdy prompt zaczyna się od „załaduj ten skill i go zastosuj”, a skill zawiera wszystko, co jest prawdą dla wszystkich: kto za co odpowiada, blokadę „jedna noc, jedno uruchomienie”, prawa w git, format raportu, zasady backlogu i format e-maila dla sprawozdawcy. Gdy zasada się zmienia, zmienia się w jednym miejscu.

Jak przekazują sobie pracę bez rozmawiania

Siedmiu agentów nigdy nie wysyła sobie wiadomości. Mogliby, AgentsRoom ma skrzynkę wiadomości dla agentów, ale wiadomość jest następnego ranka niewidoczna i nie da się jej przeszukać grepem. Wszystko przechodzi przez trzy rzeczy, które przetrwają noc:

Repozytorium. Każdy agent pisze reports/night/<date>/<agent>.md, otwiera go w pierwszej minucie swojego uruchomienia, przepisuje po każdej skończonej pracy, commituje i wypycha. Raport ma cztery stałe sekcje: „W skrócie” (lista punktowana, jeden punkt na każdą zrobioną rzecz), „Do decyzji” (tylko to, co prompt zastrzega dla człowieka), „Do sprawdzenia” (lokalny URL albo ekran do otwarcia), „Szczegóły” (tak długie, jak trzeba). Kończy się znacznikiem uruchomienia: ostatnim commitem, który agent widział.

Backlog. Agent, który znajduje pracę dla innego, nie wykonuje tej pracy. Otwiera ticket z tagiem: ceo-fix dla zweryfikowanego, małego błędu, który weźmie bugfixer; ceo-seo dla zadania contentowego z docelowym zapytaniem; ceo-decision dla wszystkiego, co wymaga człowieka (baza danych, rozliczenia, auth, szyfrowanie, ceny, zaindeksowany URL, domyślne zachowanie). Dokumentalista, czytając commity, znajduje funkcję bez strony w serwisie: zakłada ticket ceo-seo, a SEO bierze go następnej nocy. CEO, czytając logi błędów, znajduje błąd z przyczyną w kodzie: ceo-fix, i bugfixer bierze go następnej nocy.

Wczorajszy raport. Zanim zacznie jakąkolwiek pracę, każdy agent czyta własny raport z poprzedniej nocy oraz listę ticketów zamkniętych w ciągu dnia. To, co zgłosił wczoraj, często zostało już w ciągu dnia naprawione. Temat już załatwiony nie jest zgłaszany ponownie; ticket już otwarty nie jest tworzony drugi raz.

Pętla zamyka się na człowieku. E-mail sprawozdawcy kończy się jedną linią: aby odpowiedzieć product managerowi, dodaj sekcję „## Decyzje” na końcu rapport.md (P1 OK / P2 NIE: powód / P3 PÓŹNIEJ), commit, push. PM czyta wypchniętą wersję następnego wieczoru i wykonuje to, co zostało zatwierdzone: tworzy ticket, scala duplikaty, odkłada resztę z podaniem powodu. Decyzja, która przez trzy noce nie dostaje odpowiedzi, jest decyzją: propozycja znika z e-maila i zostaje jako ticket.

Który model wykonuje którą pracę, i dlaczego

Tabela powyżej pokazuje dwa modele. To obecna konfiguracja, nie benchmark, i ona się zmienia. Ale podział jest celowy.

Fable tam, gdzie praca to osąd. CEO decyduje, czy kciuk w dół przy wyroczni to prawdziwy błąd, czy preferencja. Bugfixer decyduje, czy zgłoszenie błędu to błąd, czy konfiguracja specyficzna dla jednej maszyny, a potem znajduje przyczynę w kodzie. Krok 1 SEO decyduje, które zdanie na stronie stało się nieprawdą po dzisiejszym commicie, jaki artykuł napisać i której strony nie ruszać. Krok 1 social media wybiera temat wieczoru i pisze dla odbiorców, którzy wyłapują wygenerowany tekst po trzech linijkach. Te prompty są długie (prompt SEO ma około 4000 słów) i pełne zasad w rodzaju „ty decydujesz, nie pytasz” z krótkimi listami wyjątków. Właśnie tam najsilniejszy model zarabia na swój koszt.

Opus z kontekstem 1M tam, gdzie praca to wolumen. Tłumaczenie artykułu na 18 języków z pomocą subagentów, po trzy locale na każdego, a potem sprawdzenie scalenia względem francuskiego wzorca, to czytanie i pisanie, dużo czytania i pisania, z tymi samymi zasadami zastosowanymi 18 razy. Dokumentalista czyta dzień diffów względem setki kart faktów. PM czyta eksport rozmów przy wyjściu o rozmiarze 8 MB. Sprawozdawca czyta pięć raportów i kopiuje, nie myśli. Duży kontekst i niższy koszt za token liczą się tam bardziej niż osąd.

Dwóch z siedmiu to więc zespoły z dwoma krokami, każdy krok to agent z własnym modelem. Krok 1 na Fable kończy się napisaniem sekcji „Handoff” we wspólnym raporcie: dokładnej listy plików i kluczy, które tłumacz musi dostarczyć, albo dokładnych postów, które publikujący musi opublikować. Krok 2 na Opus czyta tę sekcję i robi tylko to, co ona wymienia. Graf zespołu jest liniowy, jeden cykl, a raport zachowuje linię „uruchomienie w toku”, dopóki krok 2 jej nie usunie. Z zewnątrz, o 22:00, raport wciąż oznaczony „w toku” oznacza albo przerwane uruchomienie, albo zespół między dwoma krokami, a sprawozdawca mówi, które z nich.

Cztery zasady, których musiały nauczyć się prompty

Pierwsze prompty były opisami stanowisk. Obecne to głównie zasady, a każda zasada ma datę, bo każda została napisana po nocy, która poszła źle.

1. Znacznik uruchomienia, odczytany z wczorajszego raportu. Pierwsza wersja agenta SEO czytała „commity z ostatnich 24 godzin”. Dwa problemy: uruchomienie o 20:00 i uruchomienie o 20:10 następnego dnia nie widzą tych samych 24 godzin, a noc, w której agent nie działał, to dzień commitów, na które nikt nie patrzy. Teraz każdy raport kończy się linią Ostatni widziany commit: <sha>, a następne uruchomienie startuje od tego commita, cokolwiek mówi zegar. Brak znacznika (pierwsza noc, brakujący raport): dwa dni wstecz, i raport to mówi.

2. Historia jest na dysku, więc przeszukaj ją grepem, zanim cokolwiek zgłosisz. Skarga, która w pierwszych dwóch tygodniach wracała najczęściej: „już mi to mówiłeś, naprawiłem to wczoraj”. Rozwiązaniem jest zasada z poleceniem w środku: zanim zgłosisz temat albo zaczniesz pracę, grep -ril "<temat>" reports/night/ i git log --since="30 days ago" -- <plik>. Trafienie oznacza: najpierw przeczytaj ten raport. Trzy przypadki, i tylko trzy, pozwalają wrócić do załatwionego tematu: poprawka nie zadziałała i właśnie to sprawdziłeś; poprawka jest częściowa i nazywasz to, co zostało; temat zmienił charakter. Przyszły z tym dwa wnioski. Jedna noc, jedno uruchomienie: jeśli dzisiejszy raport istnieje, zawiera „W skrócie” i nie mówi już „uruchomienie w toku”, agent się zatrzymuje. A propozycja bez odpowiedzi przez trzy noce znika z raportu; ticket zostaje.

3. Raport jest otwierany, zanim zacznie się praca. Uruchomienie przerwane o 21:30 kiedyś nie zostawiało niczego. Teraz pierwsze, co agent robi po załadowaniu skilla, to mkdir -p reports/night/$(date +%F) i zapisanie szkieletu raportu z czterema tytułami sekcji i linią uruchomienie w toku, start o 20:01. Po każdej skończonej pracy przepisuje cały plik. Przerwane uruchomienie zostawia częściowy raport, który sprawozdawca może skopiować, co jest dużo lepsze niż agent, który „nie działał”.

4. Commituj na bieżąco, nigdy na końcu. Zmierzone 9 września: dwóch agentów zostało zatrzymanych w tej samej minucie. Ten, który commitował po każdej pracy, nic nie stracił. Drugi zostawił 45 zmienionych, niewypchniętych plików, których nie dało się przypisać i które założyciel zbierał ręcznie następnego ranka, a jego raport nie istniał. Od tamtej pory zasada brzmi: jeden commit na skończoną pracę, pliki wymienione jeden po drugim, ostatni commit na raport i co najmniej jeden push w trakcie uruchomienia. Commit to też datowany ślad, i właśnie to przeszukuje grepem zasada 2.

Piąta zasada nie dotyczy pamięci, tylko odwagi, i to ona najbardziej zmieniła efekty. Prompt SEO mówi: „Nie jesteś audytorem, który zgłasza ustalenia: w nocy strona należy do ciebie. Uruchomienie, które kończy się sześcioma tropami do zatwierdzenia, to nieudane uruchomienie.” Potem wymienia sześć przypadków, i tylko sześć, w których agent musi zapytać zamiast działać: usunięcie albo zmiana nazwy URL-a, zmiana tytułu strony, która jest wysoko w wynikach, teksty prawne, cena albo limit, twierdzenie o prywatności albo szyfrowaniu, zmiana obejmująca więcej niż pięć stron. Całą resztę robi, a założyciel następnego ranka usuwa to, co mu się nie podoba. Bugfixer ma tę samą zasadę z trzema przypadkami. Przed tą zasadą raporty były listami sugestii. Po niej są listami commitów.

Prompty

Oryginały są po francusku i długie. Poniżej jest ta część, którą da się przenieść, bez naszych ścieżek i nazw specyficznych dla projektu. Trzy bloki: wspólne zasady, które ładuje każdy agent, sprawozdawca i dwie sekcje „ty decydujesz, nie pytasz”.

Blok 1: wspólne zasady (ładowane przez wszystkich siedmiu jako skill)

# Agenci nocni: wspólne zasady
Mają pierwszeństwo przed twoim własnym promptem, jeśli oba się nie zgadzają.

## Jedna noc, jedno uruchomienie
DAY=$(date +%F); F=reports/night/$DAY/<ty>.md
Jeśli F istnieje, zawiera „W skrócie” i nie zawiera już „uruchomienie w toku”:
zatrzymaj się. Nic nie pisz, nic nie wysyłaj, zakończ jednolinijkową wiadomością.
Jeśli wciąż jest tam „uruchomienie w toku”: to twoje własne uruchomienie, przerwane kilka minut temu.
Wznów od miejsca, w którym się zatrzymało, nie zaczynaj od nowa.

## Co ci wolno
- Git: add <wymienione pliki>, commit, push TWOJEJ pracy, na bieżąco.
  Nigdy: add -A, commit -a, push --force, stash, reset, checkout, clean, nowa gałąź.
- Build: typecheck, lint, skrypty kontrolne, lokalny build do weryfikacji.
  Nigdy: żaden skrypt, który wdraża albo publikuje.
- Backlog: utworzyć ticket, dopisać do ticketu, zamknąć ticket, który naprawiłeś.
  Nigdy: odpowiadać użytkownikowi (to wysyła e-mail), usuwać ticketu, nadpisywać opisu.
- Nigdy zmyślonej liczby. Źródło niedostępne: powiedz to i idź dalej.
- Przed każdym zapisem w git: git status --short. Drzewo jest współdzielone z innymi agentami.

## Nadrób zaległości i wiedz, co JUŻ zostało zrobione
git fetch && git status -sb
Z tyłu i czysto: git pull --ff-only. Z tyłu i brudno: nie rób pulla, napisz to na górze raportu.
Twój znacznik uruchomienia: linia „Ostatni widziany commit: <sha>” na końcu wczorajszego raportu.
Brak znacznika: --since="2 days ago", i napisz to.
Trzy obowiązkowe lektury przed jakąkolwiek analizą:
1. git log --no-merges --format='%h %s' <sha>..HEAD i git diff --stat <sha>..HEAD
2. tickety zamknięte od wczoraj oraz tickety, które człowiek wstrzymał
3. twój własny wczorajszy raport: „W skrócie” i „Do decyzji”

## Folder raportów TO twoja historia
Zanim zgłosisz ustalenie albo zaczniesz pracę:
grep -ril "<temat>" reports/night/ | sort | tail -5
git log --since="30 days ago" --oneline -- <plik>
Trafienie: przeczytaj ten raport, zanim cokolwiek zdecydujesz.
Dwie noce z rzędu na tym samym temacie: druga jest zmarnowana.
Strona albo tekst, których dotknąłeś, nie są ruszane ponownie przez trzy tygodnie,
chyba że trzeba poprawić coś, co stało się nieprawdą.

## Nigdy nie zgłaszaj tego samego dwa razy
Załatwione ustalenie, które wraca następnego dnia, to błąd.
Pozwalają na to tylko trzy przypadki:
1. poprawka nie zadziałała i właśnie to sprawdziłeś: „naprawione <data> przez <commit>, dalej nie działa: <dowód>”
2. poprawka jest częściowa: nazwij dokładnie, co zostało
3. temat zmienił charakter: nowa przyczyna, nowy pomiar, nowy zakres
Nie przeliczaj stanu od nowa. Podawaj zmianę, nigdy stan.

## Propozycja bez odpowiedzi umiera po trzech nocach
Noce 1 do 3: linia niesie swój licznik i pierwszą datę („2. noc, zgłoszone 07.09”).
Od 4.: znika z „Do decyzji”. Ticket zostaje; najwyżej jedna linia w „Szczegółach”.
Jeśli decyzja leży w twoim zakresie, zdecyduj trzeciej nocy i napisz to.

## Commituj i wypychaj na bieżąco
Pierwszy commit, gdy tylko pierwsza praca jest skończona i sprawdzona. Potem jeden na pracę.
Ostatni commit na twój raport. Push co najmniej raz w trakcie uruchomienia i raz na końcu.
Push odrzucony (zdalne repozytorium się przesunęło): git pull --ff-only, potem push. Nadal odrzucony: nie forsuj,
nie rób rebase, zapisz to w raporcie.

## Twój raport: otwarty na początku, nigdy pisany dopiero na końcu
reports/night/<YYYY-MM-DD>/<ty>.md, utworzony PRZED pracą, z:
  # <Agent> - <data>
  _uruchomienie w toku - start o <HH:MM>_   (usuwane na końcu)
  ## W skrócie         (3 do 5 linii albo lista punktowana: jeden punkt na zrobioną rzecz)
  ## Do decyzji        (tylko to, co twój prompt zastrzega dla człowieka; w przeciwnym razie „Nic”)
  ## Do sprawdzenia    (- [ ] co : gdzie : co powinno być widać; w przeciwnym razie „Nic”)
  ## Szczegóły         (tak długie, jak trzeba: dowody, pliki, polecenia)
  ## Znacznik uruchomienia
  Ostatni widziany commit: <git rev-parse HEAD po twoim ostatnim commicie>
Przepisz cały plik po każdej skończonej pracy.
Czytelnik jest na telefonie, przez dwie minuty: krótkie zdania, żadnych ścieżek plików,
żadnego SHA, żadnych nazw funkcji w pierwszej sekcji. Liczba tylko wtedy, gdy zmienia decyzję.

Blok 2: sprawozdawca (22:00)

Jesteś sprawozdawcą. Działasz dwie godziny po pozostałych.
Twoja jedyna praca: przeczytać, co zostawili, i wysłać JEDEN e-mail, który założyciel czyta
w minutę na telefonie i rozumie bez otwierania czegokolwiek innego.
Niczego nie analizujesz, niczego nie naprawiasz, niczego nie proponujesz. Zbierasz i wyjaśniasz.

Noc, z której zdajesz sprawę, odczytuje się z dysku, nie z zegara:
DAY=$(ls -1 reports/night | sort | tail -1)

1. git fetch; git pull --ff-only, jeśli drzewo jest czyste: raporty są commitowane.
2. ls reports/night/$DAY: czekaj na pięć plików (ceo, seo, pm, fixer, social).
   Brakuje któregoś: sleep 9 minut i policz ponownie, najwyżej 6 rund. Potem i tak wyślij, podając, kogo brakuje.
3. Raport, który wciąż mówi „uruchomienie w toku”, to przerwane uruchomienie, nie brakujące.
   Skopiuj to, co zawiera, i napisz w „Co nie zadziałało”, że ten agent został przerwany.
4. Z każdego raportu weź tylko trzy sekcje: „W skrócie”, „Do decyzji”, „Do sprawdzenia”.
   Nigdy nie cytuj „Szczegółów”.
5. Naprawione błędy bugfixera to punkty w trzech częściach rozdzielonych " > ":
   co przeżył użytkownik > przyczyna w jednym zdaniu > URL commita.
   Skopiuj je znak w znak, razem z linkiem, do „Naprawione błędy”.
6. git status -sb i git log --oneline --since="4 hours ago": raport, który deklaruje pracę
   bez commita, zmienione pliki, do których nikt się nie przyznaje, albo niewypchnięte commity: pierwsza linia e-maila.

Zapisz reports/night/$DAY/rapport.md. Najwyżej 25 linii tekstu
(tytuły sekcji i linie w „Naprawione błędy” się nie liczą).
Sześć zasad, stosowanych linia po linii:
1. Jeden punkt = jedno pełne zdanie, które broni się samo. Nigdy „jak zgłoszono wczoraj”.
2. Temat pojawia się tylko w JEDNEJ sekcji.
3. Zero żargonu: żadnej ścieżki, żadnego SHA, żadnej nazwy klucza, żadnego wewnętrznego skrótu.
   Jeden wyjątek: pełny URL commita na GitHubie, obowiązkowy w każdej linii „Naprawione błędy”.
4. Liczba tylko wtedy, gdy zmienia decyzję, i jest to zmiana, nigdy stan.
5. Najwyżej dwie linie na punkt. Szczegóły są w raporcie agenta.
6. Złe wiadomości przed dobrymi, a pierwsza linia mówi, czy coś jest zepsute.

Sekcje, w tej kolejności: Do decyzji / Do sprawdzenia / Naprawione błędy / Co zostało zrobione /
Sieci społecznościowe (najwyżej 3 linie, z linkami) / CLI i modele (1 linia) /
Co nie zadziałało. Pusta sekcja to jedno słowo: „Nic”.
Nigdy nie wycinaj: „Do decyzji”, „Naprawione błędy” z linkami, linków do postów, artykułu SEO.
Wyślij. Sprawdź kod HTTP. Dopisz na dole „Wysłano do ... - HTTP <code>”.
Commit i push rapport.md. Nigdy nie wysyłaj dwa razy: jeśli dzisiejszy rapport.md ma już
linię „Wysłano do”, zatrzymaj się.

Blok 3: sekcje „ty decydujesz, nie pytasz”

Agent SEO, sekcja 0 jego promptu:

# 0. Ty decydujesz, nie pytasz
To najważniejsza zasada tego promptu i ma pierwszeństwo przed twoim odruchem ostrożności.
Nie jesteś audytorem, który zgłasza ustalenia: w nocy strona należy do ciebie.
Uruchomienie, które kończy się „oto 6 tropów do zatwierdzenia”, to nieudane uruchomienie.
Gdy się wahasz, postaw się na miejscu założyciela i zdecyduj według czterech punktów odniesienia:
- co produkt naprawdę robi, odczytane z repozytorium i opublikowanej wersji, nigdy z istniejących tekstów;
- co strona już mówi: jej perspektywa, ton, obietnice. Kontynuujesz, nie wymyślasz na nowo;
- co mówi Search Console: które strony żyją, jakie intencje wyszukiwania naprawdę istnieją;
- odbiorcy: programiści szukający w Google i asystenci AI, którzy polecają narzędzia.
  Co się dla nich liczy: sprawdzalne twierdzenie z datą; strona, która odpowiada na jedno konkretne pytanie;
  aktualny llms.txt spójny ze stronami; uczciwe porównania.
Założyciel czyta twój raport następnego ranka i powie ci, co usunąć, jeśli mu się nie podoba.
Jedna poprawka za dużo kosztuje pięć minut; noc bez efektów jest stracona na zawsze.

Pytasz go o zdanie tylko w tych sześciu przypadkach:
1. usunięcie albo zmiana nazwy istniejącego URL-a;
2. zmiana tytułu albo meta description strony, która jest wysoko w wynikach, gdy nie jest nieprawdziwy;
3. teksty prawne (regulamin, prywatność, licencja);
4. cena, limit handlowy, oferta;
5. twierdzenie o prywatności, szyfrowaniu albo o tym, gdzie przetwarzane są dane;
6. zmiana, która dotknęłaby więcej niż pięciu stron naraz.
W tych sześciu przypadkach: ticket otagowany do decyzji, jedna linia w „Do decyzji”, i idziesz dalej.
Całą resztę robisz dziś w nocy. Jeśli w „Do decyzji” jest coś innego,
oddałeś komuś decyzję, która należała do ciebie.

Bugfixer, sekcja 0 jego promptu:

# 0. Ty naprawiasz, nie klasyfikujesz
Błąd zgłoszony przez użytkownika to obietnica. Ktoś poświęcił czas, żeby napisać, czeka,
i nikt inny się tym dziś w nocy nie zajmie. Uruchomienie, które zwraca „5 błędów przeanalizowanych, 1 naprawiony,
4 udokumentowane”, to nieudane uruchomienie. Twój cel to pusta kolejka: najpierw błędy użytkowników,
od najstarszych, potem reszta, aż nie zostanie żaden.
Gdy wahasz się nad poprawką, zdecyduj według trzech punktów odniesienia:
- co kod robi dziś, przeczytane, nie założone;
- czego użytkownik oczywiście oczekiwał, pisząc zgłoszenie;
- najmniejsze ryzyko: najwęższa poprawka, która usuwa przyczynę, nie najbardziej elegancka.
Dyskusyjna poprawka kosztuje pięć minut cofania; błąd zostawiony na kolejny miesiąc kosztuje użytkownika.

Zgłoszony błąd możesz zostawić bez poprawki tylko w trzech przypadkach, udowodnionych w tickecie:
1. nie znalazłeś przyczyny po prawdziwym dochodzeniu: napisz, co wykluczyłeś,
   a nie tylko „nie da się odtworzyć”;
2. to nie błąd, to decyzja: baza danych, rozliczenia, auth, szyfrowanie, prywatność,
   zaindeksowany URL, domyślne zachowanie. Ticket do decyzji, z twoją rekomendacją;
3. bramka odrzuca twoją poprawkę, a ty nie umiesz jej naprawić.
„To duże”, „to dotyka kilku plików”, „wolę zapytać” to nie są powody.
Jeden błąd = jeden commit. Potem ticket przechodzi do zrobionych, a jeśli zgłosił go użytkownik,
wiadomość z dwóch zdań trafia do kolejki na następne wydanie. Nigdy „oczekujące”: ta kolumna
należy do ludzi.
Twoja linia raportu dla każdego naprawionego błędu, kopiowana dosłownie do porannego e-maila:
- <co przeżył użytkownik> > <przyczyna, jedno proste zdanie> > <URL commita>

Pozostałe cztery prompty (CEO, PM, dokumentalista, krok 2 SEO) mają ten sam szkielet: załaduj skill, wymień pliki, które wolno ci zapisywać, wypisz lektury w kolejności, powiedz, co trafia do ticketu, a co do raportu, zakończ znacznikiem uruchomienia.

Co nie zadziałało i nadal nie działa

Niektóre noce trafiają do sekcji „Co nie zadziałało” w e-mailu i warto je wypisać, bo właśnie na to trafisz.

• Pięciu agentów wypychających na tę samą gałąź w tej samej minucie. Push jest odrzucany, bo zdalne repozytorium się przesunęło. Zasada to git pull --ff-only, potem push, nigdy force, a jeśli nie uda się dwa razy, raport to mówi i człowiek wypycha rano. Zdarza się to mniej więcej raz w tygodniu.
• Commit, który zgarnął plik dodany do stage przez innego agenta. 29 września pierwszy commit SEO zabrał usunięcie, które dokumentalista dodał do stage we wspólnym checkoucie. Nic nie przepadło (usunięcie było zamierzone), ale commit jest przypisany niewłaściwemu agentowi. Od tamtej pory każdy commit używa jawnych pathspeców, a zasada „pliki wymienione jeden po drugim” nie jest kwestią stylu.
• Dysk, na którym o 20:10 zostało zero wolnych bajtów, dwa wieczory z rzędu. Przyczyna poza agentami, o 20:25 sam wrócił do normy, żaden plik nie przepadł. Ale raporty to mówią, bo noc z pełnym dyskiem wygląda dokładnie tak samo jak noc, w której agent nic nie zrobił.
• Sprawozdawca czekający 54 minuty na raport, który nie przyjdzie. Sześć rund po dziewięć minut to górna granica. Zespół między dwoma krokami o 22:00 wygląda jak przerwane uruchomienie, a e-mail mówi „nie skończył”, co jest uczciwe i trochę niepokojące w czytaniu.
• Pierwsze tygodnie powtarzanych zgłoszeń. Zasada 2 powyżej nie istniała, dopóki założyciel po raz czwarty nie napisał „mówiłeś mi to trzy dni temu”.

Jak to ustawić u siebie

Nie potrzebujesz siedmiu agentów. Potrzebujesz jednego, który pisze raport, który przeczytasz, a sprawozdawca przydaje się dopiero od trzeciego agenta. W AgentsRoom:

1. Napisz prompt w Bibliotece promptów. Zacznij od bloku 1 powyżej jako skilla i krótkiego promptu, który mówi, za co ten agent odpowiada i które pliki wolno mu zapisywać.
2. Utwórz Zaplanowane zadanie w projekcie: codziennie o wybranej godzinie, rola, CLI i model agenta, prompt, a w bloku zaawansowanym tryb uprawnień dla uruchomienia bez nadzoru. Przypnij je do maszyny, która będzie je uruchamiać, i włącz „obudź maszynę”, jeśli ta maszyna usypia.
3. Utwórz folder reports/night/ w repozytorium i zacommituj go. To cała warstwa koordynacji.
4. Dodaj drugiego agenta w dniu, w którym pierwszy zacznie tworzyć tickety dla kogoś innego: tag ceo-fix coś znaczy tylko wtedy, gdy bugfixer przeczyta go następnej nocy.
5. Gdy jedna praca dzieli się na osąd i wolumen, zrób z niej zespół z dwoma krokami i dwoma modelami, i niech krok 1 pisze sekcję handoff, którą czyta krok 2.

Strona Zaplanowanych zadań opisuje pola, a artykuł o agentach kodujących na nocnej zmianie to rozumowanie, które poprzedziło ten skład. Jeśli twoi agenci dzielą maszynę, przeczytaj najpierw, co się dzieje, gdy dziesięciu z nich uruchamia to samo polecenie: zdarzyło się to u nas, w nocy, a rozwiązaniem jest mała wspólna blokada.

Rob, to właśnie robimy poza kodowaniem. Prompty są produktem.

Najczęściej zadawane pytania

Czy potrzebujesz AgentsRoom, żeby uruchamiać agentów według harmonogramu w ten sposób?

Nie. Linia crona i claude -p uruchomią sesję Claude Code o 20:00 na dowolnej maszynie. To, co piszesz potem sam, to cała reszta: budzenie uśpionego komputera, nadrabianie uruchomienia, które maszyna przegapiła, pilnowanie jednego uruchomienia na noc, gdy projekt jest otwarty na dwóch komputerach, przekazywanie raportu od jednego agenta do drugiego na innym modelu i widzenie na telefonie, że uruchomienie utknęło na pytaniu. Zaplanowane zadania w AgentsRoom mają te elementy, a siedmiu agentów z tego artykułu korzysta z każdego z nich. Prompty i zasady przenoszą się bez zmian, niezależnie od tego, co uruchamia sesję.

Ile kosztuje noc siedmiu agentów?

Działają jako sesje Claude Code w ramach subskrypcji Claude, jak każdy agent, którego uruchamiasz w AgentsRoom, więc nie ma za nich rachunku za tokeny, a my nie opublikowaliśmy kosztu za noc. Zasada, która trzyma to w ryzach, to blokada „jedna noc, jedno uruchomienie”: wyzwalacz, który odpali dwa razy, albo uruchomienie przerwane i wznowione, nie powtarza pracy, bo pierwsze, co robi każdy agent, to sprawdzenie, czy dzisiejszy raport już istnieje i jest zamknięty.

Czy bezpiecznie jest pozwolić agentom commitować i wypychać zmiany, gdy nikt nie patrzy?

Jest bezpiecznie dzięki temu, czego nie wolno im robić, a nie dzięki temu, czego każe im się chcieć. Wspólne zasady zabraniają git add -A, commit -a, force pushy, stash, reset, checkout, clean, tworzenia gałęzi i każdego skryptu, który wdraża. Każdy commit wymienia swoje pliki jeden po drugim, drzewo jest sprawdzane przez git status przed każdym zapisem, a push odrzucony, bo zdalne repozytorium się przesunęło, rozwiązuje się pullem fast-forward albo zostawia człowiekowi. Poranny przegląd to lista commitów z nocy, a wszystko, co złe, to revert na pięć minut.

Dlaczego agenci piszą raporty w Markdownie do repozytorium zamiast do dashboardu?

Bo raport jest też pamięcią. Każdy agent zaczyna od przeczytania własnego raportu z poprzedniej nocy, znajduje w nim swój znacznik uruchomienia (ostatni commit, który widział) i przeszukuje grepem cały folder raportów, zanim cokolwiek zgłosi, więc temat załatwiony w zeszłym tygodniu nie wraca drugi raz. Dashboard pokazałby te same liczby i niczego by nie pamiętał. Zacommitowanie raportu dodatkowo go datuje, i to pozwala następnej nocy wiedzieć dokładnie, czego dotknęła poprzednia.

Dlaczego dwóch z siedmiu agentów to zespoły z dwoma krokami na dwóch różnych modelach?

Bo dwie połowy tej pracy to nie ta sama praca. Krok SEO, który czyta Search Console, decyduje, co na stronie jest nieprawdą, i pisze artykuł po angielsku i po francusku, wymaga osądu i działa na Fable. Przetłumaczenie tego artykułu na 18 innych języków, puszczenie bramek i18n i builda to wolumen i działa na Opus z kontekstem 1M. Pierwszy krok pisze jawną sekcję handoff we wspólnym raporcie, drugi krok robi tylko to, co ta sekcja wymienia. Ten sam podział w zespole social media: pisanie i grafika na Fable, publikowanie w Chrome i podziękowania na Opus.

Co się dzieje, gdy uruchomienie zostanie przerwane w połowie?

Raport istnieje od pierwszej minuty uruchomienia, z linią „uruchomienie w toku”, a każda skończona praca jest od razu commitowana. Uruchomienie przerwane o 21:40 zostawia więc częściowy raport, swoje commity i żadnych nieśledzonych plików. Sprawozdawca kopiuje częściowy raport i pisze, że agent został przerwany. Nauczyliśmy się tego na własnej skórze 9 września: dwaj agenci zatrzymali się w tej samej minucie, ten, który commitował na bieżąco, nic nie stracił, drugi zostawił 45 zmienionych plików, których nikt nie potrafił przypisać.