Vibe coding má svou stinnou stránku – a není to, co si myslíte

Přiznejme si to rovnou: vibe coding je skvělý. Řeknete, co chcete, sledujete, jak to agent postaví, vidíte testy zezelenat a můžete shipovat. Připadáte si jako kouzelník – dokud to najednou není kouzelné.

Ten zlom obvykle přijde někdy kolem třetí ráno. Vaše aplikace se najednou začne chovat divně, processor se zasekává, a vy zjistíte, že váš skvělý kód v produkci vůbec nefunguje. Nebo to otevře deset tisíc souborů najednou a celé se to zhroutí. Nebo běží bezvadně na vašich testovacích datech a pak exploduje, když přijdou skuteční uživatelé.

Kód byl přitom správný. Vyřešil problém přesně podle zadání. Jen prostě počítal s nekonečnou pamětí a nekonečným počtem otevřených souborů – protože v promptu nic nenaznačovalo, že by to mělo být jinak.

Tichý zabiják: nevyslovené předpoklady

Tady je ta chytrá část vibe codingu, o které se na konferencích nikdo nebaví. Když píšete kód sami, nosíte mentální model omezení všude s sebou. Víte, že běžíte na laptopu s 16GB RAM. Víte, že produkční server má limity na file deskriptory. Víte, že ten 400GB CSV soubor není něco, co byste mohli nacpat do paměti celý.

Ale když kód píše AI, ta omezení prostě neexistují. AI vidí "načti soubor, seřaď ho, zapiš výsledek" a řekne si: skvělé, načtu to celé. V testech to funguje perfektně. Protože ten testovací soubor má 50 KB.

Ani code review vám nepomůže. Kritické řádky vypadají úplně rozumně. Nic nevyvolává červenou vlajku, když hledáte logické chyby – protože žádné nejsou. Bug není v logice; je v neviditelné krabici, do které ta logika byla navržena.

Co kdyby compiler věděl víc?

Tady to začíná být zajímavé. Jeden vývojář jménem Nicolas Grislain experimentuje s provokativní myšlenkou: co kdyby resource constraints byly typy, ne komentáře?

Místo doufání, že váš AI-generovaný kód bude respektovat limity paměti – co kdyby compiler doslova odmítl kompilovat kód, který je porušuje? Co kdyby "tato funkce nikdy nedrží v paměti víc než 100 záznamů" a "tento program nikdy nemá otevřených víc než 3 soubory současně" byly fakta, která compiler ověřuje, ne modlitby, které šeptáte během code review?

Tohle není jen teoretické mávání rukama. Experiment používá Lean 4 – ano, ten samý Lean, který dělá vlny ve formální matematice – k zakódování resource rozpočtů přímo do typů funkcí. Compiler se stává resource auditorem, který automaticky kontroluje, že váš kód zůstává v limitech, ještě než vůbec běží.

Jak na to v praxi

Jádro toho triku je překvapivě elegantní: provlečte resource počty přes typový systém. Místo sledování "kolik souborů je otevřených" jako runtime proměnné, která se dá ignorovat, typový systém to sleduje jako phantom parameter, který se musí vyrovnat.

Když otevřete soubor, typová signatura odráží změnu: vstoupíte do funkce s N otevřenými soubory a vyjdete s N+1. Když ho zavřete, jdete z N+1 zpátky na N. Compiler to sleduje v každém kroku a vy doslova nemůžete kompilovat kód, který otevře soubor, aniž by ho zavřel, nebo otevře víc souborů, než je povoleno.

S pamětí to funguje podobně, ale s twistem. Záznamy ve volné paměti neplavou – žijí v bounded poolu s fixním počtem slotů. Nedržíte Event objekt; držíte referenci do toho poolu. Typ sleduje, kolik živých referencí existuje v jakémkoli momentě, a alokace vyžaduje důkaz, že je místo.

Magie se děje na entry pointu: program musí začít s nulovými resource a skončit s nulovými. Nemůžete leakovat handly ani refs. Nemůžete překročit limity. Compiler vás jednoduše nepustí dál.

Proč je to důležité pro vibe coding

Tento přístup mění způsob, jak přemýšlíme o promptování AI asistentů. Dnes možná přidáte poznámku jako "buď opatrný s memory usage" nebo "zavři všechny file handly" – v naději, že AI bude pozorný. S resource-aware typy specifikujete omezení formálně a implementace se musí reorganizovat, aby je splnila.

AI dostane nejdřív neomezenou verzi. Testy projdou. Pak zapnete limity. Compiler okamžitě odmítne implementaci. AI musí重构 svůj přístup – možná zpracovávat soubor po částech místo načtení celého, nebo použít connection pool místo otevírání souborů напрямую.

Implementace nefunguje jen náhodou správně; prokazatelně funguje v rámci rozpočtu.

Praktická realita

Buďme jasní: pro většinu týmů to ještě není produkční nástroj. Lean 4 přístup vyžaduje značné nastavení a je tam overhead v myšlení v termínech indexovaných typů. Ale základní insight je cenný bez ohledu na implementaci.

Při vibe codingu nesvěřujete AI jen psaní kódu, ale i mentální model vašeho systému. Váš AI asistent nezná vaše produkční prostředí. Neví, že váš container má 512MB RAM. Neví, že váš Linux kernel capuje file deskriptory na 1024.

Dokud nebudeme mít lepší způsoby, jak tato omezení zakódovat, máme několik pragmatických možností:

1. Buďte explicitní v promptech – "Vstupní soubor může obsahovat až 10 milionů řádků" je lepší než "zpracuj velké soubory efektivně"

2. Testujte s produkčními daty – Pokud jsou vaše tréninková data mikroskopická, AI se nenaučí resource vzory

3. Používejte bounded API – Architektura, která přirozeně limituje resource usage (connection pools, streaming místo načítání) se hůř špatně používá

4. Sledujte resource-aware tooling – Průmysl začíná zkoumat způsoby, jak udělat omezení explicitními v AI-generovaném kódu

Závěr

Dirty secret vibe codingu není, že píše buggy kód – je to, že píše kód, který je správný v rámci neviditelného constraint space. Ten space zahrnuje váš laptop, vaše testovací prostředí a možná vašich prvních tisíc uživatelů. Rozhodně nezahrnuje "produkci při škálování."

Resource-aware typové systémy jako tenhle Lean 4 experiment ukazují cestu k budoucnosti, kde "správný" znamená víc než "logicky správný." Znamená to "prokazatelně zůstává v limitech, které skutečně existují."

To je budoucnost, ke které stojí za to směřovat. Do té doby držte testovací data blízko produkční velikosti a možná přidejte extra poznámku do promptů ohledně těch file descriptor limitů.

Váš budoucí on-call self vám poděkuje.