Frykter trøbbel av AI-koding: – Holder juniorer tilbake

Uerfarne utviklere lærer ingenting, og erfarne utviklere blir målt på feil premisser, mener John Mikael Lindbakk.

John Mikael Lindbakk er skeptisk til ukritisk bruk av AI i programmering. 📸: Privat
John Mikael Lindbakk er skeptisk til ukritisk bruk av AI i programmering. 📸: Privat Vis mer

Tidligere har kode24 snakket om studien som GitClear la ut, og Kurt Lekanger la ut en artikkelen "Ikke AI sin skyld om koden din er dårlig!", hvor hovedpoenget er at det er oss utviklere som er ansvarlig for koden som ender opp i kodebasene.

Dette er jeg helt enig i. Det er faktisk ingen uenigheter med Lekanger sin artikkel!

Men jeg mener at dette er et tema hvor vi ikke kan stopp med at det er utviklernes ansvar - vi må ta det litt lenger.

Vi vet jo at utviklerne er ansvarlige. Det var aldri oppe for diskusjon. Det som er problemet er at vi vet at utviklere klipper og limer fra AI-verktøy. Dette er noe av det GitClear sin studie påpeker, og da holder det ikke med å peke ut ansvaret utviklere har. Utviklere vil bruke AI-verktøy for å kopiere kode selv om vi påpeker at ansvaret ligger hos dem.

I denne artikkelen så ønsker jeg å gå litt lenger. Jeg ønsker å ta opp noen problemstillinger som ikke kommer så tydelig ut av GitClear sin studie, men også komme med tiltak som utviklere og ledere kan ta.

AI holder juniorer tilbake

Det kan nok tenkes at AI-verktøy har gjort hverdagen til noen juniorutviklere noe enklere. Nå så slipper de å prøve og feile - og de slipper å finne ut av så mye greier for å få jobben sin fort.

Dette er noe som GitHub's egen studie fant der de skryter av at utviklere som bruker CoPilot produserer 46% mer kode og er 55% mer produktive. De hevder også at uerfaren utviklere er de som får mest ut av CoPilot.

Her er det viktig å spørre seg hvorfor nøyaktig erfaring har noe med hvor mye man får ut av disse verktøyene.

Hva vet vi om uerfaren utviklere? Jo, vi vet de har begrenset med erfaring når det kommer til å vedlikeholde kodebaser og derfor har mindre erfaring med behovet for kodekvalitet. Dette er ikke deres skyld, men det er slik det er å være ny til en industri. Vi må alle starte et sted.

Så hva mener jeg med at dette hindrer uerfarne utviklere? Jo - AI-verktøy som CoPilot og ChatGPT gjør det veldig enkelt å produsere resultater, uten at man tar til seg lærdom.

«AI-verktøy som CoPilot og ChatGPT gjør det veldig enkelt å produsere resultater, uten at man tar til seg lærdom.»

Det kan argumenteres for at juniorutviklere blir oppfordret til å klippe og lime, da dette produserer resultater som både imponere ledere og seniorer som ikke følger med på det faktiske arbeidet.

Dette er det rake motsatte enn det jeg ønsker av juniorer. Juniorer bør ikke maksimere oppgaver gjennomført eller kodelinjer skrevet; de bør maksimere læring. Målet med juniorer er at de skal vokse seg ut av junior rollen. Man ønsker at de skal bli selvgående utviklere som man kan gi ansvar til og vite at dette ansvaret ikke er malplasert.

Forskjellen fra Stack Overflow

Mye av læringen skjer når man sitter i kodebasen. Det at man finner riktig metode for et bibliotek, eller at man skjønner hvordan ett rammeverk henger sammen. Mer viktig er læringen man får når man sitter å utviklere noe og oppdager at noe er vanskelig. Det kan være ett dårlig interface, en data struktur som ikke effektivt lar deg gjøre det du ønsker å gjøre, noe som gjør det vrient å teste.

Alle disse tingene er noe de fleste er kjente med, og utfallet er at vi lærer hva som funker og ikke funker. Vi tar erfaringene med oss i fremtidig kode vi skriver.

AI har ikke dette problemet og vil generere seg rundt problemet. Resultatet blir at vi bygger mer logikk på toppen av en dårlig løsning. Dette er noe av grunnen til at AI øker toleransen for dårlig kode. Man kan alltids generere seg rundt problemet, men i prosessen så skaper man flere problemer.

Man kan argumentere for at dette problemet ikke er noe nytt - og det er jeg enig i. Før AI hadde vi utviklere som kopierte fra StackOverflow. Forskjellen er at nå så kommer koden inn i editoren og passer inn. Med StackOverflow (og andre kilder) så måtte man som regel tilpasse litt.

Noen, inkludert GitHub, vil argumentere at AI i seg selv er et læringsverktøy til tross for at det ikke brukes slik i praksis. Noe som kunne vært flott, men en studie fra Purdue University fant at både koden og svarene til disse verktøyene er så som så sammenlignet med StackOverflow:

"Our results show that 52% of ChatGPT-generated answers are incorrect and 62% of the answers are more verbose than human answers. Furthermore, about 78% of the answers suffer from different degrees of inconsistency to human answers."

«De vil se veldig produktive ut, men på sikt vil de gjøre aktiv skade på kodebasen og bedriften.»

Ledere bør være forsiktige

Det å måle utviklerproduktivitet har alltid vært noe ledere har hatt problemer med. Man har prøvd mye rart opp igjennom årene, alt fra å telle story points, antall linjekoder, antall oppgaver fullført, etc. Dette er noe som vil bli vanskeligere nå som utviklere bruker AI i det daglige.

Takket være AI så vil nå utviklere som ikke er klare for å ta ansvar, ville kunne få det, om man måler feil. De vil se veldig produktive ut, men på sikt vil de gjøre aktiv skade på kodebasen og bedriften - selv om de kanskje ikke mener det.

Her må ledere også være klar over at dette ikke bare gjelder juniorutviklere, men også utviklere som ikke bryr seg om kvalitet. Ledere må derfor være forsiktige med hvem de setter som teknisk ansvarlig for både teams og kodebaser.

Oppfordrer alle ledere til å lese denne artikkelen av Dan North som en advarende fortelling relatert utviklerproduktivitet.

Det er for mange ledere som mangler innsikt i hvordan teamet gjør det. Jeg har hatt ledere si at de har "null legacy" i selskaper hvor det har vist seg at mesteparten av koden de har ikke kan betraktes som annet enn legacy. Utviklerteam bør være åpne, og vi bør gjøre en bedre jobb å eksponere helsen til kodebasen og prosessen vår.

Min anbefaling er å begynne å ta i bruk DORA metrikkene, hvor ledere kan få trender over tid og teamene får innsikt i sin egen utvikler prosess. Da får man en helsesjekk på hvordan teamet lever, og man får sett hvordan dette utvikler seg over tid.

Her må jeg påpeke at disse metrikkene skal bare måles på team nivå, ikke for individer, og ledere må ta seg tid til å forstå hva de betyr. Hver gang jeg nevner "metrikker" så er det en viss prosentandel som automatisk er skeptiske.

Vedlikeholdbarhet med AI

Noen vil kanskje tro at jeg er anti-AI, men det er ikke tilfellet. Det er ett godt verktøy som har sine bruksområder. Denne artikkelen handler ikke om å ta CoPilot og ChatGPT fra noen - noe jeg ikke tror er realistisk uansett.

Vi kan ikke styre valg som individer tar. Selv om studier og andre kodere sier at man ikke skal kopiere ukritisk fra AI-verktøy, så vil det være mer enn nok utviklere som fortsatt gjør det. Vi lurer oss selv om vi ikke godtar at dette vil skje. Det er derfor viktig at vi setter inn god praksis på team nivå.

Her er noen konkrete forslag til praksiser som teams kan da i bruk:

  • Mer fokus på kvalitet i code reviews: Ingen flere LGTM type code reviews. Man må bruke tid på å gi gode tilbakemeldinger.
  • Putte mer arbeid inn i å teste mer på flere nivåer: Gode tester gjør ting lettere å refaktorere senere samt være en helsesjekk på design. Er en test dårlig så er det som oftest fordi koden er dårlig.
  • Bruk analyseverktøy som kjører i pipelinen: Alle verktøy som gir tilbakemeldinger på kodekvalitet og kode-helse er flott.
  • Ha regelmessige samlinger av hele teamet der de sammen gjør code review av deler av applikasjonen utenfor pull request-prosessen: Dette hjelper teamet å identifisere problemer, men også for å bygge en samlet forståelse av hva kvalitet betyr for dem.
  • Bruk mer av tiden på par eller gruppeprogrammering: Terskelen for klipp-og-lim er noe høyere når en kollega ser på.
«Løsningen er ikke å prøve å stoppe bruken av AI.»

Mer av de samme gamle problemene

AI kommer ikke med så mange nye problemer med tanke på utvikling. Klipp-og-lim-kode var alltid ett problem. Det at ledere ikke vet hvordan de skal måle utviklerproduktivitet har alltid vært ett problem. Det at utvikler-teams mangler god praksis for å opprettholde god kvalitet har alltid vært ett problem. Det er ingenting nytt, men AI gjør problemene mer synlig.

I Lekanger sin artikkel så argumenteres det for at tiden spart på generere kode kan bli brukt til å lære mer og bedre koden. Dette er noe jeg er 100% enig i. I praksis frykter jeg for at det ikke er nok, og behovet for gode praksiser på team nivå vil øke.

Alle verktøy må brukes med måte, og studiene tilsier at dette ikke er slik de blir brukt i dag. Her bør utviklere gå i seg selv og reflektere over deres bruk av disse verktøyene, samt starte samtaler internt i teamene. Ledere bør putte inn mer arbeid for å få innsikt i helsen til teamene og deres kodebaser.

Løsningen er ikke å prøve å stoppe bruken av AI. Vi må akseptere at vi lever i en verden hvor utviklere bruker disse verktøyene, men også tilpasse oss for å unngå negative utslag på grunn av dem.

Jeg ønsker å avslutte denne artikkelen ved å sitere slutten til GitClear sin studie:

"How will AI Assistants and Copilot transform what it means to be a developer? There's no question that, as AI has proliferated, we have entered an era where code lines are added faster than ever. The better question for 2024: who's on the hook to clean up what’s left afterward?"