Spec-Driven Development kontra Vibe Coding: Waterfall?

Specyfikacje jako źródło prawdy, czy wolna ceremonia?

Page content

Spec-Driven Development weszło w 2026 rok jako poważna odpowiedź deweloperów na dryf związany z vibe codingiem.

Argument jest prosty: agenci AI produkują lepsze i bardziej spójne wyniki, gdy implementują je zgodnie z recenzowaną specyfikacją, a nie z ad-hocowym promptem. Teoretycznie trudno się z tym spierać.

W praktyce Hacker News nazwał to „Waterfall Strikes Back” (Wodospad atakuje ponownie).

Obie strony mają rację.

Spec-Driven Development versus Vibe Coding

Przypadek na rzecz SDD w świecie Vibe Codingu

Vibe coding – praktyka pisania luźnego promptu i iterowania nad tym, co produkuje agent AI – działa wyjątkowo dobrze w przypadku małych, eksploracyjnych i jednorazowych zadań. Przez pierwsze sześć miesięcy 2025 roku był to dominujący wzorzec kodowania z wykorzystaniem AI. Deweloperzy dostarczali skrypty, prototypy i proste narzędzia szybciej niż kiedykolwiek wcześniej.

Następnie projekty urosły. Wiele plików zaczęło dryfować. Ograniczenia ustanowione w pierwszej sesji były zapominane w trzeciej. Założenia bezpieczeństwa były odrzucane. Decyzje architektoniczne zmieniały się w trakcie tworzenia funkcji, ponieważ agent nie miał trwałej pamięci o intencjach.

Spec-Driven Development (SDD) pojawił się jako dyscyplinowana odpowiedź. Główna teza: zrób ze specyfikacji centralny artefakt, a nie prompt. Najpierw napisz wymagania, projekt i plan zadań. Pozwól agentowi implementować te artefakty po jednym fragmencie na raz. Trzymaj specyfikację wersjonowaną i zaktualizowaną.

Narzędzia takie jak GitHub Spec Kit, Kiro, przepływy pracy Claude Code SDD oraz BMAD, a także inne szafotowania społecznościowe, są implementacjami tego pomysłu. Narzędzia są realne. Interes jest realny. Odbicie jest również realne.

W czym Vibe Coding jest dobry

Przed odrzuceniem vibe codingu warto precyzyjnie określić, w czym jest dobry.

Prototypy eksploracyjne. Kiedy nie jesteś pewien, co chcesz zbudować, najszybszą ścieżką jest zbudowanie czegoś surowego i zareagowanie na to. SDD wymaga wiedzy, co należy zdefiniować. Jeśli jeszcze tego nie wiesz, specyfikacje są przedwczesne.

Eksperymenty z UI. Układ wizualny i wrażenia z interakcji są trudne do określenia z wyprzedzeniem. Vibe coding pozwala szybko zobaczyć opcje, odrzucić większość z nich i zbiec się do czegoś, co naprawdę dobrze się prezentuje. Dokument wymagań nie pomoże Ci tutaj.

Jednorazowa automatyzacja. Skrypty jednorazowe, zadania ekstrakcji danych, pomocniki migracji – te rzadko wymagają dokumentu projektowego. Koszt lekkiego błędu jest niski. Koszt wolnego, ceremonialnego procesu jest realny.

Szybki feedback. Kiedy musisz szybko coś się nauczyć – czy to API działa tak, jak myślisz? – vibe coding skracą pętlę uczenia do minut. SDD zwolniłoby ten proces bez żadnej korzyści.

Błędem jest przenoszenie wzorców sukcesu z tych kontekstów i stosowanie ich do funkcji produkcyjnych z realnymi ograniczeniami, realnymi użytkownikami i realnymi konsekwencjami popełnienia błędu.

Gdzie Vibe Coding się zawodzi

Vibe coding degraduje się przewidywalnie wraz ze wzrostem zakresu i stawek.

Zmiany w wielu plikach. Gdy funkcja dotyka pięciu lub więcej plików, okno kontekstowe agenta zaczyna tracić ślad inwariantów. Bez dokumentu projektowego każdy prompt musi ponownie ustanowić kontekst, który został ustanowiony i zapomniany w poprzedniej sesji.

Dryf architektoniczny. Bez wyraźnych nie-celi, agenty implementują rzeczy. Agent dodaje warstwę cache’u, ponieważ wydaje się to rozsądne. Trzy sesje później, założenie dotyczące cache’a jest wbudowane w model danych, a jego usunięcie jest kosztowne.

Zapomniane ograniczenia. „Tylko uwierzytelnieni użytkownicy mogą to uruchomić” to zdanie w dokumencie wymagań. W sesji vibe codingu jest to coś, co wspomniano raz w pierwszej sesji, a agent nie pamięta tego w czwartej sesji, gdy pisze nowy endpoint.

Ukryte założenia bezpieczeństwa. Reguły autoryzacji, granice walidacji danych wejściowych, obsługa sekretów – to dokładnie te rodzaje implikitywnych wymagań, które są pomijane, gdy agent optymalizuje kod pod kątem prawdopodobnie działającego, a nie poprawnego i ograniczonego kodu.

Przekazanie zespołowe. Jeśli zbudowałeś to przez iteracyjne promptowanie, artefaktem, który rejestruje, co zostało zdecydowane i dlaczego, jest… log git. Powodzenia z tym.

Co zmienia Spec-Driven Development

SDD nie twierdzi, że eliminuje iterację. Dobre wersje SDD są wyraźnie iteracyjne. Zmieniają one miejsce, w którym zachodzi iteracja. Pełną definicję – w tym jak SDD różni się od TDD, BDD i metod formalnych – zobacz w Czym jest Spec-Driven Development?

Zamiast iterować nad kodem i wnioskować intencje z diffów, iterujesz nad specyfikacją, a następnie implementujesz. Specyfikacja staje się artefaktem, który rejestruje, co zostało postanowione, dlaczego i co jest poza zakresem – pełniącego podobną funkcję jak Rejestry Decyzji Architektonicznych ale zorientowanego wokół intencji funkcji, a nie wyborów na poziomie systemu. Kod implementuje tę intencję.

SDD przechodzi przez pięć faz – specyfikacja, planowanie, zadania, implementacja, walidacja – z bramą recenzji człowieka w każdym kroku. Zobacz Przepływ Pracy Spec-Driven Development Od Wymagań do Kodu w celu uzyskania pełnego procesu, szablonów i punktów kontrolnych. Agent uczestniczy w większości faz, ale ludzie recenzują artefakty przed rozpoczęciem implementacji. Ten krok recenzji jest główną różnicą między SDD a vibe codingiem.

Dlaczego deweloperzy nazywają to Waterfallem

Krytyka wodospadowa nie jest błędna. Jest po prostu skierowana na złe SDD, a nie samo SDD.

Konkretym trybem awarii jest długie planowanie wstępne. Definiczną cechą Waterfalla jest pętla zwrotna rozciągająca się do tygodni lub miesięcy: faza wymagań, faza projektowania, faza budowania, faza testowania, wysyłka. Feedback przychodzi późno. Kiedy odkryjesz, że założenie projektowe było błędne, spędziłeś już na nim tygodnie budowania.

Gdy deweloper używa Spec Kit i generuje listę zadań o długości 200 linii przed napisaniem jednej linii kodu, a następnie spędza dwa dni na szlifowaniu dokumentu wymagań, zanim agent dotknie cokolwiek, to jest Waterfall. To Waterfall z markdownem zamiast UML, ale tryb awarii jest identyczny.

Jeden komentator na HN opisał użycie Spec Kit do małego narzędzia CLI i stwierdził, że jest to „za wolne, za dużo dostosowywania przed zobaczeniem kodu”. To jest zła wersja. Ten użytkownik miał rację, odrzucając ją dla tego zadania.

Pożyteczną krytyką nie jest „specyfikacje są złe”. Jest to „długie planowanie wstępne przed feedbackiem jest złe”. To są różne twierdzenia.

Pożyteczna Środkowa Ziemia

Dobre SDD unika pułapki wodospadowej, utrzymując specyfikację małą i zaczynając implementację wczesnie.

Małe specyfikacje. Dokument wymagań dla pojedynczej funkcji powinien zmieścić się na jednym ekranie. Jeśli specyfikacja ma dziesięć stron, jest to albo projekt platformy, albo musi zostać podzielona na mniejsze funkcje. Specyfikacje, które są zbyt duże, zajmują zbyt dużo czasu do recenzji i szybko stają się przestarzałe.

Krótkie fragmenty zadań. Każde zadanie powinno być implementowalne w pojedynczej sesji agenta, recenzowalne jako mały diff i testowalne w izolacji. Jeśli zadania są zbyt duże, pętla implementacji się rozciąga, a mapowanie specyfikacji do kodu staje się trudne do zweryfikowania.

Wczesna implementacja. Zspezifikuj pierwsze zadanie, zaimplementuj je, zwaliduj je, a następnie przejdź do następnego zadania. Nie specyfikuj wszystkiego przed implementowaniem cokolwiek. Pierwsza implementacja ujawni rzeczy, których Twoja specyfikacja zrobiła źle. Zaktualizuj specyfikację przed kontynuowaniem.

Żywa specyfikacja. Gdy rzeczywistość różni się od projektu – a będzie się różnić – zaktualizuj specyfikację, a nie tylko kod. Specyfikacja jest przydatna tylko wtedy, gdy odzwierciedla to, co zostało faktycznie zbudowane.

Testy jako wykonywalny feedback. Każde kryterium akceptacji powinno mapować się co najmniej na jeden test. Zestaw testów jest maszynowo czytelną wersją specyfikacji. Jeśli specyfikacja mówi „tylko uwierzytelnieni użytkownicy mogą to uruchomić”, powinien istnieć test, który weryfikuje, że nieautoryzowane żądania są odrzucane.

Ten hybrydowy – małe specyfikacje, krótkie zadania, wczesna implementacja, żywe dokumenty – to to, co naprawdę działa. To nie jest vibe coding i to nie jest Waterfall. To kontrolowana iteracja z trwałymi artefaktami.

Kiedy SDD pokonuje Vibe Coding

Używaj SDD – nawet lekkiego SDD – kiedy koszt popełnienia błędu jest realny.

Ryzykowa logika biznesowa. Fakturowanie, uprawnienia, migracje danych, idempotencja – jakakolwiek logika, w której niepoprawne zachowanie jest kosztowne lub trudne do cofnięcia. Vibe coding pozostawia te rodzaje wymagań implikitywnych. SDD czyni je jawnymi i recenzowalnymi przed implementacją.

Zmiany w API produkcyjnym. Każda zmanta w kontrakcie API publicznego lub wewnętrznego powinna mieć dokument projektowy. Dokument projektowy jest tym, co recenzujesz przed tym, jak agent napisze kod, który zepsuje wywołujących.

Przepływy pracy wieloagentowe. Gdy wielu agentów implementuje różne części funkcji, specyfikacja jest wspólnym źródłem prawdy. Bez tego każdy agent optymalizuje lokalnie, a fragmenty mogą nie pasować do siebie.

Przekazanie zespołowe. Jeśli inny deweloper lub inny agent będzie kontynuował tę pracę, specyfikacja jest artefaktem przekazywania. Log git i README nie wystarczą.

Znaczące refaktoryzacje. Refaktoryzacje dotykające głównych abstrakcji wymagają wyraźnego stwierdzenia, co musi pozostać takie samo (zachowanie), a co może się zmienić (struktura). Bez tego agent może zepsuć kontrakty, które myślałeś, że są zachowane.

Kiedy Vibe Coding jest nadal lepszy

SDD to narzut. Czasami narzut nie jest wart tego.

Szybkie skrypty. Skrypt 50-linijkowy do zmiany nazw plików lub transformacji JSON nie potrzebuje dokumentu wymagań. Napisz prompt, sprawdź wynik, wyślij go.

Eksperymenty. Jeśli uczysz się, czy podejście jest wykonalne – eksplorujesz API, testujesz bibliotekę, weryfikujesz hipotezę – potrzebujesz szybkości, a nie struktury. Eksperymentuj najpierw, specyfikuj, jeśli eksperyment się powiedzie.

Szkice UI. Projekt interakcji korzysta z widzenia, a nie specyfikacji. Zbuduj kilka surowych wariacji szybko, zareaguj na to, co widzisz, i specyfikuj tylko to, co faktycznie zamierzasz wysłać.

Jednorazowa automatyzacja. Skrypty jednorazowe, importy danych, pomocniki migracji – koszt nieco błędnego wyniku jest zwykle niski, a artefakt i tak zostanie usunięty po użyciu.

Prototypy solo. Jeśli jesteś jedyną osobą, która kiedykolwiek zobaczy ten kod, a celem jest nauka, a nie produkcja, vibe coding jest szybszy, a wady są ograniczone.

Prosty Ramowy Decyzyjny

Praktyczne pytanie nie brzmi „SDD czy vibe coding?”. Brzmi „ile specyfikacji potrzebuję dla tego konkretnego zadania?”

Używaj vibe codingu, gdy:

  • Zadanie zajmuje mniej niż dzień
  • Eksplorujesz się lub uczysz
  • Artefakt jest jednorazowy lub niskostawkowy
  • Jesteś jedyną osobą, która dotknie tego
  • Szybkość feedbacku ma większe znaczenie niż poprawność

Używaj lekkiego SDD, gdy:

  • Zadanie zajmuje dwa lub więcej dni
  • Dotknięte są wiele plików
  • Istnieją wyraźne wymagania bezpieczeństwa lub poprawności
  • Inna osoba lub agent będzie kontynuować pracę
  • Musisz napisać testy, które mapują się na wymagania

Używaj pełnego SDD, gdy:

  • Funkcja dotyka interfejsu publicznego lub kontraktu danych
  • Uczestniczy wielu agentów lub członków zespołu
  • Organizacja wymaga recenzji projektu przed implementacją
  • Wymagane są ścieżki compliance’u lub audytowe

Najczęstszym błędem jest stosowanie pełnego SDD do zadań, które potrzebują tylko lekkiego SDD, oraz stosowanie braku specyfikacji w ogóle do zadań, które potrzebują co najmniej lekkiej. Bez względu na to, który poziom wybierzesz, specyfikacja pozostaje przydatna tylko wtedy, gdy coś ciągle sprawdza ją z kodem; Utrzymywanie Specyfikacji, Testów i Kodu w Synchronizacji w Rozwoju AI opisuje kontrole śledzenia, które łapią specyfikację cicho stającą się przestarzałą.

Złe SDD to Waterfall z markdownem. Dobre SDD to kontrolowana iteracja z trwałymi artefaktami. Vibe coding to odpowiednie narzędzie dla odpowiednich zadań – i niewłaściwe narzędzie dla niewłaściwych. Znajomość różnicy jest umiejętnością.

Przydatne Linki

Subskrybuj

Otrzymuj nowe wpisy o systemach, infrastrukturze i inżynierii AI.