Er det noen vits i å skjønne kode når vi bare kan fortelle en robot hva vi vil ha?

Proto-digitalisering

På det glade åttitallet jobbet jeg i IT-avdelingen på BI. Der gjennomførte jeg, nærmest på egenhånd, en digitaliseringsprosess. Uten at jeg var klar over at det var det jeg gjorde.

Det gjaldt karakterer, som det gjerne gjør i en akademisk sammenheng. BI hadde gått fra omtrent 3000 studenter i 1985 til 20000 i 1988, og dermed ble publisering av karakterene en nokså omfattende affære. For heltidsstudentene gjorde vi det ved å skrive ut en mange meter lang karakterliste, på pysjamaspapir med en kjedeskriver, og tapetsere en av gangene på bygget med dem. Listen var gruppert etter kurs og sortert etter studentnummer, og ca 25000 linjer lang. Studentene fant kurset sitt og lette seg møysommelig nedover til de fant studentnummeret sitt, og deretter karakteren, med påfølgende jubel eller skuffelse, alt ettersom. For de studentene som bodde annensteds i landet, hadde vi endel studentassistenter som satt med en tykk papirbunke og svarte i telefonen.

Nuvel. Jeg tenkte at dette kunne gjøres på en smartere måte, så jeg satte meg ned og skrev et lite program (i programmeringsspråket REXX, av alle ting). Programmet spurte etter studentnummeret, lette gjennom karakterlisten og skrev ut de relevante karakterene på skjermen. I tillegg viste programmet strykprosent og gjennomsnittskarakter for hvert kurs. Alle dataene lå på en stormaskin, så jeg fikk tak i noen gamle terminaler og satte dem opp. (BI hadde fått en masse terminaler gratis og hadde dem på lager.) Studentene kunne da gå opp til en av fem terminaler, skrive inn sitt syvsifrede studentnummer, trykke «Enter», og få karakterene opp på skjermen. Studentassistentene ved telefonen fikk sin egen terminal.

Prosjektet var en suksess: Det kostet nesten ingenting, vi slapp å skrive ut masse papir og henge det opp, studentassistentene fikk en lettere jobb, telefonsamtalene ble kortere og dermed billigere, og så videre. Det var også populært, både hos brukerne og i organisasjonen. Riktignok klaget noen studenter over et emosjonelt ubehag ved å få alle karakterene sine rett opp i fleisen uten forvarsel (i stedet for den noe mer skånsomme prosessen ved å finne dem en og en), men slik er det med enhver endring, man kan ikke gjøre alle til lags.

(En liten parentes til dagens studenter: Husk at dette skjedde på et tid da internett og PC var forbeholdt eksperter og entusiaster; mobiltelefoner kostet det samme som en bruktbil, veide flere kilo og kunne bare snakkes i; og all skriftlig korrespondanse skjedde på papir. Det er faktisk ikke så lenge siden.)

Kode og kodeforståelse

Programmet jeg hadde skrevet, var nokså enkelt: Spør etter studentnummer, inn alle linjer med dette nummeret i, og skriv dem på skjermen. Problemet var at selve tekstfilen var for stor for vår IBM 4381 VM/CMS stormaskin. Hvis programmet skulle søke gjennom alle de 25000 linjene, ville det ta så lang tid og bruke så mye datakraft at det ikke var aktuelt. Jeg måtte derfor gjøre en hel del tekniske finurligheter slik at bare en relativt liten del av filen ble lastet inn i arbeidsminnet. I korthet besto dette i å finne ut antall linjer i filen, høyeste og laveste studentnummer, og så klippe opp filen i passende biter som så kunne lastes inn basert på studentnummeret.

For å få til dette måtte jeg definere noen variable, bruke nokså komplisert kode med flytting inn og ut av arbeidsminne, og dele programmet opp i en startprosedyre og en loop som spurte etter studentnummeret. Programmet ble et par A4-sider langt, men det fungerte og klarte en responstid (for en standard virtuell maskin) på under et sekund. Jeg hadde skrevet kommentarer og dokumentert så godt jeg kunne, gjorde noen endringer året etter, men så ble programmet til noe som bare tikket og gikk, og jeg brukte ikke mer tid på det.

I 1990 flyttet jeg til USA for å ta en doktorgrad. Sommeren etter var jeg tilbake på BI for å besøke mine gamle venner i IT-avdelingen. En av dem ba meg om å gjøre en endring i karakterprogrammet. Jeg satte meg ned, og fant at jeg hadde glemt hvordan programmet fungerte, selv om jeg hadde skrevet den selv og sett på den for litt over et år siden. Ingen andre hadde sett på det heller – programmet hadde fungert, og nå var hele karakterpubliseringsprosessen basert på et lite program som ingen skjønte.

Det tok meg et par timer, så hadde jeg forstått det, og skrev om programmet til noe mer strukturert og svært mye mer dokumentert, og sørget for at et par av mine kolleger hadde kontroll. Men episoden lærte meg noe om hvor avhengige vi er av små, kvikke rutiner som er nokså lette å lage for en person og nokså vanskelige å vedlikeholde for flere.

Trenger vi å egentlig forstå hvordan ting fungerer?

Det lille karakterprogrammet mitt skulle gjøre en enkel funksjon, og kompleksiteten var et resultat av at teknologien på dette tidspunktet var svak, og at jeg dermed måtte gjøre endel nokså teknisk programmering for ikke å overbelaste maskinen. Å finne riktige linjer i en fil på 25 000 linjer er i dag noe som kan gjøres med en enkel kommando eller ferdig rutine. I dag ville programmet antakelig vært 4-5 linjer langt, og superenkelt å forstå.

Eller?

Hadde jeg programmert dette i dag, ville jeg antakelig ha brukt Claude Code eller en annen AI-funksjon, og ganske enkelt fortalt hva jeg ville ha. Gitt at ting nå er tilknyttet Internett (og tilgangen dermed ikke lenger begrenset til fem fysiske terminaler i et rom) ville jeg måttet legge på en masse funksjonalitet for å ha sikker innlogging, hindre at roboter suget ut hele karakterfilen, universell tilrettelegging, hjelpetekster, og så videre. Det resulterende programmet ville fungert – men jeg ville, om jeg i det hele tatt hadde kunnet se på det, ikke forstått hvordan jeg manuelt skulle fikse det hvis noe spesifikt skulle endres.

Dette kan være et problem for en enkeltperson, særlig hvis man rett og slett ikke får til å fortelle AI’en hva det er man vil ha. Men hvis programmet skal inngå i et større hele og danne grunnlag for andre programemr, blir det vanskelig.

Ett byggverk basert på tillit og frivillighet

«Don’t want money. Got money. Want recognition.»
— signaturlinje, midten av 80-tallet

All moderne programvare er bygget opp som et sett av byggestener. Når du snakker, skriver eller klikker til en datamaskin, snur programvaren seg og forteller annen programvare hva den skal gjøre – og så videre. Selve utførelsen blir distribuert ut til en masse små programmer som er svært spesialisert – du kan tenke på det som et byråkrati der du snakker til en kundebehandler, og hovedutfordringen ligger i å finne akkurat den personen eller enheten som har ansvaret for å gjøre den jobben.

Dette er små og store, hardt arbeidende programmer som gjør alt fra enkle ting (som å rydde opp fragmenter av gammel moro fra arbeidsminne eller lagringsmedium) til svært kompliserte verktøy for dokumentoppbygging (som Don Knuth‘s legendariske TeX, for eksempel). Mange av programmene er skrevet for svært mange år siden – men hvis de virker, er det jo liten grunn til å endre dem, unntatt hvis verden rundt endrer seg. De er gjort gratis tilgjengelige, fordi det rett og slett ikke finnes noen god måte å selge dem på – og kildekoden ligger åpent tilgjengelig for alle. Det betyr at alle kan endre den, men også at alle kan verifisere den.

Valutaen i dette systemet er ikke penger, men ære og berømmelse – innenfor en liten, men viktig krets – og veien til medlemsskap går gjennom hardt og helst briljant arbeid. Prosessen er ikke ulik den akademiske publiseringsprosessen, med fagfellevurdering og revisjoner. Men nå han altså hvem som helst bygge et program ved å be om det. Endel av de som gjør dette, ønsker å markere seg som programmerere inn i den åpne kildekodeverdenen – og dermed får de som skal vedlikeholde disse programmene et kjempeproblem med massevis av forslag til endringer generert av AI, som er lett å skrive men vanskelig å teste og kontrollere. Ikke ulikt offentlig forvaltning, som nå får massevis av klager, søknader og henvendelser som er AI-generert og i stand til å skrive like feilfritt og byråkratisk norsk (eller nynorsk, for den saks skyld) som de selv er.

Og dermed kan faktisk den tekniske infrastrukturen vi alle bruker og baserer oss på, over tid bli nokså morken og upålitelig.

En utvikling basert på gjenbruk og optimalisering

En ting er at den menneskelige kontrollmekanismen overveldes – man kan jo argumentere for at vi kanskje skal slutte med alle disse smårutinene og heller bare be AI’en generere store programmer hver gang vi trenger dem. Datamaskiner er jo så kraftige likevel, så det spiller vel liten rolle hvordan dette gjøres på innsiden så resultatet er det vi vil ha? Vi stoler jo på maskinlæringsmodeller basert på nevrale nettverk, der ingen kan forklare presist hva som skjer med hver enkelt beslutning – men som valideres ved å teste på data modellen ikke tidligere har sett. Kunne vi ikke gjort det samme med andre programmer?

Vel, gjør vi det, pirker vi borti kanskje den viktigste grunnen til at hele IT-teknologien har utviklet seg så fort som den har gjort: Gjenbruk av programkomponenter, opprinnelig del av et større (og norskutviklet) konsept kalt objektorientering. La meg ta et tradisjonelt eksempel: Sortering. Det finnes mange ulike måter å sortere en liste på, så det er ikke noe man som programmerer skriver selv. I stedet bruker man en liten kommando som kaller opp et allerede skrevet program. Sett nå at jeg skulle komme på en måte å sortere på som er raskere enn noe annet. Da ville jeg skrevet den som et program – eller foreslått en endring i et allerede eksisterende, mye brukt program – som så ville blitt implementert. Dermed vil alle programmer som bruker sortering bli raskere – ikke bare de programmene som blir skrevet etter at den nye sorteringsmåten er kjent, men alle programmer som sorterer ved hjelp av det allerede eksisterende programmet.

I fysisk produksjon kan komponenter ikke kan oppdateres eller byttes uten bruk av tid og penger. I kunnskapsproduksjon kan bytte av teori kan ta lang tid (Kuhn, 1962). Men innen software vil en liten forbedring i en underliggende (og mye brukt) komponent kunne bli en stor og viktig forbedring for et større system så og si øyeblikkelig. Dette ble klart for meg på tidlig nittitall, da jeg skrev om et av de første objektorienterte forretningssystemene: Da systemet var helt nytt, tok det flere minutter å skrive ut en faktura, i et firma med to millioner kunder. Den tiden gikk ned til noen få sekunder etter at man hadde optimalisert de mest brukte underliggende komponentene (Andersen & Konsynski, 1992; Davis & Morgan, 1993).

Og der har du forskjellen på digital og fysisk ytelsesforbedring – en forskjell som gjør at så fort noe blir digitalt, tar det av i forhold til alle andre teknologier. Den hastigheten har du ikke i generativ AI – i hvert fall ikke i resultatene – inntil språkmodellen lærer å reflektere over sitt eget handlemønster, dekomponere det og deretter optimalisere de mest brukte objektene.

Og det er ikke noe man kommer til å få til med Vibe coding med det første i alle fall…

Referanser:

Andersen, Espen, and Benn R. Konsynski. 1992. “Brooklyn Union Gas: OOPS on Big Iron.” HBS Case 192-144
Davis, John, and Tom Morgan. 1993. “Object-Oriented Development at Brooklyn Union Gas.” IEEE Software (January):67–74.
Kuhn, Thomas S. 1962. The Structure of Scientific Revolutions. Chicago, IL: The University of Chicago Press.
Learner, Sam. 2026. “Who Cleans up after the Vibe-Coding Party?” Financial Times, July 11.
Singh, Tarry. (2019) “Software Ate The World, Now AI Is Eating Software.” Forbes (Cognitive World), Retrieved August 19, 2026.