Jak nastavit podporu pro vaše AI-generated aplikace

„Hele, nejde mi přihlášení.“

„Mně se tam ztratila data.“

„Mohl by ses na to rychle podívat?“

Představte si, že vám podobné zprávy začnou chodit kvůli aplikaci, kterou jste před pár dny vytvořili s AI. Přesně na zkušenosti s takovou situací jsem se zeptal na svém LinkedInu. 

• Jak řešíte provoz svých vibecodovaných aplikací? Máte monitoring, podporu, domluvené SLA?
• Nebo jedete punk a doufáte, že to případně zase nějak dopromptujete?

V komentářích pod postem se sešla řada názorů a několik dobrých přístupů. A taky jedna výstižná věta od Filipa Dadi: „Vibecoding demokratizoval vývoj. A spolu s ním i on-call pohotovost.“

Když si CEO vytvoří aplikaci

Vibecodovaní výrazně zkracuje cestu mezi „tohle by nám pomohlo“ a „pojďme to zrealizovat“. Člověk, který dobře zná problém, si může vytvořit první řešení, ukázat ho kolegům a hned zjistit, jestli dává smysl. A to je obrovská výhoda a příležitost.

Představte si, že CEO přes víkend pomocí AI postaví interní aplikaci pro obchodní tým. Zhmotní vlastní představu, kterou už dlouho nosí v hlavě, ověří proces a po spuštění ušetří mnoha svým kolegům práci. Jenže hned poté se z navibecodované aplikace stane firemní nástroj, na kterém obchod každý den závisí. A jeho autor dál zůstává jediným člověkem, který ví, kde aplikace běží, jak se nasazuje a proč se ten jeden export musí spouštět dvakrát.

CEO má najednou vedle vedení firmy na starost ještě technickou podporu. 

Stanovte si vlastnictví a odpovědnosti

Jakmile v aplikaci někdo zpracovává zakázky, registrace nebo zákaznická data, musíte vědět, co se stane při problému. Kdo začne jednat? Kam se uživatel ozve? Za jak dlouho zvládnete zareagovat? Při řešení akutního výpadku nechcete zjistit, že důležitý firemní nástroj pořád visí na osobním účtu člověka, který ho kdysi navibecodoval.

Pavel Cinkeis v diskusi připomněl i vlastnictví aplikace, přístupy a to, kam putují data. Jeho doporučení sepsat před spuštěním alespoň jednu stránku o odpovědnostech a předání je podle mě výborný začátek.

Dva příklady, kdy se provoz připomněl

V červenci 2025 smazal agent Replitu data z databáze aplikace Jasona Lemkina. Replit incident ve vlastním vyjádření potvrdil. Databázi se podařilo plně obnovit pomocí rollbacku. Agent ale o této možnosti nevěděl, takže při řešení nepomohl. Replit také zavedl automatické oddělení vývojové a produkční databáze, aby změny při vývoji nezasahovaly do živých dat.

Pro mě z toho plyne jedna praktická věc: Mít možnost obnovy nestačí. Někdo musí vědět, jak ji použít. 

Ve stejném měsíci odhalili výzkumníci Wiz chybu u platformy Base44, která umožňovala neoprávněný přístup do soukromých aplikací. Dodavatel ji opravil do 24 hodin od nahlášení a podle jeho prověření nebyly zjištěny známky předchozího zneužití. Šlo o chybu platformy, kterou by samotný autor aplikace ve svém kódu neopravoval.

Tyto dva reálné příklady ukazují, proč se vyplatí mít připravené zálohy, oddělené prostředí a konkrétního člověka nebo tým, který ví, co má dělat.

Moje poučení? Provozní péče zahrnuje i přehled o dodavatelích, vyhodnocení dopadu jejich problémů a komunikaci s nimi. Vlastní aplikace je na jejich službách často závislá.

A nepohlídá to další agent?

Lidský původ kódu sám o sobě kvalitu nezaručuje. V komentářích na to správně upozornil Václav Bartoš: automatizace může zlepšovat i údržbu a spolehlivost. I proto se nabízí řešení nasadit na kontrolu a řešení chyb dalšího agenta.

Ondřej Štěpánek popsal svůj postup se Sentry, AutoGenem a Codexem: zachycená chyba spustí analýzu, návrh opravy a testy. Do produkce se změna dostane až po jeho schválení.

Petr Glaser zase soustřeďuje aplikace do společného základu, který řeší oprávnění, bezpečnost a přehled o provozu.

To jsou dobré směry a už existují i hotové nástroje. Například Sentry Seer umí hledat příčinu chyby, připravit změny kódu a otevřít návrh opravy.

Pořád ale potřebujete určit, kdo rozhodne, jestli je oprava správná, kdo má oprávnění ji nasadit a kdo zasáhne, když automatizace problém nevyřeší. Pokud všechny tyhle role končí u vás, část práce jste s pomocí dalších agentů zrychlili, ale pohotovost jste zatím nikomu nepředali.

Každá aplikace má svá rizika

Je rozdíl, jestli vám spadne aplikace pro plánování dovolené nebo systém pro plánování objednávek. U aplikace, bez které se práce týmu zastaví, rozhodně dává smysl smluvně domluvená podpora:

• Kdy je podpora dostupná a jak rychle začne problém řešit. Pracovní den a sobotní noc jsou různé služby.
• Co je kritická chyba. Nefunkční objednávky potřebují jinou prioritu než posunutá ikona.
• Co sledujeme a jak se závada hlásí. Nestačí mít dashboard, na který se nikdo nedívá.
• Jak obnovíme provoz a data. Jak dlouhý výpadek firma snese a o kolik posledních změn si může dovolit přijít?
• Co péče zahrnuje a co se platí zvlášť. Oprava závady, nové funkce a změna celého procesu nejsou stejný požadavek.

Platím hosting. K čemu ještě podpora?

Mnoho autorů AI-generated aplikací věří, že podpora není potřeba, pokud jejich aplikace vznikla na Lovablu nebo běží na Vercelu. Ale nezapomeňme, že hosting řeší jen svou část provozu. Vaše aplikace má vlastní kód, oprávnění, data a napojení na další služby.

Ze smlouvy na hosting tedy nelze automaticky odvozovat, že vám někdo opraví nefunkční přihlášení ve vlastní aplikaci. Například enterprise SLA Vercelu vymezuje dostupnost jeho platformy a mezi výluky řadí i výpadky způsobené zákaznickým softwarem. 

Podobnou hranici popisuje Lovable u svých bezpečnostních certifikací. Vztahují se na platformu, ale automaticky se nepřenášejí na aplikace, které na ní někdo vytvoří.

Jak z toho ven? Část potřeb pokryjí funkce platformy, další monitoring a automatizace. Péči může zajistit vlastní technický tým nebo externí partner. Rozhodující je vědět, kdo se stará o celek a kde jeho odpovědnost končí.

Převezmeme aplikaci i odpovědnost

To, že jste dokázali aplikaci vytvořit, z vás automaticky nedělá nejlepšího člověka pro její každodenní provoz. Schopný autor může zůstat u produktu a předat technickou péči někomu, kdo na ni má kapacitu, zkušenosti a záskok.

Náš tým umí navázat na vaši práci a dotáhnout technická úskalí ostrého provozu. Udělali jsme to například s konferenční aplikací pro FrontKon. Její organizátor s pomocí AI vytvořil základ aplikace a týden před akcí měl v ruce funkční prototyp. 

V Superkoders jsme aplikaci převzali pět dní před eventem. Upravili jsme UX a texty, doplnili funkce a připravili produkční infrastrukturu, zátěžový test, zálohování, hlášení chyb i monitoring. Zajistili jsme také technickou podporu během konference, kam dorazilo 700 účastníků. Celý příběh aplikace pro FrontKon najdete v případové studii.

Buďte autorem, ne technickou podporou

V rámci AI Powered Development pomáháme nápady rychle ověřit a existující AI aplikace dostat do produkce. Na to navazujeme se službou AI App Support, která vám zaručí dlouhodobou technickou péči o aplikaci, kterou už lidé používají.

Nejdřív zjistíme, v jakém je stavu a co potřebuje pro převzetí. Potom nastavíme monitoring, podporu a SLA podle významu aplikace pro váš byznys.

Vibecodujte a ověřujte své nápady, které by se dřív do vývoje vůbec nedostaly. Ale jakmile na výsledku začnou záviset další lidé, dejte aplikaci servis, který si zaslouží.

Máte už aplikaci, která pomáhá ostatním, ale vám přidělává druhou práci? Podívejte se na službu AI App Support a pojďme probrat vaši situaci.