Test og dokumentation når AI bliver en del af udviklingsarbejdet

Der er en samtale, jeg ofte ser i teams. Hver gang med et nyt team, men næsten ordret den samme replik:

“Vores udviklere bruger Copilot og ChatGPT alligevel. Skal vi ikke bare lade dem gøre det?”

Det er et fair spørgsmål. Det er også det forkerte spørgsmål.

Den rigtige diskussion handler ikke om, hvorvidt udviklerne må bruge AI. Det skib er for længst sejlet. Den rigtige diskussion handler om, hvordan teamet sikrer, at den kode, der ender i produktion, er testet, dokumenteret og forstået af de mennesker, der har ansvaret for den.

Hvor AI rykker noget i en udviklingsproces

Den klassiske argumentation er, at AI sparer tid. Det er sandt for nogle opgaver. Et udkast til en unit-test, en oversættelse af et regex, en hurtig skitse til en CRUD-endpoint, det går hurtigere med en AI-assistent end uden.

Det er også sandt, at AI introducerer nye risici, som de fleste teams ikke har en proces for. Kode, der ser fornuftig ud, men som rammer et bibliotek på en måde, der ikke matcher den faktiske API. Variabelnavne, der er ren fiktion. Funktioner, der “ligner” noget fra et tutorial-eksempel, men som ikke håndterer fejl ordentligt.

Det er ikke fordi AI er dårlig. Det er fordi en autocomplete med stor selvsikkerhed er en farlig kombination, hvis ingen kontrollerer outputtet.

Tre konkrete ting, et team kan gøre i næste sprint

Lav en kort skreven aftale om, hvad AI må bruges til. Ikke en politik på 14 sider. Et internt notat på en halv side, der besvarer: må vi plotte virksomhedens kildekode ind? Må vi bruge kundedata i prompts? Hvilke værktøjer er godkendt? Hvilke er ikke? Når der ikke står noget, finder folk selv ud af det, og det er sjældent ensartet.

Indfør en lille markør i pull requests. Det kan være en checkbox eller et tag: “Indeholder denne PR kode, der primært er genereret med AI-assistance?” Det er ikke for at fordømme det. Det er for at gøre det synligt for reviewerne, så de ved, at de skal være ekstra opmærksomme på de steder, hvor AI-genereret kode oftest fejler: edge cases, fejlhåndtering og afhængigheder, der ikke findes.

Tilføj en test-gate, der ikke kan omgås. Hvis et team har lavet det normale arbejde med unit tests, integration tests og linting, så holder AI-genereret kode sig typisk inden for rammerne. Det er, når test-disciplinen er svag, at man pludselig får produktionsfejl, ingen kan reproducere lokalt. AI gør ikke svagheder værre. AI udstiller dem hurtigere.

Hvad med dokumentation?

Dokumentation er nok det sted, hvor AI giver mest værdi med færrest risici. En udvikler, der har skrevet en service, kan bede en model om at lave et udkast til en README, en API-beskrivelse eller en post i en intern wiki. Det er hurtigt, og kvaliteten er ofte god nok som første draft.

Men der er en faldgrube. Modellen finder på, hvad det her gør, hvis dokumentationen ikke følges af et tjek mod den faktiske kode. Et typisk eksempel er en intern API-beskrivelse, lavet med AI-assistance, der beskriver en endpoint, som ikke findes. Den kan være kopieret fra et tidligere udkast, hvor den havde været under overvejelse. Hvis ingen fanger det, kan der gå længere tid, før en kollega forsøger at kalde den.

Lærdom: AI er glad for at fylde huller ud. Det er én af modellens største styrker, men også det punkt, hvor menneskelig kontrol skal være tættest på.

Test, fortsat

Et område, jeg gerne så mere arbejde i, er test-generering. AI er ret god til at foreslå unit-tests for kode, der er ren og struktureret. Den er noget dårligere til at finde de tests, der virkelig betyder noget: de tests, der dækker, hvad der sker, når brugeren gør noget uventet, eller når en afhængighed svigter midt i en transaktion.

Det skal et menneske stadig tænke over. Modellen kan hjælpe med at skrive testen, når man har defineret den. Den er ikke god til selv at finde den.

Tre spørgsmål inden teamet skalerer brugen

Når et team er gået fra “vi prøver lidt af” til “vi bruger det her dagligt”, bør de lederholde tre samtaler:

Hvad sker der, hvis vores AI-leverandør ændrer model eller priser? Er vi afhængige af præcis den output-kvalitet, vi får i dag, eller har vi en proces, der overlever et leverandørskift?

Hvordan håndterer vi kode, vi ikke selv ville have skrevet sådan? AI-genereret kode følger ofte mønstre, der er almindelige i træningsdataene, men som ikke nødvendigvis passer til teamets stil. Skal det rettes, eller skal stilguiden tilpasses?

Hvem har ansvaret, hvis en fejl skyldes AI-genereret kode? Det er ikke en bekvem samtale, men den bør holdes, før noget går galt, ikke bagefter.

Hvad andre kan lære af

Hvis I vil have flere konkrete eksempler på, hvordan danske teams har grebet det her an, og hvad de er stødt på undervejs, kan I læse en artikel om AI-implementering i danske softwareteams, som indeholder mere detaljerede observationer fra praksis.

Det vigtige er, at I ikke venter, til alt er afklaret, før I begynder. Men I bør heller ikke håbe på, at det løser sig selv. Det skal nogen tage ansvar for. Det er ikke et værktøjsspørgsmål. Det er en udviklingsdisciplin.