AI i utviklingsteam: nytte, fallgruver og refleksjoner

Refleksjoner om AI i utviklingsteam

Photo by Volodymyr Dobrovolskyy on Unsplash

Bruken av AI i utviklingsteam øker raskt. Det siste året har jeg både observert og selv brukt en rekke av de nye verktøyene, og det har gitt meg noen refleksjoner jeg ønsker å dele.

Jeg skal ikke påstå for mye om hva som er "bra" eller "dårlig" – det finnes allerede flinke folk som forsker på dette og gjør grundige vurderinger. For eksempel holdt Nils Brede Moe og Jan Henrik Gundelsby en veldig bra presentasjon på Javazone i år: “Fremtidens produktutvikling med AI – innsikter fra norsk forskning”. De presenterte forskningsbaserte refleksjoner rundt bruken av AI i utviklingsteam. Jeg anbefaler å se den. For meg var den en naturlig fortsettelse av presentasjonen de holdt på Javazone 2024: “10 resultater fra 10 år med forskning på team” som var av like høy og god kvalitet.

Den umiddelbare verdien

Den mest åpenbare verdiøkningen er hvor lett det er å spørre en LLM om ting man ellers ville brukt tid på å lete i dokumentasjon eller søke opp på Stack Overflow. Her er den ganske tydelig overlegen (Liu, J., et al. 2023).

Selv er jeg gammel og treg og ganske glad i god dokumentasjon. Jeg liker å sette meg ned med en kruttsterk kaffi og grave i dokumentasjonen, og det vil jeg alltid foretrekke når jeg virkelig skal forstå noe i dybden. Men av og til er det ikke der man trenger å bruke tiden. Av og til trenger man kun et overordnet blikk. Kanskje man bare skal inn og fikse en liten ting. Kanskje man trenger en rask henvisning til et konkret brukseksempel. Kansje man ikke jobber eller skal jobbe mye med denne konkrete problemstillingen. Det finnes mange gode grunner til å ikke behøve kjenne til alle detaljer for å få noe gjort. I disse tilfellene er genAI genialt.

For meg minner GenAI dialoger om da Stack Overflow kom på markedet. Før dette måtte vi tråle mailingtråder eller forumtråder, til og med bøker 🙀, og det var helt normalt å bruke timer på å finne frem til gode svar på det man lurte på. Så kom Stackoverflow. Game changer. Plutselig hadde vi et crowdsourcet verktøy som ga raske og presise svar på konkrete tekniske spørsmål. Jeg ser litt på ChatGPT og andre dialogbaserte LLM-er som en naturlig forlengelse av det skiftet. I dag er det få jeg kjenner som fortsatt bruker stackoverflow som hjelpemiddel. Ting beveger seg raskt.

Spør godt, få gode svar

Photo by bruce mars on Unsplash

Etter å ha brukt LLMer en liten stund nå så har jeg gjort meg noen erfaringer. Første erfaring er at kvaliteten på svarene står og faller på hvor godt man formulerer spørsmålet. Det lønner seg å være presis:

• Ta med versjonsnummer på rammeverket man spør om.

• Beskriv teknologien og rammene rundt problemet. For eksempel hvilket språk og versjon, hva deployment target er. Andre tekniske begrensninger. Dette er ting som språkmodellene lett faktoriserer inn.

• Vær tydelig på hva du egentlig prøver å løse. Jo bedre du beskriver hva du ønsker at output skal være jo mindre rom er det for feil. Dette er kanskje litt lite konkret. Men prøv deg frem. Gjør små iterasjoner. Ikke lag for store ting i et jafs. Da kan man fort få problemer.

Disse grepene øker sjansen for at svaret faktisk er relevant – og ikke bare "nesten riktig".

Agenter — kraftig, men ikke uten problemer

I det siste har agenter — enten som copiloter i Claude eller GPT, eller som generatorer som f.eks. Vercel sin v0 — blitt en kraftig hjelp i utviklingsarbeidet. De er imponerende: de fikser mye boilerplate, og gjør det raskt mulig å prototype en idé eller komme i gang med et konsept. v0.dev synes jeg er spesielt sterk for rask prototyping, og copilot-agenter er også spennende å jobbe med. Jeg har lekt en del med begge, og blitt imponert over hva de får til.

Samtidig kommer de til kort når målet er produksjonsklar kode. Du må teste løsningen, verifisere at den gjør det den skal, og sørge for at den faktisk fungerer i praksis. Ofte ender dialogen med agenten i at man retter feil modellen selv har introdusert — alt fra små ulikheter i feltnavn eller struktur til kompileringsfeil. Påpeker man det, fikser agenten det som regel, og så går man videre til neste problem, helt til man til slutt er i mål.

Dette er en måte å få jobben gjort på — man kommer frem til slutt — men prosessen kjennes annerledes enn det jeg er vant med. Og et par ting bekymrer meg:

Tid og flyt

For det første opplever jeg at dette ikke er en effektiv bruk av min tid. For noen som ikke programmerer som sin hovedoppgave, men som heller vil beskrive hva som skal lages, gir det utvilsomt mening. For meg som virkelig liker å programmere, og som trives i flow med musikk på øret, er det mindre effektivt og mindre tilfredsstillende.

I stedet for å kode selv, ender jeg opp med å småkrangle med en språkmodell (som av og til hallusinerer), vente på at den gjør endringer, og så manuelt gå gjennom og fikse feilene som gjenstår. Det bryter flyten og reduserer arbeidsgleden.

Eierskap og team

En annen viktig side er eierskap. Når utviklere selv skriver koden, skaper det naturlig eierskap og ansvar i teamet. Dersom mye kode er generert av en agent, reduseres dette eierskapet — noe som kan være negativt for et utviklingsteam.

Forskning viser at felles eierskap til kode påvirker ansvarlighet, kunnskapsdeling og kvalitet positivt (Koana et al., 2024; Zabardast et al., 2023). Når ansvarsområder og kodeeierskap blir uklare, øker risikoen for teknisk gjeld og fragmentert kunnskap i teamet (Sundelin et al., 2024). Noe som fører til redusert fart og flyt, og en ond sirkel er utformet.

Gode råd for AI-agenter i team

Her er det jeg tror er lurt å tenke på når man skal bruke AI-agenter i et utviklingsteam

1. Definér eierskap
   Bruk f.eks. CODEOWNERS-filer eller pull-request-regler slik at menneskelige eiere alltid har siste ord.

2. Ha obligatorisk gjennomgang
   All AI-generert kode skal reviewes og testes som om en ekstern bidragsyter hadde skrevet den.

3. Vær presis i prompt og iterasjon
   Gi agenten tydelige rammer (versjoner, rammeverk, teknologier), og aksepter at prosessen er iterativ: generer → test → forbedre.

4. Bevar utviklerens flyt
   Bruk agenter på repetitive oppgaver. For oppgaver du liker og får energi av, gjør dem selv.

5. Bevisst forhold til opphav
   Gå gjennom agent-generert kode i teamet slik at flere forstår den. Ikke la ansvaret ende opp hos én person + agent. Vær åpen om at “denne koden er det claude som har skrevet“. Det kan skape gode erfaringer og samtidig få en felles forståelse av hvordan best utnytte agenter.

6. Mål effekten
   Følg med på tid brukt, feilrate, teknisk gjeld og “hotfixes” i agent-generert kode. Bruk data for å vurdere om agenten faktisk sparer tid og forbedrer kvalitet.

Oppsummert

• Agenter gir gode muligheter for rask prototyping og effektiv generering av repetitivt arbeid.

• De reduserer kanskje utviklerens følelse av eierskap til koden, noe som kan være negativt for et team.

• Arbeidsprosessen kan bli mindre effektiv og mindre tilfredsstillende for erfarne utviklere som trives i flyt.

• Mange små, nesten-korrekte feil gjør verifisering nødvendig — det går sjelden uten manuell endring til produksjon.

Bruk AI til det du ikke finner glede i

Jeg ser på det slik: på samme måte som jeg ikke vil at AI skal spille gitar for meg, male for meg eller gjøre andre ting jeg virkelig finner glede i, vil jeg heller bruke AI til oppgaver jeg bare ønsker å få løst. På den måten kan jeg bruke tiden min der det virkelig teller – der jeg får mest utbytte og arbeidsglede.

AI blir da et verktøy som frigjør både tid og mental kapasitet, i stedet for å ta over det jeg faktisk liker å gjøre selv. Jeg ønsker at AI skal håndtere de oppgavene jeg ikke vil bruke tid på, slik at jeg selv kan fokusere på det jeg trives best med, og det som gjør meg produktiv og lykkelig på jobb.

Referanser

• Liu, J., et al. (2023). Which is a Better Programming Assistant? A Comparative Study between ChatGPT and Stack Overflow. arXiv:2308.13851

• Koana, E. R. S., et al. (2024). Examining Ownership Models in Software Teams: A Systematic Literature Review. arXiv:2405.15665

• Zabardast, E., et al. (2023). Exploring the Relationship Between Ownership and Contribution Alignment and Code Technical Debt. arXiv:2304.02140

• Sundelin, M., et al. (2024). Governing the Commons: Code Ownership and Code-Clones in Large-Scale Software Development. arXiv:2405.15866 

• Mende, C. (2023). Code Ownership: Keeping the balance between structure and flexibility. mende.io