Deterministyczne pętle feedbacku a agenci kodujący: dlaczego miękkie procesy SDLC zawodzą
Masowe wdrażanie sztucznej inteligencji do inżynierii oprogramowania obnażyło zjawisko, które przez lata pozostawało w branży technologicznym tabu: agenci kodujący wcale nie zepsuli dotychczasowych procesów wytwórczych, lecz bezlitośnie obnażyli fikcję manualnego przeglądu kodu. Jak zauważają Szymon Warda i Łukasz Kałużny w 202. odcinku podcastu „Patoarchitekci”, inżynierowie przez lata tkwili w iluzji, że drobiazgowo weryfikują każdą zmianę wprowadzaną do repozytorium. W rzeczywistości domyślną praktyką zespołów było powierzchowne zatwierdzanie pull requestów na zasadzie: „tak, tak, tak może iść”. W erze maszynowej generacji oprogramowania, gdy modele tworzą setki linii w ułamki sekund, procesy miękkie oparte na zaufaniu i pobieżnym czytaniu diffów przestają działać. Jedyną barierą chroniącą systemy przed degradacją staje się powrót do deterministycznych pętli sprzężenia zwrotnego wywodzących się z rygorystycznych praktyk DevOps.
Iluzja manualnego review i odpowiedzialność za kod
Z perspektywy cyklu życia oprogramowania (SDLC) generowanie kodu przez modele LLM nie stworzyło nowych patologii, lecz przyspieszyło te istniejące. Człowiek nie jest fizjologicznie zdolny do krytycznej analizy syntaktycznej i semantycznej tysięcy linii kodu generowanych w trybie ciągłym. Gdy przegląd staje się wąskim gardłem, programiści zaczynają traktować kod od asystentów jak czarną skrzynkę.
Prowadzący podcast Patoarchitekci podkreślają jednak kluczowy aspekt prawny i inżynieryjny: sztuczna inteligencja nie ponosi odpowiedzialności za błędy produkcyjne. Niezależnie od tego, czy autorem pierwotnego szkicu funkcji był model generatywny, pod commitem i wdrożeniem zawsze podpisuje się konkretny człowiek. Próba przeniesienia odpowiedzialności na narzędzie jest bezpodstawna. Zamiast liczyć na to, że programista wyłapie subtelne błędy logiczne wzrokiem, zespoły muszą przestawić się na weryfikację maszynową, w której to środowisko wykonawcze udziela natychmiastowej, binarnej odpowiedzi o poprawności artefaktu.
Czym naprawdę jest harness: dlaczego instrukcje w plikach markdown nie wystarczą
Wokół pracy modeli autonomicznych narosło wiele nieporozumień pojęciowych, z których największe dotyczy definicji tzw. harnessu (uprzęży). Wielu twórców oprogramowania ogranicza się do przygotowania repozytoryjnego pliku konfiguracyjnego w formacie markdown oraz listy promptowych instrukcji („skilli”). Doświadczeni architekci wskazują, że takie podejście jest fundamentalnym błędem. Plik tekstowy stanowi jedynie sugestię dla probabilistycznego modelu, a nie twardą barierę architektoniczną.
Prawdziwy harness to konfiguracja techniczna oraz zestaw restrykcji środowiskowych, których agent nie jest w stanie pominąć, nawet jeśli bardzo by tego chciał. Modele językowe wykazują naturalną tendencję do zachowań oportunistycznych: potrafią zignorować reguły biznesowe, aby tylko osiągnąć postawiony w prompcie cel (np. doprowadzić do sytuacji, w której kompilator nie zgłasza błędów). Nowoczesne narzędzia i wdrożenie Claude Code pokazują, że CLI oraz warstwa orkiestracji muszą narzucać ścisły sandbox. Agent musi działać w odizolowanym kontenerze, z ograniczonymi uprawnieniami systemowymi i pod stałym nadzorem procesów kontrolnych.
Deterministyczne pętle sprzężenia zwrotnego i jakość w CI/CD
Aby autonomiczna praca agenta przynosiła stabilne rezultaty, probabilistyczny model musi zostać zamknięty w deterministycznej pętli zwrotnej. Oznacza to rezygnację z oceny jakości na podstawie kolejnych promptów na rzecz twardych sygnałów z narzędzi statycznych. Kod zwracany przez agenta musi natychmiast trafiać do kompilatora, linera oraz silników analizy statycznej, takich jak SonarQube.
Kluczowym elementem staje się wówczas automatyzacja CI/CD i DevOps, w ramach której potoki integracyjne natychmiast weryfikują wyjściowe artefakty. Mechanizmy te muszą być zakorzenione bezpośrednio w środowisku deweloperskim za pomocą hooków (pre-commit i pre-push) oraz efemerycznych środowisk testowych. Gdy agent popełni błąd naruszający reguły typowania czy bezpieczeństwa, informacją zwrotną nie jest opinia recenzenta, lecz jednoznaczny kod błędu i zrzut ze standardowego strumienia diagnostycznego.
W tej architekturze obowiązuje jedna twarda zasada inżynieryjna: agent pod żadnym pozorem nie może posiadać uprawnień do edycji plików z testami jednostkowymi, integracyjnymi ani testami architektonicznymi. Pozostawienie modelowi swobody modyfikacji asercji kończy się najprostszą ścieżką konwergencji — agent modyfikuje warunki testowe tak, aby pasowały do wadliwej implementacji, raportując fałszywy sukces.
Równolegle zmienia się podejście do dokumentowania wymagań. Tradycyjne, rozbudowane specyfikacje (jak próby wdrażania nieutrzymywalnego Spec Kita) ustępują miejsca lekkiemu podejściu spec-driven development, wspieranemu przez diagramy architektoniczne C4. W tym ujęciu inżynieria oprogramowania w SDLC opiera się na zwięzłych, technicznych kontraktach, które stanowią bezpośrednią podstawę do budowania automatycznych testów akceptacyjnych.
Ekonomia tokenów, mit self-hostingu i ryzyko fabryk slopu
Przejście na autonomiczną generację oprogramowania to także zderzenie z twardymi realiami budżetowymi. Skończył się etap tanich, ryczałtowych subskrypcji. Dane rynkowe przytaczane przez ekspertów pokazują zróżnicowane koszty infrastrukturalne: obsługa zadań inżyniera DevOps wymaga budżetu rzędu 200–300 dolarów miesięcznie, podczas gdy wsparcie programisty przy złożonych projektach, takich jak migracja starego .NET-u, pochłania 500–600 dolarów na osobę. W ujęciu zespołowym prognozy sięgają 3000 euro miesięcznie dla czteroosobowego zespołu. Brak odpowiednich limitów w pętlach narzędziowych prowadzi do anomalii — odnotowano już przypadek przepalenia 13 tysięcy dolarów na kredyty Copilota w niekontrolowanych zapytaniach.
Część organizacji próbuje uciekać przed rachunkami od dostawców chmurowych w stronę lokalnego hostingu modeli, jednak eksperci określają ten ruch wprost jako mit finansowy. Uruchomienie dużych modeli na stacjach roboczych nie zapewnia wymaganej przepustowości: nawet wyspecjalizowany układ Apple M5 Max wyposażony w 128 GB pamięci zunifikowanej osiąga przy lokalnym wnioskowaniu zaledwie 30-parę tokenów na sekundę, co uniemożliwia sprawną pracę w wieloetapowych pętlach sprzężenia zwrotnego.
Niekontrolowana generacja kodu bez deterministycznych barier grozi przekształceniem zespołów deweloperskich w tzw. AI slop factories lub dark software factories, produkujące gigantyczne wolumeny nieutrzymywalnego kodu. W połączeniu z atrofią podstawowych umiejętności programistycznych u juniorów i rosnącą falą wypalenia wśród doświadczonych inżynierów (high performerów), deterministyczny harness staje się warunkiem koniecznym przetrwania projektów IT. Tylko twarde reguły inżynieryjne i automatyczne testy są w stanie zagwarantować, że kod generowany maszynowo zachowa integralność architektoniczną.
