Průměrný pull request čekal ve firmách před nasazením AI agentů na schválení zhruba sedm dní. Potom deset a půl. Kódu přitom přibylo, a ne málo. Jenže z fronty na kontrolu ho na druhé straně vypadlo zhruba stejně jako dřív.
Tohle je jádro pracovní studie ekonomů Fiony Chen a Jamese Strattona z Harvardu, na kterou minulý týden upozornil web Ars Technica. Autoři se dostali k datům analytické platformy Jellyfish, kterou firmy používají ke sledování práce vývojářských týmů. Vzorek je na poměry podobných studií obří: 718 firem, přes 725 tisíc lidí a zhruba 300 milionů pracovních událostí od ledna 2021 do března 2026. Commity z GitHubu, tikety z Jiry, schůzky z kalendáře.
Otázka zněla jednoduše. Když AI zrychlí psaní kódu, dodá firma víc softwaru? Podle dat ne.
Kód roste, tikety stojí
Autoři rozlišují dvě generace nástrojů. Asistenti typu GitHub Copilot nebo Cursor doplňují kód pod rukama vývojáře. Agenti jako Claude Code, Devin nebo agentní režim Cursoru dostanou zadání a sami napíšou kód napříč soubory, spustí testy a opravují chyby.
U asistentů je efekt skromný. Řádků kódu přibylo o 12 %, commitů o 9 % a pull requestů o 5 %, přičemž statisticky průkazný je jen nárůst commitů. Agenti jsou jiná liga: o 30 % víc řádků, o 20 % víc commitů a o 23 % víc pull requestů na pracovníka a měsíc. Všechna tři čísla jsou průkazná.
Pak přichází studená sprcha. Výstup firmy autoři měří počtem vyřešených tiketů v Jiře, tedy úkolů, jejichž kód doputoval až do produkce, a počtem dokončených epiků. Ani u asistentů, ani u agentů se nárůst neprokázal. U agentů statistika vylučuje, že by výstup vzrostl o víc než 12 %. Proti třicetiprocentnímu nárůstu kódu je to málo.
Autoři si ohlídali i nejbližší námitku: co když firmy s AI jen berou větší úkoly, takže tiketů je stejně, ale každý obsahuje víc práce? Velikost úloh odhadli jazykovým modelem i z doby řešení. Skladba práce se nezměnila.
Neprokázal se ani dopad na zaměstnanost. U celkového počtu lidí ve firmě studie vylučuje pokles o víc než 2,9 %, u inženýrů, kde jsou data hlučnější, o víc než 13,8 %. Rozdíl mezi juniory a seniory také nenašla. Masové propouštění kvůli agentům tedy v těchto firmách zatím neproběhlo.
Kam se ten kód ztratil
Psaní kódu je jen jeden krok výroby softwaru. Před ním je plánování, za ním review, testy a nasazení. Podle dat z Jellyfish tráví inženýr psaním kódu asi 42 % času, podle doplňkového průzkumu mezi stovkou vývojářů na platformě Prolific dokonce jen 31 %. Když zrychlíte menší část řetězu, zbytek zůstane stejně pomalý.
Po nasazení agentů se z review stalo úzké hrdlo:
| Ukazatel (agenti) | Před | Změna |
|---|---|---|
| Doba od otevření po merge pull requestu | 7,0 dne | +49 % |
| Podíl PR, u kterých reviewer požádal o změny | 13 % | téměř dvojnásobek |
| Komentáře na jeden PR | 1,66 | +35 % |
| Podíl lidí, kteří dělají review | 29 % | +14 % |
Zajímavé je, že pull requesty nezvětšily. Počet přidaných řádků na jeden PR zůstal stejný. Reviewer tedy nedostává delší diffy, dostává jich víc a častěji je vrací. U asistentů se nic z toho neprojevilo.
Jeden z juniorních vývojářů, se kterými autoři mluvili, popisuje projekt, kde směl změny schvalovat jediný senior, protože kódu rozuměl nejlíp. Na revizi se dostal jednou týdně. Po několika výpadcích, které způsobily commity od AI, firma navíc zavedla pravidlo, že kód od AI musí podepsat senior. Fronta se tím jen prodloužila.
AI na review to zatím nevyřešila
Logická odpověď zní: nasaďte AI i na kontrolu. Firmy to dělají. Do března 2026 použilo nějaký nástroj na AI code review skoro 80 % firem ve vzorku. Jenže od AI pochází jen 23,3 % všech komentářů v review a aspoň jeden AI komentář dostalo jen 10,8 % pull requestů. Schvalují pořád lidé a úzké místo podle studie trvá i po nasazení těchto nástrojů.
Autoři to vysvětlují modelem se dvěma kanály. Agent zvedá produktivitu, takže do review teče víc kódu. Současně mění jeho kvalitu, takže každý kus vyžaduje víc kontroly. První kanál se dá řešit přesunem lidí k review. Druhý ne, ten musí opravit samotná technologie. To, že roste podíl vracených PR i počet komentářů, ukazuje podle autorů právě na druhý kanál.
Pokud vám to připomíná náš text o tom, že AI kód je čtyři roky stejně děravý a mění se jen jeho objem, není to náhoda. Tady je k tomu účet za práci lidí.
Co brát s rezervou
Studie je pracovní verze, autoři ji používají jako svou hlavní práci na akademickém pracovním trhu. První verze vyšla v lednu, aktuální je ze 4. srpna 2026 a recenzním řízením v odborném časopise zatím neprošla.
Firmy nezaváděly AI náhodně. Větší společnosti sahaly po agentech dřív a autoři sami píšou, že případné zkreslení by spíš nadsazovalo přínosy AI, ne je podhodnocovalo. Měření adopce je navíc neúplné, protože soukromé licence jednotlivých vývojářů v datech nejsou.
Důležitý je i rozdíl mezi firmou a člověkem. Agenty sice do ledna 2026 zavedlo přes 95 % firem ve vzorku, ale u typické firmy je po roce reálně používalo jen asi 20 % inženýrů. Data končí v březnu 2026, takže letošní generace agentů v nich chybí. A nulový efekt na zaměstnanost platí pro jednotlivé firmy v krátkém období. Co se děje v celém odvětví, studie neměří.
Jiné práce přitom docházejí k odlišným závěrům, některé třeba našly úbytek nástupních pozic. Nejblíž má k této studii práce Demirera, Musolffa a Yanga z letošního roku, podle které Copilot v open source projektech zvedá počet řádků a commitů, ale na pull requesty a vydané verze má mnohem menší vliv.
Metrika, která lže
Pro vedoucí týmů z toho plyne nepříjemná, ale praktická věc. Počet řádků nebo commitů po nasazení AI roste, a přesto to o výsledku skoro nic neříká. Kdo měří úspěch agentů podle objemu kódu, měří vstup do fronty, ne to, co z ní vyleze.
Firmy ve studii na to už reagují samy a posílají k review víc lidí, aniž by ubraly těm, kdo píšou. Pokud nevylepšíte druhou polovinu řetězu, agent vám hlavně prodlouží frontu na schválení.
Zdroje
- Fiona Chen, James Stratton: Artificial Intelligence in the Firm: Bottlenecks in Software Production, Harvard University, pracovní verze ze 4. 8. 2026 – fion.ac/jellyfish.pdf
- Ars Technica: AI coding agents generate more code, but not more software, říjen 2026
