Rozwój oparty na specyfikacji: praktyka, na której zbiegła się cała kategoria

Każde poważne narzędzie AI do kodu wydało tę samą funkcję w ciągu około roku, a to niemal nigdy nie zdarza się przypadkiem.

W 2025 roku ciekawym pytaniem było, jak dobre stają się modele. W 2026 ciekawym pytaniem jest to, co im podajesz.

GitHub wydał Spec Kit. AWS wydało Kiro, środowisko programistyczne zbudowane wokół tej idei. BMAD-METHOD, OpenSpec i Tessl podjęły po jednej próbie. Cursor doszedł tam przez pliki zasad. Martin Fowler opublikował porównanie tych wykonań. Kiedy sześć niezależnych zespołów w dwanaście miesięcy zbiega się na tej samej odpowiedzi, nie kopiują siebie. Wszystkie uderzają w tę samą ścianę.

Ściana ma teraz nazwę. Rozwiązanie też.

Czym naprawdę jest rozwój oparty na specyfikacji

Napisz wymagania, ograniczenia i kryteria sukcesu przed wygenerowaniem jakiegokolwiek kodu. Traktuj ten dokument jako źródło prawdy. Pozwól agentowi budować wobec niego.

To wszystko. To nie nowa idea: to analiza wymagań, którą branża trzydzieści lat robiła źle, a potem w dużej mierze porzuciła jako zbyt wolną. Zmieniło się nie pojęcie. Zmieniła się ekonomia.

Specyfikacje były kosztowne w pisaniu i kosztowne w utrzymywaniu, co znaczyło, że większość zespołów pisała grube linie i odkrywała wszystko inne w przeglądzie kodu. To była rozsądna wymiana, dopóki osoba z programowania i tak potrzebowała trzech tygodni na funkcję. Przestała być rozsądna, gdy generowanie stało się szybkie, bo teraz specyfikacja jest częścią wolną, a w części wolnej mieszka cały sąd.

Sposób zawodzenia, przeciw któremu to wymyślono

Narzędzia zaczynające od polecenia pomijają specyfikację w całości. Opisujesz wynik, narzędzie wytwarza coś, co go przypomina, a każdą decyzję, której opis nie obejmował, podejmuje w milczeniu generator.

Jakie decyzje? Te, które okazują się ważne. Czy adres poczty jest jednoznaczny i jednoznaczny w obrębie czego. Co wypowiedziane konto może jeszcze widzieć. Co się stanie, gdy dwie osoby zmienią ten sam wpis. Czy ta lista potrzebuje podziału na strony, zanim będzie miała dziesięć tysięcy wierszy.

Nikt nie zadał tych pytań, więc nikt nie odpowiedział, ale aplikacja ma odpowiedź na każde z nich, wybraną przez wnioskowanie z kontekstu, który nigdy nie zawierał twojej firmy.

Ta sama dynamika pojawia się w każdym narzędziu, które pomija krok określania. To mechanizm stojący za problemem 70 procent: postęp staje nie dlatego, że pozostała praca jest trudna, ale dlatego, że blokuje ją decyzja architektoniczna podjęta w milczeniu setki generacji wcześniej, której nie da się już zmienić bez rozebrania systemu.

Dane o tym, co dzieje się bez niej

Raport DORA z 2025 roku o stanie tworzenia oprogramowania wspieranego przez AI jest najczystszym dostępnym odczytem. 90 procent osób pracujących w technologii używa teraz AI w pracy, a ponad 80 procent uważa, że podniosła ich produktywność. I wyższe wykorzystanie AI idzie w parze ze wzrostem przepustowości dostaw oraz ze wzrostem niestabilności dostaw, w tym samym czasie.

Szybciej w wydawaniu. Gorzej w utrzymywaniu rzeczy w ruchu. Jedno i drugie razem.

Analiza GitClear z 2026 roku na 623 milionach zmian w kodzie pokazuje kształt szkody. Wobec poziomu odniesienia z 2023 roku: zdublowane bloki kodu wyżej o 81 procent, kopiowanie i wklejanie w obrębie jednego wysłania wzrosło z 9,4 procent w 2022 do 15,7 procent w pierwszej połowie 2026, konstrukcje maskujące błędy wyżej o 47 procent. W tym samym czasie wywołania funkcji między plikami, najlepszy dostępny wskaźnik ponownego użycia kodu, niżej o 35 procent, a praca porządkująca kod załamana z 21 procent zmian w 2022 roku do 3,8 procent w 2026.

Osoby z programowania kopiują i wklejają teraz około pięć razy częściej, niż porządkują kod. W 2022 roku ta proporcja biegła w drugą stronę.

Nic z tego nie jest kwestią jakości modelu. To skutek tego, że generowanie jest tanie, a struktura nie jest wyraźnie niczyim zadaniem.

Trzy stopnie zaangażowania

Nie wszyscy rozumieją to wyrażenie tak samo, a różnice mają w praktyce znaczenie. Ujęcie Martina Fowlera jest najczystsze, jakie widziałem.

Specyfikacja najpierw. Piszesz specyfikację, generujesz z niej, a potem utrzymujesz kod ręcznie. Specyfikacja napędza pierwszą budowę, a potem stopniowo staje się historyczna. Najłatwiejsze do wprowadzenia, z najsłabszymi gwarancjami: pół roku później dokument opisuje system, który już nie istnieje.

Specyfikacja jako kotwica. Specyfikacja i kod rozwijają się razem. Zmieniasz specyfikację, generujesz na nowo dotknięte części, utrzymujesz oba w aktualności. Więcej dyscypliny, a nagrodą jest to, że dokument pozostaje godny zaufania.

Specyfikacja jako źródło. Specyfikacja jest jedynym wytworem, który zmieniasz. Kod jest wyjściem, tak jak wyjściem jest skompilowany plik: nie łata się go ręcznie. Najsilniejsze gwarancje i największy skok w sposobie pracy zespołu.

Większość zespołów nazywających się opartymi na specyfikacji stosuje wariant „specyfikacja najpierw”. To prawdziwa poprawa wobec promptowania na oślep i jest to zarazem wersja, która po cichu podupada.

Co należy do specyfikacji

Użyteczna próba: jeśli generator musiałby zgadywać, to należy do dokumentu.

• Model danych. Encje, relacje, liczebność, co czyni wpis jednoznacznym, co dzieje się przy usunięciu. To najbardziej wartościowa część i ta najczęściej pomijana.
• Typy użytkowników i uprawnienia. Kto istnieje, co każdy może widzieć i robić, co dzieje się na granicach.
• Niezmienniki. Zasady, których nigdy nie wolno naruszyć, wyrażone wprost. Nie „obsługiwać błędy elegancko”, bo to życzenie, a nie ograniczenie.
• Kryteria sukcesu. Jak poznasz, że rzecz działa, w słowach dość dokładnych, by spór o to, czy działa, dał się rozstrzygnąć.

Co do niej nie należy: szczegóły wykonania, które generator wybiera lepiej niż ty. Specyfikacja, która nazywa zmienne, nie jest specyfikacją, jest kodem z gorszym narzędziem.

Część, którą wszyscy robią źle

Specyfikacja pomaga tylko wtedy, gdy da się ją wymusić gdzieś poza prozą.

Jeśli ograniczenie żyje tylko w dokumencie, jest sugestią. Generator przeczytał je raz i mógł je uszanować w czternastym dotkniętym pliku albo nie. Ograniczenia muszą trafić tam, gdzie system sprawdza: „nie puste” i „jednoznaczne” w bazie danych, a nie w obsłudze formularza, typy na granicach, a nie w komentarzu, autoryzacja jako zasada, którą system ocenia, a nie warunek, o którego napisaniu ktoś pamiętał.

To różnica między rozwojem opartym na specyfikacji jako praktyką a rozwojem opartym na specyfikacji jako gatunkiem dokumentu. Dokument jest tym, jak decydujesz. Wymuszanie jest tym, jak decyzję utrzymujesz.

Jak rozpoznać, czy naprawdę to stosujesz

Cztery pytania, celowo niewygodne.

1. Gdy coś pęka, naprawiasz kod czy specyfikację? Jeśli odpowiedź to zawsze kod, w najlepszym razie stosujesz „specyfikację najpierw”, a dokument jest już przestarzały.
2. Czy nowa osoba mogłaby przeczytać specyfikację i przewidzieć, jak system się zachowa? Jeśli musiałaby po to czytać kod, specyfikacja jest streszczeniem, a nie źródłem.
3. Czy jest w specyfikacji coś, czego system nie może naruszyć? Jeśli każda zasada jest prozą, żadna nie jest zagwarantowana.
4. Przeglądasz specyfikację czy różnicę w kodzie? Przeglądanie tysięcy linii wygenerowanego kodu to teatr. Spieraj się o dokument, dopóki spór jest jeszcze tani.

Gdzie to zostawia narzędzia

Większość dzisiejszych wykonań jest oparta na specyfikacji szczególnie dla generowania kodu. Wytwarzają specyfikację i generują wobec niej wykonanie, a wytworem, na którym działają, jest baza kodu.

Trudniejsza wersja rozciąga tę samą logikę na całą aplikację (model danych, powierzchnię interfejsu programowania, granicę uwierzytelniania, interfejs), tak by specyfikacja obejmowała nie tylko to, co kod robi, ale to, czym system jest. Dokładnie tym jest faza planu w Archie i dlatego opisuję ją jako rozwój oparty na specyfikacji zastosowany do całego stosu, a nie do repozytorium. Inny zakres, ta sama zasada: określić przed generowaniem.

Rozsądne osoby nie zgadzają się co do tego, jak daleko to posuwać. Nikt poważny nie argumentuje za powrotem.

Ile to kosztuje

Przesunięcie sądu na początek jest wolniejsze w pierwszym tygodniu projektu i szybsze w każdym następnym. Ten koszt jest prawdziwy i płaci się go dokładnie w momencie, gdy rozpęd wydaje się najcenniejszy, a konkurent wydaje coś widocznego. Będą rundy pracy, w których zespół, który to pominął, będzie wyglądał na prowadzącego.

Dyscyplina też podupada. Zapisywanie ograniczeń jest mniej przyjemne niż patrzenie, jak pojawia się interfejs, a przeglądanie dokumentu mniej satysfakcjonujące niż przeglądanie kodu. Te nawyki erodują pod presją terminów, a to ta sama presja, która czyni je ważnymi.

I naprawdę nie stosuje się to do wszystkiego. Jeśli w ten weekend sprawdzasz pomysł i zamierzasz wyrzucić wynik, wyrzuć go. Nic z tego nie jest warte zachodu dla oprogramowania o dwudniowym życiu.

Powód, dla którego to zostało

Każda wcześniejsza próba nakłonienia zespołów do pisania najpierw specyfikacji zawiodła i zawiodła z dobrego powodu: specyfikacja była dodatkowym ciężarem ponad prawdziwą pracę. Pisałeś dokument, a potem i tak musiałeś zbudować rzecz.

To już nie ta wymiana. Teraz dokument jest większością pracy, a budowa jest częścią tanią. Sześć niezależnych zespołów zauważyło to w ciągu roku, bo był to oczywisty skutek tego, że model stał się dobry.

Ta praktyka nie wygrała sporu. Ekonomia przesunęła się pod nią.

Powiązane lektury

Pierwotna diagnoza: vibe coding złamał swoją obietnicę. Gdzie kategoria poszła dalej: co przychodzi po vibe codingu. Ten sam argument zastosowany do całych systemów: projektowanie oprogramowania z AI na pierwszym miejscu od pierwszych zasad. I starsze ujęcie tej samej idei: nie pisać oprogramowania dwa razy.

Często zadawane pytania

Czym jest rozwój oparty na specyfikacji? Napisaniem wymagań, ograniczeń i kryteriów sukcesu przed wygenerowaniem jakiegokolwiek kodu i traktowaniem tej specyfikacji jako źródła prawdy, wobec którego buduje agent AI. Powstał w 2025 i 2026 roku jako bezpośrednia odpowiedź na sposoby pracy zaczynające od polecenia i pomijające krok określania.

Czym różni się od klasycznych dokumentów wymagań? Pojęcie jest to samo; ekonomia nie. Klasyczne specyfikacje były dość kosztowne, więc zespoły pisały grube linie i odkrywały resztę w trakcie wykonania. Kiedy sporządzenie jednej zajmuje godziny, a nie miesiące, i da się ją tanio poprawić, warto ją skończyć i utrzymywać aktualną.

Jakie narzędzia wspierają rozwój oparty na specyfikacji? GitHub Spec Kit, AWS Kiro, BMAD-METHOD, OpenSpec i Tessl to wykonania z nazwą, a Cursor wspiera lżejszą wersję przez pliki zasad. Różnią się głównie tym, jak ściśle specyfikacja wiąże się z kodem: czy napędza generowanie raz, rozwija się obok niego, czy jest jedynym wytworem, który zmieniasz.

Jakie są trzy stopnie rozwoju opartego na specyfikacji? Specyfikacja najpierw, gdzie specyfikacja napędza pierwszą budowę, a kod utrzymujesz potem ręcznie. Specyfikacja jako kotwica, gdzie specyfikacja i kod rozwijają się razem. Specyfikacja jako źródło, gdzie specyfikacja jest jedyną rzeczą, którą zmieniasz, a kod jest traktowany jako wyjście. Większość zespołów, które to stosują, robi „specyfikację najpierw”.

Czy rozwój oparty na specyfikacji zwalnia zespoły? Przenosi pracę, zamiast ją dodawać. Decyzje w specyfikacji są podejmowane albo świadomie z góry, albo w milczeniu przez generator, który zgaduje później, a druga droga jest źródłem poprawek. Jest wolniejszy w pierwszym tygodniu i szybszy potem.

Co powinno wejść do specyfikacji? Wszystko, co generator musiałby inaczej zgadywać: model danych z relacjami i zasadami jednoznaczności, typy użytkowników i uprawnienia, niezmienniki, których nigdy nie wolno naruszyć, oraz kryteria sukcesu dość dokładne, by rozstrzygnąć spór. Pomiń szczegóły wykonania, które generator wybiera lepiej niż ty.

Czy rozwój oparty na specyfikacji to to samo co projektowanie z AI na pierwszym miejscu? Rozwój oparty na specyfikacji to praktyka określania przed generowaniem. Projektowanie z AI na pierwszym miejscu to szerszy zbiór skutków architektonicznych, obejmujący także to, gdzie wymusza się ograniczenia, w jakiej kolejności podejmuje się decyzje i jak projektować dla odbiorców będących agentami obok odbiorców będących ludźmi.