Fabryki oprogramowania: jak zbudować taką, która nie zgnije

Fabryka oprogramowania to potok, w którym agenci kodujący pobierają zadania z kolejki, budują je, testują i scalają, a człowiek czyta diff pobieżnie albo wcale. Fabryka się trzyma, gdy autonomię każdej pętli ogranicza wyrocznia, której zespół ufa bardziej niż modelowi, i gnije, gdy autonomię ogłasza się dla całej fabryki naraz.

Uruchamiasz sześciu agentów. Do czwartku masz czterdzieści pull requestów, dwie osoby zdolne rzetelnie je przejrzeć i kolejkę, która stała się ścieżką krytyczną zespołu. Raport Faros AI AI Engineering Report 2026 (kwiecień 2026, dwa lata telemetrii od 22 000 programistów i ponad 4000 zespołów) zmierzył ten sam wzorzec: mediana czasu do pierwszego review wzrosła o 156,6%, a liczba pull requestów scalonych bez żadnego review o 31,3%.

Ta strona jest dla tech leada i programistów, którzy budują taki potok, oraz dla CTO, który decyduje, jak daleko wolno mu działać bez nadzoru.

Co zyskujesz z projektowania fabryki oprogramowania

• Miejsce twojego zespołu na spektrum fabryk, wyrażone w poziomach drabiny autonomii.
• Rejestr autonomii: cztery pytania, które rozstrzygają, czy pętla może scalać zmiany bez człowieka czytającego diff.
• Kolejność budowy hali produkcyjnej, razem z kanałem kontekstu, który pomija większość potoków, i elementami z Claude Code, Codex i Cursora.
• Regułę limitu WIP i metryki, które wykrywają gnicie, zanim zrobią to incydenty.
• Trzy gotowe prompty: audyt gotowości, plan niosący kontekst z produkcji i adwersarialny recenzent bramki.

Czym jest fabryka oprogramowania?

Pętla ma pięć kroków:

1. Ludzie decydują, co zbudować, i wrzucają to do kolejki: issues, tickety albo etykieta.
2. Agenci budują i testują zmianę spełniającą wymaganie, po czym otwierają ją do CI i review.
3. Zaakceptowane zmiany trafiają na produkcję przez CD.
4. Odrzucone zmiany wracają do agenta, który iteruje, aż bramka przejdzie albo przejmie człowiek.
5. Użytkownicy korzystają z tego, co wdrożono, i generują zgłoszenia błędów, dane o użyciu i skargi, z których powstaje kolejna pozycja w kolejce.

Jedna mapa nazywa sześć stacji fabryki, a Poziom 5: prowadzisz fabrykę oprogramowania wymienia, co każde narzędzie dostarcza dla każdej z nich. Ta strona rozstrzyga to, czego tamte nie rozstrzygają: na ile autonomii zapracowała każda pętla i jak utrzymać kod w zdrowiu, gdy fabryka już działa.

Gdzie na spektrum fabryk jest twój zespół?

Nie ma testu przynależności, więc użyj dwóch osi: jaką część kodu piszą agenci i co człowiek wciąż czyta przed scaleniem. Opublikowane punkty odniesienia:

Gdzie	Udział kodu od agentów	Co czyta człowiek	Poziom pętli na drabinie
Większość zespołów	Wspomagane pull requesty pisane przez ludzi	Każdą linię	L1–L2
Minions w Stripe	„Over 1,300 Stripe pull requests … merged each week are completely minion-produced, human-reviewed, but containing no human-written code” (Alistair Gray, blog inżynierski Stripe, 2026-02-19)	Diff, po najwyżej dwóch rundach CI na ponad trzech milionach testów	L3
„Ciemna fabryka oprogramowania” (dark software factory) Dana Shapiro	Całość	Nic: „humans are neither needed nor welcome” (Shapiro, 2026-01-23). Simon Willison wskazuje, że chodzi o dział AI firmy StrongDM (2026-01-28)	L5

Pętla scalająca bez czytelnika potrzebuje trzech rzeczy naraz, a zespoły mają zwykle jedną: realnej adopcji (nie samego dostępu), walidacji aż do gotowości do scalenia (niezależne testy, sprawdzenie w przeglądarce, drugi recenzent, nigdy agent oceniający testy, które sam napisał) i zabezpieczeń zakładających porażkę (sandboksy, zawężone poświadczenia, deterministyczne kontrole).

Dlaczego fabryki oprogramowania erodują i jakie są dwa lekarstwa?

Dyskusję w 2026 roku ukształtowały dwie diagnozy: jedna dotyczy kodu, druga potoku. Potrzebujesz obu lekarstw: karm agenta prawdziwymi dowodami i dawkuj autonomię według tego, co potrafisz zweryfikować. Jednostką decyzji jest pętla, a nie fabryka, bo fabryka to dziesiątki pętli o różnej ekonomii weryfikacji.

Argument erozji: inżynieria harnessu nie wystarcza

Na AI Engineer World’s Fair w lipcu 2026 Dex Horthy z HumanLayer wygłosił wykład „Harness Engineering is not Enough: Why Software Factories Fail”. Według tytułu i opisu wykładu (źródło wtórne, wykład nie został spisany) jego teza brzmi: lepszy potok, lepsze prompty i lepsze narzędzia same nie dadzą kodu, który w dużej skali pozostaje łatwy w utrzymaniu.

Nasze odczytanie przyczyny: pętla agenta nagradza przechodzenie kontroli, które potrafi uruchomić, a nic nie ocenia utrzymywalności, bo jakość projektu zależy od próśb, których nikt jeszcze nie zgłosił. Każda zmiana może być zielona, a kod i tak się pogarsza.

SlopCodeBench zmierzył to wprost (Orlanski i in., arXiv 2603.24755, v1 2026-03-25, v2 2026-05-07). Zamiast zadań jednorazowych każe agentom kodującym wielokrotnie rozszerzać własne wcześniejsze rozwiązania, punkt kontrolny po punkcie, przy zmieniającej się specyfikacji. Śledzi dwa sygnały na całej trajektorii: rozwlekłość (kod nadmiarowy lub zduplikowany) i erozję strukturalną (złożoność skupiająca się w kilku funkcjach). Główny wynik: żaden agent nie rozwiązuje żadnego problemu od początku do końca, a najlepszy przechodzi 14,8% punktów kontrolnych.

Dlatego nachylenie musi wychwycić coś spoza agenta: człowiek czytający plany albo cykliczny pomiar samego kodu.

Argument kontekstu: potok głodzi agenta

To nasze stanowisko, wyprowadzone z tego, jak zbudowane są opublikowane fabryki, a nie z konkretnego badania: agenta głodzi potok, a nie model.

Większość opublikowanych fabryk oddziela decyzję, co zbudować, od budowania: człowiek planuje, kompresuje wynik do ticketu i przekazuje go agentowi, który nigdy nie widział problemu. Dobry projekt potrzebuje ograniczeń technicznych i dowodów: jak funkcja jest używana, których klientów dotyka błąd, co mówi stack trace. Agent z ticketem zawsze pracuje na streszczeniu i ma skłonność do pisania nowego kodu tam, gdzie lepiej poinformowany inżynier zmieniłby istniejący.

Jak zdecydować, które pętle mogą działać bez nadzoru?

Daj pętli tyle autonomii, ile potrafisz tanio i wiarygodnie zweryfikować, i ani trochę więcej.

Rejestr autonomii

Zanim pętla zacznie scalać zmiany bez człowieka czytającego diff, odpowiedz na piśmie na cztery pytania:

1. Jaka wyrocznia rozstrzyga „gotowe”? Nazwij polecenie. „Testy przechodzą” to wyrocznia. „Wygląda dobrze” nią nie jest.
2. Czy agent może ją oszukać? Jeśli agent może edytować wyrocznię, wyrocznia jest tylko sugestią. Testy, które agent pisze w tej samej zmianie, oblewają to pytanie z definicji.
3. Po jakim czasie wychodzi zła odpowiedź? Sekundy to zielone światło. „Ktoś zauważy za trzy tygodnie” to czerwone, i taka jest odpowiedź dla każdej decyzji architektonicznej.
4. Jaki jest zasięg szkód, jeśli to błąd? Odwracalny i ograniczony, czy migracja schematu.

Pętla, która czysto odpowiada na wszystkie cztery, może scalać według reguły. Pętla, która oblewa pytanie 2 lub 3, zostaje z człowiekiem, choćby harness był znakomity. Rejestr ustala poziom pętli; klasa ryzyka zmiany nadal ogranicza, co wolno pojedynczej zmianie, więc pętla na poziomie 5 eskaluje zmianę w uwierzytelnianiu tak samo jak zespół na poziomie 2 (tabela klas ryzyka jest na jednej mapie).

Pętla	Wyrocznia	Da się oszukać?	Opóźnienie informacji zwrotnej	Werdykt
Aktualizacje zależności, łatki CVE	Build plus pełny zestaw testów u konsumentów	Nie, testy powstały przed zmianą	Minuty	L5: scala według reguły
Naprawa niestabilnych (flaky) testów	Uruchom test 1000 razy i zmierz odsetek porażek	Tak, poprawka edytuje sam test	Minuty	L4: człowiek czyta diff pliku testu. L5 tylko wtedy, gdy strażnik diffu dowodzi, że linie z asercjami się nie zmieniły
Mechaniczne codemody, poprawki lintera i typów	Kompilator i linter	Tylko jeśli kontrola w CI blokuje wyciszenia i zmiany konfiguracji lintera lub tsconfig, czyli oblewa każdy nowy eslint-disable, @ts-ignore albo # noqa w diffie	Sekundy	L5 z tą kontrolą; bez niej L4
Nowa funkcja w dobrze pokrytym module	Istniejące testy plus nowe, napisane przez agenta	Tak, agent kontroluje obie strony	Minuty	L4: człowiek czyta plan i dowody
Schemat, uwierzytelnianie, cennik, migracje	Zachowanie na produkcji	Nie, ale wolno	Dni do tygodni	L3: człowiek czyta diff
Refaktoryzacje architektury	Żadna, która działa w CI	Nie dotyczy	Tygodnie do miesięcy	L3, z planowaniem na początku

Prompt do skopiowania: audyt gotowości fabryki

Audit this repository for agentic factory readiness and produce an autonomy
ledger. Do not propose a pipeline yet, and do not change any files.

Step 1. Inventory the classes of change this repo actually receives. Run
`git log --since="6 months ago" --name-only --format="%h %s"` and group
commits by what they touched (dependency manifests, migrations, tests,
feature code by module), not by commit-message prefix. Report the share of
changed lines that landed in files that already existed versus new files.

Step 2. For each class of change, fill in a table with these columns:
  - oracle: the exact command that decides "done" (read CI config to find it)
  - fakeable: could an agent editing this repo weaken or delete that oracle
    in the same change? Answer yes if the tests live in paths the agent edits.
  - latency: how long after a wrong change merges before anything surfaces it
  - blast radius: what breaks, and whether it is reversible without a deploy

Step 3. Assign each class a verdict: merges by rule, a human reads the plan
and evidence, or a human reads the diff. Justify every "merges by rule" with
the answers from step 2, and flag any class whose only oracle is a test file
the agent would also be editing.

Step 4. For the highest-volume class that still needs a human, list the
missing infrastructure that would let it move one step toward merging by
rule, cheapest first. Name files and commands that do not exist yet; do not
recommend generic best practices.

Jak zbudować halę produkcyjną fabryki?

Buduj w tej kolejności. Zespoły pomijają kroki 1 i 2, a to daje szybki potok, który wysyła na produkcję erozję.

1. Zrób repozytorium czytelnym dla agenta. AGENTS.md albo CLAUDE.md z architekturą i nieoczywistymi ograniczeniami, typowane granice modułów i testy utrwalające zachowanie; to one decydują, ile szkód narobi błędna decyzja agenta. Zobacz repozytorium gotowe dla agentów.

2. Podłącz kanał kontekstu. Zanim agent zacznie planować, czyta to, co otworzyłby inżynier: trace’y błędów, logi, dane o użyciu i słowa samego klienta. Podłącz serwery MCP do śledzenia błędów i analityki, za które zespół już płaci, i zrób z ich czytania obowiązkowy krok planowania. W Claude Code:

   # Terminal: zdalne serwery z OAuth; pierwsze wywołanie narzędzia poprosi o logowanie
   claude mcp add --transport http sentry https://mcp.sentry.dev/mcp
   claude mcp add --transport http posthog https://mcp.posthog.com/mcp

   Codex dodaje ten sam serwer poleceniem codex mcp add sentry --url https://mcp.sentry.dev/mcp, a potem codex mcp login sentry, bo zdalny serwer uwierzytelnia przez OAuth (sprawdzone z codex 0.157.1, codex mcp --help). W Cursorze dodaj ten sam URL w sekcji mcpServers pliku .cursor/mcp.json ({"sentry": {"url": "https://mcp.sentry.dev/mcp"}}). Konfigurację dla każdego narzędzia opisuje debugowanie produkcji z edytora.

3. Zbuduj kolejkę. Wystarczy etykieta na issue. Dzięki kolejce lista prac jest jawna i ma limit, więc to, co wchodzi do fabryki, jest decyzją, a nie przypadkiem. Zobacz od issue do pull requesta.

4. Zbuduj bramkę w kolejności kosztu. Najpierw kontrole deterministyczne: kompilator, linter, sprawdzanie typów, zestaw testów, testy kontraktowe. Potem agent-recenzent z adwersarialnym promptem. Potem człowiek, w pętlach, w których wymaga tego rejestr. Drogi recenzent uruchomiony przed darmowymi kontrolami pali tokeny na diffach, które odrzuciłby błąd typów.

5. Sandboks, zakres i licznik. Każdy agent dostaje izolowane środowisko, poświadczenia zawężone do swojej pętli i limit wydatków. Zobacz uprawnienia, sandboksy i tryby zatwierdzania.

6. Dodaj pomiary samej fabryki. To system produkcyjny, którego wyjściem jest kod: śledź głębokość kolejki, opóźnienie review i odsetek poprawek dla każdej pętli za pomocą obserwowalności agentów.

Uwaga

Testy w repozytorium nie są bramką dla agenta, który może je edytować. Trzymaj scenariusze behawioralne, które rozstrzygają „gotowe”, poza zasięgiem agenta, jak zbiór walidacyjny w treningu modelu: w ścieżce, do której agent nie ma zapisu, na chronionej gałęzi albo w osobnym repozytorium. Każdą zmianę dotykającą testów lub konfiguracji CI traktuj jako wysoką klasę ryzyka, bez względu na poziom pętli. Ochrona wyroczni omawia pięć warstw ochrony.

Które narzędzie obsługuje którą stację?

Trzy narzędzia pokrywają różne powierzchnie i większość fabryk je łączy. Podział jest taki sam jak w ciągłym dostarczaniu z AI.

Claude Code

Claude Code to stacja skryptowa. claude -p działa bez interfejsu w zadaniu CI i w ten sposób podpinasz recenzenta bramki albo cykliczny przegląd. Zabezpieczenia niosą flagi: --allowedTools ogranicza, czego agent może dotknąć, --output-format json sprawia, że wynik da się sparsować, a --max-budget-usd ogranicza wydatek jednego uruchomienia (wszystko sprawdzone w claude --help, v2.1.283).

# CI, na pull requeście. Plik promptu pochodzi z gałęzi domyślnej,
# nigdy z checkoutu autora zmiany.
# trusted/ to checkout gałęzi domyślnej, nie autora zmiany.
git diff origin/main...HEAD > trusted/pr.diff
claude -p "$(cat trusted/.github/prompts/gate-review.md) Review trusted/pr.diff." \
  --bare --setting-sources "" --strict-mcp-config \
  --allowedTools "Read,Grep,Glob" \
  --output-format json \
  --max-budget-usd 2 > verdict.json
jq -r '.result' verdict.json | tail -n 1 | grep -q '^PASS' || exit 1

--bare --setting-sources "" --strict-mcp-config sprawia, że zadanie nie wczytuje hooków, ustawień ani serwerów MCP z samego pull requesta, które inaczej działałyby z sekretami zadania. --bare do uwierzytelnienia czyta tylko ANTHROPIC_API_KEY (albo apiKeyHelper), nigdy OAuth, więc ustaw ten sekret w zadaniu (sprawdzone z v2.1.283). Pełny plik workflow jest w agentach headless w CI.

Wybierz Claude Code, gdy fabryka żyje w .github/workflows.

Codex

Codex to stacja wielu powierzchni. codex exec uruchamia nieinteraktywnego wykonawcę, który kończy pracę, codex review --base main recenzuje gałąź z powłoki, a na GitHubie @codex review recenzuje pull request. Integracje ze Slackiem i Linearem pozwalają wprowadzać pracę do fabryki tam, gdzie zespół już rozmawia (sprawdzone 2026-08-28).

# Bramka w CI. Zadanie potrzebuje jednego sekretu: OPENAI_API_KEY.
# trusted/ to checkout gałęzi domyślnej, nie autora zmiany.
printenv OPENAI_API_KEY | codex login --with-api-key
git diff origin/main...HEAD > trusted/pr.diff
codex exec -C trusted --sandbox read-only \
  -o verdict.txt \
  "$(cat trusted/.github/prompts/gate-review.md) Review pr.diff."
tail -n 1 verdict.txt | grep -q '^PASS' || exit 1

-C trusted ustawia zaufany checkout jako katalog roboczy agenta, więc AGENTS.md i konfiguracja .codex/ autora zmiany nigdy się nie wczytują; przechodzi tylko diff, jako plik. --with-api-key czyta klucz ze standardowego wejścia (sprawdzone w codex exec --help i codex login --help, 0.157.1). Pełny plik workflow pokazują agenci headless w CI.

Wybierz Codeksa, gdy praca wchodzi z czatu albo z trackera.

Cursor

Mocną stroną Cursora jest stacja review i budowanie wyzwalane zdarzeniami. Bugbot recenzuje pull requesty pod kątem błędów, problemów bezpieczeństwa i jakości kodu. Cloud Agents działają w izolowanych maszynach wirtualnych z pełnym środowiskiem deweloperskim, a Automations uruchamiają je według harmonogramu albo na zdarzenia z GitHuba, GitLaba, Slacka, Lineara, Sentry, PagerDuty lub webhooka. Automatyzacja wyzwalana z Sentry to kanał kontekstu podłączony wprost. PR Routing & Approval decyduje, kto musi co zatwierdzić (sprawdzone 2026-08-28). Konfigurację opisuje strona Bugbot.

Wybierz Cursora, gdy zdarzenia z produkcji mają uruchamiać agentów bez skryptu.

Prompt do skopiowania: plan niosący kontekst z produkcji

Write the implementation plan for the issue below. Do not write code yet, and
do not trust the issue description as a complete account of the problem.

First, gather evidence with the connected tools:
- The related error-tracking issue: full stack trace, frequency, first seen,
  affected releases, and how many users hit it.
- Usage data for the surface involved: how often the path runs, the drop-off,
  and whether the behavior changed after a recent release.
- Every existing file that already implements this behavior. Report what
  share of the work extends existing code versus adds new files.
- Prior attempts in git history (`git log -S` on the key identifiers), and
  what happened to them.

Then write the plan. Open it with a section titled "What the evidence says
the problem is" that confirms or contradicts the issue description. If they
contradict, stop and say so instead of planning around it.

The plan must name the files it will change, the existing abstraction it will
extend rather than duplicate, and the specific command that will prove it
worked. If no such check exists, say so instead of inventing a test that only
checks the code you are about to write.

Issue: #1234

Zamień #1234 na numer zgłoszenia; agent czyta je przez serwer MCP twojego trackera albo gh issue view.

Jak prowadzić fabrykę, nie gromadząc ukrytego długu?

Gdy hala już działa, o jej zdrowiu decydują trzy pokrętła: ile pracy wchodzi, co mierzysz i ile to kosztuje.

Ustaw limit WIP według przepustowości review, nie budżetu na tokeny

Dodawanie agentów poszerza wlot lejka; gdy bramka się nie zmienia, rośnie tylko kolejka, a kolejki przed bramkami zamieniają się w scalenia bez bramek. Raport Faros 2026 to pokazuje: mediana czasu spędzanego w review (inna miara niż czas do pierwszego review) w górę o 441,5%, a rozmiar pull requestów w górę o 51%.

Ogranicz liczbę równoległych agentów do liczby zmian, które bramka jest w stanie przepuścić w ciągu dnia. Podnoś limit tylko wtedy, gdy bramka staje się szybsza lub tańsza: gdy pętla awansuje w rejestrze, gdy dochodzi deterministyczna kontrola albo gdy pull requesty maleją. Kalibrację pułapu na programistę opisuje równoległość w zespole.

Które metryki wcześnie wychwytują gnicie fabryki?

Liczba incydentów pokazuje problem z opóźnieniem liczonym w miesiącach. Śledź zamiast niej poniższe metryki, osobno dla zmian od agentów i od ludzi. Dane Faros pochodzą z telemetrii jego własnych klientów, a nie z losowej próby, więc jego kolumnę czytaj jako kierunek, nie wzorzec.

Metryka	Co mówi	Faros, AI Engineering Report 2026
Churn kodu (kod usunięty wkrótce po napisaniu)	Przepustowość, która nie jest prawdziwa	W górę o 861%
Incydenty na pull request	Czy bramka działa	W górę o 242,7%
Błędy na programistę	Defekty uciekające przez bramkę	W górę o 54%
Pull requesty scalone bez review	Czy bramka jest pomijana	W górę o 31,3%
Mediana czasu do pierwszego review	Gdzie tworzy się kolejka	W górę o 156,6%
Duplikacja i koncentracja złożoności	Dwa sygnały erozji ze SlopCodeBench, mierzone na twoim repozytorium	Nie ma ich w raporcie; mierz je co tydzień w pętli zdrowia kodu

Cytuj ten raport w obu kierunkach. Stwierdził też wzrost liczby ukończonych epików na programistę o 66,2%, przepustowości zadań o 33,7% i wskaźnika scalania pull requestów o 16,2%, przy spadku wdrożeń tygodniowo o 11,7%. Wynik jest prawdziwy i rachunek też.

Mierz koszt na pętlę, nie na stanowisko

Autonomiczne pętle wydają pieniądze bez akceptacji człowieka przy każdym uruchomieniu. Tim Sehn z DoltHub oszacował sesję wielu orkiestrowanych agentów na około 100 USD w tokenach Claude na godzinę, „about 10X the cost of a normal Claude Code session per unit time” (2026-01-15), a tydzień takiej pracy na 3000 USD (2026-03-24): jeden użytkownik i jedna konfiguracja, ale rząd wielkości widać. Ogranicz każde uruchomienie (--max-budget-usd w claude -p) i przeglądaj wydatki na scaloną zmianę dla każdej pętli. Mechanikę opisuje zarządzanie kosztami.

Napraw platformę, zanim przeskalujesz fabrykę

Raport DORA 2025 (2025-09-23) wykazał pozytywny związek adopcji AI z przepustowością dostarczania i negatywny ze stabilnością dostarczania. Jego główna myśl: „AI doesn’t fix a team; it amplifies what’s already there”. Ten sam raport stwierdził „a direct correlation between a high quality internal platform and an organization’s ability to unlock the value of AI”.

Co się psuje w fabryce oprogramowania i jak z tego wyjść?

Nikt już nie potrafi wyjaśnić kodu. Ta luka wychodzi na jaw dopiero przy błędzie, który wymaga rozumowania o systemie. Żeby z tego wyjść, poddaj obszar kwarantannie, zapisz potrzebne zachowanie jako wykonywalne kryteria akceptacji i wygeneruj kod na nowo z tej specyfikacji, zamiast debugować kod, którego nikt nie jest właścicielem. Żeby temu zapobiec, czytaj plany nawet w pętlach, w których przestałeś czytać diffy.

Agent zmienił test zamiast kodu. Testy są zielone, błąd jest na produkcji, a diff dotknął asercji. To pytanie 2 z rejestru bez odpowiedzi. Wynieś wyrocznię poza zasięg agenta i traktuj każdy zielony przebieg ze zmienionym plikiem testu jako zmianę bez review, dopóki człowiek jej nie podpisze.

Erozja, której nie łapie żadna kontrola. Każda bramka przechodzi, a kod i tak się pogarsza, bo duplikacja i koncentracja złożoności są niewidoczne dla kompilatorów i testów. Zaplanuj pętlę zdrowia kodu, a gdy jej trend rośnie przez kilka tygodni, obniż poziom dotkniętej pętli o jeden, dopóki nie wejdzie refaktoryzacja.

Teatr review. Zatwierdzenia przychodzą kilka sekund po otwarciu pull requesta, na diffach zbyt dużych, by ktoś je przeczytał. Przejrzany pobieżnie diff na 800 linii jest gorszy od nieprzeczytanego, bo zostawia ślad, że ktoś patrzył. Przeglądaj rzetelnie losową próbkę, ogranicz rozmiar pull requestów w CI i przenieś czytanie człowieka na pakiet dowodów; zobacz review pull requestów od agentów.

Zastoje w kolejce. Praca wchodzi, agent ją podejmuje i utyka. Alarmuj na podstawie czasu spędzonego w danym stanie i kieruj wszystko, co przekroczy próg, do człowieka zamiast do kolejnej próby.

Zasięg szkód przez ścieżki bez pośrednika. Twój gateway LLM (pośrednik wywołań modelu) widzi tylko te wywołania, które przez niego przechodzą, a nie widzi bezpośrednich wywołań API, poleceń powłoki ani sesji przeglądarki. Wypisz ścieżki bez pośrednika, bo autonomiczna pętla z szerokimi poświadczeniami to inna sytuacja bezpieczeństwa niż inżynier z tymi samymi uprawnieniami. Zobacz bezpieczeństwo MCP.

Prompt do skopiowania: adwersarialny recenzent bramki

Review this diff as the last automated gate before a human sees it. Assume
the author was an agent optimizing to make checks pass, and that it had
write access to the tests.

Report only findings you can tie to a specific failure. For each, state the
input or state that triggers it and what goes wrong. Skip style, naming and
anything a linter already covers.

Check, in this order:
1. Did this change weaken its own oracle? Flag any modified, deleted, skipped
   or loosened assertion, snapshot update, or CI config change, and say
   whether the production code justifies it.
2. Does this duplicate logic that already exists in the repo? Search before
   concluding it does not, and name the function it should have called.
3. What happens on the unhappy path: empty input, concurrent callers, partial
   failure, and a downstream timeout?
4. What is the blast radius if this is wrong in production, and can it be
   reverted without a deploy?
5. What did the author not touch that this change implies should also change?

End with one line: BLOCK or PASS, and if BLOCK, the single finding that
justifies it. Do not pad the list to look thorough.

Zapisz ten prompt jako plik gate-review.md, który czytają przykłady z zakładek narzędzi powyżej; ostatnia linia każdego zadania przerywa build, jeśli werdykt nie brzmi PASS. Żeby sprawdzić samego recenzenta, raz w miesiącu podaj mu celowo zły diff (taki, który luzuje asercję) i potwierdź, że go blokuje.

Dokąd pójść dalej z fabrykami oprogramowania

Czytanie dowodów zamiast kodu Warunek wstępny: co czyta człowiek, gdy przestaje czytać każdą linię

Poziom 5: prowadzisz fabrykę oprogramowania Stacja po stacji: co Claude Code, Codex i Cursor dostarczają dla każdej z nich

Jedna mapa Drabina, cykl życia i stacje w jednej siatce, z tabelą klas ryzyka i rejestrem pętli

Jak utrzymać w zdrowiu kod pisany przez agentów Cotygodniowy pomiar erozji i progi, które obniżają autonomię pętli

Ochrona wyroczni Trzymaj testy, które rozstrzygają „gotowe”, poza zasięgiem agenta

tmux dla floty agentów Warstwa pod fabryką: który agent utknął i jak przekazywać pracę między nimi