Hva skjedde da AI kom til Glow

Morten Andersen-Gott · JavaZone 2026, Room 6 (lightning talk) Programsiden på JavaZone

Glow er et transport management-system (TMS) utviklet av Glow Technology, et heleid datterselskap av Posten: ruteplanlegging, kundeportal, sjåfør-app og mottakeropplevelse for last-mile-levering. Systemet leverer flere millioner pakker i måneden, og skal i løpet av året dekke all last-mile-levering i Norden i Posten Bring-systemet.

▶ Se dette i opptaket

Konteksten: et erfarent team med en delt kodebase

Teamet er 12 utviklere, mest konsulenter, med en gjennomsnittserfaring på 20+ år – "en haug med erfarne konsulenter som har valgt utviklingen som sitt fag." Morten kaller det det sterkeste og hyggeligste teamet han har jobbet i. Stacken er Kotlin med Arrow for funksjonell støtte, ren SQL mot databasen (bevisst uten Spring eller ORM-rammeverk – "vi synes at Tomcat har spilt alt for høyt i går"), og en kodebase fra 2018 som ble portet fra Java til Kotlin. Den eldre delen av koden bruker Map som databærer for hastighet; den nyere stilen bruker sterkt typede dataklasser. Kodebasen er altså bevisst delt mellom to stiler.

Onboarding av en AI-utvikler er som å onboarde en junior

Mot slutten av 2025 fikk teamet inn Codex og Copilot som om de var nye utviklere – og de trengte onboarding, akkurat som et menneske. Det ble en agentfil som utviklet seg underveis: "hvorfor gjorde den det? Nei, vi skriver ikke sånn kode her, det må vi slutte med."

To ting var spesielt vanskelige for agenten:

1. Den delte kodebasen. Sitter agenten i en fil skrevet i gammel stil, er det naturlig at den fortsetter i den stilen – selv når teamet ønsker ny kode i ny stil.
2. Treningsdataen sitter fast. En forskningsrapport fra 2024 fant at når forskere ba en agent bytte fra snake_case (vanlig i Python) til camelCase (mer Kotlin-aktig), fulgte den instruksjonen en stund – for så å gli tilbake til treningsdataens vaner. Modeller sliter med å komme seg helt ut av det de er trent på.

Entusiasme først, edruelighet etterpå

Den første perioden var preget av entusiasme – litt som når et lite barn tar sine første skritt: "den løp inn på badet og kom nesten frem, men det ble tiss på gulvet likevel." Men det var ikke bare modellen som var umoden. Teamet slapp AI-en litt ukritisk løs, og fikk store, rotete PR-er tilbake. En kollega som skulle reviewe kunne bli møtt med "jeg vet ikke, det var AI som skrev det" – som om AI-opphav gjorde det greit å ikke stå inne for koden.

▶ Se dette i opptaket

Spørsmålene teamet stilte var også ofte for åpne: "hvorfor feiler det her?" Svaret kom da tilbake med stor selvsikkerhet – men pekte gjerne på feil nivå. I ett eksempel forklarte agenten et nullfelt i databasen med "fordi du aksepterer null inn i API-et ditt" – riktig observasjon, men feil årsak: den egentlige bugen lå dypere, i kjernen, og krevde at man kjente koden for å forstå hvorfor.

Påske-vippepunktet

Rundt påske 2026 endret ting seg – et "slag i trynet" for en selverklært skeptisk "gretten gubbe". Teamet begynte å bruke Claude, og opplevde en tydelig kvalitetsheving: agenten forsto koden og domenet bedre, og ble flinkere til å analysere. Samtidig endret arbeidsmåten seg – teamet tok mer eierskap til PR-ene sine. Den nye arbeidsflyten:

1. Spør AI-en først: "dette er det jeg skal lage – hva tenker du om det?"
2. Diskuter frem og tilbake til det virker som en farbar vei.
3. La den skrive koden.
4. Se på koden selv – det er teamet som skal eie den. Pushback på stil, abstraksjoner og kvalitet.
5. Lag en pull request. GitHub Copilot reviewer automatisk – "den har et syndrom hvor den må si noe", men ofte er poengene ikke dumme.
6. Egen vurdering til slutt. Og når koden er god nok til å sette inn til en kollega, er det ikke lenger "lov å kritisere fordi AI skrev det" – det er lov å kritisere fordi jeg har skrevet den.

flowchart TD
    A["Spør AI: 'dette skal jeg lage - hva tenker du?'"] --> B[Diskuter fram og tilbake]
    B --> C{Farbar vei?}
    C -- Nei --> B
    C -- Ja --> D[AI skriver koden]
    D --> E[Utvikler leser og gir pushback<br/>på stil, abstraksjoner, kvalitet]
    E --> F{Står jeg inne for denne koden?}
    F -- Nei --> D
    F -- Ja --> G[Pull request]
    G --> H[Copilot auto-review]
    H --> I[Egen vurdering av innspillene]
    I --> J[Sendes til kollega -<br/>kritiseres som MIN kode, ikke 'AI-kode']

Hvor den er sterk, og hvor den fortsatt tisser på gulvet

Analyse av eksisterende kode er blitt veldig god – agenten leser og forstår raskt det som allerede finnes. Store nye features fra bunnen av er vanskeligere: den kan bli ivrig, bomme på abstraksjoner, og – særlig på tvers av kodebasen – ikke oppdage at ny kode ligner på noe som allerede finnes et annet sted.

▶ Se dette i opptaket

Den kan fortsatt gjøre graverende, potensielt katastrofale feil – teamet har flere eksempler på forsøk på å pushe en lokal branch rett til master. Det er en av grunnene til at agenten aldri får tilgang til produksjonsdatabaser eller -systemer hos Glow, uansett hvor god den blir. Og aksepterer man små unøyaktigheter over tid, forvitrer kodebasen gradvis. Derfor blir det å jobbe i små inkrementer viktigere enn noen gang – med to-tre hundre linjer i en PR er det fort gjort å godta noe man er "litt uenig i variabelnavnet på, men kjør på". Med små, hyppige leveranser er det lettere å holde et bevisst forhold til hver linje.

Stabilitet slår produktivitet

Glow er et system som brukes ekstremt mye og blir bare viktigere. Selv om man i teorien kan produsere mye mer kode med AI-hjelp, er ikke det målet i seg selv – mer kode som kjører påvirker ytelse, minne og IO, og en høyere takt på nye features er ikke nødvendigvis bra hvis brukerne eller teamet ikke klarer å ta det innover seg.

▶ Se dette i opptaket

Ubesvarte spørsmål

Morten sitter igjen med et åpent spørsmål: teamet kjenner denne kodebasen ekstremt godt selv, og kan raskt se når noe agenten skriver ikke gir mening i akkurat denne konteksten. Men hva skjer med utviklere som er nye i en kodebase, og som lener seg på AI uten selv å lese og forstå det som skjer? Lærer man kodebasen hvis man bare interagerer med diffen AI-en skriver? Og – siden kode i bunn og grunn er forretningsregler skrevet for en datamaskin – mister man forretningsforståelsen samtidig? Dette er en erfaringsrapport fra 6–7 måneder, med mye endring på veien. Hvordan det ser ut om et halvt år til, inkludert dagen "AI-selskapene finner ut hva det faktisk koster å bruke det de tilbyr", er et åpent spørsmål.

Nøkkeltakeaways

• Behandle AI-en som en junior, ikke en senior – uansett hvor selvsikker den høres ut.
• Ha et aktivt forhold til agentfilen: gjør den noe rart, gjør den det antagelig igjen, og en delt, oppdatert fil peiler den inn på riktig vei.
• Eierskapet til koden er fortsatt ditt. Du skriver den, du eier den – ikke "AI-en som medforfatter har skylden".
• Jobb i små inkrementer – det er den beste forsikringen mot å miste det kritiske blikket.
• Stabilitet vinner alltid over produktivitet i et system som dette.