Nástrahy Vibe Codingu

Perex: Vibe coding umí zrychlit prototypování a „dostat věci do pohybu“. Problém je, když se z prototypu potichu stane produkce. Tenhle článek ukáže, kde vibe coding nejčastěji padá, jaká rizika přináší a jak ho používat bezpečně.

Co je vibe coding (a proč to funguje)

Vibe coding je styl vývoje, kde cílem není „dokonalá architektura“, ale rychlý výsledek. Jedeš podle pocitu: rychle skládáš komponenty, kopíruješ ověřené patterns, používáš AI, knihovny a hotové bloky, minimalizuješ plánování a maximalizuješ momentum.

A teď pozor: vibe coding není „špatné programování“. Je to fáze. Problém vzniká ve chvíli, kdy se z fáze stane způsob života a prototyp potichu přejde do produkce.

Od „shipni to“ k „nějak to projde“

Na začátku je to legit:

• potřebuješ validovat nápad,
• ukázat demo,
• získat první uživatele,
• rozjet interní tool.

Vibe coding ti dává rychlé feedback loopy: uděláš změnu, hned vidíš výsledek, hned iteruješ. A to je brutálně silné.

Jenže někde po cestě se to zlomí:

• „shipneme to dnes“ se změní na „nějak to projde i zítra“,
• každý další „jen drobný fix“ přidává technický dluh,
• změny začnou být křehké: sáhneš na jedno a spadne druhé.

V tu chvíli už ne-shippuješ produkt, ale hasíš požáry.

Pro koho je vibe coding super (PoC, MVP, interní tooly)

Vibe coding je skvělý, když:

• děláš PoC (dokázat, že to vůbec jde),
• stavíš MVP (jestli to někdo chce a zaplatí),
• děláš interní nástroj (pár lidí, kontrolované prostředí),
• máš krátký deadline (event, launch, prezentace),
• potřebuješ rychle otestovat UX / flow / messaging.

Typicky:

• landing page + formulář + jednoduchý backend,
• MVP aplikace, kde ještě nemáš scale,
• automatizace do 1–2 systémů (n8n, webhooky),
• prototyp s AI, kde se ještě hledá „product fit“.

Tady je vibe coding „feature“, ne bug.

Kdy se z toho stává past (produkce, infra, bezpečnost)

Past začíná, když se mění kontext:

1. Produkce
   Když na tom visí byznys, objednávky, formuláře, leady, reputace. Vibe kód má často:

• slabé error stavy,
• nulové logy a alerty,
• chybějící edge casy,
• křehké integrace.

2. Infra / škálování
   Najednou přijde traffic, kampaně, integrace, cron joby, webhooks… a:

• requesty se duplikují,
• rate-limit odpálí API,
• cache neexistuje,
• DB brečí.

3. Bezpečnost
   Největší problém je, že vibe coding „funguje“ i s rizikem:

• secrets v env bez rotace,
• permissive role (admin všude),
• input bez validace,
• upload bez kontroly,
• závislosti bez kontroly.

A to je přesně ta část, kterou si v MVP „necháš na potom“… jenže potom přijde incident.

Shrnutí: vibe coding je super, dokud je jasné, že jde o prototyp-fázi. Když se ale posuneš do produkce, potřebuješ přepnout režim na: stabilizuj → zabezpeč → měř → škáluj.

Nejčastější nástrahy (reálné scénáře)

Vibe coding má jednu zákeřnou vlastnost: dlouho vypadá, že je všechno OK. Až dokud to nepřijde do produkce, nepřijde traffic, nepřijde kolega, nepřijde integrace, nepřijde „jen malá změna“. Tady jsou nejčastější situace, kde to praská.

„Funguje to na mém počítači“ (env, config drift)

Klasika: lokálně to jede, na stage/prod to padá a nikdo neví proč.

Proč se to děje:

• rozdílné .env hodnoty (API URL, keys, feature flags)
• jiná verze Node/PHP, jiné build flags
• odlišné databázové schéma / migrace neproběhly
• „dočasná“ nastavení v admin UI, která se nezaznamenala
• config se kopíruje ručně → vzniká drift

Reálné symptomy:

• 500ky jen v produkci
• rozbité uploady kvůli permissions
• CORS chyby, které lokálně nevidíš
• caching/CDN se chová jinak než localhost

Jak to zabít:

• jeden zdroj pravdy pro config (env template + validace)
• staging co je co nejblíž prod (verze, build, cache)
• CI, které zbuildí a otestuje stejně jako prod
• „config changes“ jako součást deploy procesu, ne „někde v adminu“

Chybí edge casy (null, race conditions, timeouts)

Vibe flow obvykle pokrývá happy path. Jenže realita je bordel.

Co se typicky přehlédne:

• null/undefined data (prázdný profil, chybějící field)
• „divné“ inputy (emoji ve jméně, dlouhé texty, diakritika)
• pomalé API (timeouty, rate-limit, 429)
• souběžné requesty (double submit, refresh, back button)
• webhook přijde 2× (idempotence 0)

Reálné symptomy:

• „občas se to neuloží“
• duplicity objednávek / leadů
• náhodné bugy, které nejdou reprodukovat
• UI zamrzne, protože čeká na promise navždy

Jak to podchytit:

• validace inputu (schema: zod/yup, backend validation)
• timeouts + retry/backoff + idempotence
• „loading / empty / error states“ jako povinná výbava
• aspoň minimální E2E testy na kritické flowy

Silent failures (logy 0, fallbacky 0, alerty 0)

Tohle je killer. Když něco padá a ty o tom nevíš.

Proč to vzniká:

• „udělám to rychle“ → žádné logy
• chyby se catchnou a ignorují (try/catch bez rethrow)
• fallbacky nejsou definované (co když SMS nepřijde? co když API spadne?)
• monitoring není napojený (Sentry/Logtail/Datadog nic)

Reálné symptomy:

• klient hlásí bug dřív než ty
• konverze padají a ty jen „tušíš“
• support nemá co odpovědět, protože nemá data
• incident trvá hodiny, protože nemáš trace

Jak to udělat správně:

• minimum: error tracking (Sentry) + structured logy
• alerty na kritické metriky (5xx rate, timeout spike, queue backlog)
• fallback scénáře dopředu: retry, alternative provider, manual path
• „audit trail“ pro důležité akce (platby, OTP, objednávky, integrace)

Špagetový kód a technický dluh „na splátky“

Vibe coding je často „přilepíme to sem“ a pak „jen ještě tohle“. Výsledek: systém, kterého se bojíš dotknout.

Jak to vypadá v praxi:

• logika rozházená v UI komponentech
• copy-paste funkce s malými rozdíly
• globální state a side effects bez kontroly
• rychlé hacky, které se zabetonují

Reálné symptomy:

• každá úprava stojí 3× víc času, než by měla
• bugfixy generují nové bugy
• onboarding nového člověka je peklo
• „refactor později“ se nikdy nestane

Jak z toho ven:

• pravidlo: vibe fáze → potom stabilizační sprint
• refactor na moduly/vrstvy (UI vs. domain logika vs. infra)
• typy + lint + formátování (ať je aspoň konzistence)
• definuj „definition of done“ pro produkci (testy, logy, security)

Bezpečnost – největší hidden risk

Největší problém vibe codingu je, že bezpečnost nebolí hned. Feature funguje, demo vypadá super, všichni jsou spokojení… až dokud se nestane incident. A pak už to není „ups“, ale reputační průser, ztráta dat nebo zablokovaný účet.

Vibe kód často vzniká bez threat modelu, bez guardrails a bez audit trailu. A přesně tam se skrývají ty nejdražší chyby.

Pokud to má jít do produkce, vyplatí se mít aspoň základní security hardening a u veřejných projektů i WCAG implementaci.

Secret management (API klíče v kódu, env leak)

„Jen to hodím do .env a jedeme dál.“ Ano, ale:

Typické chyby:

• API klíče hardcodnuté v repozitáři (i v historii commitu)
• .env omylem commitnuté (nebo unikne v logách)
• secrets poslané do klienta (NEXT_PUBLIC_*, frontend bundle)
• jeden klíč bez rotace, bez scope, používaný všude

Reálné následky:

• někdo ti vyžere kredit (OpenAI, SMS gateway, mapy…)
• útočník má přístup do DB/CRM/storage
• leak přes error logy nebo build output

Základní pravidla:

• secrets nikdy do kódu, nikdy do frontendu
• používat secret store (Vercel/Cloudflare/AWS Secrets/1Password)
• rotace + minimální scope (jen to, co je potřeba)
• audit: kde všude se secret používá a kdo k němu má přístup

Auth & permissions (RBAC, over-permissioned service accounts)

Vibe coding často skončí v režimu: „dej tomu admin a neřeš.“ A to je cesta do pekla.

Typické chyby:

• admin práva pro všechny (nebo pro service account)
• chybí RBAC (role-based access) – každý vidí všechno
• endpointy bez autentizace „protože to volá jen frontend“
• sdílené účty místo individuálních (žádný audit trail)

Reálné následky:

• únik citlivých dat (GDPR)
• změna cen, objednávek, obsahu bez možnosti dohledat kdo
• kompromitovaný token = kompromitovaná celá infra

Základní pravidla:

• RBAC od začátku: admin / editor / viewer / system
• service účty jen s minimálními scopes
• audit logy pro kritické akce (platby, exporty, změny rolí)
• 2FA všude, kde to jde (CRM, hosting, DNS, Ads účty)

Input validation (XSS, SSRF, SQLi, file upload)

Tohle je top místo, kde vibe coding dostane headshot. Protože „vždyť je to jen formulář“ je přesně ta věta, po které přijde incident.

Nejčastější rizika:

• XSS: user input se zobrazí bez sanitizace (komentáře, názvy, „poznámky“)
• SQLi: query skládána stringem, chybí parametrizace
• SSRF: server si sám fetchne URL z inputu (a útočník ho donutí volat interní služby)
• File upload: bez kontroly typu, velikosti, názvu, bez antiviru

Reálné následky:

• krádež session cookies, přesměrování, defacement
• přístup k interním API, metadatům cloudu
• nahrání škodlivého souboru, ransomware přes upload

Základní pravidla:

• validovat na backendu (schema validation)
• parametrizované query, ORM nebo prepared statements
• při fetchování URL whitelist, blokovat interní IP range
• upload: MIME check, size limit, random filename, mimo webroot, volitelně AV scan

Pokud řešíš OTP/form flowy, pomůže i článek SMS ověření formuláře (OTP) a GDPR.

Supply chain (dependence, npm, lockfile, typosquatting)

Vibe coding = rychlé „npm install“ a jedeme. Problém: dependencie jsou dnes jeden z největších attack vectorů.

Typické chyby:

• přidávání knihoven bez kontroly (jen aby to fungovalo)
• chybí lockfile nebo se pravidelně rozbíjí
• auto-update na latest bez review
• typosquatting (balíček s podobným názvem)

Reálné následky:

• kompromitace build procesu
• krádež env secrets
• zadní vrátka v aplikaci

Základní pravidla:

• lockfile je svatý (pnpm-lock/yarn.lock/package-lock)
• dependabot/renovate + review
• audit (npm audit, osv, Snyk) aspoň při release
• minimalizovat počet balíků: každá dependence je riziko

Výkon a škálování (když přijde traffic)

Vibe coding je většinou v pohodě… dokud nemáš traffic. Pak přijde realita: kampaně, newsletter, virál, sezóna, nebo jen pár integrací navíc. A najednou se z „rychlého webu“ stane pomalý stroj, který žere rozpočet a dropuje konverze.

Tady jsou nejčastější výkonnostní pasti.

Pokud je stack Next.js, mrkni i na Next.js vývoj a Performance.

N+1 queries, neefektivní requesty

Nejčastější důvod, proč appka umírá potichu: moc dotazů na DB/API.

Jak to vzniká:

• načteš seznam (N položek) a ke každé děláš další request/query
• v UI se spouští fetch-e duplicitně (re-render, effecty)
• API vrací „všechno“, i když potřebuješ 10 % dat
• chybí pagination, filtrace, indexy

Symptomy:

• lokálně OK, v produkci pomalé
• DB CPU/IO roste s počtem userů
• TTFB roste, CTR padá, user odchází

Jak to řešit:

• agregovat query (JOIN/IN), nebo použít batchování
• server-side fetch s cachingem
• pagination + limit fields („select only what you need“)
• sledovat slow queries a přidat indexy

Caching „někdy potom“ (CDN, ISR, Redis)

Vibe coding často znamená: „cache přidáme později“. Jenže caching není polish. Je to základní nástroj škálování.

Co se typicky zanedbá:

• bez CDN (všechno jde z origin serveru)
• bez cache na API (stejný request 100×)
• bez ISR/SSG v Next.js (stránky se renderují při každém requestu)
• bez cache invalidace (když se změní obsah)

Dopady:

• zbytečný load na server
• drahé infra náklady
• pomalé načítání na mobilu (a to zabíjí konverze)

Jak to nastavit rozumně:

• CDN na statiku (Cloudflare/Vercel)
• Next.js: ISR/SSG tam, kde to dává smysl (blog, kategorie)
• Redis/cache layer pro často volaná data (produkty, ceníky, profily)
• cache headers + revalidate strategie (short TTL + purge podle eventu)

Core Web Vitals vs. „je to pěkné“

Vibe coding často optimalizuje vzhled, ne výkon. A přitom Core Web Vitals jsou přímo napojené na UX a SEO.

Nejčastější chyby:

• velké obrázky bez optimalizace (LCP v háji)
• fonty bez preload, layout shift (CLS)
• hodně JS bundle + 3rd party skripty (INP/TTI)
• animace a efekty, co vypadají cool, ale brzdí mobil

Dopady:

• horší SEO (hlavně long-tail a lokální)
• vyšší bounce rate
• nižší konverze z placeného trafficu (tvoje Kč mizí)

Minimum, které se vyplatí:

• optimalizovat hero image a kritický obsah (LCP)
• lazy-load všechno mimo viewport
• omezit 3rd party skripty, dát je až po interakci
• sledovat CWV v reálných datech (CrUX/GA4/Speed Insights)

Rate limiting a ochrana API

Když přijde traffic, neselže jen UI. Selže i API. Zvlášť když máš:

• formuláře
• OTP/SMS
• webhooks
• search endpointy
• generování feedů

Co se děje bez limitů:

• bot ti odpálí endpoint a server padá
• SMS gateway spálí kredit
• brute-force login/OTP
• integrace se zacyklí a spamují API

Jak to řešit:

• rate limiting na úrovni edge (Cloudflare) i aplikace
• throttling podle IP/user/token
• idempotence pro webhooks a platby (aby se to nedělalo 2×)
• WAF pravidla a blokování anomálií
• ochrana drahých endpointů (search, export) přes caching + quotas

Kvalita kódu a udržovatelnost

Vibe coding umí doručit výsledek rychle, ale často za cenu toho, že další změny jsou pomalejší, rizikovější a dražší. Ne proto, že by lidi byli neschopní, ale proto, že systém nemá jasná pravidla a hranice. Udržovatelnost je to, co rozhodne, jestli projekt po 3 měsících ještě zvládneš rozvíjet bez stresu.

Nekonzistentní patterns a naming

Když každý komponent/část kódu vypadá jinak, mozek pořád přepíná kontext. To je tichý zabiják produktivity.

Jak to vypadá:

• jednou getUserData(), pak fetch_user(), pak loadProfile()
• někde camelCase, jinde snake_case, jinde úplně freestyle
• stejný problém má 3 řešení (3 různé hooky, 3 různé service vrstvy)
• stejný typ komponentu jednou „smart“, jednou „dumb“, bez pravidla

Dopady:

• code review je těžší (víc debat o stylu než o logice)
• bugy se hledají déle
• nový člověk se v tom topí

Minimum, které pomůže hned:

• naming konvence (funkce, komponenty, soubory, folders)
• „jeden pattern na jednu věc“ (např. data fetching jen přes jednu vrstvu)
• krátké README „jak tu píšeme kód“ (10 bodů)

Chybí typy (TS), chybí lint/format

Bez typů a automatických pravidel se vibe kód mění na „doufejme, že to nespadne“. Typy a lint nejsou „enterprise byrokracie“ – jsou to airbagy.

Typické problémy bez TS/lintu:

• runtime chyby typu „cannot read property of undefined“
• přehlédnuté regrese při refactoru
• nejednoznačné datové struktury (každý si domýšlí tvar objektu)

Co se vyplatí nastavit:

• TypeScript (aspoň postupně: strict později, ale směr jasný)
• ESLint + Prettier (a fix při commitu)
• základní pravidla: no-unused-vars, no-any (postupně), import order
• CI: lint + typecheck musí projít, jinak se nedeployuje

Dopad v praxi:

• méně bugů
• rychlejší refactor
• jednodušší code review

Chybí architektura (boundary, modularita)

Vibe coding rád míchá všechno dohromady: UI, business logiku, API call, state, validaci. Dokud je to malé, jde to. Když to roste, praská to.

Signály, že chybí hranice:

• komponenty mají 400 řádků a řeší všechno
• business logika je v React komponentu
• API a DB logika je „rozházená“ po celém projektu
• každý importuje všechno všude

Co znamená „boundary“ jednoduše:

• UI vrstva: render, layout, interakce
• domain/logika: pravidla (validace, výpočty, stavové přechody)
• infra: fetch, DB, storage, externí API

Proč to pomáhá:

• logiku můžeš testovat bez UI
• změníš API a nerozbiješ UI
• tým může pracovat paralelně

Praktický krok:

• zavést „service layer“ nebo „use-case“ funkce
• oddělit lib/, services/, domain/, ui/
• zakázat importy křížem (např. UI nesmí sahat přímo do DB)

Dokumentace 0 → onboarding těžký

Když projekt zná jen jeden člověk, máš bus factor 1. Vibe coding to často ještě zhorší: věci jsou „v hlavě“.

Typicky chybí:

• jak to spustit lokálně (env, seed, migrace)
• jak deployovat (rozdíly staging/prod)
• kde se nastavují klíče, webhooks, cron joby
• „co je kritické“ (SLA flowy, platby, OTP, integrace)

Co stačí (fakt minimum):

• README: setup v 10 krocích
• „Architecture notes“ (1 stránka): moduly + hlavní flowy
• Runbook: co dělat, když spadne X (mini incident manuál)
• rozhodnutí (ADR): proč jsme zvolili to a to

Testy – vibe coding bez testů je hazard

Vibe coding bez testů je jako jezdit rychle bez brzd: chvíli je to zábava, než přijde první nečekaná zatáčka. Nejhorší je, že bez testů se projekt časem dostane do stavu, kdy se tým bojí dělat změny, protože každá změna může rozbít něco jinde.

Dobrá zpráva: nepotřebuješ 100% coverage. Stačí rozumně pokrýt to, co je nejdražší, když to spadne.

Unit testy: co se vyplatí testovat (core logika)

Unit testy jsou nejlepší investice, když testuješ pravidla a logiku, ne UI.

Největší hodnotu mají:

• výpočty (ceny, slevy, DPH, scoring)
• validace (formuláře, pravidla registrace, OTP)
• transformace dat (mapování feedů, importy, normalizace)
• rozhodování (stavové přechody: lead → qualified → won/lost)
• ochrana před regresí při refactoru

Čemu se často nevyplatí věnovat moc času:

• UI render detaily (raději E2E)
• „testuju, že funkce volá funkci“ bez reálného významu

Praktické pravidlo: pokud je to logika, kterou umíš odtrhnout od UI a má jasné vstupy/výstupy → unit test.

E2E: kritické flowy (login, checkout, formuláře)

E2E testy jsou nejblíž realitě. Jsou pomalejší, ale chytí to, co uživatel opravdu zažívá.

Co by mělo mít E2E skoro vždy:

• login / registrace / reset hesla
• checkout / objednávka (pokud je e-shop)
• formuláře (kontakt, poptávka, servis) + validace + error state
• platba / integrace (aspoň „happy path“ + fail path)
• admin flowy, které jsou kritické (publikování, import)

Pro vibe projekty funguje minimalistický přístup:

• 5–10 E2E testů na „money pages“
• spouštět v CI na PR nebo nightly
• když je bug → nejdřív test, pak fix (zabiješ regresi)

Snapshoty vs. reálná hodnota

Snapshoty jsou lákavé, protože se dají udělat rychle. Problém: často vytvoří falešný pocit bezpečí a z review se stane „update snapshot a hotovo“.

Kdy snapshoty dávají smysl:

• malé, stabilní komponenty (UI ikonky, jednoduché layouty)
• email templaty nebo generované výstupy, kde chceš vidět diffs
• serializované configy (např. mapování polí)

Kdy jsou spíš noise:

• velké komponenty s hodně dynamikou
• stránky s častými změnami
• cokoliv, kde při každé změně „musíš update-nout snapshot“ a nikdo to reálně nekontroluje

Lepší alternativa:

• testovat konkrétní věc: „zobrazí error“, „button je disabled“, „API call má timeout handling“
• vizuální testy (Playwright screenshot) jen pro pár klíčových screenů

Monitoring jako „test v produkci“

Monitoring není náhrada testů, ale v reálném světě je to často jediný způsob, jak chytíš edge casy, které se v testech nikdy neobjeví.

Minimum v produkci:

• error tracking (Sentry) – stacktrace + user context
• performance monitoring (latence, TTFB, DB queries)
• uptime checks (health endpointy)
• alerty: spike 5xx, timeouty, drop konverzí, queue backlog

Největší win: když monitoring měří i „byznys“ – např. počet odeslaných formulářů, úspěšné platby, úspěšné OTP verifikace. Protože když „web běží“, ale konverze jsou 0, tak jsi pořád v háji.

Produktová rizika (UX, analytika, konverze)

Vibe coding často řeší „aby to fungovalo“, ale produkt v realitě potřebuje „aby to lidi uměli používat“ a „aby to konvertovalo“. Největší průser je, že když zanedbáš UX a měření, nevíš ani zjistit, proč věci nefungují. A pak se optimalizuje podle pocitu.

Tracking se „dá později“ → data debt

Tohle je jedna z nejdražších vět v digitálu. Když tracking odložíš, vytvoříš data debt – dluh, který se později platí stresem, time-to-fixem a spáleným budgetem.

Co se typicky odloží:

• konverze (submit form, purchase, lead, call click)
• UTM a source/medium mapping
• consent a cookie režim (a pak jsou data poloviční)
• atribuce mezi marketingem a produktem

Dopady:

• nevíš vyhodnotit kampaně → optimalizuješ naslepo
• nevíš, jestli je problém traffic, landing nebo formulář
• změny se dělají „od oka“ a často zhorší výkon

Minimum hned od začátku:

• 5–10 klíčových eventů (funnel), ne 100
• jasné naming konvence eventů
• verifikace (test: event se posílá a je v reportu)

Prakticky: pro měření a optimalizaci se hodí Analytics & CRO a pravidelný Reporting.

Bez eventů nevíš co fixovat

Když nevíš, kde lidi odpadávají, nevíš co opravovat. Bez eventů je každý bugfix loterie.

Co chceš vědět:

• kde je drop-off (landing → CTA → form_start → form_submit)
• která pole lidi nejčastěji failují
• jak dlouho trvá dokončení kroku (time-to-complete)
• jestli se problém děje na mobilu / v konkrétním prohlížeči

Příklady eventů s okamžitou hodnotou:

• cta_click
• form_start
• form_error (s typem chyby, ne s PII)
• form_submit_success
• otp_send / otp_verify_success / otp_verify_fail
• checkout_start / purchase_success

Bez toho:

• řešíš „pocity“ místo dat
• support neumí pomoct
• produkt roste pomalu, protože netušíš, kde to bolí

Accessibility a compliance se zanedbají

A11y a compliance se ve vibe codingu často berou jako „nice-to-have“. V produkci jsou to ale reálná rizika:

• právní (hlavně veřejná správa, WCAG)
• reputační (brand trust)
• konverzní (lidi se nedokážou proklikat / dokončit flow)

Typické a11y přešlapy:

• chybí labely a focus states
• modaly bez focus trap, ESC, správného aria
• OTP inputy, které jsou hezké, ale nejdou ovládat klávesnicí
• kontrast textu „vypadá cool“, ale je nečitelný

Compliance/UX dopad:

• vyšší bounce rate
• víc nedokončených formulářů
• zbytečné support tickety

Minimum:

• základní WCAG check (kontrast, focus, labely, error hlášky)
• keyboard-only průchod kritickými flowy
• „no blockers“ před release

Související: Audit přístupnosti a článek WCAG 2.2 v praxi pro města a obce.

UX detaily: error stavy, loading, empty states

Vibe coding často pokryje jen „happy path“. Ale produkce je o tom, co se děje, když něco nejde.

UX detaily, které přímo zabíjejí konverze:

• formulář spadne a user neví proč (žádná hláška)
• loading bez indikace → user klikne 3× → duplicity
• error stavy bez next-step („zkus znovu“, „kontakt“, „uloženo jako draft“)
• empty state bez vysvětlení („nic tu není“) → user odejde

Co by měl mít každý kritický flow:

• jasný loading stav (disabled CTA + spinner + text)
• error message lidskou řečí (ne „500“)
• fallback cesta (retry, alternativní kontakt, uložit a pokračovat později)
• potvrzení úspěchu (a co dál)

Zlaté pravidlo: pokud user neví, co se stalo a co má udělat dál → konverze umírá.

Týmová rizika (když vibe coding dělá 1 člověk)

Vibe coding je často sólo jízda. A to je OK… dokud projekt není kritický. Když se ale začne používat reálně (klienti, objednávky, SLA), týmová rizika jsou stejně nebezpečná jako technická. Protože i kdyby byl kód „nějak OK“, problém je, že nikdo kromě jednoho člověka neví, jak to celé funguje.

Bus factor (knowledge v hlavě)

Bus factor je počet lidí, kteří můžou vypadnout, než projekt přestane být udržitelný. U vibe codingu je často 1.

Jak to vypadá v praxi:

• jen jeden člověk ví, kde jsou secrets, webhooks, cron joby
• deploy se dělá „ručním rituálem“
• nikdo neví, co je kritické a co je „jen pěkné“
• když autor nemá čas, všechno stojí

Dopady:

• onboarding nového člověka jsou týdny
• incidenty trvají déle, protože chybí kontext
• firma je závislá na jednom člověku (riziko pro byznys i tým)

Jak to snížit bez velké byrokracie:

• 1× stránka „How it works“ (flowy + kde co běží)
• runbook: co dělat při top 3 incidentech
• checklist deploye + rollback
• sdílené přístupy přes role (ne „jedno heslo“)

Code review se obejde, protože „rychlost“

Když je deadline, review je první, co odpadne. Jenže code review není formalita — je to kontrola kvality, bezpečnosti a přenos know-how.

Proč se to obchází:

• „nemáme čas“
• „je to jen malý fix“
• „stejně tomu nikdo nerozumí“

Co tím riskuješ:

• security chyby projdou bez povšimnutí
• nekonzistentní patterns se zabetonují
• regrese se odhalí až v produkci
• tým se nenaučí kontext → bus factor zůstává 1

Pragmatické řešení:

• „lightweight review“ pravidlo: i 5 min je lepší než 0
• PR šablona: co se mění, jak testováno, rizika, rollback
• pokud se nestíhá review, tak aspoň „pair 10 min“ před mergem

Konflikt: rychle vs. správně (dohody a pravidla)

Největší týmový problém vibe codingu není kód, ale očekávání. Někdo chce rychle shipovat, někdo chce stabilitu. Bez dohod to skončí konfliktem a frustrací.

Typické konflikty:

• obchod tlačí feature, dev tlačí stabilizaci
• „jen to nasaď“ vs. „bez testů to nejde“
• „uklidíme později“ vs. „už se to nedá uklidit“

Co funguje:

• jasně definovat, kdy je vibe režim OK (PoC, MVP, interní)
• definovat „Definition of Done“ pro produkci (min. bezpečnost, logy, monitoring, testy)
• pravidlo „vibe → stabilizační sprint“ po každém větším shipnutí
• timebox: 70/30 (feature vs. hardening), nebo fixní „stabilizační den“ týdně

Pointa: rychlost a správnost nejsou nepřátelé — ale musí mít jasná pravidla hry. Jinak vibe coding začne žrát tým zevnitř.

Kdy vibe coding dává smysl (a jak ho „zlegalizovat“)

Vibe coding je brutálně užitečný nástroj — když ho používáš vědomě. Problém není vibe, problém je, když z něj uděláš produkční standard bez pravidel. „Zlegalizovat“ vibe coding znamená: dát mu mantinely, aby sis udržel rychlost, ale nevyráběl časovanou bombu.

Definuj hranice: prototyp vs. produkce

Nejdůležitější je pojmenovat, co právě stavíš:

Prototyp / PoC / MVP (vibe OK):

• cíl: validace, demo, rychlý feedback
• toleruješ hacky, dočasná řešení, menší dluh
• riziko je kontrolované (malý počet userů, interní použití)

Produkce (vibe jen s pravidly):

• cíl: stabilita, bezpečnost, předvídatelnost
• potřebuješ monitoring, audit trail, fallbacky
• každý bug stojí peníze / reputaci

Praktický hack: zaveď si 2 štítky:

• EXPERIMENT (vibe)
• PROD-READY (musí projít checklistem)

Tím zabiješ nejčastější lež: „vždyť je to jen dočasné“.

Definuj exit kritéria (co musí být hotové před deployem)

Exit kritéria jsou „minimální požadavky“, které oddělují demo od produkce. Nemusí být extrémní — ale musí existovat.

Příklad rozumného „Definition of Done“ pro produkci:

• ✅ fungují error stavy (UI i API) + user ví co dál
• ✅ konverze/eventy jsou změřené (aspoň core funnel)
• ✅ rate limiting / basic anti-abuse pro kritické endpointy
• ✅ secrets nejsou v repozitáři ani v client bundle
• ✅ aspoň 5–10 E2E testů na kritické flowy
• ✅ monitoring: error tracking + alert na spike 5xx/timeout
• ✅ rollback plán (nebo aspoň „jak to vypnout“)

Důležité: exit kritéria nejsou „nice-to-have“. Jsou to podmínky, abys nezamkl projekt v režimu chaosu.

Vibe coding s guardrails: lint, types, CI, secrets, tests

Guardrails jsou ochranné mantinely, které umožní vibe tempo bez toho, abys rozbil kvalitu. Ideální jsou takové, které fungují automaticky a nevyžadují disciplínu každého člověka.

Minimum guardrails s nejvyšším ROI:

• Lint + format: jednotný styl, méně noise v review
• Types: TypeScript / schema validation (zod) – méně runtime failů
• CI pipeline: build + lint + typecheck + testy musí projít
• Secrets hygiene: secret store + scan (Gitleaks) + rotace
• Test baseline: unit testy na core logiku + pár E2E na money flowy
• Observability: Sentry + základní metriky/alerty

Zlaté pravidlo: pokud guardrails nejsou automatické, časem se obejdou. Pokud jsou automatické, vibe tempo zůstane — a kvalita se drží.

Praktický framework: „Vibe → Stabilizuj → Scale“

Pokud chceš vibe coding používat bez toho, abys si jednou utrhl hlavu v produkci, potřebuješ jednoduchý systém. Tenhle framework funguje dobře v agentuře i interním týmu: nejdřív rychle doruč, pak to zpevni, pak škáluj. Každá fáze má jiný cíl a jiná pravidla.

Fáze 1: Vibe (rychlý PoC)

Cíl: co nejrychleji ověřit, jestli to dává smysl (value + feasibility). Tady je rychlost výhra. Nehraje se na dokonalost, hraje se na feedback.

Co se řeší:

• core flow (1–2 hlavní use-casy)
• UX koncept (na co user kliká, v čem je hodnota)
• integrace „aspoň nějak“ (mock, sandbox, test API)
• základní tech spike (jestli to vůbec jde)

Co se vědomě odkládá:

• perfektní architektura
• edge casy do detailu
• full test suite

Ale pozor — i vibe má minimum:

• žádné hardcoded secrets v kódu
• aspoň základní error handling (ať to nepadá potichu)
• krátký README „jak to spustit“

Výstup fáze: demo/PoC, které ukáže hodnotu. + jasné rozhodnutí: kill / iterate / go prod.

Fáze 2: Stabilizace (refactor + testy + security)

Cíl: z prototypu udělat něco, co se dá bezpečně provozovat a rozvíjet. Tohle je fáze, kterou lidi přeskakují — a pak brečí.

Co se dělá:

• refactor do jasných vrstev (UI / domain / infra)
• sjednocení patterns, naming, zrušení copy-paste duplicit
• typy (TS) a validace dat (schema)
• testy: unit na core logiku + E2E na kritické flowy
• bezpečnost: RBAC, input validation, rate limiting, secrets hygiene
• měření: konverze + základní funnel

Výstup fáze: „PROD-READY“ baseline. Tj. nasadit se dá bez strachu a incidenty jsou dohledatelné.

Fáze 3: Scale (monitoring, performance, SLA)

Cíl: udržet stabilitu při růstu trafficu, funkcí, týmu a integrací. Tady se řeší „jak to bude fungovat, když to půjde dobře“.

Co se řeší:

• performance: caching (CDN/ISR/Redis), DB optimalizace, CWV
• observability: logy, metriky, alerty, tracing
• infra: autoscaling, queueing, retry/backoff, idempotence
• procesy: release cadence, incident response, runbooky
• SLA/SLO: uptime, response time, error budget, monitoring hranice

Výstup fáze: systém, který je předvídatelný: umíš ho škálovat bez toho, aby se z každé kampaně stal incident.

Pointa frameworku: vibe coding není problém. Problém je, když vynecháš Stabilizaci a chceš rovnou Scale. Tohle je nejkratší cesta k tomu, abys měl rychlost i kvalitu bez konfliktů.

Checklist před tím, než to pustíš do produkce

Tohle je praktický „gate“ checklist. Nemusíš mít enterprise procesy, ale tyhle věci ti ušetří nejvíc nervů, bugů a incidentů. Ideálně si ho dej do PR šablony nebo do release checklistu.

Security checklist (secrets, auth, validation)

• Secrets nejsou v repozitáři (ani v historii commitů)
• Žádné secrets nejdou do frontendu (pozor na NEXT_PUBLIC_*)
• Secrets jsou v secret store a mají minimální scope + plán rotace
• Auth je povinný na všech citlivých endpointech (žádné „hidden URL“)
• RBAC/permissions: role existují a service accounts nemají admin všude
• Input validation na backendu (schema), ne jen v UI
• Uploady: typ/velikost, random názvy, mimo webroot, bezpečné zpracování
• Rate limiting / throttling na kritické endpointy (login/OTP/form/export)
• Závislosti: aspoň základní audit (lockfile + audit tool)

Quality checklist (lint, types, structure)

• Lint + format je nastavený a běží automaticky (pre-commit nebo CI)
• Typecheck projde (TS / schema typy) – bez „any everywhere“
• Core logika je oddělená od UI (aspoň základní boundary)
• Duplicity a copy-paste „helpery“ jsou zredukované (jeden pattern na jednu věc)
• Kritické flowy mají testy (unit na logiku + E2E na money flow)
• README: jak spustit projekt + minimální env template
• Změny mají jasný popis (co se mění, proč, riziko)

Observability checklist (logs, metrics, alerts)

• Error tracking (např. Sentry) je zapnutý a posílá stacktrace
• Logy jsou strukturované a mají request ID / user context (bez PII)
• Kritické byznys eventy jsou měřené (form_submit, purchase, otp_verify, atd.)
• Alerty existují: spike 5xx, timeouty, drop konverzí, rate limit hit
• Healthcheck endpoint (nebo uptime monitoring) běží a je sledovaný
• Máš „kde hledat“: logy, dashboard, incident kanál / postup

Deployment checklist (rollback, env parity)

• Staging je co nejblíž produkci (verze, config, cache/CDN)
• Migrace DB jsou připravené + otestované (a umíš je rollbacknout)
• Feature flags / kill switch existuje pro rizikové části
• Máš rollback plán: jak rychle vrátit předchozí release
• Env parity: správné .env hodnoty, rate limits, origin domains, CORS
• Po deployi proběhne sanity check: top 3 kritické flowy ručně/E2E
• CDN/cache invalidace je vyřešená (ať se neukazuje starý stav)

Závěr

Co si vzít:

• Vibe coding je super na PoC/MVP, ale v produkci potřebuje mantinely – jinak se z rychlosti stane chaos.
• Největší rizika jsou skrytá: bezpečnost, měření, silent failures a technický dluh, který se časem násobí.
• Minimum, které zachrání projekt: types + lint + CI + základní testy + secret hygiene + monitoring.
• Když to roste, nezachrání tě „lepší kód“, ale systém: Vibe → Stabilizuj → Scale + release checklist.
• Každý incident, který chytíš včas (logy/alerty), je levnější než „client report“, že to nefunguje.

CTA (co umíme udělat za tebe):

• Audit (1–2h): rychlý review rizik (security, performance, tracking, architektura) + konkrétní plán kroků
• Code review / hardening: refactor klíčových částí, test baseline, guardrails, secrets, rate limiting
• Monitoring & performance: Sentry/logy/alerty, CWV optimalizace, caching, SLA-ready nastavení

Pokud chceš, pošli repo nebo URL přes brief nebo si rezervuj call a uděláme ti krátký „production readiness“ report + priority na nejbližších 14 dní.