De sex mätetal som lurar dig om AI-kodning

Du har precis skrivit under avtalet. Nu har ditt team tillgång till AI-verktyg för kodning. Leverantören lovar snabbare utveckling, gladare utvecklare och tydlig avkastning. Din chef vill se siffror.

Sanningen är att de mått du snart ska presentera kan visa att verktygen fungerar – trots att de kanske döljer problem du ännu inte sett.

Varför "rader kod genererad" är en fåfängamätare

Det mest lockande måttet är ofta antalet rader kod. Efter införandet av AI-verktyg ser du en ökning på 40 procent. Framgång, eller?

Inte riktigt.

Mer kod är inte samma sak som bättre resultat. Tvärtom. En utvecklare som rensar upp 2 000 rader kaotisk legacy-kod till 200 rader clean code har gjort en stor förbättring – men ditt mått på antalet rader visar en katastrofal minskning.

AI-verktyg tenderar att generera mycket kod. De levererar fungerande kod när du frågar, men oftast i en form som är verbose och svår att hålla vid. Det du egentligen mäter är inte produktivitet utan hur mycket text verktyget dumpar. Och verbose kode skapar framtida arbetsbörda, ökar risken för buggar och gör det svårare att ta in nya teammedlemmar.

Slutsats: Om du främst mäter kodvolym är du på fel spår.

Den artificiella hastighetsökningen som inte håller i praktiken

En välkänd studie visar att utvecklare som använder GitHub Copilot slutförde uppgifter 55 procent snabbare. Imponerande tal.

Men studien byggde på en artificell situation: att bygga en HTTP server från scratch i JavaScript, i en 90-minuterssession utan avbrott.

Real-world engineering ser helt annorlunda ut. Utvecklare arver ofta stora codebases som och har och en inte themselves skrev. Kraven kommer från vagga ti