Benchmark v1 CodeVetter menjalankan 27 kasus sintetis melalui alur kerja (pipeline) peninjauan kode berbasis AI dan mencatat apakah alat tersebut dapat menemukan bug yang sengaja ditanamkan. Kemudian, ia menghitung jumlah lulus atau gagal untuk setiap kasus.

Mengapa benchmark ini penting

Pengujian ini mengajukan pertanyaan yang sempit: dapatkah peninjau tertentu mengenali cacat (defect) tepat yang ditanamkan oleh perancang benchmark dalam kumpulan cuplikan kode (snippets) tetap ini? Pengembang dapat menggunakan hasilnya sebagai pemeriksaan cepat terhadap cakupan masalah (issue coverage). Karena repositori ini menyertakan paket tugas dan skrip penilaian, siapa pun dapat menjalankan ulang pengujian tersebut dan mendapatkan angka yang sama.

Apa yang tidak dibuktikan oleh benchmark ini

Rangkaian sintetis berisi 27 kasus bukanlah pengganti bagi ribuan pull request yang ditangani tim setiap harinya. Benchmark ini tidak memberikan informasi tentang:

  • Keragaman dunia nyata – ia hanya mencakup beberapa bahasa dan rentang kategori bug yang terbatas.
  • Performa – ia tidak menyediakan pengukuran waktu atau biaya komputasi.
  • Keandalan di berbagai basis kode – tanpa pengujian repositori langsung (live-repo), kita tidak dapat mengetahui apakah alat tersebut akan melewatkan cacat yang halus atau menghasilkan false positive di lingkungan produksi.

Mencampuradukkan hasil yang dipublikasikan dengan file infrastruktur dan janji akan “data luas dan realistis” di masa mendatang menciptakan narasi pemasaran bahwa skor tunggal tersebut mewakili kemampuan siap-produksi, yang mana data tersebut tidak mendukungnya.

Bagaimana benchmark ini selaras dalam ekosistem pengujian yang lebih luas

Benchmark bergaya pengenalan (recognition-style), seperti milik CodeVetter, memetakan area permukaan yang dapat ditangani oleh suatu alat. Benchmark ini melengkapi benchmark fungsional seperti SWE-bench, yang memeriksa apakah patch yang dihasilkan AI benar-benar menyelesaikan masalah nyata dalam basis kode yang ada. Bersama-sama, keduanya memberikan gambaran yang lebih lengkap: cakupan versus efektivitas.

Benchmark agen yang baik harus memaparkan seluruh tumpukan (full stack):

  1. Dataset – input mentah dan output yang diharapkan.
  2. Dokumentasi per kasus – satu halaman untuk setiap pengujian yang menunjukkan bug, perbaikan yang benar, dan respons alat tersebut.
  3. Output peninjau – komentar atau saran tepat yang dihasilkan oleh AI.
  4. Metodologi penilaian – bagaimana kecocokan dinilai, termasuk toleransi untuk kredit parsial.
  5. Instruksi reproduksibilitas – pin versi, detail perangkat keras, dan skrip untuk menjalankan ulang pengujian.

Hanya ketika semua bagian ini transparan, kita dapat memercayai satu skor agregat tunggal.

Batasan yang dicantumkan oleh benchmark itu sendiri

  • Kasus sintetis, bukan diambil dari repositori langsung.
  • Pemilihan bahasa dan tipe bug yang sempit.
  • Tidak ada data waktu atau biaya, sehingga efisiensi tidak diketahui.
  • Batasan presisi yang mungkin menutupi kegagalan di ambang batas (borderline failures).

Apa yang perlu diperhatikan selanjutnya

Langkah selanjutnya bagi CodeVetter—dan bagi siapa pun yang menggunakan peninjau AI—adalah bukti berulang pada korpus yang lebih besar dan lebih bervariasi. Itu berarti memublikasikan hasil pada aliran pull-request yang nyata, melaporkan latensi dan konsumsi komputasi, serta merinci mode kegagalan berdasarkan kategori. Sampai data tersebut muncul, anggaplah skor 27 kasus tersebut sebagai indikator awal, bukan jaminan kesiapan.

Kesimpulan: Benchmark yang hanya memberi tahu Anda apakah suatu alat dapat menemukan segelintir bug yang telah ditulis sebelumnya berguna untuk sanity-checking, tetapi tidak menjamin bahwa alat tersebut akan bertahan dalam realitas peninjauan kode produksi yang lebih berantakan dan sensitif terhadap biaya.