AI reviewer yang punya banyak tool kedengarannya keren. Tapi kalau tool itu bikin dia muter ke file yang nggak relevan, hasilnya bukan review yang lebih pintar — hasilnya noise yang lebih mahal.

Artikel ini membahas kenapa AI code review butuh workflow berbasis evidence, bukan sekadar agent yang bisa eksplorasi semua file. Pelajaran utamanya: tool yang lebih kuat harus diikat ke konteks pull request, bukti perubahan, dan komentar yang actionable. Buat developer atau tim kecil yang mulai pakai AI reviewer, ini penting supaya AI benar-benar bantu review, bukan cuma menambah daftar komentar yang harus dibersihin manusia.

Kenapa AI code review bisa makin buruk saat tool-nya makin kuat?

GitHub baru menulis cerita menarik tentang Copilot code review: ketika mereka memberi agent tool eksplorasi kode yang lebih powerful, kualitas review sempat memburuk. Bukan karena tool-nya jelek. Masalahnya, agent jadi punya ruang gerak lebih luas untuk mencari konteks, tapi belum tentu konteks itu relevan dengan pull request yang sedang direview.

Ini pelajaran yang menurut gua penting banget buat era AI coding. Banyak orang masih menganggap masalah agent adalah “kurang tool” atau “kurang model pintar”. Padahal di workflow nyata, agent yang terlalu bebas bisa jadi kayak developer baru yang rajin buka semua folder, baca semua file, lalu komentar panjang tanpa bukti kuat.

Code review yang bagus bukan lomba menemukan sebanyak mungkin hal. Review yang bagus membantu tim menjawab pertanyaan sederhana: perubahan ini aman, masuk akal, bisa dirawat, dan sesuai intent nggak?

Apa itu evidence workflow dalam AI code review?

Evidence workflow adalah cara kerja review yang menuntut setiap komentar punya bukti yang jelas dari perubahan kode, konteks repo, test, log, atau aturan tim. Jadi agent nggak cuma bilang “ini mungkin bermasalah”, tapi bisa nunjukin kenapa masalah itu relevan dengan PR tersebut.

Dalam konteks AI reviewer, evidence workflow berarti agent perlu dibatasi dan diarahkan ke hal seperti:

  • diff pull request, bukan seluruh repo tanpa alasan;
  • file yang berubah dan dependency langsungnya;
  • test yang terkait dengan perubahan;
  • aturan repo seperti AGENTS.md, CONTRIBUTING.md, atau guideline internal;
  • riwayat issue/bug yang memang relevan dengan area kode itu;
  • komentar yang bisa ditindaklanjuti, bukan opini generik.

Kalau agent nggak punya constraint ini, dia bisa terlihat sibuk tapi nggak memberi useful work. Ini sama seperti AI coding yang hemat token tapi task success rate turun: metrik yang kelihatan bagus belum tentu memperbaiki outcome.

Tool lebih banyak bukan otomatis useful work lebih tinggi

Gua suka analogi ini: kasih seseorang akses ke semua ruangan kantor belum tentu bikin dia lebih ngerti masalah. Kadang dia cuma makin lama jalan-jalan.

Di AI agent, tool count sering terlihat seperti progress. Bisa search codebase, bisa buka file, bisa jalanin test, bisa baca issue, bisa cek dependency, bisa akses telemetry. Semua itu berguna. Tapi kalau urutannya salah, agent bisa menghabiskan waktu untuk eksplorasi yang nggak nyambung dengan review.

GitHub menulis bahwa perbaikan Copilot code review bukan cuma soal menambah tool, tapi membentuk workflow agent di sekitar evidence pull request. Ini beda tipis tapi krusial. Tool adalah kemampuan. Workflow adalah cara kemampuan itu dipakai agar menghasilkan keputusan yang lebih baik.

Buat tim kecil, versi praktisnya begini: jangan langsung menilai AI reviewer dari banyaknya komentar. Nilai dari berapa komentar yang benar-benar lu terima, berapa yang mempercepat review, dan berapa yang malah bikin reviewer manusia kehilangan fokus.

Masalah paling umum: AI reviewer bikin noise yang terasa produktif

Noise dari AI reviewer bahaya karena bentuknya terlihat seperti kerja. Komentarnya rapi, bahasanya sopan, kadang pakai istilah teknis yang meyakinkan. Tapi setelah dicek, isinya bisa terlalu generik, tidak relevan dengan diff, atau meminta perubahan yang justru bikin kode makin rumit.

Contoh pola noise yang sering muncul:

  • menyarankan abstraction baru untuk duplikasi kecil yang sengaja dibiarkan;
  • meminta error handling tambahan tanpa membaca boundary yang sudah ada;
  • menandai risiko security umum tanpa bukti bahwa path itu bisa dieksploitasi;
  • mengomentari style yang sudah diatur formatter;
  • mengusulkan test baru yang tidak menguji behavior penting.

Kalau komentar seperti ini terlalu banyak, tim bisa mengalami “alert fatigue” versi code review. Lama-lama reviewer manusia mulai mengabaikan AI, termasuk saat AI sebenarnya menemukan masalah valid.

Checklist: cara bikin AI code review lebih berguna

Kalau lu memakai AI reviewer di repo pribadi, startup kecil, atau tim kerja, gua akan mulai dari checklist sederhana ini.

1. Batasi scope review ke perubahan yang relevan

Minta agent mulai dari diff, lalu baru membuka file lain kalau ada alasan jelas. Misalnya function yang dipanggil, schema yang berubah, test yang gagal, atau interface yang ikut terdampak. Jangan biasakan agent membaca seluruh repo untuk PR kecil.

2. Paksa komentar menyertakan bukti

Format komentar bisa dibuat lebih ketat: masalahnya apa, buktinya dari mana, dampaknya apa, dan saran minimalnya apa. Kalau agent tidak bisa menunjuk bukti, komentar itu sebaiknya tidak dikirim.

3. Pisahkan kategori review

Jangan campur komentar blocking, suggestion ringan, style, security, dan performance dalam satu nada yang sama. Komentar “naming bisa lebih jelas” tidak boleh terasa selevel dengan “token bisa bocor ke log”.

4. Ukur accepted comments, bukan jumlah komentar

Metrik sederhana yang lebih sehat: berapa komentar AI yang diterima manusia, berapa yang ditolak karena false positive, dan berapa yang menghasilkan bug fix nyata. Kalau komentar banyak tapi acceptance rendah, agent lu bukan membantu — dia sedang membuat kerja baru.

5. Buat rule repo yang bisa dibaca agent

AI reviewer perlu tahu standar lokal repo. Simpan aturan di file yang jelas: cara struktur folder, naming, test wajib, pattern error handling, batas abstraction, dan area yang sensitif. Tanpa buku manual, agent akan menebak dari pola yang kebetulan dia lihat.

Di mana posisi manusia?

AI code review sebaiknya dipakai sebagai second pass, bukan pengganti ownership manusia. Agent bagus untuk menemukan pola yang terlewat, mengingatkan test, membaca diff dengan sabar, dan mengusulkan edge case. Tapi manusia tetap harus memegang konteks produk, prioritas bisnis, tradeoff, dan standar kualitas yang belum tentu tertulis.

Gua juga nggak melihat ini sebagai alasan untuk takut memakai AI reviewer. Justru sebaliknya. AI reviewer bisa berguna kalau lu memperlakukannya seperti sistem engineering: punya scope, punya metric, punya feedback loop, dan punya guardrail.

Kalau cuma “nyalain AI review lalu berharap kualitas naik”, itu bukan workflow. Itu gambling yang dibungkus dashboard.

Takeaway praktis

  • AI code review butuh evidence, bukan komentar panjang.
  • Tool yang lebih kuat bisa bikin agent lebih buruk kalau workflow-nya bebas tanpa constraint.
  • Review yang berguna harus dekat dengan diff, test, guideline repo, dan risiko nyata.
  • Ukur useful work: accepted comments, bug yang ditemukan, dan waktu review yang benar-benar turun.
  • Manusia tetap owner keputusan merge. AI hanya membantu memperluas perhatian.

FAQ singkat

Apakah AI code review aman dipakai?

Aman atau tidak tergantung akses, data repo, dan workflow. Untuk repo sensitif, cek dulu kebijakan data, permission, log, dan apakah agent bisa mengakses secret atau private dependency.

Apakah AI reviewer bisa menggantikan reviewer manusia?

Menurut gua belum. AI reviewer bisa jadi filter tambahan, tapi keputusan merge tetap butuh manusia yang paham konteks produk dan risiko.

Apa metrik paling sederhana untuk mengevaluasi AI reviewer?

Mulai dari acceptance rate komentar, jumlah false positive, waktu review, dan apakah bug penting benar-benar lebih cepat ketemu.

Kalau agent sering kasih komentar generik, harus diapain?

Perketat instruksi: komentar wajib menyebut file/baris, bukti, dampak, dan saran minimal. Kalau tidak ada bukti, agent sebaiknya diam.

Penutup

Pelajaran besarnya sederhana: AI agent yang powerful tetap butuh workflow yang waras. Di code review, yang lu cari bukan agent paling cerewet, tapi reviewer tambahan yang bisa nunjukin bukti, paham scope, dan mengurangi beban manusia.

Kalau lu pakai AI reviewer minggu ini, coba audit satu hal: dari semua komentar yang dia kasih, berapa yang benar-benar bikin PR lebih aman untuk di-merge? Jawaban itu lebih jujur daripada sekadar “AI-nya sudah aktif”.

Referensi / Bacaan Lanjut

Tags:
#AI#Software Development#Code Review#Developer Tools