Vydáno 28. října 2026 · 5 min čtení
Agenti píšou o 30 % víc kódu. Hotové práce nepřibylo
Před dvěma dny jsme tady psali, že doporučení pustit agenta do CI jako kontrolu je sice konzistentní, ale měřená data k němu nejsou. Data teď jsou — jen měří něco jiného, než co doporučujeme. Měří přesně ten problém, kvůli kterému to doporučujeme.
- Ve zkratce
- U firem, které nasadily AI agenty, vzrostl objem kódu o 30 %, commity o 20 % a pull requesty o 23 %. Počet dokončených úkolů v Jiře se měřitelně nezvýšil; interval spolehlivosti vylučuje nárůst větší než 12 %.
- Čas od odeslání pull requestu k jeho zamergování se prodloužil o 49 %, komentářů na pull request přibylo o 35 % a podíl pull requestů vrácených k úpravě se skoro zdvojnásobil.
- U našeptávačů typu Copilot byly efekty výrazně menší a většinou statisticky nevýznamné. Rozdíl mezi „agent“ a „našeptávač“ je v těchhle číslech zásadní a v novinových titulcích obvykle mizí.
Co se měřilo
Fiona Chen a James Stratton z Harvardu zpracovali data z analytické platformy pro vývojářské týmy: zhruba 300 milionů pracovních událostí přibližně 700 tisíc lidí ve 718 firmách, od ledna 2021 do března 2026. Jsou v tom data z GitHubu, z Jiry i z kalendářů.
Metoda je rozdílová analýza, která využívá toho, že firmy nasazovaly nástroje v různou dobu. Porovnává se tedy stejná firma před a po, proti firmám, které v té době nenasadily nic.
Studie důsledně odděluje dvě věci, které se v běžné debatě slévají dohromady: našeptávače (Copilot a spol., které doplňují kód během psaní) a agenty (které dostanou zadání a samy otevřou pull request). Čísla níž se liší podle toho, o co jde.
Kódu přibylo
| Měřítko | Agenti | Našeptávače |
|---|---|---|
| Řádky kódu | +30 % | +12 % |
| Commity | +20 % | +9 % |
| Pull requesty | +23 % | +5 % |
U agentů jsou všechny tři nárůsty statisticky významné. U našeptávačů je významný jen ten prostřední, zbytek se od nuly spolehlivě odlišit nedá.
Tohle je ta část, která se cituje. Teď ta druhá.
Hotové práce nepřibylo
Jako výstup, tedy jako hotovou práci, studie bere vyřešené úkoly v Jiře a nad nimi epiky, tedy celé funkce a projekty. Ani u jednoho nenašla významný efekt — u agentů ani u našeptávačů.
To samo o sobě ještě nic neznamená, protože „nenašli jsme efekt“ může znamenat i „měření bylo moc hrubé“. Autoři proto uvádějí, co jejich data vylučují: u agentů interval spolehlivosti vylučuje nárůst výstupu větší než 12 % oproti výchozímu stavu. Tedy i kdyby nějaký efekt byl, je výrazně menší než těch 30 % u objemu kódu.
Napadne vás, že se možná změnilo složení úkolů — že lidé začali řešit větší věci a počet úkolů to neukáže. Autoři to testovali dvěma měřítky velikosti úkolů a nevyšlo to.
Kam se úzké místo přesunulo
Tahle část je pro nás nejzajímavější, protože nepopisuje jen „nic se nezlepšilo“, ale ukazuje kam ta práce zmizela.
- Čas od pull requestu k merge: +49 %. Z výchozích 7,03 dne přibylo 3,45 dne. U našeptávačů se nezměnil nic.
- Vrácení k úpravě: skoro dvojnásobek. Podíl pull requestů, u kterých si revize vyžádala změny, vyskočil z výchozích 0,13 na zhruba dvojnásobek.
- Komentáře na pull request: +35 %. Z 1,66 na průměrný pull request přibylo 0,58 komentáře.
- Lidé v roli recenzenta: +14 %. Firmy přesunuly část lidí od psaní k revizi.
Dohromady to dává obrázek, který zná každý, kdo někdy revidoval cizí kód ve spěchu: psaní se zrychlilo, kontrola ne, a mezi tím se tvoří fronta.
Zrychlit jeden krok výrobního řetězce zvýší výstup jen tehdy, když ten krok byl úzké místo. Jinak se fronta jen přesune o krok dál.
Co z toho plyne pro nás
Buďme přesní, protože je snadné si tuhle studii přečíst jako potvrzení něčeho, co neříká.
Neměřila kontrolní bránu. Měřila agenty, kteří píšou kód, a to, co se po nich děje v revizi. Agenta, který nic nepíše a jen hlídá diff, nikdo v téhle studii nesledoval. Co jsme psali v předchozím článku, tedy pořád platí: pro tu konkrétní roli měřená data nemáme.
Čím ta studie je, je změření problému, kvůli kterému tu roli doporučujeme. Když je úzké místo revize, je zvláštní nápad začít tím, že do ní pošlete víc materiálu. Rozumnější je začít na opačném konci.
Druhá věc, kterou si z toho bereme: jestli se někde dá ukázat návratnost agentů, je to tady. Zkrácení revize o jeden den u týmu, který merguje padesát pull requestů měsíčně, je spočitatelná úspora. Zrychlení psaní o 30 % spočitatelná úspora není, pokud se hotová práce nezmění.
Čím je studie omezená
Pár věcí je potřeba říct nahlas, protože jinak by to vypadalo silněji, než to je.
- Je to pracovní paper, zatím bez recenzního řízení. Verze, ze které čteme, je ze 4. srpna 2026, první z ledna 2026.
- Nasazení se měří na úrovni firmy, ne jednotlivce. Autoři sami píšou, že to odhady spíš snižuje, protože se do průměru počítají i lidé, kteří nástroj nepoužívají.
- Výstup je měřen Jirou. Vyřešený úkol je slabá náhrada za „dodanou hodnotu“. Firma, která Jiru vede jinak, by vyšla jinak.
- Data jsou z jedné platformy a jen z firem, které souhlasily s jejich použitím k výzkumu.
Nic z toho ta čísla neruší. Znamená to jen, že se o ně dá opřít argument, ne postavit na nich jistota.
Co s tím
Jestli vám agenti píšou kód a nevidíte na konci víc hotové práce, tahle studie říká, že v tom nejste sami, a nabízí, kde hledat. Změřte si dvě čísla, která obě znáte z vlastního repozitáře: medián času od pull requestu k merge a podíl pull requestů vrácených k úpravě. Jestli obojí po nasazení agentů vyrostlo, máte stejný problém jako průměr v té studii, a řešením není další agent na psaní.
Stavíme a provozujeme vlastní systémy, takže tyhle fronty známe z obou stran. Zbytek skupiny je na independency.cz.
Zdroj
Fiona Chen, James Stratton: Artificial Intelligence in the Firm: Bottlenecks in Software Production, Harvard University, verze ze 4. 8. 2026. Čísla v článku jsme brali přímo z paperu, ne z přebírající zprávy.
Kontakt
Máte projekt? Napište nám.
Pár vět o tom, co řešíte, stačí. Ozveme se do jednoho pracovního dne s otázkami a návrhem postupu.