VibeCoding je opojný. Otevřete editor, napíšete pár promtů a před očima vám roste aplikace. Cítíte se jako dirigent orchestru, který hraje bez not. Ale pak to přijde. Po hodině se orchestr rozladí. Oprava tlačítka rozbije databázi. AI začne halucinovat funkce, které jste nikdy nechtěli. A vy zjistíte, že místo dirigování se snažíte uhasit požár v hořícím domě, který jste sami postavili. Pokud tento pocit znáte, vítejte v klubu. Je čas vyměnit improvizaci za systém.

Problém: Když vibeCoding narazí do zdi

Všichni jsme tam byli. Začátek je euforický, ale s rostoucím počtem řádků kódu se efektivita propadá. Bez pevného systému naráží „pocitové programování“ na pět kritických bariér:

  1. Amnézie kontextu: AI si nepamatuje vaše myšlenkové pochody z předvčerejška. Jakmile kontext chatu přeteče, model začne vařit z vody a ignorovat dřívější rozhodnutí.
  2. Smyčka zkázy (Doom Loop): Požádáte o opravu chyby A, AI ji opraví, ale vytvoří chybu B. Opravíte B, vrátí se A. Kód se mění v křehkou stavebnici, na kterou se bojíte sáhnout.
  3. Architektonické špagety: Protože neexistuje plán, nové funkce se „lepí“ tam, kde je zrovna místo. Výsledkem je neudržitelný slepenec bez jasné struktury.
  4. Tokenová inflace: Neustále kopírujete a vkládáte celé soubory zpět do chatu, abyste AI připomněli, jak projekt vypadá. Je to drahé, pomalé a frustrující.
  5. Iluze hotového: „AI to nějak dodělá.“ Nedodělá. Detaily, jako jsou validace vstupů nebo chybové stavy, se v obecných promptech ztratí a vybuchnou až v produkci.

Co je SpecKit: Váš nový šéfarchitekt

GitHub Spec Kit (a metodologie Spec-Driven Development – SDD) je lék na tento chaos. Není to jen nástroj, je to změna myšlení. Místo toho, abyste AI nutili psát kód přímo z hlavy, necháte ji nejprve vygenerovat specifikaci.

Kód se v SDD stává až druhořadým produktem. Primárním artefaktem je „živá dokumentace“ – sada souborů, které přesně definují, CO se má stát, dříve než se řeší JAK.

Čtyři pilíře SpecKitu (Artefakty)

SpecKit stojí na čtyřech dokumentech, které drží AI na uzdě:

  1. Ústava (constitution.md): Nezpochybnitelné zákony vašeho projektu.
    • Příklad: „Vždy používáme TypeScript. UI knihovna je Tailwind. Zákaz používání typu any.“
  2. Specifikace (spec.md): Produktové zadání. Říká CO stavíme a PROČ.
    • Obsah: Uživatelské příběhy (User stories), datový model, akceptační kritéria. Neřeší implementaci.
  3. Plán (plan.md): Technické řešení. Říká JAK to postavíme.
    • Obsah: Výběr knihoven, struktura složek, API endpointy, názvy funkcí.
  4. Úkoly (tasks.md): Jízdní řád. Rozpad plánu na atomické kroky.
    • Obsah: Seškrtatelný seznam kroků pro AI (nebo pro vás).

Arzenál SpecKitu: Příkazy pod lupou

Zatímco artefakty jsou „papíry“, slash příkazy (slash commands) jsou „nástroje“, kterými s nimi pracujete. SpecKit nabízí více než jen generování textu – má vestavěné nástroje pro kontrolu kvality, které fungují jako váš osobní seniorní kolega.

1. Jádro procesu (The Core Loop)

Těmito příkazy posouváte projekt kupředu:

  • /speckit.constitution: Vytvoří nebo aktualizuje základní pravidla hry. Použijete na začátku projektu nebo při změně tech stacku.
  • /speckit.specify: Hlavní kreativní nástroj. Na základě vašeho (i vágního) popisu vygeneruje profesionální spec.md.
  • /speckit.plan: Architekt. Vezme specifikaci a vymyslí technické řešení v plan.md.
  • /speckit.tasks: Projektový manažer. Rozseká plán na malé, stravitelné úkoly v tasks.md.
  • /speckit.implement: Dělník. Vezme jeden úkol a napíše kód.

2. Záchranné brzdy a kontrola kvality (QA)

Tyto příkazy odlišují SpecKit od obyčejného chatování. Použijte je, když chcete mít jistotu.

  • /speckit.clarify (Ďáblův advokát):
    • Co dělá: Přečte vaši specifikaci a klade vám nepříjemné otázky. „Co se stane, když uživatel nemá práva?“, „Jak řešíme mobilní zobrazení?“
    • Proč ho chtít: Odhalí nejasnosti dříve, než se promění v drahé bugy.
  • /speckit.analyze (Konzistence):
    • Co dělá: Zkontroluje, zda do sebe vše zapadá. Neodporuje Plán Ústavě? Nechybí v Úkolech něco ze Specifikace?
    • Proč ho chtít: Aby AI v zápalu boje nezapomněla na vaše vlastní pravidla.
  • /speckit.checklist (Jednotkové testy pro angličtinu):
    • Co dělá: Vygeneruje sadu kontrolních otázek pro specifické oblasti (UX, Bezpečnost, Přístupnost), které musíte ve specifikaci „odškrtnout“.
    • Proč ho chtít: Protože člověk snadno zapomene na edge-cases, ale checklist nezapomíná.

Workflow v praxi: Od nápadu k hotovému kódu

Zapomeňte na chaotické chatování. Zde je proces v 9 krocích, který zaručí výsledek.

Fáze 1: Definice (Specify)

1. Inicializace Ústavy

  • Cíl: Nastavit mantinely, aby AI každých pět minut neměnila framework.
  • Akce: Použijte /speckit.constitution nebo ručně vytvořte constitution.md. Napište tam své „hard skills“ preference.
  • Hotovo: Máte soubor, který říká „Jsme Next.js projekt“ a AI to respektuje.

2. Brain Dump (Hrubý nápad)

  • Cíl: Dostat myšlenku z hlavy.
  • Akce: Otevřete nový soubor nebo chat a prostě pište. „Chci aplikaci na úkoly, kde můžu dávat štítky.“
  • Hotovo: Máte odstavec textu, který dává smysl člověku.

3. Generování Specifikace

  • Cíl: Přetavit myšlenku do strukturovaného dokumentu.
  • Akce: Použijte příkaz /speckit.specify s vaším nápadem: „Na základě mého nápadu a Ústavy vytvoř spec.md.“
  • Hotovo: Máte soubor se sekcemi Core Flow, Data Model, Non-Functional Requirements.

4. Kritická revize a kontrola (QA)

  • Cíl: Vychytat chyby levně (v textu) a odhalit slepá místa.
  • Akce:
    1. Spusťte /speckit.clarify. Odpovězte na otázky AI, které upřesní zadání.
    2. Spusťte /speckit.checklist pro generování kontrolních otázek (např. „Ošetřili jste chybové stavy sítě?“).
    3. Spusťte /speckit.analyze pro ověření, že specifikace neodporuje Ústavě.
  • Hotovo: Soubor spec.md je neprůstřelný a podepíšete ho vlastní krví. Je to závazné zadání.

Fáze 2: Plánování (Plan)

5. Generování Plánu

  • Cíl: Vymyslet architekturu.
  • Akce: Příkaz /speckit.plan: „Podle spec.md a constitution.md vytvoř technický plan.md.“
  • Hotovo: Máte seznam souborů, které vzniknou, a popis funkcí. Vidíte, že AI chce použít localStorage místo databáze, a souhlasíte.

6. Generování Úkolů

  • Cíl: Rozbít slona na kousky.
  • Akce: Příkaz /speckit.tasks: „Rozděl plan.md do kroků v tasks.md.“
  • Hotovo: Máte checklist. 1. Setup projektu, 2. Vytvoření typů, 3. UI komponenta…

Fáze 3: Stavba (Implement)

7. Implementace po krocích

  • Cíl: Psát kód, který funguje na první dobrou.
  • Akce: Spusťte /speckit.implement nebo dejte AI první úkol z tasks.md ručně.
  • Hotovo: Kód je napsaný. Testy procházejí (pokud jste je chtěli).

8. Verifikace a Loop

  • Cíl: Udržet kurz.
  • Akce: Zkontrolujte výsledek. Odškrtněte úkol. Jděte na další.
  • Hotovo: Celý tasks.md je hotový.

9. Úklid a Dokumentace

  • Cíl: Nechat čisto pro příště.
  • Akce: Aktualizujte spec.md, pokud se něco změnilo. Smažte dočasné větve.
  • Hotovo: Projekt je ve stavu, kdy ho může převzít kolega (nebo vaše budoucí já).

Mini-ukázka: ZenTodo s Tagy

Představme si jednoduchou to-do aplikaci. Jak by vypadaly výstupy SpecKitu?

Rozsah (ze spec.md):

Aplikace umožňuje uživateli vytvářet úkoly a přiřazovat jim barevné štítky (tagy). Data jsou perzistentní v localStorage prohlížeče. Backend neexistuje.

Akceptační kritéria (ze spec.md):

  • Uživatel může k úkolu přidat štítek zadáním textu a stiskem Enter.
  • Štítek se zobrazí jako „pill“ badge vedle názvu úkolu.
  • Kliknutím na křížek u štítku se štítek z úkolu odstraní.

Krajní případ (ze spec.md):

  • Pokud uživatel zadá štítek, který už úkol má (case-insensitive, např. „Práce“ a „práce“), aplikace to ignoruje a nevytvoří duplicitu. Input pole se pouze vyprázdní.

Test Scénář (z plan.md / tasks.md):

  1. Vytvoř úkol „Koupit mléko“.
  2. Klikni na „Přidat štítek“.
  3. Napiš „Nákup“ a potvrď.
  4. Refreshni stránku (F5).
  5. Ověř, že úkol „Koupit mléko“ má stále štítek „Nákup“.

Vidíte ten rozdíl? Místo „udělej mi tagy“ máte přesný návod. AI nemůže uhnout.

Antipatterny: Jak to nepokazit

I se SpecKitem se dá narazit, pokud sklouznete zpět ke starým zvykům.

  1. Vibe it out (Obcházení specifikace):
    • Jak to poznáte: „Jen rychle opravím tuhle barvu v CSS přímo v kódu.“
    • Co s tím: Zastavte se. Je to v constitution.md (design systém)? Je to ve spec.md? Pokud ne, aktualizujte nejdřív dokumenty.
  2. Božský prompt (God Prompt):
    • Jak to poznáte: Snažíte se narvat specifikaci, plán i kontext do jedné zprávy.
    • Co s tím: Držte fáze oddělené. Specifikace zvlášť. Plán zvlášť. Implementace po kouskách.
  3. Implementace ve Specifikaci:
    • Jak to poznáte: Ve spec.md píšete: „Použij React useState hook.“
    • Co s tím: Špatně. Specifikace je CO (uživatel vidí stav). Plán je JAK (useState). Nechte AI vybrat nástroj v fázi Plánu, nebo ho definujte v Ústavě.
  4. Ignorování Ústavy:
    • Jak to poznáte: AI začne používat knihovny, které nesnášíte (např. jQuery v roce 2025).
    • Co s tím: Vaše constitution.md je slabá. Přitvrďte pravidla. „ZÁKAZ externích CSS knihoven mimo Tailwind.“
  5. Kovboj bez commitů:
    • Jak to poznáte: Máte 4 hodiny práce bez jediného uložení do Gitu.
    • Co s tím: SpecKit workflow přirozeně svádí k commitování po každém splněném úkolu z tasks.md. Dělejte to.
  6. Akceptování prvního návrhu:
    • Jak to poznáte: AI vygeneruje specifikaci a vy hned řeknete „OK, implementuj“.
    • Co s tím: Nikdy nevěřte prvnímu draftu. Vždy po AI chtějte, ať se zamyslí nad chybami (/speckit.analyze nebo prostě „Kde jsou slabá místa tohoto návrhu?“).

Startovací balíček pro váš první SpecKit projekt

Nečekejte na velký projekt. Zkuste to hned na malé utilitě.

Checklist pro začátek

  1. [ ] Mám nainstalovaný editor s AI (Cursor, VS Code + Copilot).
  2. [ ] Mám vytvořenou složku .spec nebo kořen projektu.
  3. [ ] Vytvořil jsem constitution.md (stačí 5 bodů).
  4. [ ] Mám nápad sepsaný v jedné větě.
  5. [ ] Vygeneroval jsem spec.md a přečetl jsem ho.
  6. [ ] Vygeneroval jsem plan.md a dává technicky smysl.
  7. [ ] Mám tasks.md rozpadlý na kroky kratší než 10 minut práce.
  8. [ ] Mám Git repozitář (init).
  9. [ ] Jsem připraven nepsat kód, ale číst kód.
  10. [ ] Mám kávu, skleničku vína nebo čaj (volitelné, ale doporučené).

Rychlá šablona (constitution.md)

# Ústava Projektu (Project Constitution)

## 1. Hodnoty a Cíle
**Účel**: [DOPLŇTE VĚTU O CÍLI PROJEKTU].
**Definice úspěchu**: Kvalita a udržitelnost mají přednost před rychlostí implementace. Kód musí být srozumitelný pro juniora i po 6 měsících.
**Rozsah**: Projekt se soustředí na [HLAVNÍ FUNKCE]. Vše ostatní je "nice-to-have" a musí být schváleno.

## 2. Architektonické Principy
**Jednoduchost před složitostí**: Volíme nejjednodušší řešení, které splňuje požadavky. Abstrakce zavádíme až tehdy, když se kód opakuje potřetí (Pravidlo tří).
**Škálování s rozumem**: Navrhujeme pro aktuální potřeby, ne pro miliony teoretických uživatelů. Rozhraní (API) však musí být čistá.

## 3. Standardy Kvality
**Testování**: Testujeme kritické cesty (to, co vydělává peníze nebo chrání data). Nebazírujeme na 100% pokrytí banalit.
**Udržitelnost**: Preferujeme explicitní (ukecaný) kód před "chytrými" jednořádkovými triky.
**Ošetření chyb**: Uživatel nesmí nikdy vidět "bílou smrt". Aplikace musí selhat elegantně a nabídnout cestu ven.

## 4. Uživatelská Zkušenost (UX)
**Srozumitelnost**: Nástroj, který dělá jednu věc skvěle, je lepší než ten, který dělá deset věcí průměrně.
**Odezva**: Uživatel musí vždy vědět, co se děje. Dlouhé operace AI musí mít indikátor průběhu a možnost zrušení.

## 5. Vývojové Praktiky (Tech Stack)
**Závislosti**: Každá externí knihovna je závazek. Přidáváme je jen s jasným zdůvodněním.
**Dokumentace**: Rozhodnutí "proč jsme to udělali takto" je důležitější než "jak to funguje".
**AI Prompting**: Přesnost a kvalita promptu je důležitější než jeho stručnost.

## 6. Rozhodovací Proces
**Při pochybnostech se ptej**:
1. Řeší to skutečný problém, který máme teď?
2. Jaká je cena údržby tohoto řešení?
3. Existuje hloupější (jednodušší) alternativa?

Rytmus práce

SpecKit není vodopád. Je to spirála.

  1. První průchod: Spec -> Plan -> Code (MVP).
  2. Druhá iterace: Změna ve Spec (nová feature) -> Update Plan -> Update Code.
  3. Refactoring: Update Constitution (nové pravidlo) -> Refactor Code.

Začněte pomalu. První pokus bude drhnout. U druhého už nebudete chtít pracovat jinak. Vítejte ve světě, kde AI kód jen nevyplivne, ale skutečně inženýrsky postaví.

Publikováno: 15 prosince, 2025 / Kategorie: Vibecoding /