Michael JohnsonEn KI-kodegransker kan legge igjen dusinvis av kommentarer og likevel overse en feil som er viktig før en utgivelse. 5. oktober 2026 presenterte GitHub ReviewBench – en forskningsforhåndsvisning av et referanseverktøy som sammenligner agenter ut fra problemene de finner, det de overser, og hvor presise kommentarene er.
For utviklere er det viktigste skiftet at man går fra å telle kommentarer til å vurdere innholdet i dem. Referanseverktøyet sammenligner agentens resultater med et fasitsett av problemer for pull requests og tar særskilt hensyn til alvorlighetsgrad og kategori for funnene.
Hva vurderer ReviewBench?
Datasettet omfatter 219 offentlige pull requests fra 187 åpent lisensierte repositorier, med kode på 19 språk. GitHub opplyser at selskapet analyserte fordelingen av over 103,9 millioner PR-er da det satte sammen datasettet. Størrelsen på repositoriene og språkfordelingen ble valgt med utgangspunkt i det samlede GitHub-utvalget, mens størrelsen på endringene med hensikt ble dreid mot mer omfattende PR-er som egner seg for kodegranskning.
For hver PR inneholder referanseverktøyet fasitkommentarer med merker for alvorlighetsgrad og kategori – for eksempel korrekthet, sikkerhet, pålitelighet, vedlikeholdbarhet og testing. ReviewBench måler presisjon: hvor stor andel av agentens kommentarer som samsvarer med faktiske problemer, og fullstendighet: hvor stor andel av kjente problemer agenten fant. Fβ-målet lar brukeren endre den relative vektingen av disse to kriteriene: større vekt på fullstendighet passer når man vil finne flere problemer, mens større vekt på presisjon bidrar til å redusere støyende kommentarer.
Slik tolker du tallene fra GitHub
Publiseringen oppgir 96,6 % samsvar mellom merkingen i ReviewBench og en uavhengig ny gjennomgang utført av senioringeniører. Dette måler hvor godt ekspertene var enige om referansefunnene, ikke presisjonen til en KI-agent.
GitHub beskrev også en separat intern A/B-test av en ensemblemodell for Copilot-kodegranskning. Ifølge selskapet økte andelen kommentarer som ble fulgt av relevante kodeendringer med 8,0 % sammenlignet med kontrollgruppen; fullstendigheten økte med 13,6 %, kommentarvolumet med 61 %, og kostnaden for kodegranskningen gikk ned med 8,0 %. Dette er resultatene fra ett av GitHubs eksperimenter, ikke en vurdering av alle agenter eller et løfte om samme effekt i andre team.
Det er særlig nyttig å holde målemetodene fra hverandre når teamet skal velge innstillinger for kodegranskning. Et stort antall kommentarer kan gå hånd i hånd med flere nyttige funn, men viser ikke i seg selv hvor mange av dem som ble bekreftet. ReviewBench deler også opp resultatene etter alvorlighetsgrad og kategori, slik at teamet for eksempel kan se særskilt på kritiske feil eller sikkerhetsspørsmål.
Slik prøver du referanseverktøyet
Ifølge GitHubs beskrivelse gir forskningsforhåndsvisningen tilgang til hele datasettet, mulighet til å sammenligne publiserte resultater og mulighet til å kjøre sin egen agent. En foreløpig kjøring omfatter 25 PR-er; en full kjøring dekker 219 PR-er fordelt på tre runder. Deltakeren oppgir et containerbilde, en konfigurasjon og sin egen modellnøkkel, mens evalueringen utføres med en felles dommermodell. Resultatene forblir private fram til innsendingen er gjennomgått og godkjent.
Den praktiske verdien av en slik kjøring er å få et sammenlignbart utgangspunkt og deretter teste systemet mot egne retningslinjer for kodegranskning og endringer som er typiske for repositoriet. Forholdene i et bestemt team – språk, arkitektur, terskler for alvorlighetsgrad og hvor mye støy som er akseptabelt – kan avvike fra sammensetningen av det generelle datasettet.
GitHub hevder at endringer i de offline-baserte evalueringene i ReviewBench samsvarte med utviklingen i resultatene under reell bruk i selskapets eksperimenter. De publiserte målingene gjelder selskapets egne tester. Den mest pålitelige bruken av referanseverktøyet nå er derfor å sammenligne agenter på et felles utvalg og kartlegge styrkene deres. En beslutning om innføring bør også bygge på testing i arbeidsflyten til det aktuelle teamet.