Měsíce jsi psal podrobné specifikace, agent z nich generoval kód — a ten byl pokaždé o kus horší. Přesně tohle zažil Matt Pocock, TypeScript instruktor a autor open-source sady skills, a mluví o tom v rozhovoru s Natem Herkem na YouTube. Zajímavé je, co udělal poté. Specifikace zahodil, vrátil se ke kódu a začal řešit prostředí, ve kterém agent pracuje. V tomhle článku rozebereme spec-driven development nevýhody, které Pocock popisuje, a hlavně praktický postup, který používá místo toho — včetně toho, jak ho zkusit ještě dnes.
Co přesně Pocock zkoušel a proč to nevyšlo
Pocock vypráví příběh o svém největším hobby projektu: vlastním editoru videa (něco jako Descript) s AI psaním a tvorbou náhledů. Poté, co viděl přednášku zástupce OpenAI na konferenci AI Engineer, že „specifikace jsou nový kód“, to chtěl vyzkoušet poctivě. Celý projekt převedl na velkou specifikaci a držel se spec-driven developmentu: specifikaci udržoval a postupně zpřesňoval, agent z ní generoval kód.
Výsledek podle jeho slov? Kdykoli se podíval do kódu, byl horší a horší. Zkoušel to několik měsíců, protože si říkal, že člověk z OpenAI přece ví, o čem mluví. Nakonec specifikace vyhodil a začal se soustředit na kód samotný.
Za tím stojí jeho hlavní myšlenka: kód je prostředí, ve kterém agent pracuje. Agent v nepořádku produkuje nepořádek — Pocock to přirovnává ke psovi, který sedí v hořícím domě a nemůže podat dobrý výkon. Dobrá codebase je podle něj taková, kde se změny dělají snadno a nerozbijí nic, na co agent nepomyslel.
Spec-driven development: tři úrovně, které se pletou dohromady
Jedním z důvodů, proč se o SDD tak snadno hádá, je, že termín nemá pevnou definici. Birgitta Böckelerová z Thoughtworks ve svém textu na webu Martina Fowlera (15. 10. 2025) rozlišuje tři úrovně:
- Spec-first — specifikaci napíšeš před kódem a použiješ ji pro daný úkol. Po dokončení se může smazat.
- Spec-anchored — specifikaci držíš i po dokončení a dál ji upravuješ při údržbě funkce.
- Spec-as-source — specifikace je hlavní zdrojový soubor, člověk kód vůbec nepíše ani needituje.
Většina nástrojů je podle ní spec-first, i když o víc ambicí mluví. Nástroje jako Kiro od AWS nebo GitHub Spec Kit popisují workflow, kde z požadavků vzniká návrh, z něj úkoly a pak kód. Pokud sis přečetl náš návod na Spec Kit, víš, že funguje — jen je potřeba vědět, na jak velký problém ho nasadit.
Právě tady nacházíme první velkou nevýhodu: jeden workflow nesedí na všechny velikosti úkolů. Böckelerová popisuje, jak Kiro rozpadl malou opravu chyby na čtyři „user stories“ se šestnácti akceptačními kritérii. U Spec Kitu zase skončila s tolika markdown soubory, že by podle jejích slov rychleji dokončila funkci obyčejným AI kódováním — a měla by přitom větší kontrolu.
Pět nevýhod spec-driven developmentu v praxi
Z Pocockova příběhu a z Fowlerova rozboru se dá poskládat poměrně konkrétní seznam.
- Dlouhé specifikace se hůř čtou než kód. Böckelerová to říká otevřeně: radši by četla kód než desítky repetitivních markdown souborů. A když specifikaci nikdo pořádně nečte, schvaluje se naslepo.
- Falešný pocit kontroly. Agent často nesplní všechny instrukce, i když jsou ve velkém kontextovém okně. V jednom příkladu Spec Kit ignoroval poznámku, že popsané třídy už existují, a vygeneroval je znovu jako duplicity.
- Specifikace zastarává. Nic ji neudržuje v synchronizaci s kódem. Hned první věc, kterou ti implementace odhalí, ji udělá nepřesnou.
- Zakrývá slabý základ. Pokud je codebase špatná, ani dokonalá specifikace agentovi nepomůže. Pocockův případ: čím víc se spoléhal na spec, tím víc kód degradoval a nevšiml si toho.
- Nejasná velikost problému. Pro malou opravu je to „kladivo na ořech“, pro velkou nejasnou funkci zase chybí produktová analýza, kterou specifikace nenahradí.
Přesto neplatí, že by specifikace byly zbytečné. Böckelerová sama píše, že princip spec-first je v mnoha situacích hodnotný. Problém je dělat z nich zdrojový kód a udržovat je jako živý dokument.
Pocock: „Moje skills nejsou spec-driven development“
Zajímavé je, že Pocock se sám proti zařazení do SDD ohrazuje. V příspěvku na X z 1. 8. 2026 napsal, že lidé jeho skills pořád pletou se spec-driven developmentem a že ho to štve. Specifikace, které jeho skills vytvářejí, jsou podle něj určené ke smazání hned po použití — nejsou to zdrojový kód ani dokument, který se uchovává. Böckelerová takový přístup nazývá spec-first, ale stále ho řadí pod SDD. Pocock s tím nesouhlasí a navrhuje vlastní (napůl žertovný) název grill-driven development: specifikace je jen projekce rozhodnutí, ke kterým ses dopracoval při „grilování“.
Rozdíl je praktický. V klasickém SDD je hlavním artefaktem specifikace. V Pocockově přístupu je hlavním artefaktem sdílené porozumění mezi tebou a agentem, a specifikace je jen jeho zápis, protože kontextová okna jednou skončí.
Jeho skill /to-spec to říká přímo. Podle dokumentace na aihero.dev (aktualizováno 24. 8. 2026) nevede žádný rozhovor — zapisuje rozhodnutí, která už padla. Smysl má jen u práce, která se nevejde do jedné session: z takové specifikace se pak pomocí /to-tickets nařežou úkoly. A když se vejde do jedné session? Pak podle stejné dokumentace přeskoč specifikaci úplně a jdi rovnou z grilování do /implement. Trvalé zůstávají soubory GLOSSARY.md a ADR, ne specifikace.
Jak pracovat s agentem místo psaní velkých specifikací
Z celého rozhovoru vychází jednoduchý postup. Pokud už máš nastavené skills pro Claude Code, zabere ti pár minut.
1. Nejdřív nech agenta, ať se tě vyptá
Pocock říká, že mezi tebou a agentem je vždy komunikační bariéra a žádný chytřejší model ji nezruší. Agent neví, co ti záleží, dokud mu to neřekneš. Proto má jednu ze svých nejpoužívanějších skills /grill-me: agent tě nemilosrdně vyslýchá k tomu, co stavíte, a odhaluje věci, o kterých jsi ani nevěděl, že je nevíš — bezpečnost, nasazení, okrajové případy. Podrobnosti najdeš v našem článku o Pocockových skills.
2. Pojmenuj věci jednou a stejně všude
Pocock doporučuje myšlenku z domain-driven designu: jednotný jazyk. Pojem „objednávka“ má znamenat totéž v kódu, v databázi, v rozhraní i v rozhovoru se zákazníkem. K tomu slouží jeho skill /grill-with-docs, který při grilování zapisuje slovník do GLOSSARY.md. Stejnou roli plní soubor AGENTS.md — drží to, co agent potřebuje vědět v každé session.
3. Specifikaci piš jen tehdy, když ji potřebuješ
Řiď se tabulkou z dokumentace /to-spec:
- Ještě jsi nic nerozhodl → grilování.
- Rozhodnuto a práce se vejde do jednoho kontextového okna → rovnou implementace, bez specifikace.
- Rozhodnuto a práce zabere víc sessions → specifikace, pak úkoly.
Tip Specifikaci po dokončení práce klidně smaž. Dlouhodobě drž jen slovník a rozhodnutí o architektuře.
4. Pečuj o prostředí agenta
Tady Pocock vidí největší zisk. Nedávno u svého projektu zařídil, aby agent mohl otevřít prohlížeč, proklikat aplikaci a pořizovat screenshoty (projekt navíc závisel na lokálně spuštěném OBS). Podle něj ten jediný krok zvedl kvalitu výsledků víc než výměna modelu. Dobře fungují testy, které chytají chyby, a kontroly, které drží codebase v kondici. O podobném nastavení píšeme v článku o ladění harnessu bez výměny modelu.
5. Neplýtvej výkonem modelu
Pocock používá Claude Code s Opus 5.5 na střední úrovni „effort“ a uvažuje o nízké. Argument: když je prostředí dobré, agent nemusí „přemýšlet naplno“, aby napsal kód, který projde testy. Rychlejší odpovědi a menší spotřeba tokenů jsou vedlejší efekt. Jak model v praxi nasadit, popisujeme v návodu k Opus 5.5 v Claude Code.
Kdy je vibe coding v pořádku
Pocock není dogmatik. V rozhovoru říká, že vibe coding je v některých situacích dobrý nápad: když chceš rychle ukázat klientovi prototyp, který dokládá, že rozumíš jeho práci. Důležité je rozlišit prototyp na zahození a kód, který budeš dál rozvíjet. U druhého platí všechno výše.
K tomu se hodí i jeho zkušenost s multitaskingem. Podle jeho slov dnes pouští několik agentů najednou a počet jeho commitů vzrostl z přibližně dvaceti za dobrý den na stovky. Dodává ale důležitou věc: důvěru k agentům buduj postupně, od malých úkolů, a nejdřív se uč „brzdit“. Na to navazuje náš článek o třímodelovém workflow v Claude Code.
Pro koho z toho co plyne
Pro tým se Spec Kitem nebo Kiro nemusíš je zahazovat. Zkus je používat jako spec-first nástroj pro větší funkce a po dokončení specifikaci archivuj nebo smaž. Malé opravy dělej bez nich.
Pro samostatného vývojáře začni grilováním místo psaním dlouhého dokumentu. Většina hodnoty vzniká v rozhovoru, ne v souboru.
Pro neprogramátora Pocockova rada je stejná jako pro vývojáře — nauč se říkat agentovi, na čem ti záleží, a nech se vyptávat.
Časté otázky
Je spec-driven development špatný nápad?
Ne obecně. Spec-first přístup je podle Böckelerové užitečný u větších funkcí. Problémy vznikají, když specifikaci držíš jako živý zdroj pravdy, nechceš ji číst a spoléháš na ni místo kvality kódu.
Co je grill-driven development?
Je to Pocockovo žertovné označení pro jeho přístup: agent tě nejdřív vyslechne, rozhodnutí se zapíšou a specifikace slouží jen jako dočasný záznam. Nejde o oficiální metodiku.
Musím při větší práci psát specifikaci?
Jen když se práce nevejde do jednoho kontextového okna. Pak specifikace zachová rozhodnutí mezi sessions. U menších změn jdi rovnou z grilování do implementace.
Dá se tenhle postup použít v jiném nástroji než Claude Code?
Ano. Pocockovy skills jsou markdownové instrukce a podle dokumentace fungují i v Codexu, GitHub Copilotu a dalších agentech. Principy — vyptávání, slovník, testy, dobré prostředí — nejsou vázané na nástroj.
Co si z toho odnést
Spec-driven development nevýhody se dají shrnout jednou větou: specifikace nenahradí kvalitní kód, srozumitelné zadání a prostředí, ve kterém se agentovi dobře pracuje. Pocock to zkoušel měsíce a výsledkem bylo zhoršování kódu, ne zlepšování. Co funguje, je vyptávání před prací, jednotný slovník, testy a občasná specifikace, kterou po použití klidně smažeš.
Zdroje: rozhovor Nate Herk × Matt Pocock na YouTube (dostupné k 21. 10. 2026), příspěvek Matta Pococka na X z 1. 8. 2026, dokumentace /to-spec na aihero.dev (aktualizováno 24. 8. 2026), Understanding Spec-Driven-Development od Birgitty Böckelerové (15. 10. 2025).
