Platíte AI za to, aby psala bugy, a pak vám naúčtuje jejich opravu

Uber prý spálil celý svůj rozpočet na AI coding pro rok 2026 za čtyři měsíce a část, ze které by mělo být každému CTO nepříjemně, je to, co za to dostal: podle toho, co se proslýchá, zhruba nic měřitelného z hlediska skutečně doručených projektů. Ne pomaleji, ne rychleji, jen mnohem větší účet. Pořád se k tomu vracím, protože to skoro dokonale sedí na to, co vidíme, když nás zavolají uklízet po týmu, který vsadil všechno na agentní coding nástroje a teď se diví, proč se jim lead time nehnul, navzdory faktuře z Cursoru, která vypadá jako druhý AWS účet.

Číslo, které koluje a které neumím nezávisle ověřit, ale sedí mi to do pocitu, je, že firmy utrácejí zhruba 44 procent svých AI tokenů na opravu bugů, které samotná AI předtím zanesla. Přečtěte si to dvakrát. Skoro polovina útraty je nástroj, který uklízí po nástroji. Kdyby vám junior na kontraktu napsal kód a pak vám naúčtoval za stejnou sazbu opravu vad v tom samém kódu, vyhodíte ho do týdne. Jenže protože tokenový měřič tiká neviditelně na pozadí, nikdo na to neukáže prstem.

James Shore zformuloval nejčistší verzi toho argumentu a rozšířila se ne náhodou. Zdvojnásobit rychlost psaní pomůže jen tehdy, když jste zároveň zlevnili údržbu na polovinu, a tu na polovinu nezlevnil absolutně nikdo. Psaní nikdy nebylo ta drahá část softwaru. Čtení, pochopení, debugování a bezpečné měnění už existujícího kódu, tam tečou peníze. AI nástroje optimalizují ten levný krok a potichu nafukují ten drahý.

Každý velocity dashboard, který mi nějaký zakladatel od začátku roku hrdě sdílel přes obrazovku, měří něco vedle hodnoty, ale ne hodnotu samotnou. Řádky kódu, mergnuté pull requesty, uzavřené story pointy, commity na engineera za týden. Vždycky to byly slabé proxy a daly se snést, dokud musel každý znak naťukat člověk, protože to ťukání aspoň korelovalo s přemýšlením. Tahle korelace je teď rozbitá. Agent otevře čtrnáct pull requestů ještě před obědem, váš graf PR za týden vyletí vertikálně a váš skutečný produkt se nepohne ani o píď blíž k čemukoli, co zákazník chtěl.

To, co přijde dál, je ta opravdu nebezpečná část a je organizační, ne technická. VP of Engineering vidí graf jak roste a reportuje velocity nahoru boardu, board vidí rostoucí velocity a schválí víc AI seatů, engineeři dole vědí, že se v codebase pracuje čím dál hůř, ale metrika říká, že je všechno super, takže nikdo nechce být ten, kdo kazí náladu. Postavili jste uzavřenou smyčku, která odměňuje propustnost tokenů a trestá každého, kdo upozorní, že propustnost není výstup.

Měli jsme klienta, středně velký SaaS na zpracování dokumentů, kterému se počet mergnutých PR meziročně zhruba zdvojnásobil a jehož skutečné dodávání feature zákazníkům, když jsme spočítali věci, které teď jejich uživatelé umí a předtím neuměli, mírně kleslo. Ty PR navíc byly refactory AI-generovaného kódu, reverty AI-generovaných regresí a testy psané na pokrytí chování, o kterém nikdo nerozhodl. Ten graf byla fikce, na kterou celá firma přistoupila.

Dluh na údržbě z AI-psaného kódu se neobjeví tam, kde byste ho hledali. Neohlásí se na sprint retro. Hromadí se v té půlsekundě zaváhání navíc, kterou cítí každý engineer, než sáhne na soubor, který agent vygeneroval před třemi měsíci. Na soubor, kterému nikdo úplně nerozumí, protože ho nikdo nenapsal. Na soubor s mírně špatnou abstrakcí, která technicky funguje a testy projde, ale modeluje doménu tak, že bojuje s každým novým požadavkem.

Vady se taky shlukují jinak. Lidské bugy bývají lokální a hloupé: off-by-one, zapomenutá null check, věc, kterou code review chytí. AI bugy bývají věrohodné, sebejisté a strukturální: celá strategie ošetření chyb, která potichu polyká výjimky, caching vrstva, která vypadá idiomaticky a je pod zátěží subtilně racy, databázová migrace, která je syntakticky dokonalá a sémanticky katastrofální. To jsou přesně ty vady, které projdou review, protože vypadají jako dobrý kód, a jsou to nejdražší bugy, jaké existují, protože je najdete v produkci, o týdny později, kdy je kontext pryč.

Nedávno jsme dělali bezpečnostní audit zákaznického portálu postaveného z velké části agentním nástrojem a našli jsme tři různá místa, kde uživatelský vstup tekl do dotazu bez parametrizace, každé zabalené v kódu dost čistém na to, aby ho dva lidští revieweři propustili. AI napsala SQL injection zranitelnosti sebejistě, dobře okomentovaně a krásně naformátovaně. Taková je textura toho dluhu. Není to nepořádný kód, který poznáte, je to čistý kód, který je špatně, a čistý-ale-špatně je ta nejtěžší věc na světě, jak chytit.

Pokud chcete tuhle útratu řídit, potřebujete metriky, které měří dodanou hodnotu a vynaložené náklady, ne vyprodukované znaky, a musí být dost jednoduché na to, abyste je položili před netechnické členy boardu bez vrstvy překladu. Tady je to, co jsme začali doporučovat a používat interně.

Měřte change failure rate a mean time to recovery, dvě DORA metriky, které skutečně zachycují kvalitu, a sledujte je v čase proti vaší AI útratě. Pokud máte vyšší frekvenci deployů, ale change failure rate vám během stejného období, kdy jste nasadili AI tooling, vyletěl z 8 na 19 procent, máte odpověď, a tomuhle souvětí board rozumí. Sledujte procento engineering hodin strávených na nové funkcionalitě pro zákazníky versus na přepracovávání a buďte upřímní, že reverty a opravy regresí se počítají jako rework, i když původní kód napsala AI a shipnul se rychle.

Dejte reálné číslo na cost-per-shipped-outcome. Ne náklad na PR, ne náklad na řádek, ale vezměte celkovou AI útratu plus plně započítané engineering hodiny a vydělte to počtem věcí, které teď vaši zákazníci umí a minulý kvartál neuměli. Je to hrubé číslo, bude nepříjemné, a o tu nepříjemnost jde, protože většina týmů teď reportuje jmenovatele nafouknutého AI šumem a náklady schované ve faktuře za SaaS, kterou nikdo nečte.

A sledujte read-time-to-change na svých nejhorších souborech, čas, který engineerovi zabere bezpečně upravit nejzašmodrchanější části codebase. Když to číslo začne lézt nahoru napříč částmi systému, kterých se dotkla AI, sledujete, jak se dluh na údržbě hromadí v reálném čase, ještě než se projeví jako zmeškané deadliny.

Nic z toho neznamená nástroje vypnout. Používáme je každý den, na Next.js frontendech, Go službách i Django backendech, a na pevně ohraničeném úkolu se seniorem u kormidla si agentní nástroj svoje peníze opravdu vydělá. Problém nastává, když berete sto až dvě stě dolarů měsíčně na engineera jako násobič produktivity, který se ospravedlní sám, zatímco ve skutečnosti je to elektrické nářadí, které zesiluje to, jaký úsudek už v místnosti je. Dejte ho silnému týmu s dobrou review disciplínou a je to páka. Dejte ho tenkému týmu pod tlakem deadlinu a je to stroj na dluhy, který shipuje rychle a účtuje vám dvakrát.

Řešení v rámci governance tedy není tabulka tokenových limitů, je to disciplína. Vyžadujte, aby AI-generovaný kód prošel stejnou laťkou review jako lidský kód, což v praxi znamená review zpomalit, ne zrychlit, protože sebejistě-špatně se chytá hůř než nepořádně-špatně. Držte agenta na krátkém vodítku u čehokoli, co sahá na auth, platby, migrace nebo přístup k datům, přesně tam, kde pořád nacházíme ty drahé strukturální bugy. A reportujte boardu kvalitativní metriky vedle těch velocity, protože ve chvíli, kdy change failure rate a cost-per-outcome sedí vedle počtu PR, přestane být graf velocity schopný lhát sám.

Týmy, které vyhrají příští dva roky, nebudou ty, co napíšou nejvíc kódu. Budou to ty, co dřív než konkurence pochopily, že platí za bugy i za jejich opravy, a rozhodly se přestat předstírat, že rostoucí graf je totéž co lepšící se byznys.