Spec-driven development se během roku 2025 stal jednou z nejviditelnějších odpovědí na vibe coding: místo jednorázového promptu zavádí specifikaci jako smlouvu mezi člověkem a AI agentem. Kiro od AWS, GitHub Spec Kit a Tessl ale pod stejným názvem dělají odlišné věci a k dubnu 2026 pořád chybí veřejný A/B benchmark, který by na stejném modelu a stejných úlohách čistě oddělil přínos SDD od zbytku agentického scaffoldingu.

Andrej Karpathy v tweetu z 2. února 2025 popsal vibe coding jako způsob práce, při kterém vývojář „zapomene, že kód existuje“, nechává AI generovat změny, nečte diffy a chybové hlášky prostě vrací zpět do chatu. Collins Dictionary z toho udělal slovo roku 2025 a Karpathy sám později ten post označil za nápad ze sprchy, který jen náhodou trefil dobu. Pro vývojářský svět je to poměrně dobrý začátek slovníku, ale mizerný základ metodiky.

Spec-driven development vzniká právě v téhle mezeře. GitHub ve svém oznámení Spec Kitu píše, že agenti často vracejí kód, který „vypadá správně, ale nefunguje úplně správně“, a že problém není jen v kódovacích schopnostech agenta, ale v tom, že s ním zacházíme jako s vyhledávačem místo s doslovným párovým programátorem. Z toho plyne zásadní posun: spec přestává být dokumentací k hotovému systému. Stává se vstupním kontraktem, podle kterého se má systém vytvořit, ověřit a později měnit.

Tři nástroje, jedno slovo a tři různé významy

Kiro vstoupil do public preview 14. července 2025 a AWS ho 17. listopadu 2025 označil za obecně dostupný. GitHub vydal Spec Kit 2. září 2025 jako open-source toolkit pro použití s Copilotem, Claude Code, Gemini CLI a dalšími agenty. Tessl, firma Guye Podjarného, zakladatele Snyku, si na podobnou vizi vzala už v listopadu 2024 kapitál 125 milionů dolarů: 25 milionů seed a 100 milionů Series A vedenou Index Ventures. Na slajdu to všechno vypadá jako jeden trend. V repozitáři je to složitější.

Birgitta Böckeler z Thoughtworks ve Fowlerově sérii Exploring Gen AI popsala SDD jako psaní specifikace před psaním kódu s AI, přičemž spec se stává zdrojem pravdy pro člověka i AI. Sama ale hned dodává, že termín je neustálený. Rozlišuje tři úrovně: spec-first, kdy se spec použije před implementací a pak často driftuje; spec-anchored, kde se udržuje i během evoluce systému; a spec-as-source, kde člověk edituje hlavně spec a kód je odvozený výstup, často označený komentářem // GENERATED FROM SPEC - DO NOT EDIT.

Tohle rozlišení je důležité, protože Kiro, Spec Kit a Tessl nejsou tři varianty stejného produktu. Kiro dělá workflow Requirements, Design, Tasks a uvnitř IDE drží uživatele u strukturovaných požadavků v EARS notaci. Spec Kit vytváří vícekrokový proces kolem příkazů /speckit.specify, /speckit.plan a /speckit.tasks, s projektovou constitution jako nadřazeným pravidlovým souborem. Tessl tlačí logiku nejdál: prohlašuje specs za primární artefakt, kód za odvozenou jednotku, a aspiruje až na spec-as-source. Böckeler u nich na blogu sama mapuje: Kiro je převážně spec-first, Spec Kit míří ke spec-anchored, ale podle ní ho nedotahuje, a Tessl je jediný, kdo skutečně směřuje ke spec-as-source.

Thoughtworks Technology Radar Vol. 34 z dubna 2026 to pojmenoval obecněji jako semantic diffusion. Termíny jako spec-driven development a harness engineering se podle něj používají nejednotně nebo se překrývají, takže je těžké poznat, jestli sledujeme samostatné techniky, nebo jen jiné nálepky pro podobné praktiky. To není slovíčkaření. Pokud metodika nemá společný význam, těžko se kolem ní staví tooling, školení, metriky a odpovědnost.

Spec se mění v testovatelný kontrakt

Nejzajímavější technický detail má dnes Kiro. Jeho requirements.md používá EARS, tedy Easy Approach to Requirements Syntax. EARS vznikl v roce 2009 u Alistaira Mavina a kolegů z Rolls-Royce jako pokus dostat přirozený jazyk požadavků do pevnějších šablon, aniž by bylo nutné přecházet na plně formální notaci. Původní práce popisuje pět jednoduchých šablon (Ubiquitous, Event-driven, State-driven, Optional Feature, Unwanted Behavior) a aplikaci na požadavky z leteckých regulací. Kiro z toho v praxi bere hlavně event-driven vzor:

WHEN a user submits the form with invalid data THE SYSTEM SHALL display validation errors next to the corresponding fields

Na první pohled to vypadá jako známé acceptance criteria v kabátu BDD. Rozdíl je v tom, že dnešní SDD nástroje se nesnaží jen lidem usnadnit čtení požadavků. Snaží se z požadavků vytvořit strojově použitelný vstup pro agenta. Kiro jde v tomhle směru nejdál property-based testingem. AWS u GA v listopadu 2025 ukázal, že Kiro umí ze strukturovaných EARS požadavků extrahovat obecné vlastnosti („pro každého autentizovaného uživatele a každý aktivní listing musí platit, že uživatel může listing zobrazit“) a generovat stovky až tisíce náhodných testovacích případů, které ověří, jestli implementace odpovídá popsanému chování. Není to jen unit test psaný člověkem podle příkladů. Je to automatizované ověřování kontraktu pomocí property-based testů. Není to formální důkaz správnosti, ale je to o řád silnější způsob, jak najít porušení smlouvy mezi spec a kódem.

Tady se láme rozdíl mezi dokumentací a kontraktem. Dokumentace vysvětluje člověku, co systém dělá nebo dělat má. Kontrakt říká agentovi, co musí platit, a dává týmu způsob, jak porušení objevit. GitHub to ve Spec Kit manifestu formuluje podobně: specifikace se podle něj mají stát živými, spustitelnými artefakty a sdíleným zdrojem pravdy. Důležitější věta je o pár odstavců dál. Nejde o to, že dokumentace najednou získala větší význam. Jde o to, že AI dělá specifikace spustitelnými.

Markdownová daň je skutečná

Problém začíná tam, kde se kontrakt změní v byrokracii. Böckeler v recenzi tří SDD nástrojů požádala Kiro o opravu malého bugu. Kiro z toho vytvořil čtyři user stories a šestnáct acceptance criteria. Sama to popsala jako „sledgehammer to crack a nut“ a dodala, že by raději revidovala kód než všechny ty Markdown soubory. Není to námitka proti disciplíně. Je to námitka proti špatné granularitě.

GitHub Spec Kit naráží na podobnou mez. Böckeler u něj popisuje množství repetitivních Markdown souborů, které je nutné číst a kontrolovat, a přidává horší detail: agent při průzkumu existujícího kódu správně našel existující třídy, ale později je vzal jako novou specifikaci a vygeneroval duplicity. Marmelab ve své kritice Spec Kitu z 12. listopadu 2025 uvádí příklad, kdy triviální požadavek na zobrazení aktuálního data v aplikaci pro time-tracking vedl k osmi souborům a zhruba 1 300 řádkům textu. Jestli se vám při tom vybaví enterprise Confluence z roku 2012, nejste sami.

AWS na tuhle bolest reagoval. V únoru 2026 přidal do Kira Bugfix Specs a Design-first workflow, tedy dvě cesty mimo původní rigidní model requirements-first. Blog Kira to říká docela otevřeně: část uživatelů už zná technickou architekturu, část řeší bug a potřebuje chirurgicky popsat, co se má změnit a co zůstat stejné. Původní třífázový tok se pro takové případy nehodil. Dobrá zpráva, a zároveň tiché přiznání, že první verze SDD nástrojů přenesla do AI světa starou nemoc softwarového procesu: snahu nacpat různé velikosti práce do jedné šablony.

Brownfield je místo, kde se ukáže pravda

Spec-driven vývoj vypadá nejlépe na čistém projektu. Napíšete product goal, necháte agenta vygenerovat spec, plán, tasks a pak implementaci. Pro demo ideální. V reálné firmě ale většina vývoje nezačíná prázdným repozitářem. Začíná patnáct let starou aplikací, doménovou logikou rozlitou mezi databázi, cron, front-end a integrační vrstvu, a dokumentací, které nikdo úplně nevěří.

Thoughtworks proto v dubnovém Radaru pochválil OpenSpec právě za jiný přístup. OpenSpec nestaví na tom, že nejdřív popíšete kompletní systém. Pracuje s deltami: propose, apply, archive. Místo úplné specifikace předem řeší konkrétní změny proti existujícímu stavu, fyzicky oddělené v adresářové struktuře (openspec/specs/ pro aktuální stav, openspec/changes/ pro navrhované změny s delta markery ADDED / MODIFIED / REMOVED). Spec se chová podobně jako verzovaný kód s historií změn. Radar OpenSpec popisuje jako lehčí, tool-agnostic alternativu k BMAD a Kiru, určenou pro týmy, které chtějí strukturu bez heavyweight procesu.

Tohle je praktičtější než ideologická debata, jestli je SDD návrat waterfallu. Pro nový interní nástroj může být GitHub Spec Kit rozumná brzda proti tomu, aby agent během dvou hodin vygeneroval neudržovatelný monolit. Pro opravu validační chyby ve starém ERP je osm souborů Markdownu nesmysl. U brownfieldu dává větší smysl delta spec, testovací harness, jasný kontext repo struktury a explicitní seznam věcí, na které agent nesmí sahat.

AGENTS.md řeší jen část problému

Vedle samotných specs běží paralelně druhá standardizační linka: kontextové soubory pro agenty. OpenAI 9. prosince 2025 oznámila, že AGENTS.md daruje do Agentic AI Foundation pod Linux Foundation. Podle OpenAI se od srpnového uvedení rozšířil do více než 60 tisíc open-source projektů a frameworků, včetně Codexu, Cursoru, Devinu, Factory, Gemini CLI, GitHub Copilotu, Jules a VS Code. Metodiku počítání firma nezveřejnila, takže číslo patří do kategorie vendor claim, ale směr je zřejmý.

Na úrovni jednoho souboru se ekosystém skutečně sbližuje. GitHub Copilot dokumentuje podporu AGENTS.md, CLAUDE.md i GEMINI.md pro agent instructions. Path-specific pravidla řeší zvlášť přes instrukční soubory s applyTo frontmatterem; Copilot coding agent navíc podporuje vnořené AGENTS.md podle umístění v repozitáři. Cursor v dokumentaci uvádí, že legacy .cursorrules deprecuje a doporučuje migraci na Project Rules nebo AGENTS.md. Windsurf ve changelogu uvádí opravy podpory AGENTS.md.

Velká výjimka je Claude Code. Oficiální dokumentace Anthropic pořád staví paměť kolem CLAUDE.md, rules a auto memory souborů v .claude. Claude Code sice umí s pamětí pracovat poměrně sofistikovaně, včetně automaticky zapisovaných poznatků z konverzací, ale issue žádající podporu AGENTS.md je v repozitáři otevřený od 21. srpna 2025 a k dubnu 2026 stále otevřený. Praktický workaround je vytvořit CLAUDE.md s importem @AGENTS.md; na Unixu lze použít i symlink ln -s AGENTS.md CLAUDE.md. Strategicky je to ale lepicí páska přes fragmentaci. Anthropic do Agentic AI Foundation daroval MCP. CLAUDE.md zůstal mimo.

Tady je dobré nerozšiřovat problém víc, než odpovídá realitě. Core context formát se sbližuje rychleji než před půl rokem. Fragmentace zůstává hlavně v tool-specific vrstvách: Cursor má vlastní typy pravidel a scoping (Always, Auto Attached, Agent Requested, Manual), Copilot má path-specific instrukce, Claude má auto memory, rules, skills a vlastní rozlišení mezi pamětí a vynutitelnými oprávněními. AGENTS.md může být společný README pro agenty. Nenahradí celý runtime konkrétního nástroje.

Důkazy o přínosu zatím nestačí

Největší slabina SDD dnes není ani Markdown, ani brownfield. Je to evidence. SWE-bench Verified a podobné benchmarky měří schopnost modelu nebo agenta řešit reálné GitHub issues, ale běžně měří celý systém: model, scaffold, nástroje, promptování, retry logiku a verifikační smyčku. Epoch AI u svého běhu SWE-bench Verified zdůrazňuje jednoduchý ReAct loop bez speciální scaffold struktury, právě aby šlo lépe porovnávat modely samotné.

Když Verdent hlásí 76,1 % pass@1 na SWE-bench Verified s plan-code-verify workflow, je to zajímavé číslo pro schopnost konkrétního agenta. Není to důkaz, že SDD jako metodika přidává určité procento úspěšnosti proti stejnému agentovi bez SDD. Chybí veřejný A/B test, kde by se vzal stejný model, stejné úlohy, stejný rozpočet tokenů a porovnal se agent bez spec workflow proti agentovi se spec workflow. Bez toho je SDD rozumná hypotéza, ne prokázaný násobič produktivity.

Vendor čísla nemají nahrazovat technický úsudek. Specifikace pravděpodobně pomáhá tam, kde je problém v nejasném záměru, v doménových pravidlech, v compliance nebo v architektonických hranicích. Nepomůže tam, kde je problém v tom, že agent neumí správně projít kódovou bázi, nerozumí staré integraci nebo jen slepě následuje příliš dlouhý soubor instrukcí.

Kdy contract-first vývoj dává smysl

Praktické pravidlo je jednodušší než terminologie. SDD má smysl, když cena chyby v požadavku převyšuje cenu napsání a revize specu. To platí pro nové produktové funkce, regulované systémy, platební logiku, doménově složité workflow, API kontrakty a změny, které budou žít déle než aktuální sprint. Tam se vyplatí nejdřív definovat chování, hraniční případy, neměnné části systému a způsob ověření. Agent pak není kouzelník, ale implementátor pod smlouvou.

Na opačném konci jsou bugfixy, CSS úpravy, malé refaktoringy, experimentální prototypy a jednorázové interní nástroje. Tam plné SDD často jen přesune práci z kódu do Markdownu. Pokud kvůli jednomu tlačítku čtete 1 300 řádků textu, neprovozujete disciplínu. Provozujete rituál.

Nejlepší současná praxe proto není „přejít na SDD“. Je přesnější: zavést spec jako kontrakt tam, kde kontrakt skutečně potřebujete. Pro greenfield může být Spec Kit nebo Kiro užitečný start. U existujících systémů se vyplatí dívat po delta přístupu typu OpenSpec nebo si napsat lehčí vlastní proces nad AGENTS.md, testy a jasně vymezenými změnami. V Claude Code dnes pořád počítejte s CLAUDE.md nebo symlinkem, pokud chcete držet jeden sdílený kontextový soubor napříč nástroji.

Spec-driven development není návrat k dokumentaci, kterou všichni ignorují. V lepší podobě je to pokus udělat ze záměru testovatelný artefakt, který agent nemůže tak snadno obejít. V horší podobě je to továrna na Markdown, kde člověk vyměnil review kódu za review textu, který agent stejně nemusí dodržet. Rozdíl mezi těmito dvěma světy nebude v názvu metodiky. Bude v tom, jestli tým dokáže spec udržovat jako kontrakt, měřit jeho přínos a bez sentimentu zahodit ceremonii tam, kde žádnou hodnotu nepřináší.