Számos, 2025 végén és 2026 elején megjelent kutatás ellentmondásos vagy összetett képet fest arról, hogy az AI-eszközök valóban növelik-e a szoftvermérnökök termelékenységét. Egy kontrollált kísérlet lassulást talált, miközben sok mérés és önbevallás nagy javulást mutat. A két jelenség közti ellentmondás fő oka a mérések alkalmatlansága: az AI jelentősen csökkenti a munkakezdés költségét, de a gyártásra kész szállítást akadályozó downstream folyamatokat nem gyorsítja fel automatikusan.
A legkényelmetlenebb eredmény: METR kontrollált kísérlete
A METR kutatóintézet korai, 2025-ös kontrollált kísérletében nyílt forráskódú fejlesztők bevonásával azt találták, hogy az AI-eszközöket használó mérnökök 19%-kal tovább dolgoztak, mint az AI nélkül dolgozók (konfidencia intervallum: +2%–+39%). A lassulás statisztikailag szignifikáns volt. Ugyanakkor a résztvevők saját megítélése eltérő volt: a mérnökök úgy érezték, mintegy 20%-kal gyorsabbak.
METR következő kísérletét 2025 augusztusában indították el, de 2026 februárjában közzétett posztjukban bejelentették, hogy felhagytak az eredeti kísérleti tervvel. A problémát az okozta, hogy túl sok fejlesztő csak akkor volt hajlandó részt venni, ha minden feladatnál használhat AI-t; a visszamaradt résztvevők 30%–50%-a szelektíven elkerülte azokat a feladatokat, amelyeket AI nélkül nem akart elvégezni. Így a minta torzult, és a vizsgálat elvesztette kontrollját.
A 2025 végi adatok trendjavulást mutattak: az eredeti fejlesztők egy részénél az AI hatása 18%-os gyorsulásként jelentkezett (konfidencia intervallum: -38%–+9%), az újonnan bevont fejlesztők körében pedig 4% gyorsulás (-15%–+9%). METR maga is óvatos volt ezekkel az értékekkel kapcsolatban, mert a self-selection feltehetően alulbecsülte a hatást, illetve a torzítások miatt a kontrollált mérés gyakorlatilag lehetetlenné vált. METR konklúziója: az AI-eszközök hasznosabbak lettek azóta, de a mérés nehézségei és a szelektálódás olyan mértékűek, hogy a kontrollált kísérletek fennakadásai maguk is fontos információt hordoznak.
További, késői 2025–2026-os adatok
- Anthropic: 2025 végén 132 saját mérnök megkérdezését, 53 interjút és 200 000 Claude Code-átirat elemzését végezték el. Az alkalmazottak önbevallása szerint az AI átlagosan 50%-os produktivitásnövekedést hozott; a pull requestek száma mérnökönként naponta 67%-kal nőtt. Anthropicnál a mérnökök a napi munkájuk 60%-ában használnak Claude-ot, és a rendszer egyre több feladatot végez autonóm módon.
- CircleCI: 28 millió CI-folyamat elemzése ezrek csapataiból. A workflow-throughput 59%-kal nőtt, ugyanakkor a median csapatnál a main branch throughput 7%-kal csökkent. A build-sikerarány 70,8%-ra esett, ami öt éves mélypontot jelent. Több kód jön létre, de kevesebb jut el a productionig; a CI válik szűk keresztmetszetté.
- Harvard Business School (HBS): 78 olyan dolgozót vizsgáltak, akik AI-t használtak saját szakterületükön kívüli feladatokra. Az AI egyformán segítette a brainstormingot, de a végrehajtásnál a domain-szakértőkhez képest a kevésbé jártas dolgozók 13%-kal gyengébben teljesítettek.
- METR, 2026 május: 349 technikai munkavállaló körében végzett felmérésben az önbevallott produktivitásnövekedés 1,4–2x között mozgott. Érdekesség: METR saját kutatói csoportja, amely a percepciós torzításokra korábban felhívta a figyelmet, a legalacsonyabb önbevallott növekedést jelentette.
A valós működés: mi történik a csapatban?
Gyakori jelenség: aktivitásmetrikák javulnak — több pull request, több commit, nagyobb zárási sebesség — miközben a tényleges feature-idővonalak nem rövidülnek. Az AI jelentősen lecsökkenti a munkakezdés költségét: első vázlatok, boilerplate, scaffolding, tesztek és magyarázatok létrehozása olcsóbbá vált. De a shippinget akadályozó tényezők (termékdöntések, tervezés, kódellenőrzés, QA, jogi megfelelés, infrastruktúra, kiadási folyamatok) nem gyorsultak ugyanúgy.
Ennek következménye: több félig kész munka (WIP) kerül a rendszerre, és ezek ütköznek a változatlan downstream folyamatokkal. A CircleCI adatai a 28 millió workflow-ról részben pontosan ezt a skálán jelentkező jelenséget mutatják: aktivitás nő, de a main branch-re jutás nem.
Anthropic Claude Code csoportjának mérnökigazgatója, Fiona Fung júniusi előadásában elmondta, hogy a kódírás, tesztírás és refaktorálás szinte nem lassítja már a csapatát, de a verifikáció, kódátvizsgálat és biztonság váltak szűk keresztmetszetté. Ez ugyanaz a korlát, amelyet a CircleCI adatok is mutatnak: a plafon nem az írási sebesség, hanem a szállítási folyamatok kapacitása.
Anthropic adata szerint az AI-val támogatott munkák 27%-a egyébként nem valósult volna meg. Ennek egy része hasznos: prototípusok, dokumentáció, amelyek döntéseket segítenek. Más része viszont alacsony prioritású munkák létrejötte, amelyek elfogyasztják a review ciklusokat és a CI-erőforrásokat, mert felépítésük majdnem ingyenessé vált, míg a felülvizsgálat, tesztelés és karbantartás nem.
Kompetencia–magabiztosság rés
A HBS kutatás rávilágít egy mechanizmusra: az AI csökkenti a magabiztosság különbségét újoncok és szakértők között — mindkettőjük számára hozzáférhetővé teszi a terveket és első vázlatokat —, de nem zárja be a kompetencia-különbséget. Egy backend fejlesztő AI-asszisztenciával frontend elemet készíthet, ami felületesen rendben van, viszont rejtett döntési hibákat és tesztelésre váró szélsőséges eseteket foglalhat magában.
A METR korai eredménye azt sugallja, hogy ez még tapasztalt szakemberekre is érvényes lehet: az AI nem teszi őket inkompetenssé, de arra készteti őket, hogy jobban bízzanak a kimenetben, mint amit az valójában indokol. Amikor a fejlesztők mélyen beépítik az AI-t munkafolyamataikba, elveszíthetik azt a képességüket, hogy AI nélkül is referenciaként dolgozzanak — ezt az automatizálási torzítás (automation bias) jelensége írja le.
Ez a vezetők számára különösen problémás: nem lehet javítani azon, amit nem látsz. Ha minden mérnök úgy érzi, 50%-kal produktívabb, de a kiadási határidők nem változnak, akkor van egy rejtett probléma, amelyet senki sem vesz észre.
Hogyan tehető fenntarthatóvá az AI-native fejlesztés?
- Válogatottabb, alaposabb kódátvizsgálat: az AI által generált kód felületi ellenőrzése könnyű, ezért a review-nek szkeptikusabb, „reasonable doubt” szemléletre kell épülnie. Kérdezd meg: milyen feltételezéseket tett a modell, amelyek nem látszanak a diffben? Milyen edge-case-eket nem teszteltek?
- Automatizálás és emberi ítélőképesség párosítása: automatizáld a stílust, lintelést, alapvető hibakeresést és tesztgenerálást, de a biztonsági, jogi vagy trust-boundary érintett kódot juttasd domain-szakértőhöz. A cél: az AI kezelje a felszíni helyességet, az emberek hozzák a következményeket feltáró ítéletet.
- CI átalakítása az új hibamódokhoz: az AI által generált kód másként bukik el — lokálisan lehet korrekt, de architektúra-inkonzisztens vagy integrációs hibákra hajlamos. Integrációs tesztek, contract tesztek és architektúra-fitness funkciók beépítése a pipeline-ba segít elkapni ezt korábban.
- Kiadás feature flag-ek mögött és aktív monitorozás: fogadd el, hogy nem fogsz mindent elkapni premerge; deployolj kis felhasználói részre (például 1%), figyeld az observability-t és rollback-elj gyorsan.
- Ember által írt tesztek kötelezővé tétele AI-asszisztált kódnál: különösen edge-case-ekre vonatkozó, határfeltételeket lefedő tesztek. A teszt megírása erősen visszajelzést ad a fejlesztő megértéséről.
- Tudatos tudásmegosztás védelme: Anthropic adatai szerint a mentorálás csorbát szenvedett, miközben az AI helyettesítette az emberi beszélgetéseket. ADR-ek, rendszeráttekintések és páros munkavégzés fontosak a közös tudás fenntartásához.
A mérés problémája
Ez nem azt jelenti, hogy ne használjuk az AI-t. Használjuk erőteljesen ott, ahol egyértelműen segít — unalmas, rutinszerű feladatoknál, prototípusokban és gyorsan ellenőrizhető munkában. De ha azt akarod mérni, hogy az AI valóban felgyorsítja-e a szállítást, a PR-szám és az önbevallott velocity rossz mutatók.
A kutatások azt mutatják, hogy a megszokott visszacsatolási hurkok megváltoztak. Érdemes más metrikákat fontolóra venni: ciklusidő feature-koncepciótól gyártásig, merged kódnak a productionig jutásának aránya rollback nélkül, vagy a sprint végén tervezett és tényleges scope közti eltérés. Vagy vállalati szinten: bevétel-növekedés összevetése az AI-befektetésekkel (eszközök, infrastruktúra, működési költségek).
Ezek instrumentálása nehéz. A fontos kérdés, amit fel kell tenni a csapatoknak: „Mit kellene mérnünk ahhoz, hogy valóban tudjuk?”
Megjegyzés: A cikkhez kapcsolódó kutatói munka személyes kapacitásban készült. A leírt vélemények a szerzők saját nézeteit tükrözik, nem feltétlenül egyeznek munkáltatóik álláspontjával.
