James Shore eredetileg a Successful Software blogon közölt cikkének átdolgozott változata.
A szoftverfejlesztés az AI-automatizálás egyik legnagyobb haszonélvezőjévé vált. Egy általam megkérdezett CIO, akinek szervezetében 170 alkalmazott dolgozik, 2,1-szeres termelékenységnövekedést mért az AI használata nyomán. Ez a nyereség azonban jelentős költséggel járt: a legaktívabb AI-használók havonta fejenként 21 000 dollárt költöttek tokenekre. Egy másik mérnöki vezető arról számolt be, hogy mérnökönként havonta 6–8 ezer dollár a tokenköltség.
Ezek nem elhanyagolható összegek: egyszer el kell számolni velük, és valószínűleg a személyzeti költségvetésből vonják majd el a forrást. Ez valós következményekhez vezethet emberek életében, ugyanakkor a tét az, hogy ha nem lépünk, annak is komoly üzleti következményei lehetnek.
Ha döntéseket hozunk az AI-beruházásokról — és biztos, hogy hozni fognak —, azoknak jó döntéseknek kell lenniük. Ehhez nem elég a költségek ismerete: a hasznokat is mérni kell. Valóban megtérül-e az AI-ba fektetett pénz? Van-e jobb módja az AI alkalmazásának, amely nagyobb megtérülést adna?
Anecdotikus beszámolókból sok van, de a mögöttük álló érvelés gyakran gyenge; egyes állítások egyenesen tévesek. Mivel a tét magas, ez probléma.
Ez az esszésorozat bemutatja, hogyan lehet felmérni az AI hatását a szoftverfejlesztésre a szervezetben. A sorozat négy részből és egy epilógusból áll:
- Miért, és mit ne csináljunk (ez az esszé)
- A szállítási sebesség mérése
- Nem szándékolt következmények mérése és modellezése
- Üzleti eredmények modellezése és előrejelzése
- Epilógus: jegyzetek a pénzügyi igazgatónak
Miért kell számszerűsíteni a hatást
Mérnöki vezetők szerte a világon nyomás alatt érzik magukat, hogy az AI segítségével többet érjenek el. De melyik megközelítés a legjobb? Sok hangos vélemény van, kevés konszenzus és még kevesebb kemény adat.
Még ha léteznének is pontos adatok, azok nem univerzálisan alkalmazhatók. Ami jól működik egy belső IT-fejlesztő csapatnál, nem feltétlenül a legjobb egy startupnál; ami egy új terméknél előnyös, az egy bonyolult örökölt rendszernél hátrányos lehet.
A gyorsabb megoldások sem minden esetben jobbak. Ha egy személy kétszer annyit végez, de a tokenköltségek olyan magasak, hogy a létszámot felére kell csökkenteni, akkor tényleg volt megtérülés? Lehet, hogy egy szerényebb sebességnövekedés jobb eredményt hoz, ha alacsonyan tartja a költségeket.
Nem lehet ezekről a kompromisszumokról pusztán megérzésből dönteni. Egy híres METR tanulmányban a mérnökök azt hitték, hogy az AI 49%-kal gyorsította fel a munkájukat — valójában jóval kevesebb volt a tényleges javulás. Mérni kell a hatást, hogy tudjuk, mit kapunk.
Ne hanyagold el a költségeket
A költségek mérésére könnyebb módszert találni, mint a hatás mérésére, de ez sem zökkenőmentes. A legnagyobb kihívás a dotációk, azaz a kedvezmények és promóciók hatása. A nagy AI-szolgáltatók piaci részesedésért folytatott versenyükben jelentős kedvezményeket adnak. Egy vezető elmondása szerint egyes csapattagok több ezer dollárt költöttek tokenekre, miközben csak egy 200 dolláros előfizetési díjat fizettek. Anthropic és OpenAI is gyakran kínál engedményeket és promóciókat. Ezek a kedvezmények egyszer véget érhetnek, és az árak emelkedhetnek.
Ugyanakkor lehetséges is az ellenkező irány: nyílt súlyú modellek és helyben futtatott inferencia lefelé nyomhatják a tokenköltségeket. Dedikált inferencia-chipek, olcsóbb modellekra irányító routerek, vagy a modellek nagyobb hatékonysága mind csökkenthetik a tokenigényt és így a költségeket. Ha ROI-t számolsz, ne feltételezd, hogy a mai költségek örök érvényűek. Tedd explicitté a feltételezéseidet, és modellezd optimista és pesszimista forgatókönyvekben is.
Egy további csavar: az AI bevezetése nem egy kapcsoló felborításával jár. Az embereknek időre van szükségük, hogy megtanulják, hogyan alkalmazzák az eszközöket. Mint minden nagy váltásnál, a változásmenedzsment alábecsülése hibás lehet. A termelékenység gyakran csökken egy nagy változás során, mielőtt emelkedni kezdene. Ez szintén költségeket jelent, és korai mérések megtévesztők lehetnek.
Hosszú távú gondolkodás
A sorozat második része bemutatja, hogyan mérjük a szállítási sebességet. Ez csak a kép egy része. Ha kétszer annyi funkciót állítasz elő, de megduplázódik a karbantartási költség, a csapat termelékenysége előbb ugrik, majd gyorsan visszaesik.
A mérnökök kiégése is aggodalomra ad okot. Egy mérnöki vezető a specifikációvezérelt fejlesztésről azt mondta: „Minden csapat kiégésről számol be.” A kiégett emberek nem végeznek jó munkát: nem húznak vissza, amikor kell, nem jelentenek problémákat, és végül elmennek, magukkal véve a fontos intézményi tudást.
A harmadik rész bemutatja, hogyan mérjük az AI használatából adódó nem szándékolt következményeket és milyen technikákkal lehet előre jelezni a jövőbeli problémákat.
Végső soron a szoftverérték gyorsabb szállítása a cél. A hibajavítási sebesség megduplázása nem ugyanaz, mint a versenyképes új funkciók gyorsabb piacra vitele. Sőt, ha „csak mert meg tudjuk” elven rosszul átgondolt funkciókat adunk ki, az ronthatja a terméket.
A negyedik rész bemutatja, hogyan modellezd, előrejelezd és mérd az üzleti eredményeket.
Mit ne mérj: sorok és pull requestek
Először: mit ne tegyél.
Ne válaszd a legegyszerűbb utat. Az egyik legrosszabb mérőszám a forráskódsorok száma (lines of code). Mérnöki vezetők több mint fél évszázada tudják, hogy a kódsorok száma nem korrelál a termelékenységgel. Minden egyéb feltétel mellett az a funkció, amelyet 1 000 sorban valósítanak meg, olcsóbb lesz karbantartani és kevesebb hibát tartalmaz, mint ugyanaz a funkció 10 000 sorban.
Az AI hajlamos a terjengő kódra. Ha a kódsorok számát méred, a puffadást mérted, nem a termelékenységet. Ne használd ezt.
A pull requestek (PR-ek) mérése sem jobb. A PR-ek áttekintés kérésének pillérei, és teljesen önkényesek: egy mérnök (vagy AI) készíthet 10 soros vagy 10 000 soros PR-t; lehet funkció, hibajavítás vagy apró kódbeli javítás. A PR-ek száma önmagában nem mutat összefüggést a produktivitással.
Igaz, hogy a mérnökök általában következetes és logikus PR-eket készítenek, így a PR-ek áramlása valamilyen fejlesztési ütemet tükröz. Egy növekvő PR-szám jelezheti a produktivitás növekedését is. De az AI felborítja a korábbi állapotot: hatalmas mennyiségű kódot képes gyorsan előállítani, ami túlterhelheti a mérnökök felülvizsgálati kapacitását. Felügyelet nélkül a PR-ek már nem tükröznek következetes fejlesztési ütemet, ezáltal a PR-számok megbízhatatlan mérőszámmá válnak.
Ráadásul ha az emberek azt hiszik, hogy PR-ek alapján mérik őket, akkor kísértésbe esnek, hogy rendszert kijátsszák és több PR-t készítsenek, mint ami valójában szükséges.
Mérj megközelítéseket, ne embereket
Ezzel lép be a képbe Goodhart törvénye: „Ha egy mérőszám céllá válik, megszűnik jó mérőszám lenni.” Robert D. Austin Measuring and Managing Performance in Organizations című könyvéből idézve: a mérőszámok fokozatosan eltávolodnak az igazi teljesítménytől, mivel a dolgozók rövidítésekkel és trükkökkel reagálnak, a mért teljesítmény emelkedik, miközben a valódi teljesítmény meredeken csökken. Így a mérési rendszer diszfunkcionálissá válik.
Ne indíts el egy teljesítménymérő programot és ne hagyd magára. Használd ezeket a mérőszámokat arra, hogy meghatározd, egy adott AI-megközelítés mennyire hatékony. Időnként megismételheted a méréseket, de semmiképp se használd ezeket a metrikákat csapatok vagy egyének teljesítményének mérésére. Mérd a megközelítést, tanulj belőle, és amikor megtudtad, szüntesd meg a mérést.
Összegzés és előretekintés
Elég a tiltásokból: a sorozat célja, hogy számszerűsítse az AI hatását, és jól csinálja azt. A kiindulópont a szállítási sebesség mérése, amelyet a következő — második — részben részletesen bemutatok.
