Czym jest programowanie sterowane specyfikacją?

Programowanie sterowane specyfikacją (spec-driven development) to sposób pracy, w którym agent kodujący buduje według pisemnej specyfikacji, sprawdzonej przez człowieka, zanim powstanie kod. Nie ustalono autora nazwy z ery AI: Kiro użyło jej w poście z premiery 14 lipca 2025, a GitHub Spec Kit 2 września 2025. Dostawcy przedstawiają je jako krok po vibe codingu, a nie jego przeciwieństwo.

Pochodzenie Nikomu nie przypisuje się ukucia nazwy w erze AI: najwcześniejsze użycia, jakie znalazły badania, to post z premiery Kiro z 14 lipca 2025 (otwiera się w nowej karcie), post GitHuba o Spec Kit z 2 września 2025 (otwiera się w nowej karcie) i post Tessl z premiery z 16 września 2025 (otwiera się w nowej karcie), a samo wyrażenie ma akademicki rodowód z 2004 roku.

Także w Wikipedia (otwiera się w nowej karcie), Wikidata (otwiera się w nowej karcie)

Ostatnia aktualizacja: 2026-10-10; Autor: Michał Jaskólski; Opublikowano 2026-10-10
Po angielsku: Spec-driven development
Najbliższy poziom drabiny: Poziom 4, darmowy przewodnik
Szukane też jako: spec-driven development, SDD

Wypróbuj 7 dni za darmo Przeczytaj darmowy przewodnik

Potem $19.99 miesięcznie lub $99.99 rocznie. Subskrypcję anulujesz na stronie konta. Zwrot pierwszego zakupu: 30 dni.

Na tej stronie

Dlaczego to ważne Programowanie sterowane specyfikacją a vibe coding Trzy poziomy spec-driven development Frameworki spec-driven: pierwsze publiczne daty Pytania Źródła

Dlaczego to ważne.

Specyfikacja przenosi czytanie człowieka z diffa na dokument: sprawdzasz, co ma powstać, zanim agent to zbuduje, a testy pilnują wyniku. Działa to tylko wtedy, gdy specyfikacja pozostaje prawdziwa, bo agent wierzy w to, co w niej stoi. Dlatego nasz przewodnik zaleca jeden wiążący spec.md, deltę specyfikacji w każdym pull requeście zmieniającym zachowanie i test przy każdym wymaganiu. Sama etykieta niewiele dowodzi: framework dokłada ceremonii, ale nie sprawia, że specyfikacja jest prawdziwa.

Programowanie sterowane specyfikacją a vibe coding

Dostawcy, którzy wprowadzili tę nazwę, przeciwstawiają ją vibe codingowi jako krok dla poważnej pracy; nasza analiza: oba pojęcia stoją raczej jedno po drugim niż naprzeciw siebie.

Programowanie sterowane specyfikacją w zestawieniu z vibe codingiem: co nazywa, kto pisze kod, kto go sprawdza, co kończy pętlę, skąd pochodzi nazwa i gdzie zawodzi
Pytanie	Vibe coding	Programowanie sterowane specyfikacją
Co nazywa	Sposób pracy: przyjmować wynik modelu bez czytania	Przepływ pracy: sprawdzona specyfikacja, plan i lista zadań przed jakimkolwiek kodem
Kto pisze kod	Model	Agent, na podstawie zatwierdzonej specyfikacji
Kto to sprawdza	Nikt nie czyta diffa; człowiek ocenia działanie na oko	Ludzie sprawdzają specyfikację, plan i zadania; testy pilnują wyniku
Co kończy pętlę	Człowiek uznaje, że działa	Lista zadań jest zamknięta, a kryteria akceptacji przechodzą (nasza analiza)
Skąd nazwa	Andrej Karpathy, wpis na X, 2 lutego 2025	Brak jednego autora z ery AI; Kiro, 14 lipca 2025; GitHub Spec Kit, 2 września 2025
Gdzie zawodzi	Wszędzie, gdzie kod utrzymują inni; Karpathy uznał je za dobre do „throwaway weekend projects” (weekendowych projektów na wyrzucenie)	Specyfikacja, której nikt nie utrzymuje, myli agenta, a krytycy widzą w papierach waterfall (Marmelab, 12 listopada 2025)

Vibe coding w oryginalnym sensie Karpathy’ego. Post GitHuba z premiery pisze, że „can be great for quick prototypes, but less reliable when building serious, mission-critical applications” (świetnie nadaje się do szybkich prototypów, ale gorzej do poważnych aplikacji). Źródło: Vibe coding a inżynieria agentowa, 2026-10-10.

Trzy poziomy spec-driven development

Birgitta Böckeler z Thoughtworks wyróżnia trzy sposoby użycia specyfikacji i stwierdziła, że wszystkie podejścia, które zbadała, są spec-first, ale nie wszystkie dążą wyżej.

Trzy poziomy spec-driven development według Böckeler i jej definicje
Poziom	Definicja Böckeler (15 października 2025), w tłumaczeniu
Spec-first	Przemyślana specyfikacja powstaje najpierw i służy w zadaniu, które właśnie realizujesz.
Spec-anchored	Specyfikacja zostaje po zakończeniu zadania i służy dalszemu rozwojowi oraz utrzymaniu tej funkcji.
Spec-as-source	Z czasem specyfikacja staje się głównym plikiem źródłowym: człowiek edytuje tylko ją i nigdy nie dotyka kodu.

Nasz przewodnik po spec-driven development wymaga więcej niż spec-first: jednego wiążącego spec.md, utrzymywanego w zgodzie z kodem przez deltę specyfikacji w każdym pull requeście zmieniającym zachowanie. Nasza analiza: to jest spec-anchored.

Źródło: Przewodnik po spec-driven development, 2026-10-10.

Frameworki spec-driven: pierwsze publiczne daty

To premiery z ery AI, które badania mogły datować na podstawie własnego wpisu lub repozytorium projektu, po kolei, z tym, co każdy z nich zapisuje przed kodem.

Kiro, OpenSpec, GitHub Spec Kit i Tessl: pierwsza publiczna data i to, co każdy zapisuje przed kodem
Projekt	Datowane przez	Co zapisuje przed kodem
Kiro (AWS)	14 lipca 2025, post z premiery	Wymagania jako historyjki użytkownika z kryteriami akceptacji w notacji EARS, potem projekt techniczny i zadania
OpenSpec (Fission AI)	5 sierpnia 2025, utworzenie repozytorium	Propozycja zmiany z deltami specyfikacji; archiwizacja scala je w `openspec/specs/`
GitHub Spec Kit	2 września 2025, post z premiery (repozytorium utworzono 21 sierpnia 2025)	Constitution, a potem specyfikacja, plan i lista zadań dla każdej funkcji, w osobnym folderze na funkcję
Tessl	16 września 2025, post z premiery produktów	Specyfikacje zapisujące intencję, wsparte testami i „hard guardrails” (twardymi barierkami)

Daty pochodzą z postów z premier Kiro, GitHuba i Tessl oraz z dat utworzenia repozytoriów OpenSpec i Spec Kit na GitHubie, odczytanych 10 października 2026. Komórki Kiro i Tessl streszczają ich posty z premier; komórki Spec Kit i OpenSpec idą za naszym porównaniem frameworków. Źródło: Frameworki spec-driven w porównaniu, 2026-09-26.

Najczęstsze pytania.

Czym programowanie sterowane specyfikacją różni się od vibe codingu?

Vibe coding przyjmuje wynik agenta bez czytania; w programowaniu sterowanym specyfikacją ludzie najpierw sprawdzają specyfikację, plan i zadania, a testy pilnują wyniku. Post GitHuba z premiery pisze, że vibe coding „can be great for quick prototypes, but less reliable when building serious, mission-critical applications”. Nasza analiza: dostawcy przedstawiają spec-driven development jako krok po vibe codingu, a nie jego wroga.

Kto wymyślił spec-driven development?

Dla ery AI nie ustalono jednej osoby. Samo wyrażenie ma akademicki rodowód w artykule Ostroffa, Makalsky’ego i Paige’a z 2004 roku. Kiro użyło go w poście z premiery 14 lipca 2025, GitHub w poście o Spec Kit 2 września 2025, a Tessl 16 września 2025. Birgitta Böckeler napisała 15 października 2025, że „the definition of ‘spec-driven development’ (SDD) is still in flux”.

Czy spec-driven development to to samo co AI-DLC?

Nie. AI-DLC to cykl życia i metoda pracy zespołu od AWS, przedstawiona 31 lipca 2025, która zastępuje sprinty „bolts” trwającymi godziny lub dni. Spec-driven development to praktyka dotycząca jednego artefaktu, czyli specyfikacji. Nasz przewodnik po frameworkach zalicza AI-DLC do potoków spec-first, gdzie jego cechą wyróżniającą jest ślad audytowy zatwierdzeń.

Czy spec-driven development to po prostu waterfall?

Krytycy twierdzą, że może tak być. François Zaninotto z Marmelab napisał 12 listopada 2025, że „revives the old idea of heavy documentation before coding”, i opisał agenta, który oznaczył zadanie „verify implementation” jako zrobione „without writing a single unit test”. Nasza analiza: ryzyko jest realne, gdy specyfikacja rozjeżdża się z kodem, dlatego nasz przewodnik wymaga delty specyfikacji w każdym pull requeście zmieniającym zachowanie i testu przy każdym wymaganiu.