Az AI-t sok szervezet úgy használja, mint a konyhamalacot. Mindent beleöntenek. Régi specifikációt, félmondatos e-mailt, kétes minőségű kódrészletet, egymásnak ellentmondó üzleti szabályt és egy sürgető határidőt. Aztán felháborodnak, amikor a gép nem kifinomult rendszert, hanem a beledobált maradék összeturmixolt változatát adja vissza.

Ez nem elsősorban modellprobléma. Ez vezetési, tervezési és mérési probléma. Az AI ugyanis nem szünteti meg a rossz folyamatokat, hanem inkább  felerősíti őket.

A gyorsaság illúziója

A fejlesztési teljesítményt még mindig meglepően primitív módon mérik. Megnézik, hány óra alatt készült el az első változat. Megszámolják a commitokat. Nézik a pull requestek számát. Megkérdezik a fejlesztőt, gyorsabbnak érezte e magát. Aztán ebből kijön egy százalékos állítás, amelyet már lehet mutogatni a vezetőségnek és a befektetőknek.

Csakhogy egy fejlesztés nem akkor készül el, amikor a kód először lefordul. Akkor készül el, amikor a megoldás megfelel az elvárásoknak, átmegy az ellenőrzéseken, beilleszthető a rendszerbe, üzemeltethető, visszaállítható, és nem kényszerít másik csapatot arra, hogy utólag eltakarítsa a következményeket.

A gépelés sebessége nem azonos a szállítás sebességével. A szöveg vagy a kód előállításának ideje nem azonos a hasznos eredmény létrehozásának idejével. A látványos aktivitás nem azonos a termelékenységgel.

A tervezés költsége látható. A tervezés hiányának költsége szétterül a teljes szervezetben.

Ezért tud egy rosszul előkészített csapat gyorsnak látszódni. A mérés az első kódrészletnél megáll, miközben a valódi költség később jelenik meg hibajavításban, újratervezésben, biztonsági vizsgálatban, ügyfélszolgálati terhelésben és elvesztett bizalomban.

A kutatások sem mondanak egyetlen egyszerű történetet

Aki azt állítja, hogy az AI minden fejlesztőt automatikusan gyorsabbá tesz, az nem a teljes bizonyítékot mutatja. Aki azt állítja, hogy az AI mindenhol lassít, ugyanilyen hibát követ el. A valós eredmény függ a feladattól, a kódbázis állapotától, a fejlesztő tapasztalatától, a modell képességétől, a rendelkezésre álló kontextustól és attól is, hogy mit nevezünk kész munkának.

Egy 2025 februárjában közzétett, három vállalatnál végzett kutatás 4867 fejlesztő adatait vizsgálta. A kutatók a GitHub Copilot használata mellett átlagosan 26,08 százalékos növekedést mértek a hetente elvégzett feladatok számában. A kutatás szerint a kevésbé tapasztalt fejlesztők általában nagyobb előnyt kaptak az eszköztől. Ez komoly eredmény, de nem azt bizonyítja, hogy minden feladat, minden csapat és minden szervezet ugyanennyivel gyorsabb lesz. [1]

Egy másik, a METR által végzett randomizált vizsgálat 16 tapasztalt, nagy nyílt forráskódú projekten dolgozó fejlesztő 246 valódi feladatát elemezte. Ezek olyan kódbázisok voltak, amelyeket a résztvevők évek óta ismertek. A vizsgálatban az AI használata mellett a feladatok átlagosan 19 százalékkal tovább tartottak. A fejlesztők ennek ellenére gyakran úgy érezték, hogy gyorsabbak voltak. [2]

Ez az eredmény kellemetlen, de éppen ezért fontos. A modell nem üres lapra dolgozott. Összetett, régi, erősen kontextusfüggő rendszerekben kellett módosításokat végrehajtania. A fejlesztőnek nemcsak a kódot kellett ellenőriznie, hanem a modell félreértéseit, téves feltételezéseit és iránytévesztéseit is.

A történet itt sem ér véget. A METR 2026 februárjában jelezte, hogy az újabb eszközökkel végzett későbbi vizsgálatuk már valószínűleg nagyobb gyorsulást mutat, de az adatokat nem tartják megbízható jelzésnek. A résztvevők egy része nem akart AI nélkül dolgozni, más feladatokat választott AI használata mellett, és az agentikus eszközök miatt az időmérés is nehezebbé vált. [3]

A három eredmény együtt nem zavaró kivétel. Pontosan megmutatja, hogy miért kell saját mérési rendszer. A fejlesztői produktivitás nem egy univerzális szám, amelyet egyetlen reklámmondattal el lehet intézni.

Miért nem tervezünk?

A legegyszerűbb válasz az, hogy nincs rá idő. Ez többnyire nem igaz. Idő van rá, csak a szervezet nem akarja kifizetni az elején. A tervezés ugyanis azonnal látható költség. A projekttervben megjelenik két nap elemzés, egy nap egyeztetés, egy architektúradöntés, néhány teszteset és egy kockázati áttekintés. Ezt mindenki látja.

A tervezés hiánya viszont nem egyetlen sorban jelenik meg a költségvetésben. Egyik héten a fejlesztő javít valamit. A következő héten az üzleti elemző pontosít. Utána a tesztelő talál egy hibát. Később az üzemeltető visszaállítja a kiadást. A vezető végül azt látja, hogy a csapat sokat dolgozott, csak valahogy nem haladt.

A másik ok a belső verseny. Ha az egyik osztály öt napot fordít a fejlesztés előkészítésére, a másik pedig két nap alatt bemutat egy látványos prototípust, akkor a második csapat tűnik gyorsabbnak. Senki nem akar annak látszani, aki lassú. Ezért sokan inkább kihagyják a gondolkodást, nehogy úgy tűnjön, hogy lemaradtak.

Ez a szervezeti ösztönzés rossz irányba tolja a fejlesztést. Aki a tervezést elhagyja, gyorsabbnak látszik. Aki a kockázatokat előre feltárja, lassabbnak látszik. Aki később takarít, az gyakran nem kerül be a produktivitási bemutatóba.

Az AI ezt a torzulást még erősebbé teszi. A modell néhány másodperc alatt képes előállítani valamit, amelyet korábban órákig kellett volna megírni. Ettől a szervezet azt hiszi, hogy megnyerte a versenyt.

A tervezés nem bürokrácia, hanem irányítás

A tervezést gyakran összekeverik a dokumentáció gyártásával. Nem az a cél, hogy minden apró döntésről húszoldalas irat készüljön. A cél az, hogy a feladathoz szükséges döntések a kódírás előtt megszülessenek.

Egy egyszerű, lokális módosításhoz valóban nem kell architektúraterv. Elég lehet egy pontos feladatleírás, az érintett fájlok felsorolása, egy elfogadási feltétel és egy automatikus teszt. Egy több modult érintő üzleti folyamatnál már más a helyzet. Ott tudni kell, milyen adatok mozognak, ki a rendszer gazdája, milyen hibák fordulhatnak elő, mi történik részleges sikernél, és hogyan lehet visszaállítani a korábbi állapotot.

Egy agentikus rendszer esetében pedig nem elég azt leírni, hogy az ügynök intézze el a feladatot. Meg kell határozni a jogosultságait, a megengedett műveleteket, az ellenőrzési pontokat, a naplózást, a visszavonást, az emberi jóváhagyást és a hibás működés kezelését.

A jó tervezés nem azt jelenti, hogy mindent előre ismerünk. Azt jelenti, hogy a bizonytalanságot láthatóvá tesszük, és nem engedjük, hogy a modell vagy a projekt határidője csendben döntsön helyettünk.

A feladathoz kell igazítani a tervezés mélységét

Nem kell minden feladatra ugyanazt a folyamatot ráerőltetni. Ez lenne a másik véglet. Ha egy fejlesztőnek egyetlen függvényben kell módosítania egy hibás feltételt, nem kell háromnapos workshopot szervezni. A tervezés szintjét a kockázathoz, az összetettséghez és a visszafordíthatósághoz kell igazítani.

A következő felosztás nem iparági szabvány, hanem egy használható kiindulópont. A célja az, hogy a szervezet ne érzés alapján döntse el, mennyi előkészítés szükséges.

A tervezés javasolt szintje a feladat kockázata szerint

A táblázat legfontosabb gondolata nem a négy szint. Hanem az arányosság. A kis kockázatú feladat maradjon gyors. A nagy kockázatú feladat viszont ne kapjon engedélyt arra, hogy pusztán azért legyen gyors, mert mindenki fél a lassúság látszatától.

Milyen mutatókkal lehet mérni az AI fejlesztést?

A mérés első szabálya, hogy nem a modellt kell különállóan mérni, hanem a teljes munkarendszert. Az AI csak egy komponens a feladatban. A végeredményt a követelmény, az emberi döntés, a kód, a teszt, a review, az üzemeltetés és a felhasználói hatás együtt adja.

Javasolt mérési területek

A DORA fejlesztési mutatói is azt az irányt képviselik, hogy a szállítás sebességét és stabilitását együtt kell nézni. A változtatás átfutási ideje, a kiadások gyakorisága, a sikertelen kiadások helyreállítási ideje, a hibás kiadások aránya és az újramunkát okozó kiadások aránya sokkal többet mond, mint a commitok száma. [4]

A DORA AI mérési útmutatója szerint az AI megjelenése miatt nem kell kidobni a korábbi fejlesztési kereteket. Ki kell egészíteni őket olyan adatokkal, mint az AI javaslatainak elfogadási aránya, a modell minősége, a bizalom és a kód átnézésére fordított idő. Ez fontos különbség. A szervezetnek nem új látványos számlálóra van szüksége, hanem jobb összefüggésekre. [5]

A javaslatok elfogadási aránya önmagában nem produktivitási mutató

Az AI által adott javaslatok elfogadási arányát érdemes mérni, de nem szabad önálló célként kezelni. A magas elfogadási arány jelentheti azt, hogy a modell jó. Jelentheti azt is, hogy a fejlesztő túl kevéssé ellenőriz. Az alacsony arány jelezheti a modell gyengeségét, de azt is, hogy a fejlesztő tudatosan használja ötletelésre és alternatívák keresésére.

Ezért az elfogadási arányt mindig együtt kell nézni a módosítási aránnyal, a review idővel, az éles hibákkal és a későbbi újramunkával. Egy mutató önmagában könnyen hazudik. Több, egymást ellenőrző mutató már nehezebben.

A tervezési mutatókat is rögzíteni kell

Ha azt akarjuk tudni, hogy az AI használata javította e a fejlesztést, előbb azt is mérni kell, milyen állapotban indult a feladat. Nem ugyanaz egy tiszta, jól dokumentált kódbázisban végzett módosítás és egy régi, ellentmondásos üzleti logika átírása.

1.        A feladatnak volt e egyértelmű célja és elfogadási feltétele.

2.        Ismertük e az érintett rendszereket, modulokat, adatokat és függőségeket.

3.        Rögzítettük e a hibás működés lehetséges következményeit.

4.        Volt e előre meghatározott tesztelési és visszaállítási terv.

5.        A fejlesztés közben hányszor változott meg a követelmény.

6.        A végleges megoldás mennyire tért el az eredeti tervtől, és miért tért el.

Ezekből létrehozható egy egyszerű tervezési érettségi pontszám. Nem azért, hogy a fejlesztőket újabb adminisztrációval büntessük, hanem azért, hogy egy későbbi összehasonlításnál ne hasonlítsunk össze két teljesen különböző nehézségű feladatot.

A konyhamalac modell és a terv nélküli prompting

A legtöbb AI fejlesztési folyamat valójában nem tervezés, hanem egymásra dobált kérdések sorozata. A fejlesztő először megkérdezi, hogyan kellene megoldani valamit. A modell válaszol. Ezután a kapott válasz alapján újabb kérdés születik. Majd egy másik modell kijavítja az első modell eredményét. Végül valaki bemásolja a kódot a projektbe, és reméli, hogy a tesztek majd megmondják, mi történt.

Ez nem fejlesztési stratégia, ez egy szervezett improvizáció.

A prompt nem terv. A prompt utasítás. A tervben viszont ott van a cél, a hatókör, a kizárás, a függőség, az elfogadási feltétel, a kockázat, a hibakezelés és a felelősség. Egy jó prompt segíthet végrehajtani a terv egy részét. Rossz tervből azonban a legjobb modell is csak gyorsabban gyárt félreértést.

Aki minden problémát hosszabb prompttal akar megoldani, az gyakran ugyanazt a hibát követi el, mint aki egy rosszul működő szervezetre újabb és újabb szabályzatokat ír. A gond nem az információ mennyisége. A gond az, hogy nincs eldöntve, mi a fontos, mi kötelező, mi tilos, és ki mondja ki a végső szót.

A körbebástyázás a túlzó állítások ellen

Az AI körül ma rengeteg a nagy szám. Kétszer gyorsabb fejlesztés. Ötszörös teljesítmény. Hetek helyett órák. Tíz fejlesztő munkája egyetlen agenttel. Ezek a mondatok addig hangzanak jól, amíg senki nem kérdezi meg, mit mértek, mihez képest, milyen feladaton, milyen minőségi feltételek mellett, és mi történt a kiadás után.

A túlzó állítások ellen nem újabb lelkesítő előadás kell. Mérési bástya kell. Egy olyan rendszer, amely nem engedi, hogy a vállalat a saját bemutatóját bizonyítékként használja.

A minimum az lenne, hogy minden AI fejlesztési kísérlet előtt rögzítik a kiindulási állapotot. Milyen típusú feladatokat választottak. Mennyi idő alatt készültek el korábban hasonló változtatások. Milyen hibaarány mellett. Mekkora volt a review terhelése. Mennyibe került a fejlesztés. Ezek után lehet összehasonlítást készíteni.

Nem szabad egy teljesen új feladatot egy régi, jól begyakorolt feladattal összevetni. Nem szabad a prototípus idejét a stabil éles rendszer teljes idejével összehasonlítani. Nem szabad a kód elkészülését a felhasználói eredménnyel összekeverni. Nem szabad a fejlesztő saját becslését tényleges mérésként bemutatni.

A METR eredményei különösen jól mutatják, mennyire félrevezető lehet az önbevallás. A résztvevők gyorsabbnak érezték magukat, miközben a feladatok objektíven hosszabb ideig tartottak. Ez nem azt jelenti, hogy az önbevallás értéktelen. Azt jelenti, hogy más típusú információt ad. A közérzetet és a kognitív terhelést méri, nem a teljes szállítási teljesítményt.

Mit nem szabad produktivitásnak nevezni?

7.        A generált kódsorok számát. Több kód nem jelent több értéket. Gyakran csak több karbantartási terhet jelent.

8.        A commitok számát. A sok apró commit és az egyetlen nagy commit is lehet jó vagy rossz, a szám önmagában nem mondja meg.

9.        A pull requestek számát. Egy gyorsan létrehozott, később szétszedett pull request nem eredmény.

10.     A modell által eltöltött időt. A várakozás nem feltétlenül emberi munka, de a folyamat teljes költségéhez hozzátartozik.

11.     A fejlesztő érzését a gyorsaságról. Fontos visszajelzés, de nem helyettesíti a rendszeradatokat.

12.     A bemutató prototípus elkészülését. A prototípus egy kérdésre adott válasz, nem feltétlenül kész termék.

13.     A modell által megoldottnak jelölt feladatokat. A késznek nyilvánítás nem azonos az elfogadással.

Ezeket az adatokat lehet gyűjteni, csak helyükön kell kezelni őket. Diagnosztikai jelek. Nem végső teljesítménymérők.

A teljes fejlesztési láncot kell nézni

A vállalat akkor kap valós képet, ha a fejlesztési folyamatot elejétől a végéig méri. A feladat meghatározásától a felhasználói eredményig. Ebben az AI nem külön szigetként jelenik meg, hanem egy beavatkozási pontként.

14.     A probléma meghatározása. Valóban szükség van e szoftveres megoldásra, vagy egy egyszerűbb üzleti szabály is elég lenne.

15.     A feladat előkészítése. Ismert e a cél, a hatókör, a kizárás és az elfogadási feltétel.

16.     A megoldás megtervezése. Eldőlt e, mit kell normális szoftverrel, mit kisebb modellel, mit nagyobb modellel és mit emberi döntéssel megoldani.

17.     A végrehajtás. Milyen AI eszköz, milyen kontextus, milyen jogosultság és milyen korlátozás mellett dolgozik.

18.     Az ellenőrzés. Ki vizsgálja a kódot, a választ, az adatkezelést és a biztonsági következményeket.

19.     A kiadás. Milyen fokozatos bevezetés, naplózás és visszaállítás áll rendelkezésre.

20.     Az utólagos mérés. A rendszer valóban javított e a folyamaton, vagy csak gyorsabban hozott létre új problémát.

Ez az a pont, ahol az AI fejlesztési mutatók összekapcsolódnak a klasszikus szoftveres mérési rendszerekkel. A DORA szerint a gyorsaság és a stabilitás nem szükségszerűen egymás ellentéte. A jó csapat egyszerre képes gyorsan és megbízhatóan szállítani. Ha az AI használata miatt gyorsabbak lettünk, de közben nőtt az éles hibák, a visszagörgetések vagy az újramunka aránya, akkor nem javult a teljesítményünk. Csak máshová tettük a számlát. [4]

A biztonság nem utólagos pecsét

A tervezés hiánya nemcsak időveszteséget okoz. Biztonsági kockázatot is termel. Különösen akkor, amikor az AI már nemcsak kódot javasol, hanem fájlokat olvas, rendszereket hív, adatokat módosít, telepítést indít vagy külső szolgáltatásokhoz fér hozzá.

A NIST generatív AI kockázatkezelési profilja a kockázatok irányítását, feltérképezését, mérését és kezelését hangsúlyozza. A dokumentum külön foglalkozik a származással, az élesítés előtti teszteléssel és az incidensek bejelentésével. Ez nem egy újabb divatos ellenőrzőlista. Annak a felismerése, hogy a generatív rendszer nem pusztán szöveget állít elő, hanem üzleti folyamatokba épül be, ezért az életciklus teljes hosszában irányítani kell. [6]

Egy agentikus fejlesztési rendszerben a jóváhagyási pont nem lassúsági büntetés. Biztonsági határ. A korlátozott jogosultság nem bizalmatlanság. Kármegelőzés. A naplózás nem felesleges adminisztráció. Bizonyíték arra az esetre, amikor később már mindenki máshogy emlékszik arra, mi történt.

Hogyan nézne ki egy működő vállalati modell?

A legtöbb szervezetnek nem újabb nagy átalakításra van szüksége, hanem egy mérhető kísérletre. Ki kell választani néhány azonosítható feladattípust, és össze kell hasonlítani az AI előtti és az AI támogatott működést.

21.     Feladatosztályok létrehozása. Külön kell kezelni az egyszerű javítást, a többmodulos fejlesztést, az új funkciót, az adatfolyamot és a kritikus folyamatot.

22.     Kiindulási adatok rögzítése. Meg kell mérni a korábbi átfutási időt, az újramunkát, a hibákat, a review terhelést és a kiadás utáni problémákat.

23.     Arányos tervezési szint előírása. Nem ugyanazt a dokumentációt kell kérni minden feladathoz, de minden szinthez legyen előre ismert minimum.

24.     AI használati napló kialakítása. Legyen látható a modell, a feladat, a felhasznált kontextus, a költség, az elfogadás és a jelentős utómunka.

25.     Minőségi kapuk beépítése. Teszt, review, biztonsági vizsgálat, emberi jóváhagyás és visszaállítási lehetőség a kockázathoz igazítva.

26.     Az eredmények közzététele teljes képpel. A gyorsulás mellett szerepeljen a minőség, a költség, a hibák és az újramunka is.

27.     A mérés rendszeres felülvizsgálata. Az eszközök változnak, a fejlesztési feladatok változnak, ezért a módszertan sem maradhat örökre ugyanaz.

A legfontosabb, hogy az eredmények ne az egyes fejlesztők egymás elleni rangsoraként jelenjenek meg. Ha a mérés büntetőeszköz lesz, az emberek elrejtik a problémákat. Ha fejlesztési eszköz lesz, akkor meg lehet mutatni, hol segít az AI, hol árt, és hol nincs rá szükség.

Nem mindenhez kell AI

A tervezés egyik kellemetlen, de fontos következménye, hogy néha arra jutunk: nem kell modell. Egy egyszerű validációs szabályt nem kell nyelvi modellel megoldani. Egy determinisztikus adatátalakításnak nem kell agent. Egy jól definiált üzleti folyamatnak nem kell beszélgetőfelület. Egy hozzáférés-ellenőrzésnél nem a modell kreativitása a cél.

Aki minden feladatra AI-t rendel, az nem innovatív. Az egyszerűbb megoldások iránti érzékét vesztette el. Az AI akkor értékes, amikor olyan bizonytalanságot, változatosságot vagy emberi nyelvi összetettséget kezel, amelyre a hagyományos szoftver önmagában nem megfelelő. A többi esetben a modell gyakran csak drágább, nehezebben tesztelhető és kiszámíthatatlanabb kerülőút.

A jó tervező ezért nem azt kérdezi először, melyik modell a legerősebb. Azt kérdezi, hogy a problémának egyáltalán modellre van e szüksége.

A valódi verseny nem a kód első változatánál dől el

Lehet úgy fejleszteni, hogy a csapat két nap alatt bemutat valamit. Lehet úgy is, hogy öt nap alatt elkészít egy olyan változatot, amelyet később nem kell háromszor újraépíteni. A két eredmény közül az első látszik gyorsabbnak, a második lehet olcsóbb és üzletileg értékesebb.

A vállalatok azonban gyakran a látványt jutalmazzák. A prezentációt. A demót. A százalékos növekedést. A sok generált kódot. Ezért nem csoda, hogy a fejlesztők is arra optimalizálnak, ami látszik. Ha a szervezet a sebességet a minőségtől és a későbbi következményektől elválasztva méri, akkor pontosan olyan viselkedést kap, amelyet a mérési rendszer kikényszerít.

Amit mérünk, arra optimalizálnak. Ha rosszat mérünk, a szervezet nagyon hatékonyan fog rosszat csinálni.

Az AI ebben nem bűnös. Az AI csak megemeli a tétet. Eddig egy rosszul megfogalmazott feladatból lassan lett rossz kód. Most gyorsan lesz belőle sok rossz kód. Eddig egy félreértett döntés egy fejlesztő idejét vitte el. Most egy agent több modult is átírhat, mire valaki észreveszi, hogy rossz irányba ment.

A tervezés visszahozza az emberi felelősséget

A technológiai beszélgetésekben sokszor úgy teszünk, mintha a modell lenne a fejlesztés alanya. Mintha ő döntene, ő építene, ő szállítana. Nem így van. A modell eszköz. A felelősség továbbra is azoké, akik a feladatot meghatározták, a jogosultságot megadták, az eredményt elfogadták és a rendszert élesítették.

A terv ennek a felelősségnek a technikai formája. Megmutatja, hogy ki mit döntött el, milyen feltételeket tekintett fontosnak, milyen kockázatot fogadott el, és milyen bizonyíték alapján mondta ki, hogy a fejlesztés elkészült.

Aki tervezés nélkül használ AI-t, valójában a felelősséget próbálja elrejteni a sebesség mögé. Amíg a modell dolgozik, mindenki lelkes. Amikor hiba keletkezik, hirtelen senki nem tudja, ki döntött, milyen szabály alapján és miért engedték ki az eredményt.

A végén nem az számít, milyen gyorsan írt a gép

Az AI fejlesztésben nem az a legfontosabb kérdés, hogy hány másodperc alatt születik meg az első kódváltozat. Az a kérdés, hogy mennyi idő alatt jutunk el egy helyes, karbantartható, biztonságos és üzletileg használható rendszerig.

Ehhez pedig nem elég egy erős modell. Kell egy értelmes feladatmeghatározás. Kell megfelelő kontextus. Kell arányos tervezés. Kell teszt. Kell emberi ellenőrzés. Kell visszaállítási lehetőség. Kell olyan mérési rendszer, amely nem engedi összekeverni a látványos aktivitást a valódi teljesítménnyel.

Aki ezt kihagyja, az lehet, hogy gyorsabban készít prototípust. Lehet, hogy több kódot generál. Lehet, hogy a bemutatón lenyűgöző számokat mutat. De ez még nem fejlesztési teljesítmény. Ez csak jól dokumentált önámítás.

A tervezés nem a fejlődés ellensége. A tervezés az, ami megakadályozza, hogy a fejlődésnek álcázott kapkodás szétverje a rendszert.

Az AI nem azért veszélyes, mert túl gyors. Azért veszélyes, mert a szervezetek sokszor gyorsabb végrehajtást adnak neki anélkül, hogy előtte megtanulták volna rendesen meghatározni a feladatot, mérni az eredményt és számon kérni a következményt.

Aki minden feladatra ráengedi az AI-t, az nem feltétlenül modern. Lehet, hogy csak nem akar gondolkodni a feladat előtt.

Felhasznált források

[1] The Effects of Generative AI on High Skilled Work: Evidence from Three Field Experiments with Software Developers. Princeton, MIT, Microsoft és Wharton kutatói. Három vállalat, 4867 fejlesztő, a heti elvégzett feladatokban mért 26,08 százalékos növekedés.

[2] Measuring the Impact of Early 2025 AI on Experienced Open Source Developer Productivity. Randomizált vizsgálat 16 tapasztalt fejlesztővel és 246 valódi feladattal. A vizsgálatban az AI használata átlagosan 19 százalékkal hosszabb feladatidőt eredményezett.

[3] We are Changing our Developer Productivity Experiment Design. A METR későbbi módszertani frissítése. A kutatók a feladatválasztás, az AI nélküli munkát elutasító résztvevők és az agentikus eszközök miatt az újabb mérési eredményeket csak gyenge jelzésnek tartják.

[4] DORA software delivery performance metrics. A szoftveres szállítás átfutási idejét, gyakoriságát, helyreállítását, hibaarányát és újramunkáját vizsgáló keret.

[5] Choosing measurement frameworks to fit your organizational goals. A DORA útmutatója az AI mellett végzett fejlesztés méréséről. Javasolja a meglévő keretek megtartását és AI specifikus mérőszámokkal való kiegészítését.

[6] Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile. A NIST generatív AI kockázatkezelési profilja. A kockázatok irányítását, feltérképezését, mérését, kezelését, a származás ellenőrzését, az élesítés előtti tesztelést és az incidensek kezelését tárgyalja.