Benchmark v1 narzędzia CodeVetter przepuszcza 27 syntetycznych przypadków przez potok (pipeline) przeglądu kodu oparty na AI i rejestruje, czy narzędzie wykryje celowo wprowadzone błędy. Następnie sumuje wyniki pozytywne i negatywne dla każdego przypadku.

Dlaczego ten benchmark jest ważny

Test stawia wąskie pytanie: czy dany recenzent potrafi rozpoznać dokładnie te wady, które projektanci benchmarku umieścili w tym stałym zestawie fragmentów kodu? Deweloperzy mogą wykorzystać wynik jako szybki sposób na sprawdzenie zakresu wykrywania problemów. Ponieważ repozytorium zawiera pakiety zadań i skrypt oceniania, każdy może ponownie uruchomić test i uzyskać te same wyniki.

Czego ten benchmark nie dowodzi

Syntetyczny zestaw 27 przypadków nie zastąpi tysięcy pull requestów, którymi zespół zarządza każdego dnia. Benchmark nie mówi nic o:

  • Różnorodności w świecie rzeczywistym – obejmuje tylko kilka języków i ograniczony zakres kategorii błędów.
  • Wydajności – nie dostarcza pomiarów czasu ani kosztów obliczeniowych.
  • Niezawodności w różnych bazach kodu – bez testów na żywych repozytoriach nie możemy wiedzieć, czy narzędzie nie przeoczy subtelnych wad lub nie wygeneruje fałszywych alarmów (false positives) w środowisku produkcyjnym.

Łączenie opublikowanych wyników z plikami infrastruktury i obietnicami przyszłych „szerokich, realistycznych danych” tworzy narrację marketingową, jakoby pojedynczy wynik reprezentował gotowość do pracy produkcyjnej, czego dane nie potwierdzają.

Jak ten benchmark wpisuje się w szerszy ekosystem testowania

Benchmarki typu „rozpoznawanie” (recognition-style), takie jak CodeVetter, mapują obszar, z jakim narzędzie może sobie poradzić. Uzupełniają one benchmarki funkcjonalne, takie jak SWE-bench, które sprawdzają, czy poprawka wygenerowana przez AI faktycznie rozwiązuje rzeczywisty problem w istniejącej bazie kodu. Razem dają pełniejszy obraz: zakres pokrycia kontra skuteczność.

Dobry benchmark agenta powinien ujawniać pełny stos (full stack):

  1. Zbiór danych – surowe dane wejściowe i oczekiwane wyniki.
  2. Dokumentacja każdego przypadku – strona dla każdego testu pokazująca błąd, poprawną poprawkę i odpowiedź narzędzia.
  3. Wyniki recenzenta – dokładne komentarze lub sugestie wygenerowane przez AI.
  4. Metodologia oceniania – jak oceniane są dopasowania, w tym tolerancja na częściowe punkty.
  5. Instrukcje reprodukowalności – przypięte wersje, szczegóły sprzętowe i skrypty do ponownego uruchomienia testu.

Tylko wtedy, gdy wszystkie te elementy są przejrzyste, możemy ufać pojedynczemu wynikowi zagregowanemu.

Ograniczenia wymienione przez sam benchmark

  • Syntetyczne przypadki, niepobrane z żywych repozytoriów.
  • Wąski wybór języków i typów błędów.
  • Brak danych dotyczących czasu lub kosztów, więc wydajność jest nieznana.
  • Ograniczenia precyzji, które mogą maskować przypadki graniczne.

Na co zwrócić uwagę w przyszłości

Kolejnym krokiem dla CodeVetter — i dla każdego, kto korzysta z recenzentów AI — jest dostarczenie powtarzalnych dowodów na większych i bardziej zróżnicowanych korpusach danych. Oznacza to publikowanie wyników na rzeczywistych strumieniach pull requestów, raportowanie opóźnień i zużycia zasobów obliczeniowych oraz klasyfikowanie trybów błędów według kategorii. Dopóki takie dane się nie pojawią, należy traktować wynik z 27 przypadków jako wczesny wskaźnik, a nie gwarancję gotowości.

Podsumowanie: Benchmark, który mówi jedynie o tym, czy narzędzie potrafi wykryć garść wcześniej napisanych błędów, jest przydatny do wstępnej weryfikacji, ale nie stanowi certyfikatu, że narzędzie poradzi sobie w trudniejszej, wrażliwej na koszty rzeczywistości przeglądu kodu produkcyjnego.