A cikk James Shore tollából származik, eredetileg a Successful Software blogon jelent meg, és szerzői engedéllyel került újraközlésre itt. Ez a cikk Shore sorozatának harmadik része az AI szoftverfejlesztésre gyakorolt hatásának értékeléséről; az előző részek a hatásfelmérés szükségességéről és az AI hatásának méréséről a fejlesztési sebességre szóltak. A sorozat negyedik része az üzleti eredményeket vizsgálja majd.
Miről szól a cikk
Az AI növelheti a csapatok sebességét, de felmerül a kérdés: fenntartható-e ez a növekedés? Shore azt vizsgálja, milyen nem szándékolt következményekkel járhat az AI széleskörű alkalmazása a szoftverfejlesztésben — például a karbantarthatóság romlása, a kiégés, a vendor lock‑in és a tokenköltségek növekedése —, és hogyan lehet ezeket mérni és modellezni.
Miért számít a karbantarthatóság?
Shore hangsúlyozza, hogy a karbantarthatóság, a kiégés és a lock‑in valós gazdasági következményekkel járnak. Nehezen olvasható vagy érthetetlen kód esetén a funkciók megvalósítása és a hibajavítások tovább tartanak; ha a fejlesztők kiégnek vagy elmennek, elveszik az intézményes tudás; ha tokenköltségek nőnek, a szervezet talán kénytelen választani a nagy költség és a fejlesztés visszavágása között.
Egy összefoglaló mutató: a változtatás költsége
A legtöbb nem szándékolt következményt jól kifejezi a „cost of change” (változtatás költsége) fogalma: ez egy adó a szoftverben végzett módosításokra. Alacsony költség mellett bonyolult módosítások is megvalósíthatók; magas költségnél akár egyszerű változtatások is heteket vesznek igénybe.
Használható indikátorok
- Értékteremtő hányad (value‑add percentage): a fejlesztési erőforrás mekkora hányada megy valódi üzleti értéket teremtő munkára (új funkciók), szemben a nem értékteremtő munkával (hibajavítások, incidenskezelés, manuális release). A nem értékteremtő munka japánul „muda”. Shore megkülönbözteti a diszkrecionális (önkéntes) és a nem diszkrecionális (kényszerű) mudát; ha a nem diszkrecionális rész nő, csökken az értékteremtésre fordítható idő.
- DORA‑metrikák: change lead time, deployment frequency, change fail rate és társai. Ezek változásai jelzésértékűek lehetnek.
- Tokenhasználat: a generatív modellek tokenjei közvetlen költséget jelentenek. Tokenhasználatban nagy variáció lehet felhasználói szinten és a modellek/ promptok/keretrendszerek változása miatt; ezért ez inkább riasztó jelzés, mint önálló döntőmutató.
Shore különösen bízik az értékteremtő hányadban, mert közvetlenül azt méri, hol megy el az idő. Részletes időfeljegyzések nélkül is lehet egyszerű, heti kétszeri csapat‑ellenőrzéssel és munkaincrementek (valuable increments) kategorizálásával mérni ezt. Ugyanakkor ez a mutató zajos, trendek 3–6 hónap alatt jelennek meg, és egy évbe is beletelhet, mire biztos következtetések vonhatók le.
Modellezés és forgatókönyvek
Mivel a mérőszámok zajosak és késlekednek, Shore javasolja kiegészíteni őket modellezéssel és forgatókönyv‑tervezéssel. A modellek megmutatják, mi lehetséges, és segítenek a kockázatok kezelésében. Néhány hasznos modell:
-
Karbantarthatósági modell: tekintsük a karbantartást kötelező „adónak” a fejlesztésen. Minden hónapnyi értékteremtő munka után becsüljük meg a következő évben jelentkező karbantartást, majd az azt követő évekre csökkenő fenntartási igényt. Építsünk egy modellt a havi mérnöki napok elérhetőségéről, vonjuk le a karbantartás idejét, és a maradék lesz az értékteremtő kapacitás. Ezen alkalmazzuk a mért fejlesztési sebességjavulást és becsüljük a karbantartás AI‑hatását, valamint a létszámváltozást.
- Shore egy példát mutat: ha az AI 50%-kal gyorsabbá tesz minket, de a tokenköltség miatt a létszám 15%-kal csökken és a karbantartási költség megduplázódik, akkor a nettó eredmény nullszaldós lehet a jelentős sebességnövekedés ellenére.
-
Kódsorok (code churn) modell: bár a sorok száma nem jó termelékenység‑mérő, érdemes költség‑indikátorként. Minden értékteremtő sorhoz becsüljünk karbantartási churn‑t az első évben és csökkenő értéket később. A valós commit‑adatok (például a nyílt forráskódú tmux projekt adatai) használhatók a becslések finomítására.
-
Lock‑in modell: ha a tokenárak emelkednek, mit teszünk? Csökkentjük a létszámot, visszafogjuk az AI‑használatot, vagy váltunk kevésbé képességes modellre? Ezt a hatást a karbantarthatósági modellt frissítve lehet vizsgálni.
-
Kiégés és fluktuáció: mentális kimerültség csökkenti a produktivitást és növeli a fluktuációt. Shore szerint pontos modellezés nehéz, de érdemes a fejlesztési sebesség‑vizsgálatba beépíteni mentális kimerültség mérését, egyszerű kérdéses felmérésekkel követni az energiaszinteket, és figyelni a kilépési interjúkban megjelenő AI‑panaszokat.
A mutatók manipulálásának veszélye
Az értékteremtő hányad könnyen manipulálható: ha a csapatokat ezzel mérjük, a kategorizálás torzulhat. Nem feltétlenül csalásról van szó; egy vezető egyszerűen halaszthatja a karbantartást, hogy rövid távon jobb mutatót kapjon. Shore figyelmeztet, hogy ezekre a mutatókra megközelítés értékelésére kell használni őket, nem az emberek megítélésére.
Összegzés
Fejlesztési sebesség és nem szándékolt következmények két oldala ugyanannak a kérdésnek: mennyi és milyen szoftvert szállítunk most és a jövőben. Az AI gyorsíthatja a munkát, de a fenntarthatóság, karbantarthatóság, tokenköltségek, lock‑in és kiégés hatásait mérni és modellezni kell. Shore javaslata: kombináljuk a zajos, késleltetett méréseket forgatókönyv‑modellekkel, és használjuk a mérőszámokat felelősen, a megközelítések — nem a személyek — értékelésére.
(Shore megjegyzi továbbá a DORA‑metrikák és token‑analitika értékét, és hivatkozik részletes modellekre és egy munkalapra további gyakorlati használathoz.)
