Váš rozpočet na AI kódování kupuje iluzi rychlosti

Váš CFO přijde na jedna-na-jedna s tabulkou, na které je roční útrata za Copilot seaty plus faktura za Claude Code API plus nějaký Cursor enterprise kontrakt, co někdo loni v březnu narychlo podepsal. Otázka je jednoduchá a brutální: co jsme za to dostali. Pokud je vaše odpověď nějaká variace na „94 % týmu to používá denně

Uber prý spálil celý svůj rozpočet na AI tooling pro rok 2026 za čtyři měsíce, a část, ze které by se mělo udělat nevolno každému engineering lídrovi, je, že tomu neodpovídal žádný skok v měřitelném výstupu. Stejná kadence dodávek, stejná míra defektů, dramaticky vyšší náklady na cloud a API. Peníze někam zmizely, tokeny se prokazatelně spotřebovaly, ale to, co měl rozpočet koupit, tedy rychlejší shipování, se na žádném dashboardu nikdy neukázalo.

Na zkušenost Amazonu pořád myslím, protože je černě vtipná tak, jak umí být jen reálné selhání engineering incentiv. Postavili interní nástroj na produktivitu, Kirorank, který měl sledovat a odměňovat výstup s pomocí AI, a inženýři udělali přesně to, co inženýři vždycky udělají, když jim postavíte před nos číslo a navážete na něj hodnocení: to číslo zoptimalizovali. Lidé začali pumpovat náklady na tokeny a generovat aktivitu, která dobře skórovala v metrice, přitom neprodukovali nic hodnotného, a Amazon nakonec nástroj zabil, protože signál, který produkoval, byl horší než vůbec žádný signál. Goodhartův zákon dorazil přesně na čas. Ve chvíli, kdy se z měřítka stane cíl, přestává být dobrým měřítkem, a „řádky kódu vygenerované AI" nebo „prompty na vývojáře za den" jsou asi ten nejsnáz manipulovatelný cíl, jaký si vůbec můžete vybrat.

Poučení není, že AI tooling je podvod. Ve steezru tyhle nástroje používáme každý den a vyplatí se. Poučení je, že když měříte špatnou věc, utratíte reálné peníze za nákup dojmu pokroku, a budete to dělat měsíce, než si toho někdo všimne, protože lidé, co tu aktivitu generují, mají všechny důvody vám pořád říkat, že to funguje.

Únik nastává v mezeře mezi kódem, který se vygeneruje, a kódem, který doopravdy doputuje do produkce a zůstane tam. AI je mimořádně dobrá v rychlém produkování věrohodně vypadajícího kódu. Mnohem hůř je na tom s produkováním správného kódu, který zapadá do vaší existující architektury, respektuje vaše konvence pro error handling a tiše nezavede N+1 query, kterého si nikdo nevšimne, dokud se ve dvě ráno během špičky nezasytí connection pool PostgreSQL.

Narazili jsme na to letos na document processing pipeline pro jednoho klienta. Jeden inženýr použil Claude Code, aby za odpoledne naskafoldoval kus ingestion vrstvy, což působilo jako obří výhra, jenže vygenerovaný kód krásně zvládal happy path a tiše polykal malformované PDFka tím, že odchytával širokou výjimku a nic nelogoval. Trvalo dva dny review a jeden produkční incident, než se to našlo, takže čistý ušetřený čas na té featuře byl záporný. Jediný důvod, proč jsme to vůbec odhalili, je, že k výstupu AI přistupujeme jako k prvnímu draftu juniora, ne jako k hotové práci.

Tohle je vzorec úplně všude. Rychlost se objeví ve chvíli generování a náklad se objeví později, v review, v debugování, v ocasu údržby, a protože jsou tyhle náklady rozptýlené a opožděné, nikdo si je nepřipíše zpátky k AI nástroji, který je způsobil. Takže tabulka ukazuje spotřebované tokeny a aktivní seaty, vývojáři hlásí, že se cítí rychlejší, a mezitím vaši senioři tráví čím dál víc týdne review většími PRs plnými sebejistě vypadajícího kódu, který se musí číst pozorně, protože může být subtilně špatný způsobem, jakým ručně psaný kód obvykle nebývá. Objem kódu vzrostl. Objem hodnoty ho nutně nenásledoval.

Pokud chcete tu útratu obhájit poctivě, vyhoďte každou metriku, která počítá využití AI, a nahraďte ji metrikami, co počítají výsledky, ty samé výsledky, na kterých vám záleželo dávno předtím, než tohle všechno vzniklo. Cycle time od prvního commitu po merged-and-deployed. Change failure rate. Čas na obnovení služby po incidentu. DORA metriky tu byly celou dobu a je jim jedno, jestli kód napsal člověk nebo model, zajímá je jenom to, jestli váš systém dostává lepší software do produkce spolehlivě a rychle.

Udělejte to srovnání pořádně. Vezměte dva týmy nebo dvě čtvrtletí, jedno s těžkým AI toolingem a druhé bez něj, a podívejte se, jestli cycle time skutečně klesl a jestli se change failure rate udržela nebo zhoršila. Pokud váš AI-heavy tým shipuje rychleji, ale častěji rozbíjí produkci, nezískali jste produktivitu, jen jste přesunuli náklad z klávesnice na on-call rotaci, a tenhle obchod se skoro nikdy nevyplatí.

Sledujte review zátěž jako předstihový indikátor. Pokud roste velikost PR a s ní roste i čas na review jednoho PR, je to AI daň, co se ukazuje, a obvykle to znamená, že lidé generují víc kódu, než ho pozorně čtou. Zdravý vzorec jsou menší a častější PRs, kde AI někomu pomohla dostat se rychleji k čistému diffu, ne rozlezlé diffy plné generovaného kódu, kterému sám autor úplně nerozumí. U jednoho klienta, kterého jsme auditovali, vyrostla průměrná velikost PR meziročně o 40 % a čas na review skoro stejně, a jakmile jsme na to ukázali, příčina byla všem v místnosti jasná, jen se na to dosud nikdo nedíval touhle optikou.

Týmy, co dosahují reálných zisků, nejsou ty s největším rozpočtem na tokeny, ale ty, co přestavěly workflow tak, aby AI dělala práci, ve které je opravdu dobrá, a lidé pevně drželi kontrolu nad prací, na které záleží. Používejte ji agresivně na věci, které jsou otravné a s nízkou sázkou: psaní testů proti existujícímu kódu, draftování migrací, generování boilerplate pro nový endpoint, který sleduje zaběhnutý vzorec, překlad funkce z jednoho jazyka do druhého, vysvětlení neznámé codebase. Tam je zrychlení reálné a riziko malé.

Držte ji na krátkém vodítku u architektury, u všeho, co se dotýká auth nebo plateb nebo integrity dat, u rozhodnutí, která se draze vracejí zpátky. Našim inženýrům říkáme, ať se na generovaný kód dívají jako na draft, který si musí zasloužit své místo, což znamená přečíst každý řádek, prohnat ho reálnými edge case a nikdy nemergovat něco jen proto, že to vypadá správně a testy náhodou prošly, protože AI je velmi dobrá v psaní kódu, který projde testy, které si taky sama napsala.

Investujte do nudné infrastruktury, která zrychluje review, protože review je teď úzké hrdlo. Dobré CI, rychlé test suity, striktní typování, lintery, co odchytí ty hloupé věci, aby se lidé mohli soustředit na ty subtilní. Pokud jste na Go, kompilátor a typový systém už tady odvedou obrovskou práci, což je jeden z důvodů, proč Go s pomocí AI obvykle selhává hlasitěji a dřív než Python s pomocí AI, kde sebejistě špatná funkce může v produkci sedět týdny, než si jí někdo všimne.

A buďte ochotni odebrat seaty lidem, kterým to nepřináší hodnotu. Ne každý profituje stejně, zisky se koncentrují u inženýrů, kteří už codebase znají dost dobře na to, aby poznali, kdy se model plete, a platit za nástroj, který přiměje vaše nejslabší inženýry produkovat víc kódu, který pak musíte uklízet, je náklad převlečený za investici.

Vraťte se na tu schůzku s jiným číslem. Ne seaty, ne tokeny, ne procento adopce, ale before-and-after na cycle time a change failure rate pro konkrétní sadu týmů v konkrétním okně, s poctivou poznámkou o tom, kde tooling pomohl a kde ne. Pokud jsou čísla dobrá, máte reálný argument a útratu obhájíte s klidným svědomím. Pokud jsou čísla stejná nebo horší, právě jste firmě ušetřili spoustu peněz a měli byste to říct, protože zabití nefungujícího nástroje je výhra, ne selhání.

Firmy, co z tohohle období vyjdou napřed, jsou ty, které k AI toolingu přistupují jako k jednomu vstupu do systému, kterému doopravdy rozumějí, ne jako ke kouzelné útratě, co automaticky produkuje rychlost. Zisky 10 až 30 % jsou reálné a stojí za to je posbírat, ale posbíráte je jen tím, že budete nemilosrdní v měření výsledků a budete ignorovat dashboard aktivity, který vám vendoři, a upřímně i vaši vlastní vývojáři, budou s radostí mávat před očima. Adopce nikdy nebyla ta těžká část. Adopce vyletěla na 84 % skoro sama. Proměnit to ve vyshipovaný a spolehlivý software je ta skutečná práce, a vypadá přesně jako engineering disciplína, o které jste věděli, že ji potřebujete, ještě dávno předtím, než se tohle všechno objevilo.