Produkt vytvořený s AI: jak ho bezpečně vylepšovat

Více o práci s modely se dozvíte v dokumentaci Ailoot.

Proč údržba produktu vytvořeného s AI začíná až po spuštění?#

Večer jste vytvořili aplikaci, zveřejnili odkaz a poslali ho přátelům. Funguje. O týden později se objeví první skutečný uživatel, klikne na něco špatným způsobem a polovina funkcí přestane fungovat. Požádáte Claude, aby to opravil — opraví jednu věc a rozbije jinou. Zní vám to povědomě?

A právě tehdy vyvstane hlavní otázka: co dělat po spuštění produktu, když opadne euforie z prvního funkčního prototypu a vy se o něj stále musíte nějak starat? Dalo by se tomu říkat vibe coding pro dospělé. Tvorba znamená nadšení a rychlost. Údržba vyžaduje chladnou hlavu: rozumíte tomu, co měníte, a máte to pod kontrolou. V této druhé části většina lidí selhává, protože se na ni nikdo nepřipravuje.

Jedna oborová studie analyzovala více než milion změn kódu od 2 444 týmů a spočítala, kam skutečně míří peníze utracené za vývoj s AI. Tady je přehled:

Průvodce „Skryté náklady vibe codingu“ vysvětluje tato čísla podrobněji. Tam šlo o to, za co platíte. Tady je otázka jiná: 44 centů z každého dolaru padne na opravy chyb — a celý tento článek je o tom, jak zabránit tomu, aby tento podíl rostl. Práce, která ho drží na uzdě, se nazývá údržba.

Rozdíl mezi člověkem, který dělá vibe coding pro dospělé, a člověkem, který jen hlídá neuronovou síť, se projeví po spuštění. Tomu prvnímu roste kódová základna, dělá vylepšení a nic se nerozbije. Produkt toho druhého se za měsíc změní v děravou konstrukci, na kterou se bojí sáhnout. Dále vysvětlím, jak se dostat do první skupiny.

Jaké problémy mohou nastat po spuštění produktu vytvořeného s AI?#

Jde o veřejné postmortemy skutečných produktů vytvořených pomocí AI, s čísly a daty. Představte si je jako mapu minového pole — každá mina už někomu vybuchla a je známo, jak se jí vyhnout.

Všech pět případů má stejnou hlavní příčinu. Ve výchozím nastavení AI zařídí, aby věci fungovaly právě teď, ne aby byly bezpečné za měsíc při zátěži. Při vývoji na vlastním počítači rozdíl nevidíte. Projeví se, až se objeví první cizí člověk se zlými úmysly.

Problém není v tom, že kód nepíšete ručně — takto pracuje mnoho lidí. Problém je, když se nikdo nezeptá: „Je databáze zabezpečená?“ Dále vám ukážu zadání, které tuto otázku položí za vás.

První bezpečnostní síť: git a návrat k tomu, „jak to bylo včera“#

Když Claude něco rozbije, potřebujete tlačítko „vrátit to do stavu, v jakém to bylo včera“. Technicky se mu říká git a je jednodušší, než se zdá.

Neprogramátor potřebuje rozumět třem pojmům:

1. Repozitář — složka projektu uložená v cloudu (obvykle na GitHubu). Kopie veškerého vašeho kódu, která není jen ve vašem počítači.
2. Commit — bod, ke kterému se můžete vrátit. V podstatě kódu říkáte: „ulož tento stav“. Každý commit je značka, ke které se můžete vrátit.
3. Deploy — nasazení. Kód byl místně ve vašem počítači a fungoval jen vám. Deploy ho odešle na externí server, aby fungoval pro všechny.

Dokud máte aktuální body návratu, můžete jakoukoli poruchu vrátit jedinou větou. Doslova.

Něco jsem rozbil — včera všechno fungovalo, ale dnes ne. Najdi poslední commit, kdy bylo všechno v pořádku, ukaž mi, co se od té doby změnilo, a vrať projekt do tohoto stavu.

Dvě pravidla, která je třeba zavést hned, než produkt uvidí další lidé:

• Repozitář musí být soukromý. Ne veřejný. Jinak si kdokoli může přečíst váš kód a vše, co obsahuje.
• Přidejte soubor s tajnými údaji do seznamu ignorovaných souborů. Klíče, hesla a přihlašovací údaje k databázi patří do samostatného souboru (obvykle .env) a tento soubor se nikdy nesmí dostat do repozitáře. Přidejte do .gitignore řádek pro .env a tajné údaje zůstanou u vás.

Samostatný průvodce se věnuje bezpečnému vracení změn v Claude Code: Jak vrátit změny v Claude Code. Bez bodů návratu kráčíte po laně bez záchranné sítě a dříve nebo později spadnete.

Co příkaz /rewind vrátí a co ne?#

Claude Code pořizuje snímek stavu před každou změnou, kterou provede. Příkaz /rewind (nebo dvojí stisknutí Esc) vrátí soubory i konverzaci do zvoleného bodu. Je to praktické: pokud jste před pěti minutami rozbili funkci, můžete se vrátit o pět minut zpět.

Je tu ale háček, kvůli kterému začátečníci přicházejí o data. /rewind nevrací všechno:

Anthropic to říká jasně: snímky jsou místní tlačítko „vrátit zpět“, zatímco git je trvalá historie. Snímky doplňují správu verzí, ale nenahrazují ji.

Praktické poučení pro neprogramátora: /rewind vás zachrání před situací „Claude právě rozbil funkci“. Pokud ale stihl smazat řádek databáze nebo nahrát kód do cloudu, vrátit ho dokáže jen git a záloha databáze. Mějte proto obě vrstvy: snímky pro rychlé návraty, commity pro trvalou historii projektu.

Jak vylepšovat produkt, aniž byste rozbili to, co už funguje?#

Každý druhý člověk se do tohoto kolotoče dostane. Požádáte AI, aby opravila drobnou chybu. Navrhne rozumnou změnu. Ta rozbije něco dalšího. Požádáte ji, aby opravila nový problém, a objeví se další dva. A tak dál.

Tento kolotoč vzniká, protože vibe coding je nedeterministický. Stejné zadání vám dvakrát dá jiný kód. Každá úprava proto může potichu posunout okolní logiku: hranice slevy se změní z 10 na 12 procent nebo se začne jinak chovat ověřovací pravidlo — bez vašich kontrol a bez jediného varování. Tomu se říká logický posun a potichu poškozuje přesně ty věci, které přinášejí peníze: ceny, přístup a platby.

Proti posunu chrání jedno pravidlo, které je tak jednoduché, že si ho můžete pověsit na zeď: nepotvrzujte kód, který byste nedokázali druhému člověku vysvětlit slovo od slova.

V praxi se z toho stává připravený postup, který použijete před každou změnou funkčního kódu. Přiměje AI postupovat po malých krocích a ukázat vám přesně, co se změnilo.

Než změníš kód, postupuj takto:

Ulož současný funkční stav jako samostatný bod návratu (commit).

Slovy přesně popiš, co plánuješ změnit a ve kterých souborech.

Proveď co nejmenší změnu — pouze to, co vyřeší můj úkol, nic navíc.

Ukaž mi, co se změnilo, a vysvětli každou změnu tak, abych ji dokázal vysvětlit jinému člověku.
Nesahej na logiku cen, přístupu ani plateb, pokud jsem tě o to nepožádal.

Dalším principem, který ušetří týdny, je disciplína při vymezování úkolů. Jeden problém, jedna změna, rychlé provedení. Nežádejte AI, aby v jednom zadání přepsala polovinu projektu. Profesionální vývojáři někdy začnou stavět celý Uber, přestože potřebovali jen jedno tlačítko — a protáhnou to na měsíce. To nepotřebujete.

Všechno, co popisuji, stojí na jedné věci: správě kontextu. Aby AI nerozbila související logiku, potřebuje znát pravidla vašeho projektu.

Jak změnu zkontrolovat před zveřejněním?#

Mezi „funguje to na mém počítači“ a „funguje to všem“ je mezikrok, který začátečníci vynechávají: testovací kopie. Jde o samostatný snímek produkčního prostředí, na kterém před skutečnými uživateli ověříte změnu. Pracovní cyklus vypadá takto:

1. Vytvořte změnu a sami ji zkontrolujte (vývoj).
2. Nasaďte ji na staging — kopii produkčního prostředí bez skutečných uživatelů.
3. Projděte klíčové scénáře a ověřte, že se nic nezměnilo.
4. Teprve potom ji nasaďte do produkce.

Proč na tom po spuštění záleží: každé vydání přináší riziko. Drobná změna kódu může přerušit přihlašování k účtu. Jedno chybějící nastavení může položit celý produkt. Staging tyto problémy zachytí bez následků; v produkci přicházíte o zákazníky.

Abyste nemuseli pokaždé všechno kontrolovat ručně, zadejte AI pokyn, aby porovnala chování nové a staré verze v kritických oblastech.

Chystám se nasadit změnu. Postupně projdi klíčové scénáře produktu a zkontroluj, že každý stále funguje jako dřív:

Registrace nového uživatele a přihlášení.

Platba a udělení přístupu po zaplacení.

Přístupová práva — běžný uživatel nevidí cizí data ani administrátorskou část.

Klíčové hodnoty obchodní logiky (ceny, slevy, limity) se nezměnily.
Pokud se cokoli chová jinak než v předchozí verzi, zastav se a ukaž mi přesně, co se změnilo.

Kde jsou vaše tajné údaje? Největší bezpečnostní díra začátečníka#

Největší mině se budu věnovat podrobně, protože zničí více produktů než kterákoli jiná. Když AI píše kód, nejjednodušší je umístit klíč tam, kde bude hned fungovat — přímo do kódu stránky, která se otevře v prohlížeči. Při vývoji rozdíl nepoznáte. Kdokoli si ale může přečíst vše, co se dostane do prohlížeče, když otevře vývojářské nástroje.

Zakladatel, jehož zákazníkům byly naúčtovány poplatky ve výši $87,500, později řekl, že tomu mohl zabránit jediný prompt. Poplatky byly nakonec vráceny, ale nevratné poplatky a ztráta klidu zůstaly. Tady je ono zadání.

Zkontroluj celý projekt a ujisti se, že se žádný tajný klíč nedostane do prohlížeče:

Najdi všechny klíče k databázi, platebnímu systému a externím službám.

Ujisti se, že je každý uložen pouze na serveru, v proměnných prostředí, a ne v kódu stránky.

Zkontroluj historii projektu — dostal se do ní někdy omylem nějaký klíč?
Ukaž mi seznam všech míst, kde jsi našel tajné údaje, a co je třeba s každým z nich udělat.

Další blízkou minou je kontrola přístupových práv pouze v prohlížeči. Pokud váš produkt rozhoduje o tom, zda „zobrazit administrátorskou část“, v kódu stránky, kdokoli může toto rozhodnutí obejít. Přístupová práva se musí vždy kontrolovat na serveru. Databáze smí vracet data pouze těm, kdo na ně mají nárok — k tomu slouží zabezpečení na úrovni řádků (RLS), které je třeba zapnout u každé tabulky.

Než začnete prodávat přístup nebo vpustíte další lidi, proveďte celkový bezpečnostní audit produktu.

Projdi projekt jako útočník a najdi bezpečnostní díry:

Jsou nějaké tajné klíče uložené v kódu, který se dostává do prohlížeče, nebo v historii projektu?

Je zabezpečení na úrovni řádků (RLS) zapnuté u každé databázové tabulky a kontrolují se přístupová práva na serveru, nikoli pouze v prohlížeči?

Je nakonfigurovaná automatická záloha databáze a ověřil jsem někdy, že z ní lze provést obnovu?

Je produkční databáze oddělená od prostředí, ve kterém běží agent AI?
U každé položky mi řekni, zda je vše v pořádku, nebo co přesně je třeba opravit.

Samostatný úplný průvodce se věnuje zabezpečení aplikací vytvořených vibe codingem: Jak zabezpečit aplikaci vytvořenou vibe codingem. Pravidlo je jednoduché: považujte vše, co AI udělala ve výchozím nastavení, za nezabezpečené, dokud neověříte opak.

Kde hostovat produkt: stupnice hostingu#

Nemusíte si hned pronajímat vlastní server a ručně ho nastavovat — na začátku je to složitý úkol, který vás připraví o čas. Můžete postupovat po stupnici podle toho, jak produkt roste:

1. Bezplatný hosting (například Vercel) — pro vás, testy a malé projekty. Funguje, pokud je platforma dostupná vašemu publiku a neukládáte osobní údaje lidí.
2. Platforma s nasazením jedním příkazem (Railway) — když máte backend a databázi. Nasadíte jedním příkazem a nemusíte nastavovat server. Bariéra vstupu je minimální.
3. Vlastní dedikovaný server — při vysoké zátěži a potřebě plné kontroly. Přejděte na něj později, až narazíte na limit platformy.

Pro neprogramátora, který právě spustil produkt, je nejjednodušší platforma s nasazením jedním příkazem, bez ruční konfigurace serveru. Na vlastní server přejděte později. Chcete-li touto cestou jít na konkrétním příkladu, přečtěte si průvodce nasazením projektu vytvořeného vibe codingem na vlastní server pomocí Coolify.

Kdy oddělit aplikaci, databázi a zálohy?#

Tři věci by neměly být v jednom košíku: aplikace, databáze a zálohy. Dokud je uživatelů málo, všechno běží pohromadě, a to je v pořádku. Existuje však jasný signál, kdy je čas je oddělit.

• Umístěte aplikaci a databázi na různé počítače. Signál: při špičkovém zatížení zůstávají CPU a paměť nad 70–80 procenty, požadavky se zpomalují a aplikace s databází soupeří o stejné zdroje. Po oddělení můžete posílit databázi, aniž byste zasahovali do aplikace, a naopak.
• Dodržujte pravidlo zálohování 3-2-1. Tři kopie dat, na dvou různých typech médií a jedna mimo pracoviště. Chrání před selháním hardwaru a ransomwarem. Klíčové je, aby zálohy probíhaly automaticky.

Četnost záloh závisí na tom, jak nákladná by byla ztráta dat za několik hodin. U online předplatitelské služby, kde je nepřijatelná ztráta hodiny platebních záznamů, musí být interval záloh kratší než hodina, nebo potřebujete ověřené transakční logy a obnovu k bodu v čase (PITR). Interval zvolte podle největší přijatelné ztráty dat a zvlášť otestujte dobu potřebnou k obnovení služby. Blogu stačí jednou denně. Logika je jednoduchá: rozhodněte, kolik dat si můžete dovolit ztratit, a podle toho nastavte zálohy.

Pomoz mi rozhodnout, zda nastal čas přesunout můj produkt na výkonnější infrastrukturu. Zkontroluj každý bod a polož mi k němu otázky:

Jak vytížené jsou při špičce CPU a paměť — drží se využití nad 70–80 procenty, nebo ne?

Běží databáze a aplikace na stejném počítači, nebo na různých?

Je nakonfigurovaná automatická záloha databáze a otestoval jsem obnovu z ní?

Existuje samostatná kopie prostředí (staging), na které lze kontrolovat změny před nasazením?
Na základě výsledků mi jasně doporuč, co ponechat, co oddělit jako první a proč.

Zbývá ještě otázka: spravovaná databáze, nebo vlastní? Pro malý tým je spravovaná téměř vždy lepší: vlastní je levnější z hlediska hardwaru, ale spotřebuje hodiny na údržbu. Pokud jste na všechno sami a váš produkt není infrastruktura, stojí ty hodiny víc než rozdíl v ceně serveru.

Jak nastavit údržbu na autopilota?#

Ruční údržba vyčerpává. Můžete si ji usnadnit dvěma způsoby: monitorováním a hlídacím agentem.

Monitorování využívá dva různé nástroje ke dvěma různým úkolům:

1. „Funguje web?“ — monitor dostupnosti (například UptimeRobot). Každých několik minut produkt zkontroluje a pošle upozornění, pokud přestane fungovat. Má bezplatný tarif.
2. „Co přesně se pokazilo?“ — nástroj pro sledování chyb (například Sentry). Shromažďuje chyby uvnitř aplikace a ukazuje, kde a proč něco selhalo.

První zjistí, že produkt přestal fungovat. Druhý ukáže, která funkce selhala a proč. Dohromady odpovídají na otázku: „Dozvím se o výpadku dřív, než zákazník napíše na podporu?“

Druhou úrovní autopilota je hlídací agent. Představte si realitní kancelář: v sedm ráno agent AI pročte poptávky na webu, zjistí, že rezervační formulář nefunguje, najde příčinu v kódu a přinese vám hotovou opravu s vysvětlením. Vy ji zkontrolujete a řeknete „ano“ — nasadí se. Pořadí je důležité: nejprve vyřešte problém uživatele (udělte přístup, omluvte se), pak zjišťujte příčinu a řešte peníze.

Ještě jedno pravidlo pro přístup AI k produkční databázi: dejte jí účet pouze pro čtení a osobní údaje skryjte za prostřední vrstvu, aby agent viděl „jméno“ místo skutečného jména člověka. Pak ani v případě chyby nebude fyzicky schopen smazat nebo poškodit produkční data. Incident z tabulky výše, kde agent vymazal produkční databázi, je přesně o chybějícím omezení. Průvodce Co dělat, když AI smazala vaši databázi vysvětluje, co dělat, když už katastrofa nastala.

Kdy je čas produkt vypnout?#

Nejpodceňovanější součástí údržby je vědět, kdy s ní přestat. Každý, kdo hodně tvoří, má hřbitov projektů: jeden vytvořil, chvíli se v něm vrtal a pak ho opustil. Je to normální a není to selhání. Selháním je měsíce táhnout něco, co nikdo nepoužívá, jen proto, že litujete investovaného času.

Hranice, podle kterých se můžete rozhodnout:

1. Dva týdny — dost na to, abyste zjistili, zda nápad funguje. Pokud se první skuteční uživatelé vracejí, pokračujte. Ticho je odpověď.
2. Tři měsíce — pevná hranice. Pokud se produkt za tři měsíce neuchytil, ukončete ho. Při rychlosti vibe codingu je šest měsíců testování jednoho nápadu příliš dlouho.

Ukončit projekt je psychicky těžké, proto to berte jako rozhodnutí, ne jako pocit. Vzdát se projektu, do kterého jste investovali, je jako propustit zaměstnance, který nezvládá svou práci: je to nepříjemné, ale nechat si ho stojí víc než ho propustit.

Údržba je práce, která udržuje produkt při životě a užitečný pro lidi. Všechno ostatní — git, zálohy, monitorování — jsou jen nástroje, které vám pomáhají dostat se do bodu, kdy vám produkt začne každý den sloužit.

Vytvořit produkt s AI za večer je polovina práce. Udržovat ho při životě a zabezpečený, jak roste — to znamená vibe coding pro dospělé.

Další krok — Ailoot.