Za jeden jediný víkend jsem vytvořil server se simulací přijímacích zkoušek, který během čtrnácti dnů využila pětina rodičů dětí hlásících se na střední školy. Tenhle článek berte jako sumář změn, které AI přináší do vývoje a především do vývoje produktů.
Server Přijímačky na školu
Tento projekt totiž nebyl jen cvičením v rychlosti. Byla to demonstrace toho, jak se mění role seniorního vývojáře na „orchestrátora“ a proč se software posouvá z pozice aktiva do pozice komodity.
Disclaimer (kdo mne neznáte): jsem člověk, který celý život řídí své nebo cizí firmy a má v nich na starosti především vývoj a analýzu dat. Před čtyřmi lety jsem se dostal k zhroucenému projektu, kde potřebovali během pár dnů nahradit masivní produkční systém na desítkách tisících počítačích. Nemožné? Dali jsme to. Předloni jsme do procesu nasadili AI. Nejdříve na triáž chyb, vzápětí na dokumentaci a před rokem na samotné programování. Dnes celou naši vývojovou stopu obsluhuje téměř výhradně AI. Pro běžně řízený vývoj je to noční můra, ale jen tak lze měnit 10 000 řádků kódu denně ve velmi volatilním prostředí. Tolik k backgroundu.
Problém: Analytika nad daty Cermatu
Syn se hlásí na střední školu. Chtěl jsem vědět, kam má s jeho výsledky šanci se dostat. Dat je dost, ale jsou nepřehledná, bez laborování s Excelem víte kulové, jaké jsou kde šance. Původně jsem chtěl jen skript pro sebe a kamarády, ale když jsem viděl jeho přínos, rozhodl jsem se to dát veřejně a na socky. Za týden mi Vercel napsal, že jsem přešvihnul finanční limit svého účtu, tím jsem se podíval na návštěvnost a pochopil, že to lidé asi fakt používají.
Zde začíná „vibecoding“. Místo abych začal psát import pandas, otevřel jsem terminál ke svému „týmu AI agentů“. Pojďme si o tom něco říct, než si z toho učiníme pár závěrů.
Metodika práce: Orchestrace, ne programování
Celý vývoj Přijímaček na školu probíhal v režimu, kdy já dodávám potřeby, doménovou znalost a architekturu, a AI dodává návrhy, analýzy a implementaci.
Náš „virtuální tým“ fungoval následovně:
- Analytik (agent Hypata): Dostala za úkol navrhnout metodiku. Prošla data, navrhla řešení. Vše si vyhodnotila sama systémem LLM-as-a-judge. Já jsem její hypotézy pouze korigoval.
(Technicky je Hypata Claude Code se specifickými instrukcemi, a modelem Anthropic Opus, která ukládá výstupy své práce do vědomostní základny.) \ - Kodér (agent Mirja): Dostala za úkol implementovat logiku a podle oponovaného zadání vytvořit kód, otestovat ho a vystavit na testovací prostředí. Mirje jen říkám „realizuj“. Nejtěžší byl modul dostupnosti škol MHD. Dopravní data totiž nemají jednotný formát pro celou ČR a načtení otevřených dat CHAPS byl pro Mirju boj na 4 hodiny…
(Technicky je Mirja separátní běh Claude Code, která načítá připravené dokumenty od Hypaty a realizuje je s levnějším modelem Sonnet, nebo se přepíná do Opusu a provede plánování, kde potřebuje.) - Validátor (agent Dave): Bere dokumentaci od Hypaty a kód od Mirje a hledá v nich logické díry nebo bezpečnostní rizika.
(Technicky: Dave je záměrně zcela jiná rodina LLM - dnes CODEX 5.3 - aby eliminovala slepotu jednoho modelu. Sahá si do adresářů Hypaty a Mirje, celé kouzlo „orchestrace“ je v tom, kdy a do jakých a co do nich kdo uložil a s čím který model volat.)
Náklady na vývoj v účtu za AI? Nevelké - používám Max tarif (200$) i pro jiný vývoj a také CODEX účet za cca 100$ měsíčně - a tento projekt mi z toho podstatně neubral (=nenarazil jsem na limit).
Ukažme si to v praxi
Asi si to zatím pořád neumíte představit, tak si pojďme laickými slovy ukázat, jak to v praxi probíhá. Vymyslíte si novou funkci. Řekneme, že by bylo zajímavé stanovit koeficient obtížnosti přijetí na jednotlivé školy. Hypata ověřila několik hypotéz a nakonec navrhla koeficient obtížnosti založený na převisu poptávky, bodových výsledcích a profilu uchazečů.
Zrovna ty výkyvy (pokud jsou) způsobují, že je obtížné odhadnout šance na přijetí - a nesouvisí to s tím, jak je škola dobrá. Spíše je vidět, že nejtěžší je přijetí na školy, které jsou v dopravně dobrých lokalitách vnímané jako nejlepší (což asi nepřekvapí). Toto Dave oponuje, když on zoponuje dokument, tak se na něj znovu dívá Hypata a „vypořádává připomínky“.
Pak vzniká draft kódu (Mirja), probíhá testování (lint, greptile atd) a následné vyhodnocení metodou LLM as a Judge, kdy já už koukám jen na vizuální formu odvedené práce, čili jak to vypadá.
Kód je komodita, hodnotu má jen funkčnost
Tady narážíme na největší mentální blok tradičních vývojářů. Při vibecodingu je mi naprosto jedno, jak vypadá kód uvnitř.
Zajímá mě jediné — jestli jsou splněné parametry:
- Bezpečnost: Data netečou, kam nemají.
- Výkon: Nezatěžuje to hardware.
- Architektura: Dodržuje se DDD, P10 a mikroarchitektura.
- Dokumentace: Je kód automaticky zdokumentován?
- Vizuální: Drží se stanovený UI vzor přístupnosti.
Jak to ověřuji? Metodou „LLM as a Judge”: jeden model kód napíše, jiný (záměrně z jiné rodiny LLM) ho audituje a píše k němu testy — někdy ještě před samotnou implementací. Pokud testy projdou, nasazuji. Říkali v televizi, že se AI spolu zločinně domlouvá? No, tak CODEX se s Opusem rozhodně nedomlouvá, ani na Nově…
Člověk v tomhle procesu funguje jako finální arbitr u velkých rozhodnutí a u UI/UX. AI tíhne k funkční strohosti a estetické nudě — je potřeba ji pošťouchnout. Když jsem se domluvil s lidmi z Hlídače státu na převzetí projektu, zadal jsem úkol analyzovat design Hlídače, vytvořit jeho design manuál a všechny komponenty webu portovat na jeho vzhled. Vyřízeno za 30 minut. Jediný zásek bylo logo, které ve formátu SVG nevypadá zmenšeně nic moc (Mirja usoudila, že si toho Michal Bláha s pravděpodobností 86,3 % nevšimne, což Dave potvrdil).
Díky výše uvedenému postupu si mohu dovolit i náročnou funkci nasadit za minimum vlastního času. V podstatě si vymyslím funkci, AI nechám vyzkoumat, jak ji optimálně provést, pak upravím detaily. Například bylo problémem to, jak prezentovat způsob výpočtu výsledku přijímaček, který ve skutečnosti je stanoven na skóre (až 200 bodů), jenže u přijímaček nemůžete dostat více než 100 bodů (ty nejsou skore, do toho se přepočítávají!) - takže to lidi mátlo. Původně Hypata trvala na tom, že je lepší preferovat přesnost před snazším pochopením, nakonec jsem to přebil vlastním rozhodnutím.
Past jménem „Vlastnictví softwaru“
Zní to jako pohádka o konci drahých programátorů? Pozor. Je tu háček, který přesně popsal Max Musing ve své eseji The Vibe Coding Trap.
Snížili jsme náklady na vytvoření softwaru (z ničeho na funkční software) téměř na nulu. Ale náklady na vlastnictví (provoz funkčního software do nekonečna) nezmizely. Naopak. Proto SaaS neumírá. Platíte za to, že nekonečný provoz software řeší někdo jiný. Proč to má cenu?
Vytvořil jsem totiž systém, který generuje tisíce řádků kódu denně. Říkám tomu „API-spaghetti monstrum“. AI ráda lepí věci k sobě tím nejjednodušším způsobem. Pokud zítra poskytovatel dopravních dat nebo CERMAT změní formát dat, můj systém se sesype. Musím do toho vstoupit a postrčit ho. Namítnete možná, že by se vyplatilo udělat autoadaptační systém na změnu formátu, ale tím si zanesete další nepříjemnosti a pracujete na něčem, co nemusí přijít a co bude lepší řešit v momentě, kdy to přijde. Zatímco dříve jste legacy kód dělali nepřehlednou logikou v něm, nyní to děláte odvolávkami na třetí strany, které nemáte pod kontrolou. Namísto Maintenance tomu tedy říkejme Regeneration.
Vibecoding není o tom, že vytvoříte software a máte hotovo. Je to o tom, že vytvoříte proces, který musíte neustále „přegenerovávat“. Údržba v tomto světě neznamená opravovat řádek 450. Znamená to zahodit celý modul a nechat agenta, aby ho napsal znovu podle nové dokumentace. Kdo toto nepochopí, toho technický dluh sežere zaživa. A technologický dluh ve vibe codingu nevzniká kódem, který jste nevytvořili, ale zbytečným API a propojením, které jste vytvořili a nemuseli. Protože tím jste přestali kontrolovat bezezbytku celý tok.
Co to znamená pro trh?
- SaaS neumírá, umírá „průměrné SaaS“: Pokud vaše aplikace jen balí databázi do hezkého UI (tzv. wrapper), jste mrtví. To si dnes každý „vibecodne“ za odpoledne sám. Přežijí jen systémy s hlubokou integrací a složitým know-how (jakým jsou třeba i právní limitace) - jako Stripe nebo WorkOS, kde platíte za to, že nemusíte řešit provoz a compliance. V SaaS je často velmi příjemné to, že někdo vymyslí schéma práce, workflow, které je dobré používat a které dále rozvíjí a adaptuje na změny světa. To si kvůli pár korunám nebudete vymýšlet sami a otázka je, proč byste to za desítku dolarů nutili dělat AI, když za podobnou částku vám to dodavatel SaaS prodá.
- Produktivita roste přes objem výstupů, ne přes rychlost. AI umožňuje dělat víc věcí, ne jen ty stejné rychleji — dokumentovat, bugfixovat, zkoušet funkce, které by se jinak nedělaly. Otázka je, jestli to uživatelé ocení: lidé obecně preferují stabilitu před rychlým vývojem a přeučovat se na novou verzi nástroje chtějí jen tehdy, když reaguje na reálnou změnu jejich prostředí.
- Demokratizace s hvězdičkou: Ano, vývoj se demokratizuje. Kolega si může naprogramovat Secret Santu na Macaly.com. Ale postavit komplexní produkční systém vyžaduje víc než jen promptování. Vyžaduje to vědět, že existuje něco jako Dijkstra algoritmus nebo DDD architektura. AI z vás neudělá experta, ale expertovi dá křídla.
- Role Orchestrátora: Pokud dnes jako vývojář ignorujete AI, degradujete se do role „dělníka kódu“. Budoucnost patří těm, kteří se posunou na „orchestrátory“ – lidi, kteří řídí roje agentů (jakkoliv velké, zákazníci už na ten termín slyší, tak ho používejme), definují vizi a hlídají kvalitu výstupu. Pro vás je to příležitost prodat jiné své schopnosti, než zapamatování si syntaxi typescriptu.
- Velké firmy dnes chtějí pomalý, ale plně předvídatelný vývoj. Na porady se nosí návrhy funkcí, ne seznam vydaných novinek a vyhodnocení průšvihů a přínosů, co automaticky vzniklé funkce vytvořily. Jiný přístup se uplatní jen tehdy, když se trh mění.
Lidé se nechtějí pořád přeučovat na novou verzi nástroje. Činí tak jen ve chvíli, když nástroj reaguje na bezprostřední změny prostředí, ve kterém působí. Nástroj sám nemá být změnou, ale reflexí změn trhu, ačkoliv výjimky toto pravidlo jen potvrzují.
Web Přijímačky na školu by nemohl fungovat, kdyby se trh nezměnil. Kdyby se nezavedly jednotné přijímačky, kdyby neexistovala otevřená data, kdyby se takto fundamentálně hluboce neproměnil „trh“ přijímaček na střední školy.
Chcete začít vyvíjet v Claude Code? Tady máte ode mne zdarma kredit na týden práce pro první tři zájemce… (už jsou využité!)