Kód, který fungoval bezvadně – dokud nevydal 35 tisíc e-mailů. Rozhovor se SNADNEE o bezpečí AI-generovaného kódu

1,5 milionu přihlašovacích tokenů. 35 tisíc e-mailů. Tisíce soukromých zpráv. Tolik našli bezpečnostní výzkumníci v databázi aplikace Moltbook – a stačilo se jen podívat do kódu, který si stahuje každý návštěvník stránky. Její tvůrce ji postavil celou přes AI, byl na to hrdý a ještě pár týdnů předtím se tím pochlubil online. Nebyl hloupý ani nedbalý – jen netušil, co všechno se dá v takové aplikaci přehlédnout.

A přesně o tom je tenhle rozhovor. SNADNEE staví software na míru dvanáct let a poslední rok k tomu dělá něco nového: pomáhá lidem zjistit, co si vlastně s AI postavili. Říkají jednu věc, kterou stojí za to slyšet, ať kód píšete sami nebo ho necháváte na modelu – úhledný a čitelný kód ještě neznamená bezpečný. Mluvíme o tom, proč se to tak často stává, jak to poznat včas, a kde je ta hranice, za kterou se vyplatí nechat si to zkontrolovat zvenčí.

Kdybyste měli jednou větou vysvětlit, co dnes SNADNEE dělá a v jakém typu problémů jste klientům nejvíc užiteční, co by to bylo?

Vyvíjíme software na míru a nejužitečnější jsme ve chvíli, kdy něco ve firmě začalo fungovat a najednou na tom závisí provoz, peníze nebo data zákazníků, takže je potřeba udělat z toho systém, který tu zátěž unese.

SNADNEE je dnes AI heavy agentura. AI je součástí každodenní práce celého týmu, velkou část kódu generujeme, a stejným způsobem stavíme řešení klientům, ať už jde o funkce postavené na AI uvnitř jejich aplikací, nebo o automatizaci práce, kterou dosud dělali lidé ručně.

Software na míru přitom vyvíjíme dvanáct let, tedy i v době, kdy se každý řádek psal ručně. Díky tomu poznáme, kdy AI odvedla dobrou práci a kdy jen dobře vypadá. Nasazujeme ji proto naplno, ale nikdy bez výstupní kontroly. Vygenerovaný kód u nás prochází automatizovanými testy a revizí seniorního vývojáře stejně jako dřív kód psaný ručně. Tenhle postoj, tedy rychlost od AI a odpovědnost na straně lidí, stojí i za vznikem VibeAuditu.

Tvrdíte, že díky AI dodáváte zhruba o 35 % rychleji ve vyšší kvalitě – jaký je jeden konkrétní proces nebo guardrail, který vám to reálně umožnil (a nebyla to jen „lepší disciplína“)?

Ten guardrail zní nudně, ale je zásadní: nezměnili jsme definici toho, kdy je kód hotový. Vygenerovaný kód u nás vstupuje do procesu jako první verze od juniorního vývojáře. Nikdo mu nevěří jen proto, že vypadá dobře a funguje. Musí projít automatizovanými testy a revizí seniorního vývojáře, jinak se k zákazníkovi nedostane. Zrychlilo se psaní kódu, kontrola zůstala stejně přísná, a zrychlení pochází právě z toho rozdílu.

Proč na tom trváme, ukazují data. Veracode testoval přes sto jazykových modelů na bezpečnostně citlivých úlohách a 45 % vygenerovaných vzorků obsahovalo zranitelnost z žebříčku OWASP Top 10. Podstatnější než samotné číslo je jeho vývoj. Úspěšnost se napříč testovacími cykly od roku 2025 do jara 2026 prakticky nezměnila, přestože modely mezitím ve schopnosti psát funkční kód výrazně pokročily. Modely se učí psát kód, který funguje, ne kód, který je bezpečný. Kdybychom spolu s psaním zrychlili i kontrolu, dodávali bychom rychleji chyby.

Vibe coding se často popisuje jako rychlost a flow nad strukturou – v čem je podle vás jeho největší přínos a v čem je naopak nejzrádnější, když má z prototypu vzniknout produkt?

Přínos je obrovský a je konkrétní. Majitel půjčovny dnes o víkendu postaví rezervační systém, který by ho dřív stál stovky tisíc a půl roku čekání. Marketingový tým si vyrobí nástroj, na který by v běžném firemním rozpočtovém procesu nikdy nedosáhl. Software přestal být investice na pět let dopředu a stal se něčím, co si pořídíte na jeden konkrétní účel. Sami tímto způsobem pracujeme.

Nejzrádnější je to, že rychlost výroby vytváří falešnou jistotu. Stanfordská studie to zachytila přesně. Vývojáři, kteří pracovali s AI asistentem, psali méně bezpečný kód a zároveň byli přesvědčeni, že je bezpečnější než ten, který by napsali sami. Tady je jádro problému. Aplikace funguje, vypadá profesionálně, klikáte a všechno reaguje, takže není důvod pochybovat.

V praxi to vypadá takto. Půjčovna má rezervační systém, který bezvadně funguje, jenže databáze se jmény, telefony a adresami klientů je dostupná komukoli z internetu. E-shop bez potíží zvládá deset objednávek denně, ale jakmile jich přijde pět set a jeden zvědavý zákazník si přepíše číslo v adrese, uvidí cizí objednávky. Interní nástroj v marketingu slouží skvěle, dokud si někdo nevšimne, že přes něj odcházejí osobní údaje zákazníků do služby třetí strany.

Britský vývojář Simon Willison nabídl definici, která tu hranici popisuje nejlépe. O vibe coding jde tehdy, když necháte software napsat AI a její kód nečtete. Jakmile ho přečtete, otestujete a dokážete vysvětlit, děláte běžný vývoj softwaru. Okamžik, kdy se z rychlého řešení stává produkt, na kterém závisí firma, je přesně ten, kdy je nutné tuhle hranici překročit. Většina lidí na to zapomene, protože aplikace fungovala už předtím.

Když někdo postaví aplikaci „na vibe“ (v0/Lovable/Replit/Claude/Cursor), jaké tři typy chyb se vám v praxi opakují nejčastěji, i když ta aplikace na první pohled funguje?

Vyberu tři, se kterými se setkáváme opakovaně. Spojuje je to, že aplikace navenek funguje bez jediného problému.

  1. Celá databáze přístupná z internetu. Přístupový klíč k databázi je uložený v kódu, který si stáhne prohlížeč každého návštěvníka, a databáze nemá zapnutou ochranu na úrovni jednotlivých záznamů. Kdokoli si pak může všechna data stáhnout, případně i přepsat. Letos v únoru to potkalo síť Moltbook, kterou její tvůrce postavil celou přes AI a veřejně se tím chlubil. Výzkumníci ze společnosti Wiz našli klíč ve zdrojovém kódu stránky během několika minut a získali přístup k produkční databázi s 1,5 milionem autentizačních tokenů, 35 tisíci e-mailovými adresami a tisíci soukromími konverzacemi. Nešlo o žádný sofistikovaný útok, stačilo se podívat, co si prohlížeč stahuje. A není to ojedinělý případ. Analýza 1 645 aplikací zveřejněných na platformě Lovable ukázala, že zhruba 70 % z nich mělo tuto ochranu vypnutou úplně a přes 170 z nich reálně vydávalo osobní údaje.
  2. Rozbitá autorizace uvnitř aplikace. Aplikace ověří, kdo jste, v prohlížeči, ale server ani databáze si to už nezávisle nezkontrolují. V ukázce to nikdo neodhalí, protože každý testuje jen svůj vlastní účet. V praxi si přihlášený zákazník změní číslo v adrese a uvidí objednávky, faktury nebo dokumenty někoho jiného.
  3. Zneužitelné placené účty. Aplikace má otevřené místo, které volá placenou službu, typicky jazykový model, SMS bránu nebo rozesílání e-mailů, a nemá nastavený žádný strop. Útočník tak může provozovateli vygenerovat účet za desítky tisíc korun, aniž by se do aplikace vůbec přihlásil.

Co přesně je VibeAudit: pro koho je, co je jeho výstup a jaký problém řeší dřív, než se z rychlého prototypu stane bezpečnostní nebo provozní průšvih?

VibeAudit je služba od SNADNEE pro lidi a firmy, kteří si aplikaci postavili přes AI nástroje typu Cursor, Lovable, Bolt, v0, Claude Code nebo Replit, a nyní ji provozují nebo ji chtějí spustit.

Výstupem je report, který seřadí nálezy podle závažnosti. U každého je uvedeno, kde přesně se nachází, co reálně hrozí a jak jej opravit. Píšeme jej tak, aby mu rozuměl majitel firmy, nejen programátor, protože rozhodnutí o opravě obvykle dělá právě on. Součástí je společné projití reportu, aby zákazník věděl, co má řešit jako první.

Problém, který řešíme, je jednoduchý. Kdo si aplikaci postavil sám, nemá jak posoudit, co vlastně postavil. A pokud se zeptá AI, jestli je jeho aplikace bezpečná, s velkou pravděpodobností uslyší, že ano. Modely jsou trénované tak, aby odpovídaly přesvědčivě, nikoli aby vás varovaly.

Že je to naléhavé právě teď, má i právní rozměr. Při úniku osobních údajů má správce 72 hodin na ohlášení úřadu a musí umět doložit, že zavedl přiměřená bezpečnostní opatření. Od listopadu 2025 navíc platí nový zákon o kybernetické bezpečnosti, česká podoba směrnice NIS2, který dopadá na tisíce firem ve vyjmenovaných odvětvích, přenáší odpovědnost přímo na vedení společnosti a jeho přechodné období končí 1. ledna 2027. Aplikace, kterou si někdo v týmu postavil za víkend, je z pohledu regulace běžnou součástí firemní infrastruktury se vším, co k tomu patří.

Nabízíme tři úrovně podle hloubky, od rychlého bezpečnostního scanu po kompletní audit s návrhem oprav. Software na míru vyvíjíme dvanáct let, takže neposuzujeme jen to, zda kód běží, ale zda na něm může firma dlouhodobě stát.

Jak vypadá „dobrý nález“ z VibeAudit pohledu – dáte příklad jedné typické kritické chyby v AI-generovaném kódu a jak by měla vypadat její oprava, aby to nebyla jen kosmetika?

Dobrý nález poznáte podle toho, že mu zákazník rozumí a dokáže podle něj jednat. Nález, který nikdo neopraví, je k ničemu, i kdyby byl technicky naprosto správný.

Vezmu klasický příklad, rozbitou autorizaci. Přihlášený zákazník vidí cizí objednávky, když si v adrese změní číslo. Kosmetická oprava skryje v rozhraní tlačítko nebo odkaz, aby na cizí objednávku běžný uživatel neklikl. Záznam ale zůstává dostupný každému, kdo si číslo přepíše sám nebo se serveru zeptá přímo. Před náhodným zákazníkem jste se schovali, před tím, kdo data skutečně chce, nikoli.

Skutečná oprava přesune kontrolu tam, kam patří, na server a do databáze. U databáze jako Supabase to znamená zapnout ochranu na úrovni jednotlivých záznamů a nastavit pravidlo, že databáze sama odmítne vydat záznam, který nepatří přihlášenému uživateli, ať se ptá kdokoli a odkudkoli. Na frontend se nelze spoléhat jako na bezpečnostní hranici, ta musí být vždy na serveru a v databázi, které předpokládají, že každý požadavek může být nepřátelský.

Rozdíl mezi kosmetikou a skutečnou opravou se dá shrnout jedinou otázkou. Změnila oprava to, co uživatel vidí, nebo to, co server dovolí?

Vibe coding často znamená, že kód vypadá čistě, ale riziko je schované uvnitř – jaké signály v kódu nebo architektuře vás nejrychleji upozorní, že AI to „poskládala hezky“, ale ne bezpečně?

Nejrychleji nás upozorní tyto věci:

  • Autorizace je řešená pouze ve frontendu, server ani databáze nemají vlastní nezávislou kontrolu. Rozhraní vypadá dobře, ale dveře jsou otevřené.
  • Přístupové údaje a klíče jsou v kódu, který si stáhne prohlížeč, nebo přímo v repozitáři.
  • Databáze má ve výchozím nastavení povoleno vše, tedy vypnutou ochranu na úrovni záznamů a veřejné čtení.
  • Veškerá logika je natlačená do jednoho obřího souboru, bez jasných hranic a oddělení odpovědností.
  • Aplikace je označená za hotovou, ale nemá jediný automatizovaný test.
  • Vše funguje pouze na ideální cestě. Nikdo neřešil, co se stane při chybném nebo záměrně škodlivém vstupu.
  • V kódu jsou knihovny, které buď neexistují, nebo je nikdo nepotřebuje. Model si je vymyslel a nikdo to nekontroloval.

Nad tím vším stojí jeden hlavní signál. AI píše kód, který vypadá čistě, konzistentně a odborně, protože přesně to se naučila. Právě ta úhlednost uspává, protože čitelnost kódu nevypovídá o jeho bezpečnosti. Potvrzují to i data. Podle výroční analýzy společnosti GitGuardian obsahují commity psané s pomocí AI zapomenutá hesla a klíče zhruba dvakrát častěji než commity bez ní. Vypadají přitom stejně dobře.

Jak se VibeAudit doplňuje s lidským review: kde podle vás AI/automatizace vyhrává (rychlost, pokrytí) a kde bez seniorního úsudku pořád vznikají slepá místa?

Automatizace vítězí v pokrytí a rychlosti. Projede na každé aplikaci stejné stovky kontrol, neunaví se, nepřeskočí nudnou část a známé vzorce, jako je zapomenutý klíč nebo vypnutá ochrana databáze, najde během několika minut. To by člověk ručně nikdy nezvládl stejně spolehlivě.

Seniorní úsudek je nenahraditelný v tom, co daný nález v konkrétní aplikaci znamená. Zda jde o kritický problém, nebo o okrajovost, lze posoudit pouze v kontextu. Sem patří řetězení několika drobností do jednoho útoku, chyby v obchodní logice, které žádný scanner nerozpozná, protože vycházejí z toho, jak konkrétní firma funguje, a především převod nálezu do opravy, která sedí na danou aplikaci, místo obecné záplaty.

A jedna věc, která se často přehlíží. AI neumí spolehlivě zkontrolovat sama sebe. Studie z Carnegie Mellon na reálných úlohách zjistila, že funkční i bezpečné zároveň bylo zhruba každé desáté řešení vygenerované AI. Podstatnější je zjištění, které k tomu patří: explicitní pokyn, ať si model dá na bezpečnost pozor, tu mezeru nezavřel. Jiná analýza ukázala, že opakované iterace s AI nad stejným kódem počet kritických zranitelností spíše zvyšují než snižují. Požádat AI, ať zkontroluje kód, který sama napsala, tedy problém neřeší. Roli kontrolora musí zastat někdo zvenčí.

Hranici lze shrnout jednoduše. Stroj řekne, co je špatně. Člověk řekne, co to pro vás znamená a co s tím. Máme to nakonec i na tričkách: postaveno citem, prověřeno rozumem.

Kdybyste měli dát jeden praktický „vibe coding checklist“ pro týmy, které chtějí rychle stavět s AI, ale zároveň nechtějí zničit budoucí údržbu, co by v něm určitě bylo?

Sedm bodů, které se dají zvládnout od prvního dne:

  1. Žádné klíče a hesla ve frontendu ani v repozitáři. Patří na server a do proměnných prostředí.
  2. Autorizace na serveru a v databázi, nikoli v prohlížeči. Zapnout ochranu na úrovni záznamů, nastavit pravidla a vycházet z toho, že každý požadavek může být nepřátelský.
  3. Zastropovat vše, co stojí peníze, tedy placené služby, e-maily, SMS i volání jazykových modelů. Bez limitu může kdokoli utrácet peníze provozovatele.
  4. Automatizované testy od začátku, alespoň na kritické cesty, jako je přihlášení, platby a přístup k datům. Ruční proklikání není testování.
  5. Ověřovat vstup od uživatele na serveru, nejen v prohlížeči.
  6. Sepsat, co aplikace dělá, kde běží a jak se provozuje. Jinak celá firma tiše závisí na jediném člověku, který ji postavil a který může odejít.
  7. Předem si určit hranici, za kterou už aplikace potřebuje kontrolu zvenčí. Typicky ve chvíli, kdy začne pracovat s osobními údaji, s platbami nebo s daty zákazníků.

K poslednímu bodu jedna poznámka. Jindřich Fáborský ve svém rozdělení úrovní vibe codingu uvádí produkční aplikace až jako nejvyšší patro, ke kterému patří stovky hodin praxe a bezpečnostní audit. S tím souhlasíme. Interní nástroj, který si uděláte na jedno odpoledne, nikdo auditovat nemusí. Aplikace, do které vkládají data vaši zákazníci, je jiná kategorie.

Jak podle vás bude vypadat vibe coding za 12–18 měsíců: co se zlepší díky AI agentům a co naopak zůstane „lidská odpovědnost“, i kdyby modely byly o řád chytřejší?

Zlepší se to, co je dnes rutina. Agenti budou spolehlivěji hlídat běžné chyby, lépe generovat opakující se části kódu a část kontroly zvládnou sami. Laťka toho, co je automaticky v pořádku, se zvedne, a to je dobře.

Zajímavý signál přišel od Andreje Karpathyho, který pojem vibe coding v roce 2025 zavedl. Letos v únoru se od něj posunul a začal mluvit o agentním inženýrství. Člověk, který tomu dal jméno, strávil rok tím, že se od volnější podoby té praxe postupně vzdaloval. Docela dobře to popisuje směr celého oboru, tedy posun od nadšení z rychlosti k disciplíně.

Data zatím ukazují opačný trend, než jaký bychom si přáli. Projekt Vibe Security Radar na Georgia Tech sleduje zranitelnosti prokazatelně způsobené AI nástroji a jejich měsíční počet během prvního čtvrtletí 2026 vzrostl ze šesti na třicet pět. Výzkumníci odhadují, že skutečné číslo je pětkrát až desetkrát vyšší. Množství kódu roste rychleji než schopnost ho kontrolovat, a tahle mezera se v nejbližších měsících spíš rozšíří.

Lidskou odpovědností zůstane úsudek a ručení za výsledek. Někdo musí převzít rozhodnutí, že daná aplikace je dostatečně bezpečná na to, aby na ní stála firma. Model, ať je jakkoli chytrý, nenese následky za únik dat ani za pokutu od úřadu. Ty nese konkrétní člověk. Nový zákon o kybernetické bezpečnosti to ostatně říká napřímo, když odpovědnost adresuje vedení společnosti. Odpovědnost se delegovat nedá, ani na velmi dobrý model.

A platí to i obráceně. Čím více kódu píše AI, tím cennější je člověk, který jej dokáže ověřit. To je nakonec celý důvod, proč VibeAudit existuje.