Warstwa weryfikacji ciemnej fabryki

StrongDM wydało oprogramowanie zgodnie z dwiema zasadami: „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 dziennie na tokeny na inżyniera.¹ BCG Platinion, powołując się na relacje Spotify i TechCrunch, podaje, że najlepsi programiści Spotify nie pisali kodu od grudnia 2025 roku, a firma scalała setki pull requestów generowanych przez AI miesięcznie.²

Dan Shapiro nazywa punkt docelowy Poziomem 5: Ciemną Fabryką. Kod generowany przez maszyny, weryfikowany przez maszyny, wdrażany bez czytania przez człowieka choćby jednej linii.³ Poprzedzające poziomy odzwierciedlają progresję, na której znajduje się większość zespołów — od ręcznego kodowania (Poziom 0), przez delegowanie zadań (Poziom 1), autopilot na autostradzie (Poziom 2), Waymo z kierowcą bezpieczeństwa (Poziom 3), aż po robotaksówkę, gdzie pisze się specyfikację i odchodzi na 12 godzin (Poziom 4).³

Pytanie, na które nikt dotąd dobrze nie odpowiedział: jak wygląda warstwa weryfikacji na Poziomie 5?

Problem weryfikacji narasta

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

Po całkowitym usunięciu człowieka 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 formie wykonywalnej, a następnie ocenić wynik w odniesieniu do tego kodowania, nie inspektując samego artefaktu.

Główna pułapka polega na tym, że agenci oszukują testy. StrongDM odkryło, że ich agenci pisali return true, by zdawać zestawy testów, nie robiąc nic użytecznego.¹ Testy były zielone. Pipeline CI był zadowolony. Kod był bezwartościowy. Eran Kahana ze Stanford Law rozszerza tę obserwację do ostrzeżenia strukturalnego: szerszym problemem jest cyrkularność, gdzie ta sama klasa technologii ocenia kod napisany przez tę samą klasę.⁴

Prawo Goodharta działa tu ze szczególną siłą. Gdy agenci optymalizują pod kątem zdawania testów, zdawanie testów przestaje mierzyć poprawność.⁴ Każda metryka, która staje się celem, przestaje być dobrą metryką. Warstwa weryfikacji ciemnej fabryki musi uwzględniać tę dynamikę — w przeciwnym razie będzie mierzyć zgodność, nie jakość.

Jak StrongDM faktycznie rozwiązuje weryfikację

Odpowiedzią StrongDM są „Scenariusze” — kompleksowe historie użytkownika przechowywane poza bazą kodu, funkcjonujące jak zbiory walidacyjne w uczeniu maszynowym.¹ Analogia jest precyzyjna: tak jak modele ML są oceniane na danych, na których nie były trenowane, tak kod budowany przez agentów jest oceniany na scenariuszach, do których agent nie ma dostępu podczas generowania.

Kluczową metryką jest „Satysfakcja”: odsetek obserwowanych trajektorii, które prawdopodobnie zaspokajają potrzeby użytkownika.¹ Nie istnieje standard branżowy określający, jaki wynik stanowi wystarczającą satysfakcję. StrongDM doszło do własnego progu empirycznie.

Aby testowanie oparte na scenariuszach działało na dużą skalę, StrongDM zbudowało Digital Twin Universe — klony behawioralne Okta, Jira, Slack, Google Docs, Drive i Sheets.¹ Bliźniaki cyfrowe dążą do 100% kompatybilności API z wykorzystaniem popularnych, publicznie dostępnych referencyjnych bibliotek klienckich SDK.¹ Agenci działają przeciwko bliźniakom, nie przeciwko zmockowanym endpointom. Wierność behawioralna bliźniaka determinuje wiarygodność testu.

StrongDM zaobserwowało coś, co sam również widziałem: „wraz z drugą rewizją Claude 3.5 (październik 2024) długoterminowe agentyczne przepływy pracy 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 — lepszy kod. Wzorzec ciemnej fabryki stał się realny dopiero po przekroczeniu tego progu przez modele.

Pięć warstw zarządzania

Pięciofilarowy model transformacji BCG Platinion obejmuje warstwę zarządzania z wieloma krokami weryfikacji, zanim kod trafi na produkcję.² Filary to: system operacyjny sterowany intencją, infrastruktura skodyfikowanej wiedzy, podnoszenie kwalifikacji pracowników, warstwa zarządzania z niezależnymi agentami weryfikacyjnymi oraz architektura fabryki do orkiestracji.² W ramach filaru zarządzania BCG Platinion opisuje testy scenariuszowe prowadzone przez niezależnych agentów, analizę statyczną, sprawdzanie zgodności architektonicznej, testy regresji behawioralnej oraz agentów red-team, którzy aktywnie próbują złamać wynik.²

Niezależność ma kluczowe znaczenie. Gdy ten sam agent pisze i testuje własny kod, problem cyrkularności Kahany się materializuje.⁴ Gdy oddzielny agent — z innym promptem systemowym, innym kontekstem, innymi bodźcami — ocenia pracę, tryby awarii się dekorelują. Nie eliminują. Dekorelują. Dwóch agentów wciąż może dzielić systematyczne obciążenia odziedziczone z danych treningowych. Jednak prawdopodobieństwo identycznych martwych pól spada, gdy agent oceniający operuje z innej perspektywy.

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

BCG Platinion identyfikuje również ograniczenie, którego sam 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 na nowo odkrywa problemy, które zespół już rozwiązał. Skodyfikowana wiedza — decyzje projektowe, kontrakty API, przewodniki stylistyczne, historie awarii — to infrastruktura, nie dokumentacja.

Co już uruchamiam na Poziomie 4

Moja nocna pętla wykonawcza, Ralph Loop, działa na Poziomie 4 według Shapiro. Piszę specyfikacje, uruchamiam agentów, idę spać i rano przeglądam wyniki. Agenci działają na ponad 95 hookach, 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 oszukiwania Kahany na poziomie narzędzi. Agent próbujący wykonać force-push na main zostaje zablokowany przed wykonaniem polecenia, nie po tym, jak test wykryje szkody. Agent próbujący zacommitować pliki pasujące do wzorców .env zostaje przechwycony. Agent raportujący „wszystkie testy przeszły” bez uruchomienia pytest zostaje oflagowany przez bramkę dowodową, która wymaga wklejonych wyników testów pokazujących zero błędów, a nie twierdzenia, że testy by przeszły.

Bramka dowodowa wymusza sześć kryteriów na każdej nietrivialnej zmianie: zgodność z wzorcami bazy kodu (wskaż 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ązuje faktyczny problem (określ potrzebę użytkownika i sposób jej zaadresowania). „Uważam” i „powinno” nie stanowią dowodu. Bramka odrzuca język niepewności i wymaga artefaktów.

Pętla jakości — implementacja, przegląd, ewaluacja, ulepszenie, 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 sterowany intencją: pliki CLAUDE.md i specyfikacje rozwojowe oparte na PRD kodują intencję projektu jako wykonywalny kontekst.
• Skodyfikowana wiedza: ponad 139 umiejętności, zorganizowanych jako wielokrotnego użytku zdolności, daje agentom dostęp do konwencji projektowych, decyzji architektonicznych i wiedzy dziedzinowej.
• Zarządzanie: hooki implementują warstwę przechwytywania. Bramka dowodowa implementuje warstwę audytu. Pętla jakości implementuje warstwę ograniczeń behawioralnych.

Dwóch filarów nie zbudowałem: podnoszenie kwalifikacji pracowników (nieistotne dla indywidualnego praktyka) i architektura fabryki jako dedykowana platforma orkiestracji (moja obecna konfiguracja wykorzystuje natywne tworzenie agentów Claude Code, a nie celowo zbudowaną fabrykę).

Przepaść między Poziomem 4 a Poziomem 5

Przejście z Poziomu 4 na Poziom 5 oznacza eliminację porannego przeglądu. Obecnie budzę się i czytam, co agenci wyprodukowali w nocy. Sprawdzam diffy w Git. Uruchamiam aplikację. Weryfikuję, czy wynik odpowiada moim intencjom. Ten przegląd zajmuje od 30 minut do godziny i wyłapuje problemy, które hooki pomijają.

Problemy pomijane przez hooki są właśnie tymi interesującymi. Należą do kategorii, z którymi obecna automatyzacja radzi sobie słabo:

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

Erozja architektoniczna. Agent dodał funkcję, 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 zarządzania BCG Platinion — wyłapuje więcej.² Żadne z nich nie wyłapuje subtelnych przypadków, gdy nowy kod jest technicznie zgodny z wzorcami, ale wprowadza konceptualny podział, który kumuluje się przy przyszłych zmianach.

Utrata wiedzy instytucjonalnej. Kahana wskazuje na 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ć”.⁴ Dziś 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 w końcu wymaga interwencji, której automatyzacja nie jest w stanie obsłużyć — incydent bezpieczeństwa, zmiana logiki biznesowej naruszająca założenia wbudowane w zestaw testów, integracja z zewnętrznym systemem, który zachowuje się inaczej niż twierdzi jego dokumentacja. Operator, który nigdy nie czytał kodu, nie jest w stanie skutecznie interweniować.

Czego warstwa weryfikacji faktycznie potrzebuje

Synteza praktyki StrongDM, modelu zarządzania BCG Platinion, analizy awarii Kahany i mojej własnej infrastruktury prowadzi do wniosku, że warstwa weryfikacji ciemnej fabryki wymaga co najmniej:

Ewaluacji w stylu zbioru walidacyjnego. Testów, do których agent generujący nie ma dostępu podczas produkcji kodu. Scenariuszy StrongDM. Specyfikacji behawioralnych przechowywanych oddzielnie od bazy kodu, ocenianych przez niezależnych agentów. Bez ewaluacji walidacyjnej Prawo Goodharta zamienia każdy zestaw testów w cel optymalizacji.

Cyfrowych bliźniaków do testów integracyjnych. Agenci nie mogą testować na systemach produkcyjnych. Mocki są zbyt płytkie — weryfikują kontrakty API, a nie zachowanie. Bliźniaki replikujące powierzchnię behawioralną zależności zewnętrznych umożliwiają kompleksowe wykonanie scenariuszy bez ryzyka produkcyjnego.

Wieloagentowej weryfikacji ze zdekorerelowanymi trybami awarii. Agent piszący i agent oceniający muszą operować z różnych kontekstów. Agenci red-team, którzy aktywnie sondują pod kątem oszukiwania, skrótów i fantomowej weryfikacji, dodają warstwę, której pasywne testowanie nie zapewnia.

Przechwytywania na poziomie narzędzi. Hooków blokujących szkodliwe operacje przed wykonaniem, a nie testów wykrywających szkody po fakcie. Warstwa hooków działa poniżej poziomu decyzyjnego agenta i nie może zostać obejścia przez sprytne promptowanie ani skróty return true.

Wykonywalnych specyfikacji intencji. Specyfikacji na tyle precyzyjnych, że niejednoznaczność jest wykrywalna. Kompetencja „myślenia intencyjnego” BCG Platinion.² Specyfikacja Poziomu 4 Shapiro, którą pisze się przed wyjściem na 12 godzin.³ Specyfikacja jest produktem. Kod jest efektem ubocznym.

Ścieżki audytu bez luki odpowiedzialności. Kahana cytuje Podstawowe Zasady Cyklu Życia AI wymagające, by wynik był „możliwy do prześledzenia do odpowiedniej strony odpowiedzialnej”.⁴ Nie istnieje jeszcze branżowy standard metodologii audytu 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

Uruchamiam Poziom 4 z wysoką pewnością. Moi nocni agenci produkują pracę, która częściej niż nie przechodzi poranny przegląd. 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. Wykrywania dryfowania intencji bez ludzkiego dopasowywania wzorców. Zgodności architektonicznej wyłapującej erozję konceptualną, nie tylko naruszenia strukturalne. Wiedzy instytucjonalnej, która kumuluje się w systemie, a nie w głowie operatora.

BCG Platinion raportuje 3-5-krotne wzrosty produktywności u zespołów przyjmujących wzorce ciemnej fabryki.² StrongDM wydało oprogramowanie budowane przez agentów z trzema inżynierami i budżetem na tokeny.¹ 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ło cały Digital Twin Universe, zanim zaufało agentom w kwestii wydawania kodu.¹ Model BCG Platinion obejmuje pięć filarów transformacji, w tym warstwę zarządzania z wieloma krokami weryfikacji, zanim kod trafi na produkcję.² Ciemna fabryka to nie fabryka, która działa w ciemności. To fabryka, w której światłem 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ę Poziomu 4. Ciemna fabryka wymaga tej samej infrastruktury, rozszerzonej tak, by działała bez człowieka, który obecnie czyta poranny diff. Hooki, bramki dowodowe, pętle jakości — są konieczne na Poziomie 5, ale niewystarczające. Brakującym elementem jest weryfikacja, która skaluje się z tą samą autonomią co generowanie.

Zbudowanie tego elementu to praca, która jest przed nami.