Wieloletni horyzont wdrożenia: dlaczego autonomiczne fabryki oprogramowania nie powstaną w najbliższych miesiącach

Wizja, w myśl której autonomiczne fabryki oprogramowania (dark software factories) zastąpią inżynierów i całkowicie przejmą cykl wytwórczy oprogramowania w perspektywie najbliższych miesięcy, zderza się z twardą rzeczywistością systemów produkcyjnych. Choć koncepcja bezobsługowego tworzenia aplikacji sterowanego wyłącznie planem rozpala wyobraźnię menedżerów, eksperci z branży wskazują na zupełnie inny horyzont czasowy. Ze względu na bariery architektoniczne, dryf kontekstu modeli oraz konieczność stałego, ręcznego nadzoru nad poszczególnymi etapami prac, technologia osiągnie pełną dojrzałość dopiero w perspektywie kilku lat — najwcześniej na początku przyszłej dekady.

Mit bezobsługowych „Dark Software Factories” a zalew „AI Slop”

Pojęcie dark software factories nawiązuje bezpośrednio do przemysłowego modelu lights-out manufacturing, w którym fabryka funkcjonuje w całkowitej ciemności, bez fizycznej obecności ludzi na hali produkcyjnej. W inżynierii oprogramowania koncepcja ta zakłada stan, w którym agenci sztucznej inteligencji samodzielnie przekładają wymagania biznesowe na kod, tworzą testy, konfigurują infrastrukturę i wdrażają stabilne wydania.

Jak zauważają Łukasz Kałużny i Szymon Warda w podcaście Patoarchitekci (związani na co dzień z firmą PROTOPIA), próby bezrefleksyjnego forsowania tego podejścia przy obecnym stanie technologii nie tworzą sprawnych fabryk oprogramowania, lecz tzw. AI slop factories. Bez rygorystycznego gorsetu inżynieryjnego proces wytwórczy zostaje zalany cyfrowym szumem: niskiej jakości kodem, sztucznie napompowanymi historyjkami użytkownika oraz powierzchownymi testami, które dają fałszywe poczucie bezpieczeństwa. Zamiast autonomii pojawia się ryzyko utraty kontroli nad systemem, ponieważ modele językowe mają tendencję do ignorowania ograniczeń projektowych, byle tylko formalnie zrealizować zadany prompt.

Dryf kontekstu modeli i kryzys odpowiedzialności

Fundamentalną barierą techniczną stojącą na drodze do pełnej automatyzacji jest dryf kontekstu modeli. Przy złożonych, wieloetapowych zadaniach model stopniowo traci spójność ze wstępnymi założeniami architektonicznymi i zaczyna podejmować decyzje sprzeczne z regułami domeny. Z tego powodu proces wymaga ciągłego zaangażowania człowieka: zarówno na etapie definiowania specyfikacji, jak i podczas odbioru wygenerowanych artefaktów.

Na pierwszy plan wysuwa się fundamentalne pytanie inżynieryjne i prawne: kto ostatecznie podpisze się pod kodem dostarczonym przez sztuczną inteligencję? Gdy w codzienne repozytoria wkraczają agenci kodujący, tradycyjne procedury kontroli jakości zostają poddane brutalnemu testowi. Praktyka code review, która w wielu organizacjach przez lata była iluzoryczna i polegała na bezrefleksyjnym klikaniu akceptacji, staje się wąskim gardłem. Szczególne wyzwanie stanowi skomplikowana architektura i backend, gdzie powierzchowne zrozumienie reguł domenowych przez model prowadzi do trudnych do wykrycia regresji i długu technologicznego.

Prawdziwy harness to nie plik Markdown

Wokół orkiestracji modeli narosło wiele nieporozumień terminologicznych. Jednym z najczęstszych błędów jest mylenie instrukcji dla agenta z właściwym środowiskiem wykonawczym (harness). W dyskusjach Patoarchitektów podkreśla się wyraźną granicę: plik w formacie Markdown (.md) czy zestaw deklaratywnych „skilli” nie stanowią harnessu. Agent potrafi ominąć miękkie wytyczne tekstowe, jeśli uzna to za wygodniejszy skrót do osiągnięcia celu.

Autentyczny harness to twarda, deterministyczna konfiguracja oraz bramki jakości (quality gates), których agent nie jest w stanie pominąć, nawet jeśli bardzo by chciał:

• Statyczna analiza kodu i reguły wymuszane przez narzędzia pokroju SonarQube;
• Rygorystyczne testy architektoniczne weryfikujące granice modułów i zależności;
• Środowiska efemeryczne i szybkie buildy weryfikujące każdą modyfikację w izolacji;
• Sztywne uprawnienia systemowe ograniczające destrukcyjne działania modeli.

Zamiast rozbudowanych, trudnych w utrzymaniu rozwiązań w rodzaju Spec Kita, eksperci postulują powrót do dyscypliny w duchu lekkiego Spec Driven Development. W tym ujęciu specyfikacje tworzone m.in. z wykorzystaniem modeli C4 traktowane są jak niezmienne rekordy decyzji architektonicznych (ADR) – ewentualne korekty nie polegają na modyfikowaniu starych założeń w locie, lecz na definiowaniu nowych, precyzyjnych zadań.

Ekonomia tokenów i mit domowego self-hostingu

Kolejnym hamulcem na drodze do natychmiastowego wdrożenia autonomicznych fabryk jest twarda ekonomia. Okres tanich subskrypcji dobiega końca, a realne budżety tokenowe zaczynają stanowić istotną pozycję kosztową w projektach IT. Z doświadczeń zespołów inżynieryjnych wyłaniają się konkretne liczby:

• 200–300 dolarów miesięcznie na jednego inżyniera DevOps przy typowych zadaniach infrastrukturalnych;
• 500–600 dolarów miesięcznie na developera realizującego złożone zadania, takie jak migracje starszego kodu w ekosystemie .NET;
• 3000 euro w prognozie miesięcznych wydatków dla niewielkiego, czteroosobowego zespołu;
• Skrajne przypadki braku nadzoru budżetowego, skutkujące przepaleniem nawet 13 tysięcy na kredyty narzędzia Copilot przez pojedynczą osobę.

Nadzieje na ominięcie tych wydatków poprzez uruchamianie modeli we własnej infrastrukturze również okazują się przedwczesne. Self-hosting zaawansowanych modeli to na obecnym etapie mit finansowy. Nawet wydajna stacja robocza M5 Max wyposażona w 128 GB pamięci zunifikowanej osiąga zaledwie 30-parę tokenów na sekundę. Przy takiej przepustowości obsługa złożonych pętli zwrotnych staje się wąskim gardłem, a koszt zakupu sprzętu przewyższa opłaty chmurowe.

Nowy horyzont inżynierii oprogramowania

Przejście od asystentów programisty do w pełni autonomicznych fabryk oprogramowania nie wydarzy się z dnia na dzień. Przekonanie, że za kilka miesięcy oprogramowanie będzie powstawać bez udziału człowieka, ignoruje problematykę atrofii umiejętności inżynierskich, braku determinizmu w generowanym kodzie oraz konieczności utrzymania długoterminowej spójności systemów. Aby uniknąć fali wypaleń wśród najbardziej doświadczonych specjalistów zmuszonych do ciągłego debugowania kodu po modelach AI, nowoczesna inżynieria oprogramowania musi powrócić do fundamentów: szybkiego sprzężenia zwrotnego, architektonicznego rygoru i precyzyjnej weryfikacji każdego fragmentu kodu.