Når kodeskriving slutter å være kjernen i utviklerrollen

Ikke fordi kode forsvinner, men fordi den i økende grad produseres av verktøy. Det som tidligere var kjernen i utviklerrollen – å implementere løsninger i kode – blir mer og mer et mellomprodukt på vei mot noe annet. Og når kjernen flyttes, må vi også forstå rollen på nytt.

Advent of Code som empirisk bakteppe

Advent of Code er en adventskalender for folk som liker å skrive kode. Hver dag i desember publiseres nye programmeringsoppgaver. Oppgavene er nye når de slippes, hver deltaker får sin egen input, og for hver oppgave finnes det ett korrekt svar. Enten er løsningen riktig, eller så er den feil.

Det publiseres to oppgaver per dag, der den andre typisk er vesentlig vanskeligere enn den første. Oppgavene blir også gradvis mer komplekse utover i måneden. De er beskrevet i prosatekst, men følger kjente mønstre: grafsøk, tilstandsbasert simulering, dynamisk programmering og rekursjon. Dette gjør dem godt egnet til å teste generell problemløsing, ikke bare kunnskap om et språk eller rammeverk.

Jeg har brukt Advent of Code som testarena for AI siden 2022:

• 2022 (ChatGPT 3.5): AI klarte i praksis ingen oppgaver.
• 2023: Den løste et par enkle før den stoppet opp.
• 2024: Jeg testet flere modeller parallelt. Mange oppgaver ble løst, men med økende behov for håndholding, særlig på oppgave 2 utover i måneden.
• 2025: Jeg brukte én modell (Claude Opus 4.5). Den løste alle oppgavene jeg forsøkte, inkludert de vanskeligste, på helt nye problemer, med korrekthet og kodekvalitet som etter min vurdering – basert på lesbarhet, konsishet og fravær av åpenbare svakheter – ofte matchet, og tidvis overgikk, det jeg selv ville levert.

Advent of Code er ikke produksjonskode. Oppgavene må kunne løses på kort tid, har perfekt spesifiserte krav, og handler primært om algoritmikk. Men signalet er vanskelig å overse: når AI allerede løser nye, algoritmiske problemer raskere og mer konsistent enn meg i et format som dette, peker det i samme retning som mye annen utvikling – nettopp den delen av jobben som handler om å produsere korrekt og ryddig kode, er på vei til å bli automatisert.

Jeg liker å sammenligne dette med verdien av å kunne skrive assembler. All kode blir til slutt assembler før den kjøres av maskinen, men det er svært få utviklere som noen gang ser denne koden, fordi den genereres av kompilatoren. På 60- og 70-tallet var evnen til å skrive effektiv assembler-kode viktig. I dag er det noe datamaskiner holder på med. Behovet for mennesker som behersker det direkte er marginalt. Kodeskriving beveger seg i samme retning: fortsatt avgjørende at det skjer, men i økende grad som en maskinoppgave.

Håndverkerrollen forsvinner – ikke utviklerrollen

Når jeg snakker om utviklerens håndverkerrolle, mener jeg i praksis selve kodeskrivingen: å implementere algoritmer, oversette krav til fungerende programvare og «få det til å virke».

Det er nettopp denne delen AI nå gjør raskere og mer konsistent, med kodekvalitet som matcher og overgår erfarne utviklere i mange situasjoner. Å kunne skrive korrekt og ryddig kode blir dermed noe verktøyene gjør, ikke et varig konkurransefortrinn for mennesker.

Dette er ikke et unikt skifte. Tegnere forsvant ikke da CAD kom. Regnskapsførere forsvant ikke da regnearkene kom. Yrket besto, men verdien flyttet seg bort fra selve verktøybruken og over mot forståelse, vurderingsevne og kontekst.

Hvis man med utvikler mener en person som primært tilfører verdi ved å skrive kode basert på relativt klare spesifikasjoner – en rolle som uansett har vært på vikende front – er det rimelig å si at den er på vei ut. Ikke fordi den er unyttig, men fordi den ikke lenger er der mesteparten av verdien skapes.

Hvis man derimot mener en person som forstår hvordan programvare faktisk fungerer, hvilke konsekvenser tekniske valg har, og hva som skjer over tid når systemer lever i virkeligheten, er bildet det motsatte. Den typen kompetanse blir viktigere enn før.

Når koding blir billigere, blir oversikt viktigere

Det mest konsekvente utfallet av at kodeskriving ikke lenger er flaskehalsen, er ikke at utviklingsarbeid blir «enkelt», men at kompleksiteten flytter seg. Når det plutselig går mye raskere å skrive kode, skrives det også tilsvarende mer kode.

I et slikt landskap er det sjelden selve kodeskrivingen som er problemet. Det som blir vanskeligere, er å forstå hva valgene vi tar nå låser oss til senere – det jeg her kaller konsekvensrommet:

• Hvilke valg er reversible?
• Hvilke valg blir dyre å endre?
• Hvilke valg bestemmer i praksis hvordan systemet kan utvikle seg videre?

Noen eksempler:

• Du velger en teknologi fordi teamet behersker den, men om to år har halvparten sluttet, og de nye utviklerne har en annen bakgrunn.
• Du bygger en integrasjon mot en leverandør som virker stabil, men kontrakten er oppe til reforhandling, og ingen fortalte utviklingsteamet.
• Du automatiserer en arbeidsflyt basert på hvordan ting gjøres i dag, men prosessen er allerede under press fra regulatoriske krav som ikke er kommunisert ennå.

Kode er et øyeblikksbilde. IT-systemer er historier som utvikler seg over tid. Det er i den historien de vanskelige beslutningene ligger – og det er der mennesker fortsatt er uunnværlige.

Den nye rollen

Utviklerrollen forsvinner ikke, men den omdefineres. Når maskiner skriver kode raskere enn mennesker, flytter den menneskelige verdien seg – i hvert fall foreløpig – til det som krever tid å lære: forståelsen av hva som skjer med systemer over tid.

Hvordan de eldes. Hvordan tekniske valg blir til organisatoriske begrensninger. Hvordan dagens snarvei blir neste års kostnad. Dette er ikke ferdigheter man får av å skrive mer kode i seg selv. Det er ferdigheter man får av å leve med konsekvensene av kode – sin egen og andres – over tid.

For utviklere betyr det at karrieren i mindre grad handler om å være best til å skrive koden, og i større grad om å:

• forstå systemer, domener og arkitektur
• se sammenhengen mellom tekniske valg og forretningsmessige konsekvenser
• bruke AI som et kraftig, men ikke ufeilbart verktøy i et større resonnerende arbeid

Spørsmålet er ikke om dette skjer, men hvor fort – og om utviklere er klare til å ta inn over seg konsekvensene av dette.