AI-koding har på kort tid gått fra å være en smart skrivehjelp til å bli en ny måte å organisere utviklingsarbeid på. Den første bølgen handlet om forslag i editoren: fullfør denne linjen, skriv denne funksjonen, forklar denne feilmeldingen. Den nye bølgen handler om agenter som kan få et mål, lese en kodebase, gjøre endringer, kjøre tester, lage pull request og forklare hva de har gjort. Det er en annen kategori verktøy.
Dette betyr ikke at utviklere plutselig blir overflødige. Det er en for enkel fortelling, og ofte en dårlig fortelling. Det som faktisk skjer er mer interessant: rollen flytter seg oppover i arbeidskjeden. Mer tid går til å definere problemet, vurdere løsningen, sikre at data ikke deles feil, forstå arkitektur, prioritere teknisk gjeld og kontrollere at endringen faktisk er trygg. Mindre tid går til å skrive hver enkelt linje for hånd.
For noen utviklere føles dette frigjørende. For andre føles det truende. Begge reaksjoner er forståelige. Når en agent kan bygge en modul, migrere et API eller rydde i testfeil på minutter, blir det vanskelig å late som om arbeidsmåten ikke er endret. Men det blir også tydeligere hvilke deler av utviklerfaget som aldri bare har handlet om tastetrykk.
Den viktigste lærdommen for norske virksomheter er derfor ikke å kaste seg ukritisk over alle nye AI-verktøy. Den er å bygge en arbeidsform der AI kan brukes uten at kildekode, kundedata, hemmeligheter, sikkerhetsinformasjon og forretningslogikk lekker til feil sted. Kodeagenter kan bli svært nyttige. De kan også bli en ny kanal for datadeling, feilslutninger og skjult teknisk risiko hvis de innføres uten styring.
Fra kodefullføring til agentisk utvikling
Det er lett å undervurdere hvor stor forskjellen er mellom en kodeassistent og en kodeagent. En assistent venter vanligvis på at utvikleren skriver noe. Den fullfører, forklarer eller foreslår. En agent kan få en oppgave som ligner mer på en liten arbeidsordre: finn feilen, endre disse filene, oppdater testen, forklar risikoen, lag et forslag til pull request.
OpenAI beskriver Codex som en kodeagent som kan arbeide på flere oppgaver parallelt og ta hele oppgaver fra prompt til endring. I Codex-dokumentasjonen beskrives både lokale klienter, IDE-utvidelse, CLI, web og skydelegerte oppgaver som deler av samme arbeidsflate. Det er et signal om at verktøyet ikke lenger bare er en editorfunksjon. Det blir et lag rundt hele utviklingsprosessen.
Anthropic bruker enda sterkere språk i rapporten "When AI builds itself". Der beskriver selskapet hvordan Claude gradvis har gått fra å foreslå kode til å skrive og endre kode selv, og hvordan en stadig større del av produksjonskode internt tilskrives Claude. Anthropic skriver at mer enn 80 prosent av koden som merges inn i deres egen kodebase i mai 2026 var skrevet av Claude. Det tallet bør ikke leses som en garanti for hva andre organisasjoner kan oppnå, men det viser hvor raskt grensene flyttes hos aktører som allerede jobber tett med slike systemer.
Microsoft peker i samme retning. På Build 2026 la selskapet vekt på agentiske apper, GitHub Copilot i mer selvstendige arbeidsflater og Scout som en personlig arbeidsagent. Det interessante er ikke bare at Microsoft sier "AI" mange ganger. Det interessante er at leverandørene prøver å flytte AI fra chatvinduet og inn i selve arbeidsflyten.
For utvikling betyr dette at spørsmålet endres. Før spurte vi: "Kan AI hjelpe meg med å skrive denne funksjonen?" Nå spør vi: "Hvilke deler av utviklingsløpet kan delegeres, og hvilke deler må fortsatt eies av mennesker?"
Det som automatiseres først
AI-kodeagenter er sterkest der oppgaven har tydelig kontekst, klare rammer og testbare resultater. Det betyr at noen typer arbeid blir mye mer automatiserbare enn andre.
Boilerplate forsvinner først. CRUD-endepunkter, enkle skjemaer, standardkomponenter, repetitiv validering, migrering mellom like mønstre og oppdatering av dokumentasjon er typiske oppgaver der agenter kan spare mye tid. Det betyr ikke at resultatet alltid er godt, men at mennesket ofte slipper å bruke energi på det mest mekaniske.
Deretter kommer vedlikeholdsarbeid. Mange kodebaser har små feil, gamle avhengigheter, ufullstendige tester, inkonsekvent naming, døde filer og dokumentasjon som ikke følger endringene. Dette er arbeid mennesker ofte utsetter fordi det er kjedelig og fragmentert. En agent kan tåle kjedsomhet bedre enn et menneske. Den kan også jobbe parallelt på flere små oppgaver.
Migreringer blir også en stor kategori. Når et rammeverk endrer API, når en databaseklient byttes, eller når et designsystem må oppdateres på tvers av mange filer, er arbeidet ofte stort, men ikke nødvendigvis kreativt. AI-agenter kan gjøre første pass, mens mennesker vurderer arkitektur, regressjoner og edge cases.
Det som ikke forsvinner like raskt er produktforståelse. En agent kan skrive en løsning på en oppgave, men den vet ikke alltid om oppgaven er riktig. Den kjenner ikke nødvendigvis historikken bak en kundeklage, de uuttalte begrensningene i en bransje, sikkerhetskravene i en avtale eller hvorfor en tidligere teknisk beslutning ble tatt. Den kan lese dokumentasjon, men den forstår ikke ansvar på samme måte som et menneske i en organisasjon.
Derfor bør utviklere ikke bare spørre "hva kan agenten skrive?" De bør spørre "hva kan agenten trygt få ansvar for?"
Utvikleren blir mer redaktør, arkitekt og kontrollør
Når AI skriver mer kode, blir utvikleren mer som en kombinasjon av redaktør, arkitekt og kontrollør. Det høres kanskje mindre romantisk ut enn klassisk programmering, men det kan være mer verdifullt.
Redaktørrollen handler om å formulere oppgaver godt. En dårlig prompt gir ofte en dårlig løsning, men det dypere problemet er ikke prompten. Det er at problemet ikke er forstått. En dyktig utvikler kan skrive en oppgave som inneholder riktig kontekst, avgrensning, akseptansekriterier, testkrav og risikopunkter. Da blir agenten langt mer nyttig.
Arkitektrollen handler om å se helheten. En agent kan foreslå en løsning som virker lokalt, men som bryter systemets retning. Den kan legge til en ny helper der prosjektet allerede har en etablert modul. Den kan kopiere et mønster som finnes, men som egentlig burde fases ut. Den kan lage en "rask" løsning som øker teknisk gjeld. Utvikleren må forstå hva som passer inn.
Kontrollørrollen handler om kvalitet og ansvar. Agenten kan kjøre tester, men den kan også skrive tester som bekrefter sin egen antakelse. Den kan lage en migrering som passer eksempeldata, men feiler på gammel produksjonsdata. Den kan bruke en tredjepartsbibliotek uten å vurdere lisens, vedlikehold, sårbarheter eller databehandling. Mennesket må fortsatt eie vurderingen.
Dette er en viktig nyanse. AI-koding gjør ikke utviklere uviktige. Den gjør svake prosesser mer synlige. Team uten god kodegjennomgang, testdisiplin, sikkerhetsrutiner og produktforståelse kan få fart, men også fart i feil retning.
Datadeling er ikke en fotnote
For Kunnskapsrom er dette kanskje det viktigste punktet: AI-kodeagenter er ikke bare utviklingsverktøy. De er også datatjenester.
Når en agent får tilgang til en kodebase, får den ofte innsikt i mer enn kode. Den kan se API-nøkler hvis de ligger feil. Den kan se kundespesifikke integrasjoner. Den kan lese interne kommentarer. Den kan se forretningslogikk, prisregler, sikkerhetsmekanismer, datamodeller og tekniske spor etter kunder. Hvis agenten også får kjøre kommandoer, lese logger eller koble seg mot skyressurser, øker risikoen ytterligere.
Derfor må virksomheter skille mellom minst tre nivåer av AI-koding.
Første nivå er ufarlig eller lavrisiko bruk: å forklare generell kode, lage et eksempel i en tom prosjektmappe, skrive en teststrategi eller foreslå dokumentasjon uten interne data. Her er risikoen ofte håndterbar.
Andre nivå er intern kodebase uten produksjonsdata. Her blir avtalevilkår, logging, modelltrening, tilgangsstyring og hemmelighetshåndtering viktige. Det bør være klart hvilke data leverandøren får, om data kan brukes til modellforbedring, hvor de behandles, og hvordan de slettes.
Tredje nivå er agent med tilgang til produksjonsnære systemer, logger, kundedata, databaseuttrekk eller infrastruktur. Dette bør ikke skje tilfeldig. Det krever bevisst risikovurdering, tilgangsbegrensning, revisjonsspor og tydelige rutiner for hva agenten får lese og gjøre.
OpenAIs Codex-hjelpedokumentasjon peker på at ChatGPT-kontroller for treningsdata påvirker om innhold behandlet gjennom Codex kan brukes til modellforbedring. Det er nettopp slike detaljer virksomheter må forstå før de tar verktøyene inn i hverdagen. Det holder ikke å si at "vi bruker bare AI til kode". Spørsmålet er hvilken kode, hvilke filer, hvilke hemmeligheter og hvilke data som følger med.
Dette henger sammen med tidligere Kunnskapsrom-artikler om hvem som egentlig kontrollerer dataene dine og GDPR-data i amerikanske skyløsninger. Kodeagenter gjør ikke disse spørsmålene mindre relevante. De gjør dem mer praktiske.
Hvor AI-koding kan gi mest verdi i små og mellomstore bedrifter
For små og mellomstore bedrifter er ikke den største verdien nødvendigvis at én utvikler blir dramatisk raskere. Verdien kan ligge i at flere oppgaver faktisk blir gjort.
Mange SMB-er har systemer som fungerer, men som ikke er godt vedlikeholdt. De har små interne verktøy, gamle integrasjoner, utestående sikkerhetsoppdateringer, manuelle rapporter, regneark som burde vært automatisert, og dokumentasjon som bare én person forstår. AI-agenter kan gjøre det billigere å rydde i slike ting.
Et godt eksempel er rapportering. En agent kan hjelpe med å hente data fra en CSV, lage et lite script, generere en graf, kontrollere feilmeldinger og dokumentere fremgangsmåten. Det er ikke nødvendigvis "programvareutvikling" i klassisk forstand, men det er arbeid som før krevde at noen kunne kode nok til å komme i gang.
Et annet eksempel er testdekning. Mange prosjekter har for få tester fordi det alltid var noe viktigere å gjøre. En kodeagent kan foreslå tester, kjøre dem, se hvor de feiler og justere. Mennesket må fortsatt vurdere om testene faktisk gir verdi, men agenten kan senke terskelen.
Et tredje eksempel er modernisering. Gamle PHP-, Python-, JavaScript- eller .NET-prosjekter kan ha repeterende oppgraderingsbehov. AI kan hjelpe med å finne mønstre og lage første versjon av endringer. Det bør ikke gå rett i produksjon, men det kan gjøre modernisering mindre skremmende.
Her ligger en praktisk mulighet: bruke AI-kodeagenter til å redusere teknisk gjeld, ikke bare til å pøse ut nye funksjoner. Det er kanskje mindre glamorøst, men ofte langt mer verdifullt.
Risikoen: mer kode er ikke det samme som bedre programvare
Anthropic peker selv på en klassisk flaskehals: når mer kode produseres, flytter presset seg til kodegjennomgang. Dette er Amdahls lov i organisatorisk form. Hvis agenten gjør én del av prosessen ti ganger raskere, blir den neste tregeste delen plutselig den virkelige begrensningen.
Det er et sunnhetstegn at leverandørene selv snakker om dette. For en virksomhet er det likevel fristende å lese produktivitetsfortellingen for enkelt: "Hvis AI kan skrive mye mer kode, kan vi levere mye mer." Kanskje. Men hvis kravene er uklare, testene svake og review-prosessen presset, kan resultatet bli mer kode som ingen helt eier.
Det finnes også en sikkerhetsrisiko. AI kan foreslå biblioteker som ikke bør brukes, lage feil tilgangskontroll, overse inputvalidering, skrive usikre SQL-spørringer, eller skjule kompleksitet bak pen syntaks. Slike feil er ikke alltid spektakulære. De kan ligge stille i måneder.
En annen risiko er at utviklere mister systemforståelse. Hvis agenten alltid gjør endringene, kan teamet etter hvert vite mindre om hvorfor systemet ser ut som det gjør. Dette er særlig farlig i små team der dokumentasjon allerede er svak. Da kan AI bli en snarvei som øker avhengigheten av verktøyet.
Den siste risikoen er organisatorisk: ledere kan bruke AI-koding som et kostnadskuttargument før de har forstått prosessen. Å kutte mennesker før man har bygget kvalitetssystemer rundt agentarbeid er kortsiktig. Det kan gjøre virksomheten raskere på demo og svakere i drift.
Hva team bør gjøre nå
Det første steget er å lage en tydelig AI-kodepolicy. Den trenger ikke være tung, men den må være konkret. Hvilke prosjekter kan brukes med eksterne kodeagenter? Hvilke filer skal aldri deles? Hvordan håndteres hemmeligheter? Hvem kan gi agenten tilgang til repository? Kan agenten bruke produksjonslogger? Kan den installere pakker? Hvem godkjenner endringer?
Det andre steget er å begynne med lavrisiko-oppgaver. Dokumentasjon, testforslag, refaktorering i isolerte moduler, kodeforklaring og migrering i sandkasser er gode startpunkter. Ikke start med produksjonskritisk betalingslogikk, persondataflyt eller tilgangskontroll.
Det tredje steget er å styrke review-prosessen. AI-generert kode bør ikke gli lettere gjennom fordi den ser ryddig ut. Tvert imot bør teamet være ekstra bevisst på testdekning, sikkerhet, avhengigheter og databehandling. En god review av AI-kode handler ikke om å finne ut om teksten ser profesjonell ut. Den handler om å forstå konsekvensene.
Det fjerde steget er å lære utviklere å skrive gode arbeidsordre. Ikke bare promter, men små spesifikasjoner. Hva er målet? Hvilke filer er relevante? Hva skal ikke endres? Hvilke tester må gå? Hvilke antakelser skal agenten ikke gjøre? Hvilke risikoer skal vurderes?
Det femte steget er å måle riktig. Ikke mål bare linjer kode eller antall pull requests. Mål feilrate, lead time, reviewtid, testdekning, tilbakeføringer, sikkerhetsfunn og hvor mye vedlikeholdsarbeid som faktisk blir gjort. Hvis AI bare øker volumet uten å bedre kvaliteten, er gevinsten svakere enn den ser ut.
Det sjette steget er å beholde eierskapet til kunnskapen. Når en agent foreslår endringer, bør teamet dokumentere hvorfor endringen ble gjort, hvilke antakelser som ble lagt til grunn, og hvilke begrensninger som fortsatt finnes. Ellers kan virksomheten ende med kode som fungerer, men som ingen kan forklare godt nok når den feiler. Det er spesielt viktig i små miljøer der én person ofte eier mye taus kunnskap.
Hva dette betyr for utviklere
For utviklere blir den viktigste ferdigheten å forstå systemer, ikke bare syntaks. Kunnskap om arkitektur, sikkerhet, domene, testing, drift og datamodellering blir mer verdifullt når selve produksjonen av kode blir billigere.
Nye utviklere bør fortsatt lære å kode. Å hoppe rett til agentstyring uten grunnforståelse er farlig. Man må kunne lese kode, debugge, forstå feilmeldinger og vite når en løsning er dårlig. Men læringsbanen endres. Det blir viktigere å lære hvordan man undersøker, tester og vurderer, ikke bare hvordan man skriver alt fra bunnen av.
Erfarne utviklere får en annen utfordring. De må gi slipp på noe av identiteten som ligger i å skrive hver linje selv. Det kan være ubehagelig. Men erfaringen deres blir ikke mindre relevant. Den blir brukt på et annet nivå. Den som kan se at en tilsynelatende enkel endring bryter en forretningsregel, en sikkerhetsforutsetning eller en gammel integrasjon, blir enda viktigere.
Den dårligste strategien er å ignorere agentene. Den nest dårligste er å stole blindt på dem. Den gode strategien er å lære dem godt nok til å vite hvor de hjelper, hvor de feiler, og hvilke rammer de må ha.
Konklusjon: Dette er ikke slutten på utvikleren, men slutten på en del rutinearbeid
AI-kodeagenter endrer utviklerrollen fordi de flytter arbeid fra tastatur til styring. De beste teamene vil ikke bare skrive raskere. De vil bli flinkere til å beskrive arbeid, teste endringer, kontrollere risiko og beskytte data.
Samtidig må vi være nøkterne. Mer kode er ikke automatisk bedre programvare. Flere agenter er ikke automatisk mer produktivitet. Og en raskere utviklingsprosess er ikke trygg hvis virksomheten ikke vet hvilke data den deler med leverandørene.
For norske virksomheter bør dette bli en praktisk, ikke ideologisk, diskusjon. Bruk AI-kodeagenter der de gir reell verdi. Start med vedlikehold, dokumentasjon, test og avgrensede endringer. Bygg rutiner for datadeling, sikkerhet og review før agentene får dypere tilgang. Og husk at ansvaret ikke flyttes til modellen. Det ligger fortsatt hos menneskene og virksomheten som setter koden i produksjon.
Videre lesing
