De v1-benchmark van CodeVetter doorloopt 27 synthetische gevallen via een door AI gestuurde code-review-pipeline en registreert of de tool de ingebouwde bugs ontdekt. Vervolgens wordt voor elk geval bijgehouden of deze is geslaagd of niet.

Waarom de benchmark belangrijk is

De test stelt een specifieke vraag: kan een bepaalde reviewer exact de defecten herkennen die de ontwerpers van de benchmark in deze vaste set codefragmenten hebben ingebouwd? Ontwikkelaars kunnen het resultaat gebruiken als een snelle controle van de issue coverage. Omdat de repository de taakpakketten en het scoring-script bevat, kan iedereen de test opnieuw uitvoeren en dezelfde resultaten krijgen.

Wat de benchmark niet bewijst

Een synthetische suite van 27 gevallen is geen vervanging voor de duizenden pull requests die een team dagelijks verwerkt. De benchmark zegt niets over:

  • Diversiteit in de echte wereld – het beslaat slechts enkele talen en een beperkt aantal categorieën van bugs.
  • Prestaties – het biedt geen metingen van timing of rekenkosten.
  • Betrouwbaarheid over verschillende codebases – zonder testen in live-repositories kunnen we niet weten of de tool subtiele defecten zal missen of valse positieven zal genereren in productie.

Het combineren van de gepubliceerde resultaten met de infrastructuur-bestanden en beloften van toekomstige "brede, realistische data" creëert een marketingverhaal dat de enkele score staat voor productiebestendige capaciteit, wat de data niet ondersteunt.

Hoe deze benchmark past in het bredere test-ecosysteem

Benchmarks die gericht zijn op herkenning, zoals die van CodeVetter, brengen het bereik in kaart dat een tool kan aanpakken. Ze vormen een aanvulling op functionele benchmarks zoals SWE-bench, die controleren of een door AI gegenereerde patch daadwerkelijk een echt probleem in een bestaande codebase oplost. Samen geven ze een vollediger beeld: dekking versus effectiviteit.

Een goede agent-benchmark zou de volledige stack bloot moeten leggen:

  1. De dataset – ruwe inputs en verwachte outputs.
  2. Documentatie per geval – een pagina voor elke test die de bug, de juiste fix en de reactie van de tool laat zien.
  3. Reviewer-outputs – de exacte opmerkingen of suggesties die de AI heeft gegenereerd.
  4. Scoringmethodologie – hoe matches worden beoordeeld, inclusief tolerantie voor gedeeltelijke punten.
  5. Instructies voor reproduceerbaarheid – versie-pins, hardware-details en scripts om de test opnieuw uit te voeren.

Pas wanneer al deze onderdelen transparant zijn, kunnen we een enkele geaggregeerde score vertrouwen.

Beperkingen die de benchmark zelf vermeldt

  • Synthetische gevallen, niet afkomstig uit live-repositories.
  • Beperkte selectie van talen en bugtypes.
  • Geen timing- of kostengegevens, dus efficiëntie is onbekend.
  • Precisiebeperkingen die grensgevallen kunnen maskeren.

Waar u op moet letten in de toekomst

De volgende stap voor CodeVetter — en voor iedereen die AI-reviewers gebruikt — is herhaaldelijk bewijs op grotere, meer gevarieerde corpora. Dat betekent het publiceren van resultaten op echte pull-request-stromen, het rapporteren van latentie en rekenverbruik, en het uitsplitsen van foutmodi per categorie. Totdat dergelijke gegevens beschikbaar zijn, moet de score van 27 gevallen worden beschouwd als een vroege indicator, niet als een garantie voor gereedheid.

Kernpunt: Een benchmark die u alleen vertelt of een tool een handvol vooraf geschreven bugs kan vinden, is nuttig voor een sanity-check, maar het certificeert niet dat de tool de rommelige, kostengevoelige realiteit van code-review in productie zal overleven.