Nie pisać oprogramowania dwa razy: rozwój oparty na specyfikacji i koniec przepisywania

Dlaczego oprogramowanie zawsze pisano dwa razy, raz w specyfikacjach i drugi raz jako kod, i dlaczego to drugie pisanie w końcu znika.

W tworzeniu oprogramowania, gdy robi się to dobrze, musimy napisać oprogramowanie dwa razy: najpierw w szczegółowych specyfikacjach wyjaśniających dokładnie, co oprogramowanie ma robić, a potem ponownie jako kod, który te specyfikacje wprowadza w życie. Ale oto twarda prawda: rzadko robi się to dobrze za pierwszym razem.

Proces często się rozsypuje, bo tworzenie wyczerpujących specyfikacji zajmuje czas, a zespoły rzadko zbierają z góry wszystkie potrzebne szczegóły. Prowadzi to do luk, założeń i kosztownych poprawek. W efekcie projekty przekraczają budżet, chybiają terminów i zostawiają wszystkich sfrustrowanymi.

Ukryte koszty pisania oprogramowania dwa razy

By zrozumieć, dlaczego pisanie dwa razy jest konieczne, ale rzadko robione dobrze, rozłóżmy dwie fazy.

1. Pierwsze pisanie: specyfikacje w języku naturalnym

Pierwszy raz, gdy pisze się oprogramowanie, nie pisze się wcale kodu. Powstają wymagania, opowieści użytkowników i dokumenty projektowe, sporządzone w języku naturalnym. Tutaj zespoły opisują, jak oprogramowanie ma działać, co użytkownicy mogą robić i jakie ma być doświadczenie.

Ale oto problem: żaden zespół nie ma nigdy luksusu napisania wszystkich szczegółów. Osoby zajmujące się produktem często muszą się spieszyć, by zmieścić się w napiętych terminach, a w niektórych projektach nie ma nawet zawodowej roli produktowej. Zarysowuje się grube linie, ale ważne funkcje i interakcje wymykają się. Steve Jobs powiedział słynne zdanie: „wielkie produkty powstają z 5000 małych decyzji”, ale w większości projektów nie podejmujemy tych decyzji z góry. Zostają do późniejszej interpretacji przez programowanie, co prowadzi do drugiego kroku.

2. Drugie pisanie: przekład specyfikacji na kod

Gdy specyfikacje zostaną przekazane, programowanie odpowiada za zamianę tych opisów w działający kod. Ale gdy pierwsze pisanie jest niekompletne, musi używać wyobraźni, by wypełnić luki. Powstają założenia, a nawet jeśli osoby z inżynierii dobrze opanowały technologię, mogą nie mieć pełnego obrazu wizji produktu.

Tutaj problemy wychodzą na powierzchnię:

• Brakujące szczegóły dają tarcie: gdy zespoły produktowe nie określą ważnej funkcji albo przypadku użycia, programowanie musi zgadywać albo improwizować. Często daje to funkcjonalność, która nie spełnia oczekiwań.
• Założenia prowadzą do poprawek: gdy programowanie wypełnia luki, może zbudować funkcje w sposób niezgodny z wizją produktu, co powoduje ogromne poprawki później w projekcie.
• Wskazywanie palcem staje się nieuniknione: gdy terminy się przesuwają, a budżety pękają, zespoły przerzucają winę. Zespoły produktowe zarzucają inżynierii, że „nie zrozumiała”, a inżynieria wskazuje na niejasne specyfikacje.

W efekcie powstaje lawina problemów prowadząca do chybionych terminów, przekroczonych budżetów i niesatysfakcjonujących wyników. Badanie CHAOS grupy Standish od lat pokazuje, że większość projektów przekracza budżet i chybia daty dostawy. Badanie McKinseya z Uniwersytetem Oksfordzkim wykazało, że duże projekty informatyczne przekraczają budżet średnio o 45 procent i czas o 7 procent, dostarczając przy tym o 56 procent mniej wartości niż przewidywano, a 17 procent dużych projektów informatycznych idzie tak źle, że zagraża istnieniu firmy.

Wyraźnie coś w tym procesie jest zepsute.

Ta praktyka ma teraz nazwę

Branża zgodziła się na określenie, podczas gdy większość ludzi spierała się o polecenia: rozwój oparty na specyfikacji. Napisz najpierw wymagania, ograniczenia i kryteria sukcesu. Traktuj tę specyfikację jako źródło prawdy. Pozwól agentowi budować wobec niej.

GitHub wydał Spec Kit. AWS wydało Kiro. BMAD-METHOD, OpenSpec i Tessl podjęły po jednej próbie. Martin Fowler o tym pisał. Zbieżność nie jest przypadkiem: tak dzieje się, gdy cała kategoria w tym samym momencie odkrywa ten sam sposób zawodzenia.

A ten sposób zawodzenia opisano powyżej. Narzędzia zaczynające od polecenia pomijają pierwsze pisanie w całości. Idą wprost do drugiego, zgadując przy każdej decyzji, której specyfikacja nigdy nie podjęła. Co jest w porządku dla pokazu i zgubne dla produktu.

Rozwój oparty na specyfikacji nie znosi pierwszego pisania. Czyni je jedynym, które wymaga ludzkiego sądu.

Nowe pierwsze pisanie: specyfikacje, które naprawdę da się skończyć

Oto co się zmienia. Powodem, dla którego nikt nie pisał kompletnych specyfikacji, nigdy nie był brak chęci: praca była zbyt wolna, by się usprawiedliwić. Tygodnie rozpoznania na dokument, który starzał się przy pierwszym kontakcie z pierwszą rundą pracy. Więc zespoły pisały grube linie i zostawiały 5000 małych decyzji do odkrycia później, po jednej interpretacji.

Kiedy sporządzenie specyfikacji zajmuje godziny, a nie miesiące, rachunek się odwraca. Możesz pozwolić sobie na wyczerpanie tematu. Wymagania funkcjonalne, projekt wizualny, model danych, przypadki skrajne, zebrane przed otwarciem edytora i dość tanie, by je poprawić, gdy czegoś się nauczysz.

Ta ostatnia część się liczy. Specyfikacja, której nie da się tanio poprawić, staje się kłamstwem w chwili, gdy przychodzi rzeczywistość. To ten sam instynkt, który stoi za budowaniem z interfejsem programowania na pierwszym miejscu: podjąć dobrze decyzje nośne, zanim ktokolwiek napisze ekran, a reszta pójdzie za tym.

Nowe drugie pisanie: generowanie kodu, a nie przekład

Gdy specyfikacja jest kompletna, drugie pisanie przestaje być problemem przekładu. Staje się problemem generowania. Standardowe języki: JavaScript, TypeScript, Python. Standardowe frameworki: React, Next.js. Prawdziwy kod, w formach, które programowanie już zna, wywiedziony z dokumentu, który podjął już każdą decyzję.

Różnica nie polega na tym, że programowanie pracuje szybciej. Polega na tym, że przestaje wykonywać część, która nigdy nie była inżynierią: mechaniczne powtarzanie decyzji, które ktoś inny już podjął.

Co zmienia się dalej

Trzy rzeczy zmieniają się razem:

1. Pierwsze pisanie zostaje skończone: gdy praca nad specyfikacją kosztuje godziny, a nie miesiące, zespoły mogą pozwolić sobie na podjęcie małych decyzji z góry, a nie na odkrywanie ich w przeglądzie.
2. Nikt nie wypełnia luk: kod wygenerowany z kompletnej specyfikacji nie wymaga od nikogo zgadywania, co zespół produktowy miał na myśli. Zgadywanie zawsze było źródłem defektów.
3. Poprawki przestają się kumulować: zamiar i wykonanie startują zgodnie. To, co wcześniej było przepisywaniem, staje się zmianą w specyfikacji.

Przyszłość pisania oprogramowania: język naturalny

Odkąd ludzie wydają oprogramowanie, praca wymagała napisania go dwa razy: raz w języku naturalnym, drugi raz jako kod. To drugie pisanie nigdy nie było częścią wartościową. Było myto, które płaciliśmy, bo nie było innej drogi.

To ruch, wokół którego organizuje się następne pokolenie kreatorów aplikacji AI: jasność przed kodem. Opisać aplikację jako plan, dobrze ustawić architekturę, pozwolić, by kod został wygenerowany wobec niej. Nie skrót omijający pracę nad określeniem, ale powód, by w końcu wykonać ją porządnie.

Jest teraz inna droga. Oprogramowanie zawsze miało być pisane raz.

Powiązane lektury

Pełny przewodnik po tej praktyce: rozwój oparty na specyfikacji. Dlaczego pokolenie zaczynające od polecenia pominęło ten krok, omawia vibe coding złamał swoją obietnicę, a co zajmuje jego miejsce, co przychodzi po vibe codingu.

Często zadawane pytania

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

Czym rozwój oparty na specyfikacji różni się od napisania klasycznego dokumentu wymagań? Dokument to ta sama idea; ekonomia nie. Klasyczne specyfikacje były dość kosztowne, więc zespoły pisały grube linie i odkrywały resztę w przeglądzie kodu. Kiedy specyfikacja zajmuje godziny, a nie miesiące, i da się ją tanio poprawić, warto ją skończyć i warto utrzymywać ją 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 kodu, czy jest jedynym wytworem, który zmieniasz.

Czy rozwój oparty na specyfikacji zwalnia zespoły? Przenosi pracę, nie dodaje jej. Decyzje zebrane w specyfikacji ktoś podejmuje i tak: albo świadomie z góry, albo w milczeniu, gdy programowanie lub model zgaduje później. Druga droga jest źródłem poprawek.

Co dzieje się z programowaniem, jeśli kod jest generowany ze specyfikacji? Znika mechaniczne powtarzanie decyzji kogoś innego. Nie znika sąd o architekturze, kompromisach, poprawności i o tym, czego nie budować. To zawsze były części wymagające osoby z inżynierii.