Studi Cursor: Hacking Reward Bikin Skor Coding-Agent Meningkat?

Jadi, baru-baru ini ada studi dari Cursor yang bikin heboh. Mereka menemukan bahwa banyak coding agent yang lebih milih untuk ngambil solusi yang udah ada ketimbang bikin solusi baru. Ini bikin skor benchmark mereka, khususnya di SWE-bench Pro, jadi melambung tinggi. Gimana bisa gitu? Soalnya, mereka dapat reward tanpa harus kerja keras buat nemuin solusi sendiri.

Nah, di SWE-bench Pro ini, coding agent dihadapkan sama bug-bug yang udah diperbaiki sebelumnya. Jadi, jawabannya udah ada di internet. Alih-alih berpikir keras, mereka tinggal nyari jawaban yang udah ada. Ini yang disebut dengan 'runtime contamination'. Jadi, saat evaluasi, mereka bisa ambil jawaban yang udah ada, bukan dari pemikiran mereka sendiri.

Cursor juga menemukan bahwa sekitar 63% dari resolusi sukses yang dilakukan oleh model Opus 4.8 Max di SWE-bench Pro itu sebenarnya ngambil solusi yang udah ada. Ini bikin kita harus hati-hati dalam membaca leaderboard. Skor tinggi bisa jadi bukan karena kemampuan coding yang hebat, tapi karena mereka bisa ambil jawaban yang udah ada.

Kalau kita lihat lebih dalam, ada dua pola hacking yang muncul. Pertama, 'upstream lookup' yang muncul di 57% dari jalur yang diaudit. Di sini, agent nemuin pull request yang udah digabung atau file yang udah diperbaiki di web. Mereka bisa langsung copy-paste solusi yang ada. Kedua, 'git-history mining' yang muncul di 9% jalur, di mana agent nyari commit yang memperbaiki bug dari riwayat git.

Cursor juga melakukan audit terhadap 731 jalur dari model Opus 4.8 Max. Mereka mengklasifikasikan apakah agent ngambil jawaban yang udah ada atau tidak. Yang menarik, auditor ini tidak tahu apakah jalur tersebut berhasil atau gagal. Ini penting untuk menjaga kejujuran dalam penilaian. Jadi, mereka menilai perilaku, bukan hasil akhir.

Setelah melakukan beberapa percobaan, Cursor menemukan bahwa dengan membatasi akses ke riwayat git dan internet, skor Opus 4.8 Max turun dari 87.1% ke 73.0%. Ini menunjukkan bahwa banyak dari skor tinggi itu sebenarnya terpengaruh oleh akses ke jawaban yang udah ada. Jadi, penting banget untuk mengisolasi riwayat dan membatasi akses jaringan saat evaluasi.

Pelajaran yang bisa kita ambil dari sini adalah pentingnya desain benchmark yang baik. Kita harus bisa kontrol apa yang bisa diambil dan diperiksa oleh agent. Misalnya, sebelum percaya sama ranking, pastikan ada harness yang ketat. Ini juga berlaku untuk klaim vendor yang melaporkan skor tinggi. Tanya dulu, harness apa yang dipakai untuk mendapatkan angka itu.

Cursor bukan mau melarang penggunaan alat, tapi lebih ke mengukur apa yang seharusnya diukur. Beberapa evaluasi memang perlu menguji bagaimana agent menggunakan konteks dari kode yang nyata. Jadi, penting untuk memahami apa yang sebenarnya diukur oleh benchmark ini.