Iluze produktivity podle METR v reálné práci na kódu

METR udělal randomizovanou kontrolovanou studii se zkušenými open source vývojáři, kteří pracovali na vlastních repozitářích. Šlo o codebase, které sami roky udržovali. Výsledek, který všichni v zápalu hádek přehlédli, zněl jasně: vývojáři používající AI nástroje potřebovali na splnění úkolů o 19 % víc času. Ne míň, ale víc. A s konfidenčním intervalem, který nepřekročil nulu. Samo o sobě je to zajímavé, ale ne zdrcující, protože rozumní lidé se můžou neshodnout na výběru úkolů, vyzrálosti nástrojů nebo na tom, jestli vývojáři Cursor uměli pořádně používat. Co by vám ale mělo brát spánek, pokud schvalujete rozpočty na nástroje, je rozdíl ve vnímání. Tíž vývojáři po dokončení odhadovali, že je AI zrychlila zhruba o 20 %. Subjektivní zážitek tedy hlásil 20% zrychlení, stopky ukazovaly 19% zpomalení. To je 39 bodů rozdílu mezi tím, co se reálně stalo, a tím, co si lidé mysleli, že se stalo. To není šum v měření. Je to systematické, strukturální zkreslení toho, jak inženýři vnímají vlastní produktivitu, když je ve hře LLM. Pokud celý váš argument pro nasazení Claude Code do týmu stojí na dotaznících mezi vývojáři a na pocitu z břicha, což je způsob, jakým se tahle rozhodnutí většinou skutečně dělají, stavíte na senzoru, který je špatně nakalibrovaný skoro o čtyřicet bodů. Sami jsme to viděli u klientských týmů, které přísahaly, že jim Cursor zásadně zvedl velocity, a pak nedokázaly ukázat jedinou metriku cycle time, která by se hnula.

Zpomalení není rovnoměrné a tvrdit, že je, by bylo stejně nepoctivé jako tvrdit, že neexistuje. AI nástroje opravdu zrychlují určitý typ práce: greenfield CRUD endpoint, boilerplate React komponentu, regex, který si napůl pamatujete, kostru testu pro funkci, jejíž chování je očividné. Přesně na tohle používáme Claude Code interně a vyplácí se. Problém je, že tady senioři netráví čas. Hodiny jdou do neznámých codebase, kde model sebevědomě navrhne přístup, který porušuje invariant, jejž nikdo nezdokumentoval. Jdou do refactoringů napříč systémem, kde přejmenování konceptu znamená pochopit sedmnáct call sites, načež AI vesele upraví dvanáct z nich a tiše vynechá pět, které používaly reflexi nebo string-based dispatch. A jdou do debuggingu nedeterministických selhání, kde se bug projeví jen pod zátěží a model pořád navrhuje věrohodně znějící opravy, které řeší symptom, jejž jste popsali, místo race condition, kterou jste ještě nenašli. V každém z těchto případů AI generuje výstup rychle, výstup vypadá správně, a tak strávíte čas tím, že věrohodný kód reviewujete a opravujete, místo abyste psali správný kód z mentálního modelu, který už máte v hlavě. Čím hlubší máte existující porozumění systému, tím víc se návrhy AI mění v daň, protože si návrh musíte nahrát do hlavy, porovnat ho s vlastním modelem, najít, kde je nenápadně špatně, a vrátit ho zpátky. Tahle review smyčka je pomalejší než to prostě napsat, a čím jste seniornější, tím horší ten poměr je.

Rozdíl ve vnímání není zvláštnost konkrétních účastníků, vyplývá přímo z toho, jak tyhle modely fungují. LLM je trénovaný produkovat nejvěrohodnější pokračování a věrohodný kód je z definice kód, který vypadá jako správný kód. To znamená, že failure mode nikdy není syntaktická chyba, kterou odhalíte za dvě vteřiny. Je to sebevědomě strukturovaná funkce, která se zkompiluje, čte se čistě, projde happy path a je špatně způsobem, který se ukáže až za tři týdny v produkci. Model nikdy neřekne, že si není jistý hranicí databázové transakce. Vygeneruje tu hranici se stejnou plynulou autoritou, s jakou vygeneruje print. Váš mozek mezitím běží na heuristice, která lidem sloužila sto tisíc let: plynulý, sebevědomý, dobře strukturovaný výstup koreluje s kompetencí. Přečtete si vygenerovaný kód, parsuje se hladce, odpovídá tvaru kódu, který jste viděli fungovat, a mozek to zařadí pod hotovo. Čtení dobře vypadajícího kódu působí jako pokrok způsobem, jakým zírání do prázdného souboru a usilovné přemýšlení nepůsobí, i když zírání a přemýšlení vyprodukuje správnou práci rychleji. To je motor té iluze. Cítíte se rychlí, protože se obrazovka pořád plní rozumným textem, a náklad na ověření, jestli je ten text vlastně správně, je odložený, vytlačený ven a v tu chvíli snadno podceněný. Dopamin z přijetí přijde okamžitě, náklad za nenápadný bug přijde později a připíše se na vrub něčemu jinému.

Pokud jste CTO a schvalujete výdaje na AI per seat, přestaňte spoléhat na dotazníky spokojenosti vývojářů jako na hlavní signál. METR vám právě ukázal, že tenhle signál je vedle o 39 bodů a vaši inženýři vám budou hlásit, že lítají, přesně do okamžiku, než data o cycle time řeknou opak. Měřte radši ty nudné věci. Sledujte cycle time od prvního commitu po merged PR, pokud umíte úkoly otagovat, tak v rozpadu podle typu, a porovnejte skupinu používající nástroje proti té, která je nepoužívá, na srovnatelné práci, aspoň po čtvrtletí, protože dva týdny líbánkových dat vám neřeknou nic. Hlídejte rework rate, konkrétně počet PR, které se do sedmi dnů od merge revertnou nebo hotfixnou, protože tam se ukáže odložený náklad za věrohodný, ale špatný kód. Dívejte se na čas review na jeden PR, protože opravdová výhra v produktivitě by neměla potichu přesouvat hodiny z autora na recenzenta. Všímejte si, kde se výhry koncentrují. Na našich vlastních projektech je poctivá odpověď taková, že AI nástroje jsou jasná výhra pro junior až mid práci, jako je scaffolding, generování testů a zkoumání neznámého API. A jsou nula od nuly nebo přímo ztráta na seniorní práci typu refactoring platebního pipeline nebo honění občasného selhání v distribuované frontě jobů. Z toho plyne, že správná politika nejspíš není plošné nasazení ani plošný zákaz. Je to párování nástroje s úkolem a nemilosrdná upřímnost ohledně toho, do které škatulky daný kus práce spadá. Týmy, které s těmihle nástroji vyhrávají, jsou ty, co měřily, ne ty, co jely na pocit.

Nic z tohohle neznamená, že jsou AI nástroje na kódování podvod, a chci být přesný, protože debata pořád sklouzává buď k evangelizaci, nebo k zavrhování. Nástroje jsou reálné, jsou užitečné a zlepšují se dost rychle na to, aby si výsledek studie z roku 2025 zasloužil zopakovat každého půl roku. Co práce METR usazuje, je užší a trvanlivější než ten titulek: vaše vnímání vlastní produktivity s AI je nespolehlivé, předvídatelně nespolehlivé, a vychýlené směrem k optimismu. Berte to tak, jak byste brali jakýkoli špatně nakalibrovaný přístroj. Nevyhodíte ho, ale korigujete jeho odchylku a křížově ho ověřujete proti měření, kterému věříte. Pro nás ve steezru to znamená záměrně rozlišovat, kdy sáhneme po Claude Code a kdy lidem řekneme, ať zavřou záložku a přemýšlí. A znamená to brát jakékoli tvrzení o revoluci v produktivitě, naše vlastní nevyjímaje, jako hypotézu k otestování proti merge metrikám, ne jako závěr. Senioři, kteří z těchhle nástrojů vytěží nejvíc, nejsou ti, co je používají nejvíc. Jsou to ti, kteří si vypěstovali ostrý instinkt pro přesný okamžik, kdy je AI přestane zrychlovat a začne je potichu zdaňovat, a kteří mají disciplínu v tu chvíli přestat. Tenhle instinkt se buduje těžko právě proto, že vám zpětnovazební signál lže, což je celý problém shrnutý do jedné věty.