Vibe coding umožňuje během hodin nebo dnů vytvořit aplikaci, na kterou by se dříve připravovalo zadání, rozpočet a vývojový tým. Pro prototypy, interní pomůcky a rychlé ověřování nápadů je to fantastická změna. Ve chvíli, kdy aplikace začne pracovat s firemními daty, používají ji další lidé nebo na ní závisí provoz, roste význam bezpečnosti, testování, dokumentace a hlavně člověka, který za výsledek odpovídá.
Ještě nedávno mohl dobrý nápad několik měsíců čekat, než se dostal na řadu ve vývoji. Dnes si obchodník vytvoří malou aplikaci pro přípravu nabídek, marketing propojí několik nástrojů a founder přes víkend postaví první verzi nové služby. Nápad se dostane z hlavy ven a velmi rychle se potká s realitou.
Právě v tom vidíme jednu z největších výhod vibe codingu. Firmy mohou levněji experimentovat a zkoušet věci, které by dříve skončily v šuplíku s poznámkou „až bude rozpočet“.
Vibe coding výrazně zlevnil experimentování
U prototypu není dokonalost hlavní disciplínou. Potřebujeme zjistit, jestli myšlenka funguje, zda lidem skutečně pomáhá a jestli má smysl investovat do dalšího rozvoje. Vibe coding tuto fázi dramaticky zrychluje.
Včas objevená slepá ulička je docela dobrý výsledek. Zvlášť když její objevování nestálo několik měsíců práce a velkou část rozpočtu. Stejně dobře může první rychlá aplikace ukázat, že původní myšlenka potřebuje změnit, a umožnit během pár hodin vytvořit další variantu.
Tento způsob práce dobře zapadá i do současného vývoje firemních aplikací na míru, kde AI umožňuje podstatně rychleji přecházet mezi nápadem, funkční ukázkou a zpětnou vazbou uživatelů.
Prototyp může povýšit téměř nepozorovaně
Zajímavý okamžik přichází ve chvíli, kdy se povedený experiment začne šířit dál. Nejprve aplikaci používá její autor, potom dva kolegové, následně se přidá celé oddělení a jednoho dne se ukáže, že bez ní nejde připravit nabídku nebo expedovat objednávku.
Nikdo přitom nemusel explicitně rozhodnout, že z prototypu vzniká firemní systém. Prostě se stal užitečným.
S jeho významem ale rostou požadavky na kvalitu. Osobní pomůcka může občas zazlobit. Systém, přes který tečou zákaznická data nebo peníze, už potřebuje podstatně větší péči.
Začnou být důležité otázky, které při prvním experimentu nebyly příliš zajímavé: Kdo aplikaci spravuje? Kde běží? Jak jsou zálohovaná data? Co se stane při výpadku? Kdo vidí které informace? Jak se nasazuje nová verze a kdo pozná, že změna nerozbila něco dalšího?
Black box: aplikace funguje, ale kdo jí opravdu rozumí?
Vibe coding přináší ještě jeden zajímavý problém. Člověk může vytvořit překvapivě komplexní aplikaci, aniž by do detailu rozuměl jejímu kódu a architektuře.
Požádá AI o přihlášení uživatelů, databázi a napojení na externí službu. Něco přestane fungovat, pošle chybovou hlášku zpět agentovi a dostane sebevědomé „opraveno“. Aplikace znovu běží, takže se pokračuje dál.
Postupně může vzniknout black box složený z velkého množství kódu a technických rozhodnutí, kterým nikdo ve firmě pořádně nerozumí. Autor neví, kde se ukládají secrets, jak fungují oprávnění, které knihovny se používají nebo proč agent zvolil konkrétní architekturu.
Samotný AI generovaný kód přitom nemusí být problém. Black box vzniká ve chvíli, kdy výslednému systému nikdo kompetentní nerozumí a chybí způsob, jak jeho chování kontrolovat.
Podobnou změnu ekonomiky vývoje popisujeme i v článku AI zlevnilo programování. Špatná rozhodnutí zůstávají drahá.
Bezpečnostní chyby často nejsou vidět
Vizuálně povedená aplikace může fungovat naprosto přesvědčivě. Přihlášení funguje, formuláře odesílají data a grafy se hýbou. Bezpečnostní problémy přitom často leží ve vrstvách, které běžný uživatel vůbec nevidí.
Typickým problémem mohou být špatně nastavená oprávnění k databázi, přístupové klíče ve frontendovém kódu, nedostatečně chráněné API nebo bezpečnostní logika prováděná pouze v prohlížeči. Na povrchu může být vše v pořádku až do chvíle, kdy se někdo podívá pod kapotu.
Dobře je to vidět na případu Moltbooku, rychle vytvořené sociální sítě pro AI agenty, jejíž zakladatel se chlubil, že nenapsal jediný řádek kódu. Přístupový klíč k databázi byl přitom vidět přímo ve zdrojovém kódu stránky – stačilo otevřít vývojářské nástroje prohlížeče. Podle analýzy Davida Grudla tak bylo vystaveno přibližně 1,5 milionu přístupových tokenů a 35 000 e-mailových adres.
Podobné incidenty ukazují jednoduchou věc: funkčnost aplikace a její bezpečnost jsou dvě různé vrstvy kvality. AI dokáže rychle vytvořit první z nich, druhá potřebuje průběžnou kontrolu a zkušenost.
Produkční software má víc vrstev než obrazovku
Bezpečnost je pouze část celé skládačky. U důležitější aplikace řeší profesionální vývoj také testování, monitoring, dokumentaci, verzování, zálohování, obnovu po havárii, správu závislostí, licence nebo způsob nasazování nových verzí.
Mnoho těchto věcí není při používání vůbec vidět. Přesto rozhodují o tom, zda lze software dlouhodobě provozovat a rozvíjet.
Čím větší škodu může chyba způsobit, tím více engineeringu kolem aplikace potřebujeme. Interní kalkulačka pro jednoho člověka má jiný rizikový profil než systém s osobními údaji zákazníků, napojením do ERP nebo možností provádět finanční operace.
Prakticky si lze představit tři úrovně:
| Použití | Typický příklad | Co řešit |
|---|---|---|
| Nízké riziko | prototyp, kalkulačka, osobní nástroj | rychlost, funkčnost, ověření nápadu |
| Střední riziko | interní aplikace pro tým, reporting, automatizace | data, přístupy, testy, správa |
| Vysoké riziko | zákaznický systém, platby, citlivá data, kritický provoz | bezpečnostní audit, architektura, monitoring, odpovědnost |
Hranice nejsou ostré. Dobré vodítko je sledovat, kolik lidí aplikaci používá, s jakými daty pracuje a jaký dopad by měl její výpadek nebo chyba.
Od vibe codingu k agentic engineeringu
AI agenty používáme intenzivně i v profesionálním vývoji. Rozdíl je hlavně v systému práce kolem nich.
Pro tento přístup používáme označení agentic engineering. Agent může pomáhat s analýzou, psaním kódu, testováním, dokumentací, code review i nasazením. Vývoj ale zároveň pracuje s technickým návrhem, verzováním, testy, bezpečnostními pravidly a průběžnou kontrolou výsledků.
Rozdíl nespočívá v tom, jestli kód vytváří AI. Rozhoduje engineering kolem ní.
S rostoucí rychlostí vývoje získává ještě větší význam zkušenost člověka, který dokáže poznat, kde lze improvizovat a kde by zkratka mohla být později drahá. Podobnou koncentraci odpovědnosti a expertízy řešíme i v článku o Forward Deployed Engineering.
Co s vibe coded aplikací, která už ve firmě běží?
První reakce nemusí být její přepis. Často dává větší smysl zjistit její skutečný stav: kde běží, s jakými daty pracuje, jak jsou řešené přístupy, zda existují zálohy, testy a dokumentace, jaké používá závislosti a kdo dnes za její provoz odpovídá.
Užitečný nástroj může po technickém auditu pokračovat dál. Někdy stačí hardening a doplnění chybějících provozních vrstev, jindy refactoring nebo převzetí profesionálním týmem. A někdy opravdu zjistíme, že prototyp splnil svůj účel a je levnější postavit další verzi čistěji.
Právě podobné situace jsou dobrým kandidátem pro STK firemního softwaru, kde lze posoudit technický stav, bezpečnost, závislosti a další možnosti rozvoje.
Experimentujte rychle, odpovědnost přidávejte včas
Vibe coding podle nás otevírá firmám obrovský prostor. Lidé mohou sami řešit drobné provozní problémy, rychle testovat nápady a vytvářet software přesně ve chvíli, kdy jej potřebují. Takových aplikací proto bude velmi pravděpodobně rychle přibývat.
Důležitý je okamžik, kdy experiment začne mít skutečný provozní význam. S významem aplikace musí růst i péče o její kvalitu, bezpečnost a správu.
Aplikace může vzniknout za víkend. Pokud na ní za půl roku stojí kus firmy, zaslouží si už úplně jinou úroveň pozornosti.
Pokud vám ve firmě vznikly rychlé AI nebo vibe coded aplikace a začínají být důležité pro provoz, můžeme v rámci STK pro firemní software projít jejich technický stav a rizika nebo rovnou probrat konkrétní aplikaci.
Nejčastější otázky
Je vibe coding vhodný pro firemní aplikace?
Ano, hlavně pro prototypy, menší interní nástroje a rychlé ověřování use case. S rostoucím počtem uživatelů, citlivostí dat a významem aplikace je potřeba postupně přidávat standardní engineering disciplíny.
Je AI generovaný kód méně bezpečný?
Bezpečnost závisí na celém způsobu vývoje, architektuře a kontrole výsledku. AI umí vytvářet funkční kód velmi rychle, ale bezpečnostní chyby mohou zůstat mimo to, co autor nebo uživatel při běžném používání vidí.
Jak poznám, že prototyp už potřebuje profesionální audit?
Typickým signálem je práce s citlivými nebo zákaznickými daty, přihlášení více uživatelů, napojení na důležité firemní systémy nebo situace, kdy výpadek aplikace začne komplikovat běžný provoz.
Musí se vibe coded aplikace předělat od začátku?
Často nemusí. Nejdřív má smysl zjistit technický stav, bezpečnost a udržovatelnost. Podle výsledku může stačit hardening, doplnění testů a dokumentace nebo postupný refactoring.
