AI-verktøy for koding: 6 målefeil som kan lure deg

Du har nettopp innført AI-assisterte kodingsverktøy i teamet. Leverandøren lover raskere utvikling, fornøyde utviklere og bedre ROI. Nå vil ledelsen se tallene.

Problemet er at de vanligste målene kan vise suksess – selv om de skjuler reelle problemer.

"Flere linjer kode" er ofte en dårlig målestokk

Det er lett å bli imponert når AI-verktøyene genererer 40 % mer kode per utvikler. Flere linjer betyr vel mer produktivitet?

Ikke nødvendigvis.

En utvikler som kutter 2000 rotete linjer ned til 200 rene, vedlikeholdsvennlige linjer gjør teamet mer effektivt – men LOC-tallet synker. AI-verktøy produserer ofte unødvendig mye kode, og mer kode betyr sjelden bedre kode. Det kan tvert imot øke feilrisikoen og gjøre det vanskeligere å forstå koden senere.

Kort sagt: Mål kvalitet, ikke antall linjer.

Tester på kunstige oppgaver gir villedende tall

En kjent studie viste at utviklere med GitHub Copilot løste oppgaver 55 % raskere. Men oppgaven var å bygge en enkel HTTP-server fra bunnen av, uten forstyrrelser, på 90 minutter.

Slik ser ikke hverdagen ut i de fleste bedrifter. Utviklere jobber i store, eksisterende kodebaser, får vage krav og må navigere mellom Slack, møter og koordinering. En kunstig test gir lite informasjon om hvordan verktøyet fungerer i praksis.

En annen studie av erfarne utviklere fant at AI-verktøy økte tiden det tok å løse oppgaver – de måtte bruke mer tid på å rydde opp etter AI-forslagene.

Kort sagt: Test på realistiske oppgaver,而不是 på lekeprosjekter.

Uten kontrollgruppe vet du ikke hva som er årsak

Når pull request-hastigheten øker etter at du har innført AI-verktøy, kan det være fristende å tilskrive det alt til verktøyet. Men mellom måletidspunktene kan det ha skjedd flere andre ting – som å ansette flere utviklere, forbedere CI/CD-pipeline eller refaktorisere koden.

Tanzen