%20in%20software%20development.%20The%20image%20features%20a%20hierarchical%20structure%20showing%20software%20c.webp)
.%20The%20model%20is%20shown%20in%20four%20levels,%20with%20each%20level%20representi.webp){kind=spacer}
AI do kodowania weszło do codziennej pracy szybciej, niż wiele zespołów zdążyło zbudować wokół niego sensowne praktyki. Najpierw był zachwyt. Wrzucasz prompt, dostajesz kod. Doprecyzowujesz dwa szczegóły, model poprawia. Prosisz o testy, generuje testy. Prośba o refaktoryzację? Proszę bardzo. Na poziomie pojedynczego zadania wygląda to wręcz magicznie.
Problem zaczyna się później. Nie wtedy, gdy generujemy pierwszy endpoint. Nie wtedy, gdy robimy prosty komponent UI. Tylko wtedy, gdy z takiego podejścia próbujemy zbudować większy, dłużej żyjący system.
I właśnie w tym miejscu pojawia się fundamentalna różnica między promptem a specyfikacją.
Prompt uruchamia odpowiedź. Spec uruchamia proces wytwarzania.
To zdanie dobrze ustawia cały problem. Bo choć przez chwilę może się wydawać, że promptowanie AI to nowy model developmentu, w praktyce bardzo szybko okazuje się, że prompt-driven development nie skaluje się w projektach. Skaluje się co najwyżej w eksperymentach, prototypach i krótkich iteracjach wykonywanych przez jedną osobę, która cały kontekst trzyma jeszcze w głowie.
Dlaczego prompt-driven development działa tak dobrze na początku?
Żeby uczciwie opisać problem, warto zacząć od tego, dlaczego promptowanie w ogóle jest tak kuszące. Powód jest prosty: ono naprawdę działa. I to działa zaskakująco dobrze.
Jeśli tworzysz mały feature, narzędzie pomocnicze, prosty landing page, parser, integrację z jednym API albo szybki proof of concept, prompt potrafi dostarczyć ogromną wartość. Skraca czas wejścia, obniża koszt pierwszej implementacji i redukuje tarcie przy przejściu od pomysłu do pierwszego działającego wyniku.
To właśnie dlatego tak wiele osób zakochało się w AI coding assistants. Bo w porównaniu z pustym plikiem prompt wydaje się genialnym interfejsem. Zamiast pisać wszystko od zera, zaczynasz od rozmowy. Zamiast konstruować każde rozwiązanie ręcznie, możesz kierować modelem jak bardzo szybkim, bardzo sprawnym juniorem z nieskończoną energią.
Ale jest w tym haczyk. Ten model świetnie działa lokalnie, dla pojedynczych zadań. Problem w tym, że software engineering rzadko kończy się na lokalnym sukcesie jednego zadania. Systemy żyją długo. Zmieniają się. Rozrastają się. Wchodzą w interakcje z innymi systemami. Są rozwijane przez wiele osób. Podlegają ograniczeniom domenowym, architektonicznym, bezpieczeństwa, wydajności i zgodności.
I wtedy prompt zaczyna pokazywać swoje granice.
Czym właściwie jest prompt-driven development?
W najprostszym ujęciu to sposób pracy, w którym głównym mechanizmem sterowania implementacją jest rozmowa z modelem. Zamiast opierać development na trwałych artefaktach, takich jak specyfikacja, kontrakt, scenariusze, ADR czy model domeny, opieramy go głównie na kolejnych wiadomościach w czacie.
Przykładowy flow wygląda tak:
- opisujesz, co chcesz zbudować,
- AI generuje pierwszą wersję,
- dopisujesz poprawki,
- AI dostosowuje kod,
- pojawia się kolejny edge case,
- wrzucasz następny prompt,
- pojawia się problem architektoniczny,
- rozwiązujesz go kolejną rozmową.
Na krótkim dystansie to wygląda sensownie. Na dłuższym zaczyna przypominać budowanie systemu z pamięci krótkotrwałej. Wszystko działa, dopóki wszyscy pamiętają, co już ustaliliśmy. A to nie jest solidny fundament dla większego projektu.
Największy problem: chat nie jest source of truth
To jest chyba najważniejszy punkt całego artykułu.
Historia rozmowy nie jest dobrym źródłem prawdy dla projektu.
Czat jest świetny do eksploracji. Do iteracji. Do szybkiego zawężania pomysłów. Do generowania wariantów. Ale bardzo słabo nadaje się na trwały nośnik decyzji projektowych.
Dlaczego?
Bo rozmowa jest z natury liniowa, ulotna i zależna od kolejności komunikatów. Część ważnych ustaleń pojawia się mimochodem. Część ginie kilka ekranów wyżej. Część zostaje nadpisana nowym promptem. Część zostaje błędnie zreinterpretowana przez model. Część w ogóle nie trafia do żadnego miejsca, z którego inna osoba albo inny agent AI mogliby z niej później skorzystać.
W rezultacie zespół zaczyna funkcjonować w bardzo niebezpiecznym trybie: „to było gdzieś w rozmowie”.
A jeśli coś było „gdzieś w rozmowie”, to w praktyce bardzo często znaczy, że nie istnieje jako stabilny artefakt.
Prompt nie utrzymuje spójności systemowej
Drugi problem jest równie ważny: prompt bardzo słabo utrzymuje spójność między decyzjami.
W dobrze prowadzonym projekcie nie chodzi tylko o to, żeby każdy pojedynczy fragment kodu działał. Chodzi też o to, żeby całość była spójna. Nazewnictwo. Reguły domenowe. Podejście do błędów. Styl integracji. Kontrakty API. Standardy bezpieczeństwa. Logging. Metryki. Sposób modelowania encji. Granice odpowiedzialności modułów.
Jeśli każdy kolejny element systemu powstaje z osobnego promptu, istnieje bardzo duże ryzyko, że AI za każdym razem będzie interpretować problem odrobinę inaczej. Raz użyje jednego wzorca. Innym razem drugiego. Raz nazwie encję Customer, innym razem Client. Raz założy synchroniczny flow, innym razem asynchroniczny. Raz doda walidację w kontrolerze, innym razem w serwisie.
Każda z tych różnic może wydawać się niewielka. Ale w skali projektu to właśnie z takich różnic powstaje architektoniczny chaos.
Ambiguity at machine speed
W poprzednim artykule newsowym pojawiła się bardzo ważna intuicja: niejednoznaczność porusza się dziś z prędkością maszyny.
Kiedyś nieprecyzyjne wymaganie oznaczało, że programista przez kilka godzin albo dni źle rozumiał zadanie. Dziś nieprecyzyjne wymaganie może w kilka minut wygenerować kod, testy, dokumentację i jeszcze propozycję refaktoryzacji, wszystkie oparte na błędnym założeniu.
To zmienia skalę problemu. AI nie tworzy nowego rodzaju chaosu. Ono po prostu dramatycznie przyspiesza dostarczanie chaosu tam, gdzie wejście jest nieprecyzyjne.
Dlatego promptowanie nie rozwiązuje problemu niejednoznaczności. Ono go często maskuje na początku, a potem zwielokrotnia.
Prompt nie tworzy kontraktu
Jest jeszcze jedna rzecz, o której mówi się zdecydowanie za mało. Prompt może być instrukcją, ale bardzo rzadko jest kontraktem.
Kontrakt mówi nie tylko, co zrobić, ale również:
- jakie są granice rozwiązania,
- jakie zachowania są obowiązkowe,
- jakie wyjątki trzeba obsłużyć,
- jakie warunki uznajemy za poprawność,
- jakie elementy są poza zakresem.
Prompt bardzo często jest skrótem myślowym. Czasem bardzo dobrym skrótem. Ale nadal skrótem. A systemów produkcyjnych nie powinno się budować na skrótach myślowych, jeśli chcemy przewidywalności.
Właśnie tu zaczyna się przewaga specyfikacji.
Spec to nie dłuższy prompt
To bardzo ważne rozróżnienie. Gdy mówię, że promptowanie nie skaluje się w projektach, nie mam na myśli tego, że wystarczy po prostu pisać dłuższe prompty.
Specyfikacja nie jest „większym promptem”.
Spec to inny rodzaj artefaktu.
Dobrze przygotowana specyfikacja jest:
- trwała,
- strukturalna,
- podzielona na warstwy,
- możliwa do przeglądu i wersjonowania,
- czytelna dla ludzi i użyteczna dla AI,
- powiązana z walidacją.
Prompt jest impulsem. Spec jest modelem pracy.
Prompt jest rozmową. Spec jest systemem odniesienia.
Prompt inicjuje wykonanie. Spec stabilizuje delivery.
Jak wygląda różnica w praktyce?
Załóżmy, że chcesz zbudować moduł promocji w e-commerce.
W podejściu prompt-driven możesz napisać coś w stylu:
Zbuduj moduł promocji dla sklepu online. Powinien obsługiwać rabaty procentowe, promocje 2+1 i ograniczenia czasowe. Dodaj API i testy.
To wystarczy, żeby AI wygenerowało coś sensownego. Być może nawet całkiem niezłego. Ale natychmiast pojawiają się pytania:
- Czy promocje mogą się łączyć?
- Co ma wygrać przy konflikcie dwóch promocji?
- Czy promocja działa per kanał, per sklep, per klient, per koszyk?
- Czy walidacja ma blokować zapis, czy tylko ostrzegać?
- Jak mierzymy skuteczność promocji?
- Jakie są ograniczenia wydajnościowe?
- Jakie eventy system ma publikować?
W podejściu spec-driven zaczynasz od czegoś zupełnie innego. Najpierw definiujesz kontekst biznesowy. Potem zakres. Potem model domenowy. Potem scenariusze BDD. Potem edge case’y. Potem kontrakty API i ograniczenia architektoniczne. Dopiero na końcu pojawia się implementacja.
I właśnie dlatego efekt końcowy jest bardziej przewidywalny. Nie dlatego, że AI nagle stało się „mądrzejsze”. Tylko dlatego, że dostało lepszy artefakt wejściowy.
Dlaczego prompt-driven development rozpada się w zespole?
Jedna osoba może jeszcze przez jakiś czas utrzymać projekt oparty głównie na rozmowach z AI. Zwłaszcza jeśli sama była autorem większości promptów i pamięta intencję stojącą za decyzjami.
Ale kiedy do projektu wchodzi zespół, sytuacja się komplikuje.
Nagle trzeba odpowiedzieć na pytania:
- Skąd nowa osoba ma wiedzieć, dlaczego coś zrobiono tak, a nie inaczej?
- Jak inny developer albo architekt ma odtworzyć decyzje ukryte w historii czatu?
- Jak tester ma zrozumieć oczekiwane zachowanie bez trwałych scenariuszy?
- Jak kolejny agent AI ma zachować spójność z poprzednimi decyzjami?
Jeśli odpowiedź brzmi „trzeba przejrzeć całą rozmowę”, to znaczy, że proces nie skaluje się organizacyjnie.
To właśnie dlatego zespoły potrzebują artefaktów, które żyją poza czatem.
Co w takim razie skaluje się lepiej?
Lepszym modelem jest podejście, w którym prompt nie znika, ale przestaje być głównym nośnikiem logiki projektu.
Innymi słowy: nie chodzi o rezygnację z promptów. Chodzi o obniżenie ich rangi.
W zdrowym, skalowalnym modelu prompt jest tylko jednym z interfejsów wykonawczych, a nie centralnym artefaktem systemu. Centralnym artefaktem staje się specyfikacja.
Flow wygląda wtedy mniej więcej tak:
Business Context → Scope → Domain Model → Scenarios → Contracts → Validate → Code
albo jeszcze prościej:
Spec → Plan → Tasks → Code → Validate
W takim modelu AI nadal robi bardzo dużo pracy. Nadal może generować kod, testy, diagramy, dokumentację, migracje czy propozycje refaktoryzacji. Ale robi to już w ramach ustalonych granic.
To jest dokładnie ta różnica, która odróżnia eksperyment od engineeringu.
Prompt jest świetny do eksploracji. Spec jest potrzebny do dostarczania
Nie chcę demonizować promptów. Byłoby to nieuczciwe i mało praktyczne. Prompt ma ogromną wartość. Problem zaczyna się dopiero wtedy, gdy próbujemy uczynić z niego fundament całego procesu.
Moim zdaniem prompt najlepiej sprawdza się w trzech sytuacjach:
- eksploracja problemu,
- szybkie prototypowanie,
- iteracyjne dopracowywanie szczegółów w ramach już ustalonej specyfikacji.
Natomiast gdy zależy nam na trwałości decyzji, spójności systemu, współpracy w zespole, traceability i przewidywalności jakości, potrzebujemy czegoś więcej. Potrzebujemy specu.
Najważniejsza zmiana mentalna
W erze AI bardzo łatwo wpaść w pułapkę myślenia, że skoro model potrafi generować kod z języka naturalnego, to wystarczy już tylko dobrze „pogadać z AI”.
Ale software engineering nigdy nie polegał wyłącznie na produkcji kodu. Zawsze chodziło o redukowanie ryzyka błędnej interpretacji, stabilizowanie decyzji i tworzenie systemów, które da się rozwijać w czasie.
Dlatego najważniejsza zmiana mentalna brzmi:
nie projektujemy już tylko kodu. Projektujemy artefakty wejściowe dla ludzi i AI.
A najlepszym takim artefaktem nie jest ulotna rozmowa. Jest nim dobrze zbudowana specyfikacja.
Podsumowanie
Promptowanie AI jest świetne. Ale tylko wtedy, gdy wiemy, do czego służy.
Jako narzędzie do szybkiej eksploracji, prototypowania i przyspieszania lokalnych zadań prompt sprawdza się znakomicie. Jako centralny fundament większego projektu zaczyna bardzo szybko ujawniać swoje ograniczenia.
Nie utrzymuje trwałego kontekstu. Nie gwarantuje spójności. Nie buduje kontraktu. Nie skaluje się dobrze na zespół. I zbyt łatwo zamienia niejednoznaczność w szybki, pozornie imponujący, ale kosztowny chaos.
Dlatego właśnie uważam, że:
Prompt to rozmowa. Spec to system.
I jeśli chcemy naprawdę kuć software z pomocą AI, to nie możemy zatrzymać się na rozmowie. Musimy przejść do specyfikacji.
