Ešte pred dvomi rokmi ste na jednoduchú landing page alebo automatizáciu potrebovali programátora. Dnes stačí popísať, čo chcete, a AI nástroj ako Cursor, Base44, Lovable alebo Claude vám vygeneruje funkčný kód. Hovorí sa tomu vibe coding – kódovanie „podľa pocitu“, kde namiesto syntaxe riešite zámer.

Znie to ako sen pre každého, kto potrebuje rýchlo poskladať landing page k novej kampani, jednoduchý interný nástroj na reporting alebo automatizáciu medzi CRM a e-mailingom. A skutočne to sen byť môže, pokiaľ viete, kde sú hranice.

Vibe coding totiž nie je „napíš čokoľvek, ono to nejako pobeží“. Aj tu platia pravidlá, ktoré rozhodujú o tom, či vám vznikne šikovný nástroj, alebo diera v zabezpečení, cez ktorú unikne databáza kontaktov.

V tomto článku si prejdeme, čo funguje v praxi podľa odporúčaní odborníkov na produktový vývoj a bezpečnosť, a ako sa vyhnúť najčastejším chybám, ktoré sa v AI generovanom kóde objavujú znova a znova.

Čo presne je vibe coding

Vibe coding je spôsob tvorby softvéru, pri ktorom opisujete zadanie v bežnej reči a AI agent za vás napíše kód. Vy zadanie spresňujete, výsledok testujete a agent chyby opravuje. Ide teda o dialóg, nie o jednorazové zadanie úlohy.

Vytvoriť si tak viete napr.:

  • rýchlu landing page k PPC kampani, ktorú by inak museli programovať programátori,
  • interný dashboard, ktorý ťahá dáta z Google Analytics alebo Search Console a prehľadne ich zobrazuje,
  • jednoduchý formulár alebo kalkulačku na webe, ktorá zbiera leady,
  • automatizačný skript, ktorý prepája formulár s CRM alebo e-mailovým nástrojom.

Práve preto, že tieto nástroje často pracujú s údajmi o zákazníkoch, je obozretnosť okolo vibe codingu dôležitejšia, než by sa na prvý pohľad zdalo.

Promt v Claudovi vytvor mi vlastnú predajnú landing page v php nna môj hosting

Zdroj: Cursor

Najskôr plán, potom kód

Najčastejšia chyba je otvoriť AI nástroj a rovno napísať „sprav mi formulár na zber leadov s uložením do databázy“. Výsledok sa väčšinou dá použiť, ale o týždeň zistíte, že sa v ňom nedá nič meniť bez toho, aby sa pokazilo niečo iné.

Osvedčený postup je pracovať v dvoch fázach:

  1. Najprv plán, nie kód. Požiadajte agenta, nech vám najskôr napíše plán riešenia, čo presne vytvorí, aké kroky bude obsahovať a čo od vás bude potrebovať. Plán si prečítajte, upravte, prípadne ho nechajte skontrolovať iným AI nástrojom. Iterovať na pláne je oveľa rýchlejšie a lacnejšie než iterovať na hotovom kóde.
  2. Až potom implementácia. Keď je plán jasný, spustite novú konverzáciu a nechajte agenta plán zrealizovať. Výstup si nechajte skontrolovať ideálne iným agentom alebo aspoň v samostatnom kroku so zameraním na tri veci: ako sa spracúvajú chyby, či existuje aspoň základné testovanie a ako je to s bezpečnosťou.

Tento prístup vám ušetrí to, čomu sa v komunite hovorí „doom loop“, teda stav, keď agent dokola opravuje ten istý problém a vy strácate čas aj nervy.

Držte kontext pod kontrolou

AI agent pracuje s tým, čo mu dáte do kontextu, teda s históriou konverzácie, prípadne s konfiguračným súborom projektu. Čím je tento kontext prehľadnejší, tým presnejšie výsledky dostanete.

V praxi to znamená: Keď prejdete na novú funkciu (napríklad z landing page prejdete na automatizáciu e-mailov), začnite radšej novú konverzáciu alebo kontext vyčistite. Staré zadania a experimentálne poznámky agenta zbytočne mýlia a vedú k tomu, že vám „opraví“ niečo, čo ste už dávno vyriešili inak.

Ak pracujete na väčšom projekte opakovane, oplatí sa mať jeden krátky súbor so zhrnutím, čo projekt robí, aké má obmedzenia a čo je „zakázaná zóna“ (napríklad prihlasovanie alebo platby, do ktorých nemá agent bez dozoru zasahovať).

Tri vrstvy, ktoré musia spolu sedieť

Každá aplikácia, aj tá najjednoduchšia, má tri vrstvy:

  • dáta (kde sa informácie ukladajú),
  • logiku (ako s nimi aplikácia narába),
  • rozhranie (čo vidí používateľ).

Väčšina chýb, ktoré vibe coding produkuje, vzniká práve vtedy, keď sa zmení jedna vrstva a ostatné dve nie.

Typický príklad z marketingovej praxe:
Pridáte do formulára nové pole (napríklad „súhlas s odberom noviniek“), agent upraví rozhranie, ale zabudne pole pridať do databázy alebo do validácie na strane servera. Formulár vyzerá funkčne, dáta sa ale nikam neukladajú alebo sa ukladajú nesprávne. Preto je dobré po každej zmene vyskúšať celý tok od začiatku do konca, nielen tú časť, ktorú ste práve menili.

Bezpečnosť: Kde vibe coding najčastejšie zlyháva

Toto je časť, ktorú marketéri (ale často aj samotní vývojári pracujúci s AI) podceňujú najviac. AI modely sú natrénované na obrovskom množstve kódu vrátane toho, ktorý bezpečnostné zásady nedodržiava a majú tendenciu vyberať najjednoduchšie riešenie, nie najbezpečnejšie. Experti na bezpečnosť opakovane upozorňujú na rovnaký okruh problémov.

API kľúče a heslá priamo v kóde

Toto je zďaleka najčastejšia chyba. Agent vloží kľúč k platobnej bráne, e-mailovému nástroju alebo AI API priamo do súboru, ktorý beží v prehliadači, čiže je čitateľný pre kohokoľvek, kto si otvorí zdrojový kód stránky.

Zdokumentované sú prípady, keď takto unikol napríklad kľúč ku cloudovému účtu a spôsobil škody v desiatkach tisíc eur. Ak si napríklad necháte spraviť formulár, ktorý posiela z prehliadača dáta priamo do vášho e-mailového nástroja, vždy sa pýtajte, kde presne sa prihlasovací kľúč nachádza.

Chýbajúca kontrola, kto má na čo právo

Predstavte si interný nástroj, kde si každý zamestnanec pozerá výkony vlastných kampaní podľa ID. Ak aplikácia neoveruje, či ID naozaj patrí prihlásenému používateľovi, stačí zmeniť číslo v adrese a uvidíte dáta kolegu. Tento typ chyby (IDOR) patrí medzi najčastejšie v AI generovanom kóde práve preto, že „to funguje“ aj bez tejto kontroly, až kým chybu niekto zámerne alebo náhodou neobíde.

Neošetrený vstup od používateľa

Ak máte na webe vyhľadávanie, filter alebo formulár, ktorý si niekde „pod kapotou“ skladá databázový dopyt priamo z toho, čo napíše návštevník, hrozí takzvaný SQL injection – útočník do poľa napíše špeciálny reťazec a namiesto výsledku hľadania dostane celú databázu. Rovnaký princíp platí pre polia, ktoré sa priamo zobrazujú iným návštevníkom (napríklad komentáre alebo recenzie). Bez správneho ošetrenia sa dá cez ne vložiť škodlivý skript.

Halucinované a nebezpečné knižnice

AI agent niekedy odporučí a nainštaluje balík, ktorý reálne neexistuje alebo existuje pod iným menom. Útočníci tento vzorec poznajú a neexistujúce názvy balíkov si zámerne registrujú so škodlivým kódom vo vnútri. Keď vám agent navrhne inštaláciu novej knižnice, overte si, že skutočne existuje a má aktívnu komunitu.

Chýbajúce základné zabezpečenie prihlásenia

Slabé alebo predvídateľné session tokeny, chýbajúce obmedzenie počtu pokusov o prihlásenie, heslá uložené nešifrovane alebo zastaraným spôsobom – toto všetko sú veci, ktoré AI agent bez explicitného zadania jednoducho nevyrieši sám od seba.

Spoločný menovateľ všetkých týchto problémov je jeden: Agent urobí presne to, o čo ste ho požiadali, no bezpečnosť si musíte výslovne vyžiadať. „Urob mi prihlasovací formulár“ a „urob mi prihlasovací formulár s bezpečným ukladaním hesiel a ochranou proti opakovaným pokusom“ môžu z pohľadu agenta vyzerať ako dve rôzne zadania a v praxi aj sú.

Riziká, ktoré sa neukážu, kým ich niekto nehľadá

Okrem chýb priamo v kóde má vibe coding aj rizikovú vrstvu okolo nasadenia, teda okolo toho, ako sa hotový projekt dostane na hosting a čo tam po sebe zanechá. Práve tieto veci si AI agent sám od seba nedorieši a bežne o nich ani neinformuje.

Vkladanie prihlasovacích údajov priamo do chatu s agentom

Keď potrebujete, aby agent nastavil pripojenie k databáze, e-mailovému API alebo platobnej bráne, je lákavé mu jednoducho vložiť heslo alebo API kľúč do správy. Problém je, že tieto údaje sa tak stanú súčasťou histórie konverzácie, a tá sa môže niekde uložiť, zálohovať alebo v horšom prípade zdieľať pri riešení problému s podporou. Citlivé údaje patria do premenných prostredia (environment variables) alebo bezpečného úložiska tajomstiev, nikdy nie do textu zadania.

Vkladanie prihlasovacích údajov priamo do chatu s agentom

Zdroj: Cursor

Verejne dostupné SQL zálohy a exporty databázy

Pri práci na webovom projekte agent často vytvára zálohu databázy (napríklad database.sql, backup.sql alebo dump.sql), aby mohol testovať zmeny. Ak takýto súbor ostane v priečinku, ktorý je dostupný cez webový prehliadač, ktokoľvek si vie stiahnuť presnú štruktúru tabuliek, názvy stĺpcov a v horšom prípade aj reálne dáta vrátane kontaktov, objednávok alebo hesiel. Aj samotná štruktúra databázy bez dát je pre útočníka cenná, pretože mu ukáže, ako presne je aplikácia postavená a kde hľadať jej slabiny.

Prístupové údaje uložené v koreňovom priečinku webu, nie mimo neho 

Súbor s citlivými údajmi (napríklad .env alebo konfiguračný súbor s heslom k databáze) by mal ležať mimo verejne dostupnej zložky webu, teda tam, kam sa cez prehliadač nedá dostať ani náhodou. Vibe coding nástroje bežne umiestnia všetko do jedného projektového priečinka bez tohto rozlíšenia, takže stačí, aby sa server niekde pomýlil v nastavení (alebo aby administrátor zabudol zablokovať prístup k .env súborom) a citlivé údaje sú verejne čitateľné len zadaním správnej adresy.

Prístupové údaje uložené v koreňovom priečinku webu, nie mimo neho

Zdroj: Cursor

Zabudnuté vzorové súbory

Agent pri nastavovaní projektu často vytvorí vzorový konfiguračný súbor (napríklad config.example.php, .env.example), ktorý má slúžiť len ako šablóna. Niekedy sa však do neho počas testovania omylom dostanú aj reálne prístupové údaje alebo súbor aspoň prezradí presnú štruktúru konfigurácie – názvy premenných, formát pripojenia k databáze, mená interných služieb. To útočníkovi zjednoduší cielený útok, aj keby v ňom reálne heslo nebolo.

Zabudnuté vzorové súbory do Claude

Zdroj: Cursor

Nesprávne nastavené oprávnenia súborov na serveri

Každý súbor a priečinok na hostingu má nastavené, kto k nemu smie pristupovať a ako (čítanie, zápis, spúšťanie). AI agent pri nasadení tieto oprávnenia zväčša nerieši vôbec alebo ich nastaví najjednoduchšie, teda najbenevolentnejšie, „aby to fungovalo“. V praxi to môže znamenať, že konfiguračný súbor s heslami je čitateľný pre kohokoľvek na zdieľanom hostingu, alebo že do priečinka s nahrávanými súbormi (napríklad obrázkami z formulára) sa dá nahrať aj spustiteľný skript.

Zabudnuté inštalačné a nastavovacie skripty

Mnoho systémov (napríklad redakčné systémy alebo hotové skripty tretích strán) používa pri prvom nastavení súbor typu install.php alebo setup.php, ktorý vytvorí databázu, založí administrátorský účet alebo nastaví základnú konfiguráciu. Po dokončení inštalácie by sa mal buď zmazať, alebo zablokovať, inak ho vie ktokoľvek spustiť znova a napríklad si vytvoriť vlastný administrátorský prístup do vášho systému. AI agenti si po sebe takéto súbory bežne neupratujú, pretože nevedia, že „inštalácia“ už z pohľadu produkcie skončila.

Čo si z toho odniesť?

Väčšina týchto rizík nesúvisí s tým, či agent napísal kód „správne“, ale s tým, čo po ňom ostalo v projekte a ako je nastavený samotný hosting. Preto sa oplatí urobiť si po nasadení krátku kontrolu priečinka na serveri a overiť si, že tam nezostali žiadne zálohy, vzorové konfiguračné súbory ani inštalačné skripty, a že citlivé údaje ležia mimo verejne dostupnej časti webu.

Praktický checklist pred spustením

Než akýkoľvek nástroj vytvorený vibe codingom nasadíte naostro (teda niekam, kam majú prístup reálni návštevníci alebo zákazníci), prejdite si aspoň toto minimum:

  • Skontrolujte, či sa niekde v kóde, ktorý beží v prehliadači, nenachádza prihlasovací údaj, API kľúč alebo heslo.
  • Overte, že formuláre validujú vstup aj na strane servera, nielen vizuálne v prehliadači. Vyskúšajte, či po prihlásení jedného účtu naozaj nevidíte dáta iného účtu len zmenou čísla v adrese.
  • Skontrolujte, či sú citlivé stránky (napríklad administrácia) chránené heslom aj na testovacej verzii.
  • Overte, že knižnice, ktoré agent nainštaloval, skutočne existujú a nie sú roky neaktualizované.
  • A napokon, majte spôsob, ako sa jedným krokom vrátiť k predchádzajúcej funkčnej verzii, ak sa niečo pokazí.

Ak si pri ktoromkoľvek bode nie ste istí, je to presne ten moment, kedy sa oplatí zapojiť niekoho z vášho vývojárskeho tímu na krátky code review. Vibe coding vám ušetrí týždne práce pri stavaní prvej verzie, nešetrite však na kontrole výstupu, ktorý ide live k reálnym používateľom.

Je vibe coding naozaj pre každého?

Okolo vibe codingu sa vytvorila takmer dogma, že technické znalosti sú prežitok a že si naozaj každý dokáže postaviť čokoľvek, len to treba „pekne opísať“. Znie to lákavo a čiastočne to aj funguje – presne preto je to nebezpečné. Marketér/ka dnes vie za minúty alebo jednotky hodín vytvoriť landing page alebo formulár bez čakania na programátorov. Kde to ale prestáva fungovať, je presvedčenie, že architektúra, bezpečnosť a základná orientácia v tom, ako web funguje, sú zbytočná nadstavba pre „starú školu“ vývojárov.

To je omyl. Neznalosť sa nevytráca len preto, že výstup vyzerá funkčne. Funkčnosť a bezpečnosť sú dve rôzne veci a AI agent vám rozdiel medzi nimi sám neoznámi. Formulár odošle dáta, stránka funguje, no to, či sú heslá uložené bezpečne, alebo či niekde neleží zabudnutá záloha databázy, výstup nepovie. Chyba sa prejaví až vtedy, keď ju niekto zámerne začne hľadať a vtedy už býva neskoro.

Druhým úskalím je údržba. Nástroj postavený za popoludnie bez akejkoľvek architektonickej úvahy sa rovnako rýchlo rozbije ďalšou úpravou. Vibe coding je skvelý na prvú verziu. Pri dlhodobom raste projektu príde moment, kedy je lacnejšie zapojiť skúseného vývojára, než opravovať nabaľujúce sa provizóriá.

Čo teda naozaj potrebujete? Nie syntax. Základnú orientáciu v tom, čo je databáza, server a čo sa deje v prehliadači. Disciplínu pýtať sa agenta nepríjemné otázky („kde sa ukladá toto heslo?“, „kto má prístup k tomuto formuláru?“) namiesto spokojnosti s prvým fungujúcim výsledkom.

Vibe coding nie je zázrak ani hazard, je to nástroj, ktorý násobí to, čo doň vložíte. V rukách niekoho, kto rozumie základným princípom, šetrí čas. V rukách niekoho, kto uveril, že technické znalosti už netreba, je len rýchlejšou cestou k problému, ktorý si všimne až niekto iný.