Et program er ikke koden sin

I 1985 satte den danske dataforskeren Peter Naur seg ned og skrev et essay de færreste har lest: Programming as Theory Building. Men budskapet hans er forbløffende enkelt, og det traff meg: Et program er ikke bare kildekoden. Det er teorien vi utviklere bærer med oss i hodet. Forståelsen av hvordan alt henger sammen.

Koden er egentlig bare et slags kart over denne teorien, og kartet er aldri hele terrenget. Den virkelige kunnskapen lever i hodene til de som bygget systemet: hvorfor ting ble akkurat slik, hvilke veier vi vurderte, hvordan bitene faktisk henger sammen.

Det kan høres litt svevende ut, men dette har veldig konkrete konsekvenser. Særlig nå, når AI-verktøyene banker på døra og lover å forandre måten vi lager programvare på.

Hva mister vi når vi outsourcer tenkningen?

Når en utvikler ber en LLM skrive kode og bare tar imot svaret uten å tenke, hopper man over hele den mentale brytekampen som faktisk bygger forståelse.

Det minner litt om å bruke kalkulator på matteprøven i fjerde klasse. Du får riktig svar, men gangetabellen sitter ikke. Men programmering er enda mer enn det — det handler om å bygge mentale modeller som vokser og modnes over tid. Hver gang vi tar en snarvei, gjør vi neste problem litt vanskeligere, ikke lettere.

AI-generert kode har en annen egenskap som er lett å overse: Den eksisterer i et teoretisk vakuum. Den vet ingenting om domenet ditt, arkitekturen din, eller hvorfor dere valgte å gjøre ting på akkurat denne måten. Når du limer inn kode du ikke fullt ut forstår, importerer du også arkitektoniske beslutninger som kanskje motsier mønstrene dere allerede har etablert.

Resultatet er ikke bare at koden blir dårligere. Det er at vi utviklere gradvis mister evnen til å tenke selvstendig om det vi bygger.

Dette er Storbritannias første KI-by

Barnsley er utpekt som Storbritannias første teknologiby. Byen blir prøvekanin for resten av landet.

Institusjoner som forvitrer

Dette stopper ikke med den enkelte utvikler. Et utviklingsteam er mer enn bare folk som skriver kode. Det er en levende institusjon, med lag på lag av erfaring, felles mål og måter å ta valg sammen på.

Mentorskap forvitrer. Juniorutviklere lærer tradisjonelt ved å jobbe med seniorutviklere, stille dumme spørsmål, få code reviews som forklarer hvorfor noe er feil. Når junioren i stedet spør ChatGPT og aksepterer svaret, brytes denne overføringen av taus kunnskap. Institusjonen mister evnen til å reprodusere seg selv.

Beslutningsprosesser flater ut. Code review er ikke bare kvalitetskontroll. Det er arenaen der teamet utvikler felles forståelse. Når AI-generert kode dukker opp uten kontekst eller begrunnelse, blir reglene usynlige. Beslutningene blir umulige å utfordre fordi ingen vet hvorfor de ble tatt.

Relasjoner svekkes. Kolleger som mottar dårlig AI-generert arbeid ("workslop") begynner å se på hverandre som mindre kreative, mindre kapable, mindre pålitelige. AI erstatter den kollegiale friksjonen med smigrende, kontekstløse svar. Når organisasjoner kaster seg ukritisk over AI, risikerer de å kutte over ekspertise-linjene, tømme beslutningsprosessene for innhold, og la relasjonene mellom folk visne hen.

Feedbackloopen ingen snakker om

Men det er enda en dimensjon her, og den er lett å overse: forholdet mellom de som drømmer om noe, og de som faktisk bygger det.

Når en leder sier "vi trenger en funksjon for å eksportere rapporter", starter en prosess som er lett å undervurdere.

Utvikleren spør: Hvilke rapporter? I hvilket format? Hvem skal bruke dette? Hva skal de gjøre med dataene etterpå?

Disse spørsmålene er ikke bare irriterende forsinkelser. De er selve feedbackloopen som former intensjonen. Gjennom samtalen oppdager lederen ofte at det egentlige behovet er noe helt annet. Kanskje ikke eksport i det hele tatt, men et dashboard. Eller en integrasjon.

Moltbook – Reddit for KI-agenter

På den nye sosiale medieplattformen Moltbook, så er mennesker kun observatører. Her er det KI-roboter som samhandler og driver kommunikasjonen.

Utviklerne blir et speil som kaster lederens ønsker tilbake. Litt klarere, litt mer gjennomtenkt.

Og her kommer AI-løftet som frister: Hva om vi kan hoppe over denne prosessen? Direkte fra intensjon til kode. Ingen utviklere som stiller spørsmål. Ingen forsinkelser mens noen "forstår domenet".

Problemet er at du får akkurat det du ba om, men ikke det du faktisk trengte.

Ledere som vil "trimme kostnaden ved å realisere intensjoner" forstår ofte ikke at feedbackloopen er det som muliggjør intensjonene i utgangspunktet. Å fjerne utviklerne er ikke å effektivisere verdiskapningen. Det er å fjerne mekanismen som gjør vage ønsker om til konkrete løsninger.

Det er litt som å droppe arkitekten fordi du tror du vet hva du vil ha: "et hus med fire soverom". Joda, du får fire soverom. Men ingen har spurt om tomten tåler det, om lyset faller riktig inn, eller om det gir mening med fire soverom når barna har flyttet ut om noen år.

Den usynlige kostnaden

Det skumle er at denne kostnaden er usynlig, i hvert fall med det første.

Når AI-generert kode "fungerer", ser det ut som en seier. Funksjonen ble levert. Det du ikke ser, er alt som ikke skjedde:

• Ingen spurte om dette var riktig problem å løse
• Ingen utfordret antagelsene bak kravet
• Ingen koblet funksjonen til den større arkitekturen
• Ingen bygget forståelse som gjør neste endring enklere

Resultatet er kode som virker for seg selv, men som ikke henger sammen med resten. Et system som sakte blir uforståelig. Ikke fordi koden er dårlig, men fordi ingen noen gang bygget en teori om hva det egentlig er.

Teorien dør ut. Koden står igjen. Og neste utvikler som skal gjøre en endring, står der uten kart, midt i ukjent terreng.

Hvor AI faktisk hjelper

Dette er ikke et argument mot AI-verktøy. De kan være genuint nyttige; for boilerplate, for utforskning, for å akselerere arbeid der teorien allerede er etablert.

Nøkkelen er enkel: Det er vi mennesker som setter teorien. AI kan hjelpe oss å utføre den.

KI-tabbe i kommune: – Brukte KI for å spare tid

Aurskog-Høland skulle bruke KI til å rydde opp i rot med vann- og avløpsbetalinger. Det gikk ikke så bra.

Det betyr at AI kan hjelpe med:

• Generere testkode for logikk du allerede forstår
• Scaffolde struktur etter mønstre du har definert
• Utforske løsningsrom du selv kan evaluere

Men AI bør ikke ta:

• Arkitektoniske beslutninger
• Domenemodellering
• Avveininger som krever forståelse av kontekst

Forskjellen ligger i om du bruker verktøyet til å gi fart til din egen tenkning, eller om du lar det ta over for deg.

Hva nå?

Naurs essay fra 1985 var en advarsel vi ikke hørte. Vi har i tiår behandlet programvare som kode-produksjon snarere enn teori-bygging. AI-verktøyene forsterker denne misforståelsen. De gjør kode-produksjon billigere, mens de gjør teori-bygging vanskeligere.

Er du utvikler? Vær bevisst på hva du gir fra deg når du aksepterer kode du ikke forstår. Den mentale kampen er ikke bortkastet tid. Det er selve læringen.

Bør KI-genererte nyheter merkes? Ja, mener tankesmie

KI-genererte nyheter bør merkes, mener den britiske tenketanken IPPR. De argumenterer også for at teknologiselskaper skal betale aviser for innhold de bruker.

Hvis du leder utviklere: Forstå at du ikke betaler for kode. Du betaler for tenkning. For feedbackloopen som gjør vage ønsker til konkrete løsninger. For institusjonen som kan vedlikeholde og videreutvikle.

Skal du kutte kostnader? Vær klar over hva du faktisk kutter. Feedbackloopen mellom de som har en idé og de som bygger den, er ikke overhead. Den er verdiskapningen.

Å kutte denne loopen for å spare penger er som å spare på fundamentet for å få råd til en ekstra etasje.