Vibe coding není problém. Problém je, že přestáváme rozumět vlastním aplikacím.

Začátkem roku 2025 popsal Andrej Karpathy nový způsob vývoje, který nazval vibe coding. Místo psaní kódu programátor popisuje záměr přirozeným jazykem, AI generuje implementaci a člověk se soustředí hlavně na výsledek.

To, co začalo jako způsob rychlého prototypování, se během jediného roku dostalo do běžné praxe. AI asistenty dnes používá velká část profesionálních vývojářů a stále častěji se dostává do produkce kód, který nikdo detailně nekontroloval. Největší riziko přitom není v tom, že AI občas udělá chybu. Riziko vzniká ve chvíli, kdy se přestane kontrolovat, co AI vytvořila.

Stejné chyby, jiná příčina

Když AI generuje kód, snaží se vytvořit řešení, které splní zadání. Bezpečnost není jejím primárním cílem. Modely se učí z obrovského množství existujícího kódu a ten obsahuje nejen dobré postupy, ale i historické chyby, zastaralé vzory a nebezpečné zkratky. SQL injection ani špatná databázová oprávnění nejsou nic nového. V aplikacích se objevují už desítky let. Co je nové, je cesta, jak se do produkce dostávají.

Dřív někdo ten kód napsal a většinou si alespoň pamatoval proč. Pamatoval si, že tady vědomě obešel validaci kvůli deadlinu, že tamten endpoint spoléhá na to, že ho volá jen interní služba, že oprávnění řeší jiná vrstva. To porozumění bylo někde uložené. Když ne v komentáři, tak aspoň v hlavě člověka, kterého šlo najít a zeptat se.

Dnes se stále častěji dostáváme do situace, kdy se kód dostává do produkce, aniž by mu někdo skutečně rozuměl. A to je bezpečnostní problém sám o sobě. Nezávisle na tom, kolik konkrétních zranitelností v něm zrovna je.

Co reálně vidím při testech

Při testech se hodně setkávám s kódem, který je funkční, ale nemá konzistentní bezpečnostní model. Jedna část aplikace validuje vstupy správně, druhá vůbec. Jeden endpoint kontroluje oprávnění poctivě, jiný mlčky předpokládá, že to vyřeší frontend. Autentizace je na třech místech ošetřená třemi různými způsoby. Je vidět, že jednotlivé části vznikaly izolovaně a nikdo neověřil, že dohromady dávají bezpečnostně konzistentní celek.

Nemůžu s jistotou poznat, jestli ten kód napsala AI, tři nesladěné týmy nebo je to způsobeno desetiletím technického dluhu. Na výsledku to ale nic nemění. Otisk je stejný, ať ho zanechal model, nebo nekoordinovaný tým. Vypadá identicky, protože má identickou příčinu. Jednotlivé kusy vznikaly bez někoho, kdo by držel v hlavě celek a hlídal švy mezi nimi. AI tenhle problém nevynalezla. Jen ho zlevnila a zrychlila natolik, že z výjimky dělá standard.

Dřív stálo úsilí vyrobit aplikaci, které nikdo nerozumí. Dnes je to nejsnazší možný výstup.

Moltbook jako potvrzení

Dobře to ilustruje případ Moltbooku. Jde o sociální síť pro AI agenty, postavenou výhradně pomocí vibe codingu. Zakladatel veřejně přiznal, že nenapsal jediný řádek kódu sám.

Do 72 hodin od spuštění aplikace exponovala 1,5 milionu autentizačních tokenů a desítky tisíc emailových adres. Nešlo o žádný sofistikovaný útok. Příčinou byla databáze ponechaná s veřejným přístupem pro čtení i zápis. Miskonfigurace, kterou by zkušený inženýr při běžné kontrole pravděpodobně zachytil během několika minut. Nešlo o chybu v rozhodování. Šlo o absenci rozhodování. Nikdo to nerozhodl, takže nikdo nevěděl, že je co kontrolovat.

Výzkumy potvrzují stejný trend

Že nejde o ojedinělý případ, potvrzuje i Veracode, který při testování více než stovky modelů zjistil, že přibližně 45 % vygenerovaných řešení obsahovalo zranitelnosti spadající do OWASP Top 10. A jejich opakovaná měření ukazují, že se to s novějšími a „chytřejšími" modely nezlepšuje. Modely se učí psát funkčnější kód, ne bezpečnější.

Stejný trend sleduje také Georgia Tech prostřednictvím projektu Vibe Security Radar. Ten mapuje veřejně evidované zranitelnosti vzniklé v souvislosti s AI generovaným softwarem, a jejich počet během roku 2026 rychle rostl.

Ale všimněte si, že tyhle čísla jsou vlastně až druhotné. Kdyby ten kód někdo skutečně chápal a vlastnil, spousta nálezů by se z velké části odchytala u kontroly. Problém není, že AI tu zranitelnost vygeneruje. Problém je, že ji nikdo neuvidí, protože nikdo ten kód nečte s porozuměním.

Jak si porozumění udržet

Řešením není AI zakázat. Stejně jako není řešením přestat používat frameworky, open source knihovny nebo cloudové služby. Důležité je záměrně udržovat vlastnictví nad tím, co nasazujete:

1. Nutíte model vysvětlit, ne jen vygenerovat. Než cokoli přijmete, ptejte se: „Jaké jsou bezpečnostní rizika tohoto přístupu a proč jsi ho zvolil?" Cílem není jen bezpečnější výstup, ale hlavně abyste vy rozuměli, proč to tak je. Ta odpověď je dokumentace rozhodnutí, která by jinak chyběla.

2. Berete AI jako juniorního vývojáře. Jeho PR procházejí stejnou kontrolou jako od kteréhokoli juniora. Ne proto, že je AI hloupá, ale proto, že nenese odpovědnost ani paměť.

3. Hlídáte švy, ne jen kusy. Jednotlivé komponenty můžou být v pořádku a celek přesto nekonzistentní. Ověřte explicitně, že autentizace, autorizace a validace fungují stejně napříč celou aplikací. To je práce, kterou za vás model neudělá, protože nikdy nevidí celý systém najednou.

4. Default-deny na produkční konfigurace. Než cokoli nasadíte, ručně ověřte databázová oprávnění a scope klíčů. Na tomhle samém padl i Moltbook. Výchozí nastavení, které nikdo nepřeklopil do restriktivního režimu.

Co si z článku odnést

Největší riziko vibe codingu není, že AI občas vytvoří zranitelnost. To je řešitelné přes kontroly, testy, skenery. Tohle všechno umíme dvacet let. Největší riziko je, že organizace začne ztrácet porozumění vlastním systémům. Že se kód, infrastruktura a bezpečnostní předpoklady přesunou do produkce, aniž by za nimi stál někdo, kdo ví, proč jsou takové, jaké jsou. Kód, kterému nikdo nerozumí, se totiž velmi špatně opravuje, audituje a zabezpečuje. A bezpečnost se vždycky rozpadá nejrychleji tam, kde chybí porozumění.