Kenapa Saran AI di Code Review Sering Ditinggalkan

Ada penelitian yang menganalisis 54.791 komentar code review buatan AI di 342 repository Python. Polanya cukup jelas: developer memang membaca dan menindaklanjuti sebagian saran AI, tapi banyak juga yang dibiarkan begitu saja. Alasan yang paling sering muncul ternyata bukan soal developer malas atau anti-AI. Sarannya keliru, tidak relevan, atau tidak cocok dengan konteks project yang sedang dikerjakan.

Klaim bahwa AI bisa mengambil alih code review sudah lama beredar, sebagian besar datang dari materi pemasaran vendor. Data ini memberi gambaran yang lebih membumi. AI sudah hadir di alur kerja developer, tapi posisinya masih sebagai pemberi masukan yang harus disaring.

Dari Autocomplete ke Ruang Review

AI di pengembangan software bergerak cepat beberapa tahun terakhir. Gelombang pertama berbentuk asisten pelengkap kode di dalam editor: developer menulis beberapa baris, AI menebak kelanjutannya. Fase berikutnya lebih ambisius. AI mengerjakan task utuh, membuka pull request (PR), dan ikut berkomentar pada perubahan kode yang diajukan orang lain.

Code review sendiri adalah proses ketika developer lain memeriksa perubahan kode sebelum digabungkan ke basis kode utama. Fungsinya menangkap bug, menjaga konsistensi arsitektur, dan memindahkan pengetahuan antar anggota tim. Di banyak organisasi, review juga jadi leher botol yang paling terasa: kode sudah siap, tapi menunggu berhari-hari untuk dilihat orang.

Di celah itulah AI masuk. Bot yang otomatis menganalisis diff lalu meninggalkan komentar inline sekarang jadi pemandangan biasa, baik di repository open source maupun perusahaan. Persoalannya, hadir di mana-mana tidak otomatis berarti berguna.

Membedah 54.791 Komentar

Datanya diambil dari aktivitas nyata di GitHub, bukan dari lingkungan buatan atau benchmark tertutup. Objeknya 54.791 komentar review yang dihasilkan AI pada 342 repository Python. Keunggulan pendekatan ini tidak bisa ditiru benchmark: kode yang direview adalah kode produksi dengan sejarah, konvensi internal, dan utang teknis yang riil, bukan soal terisolasi yang sudah punya kunci jawaban.

Python dipilih karena posisinya sebagai salah satu bahasa paling banyak dipakai di GitHub, khususnya di proyek-proyek yang bersinggungan dengan machine learning dan data. Konsekuensinya, hasil penelitian ini paling kuat berlaku untuk ekosistem Python. Belum tentu langsung bisa digeneralisasi ke Java di lingkungan enterprise atau Rust di proyek sistem, yang budaya review-nya berbeda.

Yang diukur juga bukan sekadar jumlah komentar yang diproduksi AI, tapi apa yang terjadi setelahnya: komentar itu berujung pada perubahan kode, diabaikan, atau ditolak secara eksplisit oleh developer. Jejak semacam itu ukuran paling jujur soal kegunaan feedback AI.

Lima Agent yang Diamati

Komentar yang dianalisis datang dari beberapa AI coding agent yang paling banyak dipakai saat ini: GitHub Copilot, Cursor, OpenAI Codex, Devin, dan Claude. Cara kerja dan tingkat otonominya berbeda-beda. Copilot tumbuh dari asisten di dalam editor dan kini punya fitur review yang bisa diminta langsung di dalam PR. Cursor membangun editor sendiri dengan AI sebagai lapisan utama. Codex, Devin, dan Claude lebih sering hadir sebagai agent yang mengerjakan task secara mandiri dari awal hingga membuka PR.

Penelitiannya sendiri tidak diposisikan sebagai kompetisi antar tool. Fokusnya pola perilaku developer waktu menanggapi feedback AI secara umum, tanpa menobatkan agent mana yang paling akurat. Membaca hasilnya sebagai peringkat produk akan salah arah.

Kenapa Saran AI Sering Ditinggalkan

Di sini bagian yang paling relevan buat kamu yang sehari-hari mengurus PR. Sebagian besar feedback AI yang tidak ditindaklanjuti bermuara ke satu hal: sarannya tidak nyambung dengan kondisi sebenarnya.

Bentuknya bermacam-macam. Ada saran yang secara teknis salah, mengklaim ada bug yang sebenarnya tidak ada, atau menawarkan perbaikan yang justru merusak logika. Ada yang benar secara umum tapi tidak relevan, misalnya menyarankan pola desain yang bertabrakan dengan konvensi yang sudah dipakai konsisten di project itu. Ada juga yang secara harfiah tidak salah, cuma tidak layak dikerjakan karena nilainya terlalu kecil dibanding biayanya.

Akar masalahnya keterbatasan konteks. AI melihat potongan diff dan file di sekitarnya, sementara kamu membawa informasi yang tidak tertulis di kode: kenapa suatu keputusan diambil dua tahun lalu, bagian mana yang sedang direncanakan untuk dibongkar, batasan performa apa yang berlaku. Tanpa itu, saran yang terdengar rapi bisa tetap tidak berguna.

Pola serupa muncul di penelitian lain. Studi "Human-AI Synergy in Agentic Code Review" yang menganalisis 278.790 percakapan review di 300 project menemukan bahwa saran dari reviewer manusia diadopsi jauh lebih sering dibanding saran AI agent, dengan angka 56,5% berbanding 16,6%. Lebih dari separuh saran AI yang tidak diadopsi ternyata memang keliru atau sudah diselesaikan developer dengan cara lain.

Yang Konkret Lebih Sering Dieksekusi

Sisi lain temuannya lebih menggembirakan. Saran yang konkret, spesifik, dan langsung bisa ditindaklanjuti cenderung lebih sering diselesaikan developer.

Logikanya masuk akal. Komentar yang menunjuk baris tertentu, menjelaskan masalahnya dengan jelas, dan menyodorkan perbaikan yang siap dipakai cuma menyisakan satu keputusan: setuju atau tidak. Komentar yang bersifat umum, misalnya mengimbau agar penanganan error "diperbaiki" tanpa menyebut di mana dan bagaimana, melimpahkan seluruh pekerjaan berpikir kembali ke developer. Biaya menindaklanjutinya jadi nyaris sama dengan mengerjakannya dari nol.

Buat tim yang sedang mengevaluasi tool review otomatis, implikasi praktisnya cukup jelas. Banyaknya komentar bukan indikator kualitas. Bot yang menghasilkan puluhan catatan per PR malah bisa menurunkan kemauan developer untuk membaca, sementara satu komentar tajam yang menunjuk bug nyata jauh lebih bernilai.

Apa Artinya bagi Profesi Developer

Bagian ini perlu dipisahkan dari hasil penelitian, karena sudah masuk wilayah interpretasi.

Kalau feedback AI paling berguna ketika konkret dan paling gampang gagal ketika kehilangan konteks, nilai seorang software engineer bergeser ke wilayah yang belum dikuasai AI: memahami konteks sistem, menimbang trade-off, memutuskan masukan mana yang layak dieksekusi. Kemampuan mengetik kode dengan cepat makin murah. Kemampuan menilai apakah sebuah perubahan aman untuk sistem yang sudah berjalan justru makin mahal.

Jadi keterampilan membaca dan mengevaluasi kode, bukan cuma menulisnya, makin sentral. Developer yang menerima saran AI tanpa memeriksa ulang mengambil risiko yang tidak sepadan, apalagi ketika sebagian saran memang terbukti keliru. Yang menolak semua feedback AI juga kehilangan lapisan pemeriksaan tambahan yang murah dan cepat.

Untuk pembuat tool, arahnya juga terbaca. Perbaikan terbesar kemungkinan datang dari kemampuan menyerap konteks project, bukan dari model yang lebih besar. Konvensi internal, riwayat keputusan, dan standar tim yang membedakan saran berguna dari saran yang cuma terdengar rapi.