V Silicon Valley se zrodil nový způsob, jak měřit úspěch vývojáře. Nejde o kvalitu kódu. Nejde o vyřešené problémy. Jde o tokeny. Konkrétně o to, kolik jich vývojář za den spotřebuje. Čím vyšší rozpočet na tokeny, tím větší odznak cti. Tomuto jevu se začíná říkat tokenmaxxing a data naznačují, že jde o jeden z nejdražších omylů současného softwarového vývoje.
Tokeny jsou základní jednotkou, kterou AI nástroje jako Claude Code, Cursor nebo GitHub Copilot používají ke čtení, psaní a uvažování nad kódem. Logika tokenmaxxingu je, že více tokenů rovná se více výstupu, více produktivity, více dopadu. Jenže data to vyvracejí.
Co zjistila analýza
Analytická platforma Jellyfish analyzovala přes 12 000 vývojářů ve 200 firmách v průběhu prvního čtvrtletí roku 2026. Zjistili, že typický vývojář spotřebuje přibližně 51 milionů tokenů měsíčně. Zkušený vývojář jich spotřebuje přes 380 milionů za měsíc, tedy více než sedmkrát tolik.
Co za to dostane? Vývojář z nejnižšího stupně tokenovách výdajů utratil za celé první čtvrtletí necelé 3 dolary a odeslal průměrně 11 schválených žádostí o začlenění kódu (pull requestů). Vývojář z nejvyššího stupně utratil 1 822 dolarů a odeslal průměrně 23 pull requestů. Náklady vzrostly zhruba 600násobně, ale výstup se zdvojnásobil.
Cena za jeden merged pull request se pohybuje od 28 centů u nejnižší skupiny uživatelů až po 89 dolarů u té nejvyšší. Tokeny se tedy nechovají jako lineární vstup. Chovají se spíše jako raketové palivo: jet rychleji je možné, ale vyžaduje to exponenciálně více zdrojů.
Iluze funkčního kódu
Problémem není jen cena, jde o to, co se s kódem děje po jeho přijetí. Alex Circei, zakladatel a šéf analytické firmy Waydev, která sleduje přes 10 000 softwarových inženýrů u 50 zákazníků, popisuje paradox, který vidí u manažerů znovu a znovu.
Manažeři se chlubí mírou přijetí kódu, která činí 80 až 90 procent. Takový údaj vypadá skvěle. Jenže přehlížejí to, co přichází po přijetí: vývojáři se k tomuto kódu musejí v následujících týdnech vracet a přepisovat ho. Reálná míra přijetí, po odečtení přepsaného kódu, klesá na 10 až 30 procent z původně vygenerovaného množství.
GitClear ve své zprávě z ledna zjistil, že vývojáři, kteří AI aktivně používají, vykazují 9,4krát vyšší míru tzv. code churn než jejich kolegové bez AI. Code churn označuje kód, který se napíše a záhy přepíše nebo smaže. Faros AI pak ve svém průzkumu z března, zahrnujícím data od 22 000 vývojářů ve více než 4 000 týmech, identifikoval nárůst code churn o 861 procent při vysokém využívání AI nástrojů.
Metriky, které klámou
Vývojáři debatují o metrikách produktivity desetiletí. Začínalo se s řádky kódu. Pak přišly commity, pull requesty, rychlost nasazení. Každá metrika se dříve nebo později ukázala jako nedostatečná, protože motivovala k optimalizaci sebe sama, ne skutečného výstupu.
Tokenmaxxing je pokračováním stejné logiky. Spotřeba tokenů je vstup do procesu, nikoli výstup. Měřit ji jako ukazatel produktivity dává smysl jedině tehdy, když chcete podpořit větší adopci AI nástrojů, nebo když tokeny prodáváte. Pro manažera, který chce vědět, zda jeho tým pracuje efektivně, je to zavádějící číslo.
Problém se navíc liší podle zkušenosti vývojáře. Juniorní programátoři přijímají výrazně více AI generovaného kódu než ti zkušenější. A právě oni pak čelí většímu objemu přepisování. Zkušení vývojáři jsou na tom lépe, protože si dokáží uvědomit, kde AI kód naráží na limity, a preventivně jej opravují dřív, než doputuje na review.
Bod skutečné efektivity
Jellyfish na základě dat identifikoval to, čemu říká "sweet spot" tokenovací křivky. Nejvyšší návratnost nepřináší malá skupina vývojářů s extrémně vysokou spotřebou tokenů. Přináší ji situace, kdy co nejvíce lidí v organizaci používá AI nástroje konzistentně a v rozumné míře. Takový přístup přináší výrazně více hodnoty než hrstka "tokenmaxxerů" jedoucích na plný výkon.
Zároveň to vysvětluje, proč mnoho týmů zatím plně neproměnilo příslib autonomních AI agentů v realitu. Takové systémy mohou přinést velké skoky v produktivitě, ale vyžadují solidní zázemí: izolovaná testovací prostředí, orchestraci a tzv. context engineering. Bez tohoto zázemí nelze bariéru efektivity překonat pouhým navyšováním spotřeby tokenů.
Starý problém
TechCrunch ve svém podcastu Equity zmiňuje, že propast mezi těmi, kdo AI skutečně rozumí, a ostatními se prohlubuje. A nová slovní zásoba, jako právě "tokenmaxxing", tuto propast jen zvýrazňuje. Zatímco jedni debatují o tom, zda je spotřeba 380 milionů tokenů měsíčně přiměřená, jiní stále tápou, jak správně AI nástroje do svého workflow vůbec zařadit.
Waydev kvůli nástupu rychlých AI nástrojů kompletně přepracoval svou platformu za posledních šest měsíců a vydal nové analytické nástroje sledující metadata AI agentů, tedy kvalitu a cenu jejich kódu. Atlassian před nedávnem koupil podobně zaměřený startup DX za miliardu dolarů, aby pomohl zákazníkům pochopit skutečnou návratnost investic do AI agentů. Trh s analytickými nástroji pro vývojáře roste rychle právě proto, že samotné AI nástroje tento pohled neposkytují.
Jak říká Circei: "Toto je nová éra vývoje softwaru a musíte se přizpůsobit. Není to přechodná vlna, která pomine." Jenže přizpůsobit se neznamená automaticky spotřebovávat více tokenů. Znamená to naučit se spotřebovávat tokeny chytře.
