AI napíše kód za odpoledne, ale oprava zabere dva dny. Skrytá daň

Rychlost psaní nikdy nebyla úzké hrdlo

Základní omyl, který stojí za iluzí produktivity, je skoro banální. Když se vývojář zeptá AI a ta mu za tři vteřiny vyplivne funkční regex nebo šablonu nového endpointu, má pocit, že ušetřil spoustu času. A v tu chvíli má pravdu — autocomplete opravdu zrychlil práci jemu samotnému.

Jenže úzké hrdlo ve většině firem nikdy nebylo psaní kódu. Bylo to code review, přepínání kontextu mezi úkoly, čekání na staging prostředí nebo tři vlákna na Slacku, ve kterých se zjišťuje, proč se platební webhook v produkci spouští dvakrát. S žádnou z těchhle věcí AI moc nepomůže — a v některých případech je ještě zhorší.

Čísla to ukazují hezky naostro. Podle analýzy české firmy steezr dnes zhruba 84 % vývojářů používá AI nástroje v každodenní práci — to je rychlejší adopce než u cloudu nebo kontejnerů. Jenže když se produktivita měří na úrovni celé organizace, ne na úrovni jednotlivého promptu, pohybuje se zisk někde mezi 10 a 30 %. A horní hranici vidíte hlavně u nového, „greenfield“ kódu s pevně ohraničeným zadáním, ne u údržby a integrací, které reálně žerou většinu kalendáře.

Skrytá daň: přepisování, které nikdo nepočítá

Rozdíl mezi tím, co vývojář cítí, a tím, co firma dostane, má konkrétní mechanismus. AI je mimořádně dobrá v tom, že rychle vygeneruje věrohodný kód. Mnohem horší je v tom, že vygeneruje kód správný — takový, který sedí do vaší architektury, respektuje vaše konvence pro ošetření chyb a tiše nezavede N+1 dotaz, kterého si nikdo nevšimne, dokud ve dvě ráno nezahltí connection pool databáze.

Problém je, že rychlost se projeví v okamžiku generování, ale náklady se objeví později — v review, při debugování a v údržbě. A protože jsou tyhle náklady rozptýlené a zpožděné, nikdo je už nepřičte zpátky k nástroji, který je vyvolal. V tabulce zůstane spotřeba tokenů a počet aktivních licencí, vývojáři hlásí, že se cítí rychlejší, a senioři mezitím tráví čím dál větší kus týdne pročítáním rostoucích pull requestů plných sebevědomě vypadajícího kódu.

Konkrétní příklad z praxe steezru, české softwarové firmy z Prahy: inženýr použil AI k naskicování vrstvy pro zpracování dokumentů a za odpoledne měl hotový velký kus práce. Jenže vygenerovaný kód zvládal jen „šťastnou cestu“ — chybné PDF soubory tiše zahazoval tím, že chytal širokou výjimku a nic nezaznamenal. Trvalo dva dny review a jeden produkční incident, než se na to přišlo. Čistý ušetřený čas na téhle funkci byl záporný. A to je přesně ten vzorec: objem kódu vzrostl, objem hodnoty ne.

Když se začne měřit, čísla se ošklivě zkřiví

Nejzábavnější část celého příběhu je, co se stane, když se firmy pokusí produktivitu AI kódu nějak změřit. Protože přesně ve chvíli, kdy před inženýry postavíte číslo a svážete ho s hodnocením, začnou ho optimalizovat — místo toho, aby dělali užitečnou práci.

Uber podle steezru údajně vyčerpal celý rozpočet na AI nástroje pro rok 2026 za čtyři měsíce, aniž by se objevil odpovídající skok v měřitelném výstupu. Stejné tempo dodávky, stejná chybovost, dramaticky vyšší náklady na cloud a API. Peníze někam zmizely, tokeny se spotřebovaly, ale to, co měl rozpočet koupit — rychlejší dodávku — se nikde neobjevilo.

Amazon zase postavil interní nástroj pro sledování produktivity Kirorank, který měl měřit a odměňovat výstup podpořený AI. Inženýři udělali přesně to, co inženýři vždycky udělají, když jim dáte metriku: začali ji honit. Nabíjeli tokenové náklady a generovali aktivitu, která skvěle skórovala, ale žádnou hodnotu neprodukovala. Amazon nakonec nástroj zabil, protože signál, který produkoval, byl horší než žádný signál. Přesně naplánovaně dorazil Goodhartův zákon: jakmile se metrika stane cílem, přestane být dobrou metrikou.

Co měřit místo tokenů

Jestli chcete výdaje za AI obhájit poctivě, vyhoďte každou metriku, která počítá používání AI, a nahraďte ji metrikami, které počítají výsledek. Tedy ty samé, které vás zajímaly dávno předtím, než tohle všechno začalo: cyklový čas od prvního commitu po nasazení, míra selhání změn a čas obnovy po incidentu. Tohle jsou metriky DORA a je jim úplně jedno, jestli kód napsal člověk, nebo model. Zajímá je jen to, jestli se software dostává do produkce spolehlivě a rychle.

Nejjednodušší návod, jak to ověřit, zní skoro triviálně: porovnejte dva týmy nebo dvě čtvrtletí — jedno s těžkým nasazením AI a jedno bez — a sledujte, jestli cyklový čas skutečně klesl a jestli se míra selhání nezhoršila. Pokud tým s AI dodává rychleji, ale častěji rozbíjí produkci, produktivitu jste nezískali. Jen jste přesunuli náklady z klávesnice na pohotovostní službu.

A sledujte hlavně velikost pull requestů. Pokud průměrná velikost PR meziročně roste a roste s ní i čas na review, ukazuje se daň z AI. U jednoho klienta steezru narostla průměrná velikost PR meziročně o 40 % a čas na review skoro stejně. Zdravý vzorec jsou menší a častější PR, kde AI někomu pomohla rychleji dojít k čistému diffu — ne rozsáhlé diffy plné vygenerovaného kódu, kterému plně nerozumí ani sám autor.

Kde AI opravdu pomáhá — a kde držet ruku nad brzdou

Pointa rozhodně není, že jsou AI nástroje k ničemu. Jsou výborné na věci nudné a málo rizikové: psaní testů k existujícímu kódu, příprava migrací, generování šablon pro nový endpoint podle zavedeného vzoru, překlad funkce z jednoho jazyka do druhého nebo vysvětlování neznámého kódu. Tam je zrychlení skutečné a riziko malé.

Naopak na architekturu, na cokoli, co se dotýká autentizace, plateb nebo integrity dat, a na rozhodnutí, která se draze vrací, držte AI zkrátka. Rozumné pravidlo zní: generovaný kód berte jako první nástřel juniora, který si musí své místo zasloužit — přečtěte každý řádek, prožeňte ho reálnými okrajovými případy a nikdy nemergujte jen proto, že to „vypadá dobře“ a testy náhodou projdou. AI je totiž mimořádně dobrá v tom, že napíše kód, který projde testy, které sama napsala.

Co z toho plyne pro české firmy

Pro českou scénu je tenhle pohled o to zajímavější, že jeden z nejjasnějších hlasů v debatě pochází z Prahy. steezr je česká firma a její rozbor se šíří napříč oborem právě proto, že popisuje něco, co tuší každý technický vedoucí, ale málokdo si to troufne přiznat na poradě s finančním ředitelem: adopce není hodnota. To, že 94 % týmu nástroj denně používá, není odpověď na otázku „co jsme za ty peníze dostali“.

A zároveň to není důvod AI odmítnout. Oněch 10 až 30 % zisku na úrovni organizace je reálných a stojí za to je uchopit — jen je potřeba je měřit výsledky, ne aktivitou. Firmy, které z téhle fáze vyjdou vítězně, budou ty, které AI berou jako jeden vstup do systému, kterému rozumí, a ne jako magický výdaj, který automaticky zrychluje. Přesně takhle se k tomu staví i samotný CACM: rychlost tvorby kódu je viditelný zisk, ale přepisování, které za ní následuje, je skrytá daň.