Vibe coding není bezmyšlenkovité mačkání Enteru. AI totiž udělá přesně tak dobrý produkt, jak dobrý je člověk za klávesnicí

Ještě před pár lety znamenalo vytvořit vlastní aplikaci týdny nebo měsíce práce, případně nutnost najít člověka, který ji dokáže naprogramovat. Dnes stačí otevřít Cursor, Claude Code nebo jiný AI nástroj, popsat, co chceme, a během jednoho večera může na localhostu běžet něco, co nápadně připomíná skutečný produkt.

Je to fascinující. A zároveň trochu nebezpečné.

S nástupem generativní AI se totiž extrémně zrychlilo nejen vytváření dobrého softwaru, ale také vytváření špatného softwaru. Rozdíl je v tom, že ten špatný dnes může vypadat překvapivě dobře.

Vím to z vlastní praxe. Čas od času se ke mně dostane projekt, který mám projít, převzít nebo zrevidovat. Na první pohled všechno funguje. Aplikace má pěkné rozhraní, uživatel se dokáže přihlásit, dashboard ukazuje grafy a několik hlavních funkcí skutečně něco dělá. Pak se ale člověk podívá o úroveň hlouběji.

Najednou zjistí, že část dashboardu stále stojí na mock datech. Git prakticky neexistuje nebo je historie projektu nepoužitelná. V repozitáři leží .env soubor s údaji, které tam nikdy neměly být. Bezpečnost se řešila stylem „AI napsala login, takže máme login“. V jedné části aplikace existují dvě různé implementace stejné funkce, protože při jednom z dalších promptů model místo úpravy původního řešení vytvořil nové.

A něco, co působilo jako hotová aplikace, je najednou spíš velmi přesvědčivá kulisa.

Přitom člověk, který ji vytvořil, často nic z toho netuší. Z jeho pohledu přece aplikace funguje.

A právě tady podle mě začíná být potřeba trochu přemýšlet nad tím, co dnes vlastně označujeme jako vibe coding.

Pojem se výrazně rozšířil na začátku roku 2025, kdy ho použil Andrej Karpathy. Popisoval způsob programování, při kterém se člověk přestává soustředit na jednotlivé řádky kódu a místo toho komunikuje s AI přirozeným jazykem, sleduje výsledek a postupně aplikaci upravuje.

Jeho původní popis byl navíc schválně poměrně extrémní. V podstatě popisoval situaci, kdy člověk přestane kód detailně číst, „odevzdá se vibes“, hlásí AI chyby a nechává ji, aby je opravovala.

Právě proto byl ten termín tak chytlavý. Dokonale vystihl moment, který v té době zažíval obrovský počet lidí: najednou jste nemuseli přesně vědět, jak napsat funkci nebo komponentu. Stačilo vědět, čeho chcete dosáhnout.

Jenže z meme se postupně stal téměř návod k vývoji.

Na sociálních sítích dnes vibe coding někdy působí jako specifický lifestyle. Notebook, terminál, vedle sklenka vína a série promptů. Udělej mi aplikaci. Enter. Přidej Stripe. Enter. Nefunguje přihlášení. Oprav to. Enter. Udělej deploy. Enter.

A ráno je z člověka údajně software founder.

Samozřejmě trochu přeháním. Jenže podobný způsob práce reálně existuje a jeho největším problémem není to, že při něm člověk používá AI. Problém je, že přestává rozhodovat.

AI totiž není někdo, komu jednoduše předáte celý projekt s větou „udělej to správně“.

Když jí řeknete, aby vytvořila autentizaci, autentizaci vytvoří. To ale ještě neznamená, že jste vyřešili oprávnění uživatelů, správu sessions, ukládání citlivých údajů, reset hesla, rate limiting nebo chování aplikace při útoku.

Když jí řeknete, aby vytvořila databázi, pravděpodobně nějakou vytvoří. Jenže sama od sebe nemusí vědět, jak bude aplikace vypadat za rok, jaká data budou kritická nebo jaké další služby na databázi později napojíte.

AI dokáže velmi dobře odpovídat na otázku „jak to mám udělat?“. Horší je to ve chvíli, kdy nikdo předtím pořádně neodpověděl na otázku „co vlastně děláme a proč?“.

V posledních letech se hodně mluvilo o prompt engineeringu. Kdo umí napsat dobrý prompt, údajně dostane dobrý výsledek. Jenže s tím, jak jsou modely schopnější, začíná být samotná formulace promptu méně důležitá než kontext, ve kterém AI pracuje.

Pokud modelu řeknu „vytvoř CRM“, může vytvořit CRM.

Pokud mu ale řeknu, že obchodníci pracují s několika typy klientů, existují tři uživatelské role, firma už používá konkrétní databázi, aktivita obchodníka se musí auditovat a systém se za půl roku bude napojovat na další službu, najednou je to úplně jiný problém.

A stále jsme se nedostali ke kódu.

Právě v tom podle mě spočívá schopnost, která bude s dalším rozvojem AI čím dál důležitější. Ne napsat kouzelnou větu, po které model vyplivne perfektní aplikaci, ale umět celý problém rozložit, rozhodnout, jaké informace AI potřebuje, kontrolovat její rozhodnutí a průběžně udržovat směr projektu.

Vibe coding proto nevnímám jako způsob, jak se procesu vývoje zbavit. Naopak. Je to možnost projít díky AI větší částí tohoto procesu sám.

Člověk může během jednoho dne přeskakovat mezi rešerší, návrhem produktu, UX, databází, implementací, testováním a deploymentem způsobem, který byl ještě nedávno pro jednotlivce prakticky nemožný. Nemusí být nejlepší programátor, nejlepší designer ani DevOps specialista. Musí ale alespoň vědět, že tyto vrstvy existují a že každá z nich má nějaké důsledky.

To je podle mě podstatně zajímavější definice vibe codingu než představa člověka, který jen celý večer mačká Enter.

Generativní AI má ještě jednu zvláštní vlastnost. Velmi rychle dokáže vytvořit pocit pokroku.

Před hodinou nebylo nic. Teď máme dashboard. Přidáme login a máme aplikaci. Přidáme platební bránu a máme SaaS.

Jenže vývoj produktu nikdy nebyl pouze o počtu viditelných funkcí.

Prototype klidně může obsahovat mock data. Jejich smyslem je rychle ukázat, jak by produkt mohl fungovat. Problém nastane ve chvíli, kdy už nikdo neví, že jsou to mock data.

Stejně tak může při rychlém experimentu vzniknout řešení, které není ideální z pohledu bezpečnosti nebo architektury. To samo o sobě nemusí být katastrofa. Katastrofa je pustit ho bez kontroly do produkce jen proto, že AI nikde nevypsala červené varování.

Dřív existovala alespoň přirozená brzda v podobě času. Špatná architektura se vytvářela pomalu. Dnes ji dokážeme pomocí AI během pár minut rozkopírovat do desítek souborů.

Čím rychleji tedy dokážeme tvořit, tím větší význam má schopnost se občas zastavit a zeptat se, co vlastně vzniklo.

Je to stále prototyp? Která data jsou skutečná? Co se stane, pokud uživatel udělá něco neočekávaného? Kde jsou uložené secrets? Co jsme vlastně commitnuli do Gitu? Neexistuje už stejná logika někde jinde? Je tahle část opravdu vyřešená, nebo jen vypadá, že funguje?

Tohle nejsou otázky, které mají vibe coding zpomalit. Naopak mu dávají smysl.

Protože cílem přece není napsat co nejvíc kódu. Cílem je vytvořit něco, co můžeme skutečně používat.

Řešením samozřejmě není říct každému člověku, který chce pomocí AI něco vytvořit, aby nejdřív absolvoval několik let computer science.

To by popíralo jednu z největších výhod současných AI nástrojů.

Člověk dnes nemusí znát syntaxi každého frameworku, aby dokázal něco postavit. Nemusí si pamatovat všechny příkazy ani ručně psát stovky řádků boilerplate kódu. Právě od toho tu AI máme.

Jenže mezi „nemusím všechno ručně programovat“ a „nemusím vědět vůbec nic“ je poměrně velký prostor.

A právě v něm podle mě bude vznikat nová generace tvůrců.

Lidé, kteří možná nebudou tradičními programátory, ale budou rozumět tomu, jak software vzniká. Dokážou rozdělit problém, pracovat s kontextem, navrhnout základní architekturu, používat Git, rozlišit testovací data od produkčních, přemýšlet nad bezpečností a hlavně poznat okamžik, kdy je potřeba výstup AI zkontrolovat místo dalšího zmáčknutí Enteru.

AI totiž sama o sobě kompetenci nevytváří.

Dává člověku obrovskou páku.

A když ji dostane někdo, kdo ví, co dělá, dokáže dnes během několika dní vytvořit věci, na které by dříve potřeboval celý tým. Když ji ale dostane někdo, kdo jen slepě přijímá každý další návrh, vznikne velmi rychle velmi mnoho kódu, o kterém nikdo pořádně neví, proč existuje.

Možná proto nebude největší výhodou budoucích „AI developerů“ schopnost napsat dokonalý prompt.

Mnohem cennější bude vědět, **co se má stát poté, co stisknou Enter.