Az MI-kódügynök 30%-kal több kódot ír, a kész munka mégsem nő

Az Ars Technica 2026. október 9-i beszámolója szerint az MI-kódügynökök vállalati bevezetése után az aktív dolgozóra jutó kódsorok száma átlagosan 30%-kal, a commitoké 20%-kal, a pull requesteké 23%-kal nőtt, a lezárt fejlesztési feladatoknál viszont nem mutatkozott statisztikailag szignifikáns növekedés. A több megírt és felülvizsgálatra benyújtott kód tehát a vizsgált vállalatoknál nem jelentett kimutathatóan több befejezett szoftvermunkát. A növekmény vállalati szintű becslés: nem kizárólag az ügynökök által közvetlenül megírt sorokat számolja.

Fiona Chen és James Stratton 2026. augusztus 4-i tanulmánya a Jellyfish adataiból 718 vállalat mintegy 300 millió munkaeseményét elemezte, a 2021 januárjától 2026 márciusáig tartó időszakból; egy megkérdezett fiatal szoftvermérnök így írta le a folyamatot: „code review was still the bottleneck”. Az adatok a kódváltoztatásokat, a felülvizsgálati folyamatot és a feladatkezelő rendszerekben lezárt munkát is követik. Ez teszi lehetővé, hogy a kódírás gyorsulását a fejlesztési folyamat későbbi állomásaival vessék össze.

A kódtevékenység nőtt, a lezárt munka nem követi

A három emelkedő mutató a fejlesztés különböző korai állomásait írja le. A kódsor a változtatás terjedelmét, a commit egy rögzített módosítást, a pull request pedig egy felülvizsgálatra benyújtott munkacsomagot jelez. Egyik sem mondja meg önmagában, hogy a módosítást elfogadták-e, élesítették-e, vagy elkészült-e az a funkció, amelyhez tartozik. Ezért félrevezető a commitok vagy a benyújtott változtatások számát közvetlenül leszállított szoftverként kezelni.

Aktivitás–eredmény mérőlap: a kódsorok, commitok és pull requestek oldalán egyértelmű emelkedés látszik; a lezárt Jira-feladatok és a nagyobb munkákat összefogó epicek oldalán nincs megbízhatóan kimutatható emelkedés. A feladat egy körülhatárolt fejlesztési munka, például hibajavítás vagy egy funkció része; az epic több kapcsolódó feladatot fog össze. A tanulmány ezeket a lezárásokat használja a szoftveres eredmény mérésére, mert a feladat állapota a megírás és ellenőrzés után is követhető. A pull request összevonása és a feladat lezárása külön esemény: az összevont kód még nem feltétlenül került éles környezetbe.

Felmerülhet, hogy ugyanannyi lezárt feladat mögött több vagy nehezebb munka van. Az elemzés ezért a feladatok becsült méretét és összetételét is megvizsgálta, de ezekben nem talált olyan elmozdulást, amely elfedné a nagyobb kibocsátást. A lezárt feladatokra adott becslés enyhén pozitív, ám statisztikailag nem különíthető el megbízhatóan a változatlanságtól. Ez pontosabb állítás annál, hogy minden csapat ugyanannyi szoftvert készített: az összesített adatokból a kódtermeléshez mérhető növekedés nem igazolható.

A felülvizsgálatnál torlódik fel a változtatás

A pull requestek útja megmutatja, hol veszhet el a kódírásnál nyert idő. A TechRadar 2026. október 12-i ismertetése szerint az ügynökök bevezetése után a pull request benyújtásától az összevonásáig tartó idő 49%-kal, a felülvizsgálói hozzászólások száma pull requestenként 35%-kal nőtt; a kódfelülvizsgálatban részt vevő dolgozók aránya 14%-kal emelkedett. Gyakoribbá vált az is, hogy a felülvizsgálók módosítást kértek. Vagyis a csapatok több változtatást küldtek ellenőrzésre, miközben egy változtatás végigvezetése hosszabbá és munkaigényesebbé vált.

A felülvizsgálat során a csapattársak azt nézik meg, hogy a változtatás teljesíti-e a követelményt, illeszkedik-e a meglévő kódhoz, és szükség van-e javításra vagy további tesztre. Ha a benyújtott munka gyorsabban érkezik, mint ahogyan ezeket a döntéseket meg lehet hozni, a várakozás a folyamat későbbi szakaszában jelenik meg. A hosszabb átfutásból azonban önmagában nem következik, hogy minden ügynökkel készült változtatás hibásabb: a több benyújtott munka és a felülvizsgálat változó követelményei is növelhetik a terhelést.

A különbség a fejlesztői teljesítmény értelmezését is megváltoztatja. A kódírás gyorsulása valós folyamatváltozás, de az ellenőrzésre fordított idővel együtt érdemes nézni. Ha a pull requestek száma nő, a lezárt feladatoké pedig nem, akkor a nagyobb aktivitás nem igazolja a nagyobb szállítási kapacitást. Az elemzésben éppen ez a kétféle jelzés válik szét: a fejlesztési folyamat elején több munka látható, a végén nem mérhető vele arányos többlet.

A lezárt feladat közelebb van az eredményhez, mint a kódsor

A Jira-feladat lezárása erősebb mérce a leszállított munkára, mert a kutatás által leírt folyamatban a kód megírását, ellenőrzését és élesítését követi. Az epic lezárása még tágabb egységet, összetartozó feladatokból álló funkciót vagy projektet jelöl. Ezek a mutatók ezért választ adnak arra, hogy a gyorsabb kódtermelés mellett több befejezett fejlesztési munka jelent-e meg. Az üzleti eredményt ugyanakkor nem mérik közvetlenül: az ügyfelek tényleges használata, elégedettsége és a bevétel más adatokból lenne megállapítható.

A vizsgálat a vállalati bevezetés hatását becsli, nem egyetlen fejlesztő ügynökkel végzett munkáját hasonlítja a saját korábbi munkájához. Ez a különbség lényeges: egy eszköz gyorsíthatja egy feladat megírását, miközben a csapat teljes munkafolyamatában az ellenőrzés vagy az élesítés szabja meg az áteresztőképességet. A vállalati átlag magában foglalja azt is, hogy a munkatársak eltérő mértékben használják az új eszközt. Egy erős egyéni gyorsulás ezért nem fordítható át automatikusan ugyanakkora vállalati eredményre.

A megfigyeléses adatok határa

Az elemzés eltérő időpontban bevezető vállalatok korábbi és későbbi adatait veti össze. Az oksági becslés azon a feltételezésen nyugszik, hogy bevezetés nélkül a vállalatok eredményei hasonló pályát követtek volna; a megfigyeléses adatok nem zárhatnak ki minden egyidejű szervezeti változást. A minta olyan Jellyfish-ügyfelekből áll, amelyek hozzájárultak adataik kutatási felhasználásához, ezért az eredmény nem ír le automatikusan minden fejlesztőcsapatot. A közölt időszak a márciusi adatlezárásnál ér véget, így az újabb eszközváltozatok és a később átalakuló munkafolyamatok hatása külön vizsgálatot igényel.

A fejlesztési vezető számára a közvetlen következmény a mérési határ: a kódmennyiség és a benyújtott változtatások a folyamat terhelését mutatják, a felülvizsgálati idő és a lezárt feladatok pedig azt, hogy ebből mennyi jutott tovább. A vállalati adatokban a két oldal eltérően mozdult el. A következő érdemi kérdés az, hogy a felülvizsgálati kapacitás vagy a munkaszervezés változása mellett a későbbi adatokban megjelenik-e több lezárt, használatba vett funkció.

Olvassa el ezt is:

• OBS vagy Streamlabs: az egyszerűbb adás akár 28%-kal több CPU-t kérhet
• ChatGPT vagy Gemini Deep Research: a több forrás nem mindig jobb
• Wix vagy Squarespace: a nagyobb szabadság több döntést is kér