Fable 5, Opus 4.8 dan Sonnet 4.6: cara membandingkan LLM secara jujur pada kode Anda sendiri

Ketika sebuah model baru dirilis, pengumumannya menjawab pertanyaan «seberapa lebih baik ia pada benchmark» — dan tidak menjawab satu-satunya pertanyaan yang menarik bagi saya: apa yang akan ia ubah dalam pekerjaan saya. Saya melakukan eksperimen terkontrol: tiga model Claude — Fable 5, Opus 4.8 dan Sonnet 4.6 — menerima tugas yang persis sama untuk mengaudit basis kode blog ini, masing-masing dalam salinan repositori yang terisolasi, dengan rubrik penilaian yang disepakati sebelumnya. Dalam artikel ini — metodologinya sendiri, yang dapat diulang pada proyek apa pun, hasilnya, dan secara terpisah — bagaimana eksperimen ini gagal dua kali dan apa yang diajarkannya.

Mengapa benchmark tidak menjawab pertanyaan saya

Benchmark publik memiliki dua masalah, dan keduanya fundamental. Yang pertama — kontaminasi data: contoh uji merembes ke dalam kumpulan data pelatihan, dan model sebagian «mengingat» jawaban alih-alih menyelesaikan tugas. Ini bukan kecurigaan marginal, melainkan subjek dari seluruh bidang penelitian: tinjauan Xu dan rekan-rekan (2024) mensistematisasi penelitian kontaminasi benchmark, dan tinjauan EMNLP 2025 mencatat respons industri — peralihan dari uji statis ke uji yang dihasilkan secara dinamis.

Masalah kedua lebih sederhana: benchmark mengukur bukan tugas saya. Saya tidak membutuhkan model yang paling baik menyelesaikan soal olimpiade. Saya membutuhkan model yang akan menemukan bug nyata di blog Laravel saya, tidak mengarang yang tidak ada, dan membuktikan bahwa perbaikannya berfungsi.

Dari sini muncul pemikiran sederhana: tempat uji terbaik untuk membandingkan model adalah proyek Anda sendiri. Kodenya dalam kombinasi seperti itu tidak ada dalam kumpulan data pelatihan, tugas-tugasnya persis yang saya bayar, dan hasilnya dapat saya periksa sendiri karena saya mengenal kode ini.

Desain eksperimen: satu prompt, tiga dunia terisolasi

Tugas untuk ketiga model persis sama — hanya nama branch dan folder hasil yang berbeda. Empat fase: audit sistem artikel blog dua bahasa dengan bukti setiap temuan berupa файл:строка dengan kutipan kode; pemilihan solusi untuk tiga temuan utama dengan deskripsi kompromi; implementasi satu perbaikan dengan pemeriksaan mandiri; catatan hasil dalam bahasa Rusia dan Inggris. Siklus penuh kerja rekayasa, bukan «tanya-jawab» yang terisolasi — pendekatan seperti ini juga direkomendasikan oleh Anthropic: mengevaluasi agen pada tugas dari produk nyata, menurut rubrik yang disepakati sebelum peluncuran.

Tiga aturan membuat perbandingan jujur:

Isolasi. Setiap model bekerja di git worktree terpisah — salinan direktori kerja sendiri dengan branch sendiri. Model secara fisik tidak dapat melihat hasil satu sama lain atau mengganggu satu sama lain.

Perlindungan dari halusinasi — dalam prompt itu sendiri. Baris kunci tugas: «temuan yang dikarang (kode yang tidak ada, baris yang salah) lebih buruk daripada tidak adanya temuan». Tanpa insentif ini, model yang diminta menemukan masalah cenderung «menemukannya» dalam hal apa pun. Dengan ini — setiap temuan wajib bertahan dari pemeriksaan manual.

Pengecualian petunjuk dari penilaian. Di repositori terdapat CLAUDE.md yang menjelaskan jebakan proyek yang diketahui — misalnya, jalur relatif ke aset yang rusak pada URL dengan prefiks bahasa. Ketiga model membaca file ini, sehingga temuan seperti itu «gratis»: dihitung sebagai ketelitian, tetapi bukan sebagai kedalaman.

Rubrik: menilai hanya apa yang dapat diperiksa secara manual

Sebelum peluncuran saya menetapkan enam sumbu masing-masing lima poin: akurasi audit (pemeriksaan manual sampel temuan menurut файл:строка), kedalaman (temuan terkonfirmasi yang tidak ada dalam petunjuk), kualitas penalaran tentang kompromi, kode dan realitas pemeriksaan mandiri, kualitas teks Rusia dan Inggris, disiplin (nol pertanyaan kepada manusia, tidak ada pelanggaran batasan). Prinsipnya sama dengan code review yang baik: semakin sedikit sumbu bergantung pada selera dan semakin banyak pada fakta yang dapat diverifikasi, semakin dapat dipercaya.

Bagaimana semuanya gagal pertama kali

Peluncuran pertama saya lakukan dengan salah — dan ini ternyata bagian eksperimen yang paling dapat dipindahkan. Saya membuka tiga sesi interaktif secara paralel di folder repositori yang sama. Beberapa menit kemudian di working tree terdapat perubahan yang belum di-commit yang tidak mungkin diatribusikan: checkout bersama berarti ketika satu sesi melakukan git checkout -b, branch berganti untuk ketiganya, dan perubahan serta commit mereka tercampur. Salah satu sesi juga melakukan git stash dan menyapu bersih semuanya — termasuk file saya sendiri yang tidak terkait dengan eksperimen.

“Agen AI paralel dalam satu folder bukanlah eksperimen paralel. Ini adalah satu konflik besar dengan tiga penulis.”

– kesimpulan yang membuat saya harus memulai ulang

Hasil dari dua sesi harus diakui tidak layak: bahkan jika mereka menyelesaikannya sampai akhir, saya tidak bisa dengan jujur mengatakan revisi siapa yang saya nilai. Peluncuran kedua — sudah dalam worktree terisolasi — terbentur batas tarif: dua agen mati saat start, dan yang ketiga macet, tetap terlihat "berjalan" di antarmuka. Diagnosis ditegakkan oleh sistem berkas, bukan indikator status: dalam dua puluh menit di salinan kerjanya tidak muncul satu berkas pun. Ini pelajaran portabel kedua: keaktifan agen diperiksa dari perubahan di disk. Setelah restart, ketiga model menjalani siklus penuh dalam kondisi setara.

Hasil: di mana model sama dan di mana berbeda

Hasil terpenting adalah apa yang tidak terjadi: tidak ada halusinasi pada satu model pun. Saya memeriksa manual tiga atau lebih temuan dari masing-masing — semua kutipan dan nomor baris akurat hingga karakter. Untuk tugas audit ini adalah ambang kepercayaan utama, dan ketiganya lulus.

Selanjutnya perbedaan dimulai:

	Fable 5	Opus 4.8	Sonnet 4.6
Temuan terkonfirmasi	11	5	9
Unik nontrivial	3	1	2
Verifikasi mandiri perbaikan	render integrasi pada DB sementara, xmllint, atribusi tes gagal milik orang lain	linter + render; menangkap bug sendiri	hanya linter dan daftar rute
Token / waktu	164k / 21 mnt	101k / 12 mnt	131k / 12 mnt
Total rubrik (dari 30)	30	24	25,5

Perbedaan kualitatif lebih informatif daripada skor. Opus 4.8 — satu-satunya yang tidak menyadari judul rusak Content-Type di sitemap (dua lainnya menemukannya) dan membiarkannya dalam perbaikannya sendiri; dan ke dalam teks Rusianya merembes kata Inggris — «и even путь к картинке». Sonnet 4.6 membuat perbaikan yang benar, tetapi verifikasi mandirinya deklaratif: linter alih-alih menjalankan. Fable 5 menonjol justru pada verifikasi mandiri: menemukan bahwa php di mesin saya adalah pembungkus atas kontainer docker yang dimount ke direktori utama, membangun ulang semua pemeriksaan melalui kontainer sekali pakai dan menjalankan perbaikannya secara integrasi pada basis data sementara. Perbedaan antara "saya sudah melakukannya" dan "saya membuktikan bahwa saya sudah melakukannya" — inilah sumbu paling pembeda untuk tugas agen.

Sinyal berguna lainnya adalah konvergensi: ketiga model secara independen menyebut masalah sitemap yang sama sebagai temuan utama. Ketika auditor independen bertemu pada temuan teratas, ini adalah analog murah dari kesepakatan antar-pakar: masalahnya hampir pasti nyata.

Juri dari antara peserta

Penilaian rubrik dilakukan oleh Fable 5 — model yang sama yang ikut dalam perbandingan. Ini celah metodologis, dan harus dikatakan terus terang: juri LLM secara sistematis melebihkan penilaian atas teks mereka sendiri, dan kecenderungannya makin kuat semakin baik model mengenali teksnya — ini ditunjukkan dalam karya Panickssery dan rekan di NeurIPS 2024. Bias dapat diringankan dengan dua cara, dan saya memakai keduanya: pertama, menggeser rubrik semaksimal mungkin dari sumbu selera ke fakta yang dapat diverifikasi — akurasi baris, kelengkapan perbaikan, kata asing yang merembes tidak bergantung pada simpati juri; kedua, mendeklarasikan konflik secara eksplisit dan menyerahkan sumbu sengketa ke pemeriksaan silang model lain atau manusia. Sumbu subjektif dari hasil akhir saya — kualitas teks, kualitas penalaran — patut dibaca dengan koreksi ini.

Batasan kejujuran

Satu kali jalan per model adalah n=1: perbedaan satu-dua poin tidak berarti apa-apa, hanya kesenjangan kualitatif yang layak dipercaya — bug yang terlewat, kedalaman verifikasi mandiri. Eksperimen mengukur tiga model pada satu tugas di satu domain; «Fable 5 lebih baik secara umum» tidak mengikutinya. Dan perlu diingat soal biaya: model teratas menghabiskan 1,6 kali lebih banyak token dan hampir dua kali lebih lama daripada peserta paling hemat, dan tokennya menurut harga juga lebih mahal per se — untuk tugas rutin ini argumen kuat untuk model yang lebih sederhana.

Yang saya ambil untuk diri sendiri

Metodologi menyusut menjadi daftar periksa singkat yang berlaku untuk proyek apa pun dan model apa pun:

• Tugas uji — siklus penuh pekerjaan nyata pada kode sendiri, bukan soal sintetis.
• Satu prompt untuk semua, isolasi melalui worktree terpisah, hasil — di cabang terpisah.
• Dalam prompt — harga halusinasi yang eksplisit: temuan yang dikarang lebih buruk daripada tidak ada temuan.
• Petunjuk yang tersedia untuk semua (dokumentasi, catatan di repositori) dikecualikan dari penilaian kedalaman.
• Rubrik ditetapkan sebelum peluncuran dan bersandar pada fakta yang dapat diverifikasi, bukan pada kesan.
• Sampel temuan diperiksa manual; kesamaan temuan teratas pada model independen — sinyal realitasnya.
• Juri-peserta — konflik yang dideklarasikan: sumbu sengketa diserahkan ke penilaian silang.
• Keaktifan agen diperiksa dari disk, bukan dari indikator di antarmuka.

Bonus yang tidak masuk rencana: eksperimen terbayar sendiri. Tiga audit independen menemukan masalah nyata di blog — dari sitemap tanpa halaman Inggris hingga kueri mati di controller — dan dua perbaikan siap sudah ada di cabang, menunggu dipindahkan ke produksi. Perbandingan model pada kode sendiri, berbeda dari membaca benchmark, meninggalkan bukan sekadar pendapat.

Sumber dan acuan

• Benchmark Data Contamination of Large Language Models: A Survey (Xu et al., 2024) — sistematisasi masalah kontaminasi benchmark; argumen utama untuk pengujian pada kode sendiri.
• Benchmarking LLMs Under Data Contamination: From Static to Dynamic Evaluation (EMNLP 2025) — bagaimana industri beralih dari pengujian statis ke dinamis; eksperimen saya adalah kasus khusus dari pengujian dinamis.
• Demystifying evals for AI agents (Anthropic Engineering, 2026) — praktik evaluasi agen: tugas dari produk nyata, rubrik yang dapat diverifikasi, perbedaan antara lintasan dan hasil.
• LLM Evaluators Recognize and Favor Their Own Generations (NeurIPS 2024) — mengapa model-juri menilai dirinya sendiri terlalu tinggi dan apa yang harus dilakukan.
• Run parallel sessions with worktrees (Claude Code Docs) — mekanisme bawaan untuk mengisolasi sesi agen paralel, yang tanpanya peluncuran eksperimen pertama pun gagal.