Code review i AI-alderen: Å vurdere kode ingen har skrevet

Forutsetningen som ikke lenger holder

Code review har alltid hatt en stilltiende forutsetning: at forfatteren forstår koden bedre enn revieweren. Forfatteren har tenkt gjennom problemet, veid alternativene og tatt et valg; revieweren kommer inn med friske øyne og stiller spørsmål.

Den forutsetningen holder ikke lenger. I dag kan en PR inneholde kode forfatteren fikk generert på tretti sekunder. Koden er ryddig, navnene gir mening og testene passerer. Men når du spør «hvorfor valgte du denne tilnærmingen?», blir det stille. Det er ikke latskap, men en ny virkelighet – og den krever en ny review-praksis.

Når begge parter møter koden for første gang

En utvikler får generert feilhåndtering for en integrasjon. Koden bruker tenacity med eksponentiell backoff:

@retry(stop=stop_after_attempt(5),
       wait=wait_exponential(multiplier=1, max=60))
def hent_faktura(id):
    return client.get(f"/invoices/{id}", timeout=30)

Elegant. Gjennomtenkt. Godkjent.

Tre uker senere feiler integrasjonen i produksjon, og ingen vet hvorfor retries oppfører seg som de gjør – verken forfatteren, revieweren eller noen andre. Koden ble aldri forstått, bare akseptert – og det skjedde to ganger.

Se hva som faktisk står der. Fem forsøk gir fire ventetider på 1, 2, 4 og 8 sekunder, til sammen 15. max=60 slår aldri inn; taket ville først bitt ved sjuende forsøk, og det kommer aldri. Parameteren ser vurdert ut og gjør ingenting.

Timeouten er derimot 30 sekunder per forsøk. I verste fall blir det 15 sekunder venting pluss fem forsøk på opptil 30 sekunder hver: nærmere tre minutter i én kallkjede. Ligger dette bak et HTTP-endepunkt med 30 sekunders timeout i andre enden, har klienten gitt opp for lengst, og retry-logikken jobber videre for en mottaker som for lengst har gått.

Og så det motsatte problemet, i samme linje: med Tenacitys standard retry-policy utløses @retry bare ved unntak. client.get() kan, avhengig av klienten, la være å kaste ved 503 Service Unavailable og i stedet returnere svaret som det er. Så det ene svaret som faktisk fortjente et nytt forsøk, får det aldri. Samtidig fanger @retry som standard alle unntak som oppstår, også de som et nytt forsøk aldri vil hjelpe mot: et feilstavet vertsnavn, et utgått sertifikat.

Så en 503 blir ikke forsøkt igjen, og et feil vertsnavn blir forsøkt fem ganger.

Ingen av tallene er gale i seg selv. Problemet er at parametrene aldri egentlig ble valgt for denne situasjonen.

Som jeg skrev i Tech lead i AI-alderen: problemet er sjelden mangel på svar. Det er mangel på struktur rundt dem.

Fra «er dette bra?» til «hører dette hjemme her?»

AI-generert kode kan se veldig bra ut lokalt, og det er nettopp det som er faren. Modellen er trent på beste praksis fra hele verden, men den kjenner ikke systemet ditt. Den vet ikke at dere allerede har et retry-mønster, at logging skal ha korrelasjons-IDer, eller at akkurat denne modulen har en historikk som forklarer hvorfor ting gjøres annerledes.

Alt kan se riktig ut og likevel bryte helheten. Review må derfor flytte fokus:

• Ikke «er koden korrekt?» – det fanger tester og statiske analyseverktøy ofte bedre
• Men «passer den inn?» – følger den mønstrene våre, eller introduserer den et nytt?
• Og viktigst: «forstår forfatteren den?»

Forklaringsplikten

Det mest effektive grepet jeg har sett, er også det enkleste:

Den som åpner en PR, skal kunne forklare den.

Det er en norm, ikke et forhør, og i praksis betyr den:

• komplekse valg forklares i PR-beskrivelsen, med egne ord
• nye mønstre flagges eksplisitt: «dette avviker fra slik vi gjør det – bevisst»
• «AI foreslo det» er aldri en begrunnelse

Dette er samme prinsipp som i Hvordan etablere tekniske standarder som faktisk etterleves: forventningene må være tydelige i hverdagen, ikke i et dokument ingen leser.

Det trengs ikke noe apparat rundt dette. Én linje i PR-malen holder lenge:

«Er deler av denne endringen generert? Forklar valgene du har godkjent.»

Det er ingen streng regel. Linux-kjernen, som har en av de mest krevende review-kulturene som finnes, har det samme stående i prosessdokumentasjonen sin: du forventes å forstå og kunne forsvare alt du sender inn, og kan du ikke det, skal du la være. Sender du likevel, har vedlikeholderne rett til å avvise bidraget uten grundig gjennomgang. Våren 2026 kom retningslinjene for AI-assistenter i tillegg: generert kode bør merkes med en Assisted-by:-linje, og bare et menneske kan signere den, for bare et menneske kan stå til ansvar. Terminalprosjektet Ghostty sier det enda kortere i AI-policyen sin: kan du ikke forklare hva endringen gjør, og hvordan den virker sammen med resten av systemet, uten hjelp av AI-verktøy, så la være. Kubernetes gikk lengst i juni 2026: kan du ikke selv forklare endringer AI har hjulpet deg med, blir PR-en lukket, og reviewerne forventer å diskutere med et menneske, ikke med en modell.

Reviewerens nye ansvar

Revieweren kan ikke lenger anta at noen har tenkt gjennom koden. Mistillit har ingenting med saken å gjøre; det er spørsmålene som må endres:

• «Hva skjer hvis dette kallet feiler?»
• «Hvorfor dette mønsteret og ikke det vi bruker i naboklassen?»
• «Kan du gå gjennom flyten med meg?»

Legg merke til formen: ikke «dette er feil», men «hjelp meg å forstå».

Hvis forfatteren kan svare, er alt i orden, uansett hvem eller hva som skrev koden. Kan hen ikke det, er det reviewens viktigste funn.

Tech leadens rolle

Som tech lead skal du ikke reviewe alt. Det skalerer ikke, og det skaper flaskehalser – samme mekanisme som beskrevet i Det tause ansvaret.

Din jobb er å bygge mekanismene:

• PR-maler som gjør forståelse eksplisitt
• eksempelkode som viser hva «bra» betyr hos oss
• en kultur der «jeg forstår ikke dette» er et godkjent review-funn
• automatisert håndheving av det som kan automatiseres, slik at menneskene kan bruke tiden på det som ikke kan

Review etter at koden ble billig

Code review har aldri bare handlet om å finne feil. Det har også handlet om delt forståelse, og det er den delen AI ikke endrer, bare gjør tydeligere. Når kode kan produseres uten å forstås, blir review det siste stedet forståelsen kan sikres.

Da er spørsmålet ikke lenger om koden er god nok til å merge, men om noen i rommet kan forklare hvorfor den ser slik ut.