c-CRAB, Benchmark Agen Peninjau Kode: Apa yang Diukurnya, Apa yang Ditemukannya, dan Apa Arti Sebenarnya dari 41,5%

Seorang agen peninjau kode dan seorang peninjau manusia melihat pull request yang sama dan mengangkat kekhawatiran yang sama. Menindaklanjuti komentar agen tersebut memperbaiki bug; tes pun lulus. Dan setiap metrik kemiripan teks yang dihitung oleh para penulis menilai ulasan agen tersebut pada dasarnya tidak berhubungan dengan ulasan manusia: BLEU-4 0.00, ROUGE-L 7.02, chrF 20.74, kemiripan embedding 54.59. Kekhawatiran yang sama, kata-kata yang berbeda, dan cara standar menilai ulasan tidak dapat melihat bahwa mereka setuju. Satu contoh itulah argumen di balik c-CRAB (diucapkan “see-crab”), Code Review Agent Benchmark yang diterbitkan sebagai arXiv:2603.23448.

c-CRAB mengevaluasi agen peninjau kode, bukan agen penulis kode. Untuk sebuah pull request — yang mungkin berasal dari manusia atau dari agen pengode — agen peninjau menghasilkan tinjauan, dan c-CRAB menilai tinjauan tersebut berdasarkan apakah menindaklanjutinya menghasilkan perbaikan yang benar secara perilaku. Benchmark ini dikembangkan oleh para peneliti rekayasa perangkat lunak Yuntong Zhang, Zhiyuan Pan, Imam Nur Bani Yusuf, Haifeng Ruan, Ridwan Shariffdeen, dan Abhik Roychoudhury, dan mengevaluasi empat alat: PR-Agent, Devin, Claude Code, dan Codex. Salah satu penulis berafiliasi dengan SonarSource, dan makalah tersebut secara eksplisit menjelaskan apa artinya dan apa yang tidak, dengan kata-katanya sendiri: “Pandangan dan kesimpulan yang diungkapkan dalam makalah ini adalah semata-mata milik para penulis dan tidak mewakili kebijakan resmi atau dukungan dari SonarSource. Selanjutnya, temuan yang disajikan di sini bersifat independen dan tidak boleh ditafsirkan sebagai evaluasi terhadap kualitas produk di SonarSource.”

Dua catatan sebelum detailnya. Beberapa tulisan pihak ketiga menyebut karya yang sama sebagai “CR-bench”; itu adalah tolok ukur yang sama, dan halaman ini menggunakan c-CRAB di seluruhnya. Setiap gambar di bawah ini adalah hasil yang dilaporkan sendiri oleh makalah tersebut, dibaca hari ini dari makalah dan paket replikasi — tidak dijalankan ulang secara independen — dan interpretasinya adalah milik kami ditambah diskusi praktisi yang telah muncul dari makalah tersebut. Tidak satu pun dari itu merupakan panduan dari vendor yang alatnya dievaluasi. Dan jika Anda masih memutuskan apakah akan menjalankan agen peninjau kode sama sekali, panduan pembeli kami tentang agen peninjau kode adalah titik awal yang lebih baik; halaman ini adalah tentang bagaimana agen-agen tersebut diukur.

Mengapa c-CRAB menilai ulasan dengan tes, bukan juri LLM

Cara yang umum untuk menilai agen peninjau kode adalah dengan membandingkan tinjauannya dengan tinjauan manusia, menggunakan LLM-as-judge atau metrik kemiripan teks. Penulis c-CRAB menolak keduanya. LLM-as-judge, menurut mereka,{{1}} rentan terhadap bias, ketidakstabilan, dan sensitivitas prompt,{{/1}} yang membuat penilaian yang dapat direproduksi dan konsisten menjadi sulit. Dan studi kasus di atas menunjukkan apa yang sebenarnya diukur oleh metrik string:{{2}} susunan kata, bukan efektivitas.{{/2}} Pada pull request python-telegram-bot itu, tinjauan Codex mengatakan hal yang sama dengan yang dikatakan manusia,{{3}} dan BLEU-4 serta ROUGE-L tidak dapat mengenalinya.{{/3}}

Jadi c-CRAB melakukan kebalikannya. Setiap komentar tinjauan manusia diubah menjadi tes yang dapat dieksekusi yang menangkap masalah yang mendasarinya. Sebuah komentar tinjauan dianggap benar jika menindaklanjutinya menghasilkan perbaikan yang benar secara perilaku — yang membuat tes lulus. Setiap instans dilengkapi dengan lingkungan Docker yang dapat dieksekusi, sehingga keputusan lulus/gagal dibuat dengan menjalankan kode, bukan dengan meminta model lain menilai seberapa mirip dua teks. Itulah mengapa ini penting: pekerjaan tinjauan adalah mengubah apa yang dilakukan pengembang, dan tes adalah satu-satunya sinyal penilaian yang mengukur perubahan itu secara langsung.

Makalah ini mendefinisikan dua jenis pengujian, dengan kata-katanya sendiri: “Tes perilaku mengimpor dan mengeksekusi kode yang diuji saat runtime. Mereka memanggil fungsi yang diuji dengan masukan tertentu, lalu memeriksa keluaran atau memverifikasi pengecualian. Di sisi lain, tes struktural memeriksa teks kode sumber, mencocokkan pola, dan memeriksa permukaan API untuk menentukan apakah perubahan kode yang diinginkan telah dilakukan.” Pembagian akhirnya adalah 42 tes perilaku (17,9%) dan 192 tes struktural (82,1%). Perlu satu kalimat yang jujur: sebagian besar oracle adalah pencocokan pola pada teks sumber, bukan mengeksekusi kode. Ketimpangan itu adalah keterbatasan nyata yang perlu diingat.

Bagaimana benchmark dibangun, dan berapa biaya funnel-nya.

c-CRAB dibangun di atas dataset inclusionAI/SWE-CARE yang sudah ada, yang menyediakan instance pull-request dengan metadata commit; kontribusi c-CRAB sendiri adalah oracle, bukan korpus PR. Pipeline kurasi menjalankan empat filter, dan masing-masing mengurangi jumlah instance. Makalah melaporkan funnel tersebut sebagai berikut:

• Dataset awal — 671 PR, 1.313 komentar.

• Penyaringan ulasan — 410 PR, 595 komentar. Pengklasifikasi LLM, yang dikalibrasi terhadap set emas berisi 100 komentar beranotasi manual, hanya menyimpan isu yang dapat diverifikasi secara objektif dan membuang umpan balik yang bersifat percakapan atau subjektif.

• Konstruksi lingkungan eksekusi — 410 PR, 595 komentar. Satu image Docker per PR, dengan resolusi dependensi yang beralih ke agen pengkodean saat otomasi gagal.

• Mengubah komentar bahasa alami menjadi tes — 339 PR, 481 komentar. Tes dibuat dengan GPT-5.2 dalam loop penyempurnaan berbasis eksekusi hingga tiga kali percobaan; sebuah tes hanya dipertahankan jika gagal pada kode asli dan lolos setelah perbaikan.

• Validasi dengan agen coding — 184 PR, 234 komentar. Claude Code pada backend Sonnet-4.6 mencoba memperbaiki kode hanya dengan komentar review manusia; kasus di mana ia tidak dapat membuat tesnya lulus akan dibuang. Ini adalah set final.

Sekitar 27% dari pull request awal yang bertahan. Itulah harga jujur dari oracle berbasis pengujian, dan itu juga alasan mengapa benchmark ini kecil, bukan luas. Set yang bertahan: 184 instance PR, 234 komentar tinjauan yang tervalidasi, 1,27 tes per instance, rata-rata 418,1 baris yang dimodifikasi per PR, dan 31,8 baris per tes. Dua anotator secara independen menilai apakah tes yang dihasilkan dengan setia menangkap kekhawatiran peninjau manusia, pada 50 instance sampel, dan mereka setuju 84% dari waktu.

Satu perbedaan yang akan Anda perhatikan jika membaca dengan saksama: tabel dataset mencantumkan 67 repositori, sedangkan bagian threats-to-validity menyebutkan “184 contoh pull request dengan 234 oracle yang dapat diverifikasi di 56 repositori.” Makalah ini memberikan kedua angka tersebut, di tempat yang berbeda, dan kami tidak akan merata-ratakannya atau diam-diam memilih yang lebih nyaman. Pembaca menggunakan detail semacam ini untuk menilai apakah sebuah tolok ukur layak untuk waktu mereka, jadi keduanya direproduksi di sini seperti yang diterbitkan.

Hasilnya, dan cara membacanya

Tingkat kelulusan adalah tingkat kelulusan tes agregat: per instance, ini adalah bagian dari tes PR tersebut yang lulus, dan angka utamanya adalah rata-rata di semua instance. Makalah ini melaporkan, per alat:

• Claude Code — 1.336 komentar, 7,3 per PR — perilaku 38,1%, struktural 30,7%, keseluruhan 32,1%

• Devin — 1.344 komentar, 7,3 per PR — perilaku 31,0%, struktural 23,4%, keseluruhan 24,8%

• PR-Agent — 524 komentar, 2.8 per PR — perilaku 38.1%, struktural 19.8%, keseluruhan 23.1%

• Codex — 324 komentar, 1,8 per PR — perilaku 38,1%, struktural 16,1%, keseluruhan 20,1%

• Human — 234 komentar, 1,3 per PR — 100% secara konstruksi. Manusia menulis oracle, jadi baris ini adalah penanda skala, bukan pesaing.

Bacalah baris-baris tersebut dengan saksama sebelum mengutip salah satunya. “Hanya sekitar 40%” dari abstrak adalah gabungan: 41,5% dari 234 pengujian berhasil dilalui oleh setidaknya satu dari keempat alat. Itu bukan skor agen tunggal mana pun — skor tunggal terbaik adalah milik Claude Code dengan 32,1% — dan itu tidak berarti keempat alat tersebut secara bersama-sama menangkap 40% cacat nyata. Bagian di bawah menjelaskan alasannya.

Angka yang paling menarik bukanlah pemenangnya. Claude Code dan Devin masing-masing memposting lebih dari 1.300 komentar — sekitar 7,3 per PR — untuk mencapai 32,1% dan 24,8%. Codex memposting 324 komentar, sekitar 1,8 per PR, untuk mencapai 20,1%. Baseline manusia adalah 1,3 komentar per PR. Lakukan aritmetikanya: kira-kira empat kali volume komentar hanya menghasilkan tingkat kelulusan yang jauh di bawah dua kali lipat. Volume bukanlah cakupan. Peninjau yang banyak bicara tidak sama dengan peninjau yang berguna, dan c-CRAB adalah tolok ukur pertama yang dibuat untuk menunjukkan hal itu.

Kegunaan justru berlaku sebaliknya.

Tingkat kelulusan yang rendah dapat dibaca sebagai kecaman, sampai Anda melihat apa lagi yang diukur oleh para penulis. Mereka memeriksa secara manual 92 komentar di 6 PR dan menilai 84% di antaranya bermanfaat (77 dari 92) — PR-Agent 94%, Codex 88%, Devin 85%, Claude Code 78%. Jadi sebagian besar komentar yang gagal dalam tes c-CRAB bukanlah noise; komentar-komentar itu tentang sesuatu yang tidak diangkat oleh peninjau manusia. Sampelnya kecil — 92 komentar, 6 PR — dan makalahnya mengakui hal itu, begitu pula kita.

Pola yang sama muncul dalam apa yang dibicarakan para peninjau. Peninjau manusia condong pada kemudahan perawatan, desain, dan dokumentasi; alat-alatnya condong pada ketahanan, pengujian, dan penanganan kesalahan. Makalah ini membaca hal ini sebagai argumen untuk kolaborasi manusia-agen, bukan penggantian. Ini juga merupakan penjelasan terbaik yang tersedia untuk mengapa skor-skornya tampak rendah: agen dan manusia sering kali tidak melihat hal yang sama, dan oracle hanya memberi penghargaan pada daftar milik manusia.

Apa yang Tidak Dapat Dilihat c-CRAB

Benchmark tersebut eksplisit tentang titik butanya, dan kami juga demikian. c-CRAB tidak memberikan kredit untuk masalah valid yang tidak pernah diangkat oleh peninjau manusia. Oracle-nya adalah niat peninjauan manusia: agen yang menemukan bug nyata yang tidak disebutkan siapa pun mendapat skor nol untuk itu. Makalah tersebut mengatakannya secara langsung — alat tinjauan otomatis dapat menghasilkan komentar berharga lainnya yang tidak diidentifikasi oleh peninjau manusia, tetapi “seperti benchmark lain yang ada, c-CRAB tidak secara langsung mengevaluasi komentar tambahan tersebut.”

Kalimat yang satu itu adalah koreksi atas sebagian besar liputan hasil ini. Siapa pun yang mengutip “agen peninjau hanya menyelesaikan 40%” seolah-olah itu mengukur berapa banyak cacat nyata yang ditemukan para agen, maka ia salah membaca angka tersebut. Angka itu mengukur berapa banyak masalah yang diangkat manusia dan berhasil diselesaikan para agen secara bersama-sama — sebuah klaim yang lebih sempit dan jauh lebih jujur.

Menjalankannya sendiri

Jika Anda ingin mereproduksi angka-angka tersebut atau menambahkan peninjau Anda sendiri, paket replikasi tersedia secara publik di c-CRAB-Benchmark/dataset. README adalah dokumentasi yang sebenarnya, dan ia jujur tentang bentuk hal tersebut. Pengaturannya adalah code>uv sync/code>; Anda memerlukan Docker dan code>OPENAI_API_KEY/code> atau code>ANTHROPIC_API_KEY/code>, dan Claude Code juga membaca kredensial dari code>~/.claude/.credentials.json/code>. Organisasi tersebut juga menerbitkan citra Docker siap pakai untuk lingkungan-lingkungan tersebut.

Tata letak: code>pipeline//code> berisi logika pipeline dan prompt, code>execution//code> pembangun citra Docker dan helper runtime, code>results_preprocessed//code> subset benchmark yang dirilis (410 instance yang telah diproses), code>results_pipeline_funnel//code> berkas JSONL stage0–stage4 dan ringkasan funnel, serta code>raw_results_compressed//code> keluaran eksperimen mentah.

Mereproduksi seluruh proses terdiri dari lima langkah: bangun lingkungan Docker (code>execution.build_swe_care/code>), buat tes (code>run_testgen_full.sh/code>), kumpulkan ulasan baseline (code>run_batch_baselines.py --tools pr-agent devin claude-code codex/code>), jalankan resolusi agent (code>run_batch_agent_resolution.py/code>), lalu evaluasi (code>run_batch_tool_eval.py --tool <name>/code>). Jika Anda ingin menambahkan reviewer kelima, perlu diketahui bahwa titik ekstensi bukan antarmuka plugin: prompt ulasan baseline untuk setiap tool berada di code>run_batch_baselines.py/code>, dan README tidak mendokumentasikan cara yang lebih bersih — Anda mengedit skrip tersebut.

Dua fakta lagi sebelum Anda meng-clone-nya. Makalah ini dilisensikan di bawah CC BY 4.0; halaman repositori tidak menyatakan lisensi untuk kodenya, jadi jangan menganggap ada. Dan makalah tersebut tidak memublikasikan angka biaya atau penggunaan token untuk menjalankan benchmark — itu tidak dipublikasikan, jadi kami tidak akan mengada-adakannya. Yang tersirat dari pipeline ini: satu image Docker per PR di 184 instance, ditambah proses resolusi agen, bukan sesuatu yang bisa diselesaikan dalam satu sore dengan laptop.

Apa artinya ini bagi siapa pun yang meluncurkan pipeline review.

Argumen inti c-CRAB adalah bahwa hakim LLM adalah oracle yang tidak dapat diandalkan. Jika Anda tidak dapat membangun oracle yang dapat dieksekusi — dan sebagian besar tim tidak dapat — mitigasi terbaik yang tersedia adalah jangan pernah membiarkan hakim berjalan pada model yang menghasilkan ulasan. Hakim yang berbagi model dengan peninjau setuju dengan dirinya sendiri, dan proses verifikasi berubah menjadi stempel karet yang tetap mengembalikan angka.

Itu adalah kegagalan yang justru dicegah oleh resep perutean di balik reviewer yang kami sertakan — dan ini paralel dengan kritik c-CRAB, bukan hasil tolok ukur. Meski begitu, kerangka uji tetap menjalankan penilai LLM, sebagai lintasan kedua yang mengelompokkan temuan, memberi skor 0–1 pada setiap kelompok untuk menentukan apakah itu cacat konkret dalam perubahan ini, dan membuang semua yang berada di bawah ambang batas. Resep yang mengaturnya, code>recipes/orcacode-review.dsl.yaml/code>, adalah berkas publik. Action tidak pernah menyebutkan model: ia memanggil alias router, dan resep itulah yang memutuskan. Sesuai yang disediakan, resep terdiri dari empat baris — default reviewer adalah code>deepseek/deepseek-v4-flash-0731/code>, dan sebuah aturan yang cocok dengan header code>x-cr-lens: judge/code> mengirimkan lintasan penilai ke code>z-ai/glm-5.3/code>, vendor yang berbeda. Kata-kata resep itu sendiri mensyaratkan bahwa penilai “TIDAK BOLEH MENYEBUTKAN MODEL DEFAULT”, karena pada model milik reviewer itu sendiri, ia “setuju dengan dirinya sendiri, sehingga lintasan tersebut menjadi tidak aktif meskipun tetap melaporkan keberhasilan”.

Hakim dari vendor yang berbeda mengurangi kesepakatan diri; hal itu tidak mengubah hakim LLM menjadi tes. c-CRAB tidak menguji reviewer kami, dan kami tidak akan menyiratkan sebaliknya. OrcaCode Review menjalankan proses review plus hakim verifikasi independen, per token bukan per seat, dan setiap prompt di dalamnya bersifat publik — sehingga Anda dapat mengarahkannya ke benchmark seperti ini dan mendapatkan angka Anda sendiri, bukan angka kami.

Intinya

c-CRAB adalah benchmark tinjauan kode pertama yang skornya sebagian besar dapat Anda percaya sesuai artinya: sebuah tinjauan dianggap lulus hanya ketika menerapkannya memperbaiki kode. Angka-angka utama memang rendah — alat tunggal terbaik 32.1%, gabungan 41.5% — tetapi angka-angka itu mengukur tumpang tindih dengan kekhawatiran yang diangkat manusia, bukan kualitas tinjauan, dan data kegunaan menunjukkan sebagian besar komentar adalah sinyal nyata. Pembelajaran utama yang bertahan adalah yang diargumentasikan oleh makalah itu sendiri: volume bukan cakupan, agen dan manusia melihat hal-hal yang berbeda, dan penerapan yang tepat adalah kolaborasi manusia-agen. Dan benchmark ini terbuka, jadi langkah jujur berikutnya adalah menjalankan reviewer Anda sendiri pada benchmark tersebut dan mendapatkan angka Anda sendiri.