2026-03-02

Når alle kan generere kode med AI, er eierskap til arkitekturen enda viktigere

Programvareutvikling har alltid tålt en viss grad av utydelighet. Når utviklere skrev all kode selv, kunne feil beslutninger rettes underveis. Arkitektur kunne vokse frem iterativt fordi konsekvensene av lokale valg var begrensede. Med AI endres dette fundamentalt.

Når implementasjon genereres automatisk skalerer ikke bare produktiviteten, men også inkonsistensen. En uklar grense i domenet kan bli kopiert hundre ganger på minutter. Teknisk gjeld oppstår ikke gradvis, men med én gang. Derfor kan vi ikke lenger la strukturen oppstå etter hvert. Arkitektur må være eksplisitt definert før første linje kode eksisterer.

Dette gjør arkitektur til mer enn en teknisk disiplin. Det blir operasjonell risikostyring.

I en AI-drevet utviklingsprosess er heller ikke koden systemets sannhet. Spesifikasjonen er det. Den beskriver hva systemet skal gjøre, hva det aldri skal gjøre og hvordan vi kan verifisere forskjellen. Dokumentasjon er dermed ikke lenger støtteinformasjon til implementasjonen, men produksjonsgrunnlaget implementasjonen genereres fra.

Konkurransefortrinnet flytter seg derfor fra hvem som skriver mest kode til hvem som definerer tydeligst før koden oppstår.

Eierskap til arkitekturen (The "Big Picture")

En viktig lærdom er at arkitekturen må eies av mennesker, ikke av AI. Modellen er svært god til å lage funksjoner, men den tar ikke hensyn til helheten over tid. Hvis den får bestemme strukturen selv, vil den optimalisere lokalt fra oppgave til oppgave, og resultatet blir et system som fungerer nå, men som gradvis mister sammenheng og blir vanskelig å videreutvikle. Derfor må arkitekturen beskrives eksplisitt i spesifikasjonen før implementasjon starter, enten gjennom lagdeling eller domenemodeller. AI skal implementere innenfor rammene, ikke definere dem.

"Garbage In, Garbage Out" (Spesifikasjons kvalitet)

Kvaliteten på resultatet følger kvaliteten på spesifikasjonen. En uklar eller generell, spesifikasjons fil gir tilsvarende uklar kode, fordi modellen alltid fyller inn hullene selv. Derfor må begrensninger beskrives eksplisitt. Hvilke biblioteker som skal brukes, hvilke som er forbudt, hvilke mønstre som er tillatt og hvilke som ikke er det. Jo mer presis kontrakten er, desto mer forutsigbar blir implementasjonen. Ved å koble modellen til eksisterende dokumentasjon gjennom Model Context Protocol (MCP) kan den også forstå virksomhetens begreper og regler, i stedet for å gjette basert på generisk treningsdata.

Validering ("Trust but Verify")

AI må alltid verifiseres, selv når den hevder å ha fulgt spesifikasjonen. En modell rapporterer sannsynlighet, ikke sannhet, og derfor kan korrekt utseende kode likevel bryte kontrakten. Test-drevet utvikling blir derfor en kontrollmekanisme: modellen må skrive eller følge tester før implementasjonen aksepteres, og hvis testen feiler er oppgaven ikke løst. I tillegg bør generering og evaluering skilles. Én agent produserer koden, mens en annen, med strengere instruksjoner, gjennomfører code review opp mot spesifikasjonen. Målet er ikke tillit, men verifiserbar etterlevelse.

Sikkerhet og data-personvern

AI introduserer også nye spørsmål rundt sikkerhet og personvern. Du må vite hvor kode og spesifikasjoner behandles, og om verktøyene du bruker benytter materialet til videre trening. Samtidig kan modellen foreslå løsninger som bryter grunnleggende sikkerhetsprinsipper, for eksempel å legge API-nøkler direkte i koden. Slike feil oppstår ikke av ond vilje, men fordi modellen optimaliserer for å få noe til å fungere. Derfor bør hemmeligheter alltid beskyttes med automatiske kontroller, som scanning av repository for eksponerte nøkler, før noe får slippe inn i versjonskontroll eller produksjon.

Ta små steg (Atomic Tasks)

Store oppgaver gir uforutsigbar oppførsel fra modellen. Når konteksten blir for bred, begynner den å gjette sammenhenger og blande ansvar på tvers av systemet. Derfor bør spesifikasjonen deles opp i små, atomiske oppgaver med klart avgrenset mål. Hver oppgave skal kunne genereres og verifiseres raskt, gjerne innen ett til to minutter. Små steg gjør resultatet mer stabilt, enklere å kontrollere og langt lettere å rette hvis noe blir feil.

Versjonskontroll av spesifikasjonene

Spesifikasjonene må behandles som kildekode. Når implementasjonen genereres automatisk, er det beslutningene bak systemet som blir den egentlige historikken. Derfor bør spesifikasjons-filene versjoneres og sjekkes inn på lik linje med vanlig kode. Da kan man alltid gå tilbake og forstå hvorfor en løsning ble valgt, selv om selve implementasjonen senere er regenerert av en modell.

Konsekvensen av AI-drevet utvikling

AI gjør ikke programvareutvikling enklere, den flytter bare hvor kompleksiteten ligger. Implementasjonen kan genereres, men ansvar kan ikke automatiseres. De som lykkes fremover er derfor ikke de som produserer mest kode, men de som tydeligst definerer hva som skal bygges, hva som er lov og hvordan det verifiseres før noe får eksistere i systemet.

Skrevet av: Svein Aandahl