Slik kommer teamet i gang med AI-assistert utvikling
En praktisk plan for små utviklingsteam som vil ta i bruk AI-verktøy: hvilke verktøy, hvem som starter, hva dere måler, og feilene du bør unngå den første måneden.
De fleste team som «har prøvd AI» har gjort det på egen hånd, én utvikler om gangen, uten plan. Resultatet er at noen bruker verktøyene hver dag, andre har gitt opp, og ingen vet om det hjalp. Dette er planen jeg bruker for å få et lite team i gang på fire uker.
Start med én oppgave, ikke hele teamet
Ikke rull ut et verktøy til alle samtidig. Velg én utvikler som er nysgjerrig, og én type oppgave som er vanlig og avgrenset: skrive tester for eksisterende kode, lage et nytt endepunkt etter samme mønster som de andre, eller skrive migrasjoner.
Den utvikleren bruker verktøyet på den oppgaven i to uker og noterer tre ting hver dag: hva som gikk fort, hva som gikk galt, og hva som måtte rettes i review. Det er pilotens hele rapport.
Velg verktøy etter arbeidsflyt, ikke etter hype
Det finnes tre typer AI-verktøy for utviklere, og de passer til forskjellige ting:
| Type | Eksempler | Passer til |
|---|---|---|
| Autofullføring i editoren | GitHub Copilot, Cursor Tab | Rutinekode, boilerplate, tester |
| Chat i editoren | Cursor, Copilot Chat, Continue | Forklare kode, foreslå endringer i én fil |
| Agent i terminalen | Claude Code, Codex, Copilot Agent | Oppgaver som berører flere filer, med egen plan og egne kjøringer |
Små team får mest ut av én agent i terminalen pluss autofullføring. Chat i editoren er fint, men agenten gjør det samme og mer. Begynn med én av hver, ikke tre av hver.
Retningslinjer på én side
Før flere enn én person bruker verktøyet, skriv en retningslinje på én side. Ikke mer. Den skal svare på:
- Hvilken kode og hvilke data kan sendes til verktøyet? (Normalt: all egen kode, aldri kundedata, aldri hemmeligheter.)
- Hvem er ansvarlig for koden AI skrev? (Alltid den som sendte PR-en.)
- Hva skal stå i en PR der AI har skrevet mye? (Hva som ble generert, og hva som er sjekket manuelt.)
- Hvilke verktøy er godkjent, og hvem godkjenner nye?
Les mer om personvern og avtaler i Retningslinjer og personvern før dere slipper AI løs.
Mål før og etter
Det eneste som avgjør om dette var verdt det, er om teamet leverer bedre. Mål fire tall før piloten og igjen etter fire uker:
- Hvor mange ganger dere deployer per uke
- Hvor lang tid det tar fra en commit til den er i produksjon
- Hvor stor andel av endringene som må rettes etterpå
- Hvor lang tid det tar å rette en feil i produksjon
Det er DORA-metrikkene. Slik begynner du å måle dem uten nytt verktøy.
Feilene de fleste gjør den første måneden
- Alle får tilgang samtidig. Da får du tjue meninger og null data.
- Ingen ser på det som blir rettet i review. Det er der du lærer hva verktøyet er dårlig på.
- Verktøyet brukes på det vanskeligste først. Start med det kjedelige og forutsigbare.
- Ingen oppdaterer retningslinjen. Etter piloten vet dere mer. Skriv det inn.
- Det måles ikke. Da blir evalueringen en diskusjon om følelser.
Etter fire uker har dere én utvikler som kan verktøyet, en retningslinje som er testet, og fire tall som sier om det hjalp. Da er dere klare for resten av teamet. Les Arbeidsflyt: planlegg, la AI skrive, du reviewer for neste steg.
- AI-assistert utvikling
- Copilot
- Claude Code
- Cursor
- utviklingsteam
- AI-verktøy
Usikker på hvor dere skal begynne?
Book 30 minutter. Vi går gjennom hvor dere står og hva som er det første fornuftige steget. Ingen forpliktelser, ingen salgstale.
Book 30 minutter gratis