Vytvoril som produkt pomocou AI — ako ho vylepšovať bez toho, aby ste pokazili to, čo funguje

Viac o práci s modelmi nájdete v dokumentácii Ailoot.

Prečo sa najdrahšia práca začína až po spustení?#

Za večer ste vytvorili aplikáciu, zverejnili odkaz a poslali ho priateľom. Funguje. O týždeň sa objaví prvý skutočný používateľ, niečo nesprávne stlačí a polovica funkcií prestane fungovať. Požiadate Clauda, aby to opravil — opraví jednu vec a pokazí inú. Znie vám to povedome?

A práve tu vyvstáva hlavná otázka: čo robiť po spustení produktu, keď pominie eufória z prvého funkčného prototypu a vy ho stále musíte nejako udržiavať? Dalo by sa to nazvať vibe codingom pre dospelých. Tvorba prináša nadšenie a rýchlosť. Údržba si vyžaduje chladnú hlavu: rozumiete tomu, čo meníte, a držíte to pod kontrolou. Väčšina ľudí zlyhá v tejto druhej časti, pretože ich na ňu nikto nepripraví.

Jedna odvetvová štúdia analyzovala viac než milión zmien kódu z 2 444 tímov a vypočítala, kam v skutočnosti smerujú peniaze vynaložené na vývoj pomocou AI. Takto to vyzerá:

Sprievodca „Skryté náklady vibe codingu“ vysvetľuje tieto čísla podrobnejšie. Tam bola otázka, za čo platíte. Tu je otázka iná: 44 centov z každého dolára ide na opravu chýb — a celý tento článok je o tom, ako zabrániť tomu, aby tento podiel rástol. Práca na jeho udržaní pod kontrolou sa nazýva údržba.

Rozdiel medzi človekom, ktorý používa vibe coding pre dospelých, a človekom, ktorý iba stráži neurónovú sieť, sa ukáže po spustení. Prvému rastie kódová základňa, robí vylepšenia a nič sa nepokazí. O mesiac sa produkt toho druhého zmení na deravú konštrukciu, na ktorú sa bojí siahnuť. Ďalej vysvetlím, ako sa dostať do prvej skupiny.

Čo sa v skutočnosti pokazí: 5 katastrof po spustení#

Toto sú verejné postmortemy skutočných produktov vytvorených pomocou AI, s číslami a dátumami. Berte ich ako mapu mínového poľa — každá mína už niekomu vybuchla a je známe, ako sa jej vyhnúť.

Všetkých päť prípadov má rovnakú základnú príčinu. AI predvolene zabezpečí, aby veci fungovali hneď, nie bezpečne o mesiac pri záťaži. Pri vývoji na vlastnom počítači rozdiel nevidíte. Ukáže sa, keď sa objaví prvý cudzí človek so zlými úmyslami.

Problém nie je v tom, že kód nepíšete ručne — takto pracuje veľa ľudí. Problém je, keď sa nikto nespýta: „Je databáza zabezpečená?“ Ďalej vám ukážem výzvu, ktorá túto otázku položí za vás.

Prvou záchrannou sieťou je git a návrat k tomu, „ako to bolo včera“#

Keď Claude niečo pokazí, potrebujete tlačidlo „vráť to do stavu, v akom to bolo včera“. Technicky sa toto tlačidlo volá git a je jednoduchšie, než sa zdá.

Tri pojmy, ktorým musí rozumieť aj človek, ktorý nie je programátor:

1. Repozitár — priečinok projektu uložený v cloude (zvyčajne na GitHube). Kópia celého vášho kódu, ktorá nie je iba vo vašom počítači.
2. Commit — bod návratu. V podstate kódu poviete: „ulož tento stav“. Každý commit je značka, ku ktorej sa môžete vrátiť.
3. Deploy — presun. Kód bol lokálne, vo vašom počítači, a fungoval iba vám. Deploy ho odošle na externý server, aby fungoval pre všetkých.

Ak máte aktuálne body commitov, každú poruchu môžete vrátiť späť jednou vetou. Doslova.

Niečo som pokazil — včera všetko fungovalo, ale dnes nie. Nájdi posledný commit, v ktorom bolo všetko v poriadku, ukáž mi, čo sa odvtedy zmenilo, a vráť projekt do tohto stavu.

Dva pravidlá, ktoré treba zaviesť hneď, skôr než produkt uvidia iní ľudia:

• Repozitár musí byť súkromný. Nie verejný. Inak si každý môže prečítať váš kód aj všetko, čo obsahuje.
• Pridajte súbor s tajomstvami do zoznamu ignorovaných súborov. Kľúče, heslá a prihlasovacie údaje na prístup k databáze patria do samostatného súboru (zvyčajne .env), ktorý sa nikdy nedostane do repozitára. Pridajte do .gitignore riadok pre .env a tajomstvá zostanú u vás.

Samostatný sprievodca vysvetľuje bezpečné vracanie zmien v Claude Code: Ako vrátiť zmeny v Claude Code. Bez bodov návratu kráčate po lane bez záchrannej siete a skôr či neskôr spadnete.

Čo /rewind vráti späť a čo nie?#

Claude Code vytvorí snímku stavu pred každou zmenou, ktorú vykoná. Príkaz /rewind (alebo dvojité stlačenie klávesu Esc) vráti súbory aj konverzáciu do vybraného bodu. Je to praktické: ak ste pred piatimi minútami pokazili funkciu, môžete sa vrátiť o päť minút späť.

Je tu však pasca, kvôli ktorej začiatočníci prichádzajú o údaje. /rewind nevráti späť všetko:

Samotná Anthropic to hovorí jasne: snímky sú miestne tlačidlo „vrátiť späť“, zatiaľ čo git je trvalá história. Snímky dopĺňajú správu verzií, ale nenahrádzajú ju.

Praktické ponaučenie pre človeka, ktorý nie je programátor: /rewind vás zachráni pred situáciou „Claude práve pokazil funkciu“. Ak však stihol vymazať riadok databázy alebo nahrať kód do cloudu, obnoviť ho môže iba git a záloha databázy. Preto používajte obe vrstvy: snímky na rýchle vrátenie zmien a commity ako trvalú históriu projektu.

Ako robiť vylepšenia bez toho, aby ste pokazili to, čo už funguje?#

Do tohto cyklu sa chytí každý druhý človek. Požiadate AI o opravu malej chyby. Navrhne rozumnú zmenu. Tá zmena pokazí niečo iné. Požiadate ju, aby opravila nový problém, a objavia sa ďalšie dva. A tak ďalej.

Tento cyklus vzniká preto, že vibe coding je nedeterministický. Rovnaká výzva vám dvakrát poskytne odlišný kód. Každá úprava tak môže potichu posunúť súvisiacu logiku: hranica zľavy sa zmení z 10 na 12 percent alebo sa zmení správanie pravidla overovania — bez vašich kontrol a bez jediného varovania. Hovorí sa tomu logický posun a potichu poškodzuje presne tie veci, ktoré prinášajú peniaze: ceny, prístup a platby.

Proti posunu chráni jedno pravidlo, ktoré je také jednoduché, že si ho môžete zavesiť na stenu: necommitujte kód, ktorý by ste nedokázali vysvetliť inému človeku slovo za slovom.

V praxi z toho vznikne hotový rámec, ktorý použijete pred každou zmenou funkčného kódu. AI vďaka nemu postupuje po malých krokoch a presne vám ukáže, čo sa zmenilo.

Pred zmenou kódu urob toto:

Ulož aktuálny funkčný stav ako samostatný bod návratu (commit).

Slovami presne opíš, čo plánuješ zmeniť a v ktorých súboroch.

Urob čo najmenšiu možnú zmenu — iba to, čo vyrieši moju úlohu, nič navyše.

Ukáž mi, čo sa zmenilo, a vysvetli každú zmenu tak, aby som ju dokázal vysvetliť inému človeku.
Nesiahaj na logiku cien, prístupu ani platieb, pokiaľ ťa o to nepožiadam.

Ďalšou zásadou, ktorá vám ušetrí týždne, je disciplína pri vymedzovaní úloh. Jeden problém, jedna zmena, rýchla implementácia. Nežiadajte AI, aby jednou výzvou prepísala polovicu projektu. Profesionálni vývojári niekedy začnú budovať celé Uber, hoci potrebovali iba jedno tlačidlo — a naťahujú to celé mesiace. To nepotrebujete.

Všetko, čo opisujem, stojí na jednej veci: správe kontextu. Aby AI nepokazila súvisiacu logiku, musí si pamätať pravidlá vášho projektu.

Ako skontrolovať zmenu pred jej zverejnením?#

Medzi „funguje to na mojom počítači“ a „funguje to pre všetkých“ je medzikrok, ktorý začiatočníci vynechávajú: testovacia kópia. Je to samostatná snímka vášho produkčného prostredia, v ktorej skontrolujete zmenu ešte predtým, než ju uvidia skutoční ľudia. Pracovný cyklus vyzerá takto:

1. Zmenu vytvorte a skontrolujte sami (vývojové prostredie).
2. Nasaďte ju do stagingu — kópie produkcie bez skutočných používateľov.
3. Spustite kľúčové scenáre a uistite sa, že sa nič neposunulo.
4. Až teraz ju nasaďte do produkcie.

Prečo je to po spustení dôležité: každé vydanie prináša riziko. Malá zmena kódu môže pokaziť prihlasovanie do účtu. Jedno chýbajúce nastavenie môže vyradiť celý produkt. Staging zachytí tieto problémy bez následkov; v produkcii prichádzate o zákazníkov.

Aby ste nemuseli zakaždým všetko kontrolovať ručne, dajte AI výzvu, aby porovnala správanie novej verzie so starou v kritických oblastiach.

Chystám sa nasadiť zmenu. Postupne prejdi kľúčové scenáre produktu a skontroluj, či každý stále funguje ako predtým:

Registrácia a prihlásenie nového používateľa.

Platba a udelenie prístupu po zaplatení.

Prístupové práva — bežný používateľ nevidí údaje niekoho iného ani správcovskú oblasť.

Kľúčové hodnoty obchodnej logiky (ceny, zľavy, limity) sa nezmenili.
Ak sa niečo správa inak než v predchádzajúcej verzii, zastav sa a presne mi ukáž, čo sa zmenilo.

Kde sú vaše tajomstvá? Najväčšia slabina začiatočníkov#

Najväčšiu mínu vysvetlím podrobne, pretože vyradí viac produktov než čokoľvek iné. Keď AI píše kód, najjednoduchšie je vložiť kľúč tam, kde bude hneď fungovať — priamo do kódu stránky, ktorá sa otvorí v prehliadači. Počas vývoja si rozdiel nevšimnete. Každý však môže čítať všetko, čo sa dostane do prehliadača, keď otvorí vývojárske nástroje.

Zakladateľ, ktorého zákazníkom boli naúčtované platby vo výške $87,500, neskôr povedal, že tomu mohla zabrániť jediná výzva. Platby sa nakoniec stornovali, no nevratné poplatky a stratený pokoj zostali. Tu je tá výzva.

Skontroluj celý projekt a uisti sa, že sa žiadny tajný kľúč nedostane do prehliadača:

Nájdi všetky kľúče k databáze, platobnému systému a externým službám.

Uisti sa, že každý z nich je uložený iba na serveri, v premenných prostredia, a nie v kóde stránky.

Skontroluj históriu projektu — nedostal sa do nej niektorý kľúč omylom už skôr?
Ukáž mi zoznam všetkých miest, kde si našiel tajomstvá, a čo treba s každým z nich urobiť.

Ďalšou blízkou mínou je kontrola prístupových práv iba na strane prehliadača. Ak produkt rozhoduje o tom, či „zobrazí správcovskú oblasť“, v kóde stránky, každý môže toto rozhodnutie obísť. Prístupové práva sa musia vždy kontrolovať na serveri. Databáza musí vracať údaje iba tým, ktorí na ne majú nárok — na to slúži zabezpečenie na úrovni riadkov (RLS), ktoré musí byť zapnuté v každej tabuľke.

Pred predajom prístupu alebo vpustením ďalších ľudí vykonajte všeobecný bezpečnostný audit produktu.

Prejdi projekt ako útočník a nájdi bezpečnostné diery:

Sú nejaké tajné kľúče uložené v kóde, ktorý sa posiela do prehliadača, alebo v histórii projektu?

Je zabezpečenie na úrovni riadkov (RLS) zapnuté v každej databázovej tabuľke a kontrolujú sa prístupové práva na serveri, nielen v prehliadači?

Je nastavené automatické zálohovanie databázy a overil som niekedy, že ju viem obnoviť?

Je produkčná databáza oddelená od prostredia, v ktorom beží agent AI?
Pri každej položke mi povedz, či je všetko v poriadku, alebo čo presne treba opraviť.

Samostatný úplný sprievodca sa venuje bezpečnosti vibe codingu: Ako zabezpečiť aplikáciu vytvorenú pomocou vibe codingu. Pravidlo je jednoduché: predvolene považujte všetko, čo urobila AI, za nezabezpečené, kým si neoveríte opak.

Kde hostovať produkt: postupný rebrík hostingu#

Nemusíte si hneď prenajať vlastný server a ručne ho konfigurovať — na začiatku je to zložitá úloha a zaberie vám čas. S rastom produktu môžete postupovať po jednotlivých priečkach:

1. Bezplatný hosting (napríklad Vercel) — pre vás, testy a malé projekty. Funguje, ak je platforma dostupná pre vaše publikum a neukladáte osobné údaje ľudí.
2. Platforma s nasadením jedným príkazom (Railway) — keď máte backend a databázu. Nasadíte jedným príkazom a nemusíte konfigurovať server. Prekážka vstupu je minimálna.
3. Vlastný dedikovaný server — pri vysokej záťaži, keď potrebujete úplnú kontrolu. Prejdite naň neskôr, keď narazíte na limit platformy.

Pre človeka, ktorý nie je programátor a práve spustil produkt, je najjednoduchšou voľbou platforma s nasadením jedným príkazom, bez ručnej konfigurácie servera. Na vlastný server prejdite neskôr. Ak chcete túto cestu sledovať na konkrétnom príklade, pozrite si sprievodcu nasadením projektu vytvoreného pomocou vibe codingu na vlastnom serveri s Coolify.

Kedy oddeliť aplikáciu, databázu a zálohy?#

Tri veci by sa nemali uchovávať v jednom košíku: aplikácia, databáza a zálohy. Kým je používateľov málo, všetko je spolu a je to v poriadku. Existuje však jasný signál, kedy je čas ich oddeliť.

• Umiestnite aplikáciu a databázu na rôzne počítače. Signál: pri špičkovej záťaži zostáva využitie CPU a pamäte nad 70–80 percent, požiadavky sa spomaľujú a aplikácia s databázou súperia o rovnaké zdroje. Po oddelení môžete posilniť databázu bez zásahu do aplikácie a naopak.
• Dodržiavajte pravidlo zálohovania 3-2-1. Tri kópie údajov na dvoch rôznych typoch médií, pričom jedna je mimo lokality. Chráni to pred zlyhaním hardvéru a ransomvérom. Kľúčové je automatické zálohovanie.

Frekvencia zálohovania závisí od toho, aké nákladné je stratiť údaje za niekoľko hodín. Pri online službe s predplatným, kde je strata hodiny platobných záznamov neprijateľná, musí byť interval záloh kratší než hodina alebo potrebujete overené transakčné logy a obnovu k bodu v čase (PITR). Interval vyberte podľa najväčšej prijateľnej straty údajov a osobitne otestujte čas obnovy služby. Pri blogu stačí raz denne. Logika je jednoduchá: rozhodnite sa, koľko údajov si môžete dovoliť stratiť, a podľa toho nastavte zálohovanie.

Pomôž mi rozhodnúť, či je čas presunúť môj produkt na vážnejšiu infraštruktúru. Skontroluj a opýtaj sa ma na každý bod:

Aké je vyťaženie CPU a pamäte v špičke — zostáva využitie nad 70–80 percent, alebo nie?

Sú databáza a aplikácia na tom istom počítači, alebo na rôznych?

Je nastavené automatické zálohovanie databázy a otestoval som jej obnovu?

Existuje samostatná kópia prostredia (staging) na kontrolu pred nasadením?
Na základe výsledkov mi daj jasné odporúčanie: čo ponechať tak, ako je, čo oddeliť ako prvé a prečo.

Je tu aj samostatná otázka: spravovaná databáza alebo vlastná. Pre malý tím je spravovaná takmer vždy lepšia: vlastná je lacnejšia z hľadiska hardvéru, ale spotrebuje hodiny na údržbu. Ak ste na to sami a váš produkt nie je infraštruktúra, tieto hodiny stoja viac než rozdiel v cene servera.

Ako automatizovať údržbu?#

Ručná údržba je vyčerpávajúca. Môžete si ju uľahčiť dvoma spôsobmi: monitorovaním a obchôdzkovým agentom.

Monitorovanie používa dva rôzne nástroje na dve rôzne úlohy:

1. „Je stránka dostupná?“ — monitor dostupnosti (napríklad UptimeRobot). Každých niekoľko minút otestuje produkt a pošle upozornenie, ak vypadne. Má bezplatný plán.
2. „Čo presne sa pokazilo?“ — nástroj na sledovanie chýb (napríklad Sentry). Zbiera chyby v aplikácii a ukazuje, kde a prečo niečo zlyhalo.

Prvý zachytí, že produkt prestal fungovať. Druhý ukáže, ktorá funkcia zlyhala a prečo. Spoločne odpovedajú na otázku: „Dozviem sa o výpadku skôr, než zákazník napíše na podporu?“

Druhou úrovňou automatizácie je obchôdzkový agent. Predstavte si realitnú kanceláriu: o siedmej ráno agent AI číta dopyty na webe, zistí, že rezervačný formulár nefunguje, nájde príčinu v kóde a prinesie vám hotovú opravu s vysvetlením. Skontrolujete ju a poviete „áno“ — nasadí sa. Na poradí záleží: najprv vyriešte problém používateľa (udeľte prístup, ospravedlňte sa), potom skúmajte príčinu a peniaze.

Ešte jedno pravidlo pre prístup AI k produkčnej databáze: vytvorte jej používateľa iba na čítanie a osobné údaje skryte za sprostredkovateľskú vrstvu, aby agent videl „meno“ namiesto skutočného mena človeka. Potom ani v prípade chyby nebude môcť fyzicky vymazať alebo poškodiť produkčné údaje. Prípad z tabuľky vyššie, keď agent vymazal produkčnú databázu, je presne o chýbajúcom obmedzení. Sprievodca Čo robiť, ak AI vymazala vašu databázu vysvetľuje, čo robiť, ak už katastrofa nastala.

Kedy je čas produkt vypnúť?#

Najviac podceňovanou súčasťou údržby je vedieť, kedy s ňou prestať. Každý, kto vytvára veľa projektov, má ich cintorín: jeden vytvoril, chvíľu sa s ním pohral a potom ho opustil. Je to normálne a nie je to zlyhanie. Zlyhaním je mesiace vláčiť niečo, čo nikto nepoužíva, len preto, že ľutujete vynaložený čas.

Hranice, podľa ktorých sa môžete rozhodnúť:

1. Dva týždne — dosť na to, aby ste zistili, či nápad funguje. Ak sa prví skutoční používatelia vrátia, pokračujte. Aj ticho je odpoveď.
2. Tri mesiace — tvrdý limit. Ak sa produkt za tri mesiace nerozbehol, zatvorte ho. Pri rýchlosti vibe codingu je šesťmesačné testovanie jedného nápadu príliš dlho.

Ukončiť projekt je psychologicky náročné, preto to berte ako rozhodnutie, nie pocit. Vzdať sa projektu, do ktorého ste investovali, je ako prepustiť zamestnanca, ktorý nevie vykonávať svoju prácu: nepríjemné, ale jeho udržiavanie stojí viac než prepustenie.

Údržba je práca, ktorá udržiava produkt živý a užitočný pre ľudí. Všetko ostatné — git, zálohy, monitorovanie — sú len nástroje, ktoré vám pomáhajú dostať sa do bodu, keď vám produkt začne každý deň slúžiť.

Vytvoriť produkt pomocou AI za večer je polovica práce. Udržiavať ho živý a bezpečný, ako rastie — to znamená vibe coding pre dospelých.

Ďalší krok — Ailoot.