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. Fabryki działają wtedy, gdy autonomia każdej pętli jest ograniczona wyrocznią weryfikacyjną, której zespół ufa bardziej niż modelowi, a gniją, 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 je rzetelnie przejrzeć i kolejkę, która stała się ścieżką krytyczną całej firmy. Badanie telemetryczne Faros AI z 2026 roku podaje liczby dokładnie na ten tydzień: mediana czasu do pierwszego review w górę o 156,6%, a pull requesty scalone całkowicie bez review w górę o 31,3%.

Oczywisty ruch to zautomatyzować także review. I właśnie o ten ruch branża spierała się przez cały 2026 rok. Warto zrozumieć ten spór, zanim skopiujesz czyjś potok, bo dwa najgłośniejsze głosy mają rację jednocześnie i wcale nie kłócą się o to samo.

Co zyskujesz z prowadzenia fabryki oprogramowania

• Dwuosiową mapę spektrum fabryk z naniesionymi realnymi firmami, żeby “czy jesteśmy fabryką oprogramowania” przestało być kwestią przeczucia
• Rejestr autonomii: cztery pytania do każdej pętli, które rozstrzygają, czy może działać bez nadzoru, i odpowiedź, która ją dyskwalifikuje
• Kolejność budowy hali produkcyjnej, razem z kanałem kontekstu, który pomija większość opublikowanych potoków
• Sześć metryk wykrywających gnicie wcześniej niż licznik incydentów, oraz limit WIP, który mu zapobiega
• Cztery gotowe prompty: audyt gotowości fabrycznej, specyfikacja niosąca kontekst z produkcji, adwersarialny recenzent bramki i cotygodniowy przegląd erozji

Czym naprawdę jest fabryka oprogramowania

Pętla nie jest skomplikowana i po części dlatego rozchodzi się tak szybko:

1. Ludzie decydują, co zbudować, i wpisują to do systemu ticketów.
2. Agenci budują i testują zmianę spełniającą wymaganie, po czym otwierają ją do CI i review.
3. Zaakceptowany kod trafia na produkcję przez CD.
4. Odrzucony wraca do agenta na kolejne iteracje, aż przejdzie.
5. Użytkownicy korzystają z tego, co wdrożono, i emitują dane, opinie oraz sygnały, które kształtują kolejne prace.

Nic z tego nie jest nowe. Rusztowaniem są kontrola wersji, CI/CD i monitoring, a ustandaryzowany, powtarzalny proces to rzecz, którą każdy zespół już deklaruje. Zmieniło się to, kto stoi przy stanowiskach.

Sama metafora jest starsza, niż się wydaje. Hitachi otworzyło swoje Software Works w 1969 roku, a NEC, Toshiba i Fujitsu poszły tą drogą w latach 70., wszystkie goniąc za standaryzacją procesu i reużyciem. Studium tamtej epoki autorstwa Michaela Cusumano wykazało, że fabryki były naprawdę dobre w rutynowym, produkcyjnym oprogramowaniu i uporczywie słabe w systemach operacyjnych oraz aplikacjach. To użyteczna przesłanka: fabryki optymalizują pracę, której jakość da się określić z góry.

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

Nie ma testu przynależności, więc potraktuj to jako dwie osie: jaką część kodu piszą agenci i jak uważnie ludzie wciąż go czytają. Opublikowane współrzędne, stan na sierpień 2026:

Zespół	Udział kodu od agentów	Czytanie przez ludzi	Gdzie to plasuje
Większość zespołów	Wsparcie przy PR-ach pisanych przez ludzi	Pełne review	To nie fabryka, tylko szybkie autouzupełnianie
Ramp, Cursor, Uber	Agenci w tle na realnych ticketach. Uber raportuje ~1800 w pełni agentowych zmian tygodniowo, ~11% aktualizacji backendu na produkcji, przy 95% inżynierów używających AI co miesiąc	Pełne review	Fabryka oświetlona
PostHog	~70% PR-ów	Ludzie przeglądają co najmniej 80%	Oświetlona, ze ściemnionym światłem
Stripe	Minions scalają 1300+ PR-ów tygodniowo bez ani jednej linii napisanej przez człowieka	Review przez ludzi	Oświetlona, w dużej skali
StrongDM	Całość. Trzy osoby, 32 000 linii produkcyjnego oprogramowania bezpieczeństwa	Zero. Statut zabrania ludziom pisania i recenzowania kodu	Zgaszone światła

Sporny jest prawy górny róg. Fabryka “z wyłączonym światłem” (dark factory) potrzebuje trzech rzeczy naraz, a zespoły mają zwykle jedną:

• Realnej adopcji AI. Dostęp do agentów to nie to samo co ich używanie. Fabryka, w której połowa zespołu nadal pisze PR-y ręcznie, ma na środku hali stałe stanowisko manualne.
• Walidacji do poziomu gotowości do scalenia. Review przez innego agenta, uruchomienie lokalne, przeklikanie w przeglądarce. Agent piszący testy jednostkowe do własnego kodu, a potem rozumujący o tym kodzie, niczego nie waliduje: to ten sam model oceniający własny egzamin.
• Zabezpieczeń zakładających porażkę. Sandboksy, wąsko przyznane uprawnienia, deterministyczne kontrole. Ludzie zostają w pętli jako decydenci wyłącznie przy zmianach wysokiego ryzyka.

Dlaczego spór o fabryki oprogramowania wybuchł w 2026 roku

Dwa argumenty padły w odstępie kilku tygodni i wzięcie tylko jednego z nich zbuduje ci zły potok.

Argument Dexa Horthy’ego: inżynieria uprzęży nie wystarcza

CEO HumanLayer prowadził fabrykę z wyłączonym światłem od lipca 2025 i zamknął ją w listopadzie. Agenci pisali, recenzowali i wdrażali bez udziału człowieka, a w ciągu jakichś czterech miesięcy kodbaza zdegradowała się na tyle, że znalezienie jednego błędu zajęło tygodnie ręcznego debugowania. Jego wniosek, przedstawiony jako keynote “Harness Engineering is not Enough” na AI Engineer World’s Fair, a potem jako seria esejów, brzmi: porażka nie leżała w potoku. Leżała w modelach.

Mechanizmem jest sygnał nagrody. Agenci kodujący są trenowani pod jednorazową poprawność: jeśli testy przechodzą, rollout wygrywa. Nic w tej pętli nie karze za erozję kodbazy po drodze do zieleni. A nie karze dlatego, że nie istnieje szybka wyrocznia utrzymywalności: to, czy projekt był dobry, zależy od tego, o co ktoś poprosi następnym razem, a tego nie da się wiedzieć w chwili projektowania i jest to unikalne dla każdej kodbazy.

Ta teza przestała być retoryczna, gdy zmierzył ją SlopCodeBench. Zamiast zadań jednorazowych benchmark każe agentom wielokrotnie rozbudowywać własne wcześniejsze rozwiązania pod zmieniające się specyfikacje, a potem śledzi dwa sygnały na poziomie trajektorii: rozwlekłość (kod redundantny lub zduplikowany) i erozję strukturalną (masa złożoności skupiająca się w kilku bardzo złożonych funkcjach). Wyniki, za Orlanskim i in.:

• Żaden agent nie rozwiązuje w całości ani jednego problemu. Najlepszy ścisły wynik na checkpoint to 14,8%.
• Erozja strukturalna rośnie w 77% trajektorii; rozwlekłość rośnie w 75,5%.
• Kod agenta jest 2,3x bardziej rozwlekły i 2,0x bardziej zerodowany niż kod ludzki na tych samych problemach.
• Repozytoria ludzkie degradują się rzadziej i o mniejsze marginesy w całej swojej realnej historii rozwoju.
• Proszenie o jakość z góry obniżyło początkową erozję i rozwlekłość nawet o jedną trzecią, nie zmieniając tempa degradacji.

To ostatni punkt wart dłuższego namysłu. Lepsze instrukcje przesunęły punkt startowy i zostawiły nachylenie w spokoju. Żadna ilość inżynierii uprzęży nie załata brakującego sygnału nagrody i dlatego rekomendacja Horthy’ego brzmi: czytaj kod dalej albo przenieś wysiłek człowieka wyżej, do planowania.

Argument PostHog: potok głodzi agenta

Odpowiedź PostHog nie podważa erozji. Podważa schemat.

Każda opublikowana fabryka oprogramowania wymusza czysty rozdział między decydowaniem, co zbudować, a budowaniem. Człowiek planuje, kompresuje wynik do ticketu i przekazuje go agentowi bez żadnego wcześniejszego kontekstu problemu. Lekarstwo Horthy’ego zachowuje ten kształt: lepszą wyrocznią jakości byłoby to, czy wynik przechodzi wszystkie weryfikatory dla stopniowo ujawnianej specyfikacji, a specyfikacja nadal przychodzi gotowa.

Zarzut PostHog jest taki, że dobra inżynieria produktowa tak nie wygląda. Dobre zaprojektowanie systemu wymaga ograniczeń technicznych oraz realnego zrozumienia problemu, dlatego inżynierowie produktowi rozmawiają z użytkownikami i dlatego w PostHog to inżynierowie, a nie PM-owie, decydują, co budować. Agenci dziedziczą to wymaganie. Podejmują lepsze decyzje architektoniczne, gdy widzą, jak produkt jest naprawdę używany, kim jest klient, na co narzekają użytkownicy i co jeszcze dzieje się w kodbazie.

Ich własne liczby pokazują, dlaczego uderza to najmocniej w utrzymywalność: 63% zmienionych linii w PostHog trafia do plików, które już istnieją, a fix jest ich największym typem commita z 40%. Większość pracy nad oprogramowaniem jest reakcją na zaobserwowane użycie. Gdy ostatnio goniłeś incydent, opierałeś się na logach i trace’ach, a nie na czyimś streszczeniu problemu z drugiej ręki, a agent dostający ticket pracuje na streszczeniu z drugiej ręki za każdym razem.

Dlaczego autonomię się zdobywa dla pętli, a nie ogłasza

Oba stanowiska bronią się w analizie i składają się w całość. Horthy wskazuje sufit, którego nie przeskoczysz inżynierią. PostHog wskazuje ranę zadaną samemu sobie, leżącą dobrze poniżej tego sufitu. Zaleczenie rany nie podnosi sufitu i żadne z nich osobno nie przetrwa zderzenia z prawdziwą kodbazą.

Praktyczny wniosek jest taki, że “czy jesteśmy dark factory” to złe pytanie, bo pada na złym poziomie ziarnistości. Fabryka to nie jedno ustawienie autonomii. To dziesiątki pętli o skrajnie różnej ekonomii weryfikacji, a użyteczną jednostką decyzji jest pętla.

Addy Osmani nazywa to ograniczenie: pętli można oddać tyle autonomii, ile da się tanio i niezawodnie zweryfikować, i ani cala więcej. Nazywa to przeciwciśnieniem i to jest powód, dla którego lejek z szerokim wlotem i wąską bramką nie przyspiesza, gdy poszerzasz wlot.

Rejestr autonomii

Zanim pętla ruszy bez nadzoru, odpowiedz na jej temat pisemnie na cztery pytania:

1. Jaka wyrocznia rozstrzyga “gotowe”? Nazwij konkret. “Testy przechodzą” to wyrocznia. “Wygląda dobrze” to nie.
2. Czy agent może ją oszukać? Jeśli agent może edytować wyrocznię, wyrocznia jest sugestią. Testy wewnątrz repozytorium oblewają to pytanie z definicji.
3. Ile czasu minie, zanim błędna odpowiedź wyjdzie na jaw? Sekundy to zielone światło. “Człowiek zauważy za trzy tygodnie” to czerwone i jest to odpowiedź dla każdej decyzji architektonicznej, czyli dokładnie teza Horthy’ego.
4. Jaki jest promień rażenia, jeśli to błąd? Odwracalny i ograniczony, czy migracja schematu.

Pętla odpowiadająca czysto na wszystkie cztery może dziś działać w ciemno. Pętla oblewająca pytanie 2 lub 3 zostaje w świetle bez względu na to, jak dobra jest twoja uprząż.

Pętla	Wyrocznia	Do oszukania	Opóźnienie sygnału	Werdykt
Podbicia zależności, łatki CVE	Build i pełny zestaw testów u konsumentów	Nie, zestaw powstał przed zmianą	Minuty	Działa w ciemno
Stabilizacja testów niestabilnych	Uruchom test 1000 razy, zmierz odsetek porażek	Nie, jest statystyczna	Minuty	Działa w ciemno
Mechaniczne codemody, poprawki lintera i typów	Kompilator i linter	Nie	Sekundy	Działa w ciemno
Praca nad funkcją w dobrze pokrytym module	Istniejące testy plus nowe, napisane przez agenta	Tak, agent trzyma obie strony	Minuty	W świetle: człowiek czyta plan
Schemat, autoryzacja, cennik, migracje	Zachowanie na produkcji	Nie, ale jest wolna	Dni do tygodni	W świetle: człowiek czyta diff
Refaktory architektoniczne	Żadna działająca w CI	Nie dotyczy	Tygodnie do miesięcy	W świetle, z planowaniem z góry

Jeszcze jedno ograniczenie z tej samej literatury: pętle pozostają niezawodne przy mniej więcej 3 do 10 krokach, a powyżej około 20 agent gubi wątek, bo kontekst narasta. “Pętla” wymagająca czterdziestu kroków to potok, którego jeszcze nie rozłożyłeś na części.

Wskazówka

Gotowy prompt do audytu gotowości fabrycznej:

Audit this repository for agentic factory readiness and produce an autonomy
ledger. Do not propose a pipeline yet.

Step 1. Inventory the classes of change this repo actually receives. Use
`git log --since="6 months ago" --name-only` and group commits by what they
touched, not by commit message prefix. Report the share of changed lines that
landed in files that already existed versus brand new files.

Step 2. For each class of change, fill in this table honestly:
  - the specific oracle that decides "done" (name the command)
  - whether an agent editing this repo could weaken or delete that oracle
  - how long after a wrong answer merges before anything surfaces it
  - the blast radius of a wrong answer

Step 3. Rank the classes into three buckets: can run unattended today, needs a
human reading the plan, needs a human reading the diff. Justify every
"unattended" with the answers from step 2, and flag any where the only oracle
is a test file the agent would also be editing.

Step 4. List the missing infrastructure that would let the top-ranked lit
class move down a tier, cheapest first. Be concrete about what does not exist
yet rather than recommending generic best practices.

Jak zbudować halę produkcyjną fabryki

Buduj w tej kolejności. Kroki 1 i 2 zespoły pomijają najczęściej, a ich pominięcie daje szybki potok, który dostarcza erozję.

1. Uczyń repozytorium czytelnym dla agenta. AGENTS.md albo CLAUDE.md opisujący architekturę i nieoczywiste ograniczenia, typowane granice między modułami oraz szwy testowe przypinające zachowanie. Uwagę Osmaniego warto powtórzyć, bo jest nieefektowna: mocne sygnatury, przejrzysta organizacja, czytelne stosy wywołań i wstrzykiwanie zależności nie są nową praktyką, są siatką bezpieczeństwa decydującą o tym, jak wiele szkody zrobi błędna decyzja agenta.

2. Podłącz kanał kontekstu. To argument PostHog przełożony na operacje i krok, którego niemal żaden opublikowany potok nie zawiera. Zanim agent cokolwiek zaplanuje, powinien móc sięgnąć po te same dowody, które otworzyłby człowiek: trace’y błędów, logi, dane o użyciu, nagrania sesji i faktyczną skargę klienta. Podłącz serwery MCP analityki i śledzenia błędów, za które zespół już płaci, i uczyń ich czytanie częścią kroku planowania, a nie opcjonalnym narzędziem, po które agent może sięgnąć. Agent, który przeczytał zgłoszenie w Sentry, pisze inną poprawkę niż ten, któremu wręczono ticket “checkout czasem nie działa”.

3. Zbuduj kolejkę. Etykieta na zgłoszeniu w zupełności wystarcza na start. Zadaniem kolejki jest uczynić listę pracy jawną i ograniczoną tempem, żeby to, co wchodzi do fabryki, było decyzją, a nie przypadkiem.

4. Zbuduj bramkę, w kolejności kosztu. Najpierw kontrole deterministyczne: kompilator, linter, kontrola typów, zestaw testów oraz testy własności lub kontraktu. Potem recenzent LLM z adwersarialnym promptem. Potem człowiek, dla klas, którym rejestr go przypisał. Uruchamianie drogiego recenzenta przed darmowymi spala tokeny na diffach, które odrzuciłby błąd typów.

5. Sandboksuj, ogranicz uprawnienia, mierz wydatek. Każdy agent dostaje izolowane środowisko, poświadczenia zawężone do potrzeb swojej pętli i licznik wydatków. Zadaj pytanie, które zadałby operator fabryki: w najgorszej godzinie systemu, które operacje są pośredniczone, jakie tożsamości obowiązują, jakie limity są egzekwowane, jakie dowody przetrwają i w którym miejscu człowiek musi autoryzować kontynuację? Każda ścieżka omijająca twoją bramę (bezpośrednie wywołania API, dostęp do powłoki, przeglądarka) potrzebuje własnej odpowiedzi.

6. Oprzyrząduj samą fabrykę. Prowadzisz teraz system produkcyjny, którego wyjściem jest kod. Jeśli nie widzisz głębokości kolejki, opóźnienia review i wskaźnika przeróbek na pętlę, lecisz na ślepo.

Uwaga

Testy wewnątrz repozytorium nie są bramką wobec agenta, który może je edytować. To ta porażka, przy której krok 4 wygląda porządnie, a nie daje nic. Odpowiedź StrongDM warto podebrać niezależnie od tego, co sądzisz o reszcie ich podejścia: trzymają scenariusze behawioralne jako zbiór wstrzymany na zewnątrz kodbazy, dokładnie jak zbiór walidacyjny w treningu. Agent nie widzi ani nie modyfikuje tego, czym jest oceniany. Jeśli twoja jedyna wyrocznia leży w katalogu, do którego agent ma prawo zapisu, obniż o jeden poziom każdą pętlę, która na niej polega.

Które narzędzie prowadzi halę produkcyjną?

Trzy narzędzia zajmują różne powierzchnie. Ten podział pokrywa się z tym z artykułu o ciągłym dostarczaniu i to samo rozumowanie obowiązuje tutaj.

Cursor

Cursor najlepiej obsadza stanowisko review. BugBot recenzuje PR-y automatycznie po włączeniu na repozytorium i zostawia komentarze w linii, a na żądanie wywołasz go ponownie przez bugbot run. Autofix, ogólnie dostępny od lutego 2026, uruchamia agenta chmurowego w tle, który otwiera kolejny PR z proponowaną poprawką, więc bramka produkuje diff do zaakceptowania zamiast komentarza do obsłużenia. Agenci w tle i agenci chmurowi obsługują stanowisko budowy, a Agents Window to miejsce, z którego obserwujesz flotę.

Wybierz Cursor, gdy bramka review twojej fabryki żyje w interfejsie GitHuba i chcesz, żeby porażki wracały jako PR-y.

Claude Code

Claude Code to stanowisko skryptowalne. claude -p działa bezgłowo wewnątrz GitHub Action i tak właśnie podłączysz recenzenta, bramkę albo cykliczny przegląd. Flagi niosą zabezpieczenia: --allowedTools ogranicza to, czego agent może dotknąć, a --output-format json czyni wynik parsowalnym, więc zadanie może się na nim wywalić. Hooki PreToolUse zatrzymują ryzykowne polecenie przed wykonaniem, a subagenci pozwalają jednej pętli delegować bez dziedziczenia całego kontekstu.

Wybierz Claude Code, gdy fabryka jest zdefiniowana w .github/workflows i chcesz wywoływać każde stanowisko ze skryptu z jawnymi uprawnieniami.

Codex

Codex to stanowisko asynchroniczne. Codex Cloud uruchamia zadania w środowisku hostowanym, a nie na twojej maszynie, integracja z GitHubem otwiera i recenzuje PR-y, integracja ze Slackiem pozwala koledze z zespołu odpalić zadanie z kanału, a Automations uruchamiają cykliczne prompty i dostarczają wyniki do skrzynki zadań. codex exec obsłuży workery nieinteraktywne, gdy chcesz lokalną pętlę, która kończy działanie.

Wybierz Codex, gdy praca ma wchodzić do fabryki z czatu i tam też mają zapadać akceptacje.

Wskazówka

Gotowy prompt na specyfikację niosącą kontekst z produkcji:

You are writing 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:
- Pull the related error-tracking issue: full stack trace, frequency, first
  seen, affected releases, and which users hit it.
- Pull usage data for the surface involved: how often the path runs, what the
  drop-off looks like, and whether the behaviour changed recently.
- Find every existing file that already touches this behaviour. Report what
  fraction of the work is extending existing code versus adding new files.
- Search for prior attempts at this in git history and say what happened.

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

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

Issue:

Jak zarządzać fabryką, gdy już działa

Zbudowanie jej to weekend. Prowadzenie jej bez narastania długu, którego nie widzisz, to praca.

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

Fabryka to lejek z szerokim wlotem i wąską bramką. Dodawanie agentów poszerza wlot. Jeśli bramka się nie zmienia, rośnie wyłącznie kolejka przed nią, a kolejki przed bramkami zamieniają się w scalenia bez bramki. To nie prognoza: Faros zmierzył wzrost liczby pull requestów scalonych całkowicie bez review o 31,3%, przy pracy stojącej ponad 7 dni w górę o 26% i dziennej liczbie kontekstów PR na programistę w górę o 67,4%.

Ogranicz liczbę równoległych agentów do tylu zmian, ile twoja bramka realnie przepuszcza dziennie, a potem podnoś limit wyłącznie przez przyspieszenie lub potanienie bramki. Każda inna dźwignia to teatr. Zrównoleglenie pracy zespołu omawia kalibrowanie tego sufitu na programistę.

Obserwuj sześć metryk wykrywających gnicie wcześnie

Licznik incydentów jest wskaźnikiem opóźnionym, a zanim drgnie, erozja ma już miesiące. Śledź zamiast tego poniższe, w rozbiciu na pliki tworzone przez agentów i przez ludzi, żeby porównanie było widoczne:

Metryka	Co mówi	Poziom bazowy Faros 2026
Churn kodu (stosunek linii usuniętych do dodanych w scalonym kodzie)	Przepustowość, która nie jest realna	Wzrost o 861%
Incydenty na PR	Czy bramka działa	Wzrost o 242,7%
Błędy na programistę	Odsetek defektów przechodzących przez bramkę	Wzrost o 54% (z 9% w raporcie 2025)
PR-y scalone bez review	Czy bramka jest omijana	Wzrost o 31,3%
Czas do pierwszego review	Gdzie tworzy się kolejka	Mediana w górę o 156,6%
Duplikacja i koncentracja złożoności	Dwa sygnały erozji ze SlopCodeBench, lokalnie	Brak w raporcie; zmierz sam

Badanie Faros obejmuje 22 000 programistów w ponad 4000 zespołów przez dwa lata i porównuje w każdej organizacji okres najniższej i najwyższej adopcji AI. Warto je cytować w obie strony. Ten sam zbiór danych pokazuje realne zyski: epiki ukończone na programistę w górę o 66,2%, przepustowość zadań o 33,7%, wskaźnik scalonych PR-ów o 16,2%. Wynik jest prawdziwy. Rachunek też. Kto sprzedaje ci jedną połowę tej tabeli, sprzedaje coś jeszcze.

Wskazówka

Gotowy prompt na cotygodniowy przegląd erozji:

Run an erosion sweep on the code our agents wrote this week and report on the
two signals that CI cannot see.

1. Identify the agent-authored changes. Use `git log --since="7 days ago"` with
   whatever trailer, author, or branch prefix our factory stamps on them, and
   tell me which identifier you used so I can correct it.

2. Verbosity. Run `npx jscpd --min-lines 8 --reporters json` over the changed
   paths. Report the duplication ratio, then find the near-duplicates jscpd
   misses: functions that reimplement an existing helper with different names.
   List each one next to the helper it should have called.

3. Structural erosion. Rank every function in the changed files by cyclomatic
   complexity and report what share of total complexity sits in the top 10% of
   functions. Compare that share against the same files one month ago.

4. Report the trend, not just the level. A stable ratio is fine. A ratio that
   climbed every week for a month is the failure mode we are looking for, and I
   want it flagged as such.

Output a table sorted by severity, and for the worst three, propose the specific
refactor with the existing abstraction it should collapse into. Do not open a PR.

Mierz koszt na pętlę, nie na stanowisko

Autonomiczne pętle wydają bez człowieka decydującego za każdym razem, co sprawia, że budżety zachowują się inaczej. StrongDM traktuje 1000 dolarów na inżyniera dziennie w tokenach jako podłogę, a nie sufit, z uzasadnieniem, że zbyt niski wydatek oznacza zbyt małą automatyzację. Uber poszedł w drugą stronę i ograniczył wydatki pracowników na AI po przepaleniu budżetu w cztery miesiące.

Oba przypadki niosą tę samą lekcję z przeciwnych stron: licznik należy do pętli. Pętla podbijająca zależności, która działa w ciemno i kosztuje grosze na zmianę, nie powinna dzielić linii budżetowej z pętlą refaktorów architektonicznych, która pali fortunę i nadal potrzebuje człowieka. Kontrola kosztów omawia mechanikę.

Napraw platformę, zanim przeskalujesz fabrykę

Badania DORA nad wytwarzaniem wspieranym przez AI dochodzą do wniosku niewygodnego i dobrze udokumentowanego: AI jest wzmacniaczem. Jego wpływ na wydajność organizacji zależy od jakości wewnętrznej platformy. Gdy jakość platformy jest niska, efekt jest znikomy; gdy jest wysoka, efekt jest silny i pozytywny. Inwestowanie w agentów bez inwestowania w platformę to optymalizacja lokalna.

Czytaj to razem z ustaleniem Faros, że organizacje o dojrzałych praktykach DevOps doświadczyły tego samego pogorszenia co wszyscy inni. Te dwa wnioski nie są sprzeczne: dobra platforma podnosi to, co fabryka może wyprodukować, i sama z siebie nie zatrzymuje erozji. Potrzebujesz platformy oraz rejestru.

Co się psuje w fabryce oprogramowania

Nikt już nie rozumie kodu. Przepaść między tym, ile kodu istnieje, a tym, ile ktokolwiek potrafi jeszcze wyjaśnić, rozszerza się po cichu i uwidacznia dopiero, gdy błąd wymaga rozumowania o systemie. Wyjście jest drogie: odizoluj dotknięty obszar, zapisz zachowanie, którego naprawdę od niego potrzebujesz, i wygeneruj go od nowa z tej specyfikacji, zamiast debugować kod bez właściciela. Zapobieganie jest tańsze: czytaj plany nawet w pętlach, w których przestałeś czytać diffy.

Agent poprawił test zamiast kodu. Zestaw jest zielony, błąd siedzi na produkcji, a diff dotknął asercji. To pytanie 2 z rejestru pozostawione bez odpowiedzi. Przenieś wyrocznię poza zasięg, trzymaj scenariusze behawioralne na zewnątrz repozytorium i traktuj każde zielone przejście, w którym zmienił się plik testowy, jako zmianę nierecenzowaną.

Erozja, której nie łapie żadna kontrola. Wszystkie bramki przechodzą, a kodbaza i tak się pogarsza, bo duplikacja i koncentracja złożoności są niewidoczne dla kompilatorów i zestawów testów. Zaplanuj powyższy przegląd erozji i traktuj jego linię trendu jako realny sygnał.

Teatr review. Akceptacje przychodzą kilka sekund po otwarciu PR-a, na diffach zbyt dużych, by ktoś je przeczytał. Przekartkowany diff na 800 linii jest gorszy niż nieprzeczytany, bo zostawia zapis mówiący, że ktoś patrzył. Audytuj rzetelnie próbkę, zamiast kartkować całość, i zmniejsz rozmiar PR-ów, który według Faros urósł o 51,3% przy wysokiej adopcji AI.

Zagłodzenie kolejki i utyki. Praca wchodzi, agent ją podejmuje i sprawa stoi. Alarmuj na wiek w stanie, a nie na sam stan, i kieruj wszystko po przekroczeniu progu do człowieka zamiast do kolejnej próby.

Promień rażenia przez ścieżki, których nie objąłeś pośrednictwem. Twoja brama widzi wywołania modelu, które przez nią przechodzą. Nie widzi bezpośrednich wywołań API, poleceń powłoki ani sesji przeglądarki. Wypisz nieobjęte ścieżki wprost, bo autonomiczna pętla z szerokimi poświadczeniami to inna postawa bezpieczeństwa niż inżynier z tymi samymi. Bezpieczeństwo MCP omawia stronę dostępu do narzędzi.

Wskazówka

Gotowy prompt na adwersarialnego recenzenta bramki:

Review this diff as the last automated gate before a human sees it. Assume the
author was an agent optimising 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 one, state the
inputs or state that trigger 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, 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 does this do 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 is it reversible
   without a deploy?
5. What did the author not touch that this change implies should also change?

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

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

tmux dla flot agentów Warstwa pod fabryką: widzieć, który agent stoi, przeżyć zamkniętą klapę, przekazywać pracę między sześcioma

herdr: multiplekser agentów Wykrywanie stanu agenta i API po gnieździe, gdy zgadywanie z ekranu przestaje się skalować

Ciągłe dostarczanie Podłączanie bramki: bezgłowi recenzenci, YAML potoku, bramki wdrożeń i triage czerwonych buildów

Wzorce współpracy człowiek-AI Gdzie człowiek zostaje w pętli i co się zmienia, gdy z niej wychodzi

Bramki jakości i ich egzekwowanie Deterministyczna połowa bramki i jak uczynić ją dość tanią, by szła pierwsza

Checklista review kodu od AI Czego stanowisko review ma naprawdę szukać, gdy większość diffa piszą agenci