vibe-coding

Kedy vibekódovať aplikáciu a kedy nie

Vibe coding dramaticky znížil cenu prvého pokusu v softvérovom vývoji. Kedy sa doň pustiť, kedy nie, a prečo tým neberiete prácu developerom, práve naopak.

Igor Šovčík

02 júl 2026 9 min

Photo by Bharath Kumar / Unsplash

Tento článok píšem trochu z nevyhnutnosti. V mojom okolí pribúda ľudí, ktorí nie sú developeri, no s pomocou LLM systémov začínajú stavať vlastné aplikácie, interné nástroje a automatizácie. Nadšenie je pochopiteľné. Prvýkrát v histórii softvérového vývoja sa dá veľa vecí postaviť bez toho, aby človek najprv roky študoval programovanie alebo hľadal voľného developera.

Lenže práve preto je potrebná triezvosť. Vibe coding je právom jedna z najzaujímavejších vecí, ktoré sa za posledné roky udiali v softvérovom vývoji. Významne znížil cenu prvých pokusov a často aj následných úprav. Zároveň však nezrušil technickú zložitosť. Iba ju posunul bližšie k ľuďom, ktorí sa s ňou doteraz nemuseli stretávať.

Veci, ktoré kedysi potrebovali zadanie, rozpočet, developera a týždne čakania, dnes postavíte za večer. Interný nástroj, jednoduchý dashboard, automatizácia, formulár, workflow, malá aplikácia nad databázou. Všetko vzniká rýchlejšie, než kedykoľvek predtým.

💡

Prvá otázka nie je, či AI dokáže napísať aplikáciu. Pravdepodobne dokáže. Pýtajte sa, či máte dostatočnú afinitu k učeniu sa nových vecí a riešeniu komplexných problémov.

Vibe coding okrem vývoja zrýchlil ešte jednu vec, k technickej zložitosti vás privedie priamo. Ak nemáte hlboký technologický background, problémy prídu. Prídu pri databáze, deploymente, autentifikácii, prístupoch, API kľúčoch, logoch, rate limitoch, DNS, migráciách, backupe, hostingu, bezpečnosti, testovaní a obnove dát.

Do vibe codingu by sa mal púšťať hlavne ten, koho prirodzene baví učiť sa, rozpletať problémy a postupne chápať systémy. Ak chcete iba výsledok bez učenia, rýchlo narazíte. Aplikácia síce vznikne, ale prvý vážnejší problém bude pôsobiť ako cudzí jazyk.

Najprv sa naučte jazyk, ktorým budete hovoriť s agentom

Človek nemusí byť developer, aby vedel vibekódovať. Musí si však osvojiť základnú ontológiu softvérového vývoja: slová, vzťahy a koncepty, cez ktoré bude s agentom komunikovať.

Ak neviete, čo je Git, commit, branch, pull, push, merge, deploy, environment variable, database migration, API endpoint, authentication, authorization, rate limit, webhook, cron job, log, backup, rollback alebo production, dobré otázky klásť nedokážete.

⚠️

Agent odpovedá hlavne na položené otázky. Často nevysvetlí riziko, na ktoré sa nepýtate. Poviete "postav mi aplikáciu" postaví ju. Nespýtate sa na bezpečnosť, nemusíte dostať odpoveď. Nespýtate sa, čo sa stane pri výpadku API, nemusí sa tým zaoberať.

Pri vibe codingu sa naučte nielen promptovať, ale aj pomenovať oblasti, na ktoré sa treba pýtať. Tieto otázky si klaďte opakovane pri návrhu, pred implementáciou, pred deployom aj po nasadení.

Ako mám vyriešenú bezpečnosť?
Kto má prístup k dátam?
Sú API kľúče uložené bezpečne?
Čo sa stane, ak externé API zlyhá?
Mám rate limiting?
Mám monitoring nákladov?
Kde sa logujú chyby?
Ako obnovím dáta zo zálohy?
Čo sa stane pri zlom deployi?
Vie túto aplikáciu prevziať iný developer?
Aké sú najväčšie technické riziká tohto riešenia?

⚠️

Dôležité varovanie: zo stochastickej povahy týchto systémov, v prípade neistoty odporúčam položiť tú istú otázku rôznym spôsobom aj viackrát. Netreba zabúdať na to že modely notoricky klamú.

Vytvorte si vlastné pravidlá pre agenta

Ak vibekódujete pravidelne, nezačínajte každý projekt od nuly. Vytvorte si vlastný rámec pravidiel pre agenta. V niektorých nástrojoch je to AGENTS.md, inde projektové inštrukcie, system prompt či custom instructions.

Agent tak bude opakovane pracovať podľa rovnakých štandardov.

Čo má obsahovať:

Preferovaný stack (frontend, backend, databáza)
Štruktúra projektu a konvencie pomenovaní
Ako sa rieši bezpečnosť a secrets
Práca s environment premennými
Git workflow a commit konvencie
Čo má agent skontrolovať pred každou zmenou
Čo nikdy nemá robiť (nepísať secrets do kódu, nerobiť veľké zmeny bez vysvetlenia)
Pri platených API vždy riešiť limity
Pri deploymente myslieť na rollback
Pri návrhu UI najprv vysvetliť používateľský tok

Bez rámca sa agent správa ako šikovný človek s čistou hlavou a bez histórie. Pri serióznejšom vibe codingu je to problém.

Minimálny základný stack, alebo 10 vecí, bez ktorých nechoďte do produkcie

Každá vibekódovaná aplikácia, ktorá má ísť ďalej než lokálne demo, potrebuje minimálny technický základ. Desať pilierov, ktoré oddeľujú experiment od použiteľného systému.

Git: bez neho nemáte históriu, návrat späť ani spôsob, ako projekt prevziať. Commitujte často, robte malé zmeny.
Repozitár (GitHub, GitLab): lokálny priečinok nestačí. Základ spolupráce, zálohy kódu a budúceho review.
Jasný stack: frontend framework, backend framework, databáza, autentifikácia, hosting, spôsob deployu. Nemusí byť dokonalý. Musí byť zrozumiteľný a prevzateľný.
Environment premenné: API kľúče, tokeny, heslá a secrets nepatria do kódu. .env lokálne, bezpečné nastavenia hostingu v produkcii.
Databáza s migráciami: ak aplikácia zapisuje dáta, potrebujete vedieť, ako sa mení štruktúra databázy a ako zmenu vrátiť.
Autentifikácia a autorizácia: nestačí vedieť, kto je prihlásený. Treba vedieť, čo môže robiť.
Hosting a deploy: musí byť jasné, kde aplikácia beží, ako sa nasadzuje nová verzia a ako sa rieši rollback.
Logovanie a monitoring: ak aplikácia padá potichu, dozviete sa o tom až od používateľa a používateľ chyby nehlási, ten zruší predplatné.
Backupy: ak aplikácia zapisuje dôležité dáta, musí existovať plán obnovy. Backup, ktorý nikto neskúsil obnoviť, je len želanie.
Meranie používania: PostHog, Plausible, audit log alebo jednoduché eventy v databáze. Bez merania neviete, či aplikácia prináša hodnotu.

Kedy má vibe coding zmysel

Vibe coding dáva zmysel, keď riešite konkrétny opakovaný problém. Nie vtedy, keď máte všeobecnú túžbu "mať systém". Konkrétny problém znamená, že viete pomenovať používateľa, situáciu, frekvenciu a očakávaný prínos.

✅

Dobré dôvody: úspora času, zníženie chybovosti, rýchlejšie spracovanie dát, odstránenie ručného prepisovania, interný prototyp, validácia procesu, nástroj spájajúci viacero systémov.

❌

Slabý dôvod: úspora malej licencie. Ak platíte za existujúci nástroj pár tisíc eur ročne, vlastná náhrada väčšinou nedáva zmysel. Cena licencie je viditeľná. Skutočné náklady vlastného riešenia: údržba, bezpečnosť, hosting, zmeny, podpora a zodpovednosť.

Môže to znieť kontraintuitívne. Človek, ktorý pred AI nemal kapacitu na vývoj (všetok čas mu pohltila iná práca) dnes vibekóduje. Alebo to aspoň plánuje, keďže číta tento článok. Na prvý pohľad tým berie prácu developerovi. V skutočnosti ju práve začína vytvárať. Postaví MVP, narazí na limity a zistí, že potrebuje človeka, ktorý tomu rozumie hlbšie. Ako som písal v analýze vplyvu AI na trh práce, každá nová technológia, ktorá znižuje bariéru vstupu, v konečnom dôsledku zvyšuje dopyt po expertoch. Jevonsov paradox v praxi.

Vlastný softvér má zmysel vtedy, keď šetrí významný čas alebo vytvára schopnosť, ktorú hotový nástroj nevie dodať.

Pred tým ako začnete vyvíjať vlastný Google Workspace uistite sa, že nemá požadované funkcionality zabudované.

Kedy vibe coding nedáva zmysel

Nevibekódujte aplikáciu, ak neviete presne pomenovať používateľa, neviete povedať ako často sa bude používať, alebo ak nemá vlastníka.

Nevibekódujte ju ani vtedy, keď má nahradiť kritický systém bez plánu podpory. Kritický systém vyžaduje viac než experiment bez review.

🚨

Aplikácie pracujúce s peniazmi, citlivými dátami, zákazníkmi, právnymi dokumentmi, automatickými rozhodnutiami alebo platenými API volaniami môžu začať ako prototyp. Pred ostrým používaním ich však musí vidieť skúsený developer.

Funkčné demo a produkčný systém sú dve rôzne veci.

Bezpečnosť nie je formalita

Pri vibe codingu používajte špecializované security skills, bezpečnostné režimy alebo aspoň samostatné bezpečnostné prompty. Berte to ako pravidelný audit, nie formalitu.

Agentovi nestačí povedať, aby aplikáciu spravil bezpečne. To je príliš všeobecné. Prinúťte ho rozmýšľať v konkrétnych kategóriách.

🔒

Pýtajte sa ho priamo: Ako je riešená autentifikácia? Ako autorizácia? Kto má prístup k dátam? Môže používateľ vidieť dáta iného používateľa? Kde sú uložené secrets? Existujú audit logy? Kontrolujú endpointy oprávnenia aj na backendovej strane? Sú vstupy validované? Neposielajú sa citlivé dáta do logov? Existuje ochrana pred nadmerným používaním?

Namiesto vymýšľania vlastných bezpečnostných promptov siahnite po hotových riešeniach.

Cybersecurity Skills pokrýva OWASP audit, threat modeling, dependency scanning, breach patterns aj cloud security. Pridajte ho ako skill do vášho preferovaného agentického harnessu (claude code, open code, cursor, ...). Pri každej zmene, ktorá sa dotkne autentifikácie, API, platieb či citlivých dát, ho spustite znova.

Oddeľte tvorbu od kontroly. Najprv nech agent niečo postaví, potom ho prepnite do roly kritika. Ešte lepšie: použite iného agenta alebo iný model na review. Opakujte to vždy, keď pribudne autentifikácia, nové API, platby, import, export alebo integrácia s treťou stranou.

⚠️

Aj napriek všetkému hore písanému si treba uvedomiť, že agentické review nie je audit. Security skill nie je garancia bezpečnosti. Iný model ako kritik je užitočný, ale nie je to to isté ako penetračný test, code review, threat modeling alebo zodpovednosť človeka.

Použiteľnosť nad estetikou

Veľa vibekódovaných aplikácií je technicky funkčných, ale používateľsky chaotických: priveľa polí, nejasné stavy, zlé chybové hlášky, slabá navigácia. Neprezrádzajú používateľovi, čo sa práve deje.

Design skill aplikáciu nerobí krajšou. Robí ju zrozumiteľnejšou.

🎨

Pýtajte sa agenta: Kto je používateľ? Čo chce dosiahnuť? Aký je najkratší tok k výsledku? Kde môže spraviť chybu? Čo má vidieť ako prvé? Ktoré informácie sú zbytočné? Čo sa stane pri prázdnom stave? Čo sa stane pri chybe? Ako má vyzerať loading stav? Ako používateľ zistí, že akcia prebehla úspešne?

Na kontrolu použiteľnosti nemusíte písať vlastné prompty.

UI/UX Agent Skills premení agenta na dizajnového experta: 42 komponentov, WCAG 2.2 prístupnosť, 138 dizajn systémov, pravidlá pre akýkoľvek framework. Pridajte ho raz a agent pri každej zmene UI kontroluje konzistentne.

Platené API volania: najčastejšia pasca

V deme aplikácia zavolá OpenAI, Google Maps, Twilio alebo iný externý nástroj a všetko funguje. V produkcii to isté riešenie vytvorí nečakané náklady. AI často navrhne volať API pri každom načítaní stránky, pri každom kliknutí alebo v slučke.

💰

Každá aplikácia volajúca platené alebo limitované služby potrebuje: rate limiting, caching, monitoring spotreby, budget alerty a kill switch. Rate limiting nechráni len pred útokom. Chráni aj pred vlastnými používateľmi, opakovaným klikaním, zlým importom, bugom a nekonečnou slučkou.

Pýtajte sa agenta priamo:

Ktoré operácie v tejto aplikácii stoja peniaze?
Ako často sa môže API zavolať?
Máme cache? Denný alebo mesačný limit?
Čo sa stane po prekročení limitu?
Ako zabránime opakovanému spusteniu drahej operácie?

Merajte používanie od prvého dňa

Pri interných aplikáciách ľahko preceníte vlastný nápad. Funkcia, na ktorej ste robili týždne, môže ostať nepoužívaná. Malý škaredý nástroj môže denne šetriť hodiny práce. Preto merajte od prvého dňa.

Stačí PostHog, Plausible, audit log, jednoduché eventy v databáze alebo interný dashboard. Potrebujete vedieť: kto aplikáciu používa, ako často, ktoré funkcie žijú a ktoré sú mŕtve.

📊

Každá aplikácia musí mať kill kritérium. Ak po 30–60 dňoch nemá adopciu alebo merateľný prínos, vypnite ju, zmeňte alebo prestaňte rozvíjať.

Nepoužívaná aplikácia je technický dlh.

Rozhodovací strom

1. Baví vás učiť sa nové veci, riešiť zložité technické problémy a nebojíte sa riskovať?
├── NIE → Vibe coding nie je pre vás. Používajte hotové nástroje.
└── ÁNO → Pokračujte.
2. Riešite konkrétny opakovaný problém?
├── NIE → Nestavajte aplikáciu.
└── ÁNO → Pokračujte.
3. Šetrí významný čas, znižuje chybovosť alebo odstraňuje dôležité trenie?
├── NIE → Nestavajte ju.
└── ÁNO → Pokračujte.
4. Existuje hotový nástroj, ktorý to rieši dostatočne dobre?
├── ÁNO → Vlastné riešenie zvažujte veľmi opatrne.
└── NIE → Pokračujte.
5. Má aplikácia jasného vlastníka?
├── NIE → Najprv určte vlastníka.
└── ÁNO → Pokračujte.
6. Môže spôsobiť finančnú, dátovú, právnu alebo reputačnú škodu?
├── ÁNO → Prototyp áno, ale pred ostrým používaním review skúseným developerom.
└── NIE → ✅ Pripravte minimálny stack, meranie, Git, hosting, bezpečnosť a kill kritérium. Vibekódujte.

Checklist pred prvým deployom

Pred prvým ostrým nasadením potrebujete vedieť odpovedať na tieto otázky. Ak na väčšinu neviete odpovedať, máte demo, nie produkčný systém.

Kde žije kód, je v Gite?
Kde aplikácia beží?
Ako sa deployuje?
Kde sú uložené secrets?
Kto má prístup do aplikácie a kto do databázy?
Aké dáta aplikácia spracúva?
Sú dáta zálohované a bola obnova otestovaná?
Kde sú logy produkčného prostredia?
Ako zistím, že aplikácia padá?
Aké externé API voláme?
Ktoré API volania stoja peniaze a koľko?
Máme rate limiting? Monitoring nákladov?
Máme meranie používania?
Kto je vlastník?
Kedy aplikáciu vypneme?
Kto ju skontroloval, ak môže spôsobiť reálnu škodu?

Kedy okamžite prestať vibekódovať a zavolať developera

Keď vám pri pohľade na produkčné logy, chyby systému alebo rastúci účet za API vystúpia studené kvapky potu na čelo, je už neskoro. Developera zavolajte skôr: keď aplikácia spracúva osobné údaje, mení alebo maže dáta vo veľkom, používa platby, má viac rolí používateľov, verejný login, vytvára neočakávané náklady alebo keď nikto nevie obnoviť dáta zo zálohy.

Záver

Vibe coding je výborný nástroj na rýchle overenie nápadu, internú automatizáciu a hľadanie miest, kde sa vo firme stráca čas.

Kto sa doň pustí, musí sa učiť. Osvojiť si základný jazyk softvérového vývoja. Pýtať sa agenta správne otázky. Rozumieť tomu, že agent nerieši veci, na ktoré nebol navedený.

AI neodstránila zložitosť. Zmenila iba rozhranie, cez ktoré k nej pristupujeme.

🎯

Vibekódovaná aplikácia môže začať ako experiment. Ak však môže spôsobiť reálnu škodu, nesmie experimentom zostať. Vtedy potrebuje štandardný stack, meranie, bezpečnosť, backupy, limity, vlastníka a review skúseným developerom.