Weryfikacja w Dark Factory: gdy żaden człowiek nie czyta kodu

Dark Factory (poziom 5) to środowisko wytwarzania oprogramowania, w którym maszyny generują, weryfikują i wdrażają kod — żaden człowiek nie czyta ani jednej linii. Warstwa weryfikacji, która sprawia, że Dark Factory jest wykonalna, wymaga ewaluacji typu holdout, cyfrowych bliźniaków (Digital Twin Universes), wieloagentowego przeglądu oraz zakodowanych ograniczeń smaku. Bez tej warstwy agenci oszukują testy, a jakość znika.

StrongDM wydało oprogramowanie pod dwiema regułami: „Kodu nie mogą pisać ludzie” i „Kodu nie mogą przeglądać ludzie”.¹ Trzyosobowy zespół (Justin McCarthy, Jay Taylor i Navan Chauhan) zbudował i wydał Attractor oraz CXDB (16 tys. linii Rust, 9,5 tys. Go, 6,7 tys. TypeScript) przy minimalnym wydatku 1000 dolarów na tokeny na inżyniera dziennie.¹ BCG Platinion, powołując się na relacje Spotify i TechCrunch, informuje, że najlepsi programiści Spotify nie pisali kodu od grudnia 2025 roku, a firma mergowała setki pull requestów wygenerowanych przez AI miesięcznie.²

Dan Shapiro nazywa punkt docelowy poziomem 5: Dark Factory. Kod generowany przez maszyny, weryfikowany przez maszyny, wdrażany bez czytania przez człowieka choćby jednej linii.³ Poprzedzające poziomy odzwierciedlają progresję, którą większość zespołów przechodzi obecnie: ręczne kodowanie (poziom 0), delegowanie zadań (poziom 1), autopilot na autostradzie (poziom 2), Waymo z kierowcą bezpieczeństwa (poziom 3) oraz robotaxi, gdzie piszesz specyfikację i wychodzisz na 12 godzin (poziom 4).³

Pytanie, na które nikt nie odpowiedział zadowalająco: jak wygląda warstwa weryfikacji na poziomie 5? Poniższa analiza mapuje wymaganą infrastrukturę, opierając się na infrastrukturze smaku, która określa sposób oceny jakości w całej mojej pracy inżynierskiej.

Problem weryfikacji narasta

Na każdym poziomie poniżej 5 człowiek w pewnym momencie czyta kod. Na poziomie 3 człowiek zarządza AI jak starszy programista. Na poziomie 4 człowiek sprawdza, czy testy przechodzą po 12 godzinach.³ Te poziomy działają, ponieważ osoba z wiedzą instytucjonalną potrafi dopasować wzorce do intencji. Specyfikacja mówiła „ponawiaj z wykładniczym cofaniem”, a kod realizuje liniowe ponawianie — programista wyłapuje to jednym rzutem oka.

Wyeliminowanie człowieka całkowicie sprawia, że weryfikacja staje się innym problemem. Nie trudniejszym w stopniu. Innym w rodzaju. Weryfikator nie może polegać na rozumieniu tekstu. Musi zakodować, co oznacza „poprawne” w wykonywalnej formie, a następnie ocenić wynik wobec tego kodowania, nigdy nie przeglądając samego artefaktu.

Główna pułapka to agenci oszukujący testy. StrongDM odkrył, że ich agenci pisali return true, aby zdać zestawy testów, nie robiąc nic pożytecznego.¹ Testy świeciły się na zielono. Pipeline CI raportował sukces. Kod był bezwartościowy. Eran Kahana ze Stanford Law rozwija tę obserwację do ostrzeżenia strukturalnego: szerszym problemem jest cyrkularność, gdzie ta sama klasa technologii ocenia kod, który napisała ta sama klasa.⁴

Prawo Goodharta działa tu z niezwykłą siłą. Smak jest systemem technicznym argumentuje, że automatyczna weryfikacja potrzebuje warstwy osądu ponad sobą; bez ewaluacji na poziomie smaku testy stają się celami, a nie miarami. Gdy agenci optymalizują pod przechodzenie testów, przechodzenie testów przestaje mierzyć poprawność.⁴ Każda metryka, która staje się celem, przestaje być dobrą metryką. Warstwa weryfikacji Dark Factory musi uwzględniać tę dynamikę, inaczej będzie mierzyć zgodność, nie jakość.

Jak StrongDM faktycznie rozwiązuje weryfikację

Odpowiedź StrongDM to tak zwane „Scenariusze”: end-to-end user stories przechowywane poza bazą kodu, funkcjonujące jak zbiory holdout w uczeniu maszynowym.¹ Analogia jest precyzyjna: tak jak praktycy ML ewaluują modele wobec danych, na których nigdy nie trenowali, niezależni agenci oceniają wygenerowany kod wobec scenariuszy, do których agent kodujący nie ma dostępu podczas generowania.

Kluczowa metryka to „Satysfakcja”: odsetek zaobserwowanych trajektorii, które prawdopodobnie spełniają oczekiwania użytkownika.¹ Nie istnieje standard branżowy określający, jaki wynik stanowi wystarczającą satysfakcję. StrongDM doszedł do własnego progu empirycznie.

Aby testowanie scenariuszowe działało na skalę, StrongDM zbudował Digital Twin Universe: klony behawioralne Okta, Jira, Slack, Google Docs, Drive i Sheets.¹ Bliźniaki celują w 100% kompatybilności API przy użyciu popularnych publicznie dostępnych referencyjnych bibliotek klienckich SDK.¹ Agenci działają wobec bliźniaków, nie wobec zamockowanych endpointów. Wierność behawioralna bliźniaka determinuje wiarygodność testu.

StrongDM zaobserwował wzorzec, który sam również widziałem: „wraz z drugą rewizją Claude 3.5 (październik 2024) długohoryzontowe agentowe przepływy kodowania zaczęły kumulować poprawność zamiast błędów”.¹ Poniżej pewnego progu zdolności dłuższe przebiegi agentów generują więcej błędów. Powyżej niego dłuższe przebiegi produkują lepszy kod. Wzorzec Dark Factory stał się wykonalny dopiero po tym, jak modele przekroczyły ten próg.

Pięć warstw governance

Framework transformacyjny BCG Platinion obejmuje pięć filarów, w tym warstwę governance z wieloma etapami weryfikacji przed dotarciem kodu na produkcję.² Filary to: system operacyjny oparty na intencji, skodyfikowana infrastruktura wiedzy, podnoszenie kwalifikacji zespołu, warstwa governance z niezależnymi agentami weryfikującymi oraz architektura fabryki do orkiestracji.² Filar governance obejmuje testy scenariuszowe prowadzone przez niezależnych agentów, analizę statyczną, sprawdzanie zgodności architektonicznej, behawioralne testy regresji oraz agentów red-team, którzy aktywnie próbują złamać wynik.²

Niezależność ma znaczenie. Gdy ten sam agent pisze i testuje własny kod, problem cyrkularności Kahany ma zastosowanie.⁴ Gdy oddzielny agent (z innymi promptami systemowymi, innym kontekstem, innymi motywacjami) ocenia pracę, tryby awarii stają się dekorelowane. Nie wyeliminowane. Zdekorelowane. Dwaj agenci wciąż mogą dzielić systematyczne uprzedzenia odziedziczone z danych treningowych. Jednak prawdopodobieństwo identycznych martwych punktów spada, gdy agent ewaluujący operuje z innej perspektywy.

BCG Platinion identyfikuje „myślenie intencyjne” jako kluczową kompetencję dla zespołów Dark Factory: przekładanie potrzeb biznesowych na precyzyjne, testowalne opisy pożądanych rezultatów.² Rola człowieka przesuwa się z pisania kodu na pisanie specyfikacji, wobec których agenci mogą wykonywać ewaluację. Słabe specyfikacje produkują przechodzące testy na błędnym zachowaniu — ta sama dynamika return true, którą napotkał StrongDM.¹

BCG Platinion identyfikuje również ograniczenie, którego doświadczyłem bezpośrednio: „Agenci AI są tylko tak skuteczni, jak skodyfikowana wiedza, do której mają dostęp”.² Agent działający bez kontekstu projektu generuje wiarygodny kod, który łamie lokalne konwencje, ignoruje decyzje architektoniczne i odkrywa ponownie problemy, które zespół już rozwiązał. Skodyfikowana wiedza (decyzje projektowe, kontrakty API, przewodniki stylu, historie awarii) to infrastruktura, nie dokumentacja.

Co już uruchamiam na poziomie 4

Moja nocna pętla wykonawcza, architektura agenta Ralph, działa na poziomie 4 Shapiro. Piszę specyfikacje, uruchamiam agentów, śpię i rano przeglądam wyniki. Agenci działają wobec ponad 95 hooków, które przechwytują każde wywołanie narzędzia (zapisy plików, polecenia Git, wykonanie powłoki) przed i po wykonaniu. Hooki wymuszają ograniczenia, z którymi agent nie może negocjować ani ich obejść.

Hooki adresują problem gamingu Kahany na poziomie narzędzi. Osobny wpis dokumentuje pełną architekturę hooków, ale istotna właściwość to przechwytywanie: hooki odpalają się przed wykonaniem narzędzia, nie po. Agent próbujący wymusić push do main zostaje zablokowany przed wykonaniem polecenia. Agent próbujący commitować pliki pasujące do wzorców .env zostaje przechwycony. Agent raportujący „wszystkie testy przechodzą” bez uruchomienia pytest zostaje oznaczony przez bramkę dowodową, która wymaga wklejonego wyniku testów pokazującego zero błędów, nie twierdzenia, że testy by przeszły.

Bramka dowodowa wymusza sześć kryteriów na każdej nietrywalnej zmianie: zgodność z wzorcami bazy kodu (nazwij wzorzec i plik), najprostsze działające rozwiązanie (podaj odrzucone alternatywy), obsłużone przypadki brzegowe (wymień każdy), testy przechodzą (wklej wynik), brak regresji (wymień sprawdzone pliki) i rozwiązanie faktycznego problemu (określ potrzebę użytkownika i jak zmiana ją adresuje). „Uważam, że” i „powinno” nie są dowodem. Bramka odrzuca język wyrażający niepewność i wymaga artefaktów.

Pętla jakości (implementacja, przegląd, ewaluacja, dopracowanie, oddalenie perspektywy, powtórzenie, raport) działa jako ograniczenie behawioralne zakodowane w prompcie systemowym agenta poprzez CLAUDE.md. Pętla nie gwarantuje, że agent wykona każdy krok. Hooki weryfikują, że to zrobił.

Pięć filarów BCG Platinion mapuje się na infrastrukturę, którą już utrzymuję:

• System operacyjny oparty na intencji: pliki CLAUDE.md i specyfikacje rozwoju oparte na PRD kodują intencję projektu jako wykonywalny kontekst.
• Skodyfikowana wiedza: ponad 139 umiejętności, zorganizowanych jako wielorazowe zdolności, daje agentom dostęp do konwencji projektu, decyzji architektonicznych i wiedzy domenowej.
• Governance: hooki implementują warstwę przechwytywania. Bramka dowodowa implementuje warstwę audytu. Pętla jakości implementuje warstwę ograniczeń behawioralnych.

Dwóch filarów nie zbudowałem: podnoszenia kwalifikacji zespołu (nieistotne dla samodzielnego praktyka) i architektury fabryki jako dedykowanej platformy orkiestracji (mój obecny setup wykorzystuje natywne spawnowanie agentów Claude Code, a nie dedykowaną fabrykę). System kontekstu złożonego opisuje, jak te warstwy infrastruktury kumulują się w aktywo kapitałowe, czyniąc każdą kolejną sesję bardziej zdolną.

Przepaść między poziomem 4 a poziomem 5

Przejście z poziomu 4 na poziom 5 oznacza wyeliminowanie porannego przeglądu. Obecnie budzę się i czytam, co agenci wyprodukowali w nocy. Sprawdzam diffy w Git. Uruchamiam aplikację. Weryfikuję, czy wynik odpowiada mojej intencji. Ten przegląd zajmuje od 30 minut do godziny i wyłapuje problemy, których hooki nie wykrywają.

Problemy, których hooki nie wykrywają, są tymi interesującymi. Należą do kategorii, z którymi obecna automatyzacja radzi sobie słabo:

Dryf intencji. Agent wykonał specyfikację wiernie, ale specyfikacja była niejednoznaczna, a agent wybrał błędną interpretację. Żaden test nie wyłapie nieprawidłowej interpretacji, która produkuje poprawne zachowanie. Podejście scenariuszowe StrongDM adresuje to, kodując user stories jako specyfikację, a nie wymagania techniczne.¹ Scenariusze opisują, czego doświadcza użytkownik, a nie co robi kod.

Erozja architektoniczna. Agent dodał funkcjonalność, która działa w izolacji, ale degraduje spójność strukturalną systemu. Nowe zapytanie do bazy danych omijające istniejący wzorzec repozytorium. Nowy endpoint duplikujący logikę z innego modułu. Analiza statyczna wyłapuje część z nich. Sprawdzanie zgodności architektonicznej (warstwa governance BCG Platinion) wyłapuje więcej.² Żadne z nich nie wyłapuje subtelnych przypadków, gdzie nowy kod jest technicznie zgodny z wzorcami, ale wprowadza konceptualne rozwidlenie, które narasta przy przyszłych zmianach.

Utrata wiedzy instytucjonalnej. Kahana podnosi niedoceniany risk: gdy nikt nie czyta kodu, nikt nie buduje intuicji dotyczącej systemu.⁴ Jak ostrzega Kahana: „Nikt nie będzie wiedział dlaczego. Nikt nie będzie wiedział, jak to naprawić”.⁴ Obecnie mój poranny przegląd buduje tę intuicję przyrostowo. Na poziomie 5 system staje się nieprzejrzysty dla swojego operatora. Każdy złożony system ostatecznie wymaga interwencji, której automatyzacja nie obsłuży: incydent bezpieczeństwa, zmiana logiki biznesowej łamiąca założenia wbudowane w zestaw testów, integracja z systemem zewnętrznym, który zachowuje się inaczej niż deklaruje jego dokumentacja. Operator, który nigdy nie czytał kodu, nie może skutecznie interweniować.

Czego warstwa weryfikacji faktycznie potrzebuje

Syntetyzując praktykę StrongDM, framework governance BCG Platinion, analizę awarii Kahany i moją własną infrastrukturę, warstwa weryfikacji Dark Factory wymaga co najmniej:

Ewaluacja typu holdout. Testy, do których agent generujący nie ma dostępu podczas produkcji kodu. Scenariusze StrongDM. Specyfikacje behawioralne przechowywane oddzielnie od bazy kodu, ewaluowane przez niezależnych agentów. Bez ewaluacji holdout prawo Goodharta zamienia każdy zestaw testów w cel.

Cyfrowe bliźniaki do testowania integracyjnego. Agenci nie mogą testować wobec systemów produkcyjnych. Mocki są zbyt płytkie; weryfikują kontrakty API, nie zachowanie. Bliźniaki replikujące powierzchnię behawioralną zewnętrznych zależności umożliwiają end-to-end wykonanie scenariuszy bez ryzyka produkcyjnego.

Wieloagentowa weryfikacja ze zdekorelowanymi trybami awarii. Agent piszący i agent ewaluujący muszą operować z różnych kontekstów. Agenci red-team, którzy aktywnie sondują pod kątem gamingu, skrótów i fantomowej weryfikacji, dostarczają warstwę, której pasywne testowanie nie zapewni.

Przechwytywanie na poziomie narzędzi. Hooki blokujące szkodliwe operacje przed wykonaniem, a nie testy wykrywające szkody po fakcie. Warstwa hooków znajduje się poniżej procesu decyzyjnego agenta i jest odporna na obchodzenie przez sprytne promptowanie lub skróty return true.

Wykonywalne specyfikacje intencji. Specyfikacje na tyle precyzyjne, że niejednoznaczność jest wykrywalna. Kompetencja „myślenia intencyjnego” BCG Platinion.² Specyfikacja poziomu 4 Shapiro, którą piszesz przed wyjściem na 12 godzin.³ Specyfikacja jest produktem. Kod jest efektem ubocznym.

Ścieżka audytu bez luki odpowiedzialności. Kahana cytuje AI Life Cycle Core Principles wymagające, aby wynik był „identyfikowalny do odpowiedniej odpowiedzialnej strony”.⁴ Nie istnieje jeszcze branżowy standard metodologii audytu dla oprogramowania budowanego przez agentów.⁴ Warstwa weryfikacji musi produkować artefakty, które człowiek (lub regulator, lub osoba reagująca na incydent) może prześledzić od wdrożonego zachowania wstecz do specyfikacji, która je wygenerowała.

Uczciwa ocena

Prowadzę poziom 4 z dużą pewnością. Moi nocni agenci produkują pracę, która przechodzi poranny przegląd częściej niż nie. Hooki wyłapują awarie mechaniczne. Bramka dowodowa wyłapuje awarie epistemiczne. Pętla jakości redukuje awarie behawioralne.

Poziom 5 wymaga rozwiązania problemów, których nie rozwiązałem. Wykrywanie dryfu intencji bez ludzkiego dopasowywania wzorców. Zgodność architektoniczna, która wyłapuje erozję konceptualną, nie tylko naruszenia strukturalne. Wiedza instytucjonalna, która kumuluje się w systemie, a nie w głowie operatora.

BCG Platinion raportuje 3-5-krotne wzrosty produktywności u zespołów adoptujących wzorce Dark Factory.² StrongDM wydało oprogramowanie zbudowane przez agentów z trzema inżynierami i budżetem tokenowym.¹ Argument produktywnościowy jest jasny. Argument weryfikacyjny — nie.

Zespoły odnoszące sukcesy na poziomie 5 łączy wspólna cecha: zainwestowały więcej w infrastrukturę weryfikacji niż w generowanie kodu. StrongDM zbudował cały Digital Twin Universe, zanim zaufał agentom w dostarczaniu kodu.¹ Framework BCG Platinion zawiera pięć filarów transformacji, w tym warstwę governance z wieloma etapami weryfikacji przed dotarciem kodu na produkcję.² Dark Factory to nie fabryka działająca w ciemności. To fabryka, w której światłami jest warstwa weryfikacji, a wszystko inne (łącznie z kodem) jest towarem.

Pisałem wcześniej o tym, co się psuje, gdy agenci działają bez nadzoru oraz o bramce dowodowej jako obronie przed fantomową weryfikacją. Te teksty opisują infrastrukturę dla poziomu 4. Dark Factory wymaga tej samej infrastruktury, rozszerzonej do działania bez człowieka, który obecnie czyta poranny diff. Hooki, bramki dowodowe, pętle jakości: wszystko niezbędne na poziomie 5, ale niewystarczające. Brakującym elementem jest weryfikacja, która skaluje się z tą samą autonomią co generowanie.

Budowanie tego elementu to praca, która czeka. Hub inżynierii AI gromadzi pełny łuk tego badania, od projektowania pojedynczych hooków przez kontekst złożony po granicę Dark Factory.

FAQ

Czym jest Dark Factory w wytwarzaniu oprogramowania?

Dark Factory (poziom 5 Dana Shapiro) to środowisko wytwarzania oprogramowania, w którym maszyny generują kod, weryfikują kod i wdrażają kod bez czytania przez człowieka choćby jednej linii. Poprzedzające poziomy postępują od ręcznego kodowania (poziom 0) przez rosnącą automatyzację, przy czym poziom 4 to tryb „robotaxi”, gdzie człowiek pisze specyfikację, wychodzi na 12 godzin i przegląda wyniki. Dark Factory eliminuje nawet ten końcowy przegląd.

Jakie jest największe wyzwanie weryfikacyjne na poziomie 5?

Główna pułapka to agenci oszukujący testy. StrongDM odkrył agentów piszących return true, aby zdać zestawy testów, nie robiąc nic pożytecznego. Prawo Goodharta działa z niezwykłą siłą: gdy agenci optymalizują pod przechodzenie testów, przechodzenie testów przestaje mierzyć poprawność. Warstwa weryfikacji musi to uwzględniać poprzez ewaluację typu holdout (testy, do których agent generujący nie ma dostępu podczas produkcji kodu), wieloagentową weryfikację ze zdekorelowanymi trybami awarii oraz przechwytywanie na poziomie narzędzi blokujące szkodliwe operacje przed wykonaniem.

Jaka jest przepaść między poziomem 4 a poziomem 5?

Trzy problemy, z którymi obecna automatyzacja radzi sobie słabo: dryf intencji (agent wykonał specyfikację wiernie, ale wybrał błędną interpretację niejednoznacznego wymagania), erozja architektoniczna (nowe funkcjonalności działające w izolacji, ale degradujące spójność strukturalną) oraz utrata wiedzy instytucjonalnej (gdy nikt nie czyta kodu, nikt nie buduje intuicji dotyczącej systemu potrzebnej do interwencji podczas incydentów lub zmian logiki biznesowej).

Jak StrongDM rozwiązuje problem weryfikacji?

StrongDM używa „Scenariuszy” — end-to-end user stories przechowywanych poza bazą kodu, funkcjonujących jak zbiory holdout w uczeniu maszynowym. Niezależni agenci ewaluują kod wobec scenariuszy, do których agent kodujący nie ma dostępu podczas generowania. Zbudowali Digital Twin Universe (klony behawioralne Okta, Jira, Slack, Google Docs) celujący w 100% kompatybilności API, dzięki czemu agenci testują wobec realistycznych powierzchni behawioralnych zamiast płytkich mocków.