Rozwój oparty na specyfikacji vs vibe coding: wodospad?

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 w vibe codingu.

Argument jest prosty: agenci AI generują lepsze i bardziej spójne wyniki, gdy implementują na podstawie zweryfikowanej specyfikacji, a nie ad hoc promptu. Teoretycznie trudno się z tym nie zgodzić.

W praktyce, na Hacker News nazwano to „Waterfall Strikes Back” (Powrót wodospadu).

Obie strony mają rację.

Spec-Driven Development versus Vibe Coding

Przypadek SDD w świecie Vibe Codingu

Vibe coding – praktyka polegająca na napisaniu luźnego promptu i iterowaniu nad tym, co wygeneruje agent AI – zadziwiająco dobrze sprawdza się w małych, eksploracyjnych i jednorazowych zadaniach. Przez pierwsze sześć miesięcy 2025 roku był to dominujący wzorzec kodowania z AI. Deweloperzy wydawali skrypty, prototypy i proste narzędzia szybciej niż kiedykolwiek wcześniej.

Następnie projekty się rozrosły. Funkcje obejmujące wiele plików zaczęły dryfować. Ograniczenia ustalone w pierwszej sesji były zapominane do trzeciej. Zakładane kwestie bezpieczeństwa były pomijane. Decyzje architektoniczne zmieniały się w trakcie realizacji funkcji, ponieważ agent nie miał trwałej pamięci intencji.

Spec-Driven Development (SDD) pojawiło się jako dyscyplinowana odpowiedź. Główna teza: uczynić specyfikację centralnym artefaktem, a nie promptem. Najpierw zapisz wymagania, projekt i plan zadań. Pozwól agentowi implementować na podstawie tych artefaktów po kolei, wycinek po wycinku. Utrzymuj specyfikację wersjonowaną i aktualizowaną.

GitHub Spec Kit, Kiro, Claude Code SDD workflows, and BMAD, a także inne szkielety społecznościowe, takie jak Superpowers, to wszystko implementacje tego pomysłu. Narzędzia są realne. Zainteresowanie jest realne. Reakcja krytyczna również jest realna.

W czym Vibe Coding jest dobry

Zanim odrzucimy vibe coding, warto precyzyjnie określić, w czym jest dobry.

Eksploracyjne prototypy. Gdy nie jesteś pewien, co chcesz zbudować, najszybszą drogą jest zbudowanie czegoś niedokończonego i reagowanie na to. SDD wymaga znajomości tego, co należy zdefiniować. Jeśli jeszcze tego nie wiesz, specyfikacje są przedwczesne.

Eksperymenty z UI. Wizualny układ i odczucie interakcji są trudne do zdefiniowania z góry. Vibe coding pozwala szybko zobaczyć opcje, odrzucić większość z nich i zbiec się na coś, co naprawdę dobrze się sprawdza. Dokument wymagań nie pomoże Ci tutaj.

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

Szybka informacja zwrotna. Gdy musisz szybko się czegoś nauczyć – czy ten API działa tak, jak myślisz? – vibe coding skraca pętlę nauki do kilku minut. SDD spowolniłoby to bez żadnej korzyści.

Błędem jest wzięcie wzorców sukcesu z tych kontekstów i zastosowanie ich do funkcji produkcyjnych z realnymi ograniczeniami, realnymi użytkownikami i realnymi konsekwencjami błędów.

Gdzie Vibe Coding się zawodzi

Vibe coding przewidywalnie traci na jakości wraz ze wzrostem zakresu i stawki.

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

Dryf architektoniczny. Bez wyraźnych celów poza zakresem (non-goals), agenci implementują rzeczy. Agent dodaje warstwę cache, bo wydaje się to rozsądne. Trzy sesje później, założenie dotyczące cache jest wtopione w model danych, a jego usunięcie jest kosztowne.

Zapomniane ograniczenia. „Tylko uwierzytelnieni użytkownicy mogą to wywołać” to zdanie w dokumencie wymagań. W sesji vibe codingu to jest 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. Zasady autoryzacji, granice walidacji wejścia, obsługa sekretów – to dokładnie ten rodzaj implikowanych wymagań, które zostają pominięte, gdy agent optymalizuje pod kątem prawdopodobnie działającego kodu, a nie poprawnego, ograniczonego kodu.

Przekazanie zespołowi. Jeśli zbudowałeś to przez iteracyjny prompting, artefaktem, który dokumentuje, 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 iteracja ma miejsce. Pełna definicja – w tym jak SDD różni się od TDD, BDD i metod formalnych – znajduje się w What Is Spec-Driven Development?

Zamiast iterować na kodzie i wy wnioskować intencję z różnic (diffs), iterujesz na specyfikacji, a następnie implementujesz. Specyfikacja staje się artefaktem, który dokumentuje, co zostało zdecydowane, dlaczego i co jest poza zakresem – pełniąc podobną funkcję co Architecture Decision Records, ale zorientowaną wokół intencji funkcji, a nie wyborów na poziomie systemu. Kod implementuje tę intencję.

SDD przebiega przez pięć faz – specyfikacja, plan, zadania, implementacja, walidacja – z bramką przeglądu ludzkiego na każdym etapie. Zobacz Spec-Driven Development Workflow From Requirements to Code w celu zapoznania się z pełnym procesem, szablonami i punktami kontrolnymi. Agent uczestniczy w większości faz, ale ludzie przeglądają artefakty, zanim zacznie się implementacja. Ten krok przeglądu jest centralną różnicą między SDD a vibe codingiem.

Dlaczego deweloperzy nazywają to Waterfall

Krytyka wodospadowa (waterfall) nie jest błędna. Jest po prostu skierowana przeciwko złemu SDD, a nie samemu SDD.

Konkretnym trybem awarii jest długie planowanie wstępne. Definiującą cechą waterfallu jest pętla informacyjna rozciągająca się na tygodnie lub miesiące: faza wymagań, faza projektu, faza budowy, faza testów, wydanie. Informacja zwrotna przychodzi późno. Gdy odkryjesz, że założenie projektowe było błędne, budowałeś na jego podstawie przez tygodnie.

Gdy deweloper używa Spec Kit i generuje listę 200 zadań, zanim napisze jedną linię kodu, a następnie spędza dwa dni na dopieszczaniu dokumentu wymagań, zanim agent cokolwiek dotknie, to jest waterfall. To jest waterfall z markdownem zamiast UML, ale tryb awarii jest identyczny.

Jeden komentator na HN opisał użycie Spec Kit dla małego narzędzia CLI i uznał je za „za powolne, za dużo dostosowywań przed zobaczeniem kodu”. To jest zła wersja. Ten użytkownik miał rację, odrzucając je dla tego zadania.

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

Pożyteczna droga pośrednia

Dobre SDD unika pułapki waterfallu, utrzymując specyfikację małą i rozpoczynając implementację wcześnie.

Małe specyfikacje. Dokument wymagań dla pojedynczej funkcji powinien zmieścić się na jednym ekranie. Jeśli specyfikacja ma dziesięć stron, to jest to albo projekt platformy, albo trzeba ją podzielić na mniejsze funkcje. Specyfikacje, które są zbyt duże, wymagają zbyt długiego przeglądu i szybko stają się nieaktualne.

Krótkie wycinki zadań. Każde zadanie powinno być możliwe do zaimplementowania w jednej 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 na kod staje się trudne do zweryfikowania.

Wczesna implementacja. Zdefiniuj pierwsze zadanie, zaimplementuj je, zwaliduj, a następnie przejdź do następnego zadania. Nie definiuj wszystkiego przed zaimplementowaniem czegokolwiek. Pierwsza implementacja ujawni rzeczy, w których Twoja specyfikacja się myliła. Zaktualizuj specyfikację przed kontynuowaniem.

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

Testy jako wykonywalna informacja zwrotna. 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 wywołać”, powinien istnieć test, który weryfikuje, że żądania bez uwierzytelnienia są odrzucane.

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

Kiedy SDD bije Vibe Coding

Używaj SDD – nawet lekkiego SDD – gdy koszt pomyłki jest realny.

Ryzykowna logika biznesowa. Fakturowanie, uprawnienia, migracje danych, idempotentność – każda logika, w której nieprawidłowe działanie jest kosztowne lub trudne do odwrócenia. Vibe coding pozostawia tego typu wymagania implikowane. SDD czyni je jawnymi i podlegającymi przeglądowi przed implementacją.

Zmiany produkcyjnych API. Każda zmiana w kontrakcie publicznego lub wewnętrznego API powinna mieć dokument projektowy. Dokument projektowy to to, co przeglądasz, zanim agent napisze kod, który zepsuje wywołujące.

Workflowy wielu agentów. 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ą się nie zgadzać.

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

Istotne refaktoryzacje. Refaktoryzacje dotykające rdzeniowych abstrakcji wymagają wyraźnego stwierdzenia, co musi pozostać niezmienione (zachowanie) i co może się zmienić (struktura). Bez tego agent może złamać kontrakty, które uważałeś za zachowane.

Kiedy Vibe Coding jest nadal lepszy

SDD to narzut (overhead). Czasami narzut nie jest wart swojej ceny.

Szybkie skrypty. Skrypt 50-liniowy 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 prędkości, nie struktury. Eksperymentuj najpierw, a jeśli eksperyment się uda, zdefiniuj specyfikację.

Szkice UI. Projektowanie interakcji zyskuje na oglądaniu, a nie specyfikowaniu. Szybko zbuduj kilka niedopracowanych wariantów, zareaguj na to, co widzisz, i specyfikuj tylko to, co faktycznie zamierzasz wydać.

Rzucalna automatyzacja. Skrypty jednorazowe, importy danych, pomocnicy migracyjne – koszt lekko błędnego wyniku jest zwykle niski, a artefakty i tak zostaną usunięte 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 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 się lub uczysz
  • Artefakt jest do wyrzucenia lub niskiej stawki
  • Jesteś jedyną osobą, która to dotknie
  • Prędkość informacji zwrotnej jest ważniejsza niż poprawność

Używaj lekkiego SDD, gdy:

  • Zadanie zajmuje dwa lub więcej dni
  • Dotknięto wielu plików
  • Istnieją jawne wymagania bezpieczeństwa lub poprawności
  • Inna osoba lub agent będzie kontynuował pracę
  • Musisz napisać testy mapujące się na wymagania

Używaj pełnego SDD, gdy:

  • Funkcja dotyka interfejsu publicznego lub kontraktu danych
  • Włączeni są wielu agenci lub członkowie zespołu
  • Organizacja wymaga przeglądu projektu przed implementacją
  • Wymagane są ślady zgodności lub audytu

Najczęstszym błędem jest stosowanie pełnego SDD do zadań, które wymagają tylko lekkiego SDD, oraz nie stosowanie żadnej specyfikacji do zadań, które wymagają co najmniej lekkiej. Niezależnie od wybranego poziomu, specyfikacja pozostaje przydatna tylko wtedy, gdy coś ciągle sprawdza ją w stosunku do kodu; Keeping Specs, Tests, And Code In Sync In AI Development obejmuje kontrole śledzenia, które wychwytują specyfikację cicho tracącą aktualność.

Złe SDD to waterfall z markdownem. Dobre SDD to kontrolowana iteracja z trwałymi artefaktami. Vibe coding to właściwe narzędzie do właściwych zadań – i niewłaściwe narzędzie do niewłaściwych. Znajomość tej różnicy to umiejętność.

Przydatne linki

Subskrybuj

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