W świecie wytwarzania oprogramowania co jakiś czas pojawiają się pojęcia, które brzmią jak kolejna moda. Najpierw „Agile”, potem „Shift Left”, później „Platform Engineering”, a dziś coraz częściej przewija się Spec-Driven Development. Na pierwszy rzut oka można pomyśleć, że to po prostu nowe opakowanie dla starych praktyk. I trochę tak jest. Ale tylko trochę.
Moim zdaniem Spec-Driven Development to nowoczesny, AI-powered potomek V-Modelu, mocno wzbogacony o BDD i Specification by Example. Gdybym miał ująć to jeszcze prościej, powiedziałbym tak:
- dziadek: V-Model,
- najbliższy kuzyn: BDD / Specification by Example,
- współczesna forma: Spec-Driven Development wspierane przez AI.
I właśnie z tej perspektywy warto o tym podejściu rozmawiać. Nie jako o rewolucji znikąd, ale jako o logicznej ewolucji sposobu, w jaki próbujemy zamieniać potrzeby biznesowe na działające oprogramowanie.
Skąd w ogóle bierze się potrzeba Spec-Driven Development?
Od lat branża zmaga się z tym samym problemem: co dokładnie mamy zbudować? Nie jak to zakodować. Nie w jakim frameworku. Nie czy lepszy będzie monolit czy mikroserwisy. Najpierw trzeba odpowiedzieć na dużo bardziej podstawowe pytanie: jaki problem rozwiązujemy i po czym poznamy, że rozwiązanie jest poprawne?
Przez długi czas odpowiedzią były rozbudowane dokumenty analityczne, opisy wymagań, makiety, modele procesów i grube specyfikacje funkcjonalne. Problem polegał na tym, że dokumentacja bardzo często żyła własnym życiem. Była tworzona na początku projektu, a potem kod zaczynał iść w swoją stronę.
Z drugiej strony pojawił się świat zwinny, który słusznie zwrócił uwagę, że dokumentacja bez wartości wykonawczej niewiele daje. Tyle że w wielu zespołach skręcono za mocno w przeciwną stronę. Zaczęło dominować podejście typu: „dogadamy się na daily”, „doprecyzujemy w trakcie”, „zobaczymy w refinement”. I nagle okazało się, że brak precyzyjnej specyfikacji wcale nie oznacza większej zwinności. Często oznacza po prostu chaos.
Spec-Driven Development wyrasta właśnie z tej frustracji. Z potrzeby odzyskania specyfikacji, ale w formie, która nie jest martwym dokumentem. Ma być żywa, operacyjna, testowalna i coraz częściej także czytelna dla modeli AI.
Dziadek, czyli V-Model
Jeżeli szukać przodka tego podejścia, to dla mnie jest nim V-Model. To stary, momentami niedoceniany model, który miał jedną wielką zaletę: traktował specyfikację i walidację bardzo serio.
W V-Modelu każdemu poziomowi analizy i projektowania odpowiadał poziom weryfikacji. Wymagania biznesowe miały swoje testy akceptacyjne. Wymagania systemowe miały testy systemowe. Projekt techniczny miał testy integracyjne i jednostkowe. Była w tym pewna elegancja. Logika była prosta: jeśli coś definiujesz, to musisz też wiedzieć, jak sprawdzisz, że zostało dobrze zrealizowane.
To jest właśnie fundament, który wraca dziś pod nową nazwą. Spec-Driven Development odziedziczyło po V-Modelu kilka bardzo ważnych cech:
- szacunek do specyfikacji,
- powiązanie wymagań z walidacją,
- myślenie o traceability,
- założenie, że implementacja nie powinna być oderwana od intencji biznesowej.
Oczywiście współczesne projekty nie chcą wracać do ciężkiego, liniowego procesu, w którym pół roku piszemy dokumenty, a potem drugie pół roku kod. I słusznie. Ale warto zauważyć, że sam rdzeń V-Modelu – czyli relacja między specyfikacją a testowaniem – był bardzo zdrowy.
Kuzyn, czyli BDD i Specification by Example
Potem przyszły praktyki, które zaczęły tłumaczyć wymagania na bardziej praktyczny język. Tutaj pojawiają się BDD oraz Specification by Example. I właśnie one są dla Spec-Driven Development najbliższą rodziną.
BDD nauczyło zespoły, że zachowanie systemu można opisywać w sposób zrozumiały nie tylko dla programistów, ale też dla biznesu i testerów. Scenariusze w stylu Given / When / Then nie były już tylko notatką. Stawały się kontraktem. Czymś, co da się zautomatyzować, sprawdzić i utrzymać.
Specification by Example poszło jeszcze dalej. Zamiast pisać abstrakcyjne wymagania, zaczęliśmy opierać się na konkretnych przykładach. Nie „system powinien poprawnie liczyć rabaty”, tylko: „dla klienta premium z koszykiem powyżej 500 zł rabat powinien wynieść 10%”. Nagle wymagania przestały być mgłą. Stały się czymś namacalnym.
To właśnie dlatego uważam, że BDD i Specification by Example są najbliższymi kuzynami Spec-Driven Development. Bo wprowadziły trzy rzeczy, bez których SDD nie miałoby sensu:
- operacyjny język opisu wymagań,
- przykłady jako nośnik wiedzy domenowej,
- bezpośrednie połączenie specyfikacji z testami.
Co zmieniło się dziś? Pojawienie się AI
No dobrze, skoro tyle rzeczy już było, to po co nowa nazwa? Bo pojawił się nowy czynnik, który zmienia stawkę gry: AI.
Jeszcze kilka lat temu specyfikacja była głównie artefaktem dla ludzi. Analityk pisał ją dla biznesu, architekta, programisty i testera. Dziś dochodzi nowy uczestnik procesu: model językowy, agent kodujący albo zestaw narzędzi wspierających development. I nagle okazuje się, że jakość specyfikacji zaczyna mieć wpływ nie tylko na komunikację w zespole, ale też na jakość generowanego kodu, testów, dokumentacji czy propozycji architektury.
To jest moment, w którym spec staje się interfejsem. Nie tylko między biznesem a IT, ale również między człowiekiem a AI.
Jeżeli specyfikacja jest niejasna, sprzeczna albo zbyt ogólna, to AI zrobi dokładnie to, co zwykle robi człowiek pod presją czasu: zgadnie. Czasem dobrze, czasem źle, ale niemal zawsze z dużą pewnością siebie. A to oznacza, że w erze AI dobrze napisana specyfikacja przestaje być „miłym dodatkiem”. Staje się narzędziem sterowania wytwarzaniem.
Czym więc jest Spec-Driven Development?
Spec-Driven Development to podejście, w którym specyfikacja nie jest dokumentem archiwalnym, ale centralnym artefaktem sterującym projektowaniem, implementacją, testami i coraz częściej także pracą AI.
W praktyce oznacza to, że zanim powstanie kod, próbujemy zbudować możliwie precyzyjny opis:
- jaki problem rozwiązujemy,
- jakie są reguły biznesowe,
- jakie zachowania są oczekiwane,
- jakie scenariusze muszą przejść,
- jakie ograniczenia architektoniczne obowiązują,
- oraz po czym rozpoznamy, że rozwiązanie jest gotowe.
Spec może przyjmować różne formy. To może być zestaw user stories, scenariuszy BDD, ADR-ów, opisów API, kontraktów danych, reguł domenowych, diagramów czy nawet checklist jakościowych. Ważne jest nie tyle medium, ile rola, jaką ten artefakt pełni.
W Spec-Driven Development specyfikacja:
- prowadzi implementację,
- ogranicza pole domysłów,
- umożliwia automatyzację testów,
- wspiera traceability,
- i może być bezpośrednim wejściem dla narzędzi AI.
Dlaczego nie wystarczy samo „promptowanie” AI?
Tu dochodzimy do bardzo praktycznego problemu. Wiele zespołów zachwyca się dziś tym, że można „po prostu opisać funkcję” agentowi kodującemu i dostać działający wynik. I jasne – to działa. Zwłaszcza dla małych, izolowanych zadań. Problem pojawia się później.
Bez uporządkowanej specyfikacji zaczynają się klasyczne kłopoty:
- sprzeczne decyzje między modułami,
- różne interpretacje tych samych wymagań,
- brak spójności między kodem, testami i dokumentacją,
- trudność w ocenie, czy feature faktycznie jest gotowy,
- chaos w kolejnych iteracjach rozwoju.
AI potrafi bardzo przyspieszyć produkcję, ale nie rozwiązuje magicznie problemu niejednoznaczności. Wręcz przeciwnie – potrafi go zwielokrotnić, bo błędne założenia można teraz wdrażać szybciej niż kiedykolwiek wcześniej.
Dlatego uważam, że Spec-Driven Development jest naturalną odpowiedzią na epokę AI-assisted development. To nie jest hamulec dla szybkości. To układ kierowniczy.
Jakie elementy najczęściej tworzą podejście spec-driven?
Choć nie ma jednego, kanonicznego standardu, to w praktyce ten styl pracy zwykle opiera się na kilku warstwach.
1. Kontekst biznesowy
Zaczynamy od odpowiedzi na pytanie: po co to robimy? Jakie pain pointy rozwiązujemy? Jakie KPI lub cele biznesowe za tym stoją? Bez tego nawet najlepsza specyfikacja funkcjonalna może prowadzić do świetnie wykonanego, ale niepotrzebnego rozwiązania.
2. Specyfikacja zachowań
Tutaj pojawiają się user stories, przykłady, scenariusze BDD, kryteria akceptacji i reguły biznesowe. To ta część, która mówi, jak system powinien się zachowywać z perspektywy użytkownika i domeny.
3. Ograniczenia projektowe i architektoniczne
To miejsce na decyzje techniczne, ADR-y, zasady integracji, kontrakty API, standardy bezpieczeństwa, wydajności i obserwowalności. Innymi słowy: nie tylko co ma działać, ale też w jakich ramach ma działać.
4. Walidacja
Spec bez walidacji jest tylko ambitną deklaracją. Dlatego potrzebne są testy, checklisty, scenariusze automatyczne i mechanizmy traceability. To właśnie tu wraca DNA V-Modelu.
5. Wykorzystanie AI jako wykonawcy lub współautora
W nowoczesnym wydaniu specyfikacja może być wejściem dla modeli generujących kod, testy, dokumentację, diagramy czy nawet migracje. Ale jakość efektu zależy od jakości specyfikacji. Garbage in, garbage out – tylko szybciej.
Największa różnica względem starego podejścia do dokumentacji
W tradycyjnych projektach dokumentacja często była produktem ubocznym procesu. W Spec-Driven Development dokumentacja-specyfikacja staje się aktywnym elementem delivery.
To subtelna, ale ogromna zmiana. Nie piszemy specyfikacji „bo governance wymaga”. Piszemy ją po to, by:
- lepiej myśleć o problemie,
- uzgodnić znaczenie pojęć,
- zmniejszyć ryzyko złej interpretacji,
- móc automatyzować walidację,
- i skuteczniej współpracować z AI.
To dlatego dobrze zrobione SDD nie przypomina ciężkiej analizy sprzed dekad. Bardziej przypomina zestaw połączonych artefaktów, które razem prowadzą zespół od intencji biznesowej do gotowego rozwiązania.
Dlaczego teraz ten temat wraca z taką siłą?
Bo dojrzały trzy światy naraz.
Po pierwsze, dojrzał świat domenowy. Firmy lepiej rozumieją dziś, że przewaga nie leży tylko w kodzie, ale w poprawnym odwzorowaniu procesów, reguł i wyjątków.
Po drugie, dojrzał świat automatyzacji jakości. Testy automatyczne, kontrakty API, pipeline’y CI/CD, quality gates – to wszystko sprawiło, że specyfikację można realnie powiązać z wykonaniem.
Po trzecie, dojrzał świat AI. A wraz z nim pojawiła się ogromna potrzeba tworzenia artefaktów, które są jednoznaczne, modularne i nadają się do użycia przez ludzi oraz modele.
Właśnie na przecięciu tych trzech światów rodzi się dzisiejsze zainteresowanie Spec-Driven Development.
Moja robocza definicja
Na potrzeby tego cyklu przyjąłbym taką roboczą definicję:
Spec-Driven Development to podejście do tworzenia oprogramowania, w którym centralną rolę pełni specyfikacja opisująca zachowanie, reguły i ograniczenia systemu, a sama specyfikacja służy jako podstawa do projektowania, implementacji, testów i współpracy z AI.
Ta definicja jest szeroka, ale celowo. Nie chcę zamykać tematu w jednym frameworku czy modnej etykiecie. Bardziej interesuje mnie praktyczny kierunek: jak tworzyć specyfikacje, które naprawdę pomagają dowozić systemy lepiej, szybciej i bardziej przewidywalnie.
Czego można spodziewać się w dalszej części cyklu?
To dopiero pierwszy artykuł z cyklu {dev} forge - How software is forged with AI, więc na razie ustawiamy scenę. W kolejnych wpisach warto będzie wejść głębiej w tematy takie jak:
- jak wygląda dobra specyfikacja dla AI-powered development,
- jak łączyć SDD z BDD, ADR-ami i dokumentacją architektoniczną,
- gdzie kończy się specyfikacja biznesowa, a zaczyna techniczna,
- jak utrzymywać spójność między specem, kodem i testami,
- oraz jakich błędów unikać, żeby nie stworzyć nowej wersji „martwej dokumentacji”.
Podsumowanie
Spec-Driven Development nie wzięło się znikąd. To nie jest przypadkowy buzzword wykreowany tylko dlatego, że pojawiły się modele generatywne. To raczej kolejny etap dojrzewania branży.
Z jednej strony odziedziczyliśmy po V-Modelu szacunek do relacji między wymaganiem a weryfikacją. Z drugiej strony BDD i Specification by Example nauczyły nas, że wymagania trzeba opisywać poprzez zachowania i konkretne przykłady. Dziś dokładamy do tego AI, które potrafi działać jako współtwórca rozwiązania – pod warunkiem, że dostanie sensowną, spójną i operacyjną specyfikację.
I właśnie dlatego uważam, że Spec-Driven Development to nowoczesny, AI-powered potomek V-Modelu, mocno wzbogacony o BDD i Specification by Example.
Brzmi jak rodzinne spotkanie metodyk? Trochę tak. Ale tym razem z całkiem praktycznym efektem: lepszym mostem między intencją, implementacją i jakością.
