Používáš AI při programování. Tvoje IDE generuje funkce, tvůj agent píše testy, code review běží napůl automaticky. Řádky kódu přibývají rychleji než kdy dřív. A přesto máš pocit, že pracuješ víc, ne míň.
Nejsi v tom sám — a není to jen pocit. Dvě nejvýznamnější studie z roku 2026 ukazují, že měření reálného přínosu AI k produktivitě je dnes jeden z největších slepých bodů celého odvětví. Pojďme si ukázat, co data říkají a jak změřit AI produktivitu u svého týmu tak, abys neřídil podle rozbitných čísel.
Paradox: AI všude, měření nikde
Podle Stack Overflow a Index.dev z roku 2025 používá AI nástroje 84 % vývojářů a až 46 % veškerého kódu je dnes generováno strojem. Podle SemiAnalysis tvoří Claude Code samotný zhruba 4 % všech commitů na GitHubu. AI je všudypřítomná.
Ale když se zeptáš "o kolik jsem díky tomu rychlejší?", dostaneš buď mlčení, nebo optimismus, který se s datem neshoduje.
METR, nezávislá organizace měřící schopnosti AI systémů, zveřejnila v únoru 2026 aktualizaci své kontroverzní studie. Její původní data z jara 2025 ukázala, že AI nástroje u zkušených open-source vývojářů způsobily 19% zpomalení (interval spolehlivosti +2 % až +39 % déle). Ano, přečteno správně: vývojáři s AI byli pomalejší než bez ní.
V druhé vlně studie (srpen 2025 — leden 2026) se obraz trochu zlepšil — odhadovaný dopad se pohyboval od -4 % do -18 % (tedy drobné zrychlení), ale autoři studie sami varují, že čísla jsou kvůli selekčnímu zkreslení nevěrohodná. Problém? Vývojáři, kteří na AI nejvíc spoléhají, jednoduše odmítají pracovat bez ní, takže se na studii vůbec nedostanou.
"Oželivím tolik úkolů, které AI zvládne za dvě hodiny a já bych je dělal dvacet. Bylo by mi zle, kdyby takový úkol byl vylosován jako AI-zakázaný." — účastník studie METR
To je paradox měření 2026: ti, kdo těží nejvíc, jsou zároveň ti, které nejsme schopni změřit.
Neviditelná práce, která ti sežírá den
Druhá klíčová studie — 2026 State of Engineering Excellence od Harnessu, probíhající na 700 inženýrech a manažerech v USA, UK, Francii, Německu a Indii — popisuje jev, který nazývají "produktivním offsetem". Ukazuje se, že AI urychluje hrubou tvorbu kódu, ale současně generuje masivní množství práce, kterou tradiční metriky vůbec nezachytí.
31 % dne průměrného vývojáře je dnes spotřebováno tzv. neviditelnou prací spojenou s AI. To zahrnuje hlubší kontrolu kvality kódu, odpovědnost za následné efekty cizího kódu a složité úsudky o tom, kdy AI věřit a kdy ji přepsat vlastní rukou.
Největší zdroje této tření, jak je sami vývojáři jmenují:
- Review AI kódu na přesnost — 53 % respondentů
- Oprava drobných, záludných chyb — 52 %
- Vysvětlování AI kódu kolegům — 48 %
A tady narážíme na hlavní problém: pouze 38 % organizací vůbec měří čas, který tým stráví review AI generovaného kódu. Přesně ta práce, která žere nejvíc času, je neviditelná pro všechna standardní dashboardy.
Proť tvoje staré metriky lžou
DORA metriky, cycle time, lead time, počet PR týdně — to vše bylo navrženo pro svět, kde člověk psal kód a stroj jen nasazoval. V tomhle světě platilo jednoduché pravidlo: méně času na úkol znamená vyšší produktivitu.
AI tento předpoklad rozbila.
Když Claude Code vygeneruje 300 řádků za minutu, tvůj cycle time padá skvěle. Ale pokud strávíš další hodinu review, opravou dvou tichých chyb a vysvětlováním logiky kolegovi na Slacku, skutečná cena toho úkolu se zdvojnásobila — a nikdo to v Jira tickitu nevidí. Osm z deseti engineering leaderů (81 %) v Harness studii přiznává, že doba code review prudce vzrostla od zavedení AI. Přesto se tato hodnota standardně neměří.
Klasické metriky měří objem výstupu, ne hodnotu doručenou týmu. A v roce 2026, kdy generování výstupu je levné, ale validace je drahá, to vede k systematickému zkreslení.
Jak to změřit pořádně: pět kroků
Na základě dat z obou studií a zkušeností týmů, které to dělají dobře, tady je konkrétní postup, jak si postavit vlastní měření AI produktivity.
1. Měř neviditelnou validaci
Přestaň sledovat jen to, kolik PR projde. Začni měřit, kolik času stojí review a debug po AI. Nejjednodušší způsob: přidej do Jiry nebo Linear pole AI review time a AI bug fix time pro každý PR, který obsahuje AI generovaný kód. Za měsíc uvidíš reálný podíl neviditelné práce u svého týmu — a on bude vyšší, než čekáš.
2. Sleduj ship rate, ne code volume
Rozděl metriky na dvě kategorie: generované (kolik kódu vzniklo) a doručené (kolik funkcí reálně došlo do produkce a nevrátilo se jako bug). Prioritou je druhé číslo. Pokud AI generuje 2× víc kódu, ale ship rate hodnoty roste jen o 20 %, tvoje ROI z AI je poloviční, než sis myslel.
3. Audituj, jestli tvoje metriky vůbec dávají smysl
Harnessův report uvádí děsivé číslo: 94 % týmů souhlasí, že tech debt, validační čas a vyhoření v jejich metrikách chybí. Pokud tvůj dashboard ukazuje "vše zelené", zatímco tým je vyčerpaný review maratonem, je to signál, že měříš špatnou věc. Vysoká důvěra v neúplné metriky je podle studie rizikový signál, utěšující indikátor.
4. Počítej s nárůstem governance
Jak se AI škáluje, roste potřeba security review, compliance kontrol a architektonických rozhodnutí. To je práce, kterou AI neudělá za tebe — naopak ji často vytvoří (generovaný kód s nejasnou licencí, API klíče v promptech). Předpokládej, že governance bude růst lineárně s objemem AI kódu, a alokuj na ni kapacitu předem.
5. Vytvoř důvěru, ne dohled
Asi nejdůležitější bod a zároveň ten nejvíc přehlížený: 54 % vývojářů se obává, že se data o AI produktivitě použijí proti nim při hodnocení výkonu. Pokud tým cítí, že je měřen proto, aby byl trestán nebo optimalizován, začne data zkreslovat — přesně jak viděl METR ve své studii. Lidé přestanou reportovat úkoly, začnou selektivně vybírat, co změřit. Definuj jasné mantinely: měření je pro rozhodování o nástrojích a procesech, ne pro individuální hodnocení.
Konkrétní mini-framework, který zavedeš za odpoledne
Pokud nechceš stavět složitý systém, udělej toto:
- Dva týdny měř na dvou trackech. U každého PR zaznamenej celkový čas od začátku do merge a vedle toho počet minut, které jsi strávil(a) validací AI generovaných částí. Zjistíš poměr, např. 60 % úkolu je "psaní" a 40 % je "kontrola".
- Vynásob tenhle poměr svým odhadem AI podílu v kódu. Pokud AI píše 50 % kódu a kontrola stojí 40 % času, reálná "skrytá daň" AI je zhruba 20 % tvého pracovního dne.
- Porovnej se ship rate. Pokud se hodnota doručená týmu nezvyšuje aspoň o těch 20 %, AI ti v současné podobě reálnou produktivitu nezvyšuje — jen se přesouváš z psaní na review.
Tenhle framework nezachytí všechno. Nezmerí kvalitu, kreativitu nebo to, že se naučíš nové věci z AI návrhů. Ale dá ti první reálné číslo, se kterým můžeš dál pracovat.
Shrnutí
AI nástroje v roce 2026 rozhodně nejsou naděné. METR sám věří, že reálné zrychlení vývojářů existuje a pravděpodobně roste — prostě ho těžko dokážeme, protože ti, kdo na AI spoléhají, se studiami odmítají spolupracovat.
Ale mezi "něco to urychluje" a "víme, co to urychluje a za kolik" je propast. Většina týmů dnes stojí na té straně, kde jen tuší. A právě "neviditelná práce" — review, debug, vysvětlování — je to, co rozhoduje o tom, jestli je AI investice, nebo daň.
Pokud chceš vědět, na čem jsi, přestaň koukat na řádky kódu. Začni měřit tu část dne, kterou nikdo nechce měřit. Až zjistíš, že je to třetina tvého času, budeš vědět, kde hledat reálné zrychlení.
