Dette får du med deg fra artikkelen:  

Hvordan AI forandrer programvareutvikling, og hvorfor den gamle arbeidsmodellen for IT-team begynner å gå ut på dato. Du får også et innblikk i hvordan den nye utviklingssyklusen ser ut, og hvilke ferdigheter som vil telle mest for teknologiteam i årene som kommer.  

90 % av utviklere bruker AI hver dag – det viser DORA 2025. 41 % av all kode i verden genereres av AI. Hos Google er allerede 25 % av produksjonskoden AI-assistert.  

Et nytt paradigme har vokst frem: Spec-Driven Development. En gjennomarbeidet spesifikasjon er blitt det sentrale elementet i prosessen – ikke en enkel oppgavebeskrivelse.  

Selskaper som bare «la til AI» i den gamle prosessen, fikk lite igjen for det. DORA 2025 sa det rett ut: AI fikser ikke et team – det forsterker bare det som allerede er der. Forskning på utviklingsteam viser at team med høy AI-bruk lukker 98 % flere pull requests, men at review-tiden økte med 91 %, uten at leveringstakten ble bedre. CodeRabbit dokumenterte i desember 2025 at PR-er skrevet med AI-støtte inneholdt 1,7 ganger flere problemer, mens antall feil per utvikler økte med 9 %.  

Konklusjonen er klar: AI øker farten på kodeproduksjon – men også på feilproduksjon. Fordelen ligger ikke i verktøyet alene, men i den nye arbeidssyklusen rundt det:  

spesifikasjon → AI genererer → mennesket verifiserer → AI tester → mennesket tar ansvar  

Utvikler – eller også tester?  

Den andre store endringen handler om eierskap til kvaliteten. Rollen som dedikert tester, slik mange kjenner den idag, er i ferd med å bli mindre vanlig.  

Det høres kanskje drastisk ut, særlig for de som jobber med testing i dag. Men dette er ikke en løsrevet påstand – det er en modell verdens største teknologiselskaper innførte for lenge siden. Microsoft avviklet SDET-rollen allerede i 2014. Google, Meta, Apple, Amazon, Netflix og Uber bygger ikke teamene sine rundt manuelle testere. Her er det utvikleren selv som har ansvar for at koden faktisk virker.  

En ingeniør som opplevde denne overgangen, beskrev forskjellen slik:  

I den gamle modellen leverte utvikleren fra seg arbeidet, QA fikk en oppgave en dag eller to senere, fant feil og sendte alt i retur. Det kostet dager. Etter omleggingen testet alle sin egen kode og teamet ble merkbart mer produktivt.  

Den klassiske ping-pong-runden mellom utvikling og testing blir gradvis mindre relevant. Tidligere var den største barrieren mot denne endringen selve kostnaden ved å skrive tester. Nå har regnestykkene snudd. AI genererer enhetstester på få minutter, og Capgeminis World Quality Report viser at team som bruker AI-basert testing har redusert testvedlikehold med 70 prosent- det er en vesentlig forskjell.  

Ferdig kode holder ikke lenger  

Tanken om å «skrive kode og sende den videre til testing» er på vei ut. I stedet vokser det frem en ny forventning: «jeg har skrevet løsningen, testet den, vurdert edge cases – og står inne for resultatet». AI er et kraftig hjelpemiddel, men det er fortsatt mennesker som må bekrefte at koden fungerer. Verktøyet kan foreslå løsninger, generere tester og identifisere risiko. Ansvaret kan det ikke ta.  

Hva skjer med testerrollen?  

Det viktigste å understreke er at testerrollen ikke forsvinner. Den endrer seg. Tyngdepunktet flytter seg fra å gjennomføre testscenarioer til å tenke som en quality architect. Det betyr mer ansvar for automatisering, risikostrategier, vurdering av AI-atferd i produkter og bygging av testsystemer som utviklere ikke setter opp selv.  

Det er krevende arbeid – men også langt mer verdifullt enn å kjøre gjennom forhåndsdefinerte scenarioer. Hvordan overgangen vil se ut, varierer fra organisasjon til organisasjon. Likevel peker utviklingen i samme retning.   

Prosjektledelse ser annerledes ut  

Samtidig endres måten arbeid planlegges og organiseres på. Tradisjonelle sprintere med en dedikert QA-fase på slutten gir stadig mindre mening. Testing er ikke lenger noe som skjer etter at koden er ferdig – det er en løpende del av utviklerens hverdag. Det påvirker også definisjonen av hva som regnes som «ferdig». Stadig oftere inkluderer definition of done:  

• tester skrevet og kjørt av utvikleren selv  
• code review er gjennomført, gjerne med AI-støtte  
• risikoer er vurdert og dokumentert.  

Dette påvirker hvordan vi estimerer arbeid, måler fremdrift og organiserer leveranser. Det er mer enn en prosessjustering – det er en reell ny leveringsmodell.  

En varig endring  

Dette handler ikke om å snu alt på hodet over natten. Det handler om å erkjenne at retningen allerede er tydelig.  

Noen virksomheter tok dette steget for lenge siden. Andre er midt i overgangen nå. Men det er vanskelig å se for seg at den tradisjonelle arbeidsmodellen vil bestå uendret. For mange er dette fortsatt ukjent terreng. En ting virker likevel sikker: veien tilbake til det som var, finnes ikke lenger.