{dev} forge – Jak budować specyfikację w OpenSpec pod AI coding agents

Do tej pory w serii {dev} forge – How software is forged with AI rozmawialiśmy głównie o ideach:

• czym jest Spec-Driven Development,
• dlaczego promptowanie nie skaluje się w projektach,
• jak wygląda dobra specyfikacja,
• oraz dlaczego AI potrzebuje kontraktu zamiast luźnej rozmowy.

Pora więc przejść do praktyki.

W tym artykule pokażę, jak wygląda realny workflow pracy z AI w podejściu spec-driven przy użyciu OpenSpec oraz Codex CLI.

I właśnie tutaj zaczyna się najciekawsza część całego trendu.

Bo kiedy pierwszy raz zobaczysz, że AI nie pracuje już na pojedynczym promptcie, tylko na uporządkowanej specyfikacji, bardzo szybko zrozumiesz jedną rzecz:

przyszłość AI-assisted development nie wygląda jak chat. Wygląda jak pipeline specyfikacji.

Czym właściwie jest OpenSpec?

OpenSpec to lekki framework do Spec-Driven Development, którego celem jest uporządkowanie współpracy z AI coding assistantami wokół trwałych artefaktów zamiast ulotnych rozmów.

Projekt wspiera wiele narzędzi AI, między innymi:

• Codex,
• Claude Code,
• Cursor,
• GitHub Copilot,
• Gemini CLI.

OpenSpec opisuje się jako:

• open source,
• universal,
• bez API keys,
• bez MCP.

Najważniejsze jednak jest coś innego:

OpenSpec zamienia specyfikację w aktywny artefakt procesu developmentu.

Źródła:

• https://openspec.dev/
• https://github.com/Fission-AI/OpenSpec

Jak wygląda workflow OpenSpec?

Domyślny workflow wygląda mniej więcej tak:

Propose → Explore → Apply → Validate → Archive

Czyli:

• najpierw definiujesz zmianę,
• potem eksplorujesz rozwiązanie,
• następnie AI implementuje zmianę,
• na końcu walidujesz rezultat i archiwizujesz decyzję.

To jest ogromna różnica względem klasycznego „wrzuć prompt i zobacz co wyjdzie”.

OpenSpec wymusza bowiem myślenie o zmianie jako o procesie opartym o trwałe artefakty.

Instalacja OpenSpec

OpenSpec działa jako pakiet npm.

Instalacja jest bardzo prosta:

npm install -g @fission-ai/openspec@latest

Po instalacji możesz sprawdzić wersję:

openspec --version

Źródła:

• openspec.dev
• GitHub OpenSpec

Inicjalizacja projektu

Następnie przechodzisz do repozytorium projektu:

cd my-project

I uruchamiasz:

openspec init

OpenSpec skonfiguruje workflow oraz zainstaluje odpowiednie skills i komendy dla wybranego narzędzia AI.

Domyślnie aktywowany jest profil core, który zawiera workflow:

• propose
• explore
• apply
• sync
• archive

Źródło:

• supported-tools.md

OpenSpec + Codex

I tutaj robi się naprawdę ciekawie.

OpenSpec ma natywne wsparcie dla Codex.

Podczas inicjalizacji może instalować:

• skills,
• workflow commands,
• spec-driven prompts.

Dla Codex instalowane są między innymi:

.codex/skills/openspec-*/SKILL.md

oraz workflow commands:

$CODEX_HOME/prompts/opsx-*

Źródło:

• OpenSpec supported tools

Jak działają skills?

Skills to jeden z najważniejszych elementów nowoczesnego AI-assisted development.

Można je traktować jak:

• procedury operacyjne dla AI,
• specjalizowane instrukcje,
• trwałą wiedzę domenową.

Zamiast za każdym razem tłumaczyć AI:

• jak wygląda architektura projektu,
• jakie są standardy kodowania,
• jakie obowiązują reguły bezpieczeństwa,
• jakie są konwencje nazewnicze,

skills dostarczają ten kontekst automatycznie.

To właśnie tutaj zaczynamy odchodzić od „AI jako chat” w stronę „AI jako uczestnik procesu engineeringowego”.

Instalacja skills w Codex

Codex wspiera skills w bardzo podobny sposób do Claude Code.

Skills można instalować:

• globalnie,
• per projekt,
• bezpośrednio z repozytoriów.

Przykładowo Codex wykrywa skills w katalogach:

~/.codex/skills/

lub:

.codex/skills/

Codex automatycznie ładuje skills przy starcie sesji.

Źródła:

• OpenAI Codex Skills
• Codex Skills Guide

Praktyczny przykład – budowa feature’a

Załóżmy, że chcemy dodać nowy feature:

„Program lojalnościowy dla klientów premium w sklepie online”

W klasycznym prompt-driven development moglibyśmy napisać:

Dodaj loyalty program dla klientów premium.

I AI prawdopodobnie wygenerowałoby jakiś kod.

W OpenSpec zaczynamy zupełnie inaczej.

Krok 1 – Propose

Najpierw definiujemy zmianę.

Powstaje proposal zawierający:

• cel biznesowy,
• zakres,
• model domenowy,
• scenariusze,
• kontrakty API,
• edge case’y.

Przykład:

# Premium Loyalty Program

## Goal
Introduce loyalty tiers for premium customers.

## Rules
- Customer earns points per order
- Premium threshold: 1000 points
- Discount applies only to eligible categories

## API
POST /loyalty/points
GET /loyalty/status

## Edge Cases
- Refund removes points
- Expired points cannot be reused

To jest gigantyczna różnica względem pojedynczego prompta.

AI dostaje:

• intencję,
• reguły,
• kontrakt,
• granice rozwiązania.

Krok 2 – Explore

Następnie AI eksploruje rozwiązanie.

To etap, w którym:

• analizowana jest architektura,
• sprawdzane są zależności,
• identyfikowane są ryzyka.

To bardzo ważne, bo AI przestaje działać „na ślepo”.

Krok 3 – Apply

Dopiero teraz Codex przechodzi do implementacji.

I to jest moment, w którym naprawdę widać przewagę spec-driven development.

AI nie generuje już „jakiegoś rozwiązania”.

AI implementuje konkretną specyfikację.

To ogromna różnica jakościowa.

Krok 4 – Validate

Na końcu następuje walidacja:

• czy feature spełnia scenariusze,
• czy kontrakty API są poprawne,
• czy edge case’y są obsłużone.

To właśnie tutaj wraca DNA V-Modelu i BDD.

Spec nie kończy się na implementacji.

Spec definiuje również sposób walidacji.

Największa zmiana mentalna

Najciekawsze w całym OpenSpec nie jest samo narzędzie.

Najważniejsza jest zmiana sposobu myślenia.

W klasycznym AI-assisted development często wygląda to tak:

Human → Prompt → AI → Code

W podejściu spec-driven wygląda to bardziej tak:

Human → Spec → Workflow → AI → Validate → Codebase

To zupełnie inny poziom dojrzałości procesu.

Dlaczego to jest ważne?

Bo AI coding assistants są coraz lepsze.

A im lepsze są modele, tym większe znaczenie ma jakość wejścia.

Prompt może wystarczyć do:

• małego taska,
• eksperymentu,
• prototypu.

Ale jeśli chcesz budować:

• większy system,
• zespół AI-assisted developers,
• powtarzalny proces engineeringowy,
• kontrolę jakości i traceability,

to potrzebujesz czegoś więcej.

Potrzebujesz specyfikacji jako centralnego artefaktu procesu.

Podsumowanie

OpenSpec pokazuje bardzo wyraźnie, w jakim kierunku zmierza AI-assisted development.

Nie chodzi już tylko o „pisanie promptów”.

Chodzi o budowanie:

• workflowów,
• skills,
• specyfikacji,
• kontraktów,
• procesów walidacji.

I właśnie dlatego uważam, że:

przyszłość AI programming nie będzie oparta o chat.

Będzie oparta o spec-driven workflows.

A OpenSpec jest dziś jednym z najciekawszych praktycznych przykładów tego kierunku.

{dev} forge – Kto odpowiada za kod generowany przez AI?

AI coding assistants zmieniły sposób, w jaki powstaje software. Kod, który kiedyś był efektem godzin pracy developera, dziś może powstać w kilka minut. Prompt, kilka iteracji i gotowe. Szybkość robi wrażenie. Problem w tym, że wraz z tą zmianą pojawia się pytanie, które wielu zespołów jeszcze nie zadaje wystarczająco głośno:

kto odpowiada za kod generowany przez AI?

To nie jest pytanie filozoficzne. To jest pytanie bardzo praktyczne. Dotyczy jakości, bezpieczeństwa, odpowiedzialności prawnej i – co najważniejsze – odpowiedzialności inżynierskiej.

W świecie, w którym kod powstaje coraz częściej przy udziale modeli językowych, nie możemy pozwolić sobie na brak jasnej odpowiedzi.

Mit: „AI wygenerowało, więc to nie moja odpowiedzialność”

Jednym z najbardziej niebezpiecznych mitów, jakie pojawiły się wraz z popularyzacją AI, jest przekonanie, że skoro kod został wygenerowany przez model, to odpowiedzialność za jego jakość jest „rozmyta”.

To bardzo wygodna narracja. Ale całkowicie nieprawdziwa.

AI nie jest członkiem zespołu. Nie bierze odpowiedzialności. Nie podpisuje się pod commitami w sensie inżynierskim. Nie odpowiada przed klientem, audytem ani produkcją.

AI jest narzędziem. Bardzo zaawansowanym, ale nadal narzędziem.

A odpowiedzialność za efekt użycia narzędzia zawsze pozostaje po stronie człowieka i organizacji.

To nie pierwszy raz w historii

Warto zauważyć, że to nie jest zupełnie nowy problem. Historia software engineeringu zna już podobne momenty.

Kiedy pojawiły się frameworki, biblioteki open source, code generators czy low-code platforms, również pojawiało się pytanie: kto odpowiada za kod, którego nie napisaliśmy w 100% sami?

Odpowiedź zawsze była taka sama:

odpowiada ten, kto decyduje o użyciu i wdrożeniu.

To, że nie napisałeś każdej linijki ręcznie, nie zwalnia Cię z odpowiedzialności za system, który trafia na produkcję.

AI tylko podnosi stawkę, bo zwiększa skalę i tempo generowania kodu.

Problem numer jeden: iluzja poprawności

Jednym z największych zagrożeń przy pracy z AI jest to, że generowany kod wygląda poprawnie.

Ma sensowną strukturę. Kompiluje się. Często przechodzi nawet podstawowe testy. Komentarze brzmią przekonująco. Nazwy są logiczne. Wszystko sprawia wrażenie profesjonalne.

Ale „wygląda poprawnie” to nie to samo, co „jest poprawne”.

Model nie rozumie Twojego systemu w taki sposób, jak robi to doświadczony inżynier. Nie zna wszystkich kontekstów biznesowych. Nie zna ograniczeń infrastrukturalnych. Nie zna kompromisów, które zostały wcześniej podjęte.

W rezultacie może wygenerować rozwiązanie, które:

• łamie reguły domenowe,
• narusza założenia architektury,
• wprowadza subtelne błędy logiczne,
• nie spełnia wymagań niefunkcjonalnych,
• jest podatne na problemy bezpieczeństwa.

I to wszystko bez żadnego ostrzeżenia.

Problem numer dwa: brak świadomości decyzji

Kiedy developer pisze kod ręcznie, podejmuje serię mikrodecyzji. Każda linijka ma swoje uzasadnienie. Każda konstrukcja wynika z jakiejś intencji.

W przypadku kodu generowanego przez AI część tych decyzji jest ukryta. Model generuje rozwiązanie, ale nie zawsze jasno komunikuje, dlaczego wybrał właśnie takie podejście.

To prowadzi do bardzo niebezpiecznej sytuacji:

zespół zaczyna utrzymywać kod, którego w pełni nie rozumie.

A utrzymywanie kodu bez zrozumienia to prosta droga do problemów.

Problem numer trzy: odpowiedzialność rozproszona

W klasycznym modelu developmentu odpowiedzialność jest względnie jasna. Wiemy, kto implementował feature, kto go reviewował, kto zatwierdził wdrożenie.

W modelu opartym o AI bardzo łatwo tę odpowiedzialność rozmyć:

• „AI to wygenerowało”
• „to było tylko sugestią”
• „nie zmieniałem tego, bo wyglądało dobrze”

Jeśli zespół nie zdefiniuje jasno zasad pracy z AI, bardzo szybko może dojść do sytuacji, w której nikt nie czuje się właścicielem kodu.

A brak właściciela to brak jakości.

Jak powinna wyglądać odpowiedzialność w erze AI?

Moim zdaniem odpowiedź jest prostsza, niż się wydaje:

odpowiedzialność się nie zmienia. Zmieniają się narzędzia.

To nadal:

• developer odpowiada za kod, który commitował,
• reviewer odpowiada za code review,
• architekt odpowiada za spójność systemu,
• organizacja odpowiada za to, co trafia na produkcję.

AI nie znosi tych ról. Ono tylko zmienia sposób, w jaki wykonujemy pracę.

Nowa kompetencja: AI Code Review

Wraz z AI pojawia się nowa, bardzo ważna kompetencja: umiejętność reviewowania kodu generowanego przez model.

To nie jest dokładnie to samo, co klasyczny code review. Trzeba nauczyć się patrzeć na kod trochę inaczej.

Na co zwracać uwagę?

• Czy rozwiązanie jest zgodne z architekturą systemu?
• Czy nie wprowadza ukrytych założeń?
• Czy obsługuje edge case’y?
• Czy nie „overengineeruje” problemu?
• Czy nie pomija ważnych aspektów (np. bezpieczeństwa, walidacji, logowania)?

AI potrafi być bardzo przekonujące. Dlatego review musi być jeszcze bardziej świadome.

Rola Spec-Driven Development

I tutaj wracamy do jednego z głównych tematów tej serii.

Jeśli chcemy realnie zarządzać odpowiedzialnością za kod generowany przez AI, potrzebujemy stabilnego punktu odniesienia. Czegoś, co pozwala jasno powiedzieć:

„to jest poprawne, a to nie”.

Właśnie tę rolę pełni specyfikacja.

W podejściu spec-driven:

• AI nie „zgaduje” rozwiązania, tylko realizuje spec,
• kod można walidować względem scenariuszy i kontraktów,
• odpowiedzialność jest powiązana z artefaktami, a nie rozmową,
• łatwiej przeprowadzić audyt i analizę decyzji.

To nie eliminuje potrzeby myślenia. Ale znacząco zmniejsza ryzyko chaosu.

Najważniejsza zasada

Jeśli miałbym sprowadzić cały temat do jednej zasady, brzmiałaby ona tak:

Jeśli wrzucasz kod na produkcję, bierzesz za niego odpowiedzialność – niezależnie od tego, czy napisałeś go sam, czy wygenerowało go AI.

To podejście jest brutalnie proste. Ale właśnie dlatego działa.

Podsumowanie

AI zmienia sposób, w jaki tworzymy software. Przyspiesza development, obniża barierę wejścia i pozwala realizować pomysły szybciej niż kiedykolwiek wcześniej.

Ale nie zmienia jednego:

odpowiedzialności za system.

Nie możemy traktować AI jako wymówki. Nie możemy zrzucać na nie decyzji. Nie możemy zakładać, że skoro coś zostało wygenerowane, to jest automatycznie poprawne.

W erze AI dobry inżynier to nie ten, kto pisze najwięcej kodu. To ten, kto potrafi ocenić, który kod powinien istnieć.

A do tego potrzebujemy nie tylko promptów, ale przede wszystkim dobrze zbudowanych specyfikacji.

{dev} forge – Spec vs Prompt: dlaczego promptowanie nie skaluje się w projektach

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.