Development Spec-Driven vs. Vibe Coding: Model kaskadowy?

Specyfikacje jako źródło prawdy czy powolny rytuał?

Page content

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

Argument jest prosty: agenci AI produkują lepsze, bardziej spójne wyniki, gdy implementują rozwiązania na podstawie przeglądanej specyfikacji, a nie ad-hocowych promptów. Teoretycznie trudno z tym dyskutować.

W praktyce Hacker News nazwał to „Waterfall Strikes Back” (Kaskada się mści).

Obie strony mają rację.

Spec-Driven Development versus Vibe Coding

Przypadek dla SDD w świecie vibe codingu

Vibe coding – praktyka polegająca na napisaniu luźnego promptu i iterowaniu nad tym, co wygeneruje 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. Programiści 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 zostały zapomniane w trzeciej. Założenia dotyczące bezpieczeństwa zostały pominięte. Decyzje architektoniczne zmieniały się w połowie funkcji, ponieważ agent nie miał trwałej pamięci o intencji.

Spec-Driven Development (SDD) pojawił się jako dyscyplinowana odpowiedź. Główna teza: specyfikacja powinna być centralnym artefaktem, a nie promptem. Napisz wymagania, projekt i plan zadań jako pierwsze. Pozwól agentowi implementować na podstawie tych artefaktów, po jednym kroku na raz. Trzymaj specyfikację wersjonowaną i aktualizowaną.

Narzędzia do kodowania z AI – GitHub Spec Kit, Kiro, BMAD oraz rosnąca liczba niestandardowych przepływów pracy Claude Code – to wszystko wdrożenia tej idei. Narzędzia są prawdziwe. Zainteresowanie jest prawdziwe. Odbicie jest również prawdziwe.

W czym vibe coding jest dobry

Zanim odrzucimy vibe coding, warto precyzyjnie określić, w czym on dobrze się sprawdza.

Prototypy eksploracyjne. Gdy nie jesteś pewien, co chcesz zbudować, najszybszą ścieżką jest zbudowanie czegoś niedokładnego i reakcja na to. SDD wymaga wiedzenia, co należy zdefiniować. Jeśli jeszcze nie wiesz, specyfikacje są przedwczesne.

Eksperymenty z UI. Wizualny układ i odczucia 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 faktycznie działa dobrze. 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.

Szybka zwrotna informacja. Gdy potrzebujesz szybko czegoś się nauczyć – czy to API działa tak, jak myślisz? – vibe coding skraca pętlę uczenia do minut. SDD spowolniłoby to 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 błędów.

Gdzie vibe coding się załamuje

Vibe coding degradowany jest przewidywalnie w miarę wzrostu zakresu i stawek.

Zmiany w wielu plikach. Gdy funkcja dotyka pięciu lub więcej plików, okno kontekstowe agentu zaczyna tracić śledzenie 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-celów, agenty implementują rzeczy. Agent dodaje warstwę cache, ponieważ wydaje się to rozsądne. Trzy sesje później, założenie o cache 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 to coś, co wspomniałeś raz w pierwszej sesji, a agent nie pamięta tego w czwartej sesji, gdy pisze nowy endpoint.

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

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

Co zmienia Spec-Driven Development

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

Zamiast iterować na kodzie i wnioskować intencję z diffów, iterujesz na specyfikacji, a następnie implementujesz. Specyfikacja staje się artefaktem, który rejestruje, co zostało decyzja, dlaczego i co jest poza zakresem – pełniąc podobną funkcję jak Rejesty Decyzji Architektonicznych ale zorientowaną wokół intencji funkcji, a nie wyborów na poziomie systemu. Kod implementuje tę intencję.

Typowy przepływ pracy SDD przebiega przez pięć faz:

Specyfikacja. Opis problemu, użytkownicy, cele, nie-cele, kryteria akceptacji, otwarte pytania.

Planowanie. Decyzje architektoniczne, dotknięte moduły, model danych, kontrakty API, obawy dotyczące bezpieczeństwa, strategia testów.

Podział zadań. Małe fragmenty implementacji z wyraźnymi kryteriami walidacji i punktami kontroli przez człowieka.

Implementacja. Po jednym zadaniu na raz, z resetem kontekstu między zadaniami, stosując ograniczenia ze specyfikacji i aktualizując plan, gdy rzeczywistość różni się od projektu.

Walidacja. Testy, lint, kontrole typów, kryteria akceptacji, diff specyfikacji-kodu.

Agent uczestniczy w większości faz – sporządzanie specyfikacji, generowanie projektu, proponowanie zadań – ale ludzie przeglądają artefakty przed rozpoczęciem implementacji. Ten krok przeglądu jest kluczową różnicą między SDD a vibe codingiem.

Dlaczego programiści nazywają to Kaskadą

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

Konkretym trybem awarii jest długie planowanie wsteczne. Definiującą cechą kaskady jest pętla zwrotna, która rozciąga się na tygodnie lub miesiące: faza wymagań, faza projektowania, faza budowy, faza testów, faza wysyłki. Zwrotna informacja przychodzi późno. Gdy odkryjesz, że założenie projektowe było błędne, budowałeś na nim przez tygodnie.

Gdy programista używa Spec Kit i generuje listę zadań na 200 linii przed napisaniem pojedynczej linii kodu, a następnie spędza dwa dni na polowaniu dokumentu wymagań przed tym, jak agent dotknie cokolwiek, to jest kaskada. To jest kaskada z markdownem zamiast UML, ale tryb awarii jest identyczny.

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

Pożyteczna krytyka to nie „specyfikacje są złe”. To „długie planowanie wsteczne przed zwrotną informacją jest złe”. To są różne twierdzenia.

Pożyteczna środek

Dobre SDD unikają pułapki kaskady, trzymając specyfikację małą i zaczynając implementację wczesną.

Małe specyfikacje. Dokument wymagań dla pojedynczej funkcji powinien zmieścić się na jednym ekranie. Jeśli specyfikacja ma dziesięć stron, to albo projekt platformy, albo należy go podzielić na mniejsze funkcje. Duże specyfikacje zajmują zbyt dużo czasu do przeglądu i szybko stają się przestarzałe.

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

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

Żywa specyfikacja. Gdy rzeczywistość różni się od projektu – a tak się stanie – zaktualizuj specyfikację, nie tylko kod. Specyfikacja jest pożyteczna tylko wtedy, gdy odzwierciedla to, co faktycznie zbudowano.

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

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

Kiedy SDD pokonuje vibe coding

Używaj SDD – nawet lekkiego SDD – gdy koszt błędu jest realny.

Ryzykowna logika biznesowa. Rozliczenia, uprawnienia, migracje danych, idempotencja – każda logika, gdzie nieprawidłowe zachowanie jest kosztowne lub trudne do cofnięcia. Vibe coding pozostawia te rodzaje wymagań implikitywnie. SDD czyni je wyraźnymi i przeglądowymi przed implementacją.

Zmiany w produkcyjnym API. Każda zmiana w kontrakcie API publicznym lub wewnętrznym powinna mieć dokument projektowy. Dokument projektowy jest tym, co przeglądasz przed tym, jak agent napisze kod, który psuje wywołania.

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

Przekazanie zespołowe. Jeśli inny programista lub inny agent będzie kontynuował tę pracę, specyfikacja jest artefaktem przekazania. Log gitowy i README nie są wystarczające.

Istotne refaktoryzacje. Refaktoryzacje dotykające podstawowych abstrakcji potrzebują wyraźnego stwierdzenia, co musi pozostać takie samo (zachowanie) i co może się zmienić (struktura). Bez tego agent może złamać kontrakty, które myślałeś, że zostały zachowane.

Kiedy vibe coding jest nadal lepszy

SDD to narzut. Czasami narzut nie jest wart tego.

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

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

Szkice UI. Projekt interakcji korzysta z widzenia, a nie określania. Zbuduj kilka niedokładnych wariantów szybko, zareaguj na to, co widzisz, i określaj tylko to, co faktycznie będziesz wysył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 uczenie się, a nie produkcja, vibe coding jest szybszy, a wady są ograniczone.

Prosty framework decyzyjny

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

Używaj vibe codingu, gdy:

  • Zadanie zajmuje mniej niż dzień
  • Eksplorujesz lub uczysz się
  • Artefakt jest jednorazowy lub niskostawkowy
  • Jesteś jedyną osobą, która dotknie tego
  • Szybkość zwrotnej informacji 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 dotyczące 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 publicznego interfejsu lub kontraktu danych
  • Włączonych jest wielu agentów lub członków zespołu
  • Organizacja wymaga przeglądu projektu przed implementacją
  • Wymagane są ścieżki audytowe lub zgodności

Najczęstszym błędem jest stosowanie pełnego SDD do zadań, które potrzebują tylko lekkiego SDD, a stosowanie żadnej specyfikacji do zadań, które potrzebują co najmniej lekkiej.

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

Przydatne linki

Subskrybuj

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