Jak postupovat při tvorbě aplikace s AI: 6 kroků

Při tvorbě aplikace s AI potřebujete kromě zadání také postup kontroly. Rozšiřování funkcí bez porozumění změnám ztěžuje hledání chyb. Následujících šest kroků navazuje na rizika vibe codingu a ukazuje, jak práci průběžně ověřovat.

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.

Oddělte nezbytný první proces od dalších nápadů. Odložené funkce vyhodnoťte podle používání a obchodní potřeby; jejich počet sám neříká, kolik jich později využijete.

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.

Plánování a revizi lze zadat běžnou instrukcí nebo dostupným režimem nástroje. Dokumentace Claude Code rozlišuje vestavěné příkazy a rozšíření. Příkaz z cizího pluginu nemusí být ve vaší instalaci dostupný. Před použitím ověřte jeho popis, oprávnění a podmínku ukončení; žádný režim neslibuje dokončení libovolné aplikace.

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“

Kvalitu ovlivňuje model, zadání, kontext i harness: dostupné nástroje, pravidla, kontroly a oprávnění. Porovnávejte konkrétní konfigurace na stejných úlohách, ne pouze názvy produktů. Více v článku o agentech a harnessu.

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:

1. Zadejte AI jeden krok, ne celý plán.
2. Nechte ji napsat kód a test k němu, nebo test aspoň popsat.
3. 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č.
4. Commit. Až pak další krok.

Malé ověřené změny usnadňují hledání příčiny chyby i návrat. Pro delší úlohu určete rozpočet, kontroly a podmínky zastavení. Procházející testy ověřují pokryté případy; nejsou důkazem bezchybnosti celé aplikace.

Představte si jednoduchou evidenci zakázek. První krok nemusí být „hotová aplikace“, ale vytvoření jedné zakázky a ověření, že zůstane uložená i po obnovení stránky. Teprve potom přidávejte další stav, filtr nebo roli. Tak snáz poznáte, ve které změně vznikla chyba.

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. Chraňte tajné hodnoty na serveru, validujte nedůvěryhodné vstupy a testujte přístup k datům pro různé role. Administrace potřebuje autentizaci a serverové ověření oprávnění při každé chráněné operaci; neznámá adresa není ochrana. Podrobnosti v článku o vibe codingu.

Krok 5: Co ověřit před produkčním provozem

Funkční průchod na vývojovém počítači nepokrývá provozní situace. Následující oblasti prověřte podle konkrétní aplikace; samotné označení „prototyp“ neříká, které z nich už má vyřešené.

• 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. Ověřte přiměřené omezení požadavků, souborů a vstupů podle rizika zneužití a nákladů.
• Chybové stavy. Vyzkoušejte nedostupnost platby, e-mailu a databáze. Potvrzení musí odpovídat skutečnému stavu; určete opakování, dohled a náhradní postup.
• 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.

Složitost těchto opatření závisí na aplikaci. U každé položky určete řešení, odpovědnost a provedenou zkoušku. Nevyřešené kritické riziko je důvod odložit nasazení.

To, že jde zakázku uložit, ještě neodpovídá na otázku, co se stane při výpadku databáze nebo přihlášení jiného uživatele. Před spuštěním si proto projděte i situace, které při běžném klikání nenastanou.

Krok 6: Kdy si na to vzít profesionála

Malý prototyp s testovacími daty může být vhodné cvičení i pro začátečníka. Počet uživatelů sám neříká, zda zvládnete bezpečný provoz. Odbornou pomoc zvaž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í,
• neumíte ověřit některou kritickou oblast, například oprávnění nebo obnovu dat.

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 ovlivňuje model, zadání, kontext, nástroje i kontroly; posuzujte doložené výsledky.

Nejčastější otázky

Musím umět programovat, abych s AI postavil aplikaci?

Prototyp lze vytvořit i bez předchozí programátorské praxe, ale nasazení vyžaduje odpovídající porozumění a kontrolu. U dat, plateb a oprávnění přizvěte člověka schopného prověřit kód. Krátké vysvětlení architektury nenahrazuje tuto práci.

Který nástroj je lepší, Claude Code, nebo Codex?

Vyzkoušejte dostupné režimy na stejném úkolu. Porovnejte správnost, opravy, nástroje a cenu. Dobrý postup pomáhá, ale neodstraňuje rozdíly ani omezení konkrétní služby.

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ů, dostupné příkazy a rozšíření
• 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