Poziom 5: prowadzisz fabrykę oprogramowania

Poziom 5 drabiny autonomii to fabryka oprogramowania: potok, w którym agenci biorą pracę z kolejki, budują ją, weryfikują i otwierają pull requesty, których nie napisał żaden człowiek. Fabryka ma sześć stanowisk (intencja, harness, pętla, graf, weryfikacja i wydanie), a pętla może działać bez nadzoru tylko wtedy, gdy o „gotowe” rozstrzyga wyrocznia, której agent nie może edytować.

Ta strona jest dla tech leada lub inżyniera platformy, który ma już za sobą pętle poziomu 4, i dla CTO, który decyduje, czy sfinansować pilotaż fabryki. Typowa sytuacja: twoje przebiegi z /goal kończą się w nocy, kolejka przeglądów stała się najwolniejszą częścią dostarczania, a ktoś pyta, czy agenci nie mogliby sami scalać aktualizacji zależności. Ta strona odpowiada, które pętle mogą, czego każde stanowisko potrzebuje najpierw i co do tego dostarczają Claude Code, Codex i Cursor.

Jak blisko ciemnej fabryki jest dziś ktokolwiek?

Dan Shapiro nazwał ten szczebel w tekście The Five Levels: from Spicy Autocomplete to the Dark Factory (23 stycznia 2026): to „czarna skrzynka, która zamienia specyfikacje w oprogramowanie”, gdzie „ludzie nie są ani potrzebni, ani mile widziani”. Umieszcza tam tylko „garstkę ludzi”, w zespołach „poniżej pięciu osób”.

Najlepiej udokumentowany przypadek produkcyjny, Minions Stripe’a, zostawia człowieka w pętli. Stripe podał, że ponad 1300 pull requestów tygodniowo jest „w całości wytworzonych przez minionów, przejrzanych przez ludzi, ale bez kodu napisanego przez człowieka” (Stripe, 19 lutego 2026). Agenci działają na „ponad trzech milionach” istniejących testów i dostają „najwyżej dwie rundy CI” (Stripe, 9 lutego 2026), zanim gałąź wróci do człowieka. Warstwa dowodów powstała przed agentami.

Koszt pominięcia tej warstwy też zmierzono. Telemetria Faros AI z 22 000 deweloperów (AI Engineering Report 2026, kwiecień 2026) pokazuje wzrost przepustowości zadań na dewelopera o 33,7% i wskaźnika scalania PR-ów na dewelopera o 16,2%, a jednocześnie wzrost incydentów na pull request o 242,7%, mediany czasu w przeglądzie o 441,5% i o 31,3% więcej pull requestów scalonych bez żadnego przeglądu. Traktuj więc poziom 5 jako cechę pojedynczych pętli, nigdy całej firmy.

Jakie stanowiska ma fabryka oprogramowania?

Każde stanowisko odpowiada za jedną decyzję. Stanowisko, które nie wytwarza dowodów, musisz nadzorować, czytając kod.

Stanowisko	Decyzja, za którą odpowiada	Dowód, który musi wytworzyć	Objaw, gdy go brakuje
Intencja	Co agent wie na starcie	Specyfikacja z kryteriami akceptacji i nazwanym warunkiem stopu	Wiarygodny kod, który rozwiązuje zły problem
Harness	Co agent może uruchomić i do czego sięgnąć	Polityka uprawnień i sandboksa w systemie kontroli wersji	Przebieg, który działa, bo miał więcej dostępu, niż powinien
Pętla	Kiedy agent się zatrzymuje	Warunek stopu sprawdzalny maszynowo i limit ponowień	Przebiegi, które nie kończą się wcale albo kończą się ogłoszeniem sukcesu
Graf	Kto co robi, gdy agentów jest kilku	Spisana topologia: planista, wykonawcy, sędzia, izolacja	Agenci nadpisujący sobie nawzajem pliki lub kontekst
Weryfikacja	Co liczy się jako dowód	Deterministyczne kontrole, których przebieg nie może edytować, plus wyniki przeglądu	Zielone kontrole na testach przepisanych przez agenta
Wydanie	Jak praca opuszcza budynek	Pakiet dowodów w pull requeście i nazwana osoba, która scala	Scalenie, którego nikt nie potrafi wyjaśnić tydzień później

Stanowiska są naniesione na cykl życia i drabinę na stronie jedna mapa. Pełny przewodnik budowy z rejestrem autonomii to fabryki oprogramowania.

Które pętle mogą działać bez nadzoru?

Poziom należy do pętli, nie do zespołu. O tym, czy pętla może działać po ciemku, rozstrzygają cztery pytania, a pętla musi przejść wszystkie cztery:

1. Jaka wyrocznia rozstrzyga o „gotowe”? Nazwij konkretną kontrolę. „Przechodzą testy i type checker” to wyrocznia. „Wygląda dobrze” nie jest.
2. Czy agent może ją oszukać? Jeśli agent może edytować wyrocznię, wyrocznia jest tylko sugestią. Testy w tym samym diffie z definicji oblewają to pytanie.
3. Po jakim czasie wychodzi na jaw błędna odpowiedź? Minuty to zaliczenie. „Klient zauważy za trzy tygodnie” to oblanie.
4. Jaki jest zasięg szkody, jeśli wynik jest błędny? Odwracalny i ograniczony to zaliczenie. Migracja schematu albo ścieżka płatności to oblanie.

Przyjmij tę tabelę jako regułę, którą zespół stosuje, zanim jakakolwiek pętla wyjdzie spod nadzoru:

Klasa pętli	Wyrocznia	Agent może ją edytować?	Czas do wykrycia	Zasięg szkody	Werdykt
Aktualizacje zależności patch i minor	Pełny zestaw CI	Nie, jeśli konfiguracja CI i testy są chronione	Minuty	Jeden commit do odwrócenia	Bez nadzoru, scala człowiek
Migracje lintera i codemody	Linter plus type checker	Nie, jeśli konfiguracja reguł jest chroniona	Minuty	Mechaniczne, odwracalne	Bez nadzoru, scala człowiek
Kwarantanna niestabilnych testów	Statystyki ponownych uruchomień z historii CI	Tak, chyba że kwarantanna żyje poza repozytorium	Dni	Ukrywa prawdziwe awarie	Pod nadzorem
Funkcje ze specyfikacji	Testy akceptacyjne napisane razem ze specyfikacją	Tak, jeśli są w tym samym diffie	Dni do tygodni	Zachowanie produktu	Pod nadzorem, przegląd dowodów
Uwierzytelnianie, pieniądze, schemat, migracje	W najlepszym razie częściowa	Zależnie od przypadku	Tygodnie	Nieodwracalny	Zostaje u człowieka, który czyta kod

Ostatni wiersz to krótka lista klas zmian, w których ktoś nadal czyta kod; dlaczego, wyjaśnia strona czytanie dowodów zamiast kodu.

Prompt do skopiowania: znajdź pierwszą pętlę, która może działać po ciemku

Read the last 60 merged pull requests in this repository (use `gh pr list
--state merged --limit 60 --json number,title,files,labels`) and group them
into loop classes: repeated kinds of change such as dependency updates, lint
fixes, flaky tests, copy changes or feature work.
For each class, answer the autonomy ledger in a markdown table:
1. the oracle that decides "done", as a command that exits 0;
2. whether an agent working on that class could edit that oracle, citing
   the file paths it would have to touch;
3. how long a wrong change of that class took to surface, using reverts and
   follow-up fixes in the git log as evidence;
4. the blast radius if it is wrong.
End with the single class that passes all four, or say that none does and
name the one change that would make the best candidate pass.
Do not modify any files.

Jak uruchomić pierwszą pętlę fabryki?

Buduj pętle po jednej, zaczynając od harnessu. Kroki używają aktualizacji zależności, pierwszego wiersza tabeli, bo jej wyrocznia już istnieje.

1. Zapisz intencję jako plik w repozytorium, na przykład .factory/dep-bump.md, żeby każdy przebieg dostawał te same instrukcje, a prompt przechodził code review jak każda inna zmiana. Jako treść użyj promptu poniżej.

2. Wynieś wyrocznię poza zasięg agenta. Dodaj wpis w CODEOWNERS dla tests/, .github/ oraz konfiguracji lintera i typów i włącz w regułach gałęzi „Require review from Code Owners”; sam plik CODEOWNERS tylko prosi o recenzję. Ustaw kontrole CI jako wymagane i dodaj krok CI z sekcji o awariach poniżej, który oblewa każdą gałąź z fabryki zmieniającą chronione ścieżki. Przebieg nadal może zmienić kod, ale nie scali słabszego testu. Hooki i testy holdout opisuje strona ochrona wyroczni.

3. Ustal harness. Uruchamiaj agenta w jednorazowym zadaniu CI lub środowisku chmurowym z jawną listą dozwolonych narzędzi, limitem wydatków i bez sekretów poza poświadczeniem do modelu. Rób checkout z persist-credentials: false, żeby w .git/config nie leżał token z prawem zapisu, gdy działa agent. Otwarcie pull requesta to osobne zadanie (job), w którym nie działa żaden agent: zadanie agenta wgrywa swoje zmiany jako artefakt z patchem, a drugie zadanie, z własnym, wąsko ograniczonym tokenem (contents: write, pull-requests: write), nakłada patch, robi push i otwiera pull request.

4. Uruchom pętlę w trybie headless w nieinteraktywnym trybie narzędzia (polecenia poniżej). Warunek stopu pętli jest w prompcie: najwyżej dwie próby naprawy, co odpowiada dwóm rundom CI u Stripe’a.

5. Wydawaj z dowodami, nie z diffem. Pull request zawiera podsumowanie przebiegu, kody wyjścia trzech kontroli i link do changeloga zależności. Człowiek scala na podstawie tego pakietu dowodów i czyta kod tylko wtedy, gdy dowody są niepełne.

6. Mierz, zanim poszerzysz. Przez cztery tygodnie śledź dla pętli odsetek rewertów, incydenty na pull request i czas oczekiwania na przegląd. Drugą klasę pętli dodaj dopiero wtedy, gdy te trzy liczby są stałe albo lepsze.

Prompt do skopiowania: stanowisko budowy dla aktualizacji zależności

You are the build station of a dependency-update loop. Scope: one outdated
direct dependency per run, patch or minor versions only. If the only update
available is a major version, stop and report it.
1. Run `npm outdated --json`, pick the patch or minor update that has been
   available longest, and update only that package and the lockfile.
2. Run `npm test`, `npm run lint` and `npm run typecheck`. If any fails, fix
   the application code, never the tests, the lint config or the type config.
   Make at most two fix attempts, then stop.
3. Do not edit anything under tests/ or .github/, or any lint or tsconfig file.
4. Finish with a JSON summary: package, from, to, each of the three commands
   with its exit code, the files you changed, and "status": "ready" or
   "needs-human" with a one-sentence reason.

Każde polecenie headless uruchamiasz z katalogu głównego repozytorium w zadaniu CI lub jednorazowym runnerze z kroku 3.

Claude Code

Tryb dontAsk automatycznie odrzuca każde wywołanie, które wymagałoby zgody, więc przebieg nigdy nie czeka na odpowiedź: działają tylko odczyty plików, polecenia tylko do odczytu i narzędzia z listy dozwolonych.

claude -p "$(cat .factory/dep-bump.md)" \
  --permission-mode dontAsk \
  --allowedTools "Read" "Edit" "Bash(npm outdated *)" "Bash(npm install *)" \
    "Bash(npm test)" "Bash(npm run lint)" "Bash(npm run typecheck)" \
  --max-budget-usd 5 \
  --output-format json > .factory/last-run.json

Do przebiegów z harmonogramu bez własnego CI służy routine: uruchamia ten sam prompt jako sesję w chmurze według harmonogramu, z wywołania API albo ze zdarzenia GitHuba. Routines (rutyny) nie mają wyboru trybu uprawnień ani pytań o zgodę w trakcie przebiegu, więc lista dozwolonych narzędzi żyje w środowisku, nie w sesji.

Codex

codex exec nie potrzebuje flagi zatwierdzeń: nie ma własnego -a i zawsze działa z zatwierdzaniem never, więc polecenie spoza sandboksa kończy się błędem zamiast czekać na odpowiedź (sprawdzone w CLI 0.157.1). Sandbox workspace-write ogranicza dostęp do sieci, dopóki go nie włączysz, a ta pętla potrzebuje rejestru pakietów.

codex exec \
  --sandbox workspace-write \
  -c sandbox_workspace_write.network_access=true \
  -o .factory/last-run.md \
  "$(cat .factory/dep-bump.md)"

Starsze --sandbox nadal działa w 0.157.1; OpenAI woli teraz profile uprawnień (beta, -c default_permissions=":workspace"). Nie łącz profilu z --sandbox, dopóki tego ponownie nie sprawdzisz, bo według OpenAI tych dwóch systemów nie da się łączyć.

Do przebiegów cyklicznych służą automatyzacje (Automations) w Codeksie, które planują to samo zadanie w tle. W CI ten sam nieinteraktywny przebieg opakowuje openai/codex-action@v1.

Cursor

CLI Cursora ma tryb print (-p, --print) i działa w GitHub Actions, ale dla pętli fabryki prostszą drogą jest Automation z wyzwalaczem Scheduled lub Source control, która uruchamia Cloud Agenta z .factory/dep-bump.md jako zadaniem. Cloud Agents działają w izolowanych maszynach wirtualnych, a Cloud Agents API wysyła webhook statusChange, gdy przebieg się skończy, więc twoje systemy poznają wynik bez odpytywania (dokumentacja Cursora, sprawdzona 2026-08-28).

Uwaga

Nigdy nie dodawaj --dangerously-skip-permissions, bypassPermissions ani --dangerously-bypass-approvals-and-sandbox z Codeksa do pętli fabryki poza jednorazowym sandboksem z ograniczoną siecią. Pętla, która potrzebuje pełnego dostępu, żeby przejść, mówi ci, że jej harness jest zły.

Skąd wiesz, że wynik fabryki jest poprawny, bez czytania każdego diffa?

• Decydują deterministyczne bramki, modele doradzają. Typy, testy, linter i kontrole migracji, które w razie wątpliwości blokują, rozstrzygają, czy zmianę można scalić. Agenci przeglądający, tacy jak /code-review w Claude Code, /review w Codeksie i Bugbot w Cursorze, dokładają ustalenia, ale żaden z nich nie jest deterministyczny, więc żaden nie może być jedyną bramką.
• Wyrocznia żyje poza diffem. Wymagane kontrole pochodzą z workflow, którego gałąź z fabryki nie może zmienić: z reguły „Require workflows to pass” przypiętej do gałęzi domyślnej albo z zadania pull_request_target (zadanie pull_request_target nie może pobierać ani uruchamiać kodu gałęzi, mając dostęp do sekretów; testy gałęzi uruchamiaj w osobnym zadaniu bez uprawnień), a krok CI oblewa każdą gałąź z fabryki, która dotyka .github/. Workflow pull_request uruchamia się z własnego merge refa gałęzi, więc gałąź, która go edytuje, zmienia własną kontrolę. CODEOWNERS z wymaganym przeglądem właścicieli kodu obejmuje ścieżki testów i konfiguracji, a zestaw holdout, którego agent nigdy nie widzi, wykrywa nadmierne dopasowanie do widocznych testów.
• Każdy pull request niesie pakiet dowodów: plik intencji, polecenia i kody wyjścia, ustalenia z przeglądu i log przebiegu. Jak go czytać, opisuje strona przegląd PR-ów od agentów.
• Audyt próbkowy zastępuje przegląd linijka po linijce. Co tydzień wyznaczony właściciel czyta od początku do końca małą losową próbkę scalonych pull requestów z fabryki. Jeśli próbka znajdzie defekt, który przeszedł przez bramki, pętla wraca pod nadzór, dopóki nowa kontrola nie pokryje luki.
• Cztery liczby na pętlę: odsetek rewertów, incydenty na pull request, czas oczekiwania na przegląd i odsetek scaleń bez zatwierdzenia przez człowieka.

Właściciel pętli podpisuje się pod pętlą, a osoba scalająca pod każdym pull requestem na podstawie jego dowodów. Nikt nie podpisuje się pod „fabryką” jako całością; czytanie styków między stanowiskami to zadanie człowieka.

Prompt do skopiowania: napisz kontrakt weryfikacyjny dla jednego stanowiska

Station: verification. Loop: patch and minor dependency updates.
Write the station's contract as a markdown table with one row each for: the
inputs it accepts; the deterministic validators that must pass before
hand-off, each as a command that exits 0; whether the agent can edit any of
those validators, and if it can, a replacement that lives outside the diff;
the failure route, naming which station receives a FAIL and what it gets
back; the maximum retries before the run stops; and the human escalation
trigger. Then answer the autonomy ledger for this loop: what oracle decides
done, can the agent fake it, how long until a wrong answer surfaces, and
what the blast radius is. End with a one-line verdict: runs unattended, or
stays supervised and why.

Co każde narzędzie dostarcza dla każdego stanowiska?

Wiersze Claude Code, łącznie z komórkami „Nieudokumentowane”, sprawdzono ponownie 2026-09-26 w code.claude.com i w zainstalowanym CLI (2.1.283). Wiersze Codeksa sprawdzono 2026-09-26 w CLI 0.157.1 tam, gdzie CLI je pokazuje, a w pozostałych przypadkach w dokumentacji OpenAI 2026-08-28. Wiersze Cursora zweryfikowano ostatnio 2026-08-28, bo 2026-09-26 cursor.com był nieosiągalny. „Nieudokumentowane” oznacza lukę w dokumentacji w danym dniu, a nie dowód, że narzędzie tego nie potrafi. Sprawdź stronę producenta w dniu, w którym na niej budujesz.

Intencja: kontekst, procedura i plan

Możliwość	Claude Code	Codex	Cursor
Trwałe instrukcje projektu	CLAUDE.md i auto memory	AGENTS.md	Rules
Procedura wielokrotnego użytku	Skills	Skills (/skills)	Agent Skills
Paczka do dystrybucji	Plugins	Plugins (codex plugin)	Plugins
Plan przed implementacją	Plan mode (/plan)	Plan mode (/plan)	Plan Mode
Wskazówki, jak zapisać weryfikowalny cel	Write an effective /goal condition: stan końcowy, wskazana kontrola, ograniczenia	Long-running work: wynik, ograniczenia, weryfikacja	Nieudokumentowane (2026-08-28)

Obaj producenci opisują te same trzy części: wynik, kontrolę, która go dowodzi, i to, czego nie wolno zmienić. Przenieś je do każdego pliku intencji, niezależnie od tego, które narzędzie go uruchamia.

Harness: uprawnienia, sandbox i moc obliczeniowa

Możliwość	Claude Code	Codex	Cursor
Polityka uprawnień	Tryby uprawnień: Manual, acceptEdits, plan, auto, dontAsk, bypassPermissions	Polityki zatwierdzania untrusted, on-request (domyślna), granular, never; profile uprawnień (beta)	Run modes
Zgody wydawane przez model	Klasyfikator trybu auto	Auto-review (--approve-for-me)	Auto-review dla lokalnych wywołań narzędzi
Sandbox systemu operacyjnego	Sandboxed Bash (macOS, Linux, WSL2)	Tryby --sandbox i codex sandbox	/sandbox w CLI
Hooki cyklu życia	Hooks	Hooks (wymagają zapisanego zaufania)	Hooks
Narzędzia zewnętrzne	MCP	MCP (codex mcp)	MCP
Własna moc obliczeniowa	Self-hosted environments (beta w Team i Enterprise)	Nieudokumentowane (2026-08-28)	Private workers w Cloud Agents API
Przekazywanie zdarzeń z zewnątrz do działającej sesji	Channels (research preview)	Nieudokumentowane (2026-08-28)	Nieudokumentowane (2026-08-28)

Klasyfikator Claude Code blokuje działania, które wykraczają poza prośbę, celują w nierozpoznaną infrastrukturę albo wyglądają na sterowane wrogą treścią: to ocena wydawana przez model. W pętli bez nadzoru wybierz jawną listę dozwolonych narzędzi, a każdy klasyfikator traktuj jako drugą linię.

Pętla: warunki stopu, harmonogramy i przebiegi headless

Możliwość	Claude Code	Codex	Cursor
Cel lub warunek stopu	/goal	/goal (stabilne, domyślnie włączone)	/goal (wdrażane, 2026-08-19)
Pętla interwałowa	/loop	Brak /loop (sprawdzone 2026-09-26, CLI 0.157.1)	Wbudowany skill /loop
Przebiegi bez nadzoru z harmonogramu	Routines (research preview, minimum godzina)	Automations	Automations
Wywołanie headless	claude -p	codex exec	Tryb print (-p)
SDK do programowania	Claude Agent SDK	Codex SDK	@cursor/sdk, cursor-sdk
Izolowany przebieg w chmurze	Claude Code on the web	Codex cloud	Cloud Agents

Wyzwalacze różnią się bardziej niż same uruchamiacze: routines startują z harmonogramu, wywołania API albo zdarzenia GitHuba; automatyzacje (Automations) w Codeksie wymieniały jako źródła zdarzeń Gmaila, Slacka i aktywność w pull requestach na GitHubie (2026-08-28); automatyzacje w Cursorze dokładają Webhook, Linear, Sentry i PagerDuty. Jeśli twoja fabryka bierze pracę z kolejki, ta lista wyzwalaczy jest tą kolejką.

Graf: wielu agentów bez kolizji

Możliwość	Claude Code	Codex	Cursor
Delegowani subagenci	Subagenci, domyślnie 20 działających na sesję	Subagenci (/subagents)	Subagenci, na własnych maszynach wirtualnych od 2026-08-19
Równorzędni agenci, którzy piszą do siebie	Agent teams (eksperymentalne, domyślnie wyłączone)	Nieudokumentowane (2026-08-28)	Nieudokumentowane (2026-08-28)
Orkiestracja sterowana skryptem	Dynamic workflows	Nieudokumentowane (2026-08-28)	Nieudokumentowane (2026-08-28)
Izolacja systemu plików	Worktrees (--worktree)	Worktrees (--worktree, /worktree)	Worktrees
Jeden ekran dla wielu agentów	Agent view (claude agents, research preview)	Centrum dowodzenia codex agents	Agents window

Dynamic workflows „orkiestrują wielu subagentów ze skryptu, który pisze Claude, a ty możesz go uruchomić ponownie”: to hala fabryczna, którą da się wersjonować. Topologię planista, wykonawcy i sędzia we wszystkich trzech narzędziach opisuje strona wzorce orkiestracji. Ogólna nazwa koordynowania wielu agentów w ten sposób to orkiestracja agentów.

Weryfikacja: przegląd i wycofanie

Możliwość	Claude Code	Codex	Cursor
Przegląd lokalnego diffa	/code-review	/review, codex review	Nieudokumentowane (2026-08-28)
Głęboki przegląd wieloagentowy	Ultrareview: /code-review ultra lub claude ultrareview	Nieudokumentowane (2026-08-28)	Nieudokumentowane (2026-08-28)
Zarządzany przegląd pull requestów	Code Review (research preview, Team i Enterprise)	@codex review na GitHubie i GitLabie	Bugbot
Przegląd bezpieczeństwa	/security-review, plugin Claude Security	Codex Security, @codex security review	Security Agents
Cofnięcie zmian	Checkpointy (/rewind)	Nieudokumentowane (2026-08-28)	/rewind w CLI

Najdalej idzie Ultrareview: „każde zgłoszone ustalenie jest niezależnie odtworzone i zweryfikowane”. Nadal jednak zwykle trwa od 5 do 10 minut i po darmowych przebiegach kosztuje zwykle od 5 do 25 dolarów za przegląd, więc pasuje do zmian wysokiego ryzyka, a nie do każdego pull requesta z fabryki.

Wydanie: CI, wyzwalacze i obieg w obie strony

Możliwość	Claude Code	Codex	Cursor
Uruchamianie w CI na GitHubie	anthropics/claude-code-action@v1	openai/codex-action@v1	Cursor CLI w GitHub Actions
Uruchamianie w GitLabie	GitLab CI/CD	Przegląd merge requestów (@codex review)	Integracja z GitLabem
Wyzwalanie z własnych systemów	Wyzwalacz API w routines	Nieudokumentowane (2026-08-28)	Wyzwalacze Webhook
Powiadomienie wychodzące o stanie przebiegu	Nieudokumentowane (2026-09-26)	Nieudokumentowane (2026-08-28)	Webhooki (statusChange)
Kierowanie i zatwierdzanie pull requestów	Nieudokumentowane (2026-09-26)	Nieudokumentowane (2026-08-28)	PR Routing & Approval (dokumentacja producenta)
Sterowanie przebiegiem z telefonu	Remote Control	Codex Remote (codex remote-control, eksperymentalne)	Cloud Agents na urządzeniach mobilnych

Liczy się luka w obiegu w obie strony. Wyzwalacz API w routine „zwraca URL sesji”, ale Claude Code nie dokumentuje webhooka wychodzącego, więc twoje systemy muszą odpytywać. Cursor dokumentuje oba kierunki.

Gdzie fabryka oprogramowania gnije najpierw

Kolejka wyprzedza możliwości przeglądu. Objaw: czas oczekiwania na przegląd rośnie z tygodnia na tydzień, a przepustowość wygląda zdrowo, czyli wzorzec z raportu Faros. Naprawa: ogranicz liczbę otwartych pull requestów z fabryki na pętlę, wstrzymuj przyjmowanie pracy po osiągnięciu limitu i przenieś recenzentów z diffa na pakiet dowodów.

Wyrocznia dryfuje w zasięg agenta. Objaw: zielony przebieg, którego diff dotyka testu, snapshotu albo reguły lintera. Naprawa: wycofaj zmianę, dodaj ścieżkę do CODEOWNERS i dodaj krok CI, który oblewa gałąź z fabryki modyfikującą chronione ścieżki.

Przebiegi bez nadzoru dziedziczą wczorajsze uprawnienia. Routines i automatyzacje z założenia działają bez pytań o zgodę, więc o 3 w nocy uruchamia się to, na co harness pozwalał w zeszłym miesiącu. Naprawa: trzymaj listę dozwolonych narzędzi w systemie kontroli wersji i przeglądaj ją jak kod. Tryb uprawnień ustawiaj w ustawieniach użytkownika lub zarządzanych, bo Claude Code ignoruje auto i bypassPermissions w ustawieniach projektu, a limity Codeksa przypinaj w requirements.toml.

Niezaufany tekst trafia do agenta z narzędziami. Treść zgłoszeń, komentarze w pull requestach, payloady webhooków i pobrane strony piszą ludzie z zewnątrz. Naprawa: pętlom, które je czytają, daj narzędzia tylko do odczytu, kroki z niezaufanym wejściem uruchamiaj z --bare --setting-sources "" --strict-mcp-config, żeby nie ładowały się hooki projektu ani serwery MCP (--bare uwierzytelnia się tylko przez ANTHROPIC_API_KEY albo apiKeyHelper, nie tokenem OAuth), a zapis oddaj osobnemu zadaniu. Claude Code już teraz oznacza tekst wyzwalający routine jako niezaufane dane.

Nikt nie odpowiada za całą linię. Sześć stanowisk z sześcioma właścicielami i nikim, kto czyta styki, to przepis na zielony potok, który wypuszcza zły produkt. Naprawa: wyznacz jednego właściciela na pętlę, który prowadzi cotygodniowy audyt próbkowy i może bez zebrania przełączyć pętlę z powrotem pod nadzór.

Dokąd dalej na poziomie 5

Poziom 4: piszesz specyfikacje Warunek wstępny: specyfikacje, warunki stopu i hooki dla jednego długiego przebiegu.

Jedna mapa Drabina, cykl życia i stanowiska fabryki w jednej siatce.

Czytanie dowodów zamiast kodu Co czyta człowiek, gdy diff pisze fabryka.

Fabryki oprogramowania Pełny przewodnik budowy i rejestr autonomii.

Od zgłoszenia do pull requesta Kompletna pętla fabryki we wszystkich trzech narzędziach.

Backlog dla agentów Tnij pracę na pętle, które agent może skończyć i udowodnić.

Przebiegi agentów bez nadzoru Polityka dla ograniczonej, cyklicznej pracy.

Co zostaje człowiekowi Czego żadne stanowisko za ciebie nie rozstrzygnie.