Vibe coding funguje. Sám jsem si tak udělal nástroj na koláže fotek. Vibe engineering je pak o kus dál, agent píše a inženýr řídí. Myslím si ale, že ani to nebude stačit.
Vibe coding funguje. Na koláže.
Přiznám se, vibe coding jsem zkusil a vyšel :-D Potřeboval jsem jednoduchý nástroj na koláže fotek. Popsal jsem, co chci, agent to napsal, párkrát jsem řekl „tohle posuň“ a „tohle udělej větší“ a bylo hotovo. Do kódu jsem se pořádně nepodíval.
A víte co? Je to úplně v pořádku. Nástroj pro mě, nic produkčního, žádná citlivá data. Když se rozbije, napíšu si nový.
Problém začne, až stejný přístup zkusíte na produkčním systému. Tam už nejde o to, jestli se koláž vykreslí. Jde o data zákazníků, bezpečnost, provoz. A tam „funguje to, tak to nechám“ nestačí.
Vibe engineering je správný směr
Vibe engineering na to jde líp. Agent píše kód, inženýr řídí, ověřuje a nastavuje pravidla. Agent dostane kontext, hranice a nástroje. Výsledek prochází testy, CI a review.
Jak takový setup vypadá u nás, jsem popsal v článku Lepší modely má každý. Proč s nimi někdo letí a jiný ne?.
Jenže i to je podle mě jen mezikrok.
Kód jako nový assembler
Kdo z vás naposledy četl assembler, který mu vyplivnul kompilátor? No právě.
Myslím, že s kódem z AI to dopadne podobně. Řádek po řádku ho bude číst čím dál méně lidí. Nebude na to čas a hlavně to nebude dávat smysl. Hodnota se přesune jinam. Ke kontrole záměru, chování a výsledku.
Jasně, ten příměr kulhá. Kompilátor je deterministický, LLM ne. Dvakrát stejné zadání, dva různé výsledky. Ale právě proto budou testy, CI a ověřování výsledku ještě důležitější než dnes. Když už kód nečtu, musím umět ověřit, že dělá, co má.
Ticket zavřený, produkt nedodaný
Když agent zvládne napsat kód, co zbude na inženýrovi? Podle mě všechno ostatní.
Pochopit problém. Vědět, kdo je uživatel a co opravdu potřebuje. Rozhodnout, co dělat a co ne. Nasadit. Změřit, jestli to pomohlo. A pak se o to postarat v provozu.
Product engineering místo „zavřel jsem ticket“. Zavřený ticket nikoho nezajímá. Zajímá je, jestli funguje produkt.
Co agentovi nesvěřím bez porozumění
Pak jsou tu věci, které zůstávají na člověku. Ne proto, že by je agent nenapsal. Napíše. Ale bez porozumění nepoznám, jestli to napsal dobře.
- Šifrování.
- Přihlašování a autorizace.
- Databáze a konzistence dat.
- Výkon.
- Bezpečnost.
- Provoz.
Příklad z praxe? Refresh tokenů. Agent napsal kód, který vypadal úplně v pořádku a testy prošly. Jenže jsem v něm našel nedostatky. Krátkodobý token si mohl vytvořit dlouhodobý, takže se úplně obešel záměr, že přístup má po čase vypršet. A jinde token dovoloval číst data déle, než bylo zamýšleno.
Žádný test nespadl. Žádná chybová hláška. Kód dělal přesně to, co v něm bylo napsané, jen ne to, co jsme chtěli. Kdo nerozumí tomu, jak fungují tokeny a autorizace, tomu takový bug projde i přes review.
Co dělá dobrého inženýra dnes
Dobrý inženýr v době agentů:
- dá agentovi kontext a hranice,
- ověří výsledek testy a CI, ne pocitem,
- ví, kde AI věřit a kde ne.
To poslední je nejtěžší. A naučit se to dá jen tak, že těm věcem pod tím opravdu rozumíte.
Co s tím
- Dotahujte produkt, ne jen úkoly. Od problému až po provoz.
- Investujte do těžkých základů. Bezpečnost, data, distribuované systémy. Tohle za vás agent neposoudí.
- Postavte si setup, ve kterém agent pracuje bezpečně. Pravidla, testy, CI, review.
Z kódu se stává assembler. Z inženýra produktový architekt. Kdo zůstane jen u psaní kódu, toho agent dožene jako prvního.
