Michael JohnsonEen AI-reviewer kan tientallen opmerkingen plaatsen en toch een fout missen die belangrijk is voor een release. Op 5 oktober 2026 introduceerde GitHub ReviewBench — een onderzoekspreview van een benchmark die agents vergelijkt op gevonden problemen, gemiste problemen en de nauwkeurigheid van opmerkingen.
Voor ontwikkelaars is vooral de verschuiving van het tellen van opmerkingen naar het beoordelen van hun inhoud van belang. De benchmark vergelijkt de uitvoer van een agent met een referentieset van problemen voor pull requests en houdt afzonderlijk rekening met de ernst en categorie van bevindingen.
Wat beoordeelt ReviewBench precies?
De dataset bevat 219 openbare pull requests uit 187 open-source-repositories met code in 19 talen. GitHub meldt dat het bij het samenstellen van het corpus de verdeling van meer dan 103,9 miljoen PR’s heeft geanalyseerd. De omvang van repositories en de verdeling over talen zijn afgestemd op de algemene GitHub-steekproef. De omvang van wijzigingen is bewust verschoven naar inhoudelijkere PR’s die geschikt zijn voor review.
Voor elke PR bevat de benchmark referentieopmerkingen met labels voor ernst en categorie, zoals correctheid, beveiliging, betrouwbaarheid, onderhoudbaarheid en testen. ReviewBench berekent de precisie: welk deel van de opmerkingen van een agent overeenkomt met daadwerkelijke problemen; en de recall: welk deel van de bekende problemen de agent heeft gevonden. Met de Fβ-score kan het relatieve gewicht van deze twee criteria worden aangepast: een hoger gewicht voor recall is geschikt om meer problemen op te sporen, terwijl een hoger gewicht voor precisie helpt om ruisachtige opmerkingen te beperken.
Hoe lees je de cijfers van GitHub?
In de publicatie staat dat ReviewBench-labels voor 96,6% overeenkwamen met een onafhankelijke herbeoordeling door senior engineers. Dit is een maat voor de overeenstemming tussen experts bij het beoordelen van referentiebevindingen, niet voor de nauwkeurigheid van een AI-agent.
GitHub beschreef daarnaast een interne A/B-test van een ensemble van modellen voor Copilot-code-review. Volgens het bedrijf steeg, ten opzichte van de controlegroep, het aandeel opmerkingen dat werd gevolgd door overeenkomstige codewijzigingen met 8,0%, de recall met 13,6% en het aantal opmerkingen met 61%, terwijl de kosten van reviews met 8,0% daalden. Dit zijn resultaten van één experiment van GitHub; ze vormen geen beoordeling van alle agents en zijn geen garantie op hetzelfde effect bij andere teams.
Het onderscheid tussen de meetwaarden is vooral nuttig wanneer een team de instellingen voor code-review kiest. Een groot aantal opmerkingen kan samengaan met meer bruikbare bevindingen, maar op zichzelf zegt dat niet hoeveel daarvan bevestigd zijn. ReviewBench splitst de resultaten ook uit naar ernst en categorie, zodat een team bijvoorbeeld afzonderlijk kan kijken naar kritieke fouten of beveiligingsproblemen.
Hoe probeer je de benchmark uit?
Volgens de beschrijving van GitHub kun je met de onderzoekspreview de volledige dataset bekijken, gepubliceerde resultaten vergelijken en je eigen agent uitvoeren. Voor een eerste test zijn 25 PR’s beschikbaar; de volledige uitvoering omvat 219 PR’s in drie rondes. Deelnemers leveren een containerimage, configuratie en eigen modelsleutel aan, waarna de evaluatie met een gemeenschappelijke beoordelaar wordt uitgevoerd. De resultaten blijven privé totdat de inzending is gecontroleerd en goedgekeurd.
Het praktische doel van zo’n test is een vergelijkbaar uitgangspunt te krijgen en vervolgens het systeem te toetsen aan de eigen reviewregels en wijzigingen die kenmerkend zijn voor de repository. De omstandigheden van een specifiek team — talen, architectuur, ernstgrenzen en aanvaardbare hoeveelheid ruis — kunnen afwijken van de samenstelling van het algemene corpus.
GitHub stelt dat veranderingen in de offline-evaluaties van ReviewBench in de eigen experimenten dezelfde richting op wezen als resultaten in de praktijk. De gepubliceerde metingen hebben betrekking op tests van het bedrijf zelf. De betrouwbaarste toepassing van de benchmark is daarom voorlopig het vergelijken van agents op een gedeelde dataset en het analyseren van hun sterke punten. Een besluit over invoering kan het beste ook worden gebaseerd op tests in de workflow van het specifieke team.