Problem powierzchownych wymagań projektowych generowanych automatycznie przez AI: jak „AI slop” paraliżuje proces SDLC

Masowe wdrażanie generatorów tekstu w procesach projektowych doprowadziło do zjawiska, w którym problem powierzchownych wymagań projektowych generowanych automatycznie przez AI stał się jednym z najpoważniejszych zagrożeń dla stabilności współczesnego cyklu wytwórczego oprogramowania. Zamiast rzetelnej analizy przypadków brzegowych oraz modelowania procesów domenowych, tablice w systemie Jira są masowo zalewane rozwlekłymi biletami tworzonymi przez modele językowe na podstawie jednozdaniowych poleceń. Powstający w ten sposób „AI slop w wymaganiach” stwarza groźną iluzję kompletności: tekst jest gramatycznie bezbłędny, podzielony na sekcje i nasycony technicznym żargonem, lecz w rzeczywistości pozbawiony kluczowych reguł biznesowych, co prowadzi do paraliżu implementacyjnego oraz gwałtownego wzrostu długu technicznego.

„Mięsne proxiaki” i ucieczka przed odpowiedzialnością w Jira

Jednym z głównych źródeł degradacji jakości specyfikacji jest zmiana zachowań po stronie osób odpowiedzialnych za zbieranie i definiowanie wymagań. W branżowym slangu pośrednicy w procesie decyzyjnym — Product Ownerzy czy analitycy biznesowi, określani niekiedy dosadnie jako „mięsne proxiaki” — zaczęli traktować modele generatywne jako automatyczne alibi. Wygenerowanie kilkuset słów kwiecistego opisu zadania w Jira zajmuje kilkanaście sekund i zwalnia twórcę z konieczności głębszego zastanowienia się nad realną architekturą systemu.

W zespołach pojawia się wyraźny opór przed stosowaniem ustrukturyzowanych, sformalizowanych metod opisu zachowania oprogramowania, takich jak konwencja Given-When-Then, tabele decyzyjne czy specyfikacje oparte na regułach BDD. Ustrukturyzowane podejście wymaga bowiem wysiłku intelektualnego, precyzji logicznej i jednoznacznego zdefiniowania warunków brzegowych. Generowanie ogólnikowego tekstu przez asystentów pozwala natomiast szybko zrzucić z siebie formalną odpowiedzialność za bilet: zadanie w Jira ma przecież wypełnione pola, zawiera listę kroków i sprawia wrażenie w pełni przygotowanego do developmentu. W rzeczywistości jest to jednak zjawisko czysto fasadowe.

Pozorna precyzja a degradacja architektury

Najbardziej zdradliwą cechą powierzchownych wymagań generowanych przez algorytmy jest ich pozorna poprawność (plausible but incorrect). Dokument wygląda profesjonalnie, co usypia czujność inżynierów i osób dokonujących przeglądu zadań. Zamiast zwięzłego kontraktu określającego stany systemu, programiści otrzymują wieloaspektowy, syntetyczny opis, w którym kluczowe założenia projektowe zostały zmyślone lub pominięte.

Gdy taka powierzchowna specyfikacja trafia do realizacji — niezależnie od tego, czy wdraża ją człowiek, czy autonomiczny agent programistyczny — błędy logiczne natychmiast przenikają do kodu źródłowego. W szczególności cierpi na tym logika biznesowa w backendzie, gdzie brak precyzyjnych walidacji, transakcyjności oraz obsługi błędów skutkuje powstawaniem niestabilnych mikroserwisów. Weryfikacja takiego kodu staje się koszmarem: recenzent nie ocenia już tylko kodu, lecz musi przeprowadzić inżynierię wsteczną całego biletu, by odgadnąć, co właściwie autor miał na myśli.

SDLC w erze agentów: lekki Spec-Driven Development i twardy harness

Kwestię konsekwencji bezrefleksyjnego stosowania generatywnych narzędzi w cyklu wytwórczym podjęli Łukasz Kałużny i Szymon Warda w 202. odcinku podcastu Patoarchitekci zatytułowanym „Kto się podpisze pod kodem od AI? - SDLC, koszty i harness”. Prowadzący postawili twardą diagnozę: nowoczesne narzędzia niczego nie zepsuły, a jedynie brutalnie obnażyły to, co w branży nie działało od lat. Jak zauważył Szymon Warda: „Czy robiliśmy review lat temu trzy? Nie, nie robiliśmy, tylko wszyscy okłamywali się, że robią review porządnie i klikali: tak, tak, tak może iść”.

Odpowiedzią na zalew „AI slop factories” nie jest jednak powrót do ociężałych, nieutrzymywalnych metodyk pokroju Spec Kita, lecz lekki Spec-Driven Development (SDD) oraz modelowanie oparte na architekturze C4. W takim podejściu specyfikacja staje się wersjonowanym w repozytorium kontraktem technicznym, a nie efemerycznym wpisem w Jira. Kluczową rolę zaczyna odgrywać również pojęcie harnessa. Jak podkreśla Łukasz Kałużny, harness to nie plik Markdown z promptem ani zestaw umiejętności (tzw. skille) wklejonych do edytora — harness to twarda konfiguracja środowiska wykonawczego, zestaw reguł, bramek jakościowych (quality gates), testów architektonicznych i narzędzi pokroju SonarQube, których agent programistyczny nie jest w stanie ominąć, nawet gdyby próbował pójść na skróty.

Współczesna inżynieria oprogramowania w SDLC wymaga przeniesienia punktu ciężkości z powierzchownego generowania treści na budowę szczelnych pętli zwrotnych, które natychmiast odrzucają kod niespełniający rygorystycznych kryteriów formalnych.

Koszty, rachunek ekonomiczny i powrót do inżynierskiego rygoru

Iluzja bezwysiłkowego wytwarzania dokumentacji i kodu zderza się także z realiami finansowymi. Koszty subskrypcji asystentów gwałtownie rosną: w praktyce zespołowej wynoszą one od 200–300 dolarów miesięcznie na inżyniera DevOps do 500–600 dolarów na developera przy migracji starszych platform, takich jak .NET. Forecasty dla czteroosobowego zespołu potrafią sięgać 3000 euro miesięcznie, a w skrajnych przypadkach odnotowano pojedyncze incydenty przepalenia 13 tysięcy na kredyty Copilota. Z kolei próby ucieczki w lokalny self-hosting modeli okazują się mitem finansowym — stacja M5 Max wyposażona w 128 GB pamięci jest w stanie wygenerować zaledwie 30-parę tokenów na sekundę, co wyklucza obsługę produkcyjnego ruchu zespołowego.

Zastępowanie rzetelnej analizy automatycznie wygenerowanym tekstem w Jira to prosta droga do utraty kontroli nad domeną. Dopóki zespoły traktują narzędzia tekstowe jako sposób na ucieczkę przed odpowiedzialnością, dopóty projekty będą grzęznąć w kosztownym chaosie. Ratunkiem pozostaje powrót do rygorystycznego definiowania kryteriów akceptacji, twardych kontraktów API oraz weryfikowalnych bramek architektonicznych, których żaden model nie zastąpi bez udziału świadomego inżyniera.