Tolok ukur (benchmark) untuk alat peninjauan kode berbasis kecerdasan buatan (AI code review) sering kali dipublikasikan dengan klaim keunggulan performa yang sangat meyakinkan. Namun, laporan performa semacam ini sebaiknya dipandang sebagai catatan mengenai apa yang dicapai sebuah perkakas pada skenario pengujian spesifik milik pihak lain, bukan sebagai tabel peringkat universal. Dalam perbandingan yang dirilis oleh vendor perangkat lunak, hampir setiap pembuat menempatkan produk mereka sendiri di peringkat teratas. Perkakas pesaing yang sama bahkan memperoleh skor yang bertolak belakang di berbagai laporan yang berbeda karena setiap vendor menerapkan parameter pengukuran, repositori, dan metodologi penghitungan yang berlainan. Seluruh data pengujian yang dibahas di sini diakses pada 5 Oktober 2026, serta data dari ReviewBench pada 6 Oktober 2026.

Tujuh Pertanyaan Kritis Evaluasi Tolok Ukur

  • Untuk mengevaluasi validitas sebuah tolok ukur peninjauan kode AI, terdapat tujuh pertanyaan kritis yang perlu diajukan: Siapa yang menjalankan pengujian dan apakah produk mereka sendiri terdaftar dalam tabel? Berapa banyak kasus pengujian yang disertakan dan siapa yang memilihnya? Siapa yang merumuskan kunci jawaban atau ground truth? Siapa atau mekanisme apa yang memutuskan bahwa sebuah komentar AI cocok dengan masalah yang diketahui? Bagaimana perkakas pesaing dikonfigurasi, pada paket langganan apa, dan dengan pengaturan apa? Apa definisi sebenarnya dari metrik presisi (precision), perolehan (recall), atau tingkat penangkapan (catch rate), serta apakah komentar yang tidak relevan (noise) diberikan penalti? Terakhir, kapan pengujian tersebut dilakukan dan apakah vendor telah melakukan penyesuaian model terhadap set data yang sama setelahnya?
  • Variasi pendekatan terlihat jelas pada sembilan tolok ukur yang dianalisis. Greptile (Juli 2025) mengukur catch rate pada 50 bug di lima repositori dengan memverifikasi temuan terhadap bug yang diketahui pada paket hosted dan pengaturan bawaan, menempatkan Greptile di posisi pertama. Augment (Desember 2025, diperbarui Juni 2026) mengukur presisi, recall, dan F-score terhadap golden comments pada 50 pull request (PR) di lima proyek dengan kunci jawaban yang dikoreksi sendiri, menempatkan Augment di posisi teratas berdasarkan F-score. Qodo (Februari 2026) mengevaluasi metrik terhadap 580 isu yang disuntikkan ke dalam 100 PR menggunakan penilai berbasis model bahasa besar (LLM). Cursor (April 2026) mengukur tingkat penyelesaian (resolution rate) pada repositori publik dengan 11.419 hingga 50.310 PR per alat melalui penilai LLM, menghasilkan Cursor di peringkat teratas. Macroscope (September 2025) menguji tingkat deteksi 118 runtime bug pada 45 repositori menggunakan LLM yang diverifikasi manual. Bito (Maret 2026) mengukur cakupan terhadap Truth Set berisi 65 isu dalam lima bahasa pemrograman. Sementara itu, CodeRabbit (September 2026) membandingkan model internal pada pipeline miliknya menggunakan 13 kasus dan 44 PR untuk evaluasi kecepatan melalui penilai independen dengan sistem tiga suara tanpa memeringkat alat pesaing.
  • Inkonsistensi data terlihat nyata saat melacak satu produk tertentu di berbagai pengujian vendor. CodeRabbit muncul di lima tolok ukur berbeda dengan hasil yang bervariasi: tabel Augment memberikannya presisi 36% terhadap golden comments milik Augment; Greptile mencatat catch rate 44% pada 50 bug milik Greptile; Macroscope mencatat tingkat deteksi 46% pada 118 runtime bug; Cursor mencatat tingkat resolusi 48,96% pada repositori publik; dan Bito menyatakan CodeRabbit meraih rata-rata cakupan 65,8%. Fenomena ini juga terjadi saat menggunakan proyek sumber terbuka yang identik seperti Sentry, Cal.com, Grafana, Keycloak, dan Discourse. Meskipun Greptile dan Augment menggunakan 50 PR dari repositori yang sama, Augment merevisi kunci jawaban secara manual. Akibatnya, Greptile unggul menurut aturan skoring Greptile, sedangkan Augment memimpin berdasarkan sistem penilaian Augment. Kunci jawaban dan aturan evaluasi merupakan penentu utama hasil akhir.
  • Perbedaan definisi metrik teknis menjadi faktor fundamental lainnya. Metrik recall mengukur proporsi masalah yang berhasil dideteksi alat. Namun, metrik presisi memiliki interpretasi yang berbeda: terhadap kunci jawaban statis, presisi mengukur kesesuaian komentar alat dengan daftar isu yang disusun sebelumnya, sebagaimana diterapkan Qodo. Jika ada bug nyata yang terlewat dari kunci jawaban, komentar alat justru dihitung sebagai kesalahan (false positive). Sebaliknya, Cursor mendefinisikan presisi berdasarkan respons pengembang, di mana komentar dianggap valid jika pembuat kode melakukan perubahan sebelum PR digabungkan. Dalam metode ini, peringatan teknis yang benar namun diabaikan pengembang dihitung sebagai noise, sementara saran sepele yang diperbaiki dihitung sebagai temuan valid. Pada tolok ukur catch rate Greptile, komentar keliru dan saran gaya kode tidak memengaruhi skor. Prioritas vendor pun terbelah; Baz mengutamakan optimalisasi presisi, sedangkan Qodo memandang presisi sebagai parameter pascapemrosesan yang dapat disesuaikan pengguna.
  • Sebagian pengembang tolok ukur secara terbuka mencantumkan batasan metodologi mereka di bagian penjelasan teknis. CodeRabbit secara eksplisit mengakui bahwa pengujian pada 13 kasus merupakan set data yang terlalu kecil, di mana Claude Sonnet 5.5 menangkap 6 masalah dan Sonnet 5 menemukan 4 masalah. Macroscope menyatakan bahwa mereka hanya menyaring runtime bug yang terisolasi karena perkakas mereka dirancang spesifik untuk masalah tersebut, sembari mengakui bahwa perkakas pesaing tidak memiliki kesempatan memperbaiki alur kerja terhadap set data tersebut. Baz menyebut banyak tolok ukur terdahulu terlalu kecil untuk digeneralisasi, terlalu statis, dan terikat pada preferensi penilaian satu vendor. CodeAnt bahkan menyatakan secara lugas bahwa sebagian besar perbandingan diproduksi oleh vendor itu sendiri, sehingga setiap tolok ukur dapat dipastikan memenangkan produknya masing-masing.
  • Upaya menghadirkan tolok ukur independen dan open-source dilakukan oleh inisiatif seperti Martian Code Review Bench dan GitHub ReviewBench. Martian berupaya mengatasi masalah evaluasi mandiri dengan menjalankan alur kerja perkakas secara langsung sejak 25 Agustus 2026. Evaluasi dilakukan secara luring (offline) terhadap 173 golden comments pada 50 PR (137 pada data Maret 2026) dan secara daring (online) terhadap perbaikan langsung pengembang. Perubahan pada penilai LLM atau deduplikasi temuan (seperti commit 720e1d3 pada 19 Maret 2026) terbukti dapat mengubah posisi teratas di papan peringkat. Sementara itu, GitHub ReviewBench yang diumumkan pada 5 Oktober 2026 menguji 219 PR pada 187 repositori lintas 19 bahasa menggunakan Claude Sonnet 5. Kendati terbuka, Copilot Code Review menduduki peringkat pertama, di mana 1.185 dari 2.623 temuan true positive pada data 6 Oktober 2026 dihasilkan oleh Copilot Code Review (ccr), yang memperlihatkan adanya potensi bias model pada dataset dasar.
  • Daripada mempercayai peringkat mutlak pada papan skor vendor, tim pengembang disarankan melakukan pengujian mandiri pada repositori internal. Langkah praktisnya adalah memilih pull request historis yang memiliki riwayat masalah nyata melalui revert, hotfix, atau evaluasi pascainsiden. Buka kembali perubahan kode dari commit sebelumnya agar setiap perkakas meninjau diff yang sama. Pasang dan jalankan perkakas sesuai konfigurasi lingkungan produksi, bukan hanya pengaturan bawaan. Hitung secara terpisah rasio penemuan bug nyata, jumlah komentar noise yang harus dibaca pengembang, serta waktu dan biaya komputasi per peninjauan. Metode ini juga berlaku untuk menilai perkakas baru yang belum masuk tolok ukur publik, seperti Sigma dari Mnemoverse yang berjalan pada model Claude Code dan OpenAI. Cermati metodologinya sebelum melihat grafik peringkat, lalu biarkan data dari pull request internal yang menentukan perkakas terbaik.