Spec-driven development s AI: nejdřív plán, pak nechte agenta stavět

Vibe coding má svoje kouzlo. Otevřete Claude Code, napíšete 'udělej mi přihlašovací formulář' a za minutu koukáte na hotový kód. U prototypu nebo víkendového projektu je to úžasné. Problém nastane ve chvíli, kdy to samé zkusíte na produkčním systému, kde už je 200 tisíc řádků kódu, tři týmy a zákazníci, kteří si nepřejí, aby jim v pátek večer spadly platby.

Tam freestyle prompting přestává fungovat. Agent je mimořádně schopný vykonavatel, ale je jenom tak dobrý, jak dobré zadání dostane. A 'udělej mi to nějak' zadání není. Nejlepší vývojáři v roce 2026 proto u vážné práce nepřepínají mezi 'AI vs. bez AI' — přepínají mezi 'vibe coding' a 'spec-driven development'. Pojďme se podívat, co to znamená a kdy co použít.

Co se pokazí, když vibe-codíte na vážných věcech

Když dáte agentovi vágní zadání na netriviálním úkolu, stane se typicky tohle: agent si domyslí věci, které jste nikdy neřekli. Vybere si knihovnu, kterou v projektu nepoužíváte. Změní datový model, protože se mu 'zdál čistší'. Vyřeší edge case, který jste vůbec nezmiňovali, a ignoruje tři, na kterých vám záleží. Kód vypadá dobře, projde buildem, a vy ho po dvaceti minutách čtení diffu buď zahodíte, nebo strávíte hodinu tím, že ho vracíte tam, kam patří.

Druhý problém je scope. Agent nadšeně refaktoruje, přejmenovává a 'vylepšuje' soubory, kterých se úkol vůbec neměl dotknout. Výsledkem je PR o 40 souborech, kde 35 z nich je šum. Review takového PR je noční můra a přesně tady se rodí bezpečnostní díry a regrese — protože nikdo nemá kapacitu poctivě přečíst 2000 řádků změn.

Jak vypadá dobrý spec pro agenta

Spec není formální dokument na deset stran. Je to jasné, stručné zadání, které agentovi nedovolí si domýšlet to podstatné. Dobrý spec pro implementační úkol obsahuje pět věcí:

• Scope — co přesně se má udělat a čeho se agent NEMÁ dotknout ('uprav jen endpoint X, datový model nech být')
• Constraints — jaké knihovny, konvence a vzory dodržet ('používej existující ApiClient, žádné nové dependencies')
• Acceptance criteria — jak poznáme, že je hotovo ('vrací 400 při chybějícím emailu, 200 s tokenem při úspěchu')
• File-level plán — které soubory se mají změnit a jak zhruba ('nový handler v auth/views.py, test v tests/test_auth.py')
• Očekávání na testy — co má být otestované a jakým stylem ('unit testy na validaci, jeden integrační test happy path')

Kouzlo je v tom, že tenhle spec často nemusíte psát celý ručně. Nechte agenta napsat první draft plánu, přečtěte si ho a opravte. To je mimochodem nejrychlejší způsob, jak odhalit nedorozumění — když agent v plánu napíše 'přidám nové pole do User modelu' a vy víte, že to je zakázané, chytnete to za deset vteřin místo po hodině implementace.

## Ukol: Rate limiting na login endpoint

### Scope
- Uprav POST /api/auth/login/
- NEMEN datovy model ani jine endpointy

### Constraints
- Pouzij existujici Redis klient (core/cache.py)
- Zadne nove dependencies
- Dodrz konvenci trailing slash na URL

### Acceptance criteria
- Max 5 pokusu za minutu na IP
- Pri prekroceni vraci 429 + Retry-After hlavicku
- Uspesny login limit resetuje

### Plan souboru
- core/ratelimit.py — nova utilita
- auth/views.py — aplikuj dekorator na login
- tests/test_ratelimit.py — pokryti

### Testy
- Unit: limit se spusti po 5 pokusech
- Integracni: 429 ma spravnou hlavicku

Smyčka: plán → review → implementace → ověření

Spec-driven development má rytmus. Nejde o to napsat dokonalé zadání a pak zmizet na hodinu. Jde o čtyři fáze s lidskými kontrolními body na správných místech.

1. Plán

Nechte agenta nejdřív jen naplánovat — bez psaní kódu. Většina agentů má dnes explicitní plán mód. Cílem je dostat na stůl seznam kroků a dotčených souborů, než padne jediný řádek implementace.

2. Review plánu

Tohle je nejdůležitější kontrolní bod celého procesu. Čtete plán, ne kód. Plán je desetkrát kratší než výsledný diff a chyby v uvažování se v něm odhalují mnohem snáz. Opravíte scope, doplníte constraint, zamítnete zbytečný refaktor. Teprve pak dáte zelenou.

3. Implementace

Teď agenta pusťte. S dobrým plánem běží tahle fáze do velké míry autonomně — píše kód, spouští testy, opravuje chyby. Vy zatím nemusíte viset nad každým řádkem, protože hranice jste nastavili předem.

4. Ověření

Nakonec ověřujete proti acceptance criteria, ne proti pocitu. Prošly testy, které jste chtěli? Chová se endpoint tak, jak spec říkal? Drží se diff scope? Protože jste kritéria napsali dopředu, review je konkrétní 'ano/ne', ne mlhavé 'hmm, vypadá to OK'.

Kdy je vibe coding pořád v pohodě

Tohle není manifest proti vibe codingu. Freestyle prompting je naprosto legitimní nástroj — jen pro jiný druh práce. Vibe coding dává smysl u prototypů, kde je cílem rychle zjistit, jestli nápad vůbec stojí za to. U throwaway skriptů, které spustíte jednou a zahodíte. U osobních nástrojů, kde jste jediný uživatel i údržbář. U učení nové knihovny, kde chcete rychle vidět, jak věci fungují.

Spec-driven přístup zvolte ve chvíli, kdy platí aspoň jedno z tohohle: kód půjde do produkce, bude na něm pracovat víc lidí, bude se dlouhodobě udržovat, nebo dělá něco, kde chyba bolí — platby, autentizace, data zákazníků. Jinými slovy: čím vyšší cena omylu a čím delší život kódu, tím víc se vyplatí investovat do specu předem.

Závěr: plán je nový prompt

Nejlepší způsob, jak dnes využít coding agenta na vážnou práci, není psát chytřejší jednorázové prompty. Je to naučit se psát dobré specy a řídit smyčku plán → review → implementace → ověření. Agent přebírá vykonávání. Vy si necháváte to, na čem záleží: definici problému, hranice řešení a rozhodnutí, že je hotovo.

Začněte jednoduše. U příštího netriviálního úkolu nechte agenta nejdřív napsat plán, deset minut ho poctivě přečtěte a opravte, a teprve pak ho pusťte stavět. Ten jeden krok navíc před vámi je rozdíl mezi 'AI mi generuje kód, který musím opravovat' a 'AI staví přesně to, co jsem chtěl'.