Spec-driven development s GitHub Spec Kit: přestaň vibe codovat feature, specni je
Znáš to. Sedneš, napíšeš agentovi "přidej systém notifikací", ten nadšeně vygeneruje 2 000 řádků, a o tři dny později zjišťuješ, že si každý pochopil zadání jinak. Ty jsi myslel přepínače pro jednotlivé kanály, agent postavil jeden globální on/off switch a design by potřeboval přepsat půlku user servisu. Kód přitom nebyl problém — problém bylo, že nikdo předem nedokázal sdílet kontext.
Přesně tenhle problém řeší spec-driven development (SDD) a GitHub k němu vydal open-source toolkit Spec Kit, se kterým celé workflow rozjedeš za pět minut v agentovi, kterého už stejně používáš — Claude Code, Copilot, Cursor, Gemini CLI.
Co spec-driven development je (a není)
SDD není návrat k waterfallu a není to psaní suchých requirement dokumentů, které si nikdo nepřečte. Je to verzování vlastního myšlení. Technická rozhodnutí dřív zůstávala uvězněná v e-mailech, Slacku a hlavách lidí — teď je zachytíš v Markdownu, který se vyvíjí spolu s kódem a který AI agent použije jako kotvu.
Proč na tom záleží zrovna teď? Protože agent bez kvalitní specifikace implementuje něco. Slabý prompt vystihne jen průměr tvého zadání. Se specifikací dostane přesně to, co jsi skutečně chtěl — včetně hraničních případů, o kterých jsi věděl, ale nenapsal.
Klíčová věc: specifikace je oddělená od kódu. To otevírá věci, které dřív nešly — můžeš nechat agenta vygenerovat dvě kompletně odlišné implementace téže specifikace (třeba jednu v Rustu a jednu v Go) a porovnat je. Nebo víc variant designu jednoho feature.
Jak Spec Kit funguje
Workflow má tři kroky a každý z nich je jeden Markdown soubor:
- Specify — co a proč. Funkční požadavky a motivace. Výslovně bez technických rozhodnutí.
- Plan — jak. Frameworky, knihovny, databáze, infrastruktura. Včetně researchu, datových kontraktů a quickstartu pro kolegy.
- Tasks — rozdělení specifikace a plánu na fáze a konkrétní tasky, které agent zvládne samostatně dodělat.
Instalaci má na starost Specify CLI:
uvx --from git+https://github.com/github/spec-kit.git specify init muj-projekt
CLI tě nechá vybrat agenta (podporuje většinu současných — Copilot, Claude Code, Gemini CLI, Cursor, Qwen Code a další), stáhne pro něj správné šablony a založí git repozitář, pokud ještě není. V projektu ti přibudou dvě složky:
.specify/— šablony pro spec, plan a tasks, plus helper skripty (bash i PowerShell).github/prompts/(u Copilota; jinde analogicky) — prompt definice pro slash commandy
A pak už jen používáš tři commandy, které fungují stejně v každém agentovi:
/specify → /plan → /tasks
Postupně za sebou. Každý krok vytvoří artefakt ve složce specs/, který si můžeš ručně upravit — jsou to obyčejné Markdowny.
Constitution: pravidla, která se nesmí porušit
Nejzajímavější část Spec Kitu je soubor constitution.md. Je to sada nediskutabilních principů projektu — firemní ústava pro kód. Třeba:
- každá nová funkce musí mít testy, než se mergne
- aplikace našeho týmu jsou vždy CLI-first
- žádné nové závislosti bez schválení v review
Constitution se pak automaticky dotahuje do každého kroku /plan a agent ti při jeho porušení dá vědět. Pro firmy je to způsob, jak si vynutit opinionated stack — sadu konvencí, kterou budou dodržovat všechny nové i staré projekty, včetně těch, na kterých pracuje AI.
Prakticky: jak na to v reálném projektu
Zkus si to na nejbližší větší feature, kterou máš v backlogu. Třeba onen notifikací systém:
1. Nejprve si promysli zadání. Čím detailnější první prompt do /specify, tím míň pak budeš dopisovat. Nerozhoduj o technologiích, ale vyjmenuj, co systém má umět: "uživatel si zapne/vypne notifikace per kanál (e-mail, push, in-app), s výchozí hodnotou podle typu zprávy, a změna se projeví do 5 minut".
2. Nech vygenerovat spec a přečti si ho. Agent doplní strukturu (user stories, požadavky číslované jako FR1, FR2…, edge casy). Tady nejlevněji opravuješ nedorozumění — změna stojí pár úhozů, ne sprint.
3. Spusť /plan. Až teď se řeší technický návrh. Pokud máš konkrétní preference (PostgreSQL, ne MongoDB; Sentry pro sledování doručení), napiš je do promptu — jinak se rozhodne agent za tebe.
4. Rozbij na tasky přes /tasks. Dostaneš číslované, atomické kroky navázané na čísla požadavků ze specu. Každý task je velký přesně na jedno kolo agenta — dost velký, aby to mělo smysl, dost malý, aby ses v tom neztratil.
5. Implementuj. Prostě řekni agentovi, ať tasky implementuje. Helper skripty hlídají, že všechno běží na jedné feature branchi a že si následné prompty pamatují odkazy na spec, plán a datové kontrakty.
Reálné časové rozdělení podle těch, kteří SDD používají: většina času jde na review vygenerovaných dokumentů a kódu, ne na psaní. To je správně — přesouváš se z role autora do role editoru.
Kdy to použít — a kdy ne
SDD se vyplatí u větších funkcí, nových projektů, refactoringů a všude tam, kde zadání dotýká víc lidí. Čím víc lidí musí sdílet stejnou představu, tím větší hodnota.
Nepoužívej to na opravu překlepu v CSS, jednorázový skript ani rychlý experiment. Tam je vibe coding pořád nejrychlejší cesta. SDD je sval pro věci, které budou žít déle než jeden den a které bude někdo dál rozvíjet.
Jedna z prvních reálných zkušeností zní: přidání feature do existující Node.js aplikace trvalo ~90 minut od promptu po kompletní spec, plán a rozpad tasků, plus ~35 minut exekuce agentem. Žádná magie — ale výsledkem je feature, kterou chápeš i ty.
Tipy na závěr
- Uprav si šablony.
.specify/složka je tvá — smaž, co nepotřebuješ, dopiš, co váš tým řeší. Default je example implementation, ne zákon. - Constitution naplň postupně. Začni s 3–5 pravidly, která už dávno máte, jen nejsou nikde napsaná. Rozšiřuj, až když agent opakovaně porušuje něco, co považuješ za samozřejmost.
- Spec je živý dokument. Když implementace odhalí chybu v zadání, oprav spec, ne jen kód. Příště agent vyjde ze správné verze.
- Funguje cross-agent. Šablony jsou navržené tak, aby je zvládly většinou agentů bez úprav — Spec Kit není další vendor lock-in.
Spec-driven development nezpomaluje. Posouvá práci z "opravuj, co agent pokazil" na "řekni agentovi přesně, co má udělat". A pokud ti pořád ještě agent generuje kód, který pak tři dny ladíš, je docela možné, že problém není v modelu — jen v zadání.
Vyzkoušej to na nejbližší větší feature. uvx --from git+https://github.com/github/spec-kit.git specify init a jde se.
