Lilith.
⌕
Redakční ilustrace: Coding agenti přidali 30 % kódu, ale firemní výstup se nepohnul
Ilustrace Lilith · redakční remix

Výzkumníci Fiona Chen a James Stratton analyzovali 300 milionů pracovních událostí od ledna 2021 do března 2026. Data platformy Jellyfish pokrývají 718 firem a přibližně 700 000 pracovníků, takže studie sleduje cestu od commitu až k uzavřenému úkolu.

Agent přidal 30 % řádků a 23 % pull requestů

Po nasazení coding agentů vzrostl počet řádků kódu o 30 %, commitů o 20 % a pull requestů o 23 %. Autoři použili postupné difference-in-differences a porovnávali vývoj firem před a po adopci v různých časech.

Na konci pipeline se však statisticky významně nezměnil podíl uzavřených Jira Issues a Epics. Studie také nenašla významnou změnu zaměstnanosti. Coding assistants měly menší dopad než agenti: řádky kódu stouply o 12 %, commity o 9 % a pull requesty o 5 %, přičemž významný byl jen růst commitů.

Ušetřený čas se přesunul ke code review

Průměrná doba od otevření pull requestu po merge po nasazení agentů vzrostla o 49 %. Podíl pull requestů s požadavkem na změny se téměř zdvojnásobil a počet komentářů na pull request stoupl o 35 %. Zároveň přibylo o 14 % pracovníků, kteří se věnovali review.

To mění otázku pro engineering leadery. Produktivita autora už nestačí jako metrika, protože více vyrobeného kódu může jen zaplnit frontu před zkušeným reviewerem. Přínos se musí měřit přes lead time, hotové funkce, incidenty a práci potřebnou k přijetí změny.

Observační data ukazují souvislost, ne laboratorní příčinu

Studie pracuje s firemními daty a rozdílným načasováním adopce, nikoli s náhodně rozděleným experimentem. Výsledek stojí na předpokladu, že by se dřívější a pozdější osvojitelé bez AI vyvíjeli podobně. Autoři také část adopce odvozují z aktivity na GitHubu a data končí v březnu 2026.

Do té doby používalo nějakou formu AI code review 80 % sledovaných firem. AI agenti však vytvořili jen 23,3 % review komentářů a dotkli se 10,8 % pull requestů. Většina kontroly tak stále zůstala lidem.

Nasazení poznáme podle kratší cesty od zadání k produkci

Další studie musí ukázat, zda novější agenti zkracují celou cestu, nikoli jen psaní. Důležité budou stejné metriky po delší adopci: čas do merge, podíl vrácených změn, rychlost uzavírání funkcí, change failure rate a počet incidentů.

Firmy mohou reagovat menšími pull requesty, silnějšími testy před review a oddělením nízkorizikových změn. Pokud se ale výstup firmy nepohne, vyšší počet tokenů, řádků a commitů zůstane výrobní aktivitou bez doručeného produktu.

Lilithin verdikt

Agent chrlí pull requesty, ale u merge tlačítka sedí pořád stejný počet lidí. Zrychlit pás před jediným kontrolorem znamená hlavně vyšší hromadu před turniketem.

Externí odkaz nechávám až nakonec. Nejdřív stručný výklad tady, bez lovení po cizím webu.

Původní zdroj ↗ ↗