Review-flaskehalsen: Når AI produserer raskere enn teamet kan vurdere

Balansen som er borte

Regnestykket i et utviklingsteam har alltid hatt to sider: hvor fort kode produseres, og hvor fort den kan vurderes. I tiår har de to sidene vært i grov balanse, fordi å skrive kode tok tid og review-køen dermed holdt tritt. Den balansen er borte.

Generering er blitt nesten gratis, mens vurdering koster det samme som før: menneskelig oppmerksomhet, kontekst og tid. Resultatet ser du i teamet ditt allerede. PR-køen vokser og reviews blir overfladiske – eller de blir grundige, og da stopper alt.

Flaskehalsen har flyttet seg, og den har flyttet seg til det eneste stedet som ikke kan automatiseres bort: forståelsen.

Det nye asymmetriproblemet

En utvikler produserer nå kode raskere enn noen gang. Hvor mye raskere, er vanskelig å måle: METRs kontrollerte forsøk fant i 2025 at erfarne utviklere ble 19 prosent tregere med AI, og oppfølgingen fra februar 2026 peker mot rundt 18 prosent raskere for de samme utviklerne – et tall METR selv kaller upålitelig, fordi utviklere nå nekter å jobbe uten AI. Men revieweren må fortsatt forstå hver linje, og forståelse har ikke fått noen turbolader.

Verre: AI-generert kode er ofte tyngre å reviewe enn håndskrevet. Den er lengre. Den er mer «komplett» – med feilhåndtering og edge cases forfatteren ikke har tenkt gjennom. Og den mangler det viktigste signalet en reviewer har: visshet om at noen allerede har tenkt.

Dette er målt, ikke antatt. GitClear har målt 623 millioner kodeendringer fra 2023 til så langt i 2026, og sammenligner med 2022, det siste året før AI. Da var 21 prosent av endrede linjer flyttet kode – det maskinelle sporet etter refaktorering – og 9,4 prosent kopiert. Så langt i 2026 er 3,8 prosent flyttet og 15,7 prosent kopiert. Krysningen kom i 2024, det første året det ble kopiert mer enn det ble flyttet. Tallene for 2026 er foreløpige, og retningen er ikke det. Det er ingen dom over hver enkelt linje. Det er en beskrivelse av hva review-køen din fylles med.

Og køen er målt også. LinearBs benchmark for 2026, 8,1 millioner pull requests fra 4 800 team, viser at AI-assisterte PR-er er rundt to og en halv gang større enn håndskrevne – over 400 linjer mot 157 på 75-persentilen – og at AI-genererte PR-er venter over 16 timer på første reviewer, mot rundt 200 minutter for de håndskrevne. Under en tredjedel av dem blir merget innen 30 dager; håndskrevne blir det i 84,5 prosent av tilfellene. LinearBs egen konklusjon er denne artikkelens: code review er den kritiske begrensningen i AI-assistert utvikling.

Asymmetrien skaper et valg ingen vil ta høyt: senk tempoet, eller senk kvaliteten på vurderingen. De fleste team velger det siste uten å bestemme det, én PR om gangen.

Fellen: Tech lead som eneste port

Den instinktive responsen er sentralisering: «alle større PR-er skal innom meg.» Det er forståelig. Og det er nøyaktig feil.

Jeg har sett en principal engineer gjøre det. Køen hans vokste til én runde review kunne ta opptil en uke, og slik sto det i et par måneder. Amazon gjorde det samme i stort i mars 2026: etter flere alvorlige utfall pekte et internt notat på GenAI-assisterte endringer, og svaret ble at slike endringer må godkjennes av en senior ingeniør. Amazon sa siden at bare én av hendelsene involverte AI, og at årsaken var en brukerfeil som systemene lot ramme for bredt. Ifølge Sonars undersøkelse for 2026 sier 38 prosent av utviklere allerede at AI-kode krever mer innsats å reviewe enn en kollegas. Den innsatsen flyttes nå til de færreste og dyreste. Faros’ AI Engineering Report fra våren 2026, to år med telemetri fra 22 000 utviklere, måler den flyttingen: der AI-bruken er høyest, har median tid i review økt 441,5 prosent, og 31,3 prosent flere PR-er merges uten review i det hele tatt. Rapporten kaller det skatten på seniorene: koden ser ut som om den er skrevet av noen som vet hva de gjør, og feilene ligger under overflaten. Oppfølgingen fra september 2026, The Speed Trap, ser på team som allerede bruker AI tungt, og der bruken går dypere, har økningen i PR-er som merges uten review, gått fra 31,3 til 76,3 prosent, tiden i QA har økt 300,6 prosent, og tiden i review er fortsatt sterkt forhøyet. Faros’ konklusjon står fast fra april: den største gevinsten ligger der koden skrives.

Som jeg skrev i Tech lead i AI-alderen: når kompleksiteten øker, er det fristende å stramme inn med mer kontroll og mer godkjenning. Men det skaper flaskehalser – og nå snakker vi om en flaskehals som allerede er overbelastet.

Du kan ikke reviewe deg ut av dette. Ingen kan. Du må bygge mekanismer i stedet.

Mekanismer som skalerer vurdering

1. Automatiser førstelinjen

Alt som kan sjekkes av verktøy, skal sjekkes av verktøy: formatering, naming, kjente mønsterbrudd, sikkerhetsregler. Analyseverktøy og CI-porter er ikke nytt, men verdien deres har mangedoblet seg. Hver automatiserte sjekk frigjør menneskelig oppmerksomhet til det bare mennesker kan: vurdere om koden hører hjemme.

2. Flytt kvaliteten oppstrøms

Den billigste reviewen er den som ikke trengs. Kontekstfiler og delte prompts gjør at generert kode ligner systemet fra start. Divergens er det som koster review-tid.

3. Forklaringsplikt reduserer vurderingskostnaden

En PR der forfatteren har forklart valgene, gjør reviewerens jobb langt lettere. Revieweren skal ikke lenger rekonstruere tankegangen, bare vurdere den. Det er derfor «forstå før du merger» er en tempo-optimalisering like mye som et kvalitetsprinsipp.

4. Størrelse som norm

Store genererte PR-er er der vurderingen bryter sammen. Sett en tydelig norm: del opp oppgaven til den får plass i én liten PR. I praksis tar en middels stor PR tre til fem runder i review. Den samme endringen delt i tre små blir godkjent på én til to. AI gjør det billig å produsere mye. Da må teamet gjøre det normalt å levere lite om gangen.

5. Distribuer review-kompetansen

Hvis bare to personer kan vurdere arkitektoniske avvik, har dere to flaskehalser. Bruk parreviews og roterende reviewere bevisst – ikke for rettferdighet, men for å bygge vurderingskapasitet i hele teamet.

Det handler om å beskytte tempoet

Merk hva dette ikke er: et argument for å bremse. Det er det motsatte. Team som ignorerer asymmetrien, får ett av to utfall: en voksende kø som dreper flyten, eller en voksende mengde uforstått kode som dreper den senere. Begge er tempo-tap, bare med ulik forsinkelse.

Mekanismene over er der for å bevare farten AI gir. Samme logikk som i Beslutningslatens: fremdrift beskyttes av struktur, ikke av innsats.

Bygg porten, ikke bemann den

Flaskehalsen i programvareutvikling har flyttet seg, fra å skrive kode til å forstå den. Det er ikke et problem som løses med flinkere reviewere eller lengre dager. Det løses med mekanismer: automatisering, kontekst, forklaringsplikt, små enheter, distribuert kompetanse.

Tech leadens jobb er ikke å stå i porten. Det er å bygge porten slik at den ikke trenger å bemannes av én person.

Vurderingskapasiteten er blitt teamets knappeste ressurs, og den vokser bare når flere enn deg kan lese en PR og si hva som mangler.