Milvus
Zilliz
  • Home
  • Blog
  • Ulasan Kode AI Menjadi Lebih Baik Ketika Model Berdebat: Claude vs Gemini vs Codex vs Qwen vs MiniMax

Ulasan Kode AI Menjadi Lebih Baik Ketika Model Berdebat: Claude vs Gemini vs Codex vs Qwen vs MiniMax

  • Engineering
February 26, 2026
Li Liu

Baru-baru ini saya menggunakan model AI untuk meninjau sebuah pull request, dan hasilnya bertentangan: Claude menandai adanya perlombaan data, sementara Gemini mengatakan bahwa kodenya bersih. Hal ini membuat saya penasaran tentang bagaimana model AI lainnya akan berperilaku, jadi saya menjalankan model unggulan terbaru dari Claude, Gemini, Codex, Qwen, dan MiniMax melalui tolok ukur tinjauan kode terstruktur. Hasilnya? Model dengan performa terbaik hanya menangkap 53% bug yang diketahui.

Namun, keingintahuan saya tidak berhenti sampai di situ: bagaimana jika model-model AI ini bekerja sama? Saya bereksperimen dengan membuat mereka saling berdebat, dan setelah lima putaran perdebatan yang saling berlawanan, deteksi bug melonjak menjadi 80%. Bug yang paling sulit, yang membutuhkan pemahaman tingkat sistem, mencapai deteksi 100% dalam mode debat.

Artikel ini membahas desain eksperimen, hasil per model, dan apa yang diungkapkan oleh mekanisme debat tentang bagaimana sebenarnya menggunakan AI untuk peninjauan kode.

Membandingkan Claude, Gemini, Codex, Qwen, dan MiniMax untuk peninjauan kode

Jika Anda telah menggunakan model untuk peninjauan kode, Anda mungkin memperhatikan bahwa model-model tersebut tidak hanya berbeda dalam hal akurasi, tetapi juga berbeda dalam hal cara mereka membaca kode. Sebagai contoh:

Claude biasanya berjalan di rantai pemanggilan dari atas ke bawah dan akan menghabiskan waktu di jalur yang "membosankan" (penanganan kesalahan, percobaan ulang, pembersihan). Di situlah sering kali bug yang sebenarnya bersembunyi, jadi saya tidak membenci ketelitiannya.

Gemini cenderung memulai dengan keputusan yang kuat ("ini buruk"/"terlihat baik-baik saja") dan kemudian bekerja mundur untuk membenarkannya dari sudut pandang desain/struktur. Terkadang hal itu berguna. Kadang-kadang itu terbaca seperti membaca sekilas dan kemudian melakukan pengambilan gambar.

Codex lebih tenang. Tetapi ketika menandai sesuatu, sering kali konkret dan dapat ditindaklanjuti - lebih sedikit komentar, lebih banyak "baris ini salah karena X."

Namun, ini adalah kesan, bukan pengukuran. Untuk mendapatkan angka yang sebenarnya, saya membuat tolok ukur.

Pengaturan

Lima model unggulan diuji:

  • Claude Opus 4.6

  • Gemini 3 Pro

  • GPT-5.2-Codex

  • Qwen-3.5-Plus

  • MiniMax-M2.5

Perkakas (Magpie)

Saya menggunakan Magpie, sebuah alat benchmarking sumber terbuka yang saya buat sendiri. Tugasnya adalah melakukan "persiapan tinjauan kode" yang biasanya Anda lakukan secara manual: menarik konteks di sekitarnya (rantai pemanggilan, modul terkait, dan kode yang berdekatan yang relevan) dan memasukkannya ke model sebelum meninjau PR.

Kasus uji (PR Milvus dengan bug yang diketahui)

Dataset ini terdiri dari 15 pull request dari Milvus (database vektor sumber terbuka yang dibuat dan dikelola oleh Zilliz). PR ini berguna sebagai tolok ukur karena masing-masing digabungkan, hanya untuk kemudian memerlukan pengembalian atau perbaikan setelah bug muncul dalam produksi. Jadi, setiap kasus memiliki bug yang diketahui yang dapat kami nilai.

Tingkat kesulitan bug

Tidak semua bug ini sama sulitnya untuk ditemukan, jadi saya mengkategorikannya ke dalam tiga tingkat kesulitan:

  • L1: Terlihat dari diff saja (use-after-free, off-by-one).

  • L2 (10 kasus): Membutuhkan pemahaman kode di sekitarnya untuk menemukan hal-hal seperti perubahan semantik antarmuka atau perlombaan konkurensi. Ini merupakan bug yang paling umum ditemukan dalam peninjauan kode harian.

  • L3 (5 kasus): Membutuhkan pemahaman tingkat sistem untuk menangkap masalah seperti inkonsistensi status lintas modul atau masalah kompatibilitas peningkatan. Ini adalah tes tersulit untuk mengetahui seberapa dalam sebuah model dapat memahami basis kode.

Catatan: Setiap model menangkap semua bug L1, jadi saya tidak memasukkannya dalam penilaian.

Dua mode evaluasi

Setiap model dijalankan dalam dua mode:

  • Raw: model hanya melihat PR (diff + apa pun yang ada di konten PR).

  • R1: Magpie menarik konteks di sekitarnya (file yang relevan / situs panggilan / kode terkait) sebelum model meninjau. Ini mensimulasikan alur kerja di mana Anda menyiapkan konteks di depan alih-alih meminta model untuk menebak apa yang dibutuhkannya.

Hasil (hanya L2 + L3)

ModeClaudeGeminiCodexMiniMaxQwen
Mentah53% (pertama)13% (terakhir)33%27%33%
R1 (dengan konteks oleh Magpie)47% ⬇️33%⬆️27%33%40%⬆️

Empat hal yang dapat diambil:

1. Claude mendominasi tinjauan mentah. Dia mendapatkan skor 53% deteksi keseluruhan dan 5/5 sempurna untuk bug L3, tanpa bantuan konteks apa pun. Jika Anda menggunakan satu model dan tidak ingin menghabiskan waktu untuk menyiapkan konteks, Claude adalah pilihan terbaik.

2. Gemini membutuhkan konteks yang diberikan kepadanya. Skor mentahnya sebesar 13% adalah yang terendah dalam grup, tetapi dengan Magpie yang menyediakan kode di sekitarnya, skornya melonjak menjadi 33%. Gemini tidak mengumpulkan konteksnya sendiri dengan baik, tetapi kinerjanya cukup baik ketika Anda melakukan pekerjaan itu di awal.

3. Qwen adalah pemain dengan bantuan konteks terkuat. Ia mendapat skor 40% dalam mode R1, dengan 5/10 pada bug L2, yang merupakan skor tertinggi pada tingkat kesulitan itu. Untuk tinjauan harian rutin yang mengharuskan Anda menyiapkan konteks, Qwen adalah pilihan yang praktis.

4. Lebih banyak konteks tidak selalu membantu. Hal ini mengangkat Gemini (13% → 33%) dan MiniMax (27% → 33%), namun sebenarnya merugikan Claude (53% → 47%). Claude sudah unggul dalam mengatur konteksnya sendiri, sehingga informasi tambahan kemungkinan besar akan menimbulkan kebisingan daripada kejelasan. Pelajarannya: sesuaikan alur kerja dengan model, daripada mengasumsikan lebih banyak konteks lebih baik secara universal.

Hasil ini selaras dengan pengalaman saya sehari-hari. Claude yang berada di posisi teratas tidaklah mengejutkan. Skor Gemini yang lebih rendah dari yang saya harapkan masuk akal jika dipikir-pikir: Saya biasanya menggunakan Gemini dalam percakapan multi-berputar di mana saya mengulangi desain atau mengejar masalah bersama-sama, dan Gemini bekerja dengan baik dalam pengaturan interaktif tersebut. Tolok ukur ini adalah pipa tetap, jalur tunggal, yang merupakan format di mana Gemini paling lemah. Bagian debat nanti akan menunjukkan bahwa ketika Anda memberikan Gemini format multi-ronde, format permusuhan, kinerjanya akan meningkat secara nyata.

Biarkan Model AI Berdebat Satu Sama Lain

Setiap model menunjukkan kekuatan dan titik buta yang berbeda dalam tolok ukur individu. Jadi saya ingin menguji: apa yang terjadi jika model-model tersebut saling meninjau hasil kerja satu sama lain, bukan hanya kodenya saja?

Jadi saya menambahkan lapisan debat di atas benchmark yang sama. Kelima model berpartisipasi dalam lima ronde:

  • Di Babak 1, setiap model mengulas PR yang sama secara independen.

  • Setelah itu, saya menyiarkan kelima ulasan tersebut kepada semua peserta.

  • Di Babak 2, setiap model memperbarui posisinya berdasarkan empat model lainnya.

  • Ulangi hingga Ronde 5.

Pada akhirnya, setiap model tidak hanya bereaksi terhadap kode - tetapi juga bereaksi terhadap argumen yang telah dikritik dan direvisi beberapa kali.

Untuk menjaga agar hal ini tidak berubah menjadi "LLM yang setuju dengan keras," saya memberlakukan satu aturan yang keras: setiap klaim harus menunjukkan kode tertentu sebagai bukti, dan model tidak bisa hanya mengatakan "poin yang bagus" - model harus menjelaskan mengapa ia berubah pikiran.

Hasilnya: Mode Debat Tunggal vs Debat Terbaik

ModeL2 (10 kasus)L3 (5 kasus)Total deteksi
Individu terbaik (Claude Mentah)3/105/553%
Debat (kelima model)7/10 (dua kali lipat)5/5 (semua tertangkap)80%

Apa yang menonjol

1. Deteksi L2 meningkat dua kali lipat. 2. Bug rutin dengan tingkat kesulitan menengah melonjak dari 3/10 menjadi 7/10. Ini adalah bug yang paling sering muncul di basis kode yang sebenarnya, dan ini adalah kategori di mana masing-masing model meleset secara tidak konsisten. Kontribusi terbesar dari mekanisme debat adalah menutup kesenjangan sehari-hari ini.

2. Bug L3: tidak ada yang meleset. Dalam uji coba model tunggal, hanya Claude yang berhasil menemukan kelima bug tingkat sistem L3. Dalam mode debat, grup mencocokkan hasil tersebut, yang berarti Anda tidak perlu lagi bertaruh pada model yang tepat untuk mendapatkan cakupan L3 penuh.

3. Debat mengisi titik-titik buta daripada menaikkan plafon. Bug tingkat sistem bukanlah bagian yang sulit bagi individu terkuat. Claude sudah memilikinya. Kontribusi inti dari mekanisme debat adalah menambal kelemahan Claude pada bug L2 rutin, di mana Claude secara individu hanya menangkap 3 dari 10 bug, tetapi kelompok debat menangkap 7 bug. Dari situlah lompatan 53% → 80% berasal.

Seperti apa debat sebenarnya dalam praktiknya

Angka-angka di atas menunjukkan bahwa debat berhasil, tetapi contoh konkret menunjukkan mengapa debat berhasil. Berikut ini adalah panduan ringkas tentang bagaimana kelima model menangani PR #44474, yang memperkenalkan pemuatan kunci utama yang malas selama pencarian.

PR #44474: Pengoptimalan pemuatan malas yang mengubah pencarian untuk mengambil kunci utama sesuai permintaan alih-alih memuat semuanya di awal.

Ronde 1

Gemini membuka dengan agresif:

"PR ini adalah ladang ranjau praktik buruk, potensi perilaku yang tidak terdefinisi, dan kemunduran kinerja yang disamarkan sebagai 'pengoptimalan'."

Claude dan Qwen berfokus pada perilaku dan kinerja yang tidak terdefinisi, menyatu dalam keprihatinan yang sama:

"Model memori C++ tidak menjamin keamanan untuk penulisan secara bersamaan ke indeks yang berbeda dari vektor yang sama tanpa sinkronisasi yang tepat."

Ketiganya menemukan masalah yang nyata, tetapi tidak ada yang menemukan bug yang lebih dalam. Kemudian Codex, yang hampir tidak pernah berbicara, menandai sesuatu yang terlewatkan oleh yang lain: vektor primary_keys_ diubah ukurannya, tetapi hanya posisi yang melewati fase pengurangan yang benar-benar terisi. Setiap posisi lainnya dibiarkan bernilai nol.

Babak 2

Claude mengambil temuan Codex dan menelusuri konsekuensi hilirnya:

"Saya menemukannya: SortEqualScoresByPks dijalankan sebelum ReduceResultData. Jadi, ketika SortEqualScoresByPks dieksekusi, nol PK telah diambil dengan malas. Seluruh vektor primary_keys_ penuh dengan nilai PkType yang dibuat secara default."

Secara sederhana, fungsi sortir berjalan sebelum kunci-kunci dimuat, jadi fungsi ini mengurutkan angka nol. Claude mengakui kesalahan tersebut secara terbuka:

"codex-cli mengidentifikasi bug kebenaran kritis yang asli. Saya melewatkan hal ini pada putaran pertama saya."

Kombinasi Model Mana yang Dapat Menemukan Bug Terbanyak?

Lonjakan dari 53% menjadi 80% terjadi karena lima model saling menutupi titik buta satu sama lain. Tetapi tidak semua orang mampu menyiapkan dan menjalankan lima model melalui lima putaran perdebatan untuk setiap tinjauan kode.

Jadi saya menguji versi yang lebih sederhana: jika Anda hanya bisa menjalankan dua model, pasangan mana yang paling mendekati plafon multi-model?

Saya menggunakan context-assisted (R1) dan menghitung berapa banyak dari 15 bug yang ditemukan di setiap model:

  • Claude: 7/15 (47%)

  • Qwen: 6/15 (40%)

  • Gemini: 5/15 (33%)

  • MiniMax: 5/15 (33%)

  • Codex: 4/15 (27%)

Yang penting, kemudian, bukan hanya berapa banyak bug yang ditemukan oleh masing-masing model, tetapi bug mana yang terlewatkan. Dari 8 bug yang terlewatkan oleh Claude, Gemini menemukan 3 bug: kondisi perlombaan konkurensi, masalah kompatibilitas API penyimpanan awan, dan pemeriksaan izin yang hilang. Di sisi lain, Gemini melewatkan sebagian besar struktur data dan bug logika yang dalam, dan Claude menangkap hampir semuanya. Kelemahan mereka hampir tidak tumpang tindih, dan itulah yang membuat mereka menjadi pasangan yang kuat.

Pasangan dua modelCakupan gabungan
Claude + Gemini10/15
Claude + Qwen9/15
Claude + Codex8/15
Claude + MiniMax8/15

Kelima model tersebut bersama-sama mencakup 11 dari 15, menyisakan 4 bug yang terlewatkan oleh setiap model.

Claude + Gemini, sebagai pasangan dua model, sudah mencapai 91% dari plafon lima model tersebut. Untuk tolok ukur ini, ini adalah kombinasi yang paling efisien.

Meskipun demikian, Claude + Gemini bukanlah pasangan terbaik untuk semua jenis bug. Ketika saya mengelompokkan hasilnya berdasarkan kategori bug, gambaran yang lebih jelas muncul:

Jenis bugTotalClaudeGeminiCodexMiniMaxQwen
Kesenjangan validasi432113
Siklus hidup struktur data431131
Perlombaan konkurensi201000
Kompatibilitas201101
Logika yang dalam310111
Total1575456

Perincian jenis bug mengungkapkan mengapa tidak ada satu pun pasangan yang terbaik secara universal.

  • Untuk bug siklus hidup struktur data, Claude dan MiniMax berada di posisi 3/4.

  • Untuk kesenjangan validasi, Claude dan Qwen berada di posisi 3/4.

  • Untuk masalah konkurensi dan kompatibilitas, Claude mendapat nilai nol untuk keduanya, dan Gemini adalah yang mengisi kesenjangan tersebut.

  • Tidak ada model yang mencakup semuanya, tetapi Claude mencakup jangkauan terluas dan paling mendekati sebagai generalis.

Empat bug terlewatkan oleh setiap model. Satu melibatkan prioritas aturan tata bahasa ANTLR. Salah satunya adalah ketidakcocokan semantik kunci baca/tulis di seluruh fungsi. Satu lagi membutuhkan pemahaman tentang perbedaan logika bisnis antara tipe pemadatan. Dan satu lagi adalah kesalahan perbandingan diam di mana satu variabel menggunakan megabyte dan variabel lainnya menggunakan byte.

Kesamaan dari keempat kesalahan ini adalah bahwa kode tersebut secara sintaksis sudah benar. Bug ada dalam asumsi yang dibawa oleh pengembang di kepala mereka, bukan di diff, dan bahkan tidak ada di kode di sekitarnya. Di sinilah kira-kira di mana tinjauan kode AI mencapai puncaknya saat ini.

Setelah Menemukan Bug, Model Mana yang Paling Baik untuk Memperbaikinya?

Dalam peninjauan kode, menemukan bug adalah setengah dari pekerjaan. Setengah lainnya adalah memperbaikinya. Jadi setelah putaran debat, saya menambahkan evaluasi rekan sejawat untuk mengukur seberapa berguna saran perbaikan dari masing-masing model.

Untuk mengukur hal ini, saya menambahkan babak evaluasi rekan sejawat setelah debat. Setiap model membuka sesi baru dan bertindak sebagai juri anonim, menilai ulasan model lainnya. Kelima model dipetakan secara acak ke Peninjau A/B/C/D/E, sehingga tidak ada juri yang tahu model mana yang menghasilkan ulasan yang mana. Setiap juri memberi nilai pada empat dimensi, dengan nilai 1 hingga 10: akurasi, kemampuan untuk ditindaklanjuti, kedalaman, dan kejelasan.

ModelAkurasiDapat ditindaklanjutiKedalamanKejelasanSecara keseluruhan
Qwen8.68.68.58.78,6 (berada di urutan pertama)
Claude8.48.28.88.88,6 (berada di urutan pertama)
Codex7.77.67.17.87.5
Gemini7.47.26.77.67.2
MiniMax7.16.76.97.47.0

Qwen dan Claude berada di posisi pertama dengan selisih yang jelas. Keduanya secara konsisten mendapat nilai tinggi di keempat dimensi, sementara Codex, Gemini, dan MiniMax mengelompok satu poin penuh atau lebih di bawahnya. Khususnya, Gemini, yang terbukti berharga sebagai mitra pencari bug untuk Claude dalam analisis pasangan, berada di peringkat paling bawah untuk kualitas ulasan. Pandai menemukan masalah dan pandai menjelaskan cara memperbaikinya jelas merupakan keterampilan yang berbeda.

Kesimpulan

Claude adalah orang yang Anda percayai dengan ulasan yang paling sulit. Ia bekerja melalui seluruh rantai panggilan, mengikuti jalur logika yang dalam, dan menarik konteksnya sendiri tanpa Anda perlu menyuapinya. Pada bug tingkat sistem L3, tidak ada yang bisa menandinginya. Kadang-kadang ia terlalu percaya diri dengan matematika, tetapi ketika model lain membuktikan bahwa ia salah, ia akan memilikinya dan menelusuri di mana penalarannya rusak. Gunakan untuk kode inti dan bug yang tidak boleh Anda lewatkan.

Gemini datang dengan penuh semangat. Gemini memiliki pendapat yang kuat tentang gaya kode dan standar teknik, dan cepat dalam membingkai masalah secara struktural. Kelemahannya adalah bahwa ia sering berada di permukaan dan tidak menggali cukup dalam, itulah sebabnya ia mendapat nilai rendah dalam evaluasi rekan sejawat. Di mana Gemini benar-benar mendapatkan tempatnya adalah sebagai penantang: penolakannya memaksa model lain untuk memeriksa ulang pekerjaan mereka. Pasangkan dengan Claude untuk perspektif struktural yang terkadang dilewati oleh Claude.

Codex hampir tidak mengucapkan sepatah kata pun. Tetapi ketika dia bicara, dia sangat berarti. Tingkat keberhasilan pencariannya terhadap bug yang sebenarnya tinggi, dan ia memiliki kemampuan untuk menangkap satu hal yang dilewatkan oleh orang lain. Dalam contoh PR #44474, Codex adalah model yang menemukan masalah kunci primer bernilai nol yang memulai seluruh rantai. Anggap saja sebagai peninjau tambahan yang menangkap apa yang terlewatkan oleh model utama Anda.

Qwen adalah yang paling lengkap di antara kelimanya. Kualitas ulasannya menyamai Claude, dan sangat bagus dalam menyatukan perspektif yang berbeda ke dalam saran perbaikan yang dapat Anda lakukan. Aplikasi ini juga memiliki tingkat deteksi L2 tertinggi dalam mode bantuan konteks, yang menjadikannya standar yang solid untuk ulasan PR sehari-hari. Satu kelemahannya: dalam debat yang panjang dan multi-ronde, terkadang kehilangan jejak konteks sebelumnya dan mulai memberikan jawaban yang tidak konsisten di ronde selanjutnya.

MiniMax adalah yang paling lemah dalam menemukan bug dengan sendirinya. Paling baik digunakan untuk mengisi grup multi-model daripada sebagai pengulas mandiri.

Keterbatasan Eksperimen Ini

Beberapa peringatan untuk menjaga agar eksperimen ini tetap dalam perspektif:

Ukuran sampelnya kecil. Hanya ada 15 PR, semuanya dari proyek Go/C++ yang sama (Milvus). Hasil ini tidak dapat digeneralisasi untuk semua bahasa atau basis kode. Perlakukan mereka sebagai arahan, bukan definitif.

Model pada dasarnya bersifat acak. Menjalankan perintah yang sama dua kali dapat menghasilkan hasil yang berbeda. Angka-angka dalam posting ini adalah satu snapshot, bukan nilai yang diharapkan stabil. Peringkat model individu harus dianggap enteng, meskipun tren yang lebih luas (debat mengungguli individu, model yang berbeda unggul pada jenis bug yang berbeda) konsisten.

Urutan berbicara sudah ditetapkan. Debat menggunakan urutan yang sama di semua ronde, yang mungkin telah mempengaruhi bagaimana model yang berbicara kemudian merespons. Eksperimen di masa depan dapat mengacak urutan per ronde untuk mengontrol hal ini.

Cobalah sendiri

Semua alat dan data dari eksperimen ini adalah sumber terbuka:

  • Magpie: Alat sumber terbuka yang mengumpulkan konteks kode (rantai panggilan, PR terkait, modul yang terpengaruh) dan mengatur perdebatan multi-model yang berlawanan untuk peninjauan kode.

  • AI-CodeReview-Arena: Pipeline evaluasi, konfigurasi, dan skrip lengkap.

  • Kasus pengujian: Semua 15 PR dengan anotasi bug yang diketahui.

Semua bug dalam percobaan ini berasal dari pull request yang nyata di Milvus, sebuah database vektor sumber terbuka yang dibangun untuk aplikasi AI. Kami memiliki komunitas yang cukup aktif di Discord dan Slack, dan kami ingin lebih banyak orang yang mengutak-atik kodenya. Dan jika Anda akhirnya menjalankan benchmark ini pada basis kode Anda sendiri, silakan bagikan hasilnya! Saya sangat ingin tahu apakah tren ini berlaku di berbagai bahasa dan proyek.

Teruskan Membaca

    Try Managed Milvus for Free

    Zilliz Cloud is hassle-free, powered by Milvus and 10x faster.

    Get Started

    Like the article? Spread the word

    Terus Baca