Software Dark Factory: fabryka agentów w AI SDLC

W Ziemi obiecanej Władysława Reymonta Karol Borowiecki, Maks Baum i Moryc Welt próbują zbudować fabrykę w Łodzi. Film Andrzeja Wajdy — zrealizowany w 1974 roku, z premierą w 1975 — pokazuje nie tylko energię przedsiębiorców, lecz także cenę przemysłowego przyspieszenia. Kiedy dziś myślę o Software Dark Factory, wracam do tego obrazu: trzech wspólników szukało kapitału, maszyn i ludzi; my możemy organizować pracę setek agentów w cyfrowej fabryce. Analogia jest kusząca, ale ma granicę. Wydajność nie zwalnia z odpowiedzialności za to, co fabryka wytwarza i komu służy.

Gdy pierwszy raz zobaczyłem ChatGPT i zacząłem rozumieć, jak działają modele językowe oparte na architekturze transformera, wiedziałem, że w naszej branży IT — szczególnie w kodowaniu — nastąpi zmiana wywracająca dotychczasowy sposób pracy. Rok po roku modele coraz lepiej radziły sobie z kodem. Już praca o modelu Codex z 2021 roku opisywała uczenie na publicznie dostępnym kodzie. Dziś nie chodzi tylko o wygenerowanie funkcji na żądanie. Możemy zaprojektować proces, w którym agenci planują, implementują, uruchamiają testy, analizują błędy i poprawiają wynik. To jest dla mnie początek cyfrowej fabryki oprogramowania.

Co naprawdę znaczy „ciemna fabryka” oprogramowania?

W przemyśle lights-out factory oznacza zakład, który może pracować przez długi czas bez ludzi stojących przy każdej maszynie. W oprogramowaniu słowo „dark” jest metaforą autonomicznego przepływu pracy, a nie zachętą do ukrywania procesu. Warto odróżnić ogólne określenie Software Dark Factory od konkretnej inicjatywy StrongDM Software Factory. StrongDM opisuje własny sposób pracy: ludzie określają intencję i scenariusze, a agenci wytwarzają kod i iterują na podstawie walidacji. To przykład wdrożenia, nie gotowy standard dla każdej firmy.

W zwykłej automatyzacji agent dostaje polecenie „zrób funkcję”, oddaje diff, a człowiek szuka błędów. Fabryka zaczyna się dopiero wtedy, gdy istnieje powtarzalna pętla: zadanie, kontrolowane środowisko, niezależne kryteria odbioru, obserwowalny wynik i mechanizm poprawy. Jeden udany prompt nie jest fabryką. Sto równoległych promptów bez dobrego sprawdzania to tylko szybsza produkcja błędów.

Ta część AI SDLC dotyczy użycia AI do wytwarzania oprogramowania. Jeśli produktem jest sam system AI, dochodzą jeszcze dane, ewaluacje zachowania modelu i zarządzanie jego zmianami. Te dwa nurty często spotykają się w jednym repozytorium, ale nie wolno utożsamiać ich testów.

Pętla, która zamienia agentów w system produkcyjny

Wyobraźmy sobie firmę, która chce dodać do panelu klientów możliwość zgłaszania reklamacji. Nie zaczyna od komendy „napisz cały moduł”. Zespół ustala, kto może zgłosić reklamację, jakie dane wolno pobrać, co ma się wydarzyć po wysłaniu formularza i po czym poznać poprawny wynik. Tę intencję można zapisać w specyfikacji z kryteriami odbioru. Dopiero potem agent dostaje pracę.

Etap	Co dzieje się w fabryce	Co może pójść źle
Intencja i ograniczenia	Człowiek definiuje cel, domenę, dane i zakazy.	Agent optymalizuje źle opisany cel.
Podział pracy	Orkiestrator przydziela zadania agentom w odrębnych środowiskach.	Równoległe zmiany wchodzą sobie w drogę.
Wytwarzanie	Agenci piszą kod, testy, migracje i dokumentację.	Powstaje spójna stylistycznie, lecz błędna implementacja.
Niezależna walidacja	CI uruchamia testy, scenariusze użytkownika, kontrole bezpieczeństwa i zgodności.	Testy tylko potwierdzają błędne założenie agenta.
Sprzężenie zwrotne	Agent dostaje diff, log, ślad, zrzut ekranu lub niezaliczony scenariusz.	Pętla poprawia wskaźnik testu kosztem realnego zachowania.
Odbiór i eksploatacja	Właściciel produktu i zespół decydują o wydaniu, obserwują skutki i tworzą następne zadania.	Dobra ocena lokalna przesłania koszt lub szkodę na produkcji.

StrongDM formułuje rdzeń swojej fabryki jako „seed → validation harness → feedback loop”. „Seed” to zalążek intencji i projektu; validation harness jest środowiskiem, które potrafi ocenić zachowanie; pętla odsyła wynik do agentów. Najważniejsza różnica dotyczy jakości sprawdzania. Gdy agent może dowolnie zmienić kod i wszystkie testy, zielony wynik niewiele dowodzi. Część scenariuszy odbiorczych powinna pozostać niezależna od wykonawcy. Dla reklamacji mogą to być przypadki dotyczące cudzych danych, dwukrotnego wysłania, awarii usługi i śladu audytowego.

Podobną lekcję opisuje OpenAI w tekście o harness engineering: inżynierowie projektowali środowisko, ograniczenia architektoniczne i informacje zwrotne dla agentów. To ważniejsza zmiana roli niż sam wzrost liczby wygenerowanych linii kodu. Dojrzała organizacja inwestuje w czytelne logi, uruchamialne testy, stabilne środowiska, dane testowe i jednoznaczne kontrakty, bo agent potrzebuje dowodów równie bardzo jak człowiek.

W przykładzie reklamacji pętla powinna umieć odtworzyć całe zdarzenie: klient składa zgłoszenie, system zapisuje jego identyfikator, odpowiednia osoba dostaje powiadomienie, a drugi klient nie widzi cudzej sprawy. Agent może poprawić walidację formularza po błędzie testu. Nie może jednak uznać, że problem zniknął, gdy usunie sprawdzenie izolacji klientów albo zmieni definicję oczekiwanego wyniku. Właściciel kryteriów odbioru i wykonawca zmian muszą pozostać odrębnymi rolami, nawet jeśli obie wspierają różne agenty.

Informacja zwrotna też powinna być konkretna. „Test nie przeszedł” pozostawia modelowi pole do zgadywania. Znacznie lepszy jest zestaw: nazwa scenariusza, wejście, oczekiwany rezultat, wynik rzeczywisty, ślad operacji i wskazanie wersji kodu. Potem można sprawdzić, czy poprawka usunęła przyczynę, czy tylko dopasowała się do jednego przypadku. To jest mechanizm uczenia procesu między iteracjami, a nie dowód, że sam model zmienia swoje wagi podczas pracy w repozytorium.

Roje agentów: gdzie skala pomaga, a gdzie szkodzi?

Rój ma sens, gdy zadanie można podzielić na względnie niezależne prace: migrację bibliotek w wielu pakietach, testy kilku modułów, analizę zależności i dokumentację. Orkiestrator musi wiedzieć, co jest gotowe, co blokuje inne zadania i które zmiany wymagają wspólnego przeglądu. W przeciwnym razie rośnie liczba konfliktów, koszt modeli i czas integracji. OpenAI opisuje własną orkiestrację agentów jako mechanizm przydzielania pracy i kontroli wyników; sama możliwość uruchomienia wielu agentów nie rozwiązuje problemu koordynacji.

Mała poprawka w jednym pliku zwykle nie potrzebuje roju. Wąskie gardło często przesuwa się z pisania kodu do jakości wymagań, danych testowych i decyzji produktowej. Jeśli czterdziestu agentów czeka na niejednoznaczny opis procesu reklamacji, dodanie kolejnych czterdziestu nie pomoże. Skalowalność cyfrowej fabryki jest ogromna w porównaniu z fizyczną, lecz nie jest nieograniczona: ograniczają ją koszt inferencji, przepustowość CI, wspólny stan repozytorium, prawa do danych i zdolność organizacji do odbioru pracy.

Dlatego rola inżyniera przesuwa się w stronę projektowania granic: interfejsów, testów, uprawnień i ścieżek przywrócenia działania. Nadal trzeba rozmawiać z klientem, rozumieć wyjątki procesu i odróżniać poprawny program od rozwiązania właściwego problemu. Rozwijam tę zmianę w artykule o przejściu kodera do roli FDE.

W praktyce pojawiają się trzy funkcje, choć nie muszą być trzema stanowiskami. Ktoś odpowiada za intencję: rozstrzyga, jaki problem klienta ma zniknąć i jakie kompromisy są dopuszczalne. Ktoś odpowiada za harness: zapewnia dane, środowiska, testy i polityki, których agent nie powinien zmienić dla łatwiejszego wyniku. Ktoś odpowiada za wydanie: ocenia zmianę w kontekście produktu, ryzyka i możliwości wycofania. Przeniesienie pisania kodu na agentów nie usuwa tych obowiązków. Zwykle czyni je bardziej widocznymi.

Autonomia wymaga granic poza promptem

Agent może przeczytać złośliwą instrukcję w dokumentacji, zależności albo wyniku wyszukiwania. Może też pomylić środowisko testowe z produkcyjnym. Dlatego sam plik z instrukcjami nie wystarcza. W AGENTS.md warto opisać reguły pracy, ale plik nie jest zaporą sieciową ani systemem uprawnień. Równoległe zadania powinny mieć odrębne środowiska, ograniczony dostęp do danych i tajemnic, a działania zewnętrzne muszą przechodzić przez niezależne kontrole.

Przykładem takiej warstwy jest NVIDIA OpenShell: uruchamia agenta w sandboxie i egzekwuje polityki dostępu do plików, procesów, sieci oraz usług. To nie sprawia, że agent rozumie biznes lepiej. Ogranicza natomiast szkody, które może wyrządzić, gdy się pomyli lub zostanie zmanipulowany. Fabryka, która ma pracować długo i równolegle, potrzebuje właśnie takiego rozdzielenia między zdolnością do działania a prawem do działania.

Czy to będą złote czasy open source?

Wierzę, że tak — pod warunkiem, że potraktujemy otwarty kod jako wspólną infrastrukturę wiedzy, a nie darmowy surowiec bez reguł. Publiczne repozytoria, dokumentacja, testy i czytelne licencje pozwalają ludziom i agentom zrozumieć zależności, odtworzyć błędy oraz ulepszać narzędzia. Otwarte projekty mogą zyskać więcej poprawek i szybszą integrację. Dla suwerennych systemów ważne jest też to, że kod narzędzi, harnessów i modeli otwartych na kontrolę można uruchamiać oraz audytować na własnej infrastrukturze.

Nie oznacza to jednak, że każdy model ma dostęp do „całego kodu świata”. Dane użyte do treningu, kod publicznie dostępny dzisiaj i repozytorium udostępnione agentowi podczas zadania to trzy różne rzeczy. Model nie uczy się automatycznie z każdej nowej interakcji, a publiczna dostępność pliku nie usuwa licencji ani praw autora. Kto może trenować na kodzie, na jakich warunkach wolno powielać wynik i jak wynagradzać twórców? To ważny temat na osobny artykuł. Dziś uczciwiej postawić pytanie niż udawać, że jest już rozstrzygnięte.

Jak zacząć bez budowania mitycznej fabryki od razu?

Wybierz jeden powtarzalny typ zmian, na przykład naprawy błędów z dobrymi testami regresji. Zapisz wymagania i dwa lub trzy scenariusze, których agent nie może dowolnie przepisać. Daj mu osobne środowisko, ograniczone uprawnienia i dostęp do logów. Uruchom pętlę: implementacja, niezależny test, informacja zwrotna, poprawka. Po kilku zadaniach oceń nie liczbę commitów, lecz jakość wydanej funkcji, pracę ludzi przy odbiorze, incydenty i koszt całej pętli.

Zapisz też warunek zatrzymania. Jeśli po kolejnych iteracjach agent wraca do tego samego błędu, rozszerza zakres zmian albo prosi o coraz szersze uprawnienia, zadanie wraca do człowieka. Jeżeli testy przechodzą, ale klient w próbie odbiorczej nadal nie potrafi wykonać pracy, nie zwiększaj liczby agentów: popraw definicję celu. Fabrykę warto skalować dopiero wtedy, gdy taki pojedynczy cykl daje powtarzalny, mierzalny rezultat.

„Ciemna” fabryka nie powinna być czarną skrzynką. Im dłużej może działać bez człowieka przy klawiaturze, tym bardziej potrzebuje widocznych kryteriów, śladów decyzji i możliwości zatrzymania. W łódzkiej historii maszyna pomnażała zarówno ambicję, jak i błędy właścicieli. Z agentami będzie podobnie. Naszą przewagą nie stanie się liczba cyfrowych pracowników, ale umiejętność nadania im dobrego celu i sprawdzenia, czy rzeczywiście go osiągnęli.