FrontierCode Diamond: 13.4% Patch Layak Digabungkan pada 50 Tugas Sulit (Juni 2026)

Materi tambahan tentang konfigurasi alat tersedia di dokumentasi Ailoot.

Apa Itu FrontierCode, dan Mengapa Ini Penting?#

Cognition adalah perusahaan di balik Devin (insinyur AI otonom pertama, Maret 2024) dan Windsurf (diakuisisi pada Juli 2025). Mereka juga mengembangkan lini model SWE-1.x mereka sendiri. Benchmark ini diterbitkan di blog publik cognition.com/blog/frontier-code.

Perubahan utamanya bukan soal angka baru. Ini soal skala yang kini digunakan untuk mengukur berbagai hal.

Benchmark ini memiliki tiga tingkat kesulitan: Extended (150 tugas, set lengkap), Main (100 tugas tersulit, termasuk Diamond), dan Diamond (50 tugas yang sangat berat). Cognition sengaja membiarkan Diamond “sebagian besar belum jenuh”—bahkan model terbaik pun menyelesaikan kurang dari 15%. Tujuannya adalah memberi benchmark ini ruang satu tahun ke depan dan mencegahnya menjadi jenuh dalam sebulan, seperti yang terjadi pada HumanEval.

Apa yang Diukur FrontierCode: “Apakah Maintainer Akan Menggabungkan PR Ini?”#

Enam sumbu evaluasi (dari blog resmi Cognition):

1. Kebenaran perilaku — apakah patch menyelesaikan tugas?
2. Keamanan terhadap regresi — apakah patch menghindari kerusakan pada kode yang sudah ada?
3. Kerapian mekanis — apakah patch lolos pemeriksaan build, lint, dan gaya?
4. Kebenaran pengujian — apakah pengujian yang ditulis agen valid (pengujian yang lolos pada kode apa pun tidak dihitung)?
5. Cakupan — apakah patch menghindari perubahan pada berkas yang tidak diminta?
6. Kualitas kode — apakah kode mengikuti konvensi proyek, dan apakah mudah dibaca?

Agar patch dianggap layak digabungkan, patch harus lolos keenam sumbu. Gagal satu saja, patch tidak akan digabungkan.

Itulah pergeseran sudut pandang yang utama. “Kebenaran kini menjadi syarat dasar,” kata Cognition. Sebelumnya, benchmark bertanya, “Apakah kode lolos pengujian?” Kini pertanyaannya, “Apakah pemimpin teknis sungguhan akan memasukkan ini ke dalam proyek?”

Cognition memperkenalkan tiga teknik penilaian baru:

• Reverse-Classical: pengujian yang ditulis agen harus gagal pada versi kode yang rusak. Jika tidak, pengujian itu palsu.
• Code Scope: pemeriksa otomatis memastikan patch tetap berada dalam berkas dan jumlah baris yang disepakati untuk tugas tersebut.
• Adaptive Classical Grading: alat LLM “mutagent” menyesuaikan pengujian ketat agar sesuai dengan variasi solusi yang valid.

Mengapa Benchmark Lama Tak Lagi Berfungsi?#

Agen AI sudah menguasai HumanEval pada 2024. SWE-bench Verified kurang lebih sama: pada Agustus 2025, OpenAI secara terbuka mengakui masalah kontaminasi (model telah “melihat” kumpulan data itu selama pelatihan). Benchmark kehilangan kemampuannya untuk membedakan model-model teratas.

Studi utama yang meruntuhkan tolok ukur lama terbit pada Maret 2026.

Yang mereka lakukan:

• Memilih 4 maintainer aktif dari 3 repositori (scikit-learn, Sphinx, pytest).
• Meminta mereka mengevaluasi 296 PR buatan AI dari SWE-bench Verified—semua PR tersebut lolos pengujian otomatis.
• Membandingkan keputusan para maintainer dengan penilaian otomatis.

Dengan kata lain, benchmark menyatakan “lulus”, sedangkan maintainer berkata “tidak akan digabungkan”—dan ini terjadi pada rata-rata seperempat kasus. Tiga alasan utama penolakan, dari yang paling ringan hingga paling serius:

1. Kualitas kode — tidak sesuai dengan gaya repositori.
2. Merusak kode lain — merusak kode di sekitarnya.
3. Kegagalan fungsi inti — tidak sepenuhnya menyelesaikan tugas, meskipun pengujian menunjukkan hasil hijau.

FrontierCode memformalkan masalah ini secara tepat. Cognition mengambil gagasan ini dan mengembangkannya menjadi benchmark lengkap dengan lebih dari 20 maintainer, bukan 4.

Satu lagi pukulan telak adalah studi Desember 2025 tentang keamanan patch buatan AI.

Di dalamnya, 61% solusi SWE-Agent dengan Claude 4 Sonnet benar secara fungsional, tetapi hanya 10.5% di antaranya yang aman.

Kodenya lolos pengujian, tetapi setiap patch lainnya memperkenalkan celah keamanan. Hal ini sama sekali tidak terlihat pada benchmark SWE-bench—benchmark itu tidak mengukur keamanan. FrontierCode setidaknya berupaya menangkapnya melalui sumbu “kerapian mekanis” dan kualitas kode.

Peringkat Model: Opus 4.8 di 13.4%, GPT-5.5 di 6.3%#

Hal-hal yang menonjol dari tabel:

• Satu pemimpin yang jelas. Opus 4.8 dari Anthropic unggul kira-kira dua kali lipat dari pesaing terdekatnya. Kesenjangan yang sulit terlihat di SWE-bench tampak jelas di FrontierCode.
• Model terbuka belum mengejar. Kimi K2.6—model kode terbuka terbaik—mendapat skor 3.8% di Diamond. Itu 3–4 kali lebih rendah daripada Opus 4.8. Cognition tidak menerbitkan kisi lengkap Kimi K2.6 untuk Main dan Extended, jadi belum ada perbandingan untuk set lengkap.
• Cognition dengan jujur menempatkan modelnya sendiri di bagian bawah tabel.

Subset Diamond sengaja dibiarkan “belum jenuh”. Cognition menyediakan margin keamanan untuk tahun-tahun mendatang. Jika benchmark sebelumnya jenuh dalam 12–18 bulan, FrontierCode dirancang dengan batas atas yang lebih tinggi.

Apa Arti “13% Layak Digabungkan” bagi Vibe Coder yang Menggunakan Claude Code?#

Pertama, pembingkaian ulang yang penting: set Diamond FrontierCode sengaja dibuat sangat berat. Untuk tugas biasa di proyek startup baru tanpa empat puluh modul yang saling bergantung, agen AI menunjukkan kinerja yang jauh lebih baik. Opus 4.8 yang sama mendapat skor 51.8% layak digabungkan di Extended (150 tugas, set lengkap). Gambarnya sama sekali berbeda.

Hasil 51.8% berlaku untuk set Extended benchmark yang berisi 150 tugas. Nilainya lebih tinggi daripada hasil Diamond, tetapi kedua angka tidak memperkirakan kelayakan penggabungan patch setiap model pada tugas Anda sendiri. Skor Main atau Extended yang tidak tersedia untuk model lain tidak membenarkan pengisian perkiraan kinerjanya.

Maknanya bagi vibe coder yang mendorong kode ke produksi:

• Pengujian hijau tak lagi berarti “siap digabungkan.” Pengujian yang ditulis AI sendiri mungkin tidak berguna—pengujian itu lolos pada kode apa pun. FrontierCode mengukurnya secara langsung melalui Reverse-Classical: jika sebuah pengujian tidak gagal pada versi yang rusak, pengujian itu tidak dihitung.
• Gaya dan konvensi repositori itu penting. Jika suatu proyek memiliki pola yang sudah ditetapkan dan AI tidak mengikutinya, rekan kolaborator sungguhan tidak akan menerima perubahan itu. Dalam proyek solo tanpa aturan, ini bukan masalah besar. Dalam tim, ini adalah masalah nomor satu.
• Pengujian tidak mengatasi keamanan. Ingat angka di atas: hanya 10.5% patch yang aman meski 61% benar. Ini perlu diperiksa secara terpisah, dengan alat yang mendeteksi token, berkas .env, dan kata sandi bawaan.
• Melampaui tugas adalah kesalahan AI yang lazim. Anda memintanya memperbaiki fungsi otorisasi, lalu mendapat patch yang juga menulis ulang lapisan internal dan pencatatan log. Ini salah satu dari 6 sumbu FrontierCode.

6 Kategori Kesalahan Apa yang Dilakukan AI pada Tugas Sulit?#

Mari kita bahas setiap sumbu dengan bahasa sederhana:

1. Kebenaran perilaku — apakah patch menyelesaikan tugas?

Sumbu paling dasar. AI sering menulis kode yang tampak seperti solusi, tetapi menyelesaikan masalah yang keliru. Saya meminta AI “menambahkan tanda baca telah dibaca ke pesan” dan mendapat fungsi markAsRead, tetapi fungsi itu belum dihubungkan ke komponen chat itu sendiri. Pengujian fungsi tersebut lolos. Tugas bisnisnya belum terselesaikan.

2. Keamanan terhadap regresi — apakah patch menghindari kerusakan pada kode di sekitarnya?

AI mengubah satu modul, lalu modul lainnya tidak berfungsi. Kasus yang paling umum: agen AI mengubah tanda tangan fungsi dan lupa bahwa fungsi itu dipanggil dari 17 tempat lain. Anda tidak bisa melihat hal ini di SWE-bench—pengujian hanya dijalankan untuk satu berkas. Di FrontierCode, mereka menjalankan seluruh rangkaian pengujian repositori.

3. Kerapian mekanis — apakah patch lolos pemeriksaan build, lint, dan gaya?

AI bisa menghasilkan kode yang berhasil dikompilasi secara lokal tetapi gagal di CI: impor yang hilang, tab sebagai pengganti spasi, dua spasi di akhir baris, atau kesalahan kecil di eslint.config.js. Dalam proyek aktif, gaya bukan soal selera; itu aturan tim.

4. Kebenaran pengujian — apakah pengujian yang ditulis AI valid?

Sumbu yang paling rumit. AI menulis pengujian yang lolos. Namun pengujian itu lolos pada kode apa pun, termasuk kode yang rusak. Saya sudah sering melihat ini: pengujian memeriksa “apakah skrip berhenti dengan kesalahan?” tetapi tidak memeriksa “apakah skrip mengembalikan hasil yang benar?” Reverse-Classical FrontierCode menangkap kasus ini secara tepat.

5. Cakupan — apakah patch menghindari perubahan pada berkas yang tidak terkait?

Saya meminta AI memperbaiki satu fungsi dan mendapat patch untuk 12 berkas, termasuk berkas yang tidak berkaitan dengan tugas. Itulah “inisiatif” AI yang membuat proyek produksi rusak dengan mengubah hal-hal yang tidak saya minta. Sumbu ini menjadi penghalang mutlak di FrontierCode.

6. Kualitas kode — apakah kode mengikuti konvensi repositori?

AI menulis fungsinya sendiri “dari awal” alih-alih menggunakan helper yang sudah ada di lib/. Atau AI memberi nama variabel dengan cara yang tidak sesuai gaya proyek. Atau AI menempatkan logika di lapisan arsitektur yang salah. Dari sudut pandang pengujian, semuanya berfungsi. Dari sudut pandang pemimpin teknis, perubahan itu tidak akan digabungkan.

Cara Memeriksa Kode AI Sebelum Push: 5 Langkah#

1. Jalankan seluruh rangkaian pengujian, bukan hanya pengujian yang terkait dengan perubahan

   AI sering mengubah kode di luar tugas. Masalahnya akan muncul pada pengujian di sekitarnya. Saya menjalankan seluruh rangkaian pengujian (dengan satu perintah npm test, tanpa path), bukan hanya pengujian untuk berkas tertentu. Pada proyek besar, menjalankannya secara paralel dengan git worktree akan praktis (lihat Git worktree di Claude Code).

2. Jalankan pemeriksaan lint, gaya, dan tipe

   Tiga perintah berurutan: eslint ., prettier --check ., tsc --noEmit. Agen AI bisa melewatkan tab maupun spasi ekstra di akhir baris. Jika proyek memiliki pemeriksaan ketat, jalankan secara lokal sebelum dirilis.

3. Uji pengujiannya

   Yang paling penting dari 5 pemeriksaan. Saya membuat sedikit “kerusakan” pada kode (mengubah return true menjadi return false). Pengujian harus gagal. Jika pengujian tidak gagal, AI menulisnya hanya untuk formalitas dan pengujian itu tidak berguna. Saya menghapus pengujian tersebut dan meminta AI menulis ulang dengan syarat wajib: pengujian harus gagal pada versi yang rusak.

4. Periksa berkas apa saja yang disentuh AI

   Perintah git diff --stat menunjukkan berkas mana yang berubah dan berapa barisnya. Jika AI menyentuh 12 berkas sebagai tanggapan atas permintaan “perbaiki formulir kontak”, AI telah melampaui cakupan tugas. Saya mengembalikan perubahan tambahan dengan satu perintah untuk berkas tersebut.

5. Jalankan pemeriksaan keamanan menggunakan skill siap pakai

   Pengujian tidak menangkap injeksi SQL atau kata sandi yang ditulis langsung. Saya menggunakan skill keamanan siap pakai untuk Claude Code (lihat 754 skill keamanan siap pakai). Setidaknya, cari sendiri kata “password,” “secret,” dan “key” di kode proyek, lalu periksa kelengkapan .env.example.

Semua 5 langkah mencakup 5 dari 6 sumbu FrontierCode (1–5). Sumbu keenam—kualitas kode—diperiksa secara otomatis melalui linting ditambah tinjauan manusia.

Apa yang Sebenarnya Meningkatkan Peluang Kode Layak Digabungkan?#

Agen AI di proyek yang belum disiapkan hanya melihat berkas yang Anda buka untuknya. Agen itu tidak memiliki riwayat keputusan Anda, tidak mengetahui konvensi Anda, dan tidak punya peta modul-modul Anda. Ini bukan masalah besar untuk perubahan sederhana. Untuk perubahan sulit, kurangnya konteks proyek adalah risiko yang layak ditangani. Angka benchmark 13.4% tidak mengisolasi kualitas konteks sebagai penyebabnya.

Yang perlu Anda lakukan untuk mengubah 13% itu menjadi sesuatu yang benar-benar bisa Anda dorong ke produksi:

1. Aturan proyek — agar AI meniru penalaran Anda, bukan rata-rata internet.

Ini adalah kumpulan solusi siap pakai, kebiasaan, dan aturan yang telah Anda pelajari dalam format yang dibaca agen AI untuk setiap permintaan. Setelah ada 30+ aturan, AI berhenti mengarang “rata-rata industri” dan mulai memberi saran dengan gaya Anda. Pelampauan cakupan tugas bisa diatasi dengan satu baris dalam aturan: “jangan sentuh berkas di luar yang disebutkan secara eksplisit dalam permintaan.”

2. Peta proyek — folder yang menjelaskan proyek.

Di sinilah Anda menyimpan produk, audiens, ekonomi, metrik, dan pengaturan. Sebelum setiap permintaan, agen AI membaca daftar isi dan memahami bagian bisnis mana yang sedang dikerjakannya. Ini secara otomatis menangani dua alasan penolakan yang disebutkan di atas: gaya dan kerusakan pada kode lain.

3. Context Engineering — mengelola apa yang dilihat AI sebelum permintaan.

Ini bukan soal “cara merumuskan prompt”, melainkan “apa yang dimasukkan ke jendela konteks SEBELUM prompt.” CLAUDE.md, prasyarat, dan tautan terarah ke berkas. Ini menangani kegagalan kebenaran perilaku dan kualitas kode.

Gunakan kombinasi ini sebagai persiapan pemeriksaan, bukan bukti bahwa lima sumbu sudah lolos. Verifikasi perilaku, regresi, pengujian, cakupan, dan kualitas kode pada patch sebenarnya sebelum menerimanya.

Lapisan tambahan lainnya adalah agen peninjau:

• Cursor Bugbot — menjalankan tinjauan pada setiap PR. Menurut Cursor, alat ini memproses sekitar 2 juta PR per bulan.
• Subagen bersarang di Claude Code v2.1.172 — satu agen menulis kode, agen kedua meninjaunya, dan agen ketiga menjalankan pengujian. Ini gagasan yang sama seperti FrontierCode: memisahkan peran “penulis” dan “pemimpin teknis.”

Lihat juga: Keamanan Vibe Coding, Cara Mengonfigurasi Claude Code agar Tidak Merusak Proyek Anda pada Malam Hari, dan Context Engineering sebagai sebuah konsep.

Untuk materi tambahan tentang bekerja dengan alat, lihat dokumentasi Ailoot.