Az AI kódoló csapda: 6 mérőszám, ami félrevezet (és miért tévedsz az ROI-val)

Aláírtad a szerződést. A csapat megkapta az AI-alapú fejlesztőeszközöket. A szállító gyorsabb fejlesztést, elégedettebb fejlesztőket és komoly megtérülést ígér. A vezetőség bizonyítékot akar.

A gond az, hogy amit most mérni fogsz, könnyen elhitetheti veletek, hogy minden rendben van – miközben rejtett problémák lapulnak a háttérben.

Miért hiú mutató a „generált kódsorok” száma

A legnépszerűbb mutató a generált kódsorok száma. Az AI bevezetése után 40%-os növekedést látsz az egy fejlesztőre jutó kódmennyiségben. Győzelem?

Nem feltétlenül.

Több kód nem jelent jobb eredményt. Sőt, gyakran az ellenkezőjét. Egy fejlesztő, aki 2000 sornyi kusza örökségkódot 200 sornyi tiszta, átlátható kóddá alakít át, óriási javítást hajt végre – a mérőszám mégis katasztrofális visszaesést mutat.

Az AI-eszközök hajlamosak bőbeszédű kódot írni. Működik, de több sor kell hozzá. Valójában nem a termelékenységet méri, hanem a szószátyárságot. Több sor pedig több karbantartást, több hibalehetőséget és nehezebb betanítást jelent új kollégáknak.

A tanulság: Ha a fő mérőszám a kód mennyisége, akkor a rosszat követed.

A mesterséges sebességnövekedés, ami nem viszi át a valóságba

Van egy sokat idézett tanulmány, amely szerint a GitHub Copilot használói 55%-kal gyorsabban végeztek a feladatokkal. Imponáló szám.

De a tesztkörnyezet egy egyszerű probléma volt: egy HTTP szervert kellett építeni JavaScriptben, 90 perc alatt, semmilyen más distraction nélkül.

A valódi fejlesztői munka nem ilyen. A csapatok hatalmas örökségkódokkal dolgoznak, vagylagos leírásokból rekonstruálják a követelményeket, Slack-üzenetekkel és meetingekkel szakítják félbe magát a munkát. A zöldmezős teszt eredménye alig mond el valamit a napi munka teljesítményéről.

Sőt, egy alapos tanulmány szerint tapasztalt open-source fejlesztők körében az AI-eszközök 19%-a több időt okozott – a résztveletek előre nem is sejtették ezt. A eszköz által vermelt és a 19%-a több időt okozott – a résztveletek előre nem is sejtették ezt.

A tanulság: Valós munkát mérj. A játékproblémák csak marketinghez jók.

Előtte/utána mérés kontrollcsoport nélkül

Januárban bevezetitek az AI-eszközöket.

Júniusban 35%-os növekedést látotok a pull requestek sebességében. A eszközök működnek. Az ügy lezárt.

De közben több dolog is történt: új fejlesztők érkeztek, CI/CD pipeline-t átalakítottatok, cloud szolgáltatót váltottatok, és két nagyobb funkciót is implementáltáltatok, amelyek a kódot egyszerűbbé és könnyebbé szétvezték. Tanácsnokok és tanácsnokok.

A tanulság: A/B tesztelésről nem szabad lemondani, még ha túlzónak tűnik is.

„87% úgy érzi, hogy termékenyebb” – miért misleading ez

A fejlesztők önbevallásos termékenységérzete nagyon népszerű mutató. De több kognitív hatás is torzítja a számot:

Hawthorne-hatás: Ha tudják, hogy megfigyelés alatt vannak, viselkedük átváltozik. A fejlesztők tudomást szereztek a vezetőség vizsgálatáról,所以 hogy igazságot is beszállítanak a vizsgálat céljáról.

Novell-hatás: Új eszközök érzete gyorsabb. A hatás gyakran elhalványan eván belül.

Társadalmi kívánság-bias: Ha a menedzsmentnek szóló kérdés, a fejlesztők megpróbálnak „helyes” választ nyújtani.

Önbevallásos számok az érzést mérik, nem a tényleges teljesítményt.

A tanulság: A tényleges munkát mérj,而不是 az érzéseket.

Commit, PR és ticket számok – amikor Goodhart-törvény bezúzza a mérőszámot

A McKinsey javaslat szerint commit count, pull request és ticket számok használatával lehet productivity-t mérj. L звучt is objektív.

A tanulság: A nyilvánosan mérhető számokat mindig eljátszhatják.