Vibecoding není chaos. Potřebuje jen systém.

Na vibecodingu je dnes zajímavé to, že člověk velmi rychle získá pocit, že mezi nápadem a hotovou aplikací už skoro nic není. Zadáte prompt, něco vznikne, upravíte zadání, vznikne další část a věci se hýbou. To je skvělé. Zároveň je ale velmi snadné dostat se do stavu, kdy každá další změna rozbije předchozí, aplikace začne bobtnat a člověk se v tom přestane orientovat.

Tohle není nic nového. Každý nový programátor si něčím podobným prošel. Na začátku je nadšený, že něco vzniká, zkouší spoustu cest, jak něco naprogramovat, a postupně se dostane do bodu, kdy už není schopen pokračovat. Komplexita začne narážet a každá další funkcionalita rozbíjí tu předchozí. Někdo to vzdá a usoudí, že programování není pro něj. Někdo začne zkoumat, jak se software vlastně vyvíjí.

A přesně do této oblasti se dnes dostává spousta lidí, kteří začali vytvářet aplikace pomocí AI nástrojů.

Proto podle mě dává smysl vrátit se k jednoduchému základu:

Nápad → Specifikace → Plán → Kódování → Testování → Security → Nasazení

Ne proto, abychom si vývoj komplikovali, ale proto, abychom zvládli to, co dnes AI nástroje umožňují dělat mnohem rychleji. Vibecoding podle mě není chaos. Chaos vzniká teprve ve chvíli, kdy chybí systém.

Začněte nápadem, ne kódem

Hned na začátku není potřeba najít nejdokonalejší nástroj. Důležitější je vyzkoušet, co vám nejvíce vyhovuje, a v tom si vybudovat jistotu. Násobně se to potom vrátí. V dnešní době už hlavní nástroje většinou pokryjí všechno, co budete potřebovat. Pak už je potřeba volit spíš podle preferencí a peněženky.

Když máte skvělý nápad, tak hurá na to. Jen ne rovnou do kódu. Sepište si aspoň v několika bodech, co to bude dělat. Jak se do toho dostanou data. Jak z toho budete získávat data zpět. Nakreslete si na papír nebo v počítači základní obrazovky a uvidíte, kolik věcí vás ještě napadne. To je první krok.

Je lákavé ho přeskočit a začít rovnou programovat, protože máte pocit, že přesně víte, co chcete. Jenže právě tady vzniká základ celého řešení. Když to přeskočíte, jen si problémy posunete do další fáze.

Specifikace šetří čas, energii i tokeny

Další částí je vytvoření specifikace.

To znamená vytvořit si popis toho, jak se to bude realizovat a v jakých technologiích. Čím víc práce do toho dáte, tím kvalitnější výsledek dostanete. Ušetříte spoustu slepých uliček a také spálených tokenů.

Není potřeba všechno vymýšlet sám. Ve vašem nástroji můžete zadat například:

„Chci vytvořit aplikaci XY, která bude dělat toto… Navrhni mi nejvhodnější technologii, ukládání dat a postupy běžné a osvědčené.“

Pokud na to chcete jít systematičtěji, je dobré použít nějakou knihovnu nebo framework, který s tím pomůže. Například já používám OpenSpec. Postupně pomocí něj vytvářím jednotlivé části aplikace přes specifikace.

Výsledkem je popis aplikace v markdown souborech, který si můžete projít a také upravovat pomocí AI. Třeba zadáním:

„Navrhl jsi to v Pythonu, ale já bych to chtěl v JavaScriptu. Můžeš mi říct výhody a nevýhody?“

nebo

„Navrhuješ ukládat data do MSSQL, ale já mám malý projekt. Není lepší SQLite nebo MySQL? A proč?“

Všemu, čemu nerozumíte, je vhodné se zeptat a nechat si to vysvětlit. Nenavrhujte systémy rovnou pro tisíce lidí. Nemusíte mít špičkovou technologii. A pokud jste někdy programovali, tak si vyberte jazyk, u kterého aspoň trochu vizuálně poznáte, co dělá.

Proč dělat specifikace a neříkat rovnou „naprogramuj uložení do databáze“? Protože když se vrátíte později, tak veškerá historie z chatu už bude pryč. Ve specifikacích ale zůstane uloženo, co se dělo a proč.

Novou funkcionalitu pak zadáváte třeba takto:

„Podívej se do specifikací, jak ukládáme data do databáze, a navrhni mi novou funkcionalitu XY.“

Můžete odkazovat na konkrétní specifikaci nebo na celou historii návrhu.

Dobře se mi v této fázi osvědčuje i Context7. Když nevíte, jak vytvořit například aplikaci v Next.js, můžete zadat:

„Navrhni mi aplikaci v Next.js dle best practices, use Context7.“

Tento příkaz si stáhne dokumentaci a doporučení a pomůže vám se specifikací. Můžete se ptát na spoustu technologií a v dalších fázích vám pomůže i s konkrétní realizací. Při kódování například přidáte:

„… když nevíš, tak se podívej do dokumentace, use Context7“

A s velkou pravděpodobností dostanete kvalitnější výsledek.

Bez plánu se projekt začne rozpadat

Další část je plán realizace.

Výhodou OpenSpec je, že rovnou připraví i plán, jak se budou specifikace realizovat, respektive v jakém pořadí. A to je důležité. Protože nechcete naprogramovat web, který potřebuje data, ale ještě neexistuje databáze, ze které se budou číst.

Opět není potřeba všechno vymýšlet sám. Stačí zadat například:

„Projdi vytvořené specifikace a navrhni, v jakém pořadí realizovat připravené tasky…“

Na konci je dobré si plán alespoň trochu projít, abyste získali povědomí, co vlastně stavíte.

Na konci této první větší fáze se vyplatí pokládat spoustu otázek:

• Projdi ještě jednou všechny specifikace, jestli jsme na něco nezapomněli.
• Je všechno jasné? Můžeme přistoupit k realizaci?
• Nejsou některé navrhované technologie v konfliktu s ostatními?
• Vidíš nějaké části k vhodnějšímu řešení, než jsme navrhli?

Tady se podle mě opravdu vyplatí strávit hodně času.

Kódování je až další krok

Pak přichází samotné kódování, tedy vytvoření aplikace.

Pak už dává smysl říct nástroji něco jako:

„Vezmi plán a postupuj po jednotlivých specifikacích a realizuj je. Po každé dílčí části spusť test, že je funkční, a následně zaverzuj pomocí git. Pokračuj, dokud nedokončíš všechny specifikace, a pokud narazíš na chybu, pokračuj s další částí, problémy vyřešíme na konci.“

A jdete třeba spát.

Ráno máte spoustu nového kódu a můžete testovat a ladit. Je ale potřeba správně nastavit očekávání. Prostě to nebude dokonalé a většina nebude fungovat napoprvé.

Pak se spustí proces, kdy postupně berete jednotlivé části, tedy specifikace, a zkoušíte, že fungují. Přímo zadáváte, co chcete upravit. Třeba změň velikosti textu, přidej sloupec do tabulky a podobně. Pokud ale zjistíte, že by se aplikace měla chovat úplně jinak, je lepší znovu založit novou specifikaci. Tím si připravíte další sadu vstupů třeba zase na noc. Postupně ladíte, vychytáváte chyby, píšete nové specifikace a dotváříte systém.

I tokeny a modely potřebují strategii

Začíná být dneska téma i cena tokenů, takže pár praktických tipů.

Přepínám v nástroji modely. Plánování dělám ve vyšším modelu, například v GPT-5.4 s vyšším přemýšlením, ale zadávám v promptu:

„Celou specifikaci připravuj tak, že bude realizována v modelu GPT-5.4-mini, který je ekonomičtější.“

Při realizaci pak model přepnu a samotné provedení nechám běžet levněji.

Po každém tasku vytvořím nový chat nebo alespoň komprimuji historii kontextu.

Moje vychytávka je, že mám nainstalovaný Qwen Code a ten je zdarma, když se přihlásíte přes Qwen OAuth. Pak v Codexu zadám:

„vem postupně tasky a nech je realizovat pomocí qwen code. Po dokončení udělej code review a otestuj, že task je funkční a na konci zaverzuj“

Orchestraci přebere vyšší model a zbylý vývoj jede na levném, ale použitelném modelu. Je třeba trochu přemýšlet, jaká data odesíláme, ale u vývoje tam většinou neodcházejí nějaká kritická a citlivá data. Tady je možné využít i lokální model.

Na konci se vyplatí zavolat ještě:

„udělej mi code review jednotlivých změn a navrhni, jak vylepšit naimplementované tasky“

Vrátí doporučení a ta se následně buď realizují rovnou, nebo se znovu zaplánují pomocí OpenSpec.

Když netestujete, nevzniká produkt

Dalším krokem je testování.

Když máte hotovo přes 50 % aplikace, tak je vhodné začít testovat. Tady se opravdu vyplatí provádět to ručně a projít všechny varianty, které může uživatel zadávat. Vyzkoušet, že do místa pro telefon se nedá zadat text. Do e-mailu něco, co neodpovídá e-mailu. To je ta základní validace, na které pak stojí spousta dalších věcí.

Je dobré vymyslet si různé scénáře, kde by to mohlo selhat, a projít je. Pokud to není nástroj jen pro vás, tak je ještě lepší posadit někoho k obrazovce a nechat ho projít celý proces, který jste zamýšleli, a jen ho tiše sledovat, jak aplikaci používá.

Výkřiky typu „ty to nevidíš?“ nebo „jsi slepý/á?“ nepomáhají ani testování, ani domácí pohodě.

K testování je dobré použít i připravené skilly. Třeba Playwright. Pomůže se spoustou věcí, které člověk bez vývojářského zázemí složitě dohledává. Když nevíte, jak ho použít, stačí zadat:

„vysvětli mi, jak použít skill Playwright“

A nástroj vás navede.

Když netestujete, nevzniká produkt. Jen generujete další kód.

Bezpečnost nepatří až na konec

I když aplikaci používáte jen sami na svém počítači, časem vás může napadnout, že by bylo fajn dát ji někam na internet. A v tu chvíli může přijít spousta starostí. Proto se vyplatí udělat aspoň základní bezpečnostní kontrolu.

Můžete použít například připravené skilly z marketplace. Zadání může být třeba:

„Použij skill … a zjisti bezpečnostní problémy aplikace. Seřaď je dle závažnosti a vysvětli mi rizika, když je neodstraním.“

Výsledek, který dostanete, je pak vhodné zaplánovat pomocí specifikací. Třeba zadáním:

„Použij OpenSpec propose a navrhni mi odstranění jednotlivých bezpečnostních problémů“

A pak to nechat zrealizovat.

Proč dělat i bezpečnostní změny přes specifikace a neříkat jen „oprav chybu“? Protože když se vrátíte později, veškerá historie v chatu už zmizela, ale ve specifikacích zůstane uloženo, co se dělalo a proč.

Důležité změny patří do systému, ne do jednoho zapomenutého chatu.

Nasazení je okamžik pravdy

Poslední částí je nasazení.

To je chvíle, kdy už nestačí, že „to funguje u mě“. Aplikace je skoro dokončená a je čas ji nasadit a dát k dispozici uživatelům.

Pokud jde o jednoduchou věc, třeba web a podobně, tak je nejjednodušší to nahrát přes FTP a webové rozhraní hostingu včetně databáze. Pokud jsou to pro vás sprostá slova, tak se prostě zeptejte:

„Co je FTP?“

„Jak nahrát data na hosting?“

Agent vás tím provede.

Umí to dnes často i sám. Zadání typu:

„Tady máš přístupové údaje a nahraj tam projekt. Pak otestuj, že vše funguje.“

Je u jednodušších věcí už docela realistické.

I tady ale dává smysl pochopit aspoň základy. Třeba jak používat .env pro skrytí hesel a klíčů. Zní to jako detail, ale později šetří hodně starostí.

Pokud to myslíte vážněji, tak se dříve nebo později vyplatí podívat i na Docker.

Velmi zjednodušeně řečeno je kontejner malý počítač, který má v sobě nainstalováno všechno, co budete potřebovat pro provoz své aplikace. Tento kontejner pak můžete spustit u sebe na počítači nebo rovnou na hostingu. Nahrajete ho do větších cloudových platforem a hostingů, jako jsou AWS, Azure, Hetzner a další.

Výhoda je v tom, že aplikaci oddělíte od vlastního počítače a okolí. Tím lépe řídíte, ke kterým datům má přístup a co všechno může ovlivnit. I to je základní bezpečnostní benefit.

AI mění rychlost. Principy dobrého vývoje ale zůstávají.

Toto je krátký popis workflow vývoje aplikací, který se dá dobře použít, pokud to s vibecodingem myslíte vážně. Ušetří vám to alespoň základní starosti s problémy.

Nestačí mít dobrý nápad. Nestačí mít dobrý prompt. Nestačí ani to, že AI umí psát kód. Rozdíl vzniká ve chvíli, kdy začnete řídit celý proces od nápadu až po provoz.