Tahun lalu, tim engineering di sebuah perusahaan perangkat lunak harus menentukan agen coding berbasis kecerdasan buatan untuk membantu proses pengembangan. Salah seorang anggota tim secara sukarela mengambil alih tugas evaluasi tersebut. Ia merasa yakin dengan pendekatannya: melihat skor benchmark publik, menyusun daftar pesaing, lalu memilih yang berada di posisi teratas.
Kepercayaan diri itu sirna ketika alat tersebut benar-benar diarahkan ke repositori kode milik perusahaan. Tidak ada kegagalan dramatis. Namun, agen itu terus menerus menghasilkan kesalahan-kesalahan kecil yang perlahan menyedot waktu tim. Diff yang dihasilkan sering ditolak reviewer. Pada satu insiden, fungsi direname dan merusak tiga file lain yang tidak pernah dibuka oleh agen. Tes yang dijalankan lulus, tetapi repositori dalam keadaan rusak.
Pengalaman memalukan itu memaksa sang engineer untuk menyelidiki mengapa skor benchmark bisa begitu menyesatkan. Setelah beberapa pekan membaca dan mencoba beberapa pendekatan, ia menemukan sejumlah celah dalam metode evaluasi konvensional. Skor tersebut tidak palsu, tetapi hanya mengukur kode orang lain.
Salah satu celah adalah kemungkinan agen telah melihat jawaban saat pelatihan. Soal-soal di benchmark publik sudah tua, sehingga model kemungkinan besar dilatih menggunakan perbaikan asli yang dipakai untuk penilaian. Akibatnya, skor sebagian mengukur ingatan, bukan kemampuan memecahkan masalah yang sesungguhnya.
Celah lainnya berkaitan erat dengan ketidakcocokan dengan pekerjaan riil. Benchmark menyediakan repo bersih, satu isu jelas, dan satu perintah tes. Di dunia nyata, engineer memberi agen editor setengah terbuka, cabang kode berantakan, utas Slack, dan komentar reviewer. Kebiasaan kode internal (pustaka, pembungkus, gaya tes, impor terlarang) tidak dikenal benchmark. Standar kelulusan pun jauh lebih rendah: cukup membuat tes rusak menjadi lulus, tanpa memedulikan formatting atau ukuran diff.
Bagi tim teknologi di Indonesia, kisah ini menjadi peringatan saat banyak perusahaan lokal mulai mengadopsi alat bantu coding AI seperti GitHub Copilot, Cursor, hingga solusi dari vendor dalam negeri. Budaya pengembangan di Tanah Air seringkali memiliki keunikan: cabang fitur yang menumpuk, dokumentasi minim, dan konvensi penulisan yang spesifik. Mengandalkan papan peringkat global tanpa uji coba internal berisiko membuang biaya langganan dan menurunkan kecepatan rilis.
Dampaknya dirasakan langsung oleh reviewer kode dan engineer junior. Mereka yang harus membersihkan diff berantakan atau memperbaiki pemanggilan fungsi yang terputus. Di sisi lain, kepercayaan terhadap otomasi bisa terkikik jika alat tersebut kerap menampilkan tes lulus namun sistem rusak. Situasi ini sejalan dengan lanskap startup Indonesia yang mengejar efisiensi, tetapi sering kali mengabaikan evaluasi kustom.
Perbandingan dengan kondisi di Indonesia juga terlihat pada ketersediaan data evaluasi. Sebagian besar tim belum menyadari bahwa riwayat git mereka sendiri, yakni pull request yang sudah digabung, adalah set tes terbaik. Ini gratis dan merepresentasikan intent riil, komentar reviewer, serta diff final yang terbukti aman.
"Saya merekomendasikan alat berdasarkan angka yang ternyata tidak berarti apa-apa bagi situasi kami. Itu cukup memalukan hingga saya akhirnya mencari tahu akarnya," tulis sang engineer dalam catatannya. Ia kemudian menghentikan penggunaan leaderboard sebagai keputusan akhir, melainkan sekadar tes aroma untuk mempersempit pilihan.
Metode evaluasi yang ia bangun memanfaatkan 50 penggabungan PR terakhir. Ia melewati kenaikan versi dan file generasi otomatis, lalu merekam commit awal dan teks isu. Repositori dikembalikan ke titik tersebut, agen diberi isu, dan hasilnya dibandingkan dengan penggabungan asli. Penilaian tidak dilakukan pada kemiripan teks, melainkan apakah diff tersebut akan lulus review yang sama.
Dari eksperimen itu, lahir lima kriteria penilaian. Kelulusan review berdasarkan perilaku, urutan penggunaan alat secara logis, pembaruan semua bagian yang tersentuh, kesesuaian rencana dengan hasil akhir, dan kemampuan menghentikan ide buruk. Kriteria terakhir terbukti paling krusial: agen yang tidak mau revert saat tes gagal cenderung menumpuk kode baru di atas kegagalan dan mengirim regresi.
Ke depan, tim yang bijak akan membangun pipeline evaluasi otomatis menggunakan repositori sendiri, memperbarui set PR setiap minggu, serta memindai diff terhadap rahasia palsu dan pola shell berbahaya. Tren ini menunjukkan bahwa evaluasi kustom bukan lagi kemewahan, melainkan kebutuhan saat agen coding semakin masuk ke alur kerja inti perangkat lunak.