Aplikace s pomocí AI stavím denně – vlastní nástroje, aplikace pro klienty i cvičné projekty na kurzu. A jednu věc vidím pořád dokola: lidé, kteří s Claude Code nebo Codexem začínají, skočí rovnou do psaní kódu. „Udělej mi aplikaci na evidenci zakázek." Za hodinu něco běží, za den to má dvacet funkcí a za týden se to nedá opravit. O tom, jaké chyby při tom vznikají, jsem psal v článku Vibe coding: 7 chyb amatérů. Tenhle článek je jeho druhá půlka – ne co nedělat, ale jak postupovat, aby z toho byla aplikace, kterou lze předat, provozovat a rozvíjet.
Správný postup s AI nástroji má šest kroků: 1) zadání a rozsah včetně toho, co aplikace nedělá, 2) návrh a jeho kritika ještě před prvním řádkem kódu (plánovací režim, revize návrhu), 3) plán rozdělený na malé kroky s testy, 4) review kódu a bezpečnostní checklist, 5) produkční příprava – monitoring, zálohy, limity, chybové stavy, práva, náklady na API a aktualizace závislostí, 6) rozhodnutí, kdy si vzít profesionála. Nástroje jako Claude Code nebo Codex nejsou „jen model": jsou to model plus struktura pravidel, nástrojů a kontrol kolem něj – a právě ta struktura rozhoduje o kvalitě výsledku.
Krok 1: Zadání a rozsah – hlavně to, co aplikace nedělá
Nejlepší zadání pro AI je stejné jako nejlepší zadání pro člověka: kdo aplikaci používá, jaký problém řeší, jak poznáte, že funguje. Napište to na jednu stránku a přidejte tři věci, které lidé vynechávají:
- Co aplikace nedělá. „Nedělá fakturaci, nedělá platby, nemá mobilní aplikaci." Bez téhle věty vám AI ochotně přidá všechno, co ji napadne, a každá funkce navíc je další místo, kde se to rozbije.
- Kdo k čemu smí. Role a oprávnění popsané předem, ne domyšlené v půlce práce.
- Data. Jaké entity existují (zakázka, klient, položka), co je povinné, co se nesmí ztratit.
Rozsah pište pesimisticky. První verze má dělat jednu věc pořádně; každou další si zapište do seznamu „později". Zjistíte, že polovinu z něj nikdy nebudete potřebovat.
Krok 2: Návrh a jeho kritika – ještě bez kódu
Tady se rozhoduje o většině pozdějších problémů. Než necháte AI psát, nechte ji navrhnout: strukturu dat, hlavní obrazovky, tok jedné typické operace, kde co běží. A pak ten návrh nechte zkritizovat – ideálně jiným kontextem, než který ho napsal.
Moderní AI nástroje na to mají přímo režimy a příkazy. V Claude Code je plánovací režim (/plan), ve kterém nástroj prochází projekt a připravuje postup, aniž by měnil soubory; cílově orientovaný režim (/goal), kde definujete měřitelnou podmínku hotovo a nástroj na ní pracuje, dokud není splněná nebo se neukáže jako nesplnitelná; příkazy pro revizi kódu (/code-review, /security-review); a rozšíření skrz pluginy – například kritika návrhu rozhraní typu /design:design-critique, která projde návrh z pohledu hierarchie, použitelnosti a konzistence. Codex má obdobné nastavení – míru samostatnosti, schvalování změn, revizi – ale přesné názvy se mění s verzemi, takže si je ověřte v aktuální dokumentaci svého nástroje.
Podstata je stejná bez ohledu na nástroj: oddělte fázi „přemýšlej a navrhni" od fáze „piš" a mezi ně vložte kritiku. Kritika návrhu je levná; kritika hotové aplikace je drahá.
Krátce o „harnessu"
Když se lidé diví, proč jim stejný model dává v různých nástrojích tak rozdílné výsledky, odpověď je harness. Claude Code, Codex a podobné nástroje nejsou jen model, ke kterému píšete. Je to model plus struktura kolem něj: pravidla projektu, které si nástroj načte, dostupné nástroje (čtení a úprava souborů, spouštění testů, prohlížeč), paměť napříč sezením, kontroly a oprávnění, kdo co smí spustit. Tahle struktura rozhoduje o kvalitě víc, než by člověk čekal – dva lidé se stejným modelem a různým harnessem dostanou dvě různé aplikace. Do detailu tady nepůjdu (je to know-how, které stavím měsíce a učím na kurzech), ale princip si odneste: investujte do pravidel a kontrol kolem modelu, ne jen do lepších promptů. Víc o tom v článku AI agenti a harness.
Krok 3: Plán → malé kroky → testy
Ze schváleného návrhu vznikne plán: očíslované kroky, každý s popisem „hotovo znamená". Krok má být tak malý, aby se dal ověřit během minut – jedna obrazovka, jedna operace, jedna migrace databáze. Pak pracujete v cyklu:
- Zadejte AI jeden krok, ne celý plán.
- Nechte ji napsat kód a test k němu, nebo test aspoň popsat.
- Spusťte to. Přečtěte diff – nemusíte rozumět každému řádku, ale musíte vědět, co se změnilo a proč.
- Commit. Až pak další krok.
Proč tak pedantsky? Protože AI mění kód rychle a plošně a jediný spolehlivý způsob, jak udržet kontrolu, je mít po každém kroku ověřený stav, ke kterému se lze vrátit. Cílově orientované režimy typu /goal s tímhle pomůžou – zadáte „všechny testy procházejí a lint je čistý" a nástroj iteruje, dokud to neplatí – ale fungují jen tehdy, když testy existují a když je hodnotí něco jiného než model, který kód psal.
Krok 4: Review a bezpečnostní checklist
Než cokoli nasadíte, dva průchody:
Review kódu. Nechte AI projít vlastní práci jinýma očima – v jiném kontextu, s jinou instrukcí („hledej chyby, ne potvrzuj, že je to dobře"). Nástroje na to mají příkazy; důležitější než konkrétní příkaz je, že reviewer nesmí být tentýž kontext, který kód psal. Když máte po ruce člověka, který programuje, je to nejlépe investovaná hodina celého projektu.
Bezpečnostní checklist. Nebudu opakovat detaily z článku o chybách vibe codingu, jen připomenu položky, které si před nasazením odškrtněte: tajné klíče mimo kód, validace každého vstupu na serveru, přístupová pravidla databáze zapnutá a otestovaná, přihlášení a role ověřované při každém požadavku, závislosti z ověřených zdrojů, admin mimo veřejnou adresu.
Krok 5: Proč většina „hotových" vibe-code aplikací není připravená na produkci
Aplikace, která funguje na vašem počítači, není aplikace připravená pro provoz. Tohle je seznam věcí, které v prototypech téměř nikdy nejsou – a bez kterých vám aplikace jednou v noci přestane fungovat a nikdo se to nedozví:
- Monitoring a logy. Když nastane chyba, dozvíte se to vy, nebo až zákazník? Aplikace musí hlásit chyby a mít čitelné logy, ke kterým se dostanete.
- Zálohy a obnova. Nejen „zálohujeme", ale „vyzkoušeli jsme, že se ze zálohy dá obnovit". Neotestovaná záloha je přání.
- Limity. Omezení počtu požadavků na endpoint, velikosti nahrávaných souborů, délky vstupů. Bez nich stačí jeden robot a účet za infrastrukturu vystřelí.
- Chybové stavy. Co se stane, když nejde platební brána, když e-mail neodejde, když databáze neodpoví? Prototyp v takové chvíli spadne nebo tiše ztratí data. Produkční aplikace to zaznamená, zopakuje nebo srozumitelně oznámí.
- Přístupová práva a prostředí. Oddělené testovací a ostré prostředí, oddělené klíče, žádné sdílené účty.
- Náklady na API. Aplikace volající AI nebo jiné placené služby potřebují rozpočtové stropy a upozornění. Bez nich se první úspěšný marketing změní v překvapivou fakturu.
- Aktualizace závislostí. Knihovny stárnou a objevují se v nich díry. Někdo je musí sledovat a aktualizovat – a to znamená mít testy, které po aktualizaci řeknou, jestli něco neprasklo.
Nic z toho není technicky složité. Je to práce, která se u prototypu přeskočí, protože „to funguje". Před nasazením si tenhle seznam projděte položku po položce a u každé napište, jak je vyřešená. Kde není odpověď, není hotovo.
Krok 6: Kdy si na to vzít profesionála
Ne vždy. Interní nástroj pro tři lidi, kalkulačku na web nebo prototyp k ověření nápadu zvládnete sami – a doporučuji to zkusit, přesně tohle učím na kurzu vibe codingu. Profesionála si vezměte, když:
- na aplikaci závisí příjem firmy nebo data zákazníků,
- potřebujete platby, integrace na účetnictví či sklad, více rolí,
- ji bude používat víc lidí, než dokážete osobně obvolat, když se něco pokazí,
- jste si u seznamu z kroku 5 u víc než dvou položek museli napsat „nevím".
Nemusí to znamenat, že vám ji celou postaví. Často stačí, když navrhne architekturu, nastaví strukturu projektu a kontroly a vy pak s AI stavíte v mantinelech, které drží. Přesně tak stavím aplikace na míru – a část klientů si po předání rozvíjí aplikaci s AI sama, protože ví, jak je postavená.
Shrnutí
- Začněte zadáním na jednu stránku včetně toho, co aplikace nedělá, jaké má role a jaká data.
- Návrh nechte vzniknout a zkritizovat před prvním řádkem kódu – používejte plánovací režim a nezávislou revizi.
- Pracujte v malých krocích: jeden krok, kód + test, přečíst diff, commit.
- Před nasazením review v jiném kontextu a bezpečnostní checklist.
- Produkce znamená monitoring, zálohy s ověřenou obnovou, limity, ošetřené chybové stavy, oddělená prostředí, stropy nákladů a údržbu závislostí.
- Kvalitu určuje harness – pravidla, nástroje a kontroly kolem modelu – víc než samotný prompt.
Nejčastější otázky
Musím umět programovat, abych s AI postavil aplikaci?
Na prototyp nebo interní nástroj ne. Musíte ale rozumět tomu, co jste postavili: jak tečou data, kde co běží, kde jsou logy. To není programování, to je hodina vysvětlování – a přesně o ni jde na kurzu. Na aplikaci, na které stojí byznys, už chcete někoho, kdo kód umí číst.
Který nástroj je lepší – Claude Code, nebo Codex?
Oba jsou schopné a oba se rychle mění. Důležitější než volba nástroje je postup: oddělený návrh, malé kroky, testy, nezávislá revize. Špatný postup zkazí výsledek v jakémkoli nástroji; dobrý postup funguje ve všech.
Jak poznám, že je aplikace připravená na produkci?
Projděte seznam z kroku 5 a u každé položky napište konkrétně, jak je vyřešená: kdo dostane upozornění při chybě, kdy jste naposledy obnovili zálohu, jaké jsou limity, co se stane při výpadku platební brány. Kde chybí odpověď, není hotovo.
Kdy se vyplatí zavolat vývojáře?
Když na aplikaci závisí příjem nebo data zákazníků, když potřebujete platby a integrace, nebo když ji bude používat víc lidí, než dokážete osobně obsloužit. Často stačí, když profesionál navrhne strukturu a kontroly – a vy pak s AI stavíte v bezpečných mantinelech.
Zdroje a odkazy
- Claude Code – přehled příkazů –
/plan,/goal,/code-review,/security-reviewa další - OpenAI Codex CLI – lokální kódovací agent od OpenAI
- Vibe coding: 7 chyb, kvůli kterým amatérské AI aplikace končí průšvihem – čemu se vyhnout