Hva AI kan brukes til i utvikling: fra skisse til produksjon

De fleste tenker på AI i utvikling som autofullføring av kode. Det er den minste delen. Størst effekt får små team der kunstig intelligens (KI) brukes før koden, i skisser, mockups og krav, og etter koden, i tester, review og dokumentasjon. Her er hele løpet, med hva jeg mener er modent nok til å bruke i dag.

Oversikten

Resten av artikkelen går gjennom stegene i rekkefølge. Vil du bare ha svaret, holder tabellen.

Krav og planlegging

Møtenotater, en e-post fra kunden og tre stikkord på en lapp. Det er råmaterialet for de fleste oppgaver i et lite team. AI gjør det til brukerhistorier med akseptansekriterier på noen minutter, og det er bra. Det som er bedre, er å be verktøyet finne hullene: hvilke tilfeller er ikke nevnt, hvilke begreper er brukt om to forskjellige ting, hva skjer når data mangler.

Resultatet er ikke ferdige krav. Det er en liste med spørsmål dere stiller kunden før noen koder. Det er der tiden spares.

Skisser og mockups

Dette er det bruksområdet som har endret seg mest det siste året. Fra en beskrivelse i vanlig norsk lager verktøy som Figma Make, v0 og Lovable en klikkbar prototype på minutter. Claude kan gjøre det samme rett i samtalen. Det som før krevde en designer og to dager, tar nå en time, og det kan gjøres i møtet med kunden.

Bruk det til å avklare. «Mener du noe sånt?» med en prototype foran seg gir et helt annet svar enn en kravliste. Lag tre varianter, la kunden velge, kast de to andre.

Design og brukergrensesnitt

AI er god hjelp til det håndverksmessige i design: holde seg til et designsystem, foreslå tokens for farger og avstander, sjekke kontrast og tilgjengelighet, og skrive tekstene i grensesnittet så de er korte og konsekvente. Gi verktøyet designsystemet deres som kontekst, så følger det reglene bedre enn mange mennesker gjør.

Det AI ikke gjør, er å velge hva som skal bygges, eller å vite at kundene deres er elektrikere på en byggeplass med hansker på. AI foreslår det vanlige. Trenger dere det riktige, må noen som kjenner brukerne bestemme. Her går grensen mellom hjelp og hype.

Koding

Selve kodingen har jeg skrevet tre artikler om, så kort her: et lite team får mest ut av én agent i terminalen (Claude Code, Codex eller Copilot Agent) pluss autofullføring i editoren. Agenten tar oppgaver som berører flere filer, med egen plan og egne testkjøringer. Mennesket planlegger og reviewer.

• Slik kommer teamet i gang med AI-assistert utvikling: verktøy, pilot, hva dere måler.
• Arbeidsflyt: planlegg, la AI skrive, du reviewer: steg for steg.
• Hva AI er dårlig på i kode, og hvordan du sikrer deg: de seks vanligste feilene.

Testing

Testing er det mest undervurderte bruksområdet, og det jeg oftest anbefaler team å starte med. Fire ting fungerer godt:

1. Enhetstester for kode som finnes. Pek agenten på en modul uten tester og be om tester som dekker grensetilfellene. Det er kjedelig arbeid ingen gjør frivillig, og AI gjør det på minutter.
2. Ende-til-ende-tester. Beskriv brukerreisen i vanlig språk, og la agenten skrive Playwright-testen og kjøre den til den er grønn. Tester som før var for dyre å skrive, blir plutselig rimelige.
3. Testdata. Realistiske, varierte og syntetiske datasett med norske navn, adresser og tegnsett, uten én eneste ekte kunde.
4. Utforskende testing. «Her er funksjonen. Hvilke ti ting kan gå galt?» Listen inneholder som regel tre ting dere ikke hadde tenkt på.

Den ene advarselen: en test AI har skrevet kan være grønn uten å teste noe. Be om at testen skrives først og vises feilende før koden rettes. Det er beskrevet i Hva AI er dårlig på i kode.

Code review

La AI være første reviewer på hver pull request, før et menneske leser. Den fanger det mekaniske: glemt feilhåndtering, hemmeligheter i kode, avvik fra konvensjonene, SQL satt sammen med strenger, manglende tilgangskontroll på et nytt endepunkt. GitHub Copilot har det innebygd, og en agent kan gjøre det samme med en fast sjekkliste fra repoet.

Det den ikke fanger, er om løsningen løser riktig problem, og om den passer inn i det teamet skal bygge neste måned. Det er fortsatt menneskets jobb. Teamene som får mest ut av AI-review, bruker den tiden den sparer til grundigere menneskereview, ikke til mindre.

Dokumentasjon og gammel kode

Her sparer AI mest tid i etablerte systemer. Tre bruksområder:

• Forklare kode ingen forstår. Modulen som ble skrevet av en som sluttet i 2019. Be agenten lese den og forklare hva den gjør, hvilke antakelser den bygger på og hvor den kalles fra. Det som før tok en dag med kaffe og debugger, tar en time.
• Skrive dokumentasjon. README, API-dokumentasjon, kommentarer til offentlige funksjoner. Be om det som en del av hver oppgave, så blir det faktisk gjort.
• Planlegge migreringer. Fra én rammeverksversjon til en annen, fra ett bibliotek til et annet. AI lager en oversikt over alt som må endres og i hvilken rekkefølge, og kan ta de mekaniske delene selv.

Fallgruven er dokumentasjon som beskriver hva koden gjør, linje for linje. Det kan alle lese selv. Be om hvorfor: hvilke beslutninger ble tatt, og hva skjer hvis man endrer dem.

Drift og feilsøking

En feilmelding på tre hundre linjer, en logg fra i natt, et stacktrace fra et bibliotek ingen kjenner. Lim det inn og be om en forklaring og tre mulige årsaker. Det treffer ofte, og det er en god start selv når det bommer. Hendelsesrapporter etter en feil i produksjon skriver AI godt fra en tidslinje med stikkord.

Hva som ikke egner seg ennå

• Arkitekturvalg. AI gir et overbevisende svar på «skal vi bruke mikrotjenester?» uten å vite noe om teamet, kundene eller budsjettet. Bruk den til å liste alternativer og konsekvenser, ikke til å bestemme.
• Ytelsesoptimalisering uten måling. Forslagene høres riktige ut og gjør ofte ingen forskjell. Mål først, så spør.
• Sikkerhetskritisk kode uten review. Autentisering, betaling, tilgangskontroll. AI kan skrive utkastet, men her må et menneske som kan feltet lese hver linje.
• Alt som krever kontekst ingen har skrevet ned. Verktøyet vet bare det som står i repoet og det du forteller det. Er kunnskapen bare i hodet på to personer, får du svar som ser riktige ut og er feil.

Hvor dere starter

Velg ett steg fra tabellen øverst, det der teamet taper mest tid i dag. For de fleste små team er det testing eller gammel kode, ikke koding. La én utvikler bruke verktøyet på det i to uker, og mål før og etter med DORA-metrikkene. Virker det, tar dere neste steg.

Vil dere ha hjelp til å finne de to–tre stegene som gir mest hos dere, er det akkurat det AI-kartleggingen gjør.