SDD w praktyce: Testuję 3 podejścia do Spec-Driven Development na tym samym zadaniu
Podobają Ci się takie praktyczne porady?
Zapisz się do mojego newslettera, aby otrzymywać więcej praktycznych wskazówek, najnowszych trendów i sprawdzonych rozwiązań prosto do swojej skrzynki!
Każdy kto pracuje z AI przy tworzeniu kodu w końcu trafia na ten sam problem. Dajesz agentowi zadanie, agent coś generuje, a po godzinie okazuje się że zbudował coś zupełnie innego niż planowałeś. Nie dlatego że AI jest złe. Dlatego że nie miało wystarczającego kontraktu.
Spec-Driven Development to odpowiedź na ten problem. Zamiast rzucać agentowi prompt i liczyć na najlepsze, najpierw piszesz dokładną specyfikację, co ma powstać, jak ma działać i w jakich ramach technicznych. Dopiero z gotowym kontraktem AI siada do kodowania.
W tym artykule testuję trzy różne podejścia do SDD na tym samym zadaniu: landing page dla mojego biznesu z warsztatami AI pod adresem standev.it/ai-workshop. Mój autorski workflow, Spec Kit od Microsoftu i OpenSpec. Każde podejście ma inne założenia, inne możliwości i inne ograniczenia. Zobaczmy co wychodzi w praktyce.
Czym jest Spec-Driven Development i dlaczego warto
Dobra specyfikacja powinna zawierać cztery elementy: cel zadania, wymagania funkcjonalne, ograniczenia techniczne i kontekst architektury. Bez tych czterech rzeczy AI nie ma kontraktu, ma tylko luźne wytyczne.
Kiedy AI ma kontrakt, nie zgaduje. Nie improwizuje. Wykonuje jasne instrukcje jak kontraktor według projektu budowlanego. Różnica w jakości outputu jest nieporównywalna z chaotycznym promptowaniem.
Podejście pierwsze: mój autorski SDD workflow
Mój workflow składa się z sześciu kroków. Wszystko zaczyna się od pliku raw-task, gdzie wklejasz surowy opis zadania. Bez żadnej instalacji, bez konfiguracji. Kopiujesz jeden folder .claude do projektu i działasz od pierwszej minuty.
Po raw-task przychodzi czas na specyfikację, spec-review, plan, implementację, code review i plik done. Każdy krok inicjujesz świadomie przez slash komendę. To Ty decydujesz kiedy przechodzisz dalej, nie narzędzie.
Spec-review to jedyny blokujący etap w tej trójce. AI nie przechodzi dalej dopóki specyfikacja nie jest kompletna. Albo dostaje PASS i idziesz dalej, albo FAIL i wracasz do poprawek.
Każde zadanie dostaje własny folder z numerowanymi plikami (st-47/ dla taska o id ST-47). Dzięki temu możesz w każdej chwili wrócić do dowolnego taska bez ładowania całego kontekstu projektu. Nie przepalasz tokenów, nie tracisz czasu na odtwarzanie stanu.
Na końcu masz plik done, czyli delivery manifest. Czarno na białym: wszystkie zmiany, zaimplementowane serwisy, komponenty, odchylenia od planu. Tester wie co sprawdzać. Ty wiesz co zostało dostarczone.
Podejście drugie: Spec Kit od Microsoftu
Spec Kit to framework stworzony przez Microsoft, który promuje podejście spec-driven development oparte na generowaniu szczegółowych specyfikacji przed kodowaniem. Instalujesz go przez npm, inicjalizujesz w projekcie i korzystasz z zestawu sześciu komend: constitution, specify, clarify, plan, tasks i implement.
Po instalacji pojawia się folder .specify, który jest sercem całego frameworka. Lądują tam wszystkie artefakty generowane w trakcie pracy: specyfikacja, plan techniczny, taski, checklist. Spec Kit automatycznie generuje też CLAUDE.md, plik kontekstowy dzięki któremu agent wie z jakim projektem ma do czynienia od pierwszego uruchomienia.
Kluczowa architektoniczna różnica versus mój SDD: Spec Kit używa mechanizmu skills zamiast slash komend. Skills to reużywalne instrukcje, które Claude ma dostępne w kontekście bez wpisywania czegokolwiek. To inna filozofia pracy.
Co Spec Kit robi dobrze
Generuje bardzo szczegółowy output: requirements, spec, plan, research, data model. Dużo struktury i granularności na każdym etapie. Dobry punkt startowy dla tych którzy dopiero zaczynają z SDD.
Czego Spec Kit nie ma
Brak blokującego review specyfikacji przed planem. Brak code review. Brak dokumentacji na końcu. Osobny branch do mergowania po każdej implementacji.
Podejście trzecie: OpenSpec
OpenSpec to lekki framework który działa z ponad 20 różnymi agentami AI. Repozytorium na GitHubie ma już prawie 50 tysięcy gwiazdek. Instalacja przez npm, inicjalizacja jedną komendą, cztery skille dodane do folderu .claude.
Cały workflow OpenSpec sprowadza się do trzech kroków. Zaczynasz od /opsx:propose gdzie wklejasz opis zadania. OpenSpec generuje od razu cztery artefakty naraz: proposal.md, specs/ z wymaganiami funkcjonalnymi, design.md z decyzjami technicznymi i tasks.md z listą zadań. Potem /opsx:apply który implementuje wszystkie zadania z listy. Na końcu archiwizacja.
OpenSpec jest najszybszy z tej trójki jeśli chodzi o drogę od pomysłu do kodu. Ta szybkość ma jednak swoją cenę.
W OpenSpec brakuje dwóch rzeczy które w SDD uważam za krytyczne: spec-review i świadomego etapu planowania. Po propose idziesz od razu do implementacji, bez zatrzymania i weryfikacji.
Porównanie na jednym zadaniu: które podejście wygrało?
Wszystkie trzy podejścia testowałem na tym samym zadaniu: landing page standev.it/ai-workshop dla mojego biznesu z warsztatami AI. To samo zadanie, trzy różne workflow, trzy różne outputy.
- OpenSpec: trzy komendy i jesteś w implementacji. Najszybszy. Brak weryfikacji specyfikacji i świadomego planowania.
- Spec Kit: najbardziej szczegółowy output. Dużo plików, dużo struktury. Brak blokującego review, brak code review, brak dokumentacji na końcu.
- Mój SDD: sześć kroków, ale każdy ma konkretny cel. Jedyny blokujący review specyfikacji w tej trójce. Code review po implementacji. Delivery manifest na końcu. Zero instalacji.
Jeśli budujesz coś na produkcję i zależy Ci na tym żeby AI nie zgadywało, SDD wygrywa. Jeśli chcesz szybko prototypować małe zmiany, OpenSpec wystarczy.
Jak Standev.it używa SDD w produkcji
W projekcie standev.it mam folder .claude z podfolderami specs i tasks. Każdy task dostaje własny numerowany folder zgodny z ID z YouTrack (na przykład st-47/). W tym folderze po kolei rosną pliki: od raw-task przez spec i spec-review aż do pliku done.
Taka struktura ma trzy praktyczne zalety. Po pierwsze, zawsze możesz wrócić do dowolnego taska bez odtwarzania kontekstu. Po drugie, plik done jest gotową dokumentacją dla każdej zmiany. Po trzecie, dzięki temu że każdy task ma własny folder, nigdy nie ładujesz większego kontekstu niż musisz. Tokeny idą tam gdzie powinny.
Jeśli chcesz pobrać gotowy workflow i użyć go w swoim projekcie, całe repozytorium jest dostępne na GitHubie. Link znajdziesz w opisie odcinka wideo, a jeśli wolisz pisemny przewodnik, sprawdź standev.it.
Podsumowanie: które podejście wybrać?
Wybór podejścia do SDD powinien zależeć od tego co budujesz i na jakim etapie jesteś. Prototyp na szybko? OpenSpec wystarczy. Nowy projekt, dużo niewiadomych, zależy Ci na jakości? Spec Kit da Ci dużo struktury. Projekt produkcyjny, praca w zespole lub solo na dłuższą metę? Mój SDD ma blokujący spec-review, code review i delivery manifest, czyli trzy rzeczy których tamte dwa nie mają.
Jedno jest pewne w każdym z tych podejść: AI pracuje lepiej z kontraktem niż bez niego. Specyfikacja przed kodem to nie overhead. To inwestycja która zwraca się przy każdym kolejnym promcie.
Zapisz się na newsletter na standev.it i pobierz mój SDD workflow za darmo. Dostaniesz gotowy folder .claude z komendami, szablony plików i instrukcję jak wdrożyć to w swoim projekcie od zera.
Cały proces testuję na żywym zadaniu i pokazuję krok po kroku w tym odcinku na YouTube — jeśli wolisz zobaczyć to w akcji zamiast czytać, zacznij od tam.
📚 Chcesz więcej takich artykułów?
Ten artykuł to tylko początek! W moim newsletterze dzielę się głębszymi analizami, praktycznymi case studies oraz ekskluzywnyimi materiałami, które pomogą Ci rozwijać się jako programista.
Podziel się artykułem
Pomóż innym programistom znaleźć te treści
.jpg)
.png)
