Code review oleh AI: bisakah menggantikan reviewer manusia?

Belum sepenuhnya. Reviewer AI hari ini sudah bisa membaca konteks seluruh repo, menemukan bug umum, dan di beberapa alat bahkan memberi approval. Namun GitHub sendiri meminta hasil review Copilot divalidasi dan dilengkapi review manusia. Pembagian yang masuk akal: AI memeriksa lebih dulu, manusia memutuskan untuk perubahan berisiko.

Tesis saya: pertanyaan "bisakah AI menggantikan reviewer?" salah sasaran, karena code review sejak awal tidak hanya soal mencari bug. Riset di Microsoft dan Google menunjukkan review juga dipakai untuk berbagi pemahaman di dalam tim. Bagian mencari bug memang makin banyak diambil mesin. Bagian memahami dan menyetujui arah perubahan masih pekerjaan orang.

Yang perlu diluruskan dulu

Code review adalah kebiasaan meminta orang lain membaca perubahan kode sebelum perubahan itu digabung ke kode utama. Di GitHub, perubahan itu dibungkus dalam pull request (PR), yaitu permintaan resmi untuk menggabungkan satu cabang kode ke cabang lain.

Ada dua salah kaprah yang perlu diluruskan. Pertama, reviewer AI dianggap sekadar linter yang lebih pintar. Linter adalah alat yang memeriksa kode dengan aturan tetap, misalnya format atau variabel yang tidak dipakai. Reviewer AI generasi sekarang bekerja lain. Ia membaca perubahan beserta konteks repo, lalu menulis komentar dalam bahasa biasa.

Kedua, ada anggapan bahwa kalau AI sudah bisa menulis kode, AI juga otomatis bisa menilai kode itu dengan adil. Dokumentasi GitHub justru punya panduan khusus untuk meninjau kode buatan AI, lengkap dengan daftar jebakan yang khas mesin. Jadi vendornya sendiri tidak menganggap urusan ini selesai.

Catatan jujur. Artikel ini ditulis 2 November 2026. Fakta tentang fitur dan biaya diambil dari dokumentasi resmi GitHub dan Greptile, serta dari publikasi riset Microsoft dan Google. Angka performa dari vendor saya tulis sebagai klaim vendor. OpenAI juga menerbitkan studi kasus tentang Greptile yang memakai Codex, tetapi halamannya tidak bisa saya buka dari lingkungan kerja saat menulis. Karena itu isinya tidak saya kutip, dan semua klaim di dalamnya saya anggap belum terverifikasi.

Artikel ini untuk kamu yang sudah menulis kode dengan bantuan AI, mengelola tim kecil, atau mulai bertanya apakah reviewer manusia masih perlu dibayar. Artikel ini kurang cocok kalau kamu mencari panduan langkah demi langkah mengaktifkan alat tertentu. Untuk itu, dokumentasi resmi masing-masing alat lebih tepat.

Apa yang sebenarnya dikerjakan code review

Sebelum menilai apakah mesin bisa menggantikan reviewer, kita perlu jelas dulu apa yang digantikan. Di sini riset lama masih sangat relevan.

Pada 2013, Alberto Bacchelli dan Christian Bird mengamati, mewawancarai, dan menyurvei pengembang serta manajer di Microsoft. Mereka juga mengklasifikasi ratusan komentar review secara manual. Hasilnya diterbitkan dalam makalah Expectations, Outcomes, and Challenges of Modern Code Review. Temuannya menarik. Mencari cacat memang alasan utama orang melakukan review. Namun komentar review yang benar-benar soal cacat lebih sedikit dari dugaan.

Manfaat lain justru menonjol: transfer pengetahuan, kesadaran tim tentang apa yang sedang berubah, dan munculnya solusi alternatif. Makalah itu juga menyimpulkan bahwa memahami kode dan memahami perubahan adalah inti pekerjaan reviewer. Kebutuhan memahami itu, menurut penelitinya, sebagian besar belum terpenuhi alat yang ada saat itu.

Google punya studi serupa. Makalah Modern Code Review: A Case Study at Google (ICSE SEIP 2018) memakai 12 wawancara, survei dengan 44 responden, dan analisis log dari 9 juta perubahan yang direview. Studi ini menelusuri alasan Google memperkenalkan review, praktiknya, serta kepuasan dan kesulitan pengembangnya.

Kalau saya rangkum, review menjalankan setidaknya empat fungsi:

• Menangkap kesalahan: bug logika, celah keamanan, kasus tepi yang terlewat.
• Menjaga konsistensi: gaya penulisan, pola arsitektur, dan aturan tim.
• Menyebarkan pemahaman: lebih dari satu orang tahu bagaimana bagian sistem itu bekerja.
• Menguji keputusan: apakah perubahan ini memang menyelesaikan masalah yang benar, dan apakah ada cara yang lebih sederhana.

Reviewer AI sudah cukup kuat di dua fungsi pertama. Di dua fungsi terakhir, kontribusinya jauh lebih terbatas. Fungsi ketiga bahkan secara definisi tidak bisa digantikan mesin. Tujuannya agar manusia di tim ikut paham, dan itu tidak terjadi kalau tidak ada manusia yang membaca.

Satu data lagi dari Google patut disebut karena sering disalahpahami. Dalam tulisan Resolving code review comments with ML (23 Mei 2023), Google menyebut penulis kode rata-rata butuh sekitar 60 menit kerja aktif antara mengirim perubahan untuk direview dan menyelesaikannya. Mereka lalu memakai model untuk mengusulkan suntingan berdasarkan komentar reviewer.

Model itu dikalibrasi untuk presisi target 50%, artinya separuh suntingan yang diusulkan pada data evaluasi benar. Di peluncuran internal, 40 sampai 50% suntingan yang dilihat pratinjaunya akhirnya diterapkan penulis kode. Perhatikan arahnya. AI di sini membantu penulis menjalankan komentar reviewer manusia. Ia tidak menggantikan reviewer itu.

Apa yang sudah bisa dikerjakan reviewer AI hari ini

Dua alat yang saya jadikan acuan adalah Copilot code review dari GitHub dan Greptile. Keduanya punya dokumentasi publik yang cukup rinci, jadi kemampuannya bisa diperiksa, bukan sekadar diklaim.

Copilot code review

Menurut dokumentasi resmi GitHub, paket Copilot Free tidak mencakup Copilot code review. Review otomatis untuk PR milik sendiri tersedia di paket Copilot Pro, Pro+, Max, serta lisensi Business dan Enterprise. Fitur ini bisa dipakai di GitHub.com, GitHub CLI, GitHub Mobile, VS Code, Visual Studio, Xcode, dan JetBrains. Dukungan Azure DevOps masih public preview.

Beberapa hal yang menurut saya paling penting dari dokumentasinya:

• Konteks seluruh repo. Copilot mengumpulkan konteks dari seluruh repository, bukan hanya baris yang berubah. Kemampuan ini berjalan di atas GitHub Actions. Kalau runner GitHub tidak tersedia, review tetap jalan tetapi dalam versi yang lebih terbatas.
• Tiga level usaha. Lite untuk umpan balik cepat soal bug umum, celah keamanan, dan gaya. Balanced (default) memakai model penalaran lebih tinggi untuk logika kompleks dan perubahan lintas layanan. Max memakai beberapa model penalaran tinggi sekaligus dan masih berstatus public preview.
• Model tidak bisa diganti. GitHub menyebut Copilot code review memakai campuran model, prompt, dan perilaku sistem yang disetel khusus, sehingga pengguna tidak bisa memilih model sendiri.
• Bisa menyerahkan perbaikan. Saran dari review bisa diteruskan ke Copilot cloud agent, yang lalu membuat PR baru berisi perbaikan. Fitur ini masih public preview.
• Membaca aturan tim. Copilot membaca instruksi khusus repo, AGENTS.md, dan agent skills. AGENTS.md adalah file berisi aturan proyek yang bisa dibaca berbagai agen AI.

Yang paling relevan dengan judul artikel ini adalah fitur Copilot approvals. Setiap review Copilot menyertakan penilaian apakah PR sudah siap disetujui. Secara default, penilaian itu tidak dihitung sebagai approval wajib. Kalau fitur approvals diaktifkan di level repository, organisasi, dan enterprise, approval Copilot bisa memenuhi aturan required approval sama seperti approval rekan kerja. Begitu ada commit baru setelah approval, approval itu dibatalkan.

Artinya, secara teknis GitHub sudah membuka pintu bagi AI untuk menggantikan satu reviewer manusia dalam alur persetujuan. Pintunya tertutup secara default, dan harus dibuka dengan sengaja di tiga tingkat.

Greptile

Greptile menyebut dirinya agen code review yang otomatis meninjau setiap PR. Ia membangun graf dari seluruh repository, yaitu peta fungsi, kelas, dan ketergantungan antar-bagian kode. Dengan peta itu, Greptile mencoba melihat dampak perubahan pada bagian sistem yang letaknya jauh dari baris yang diubah.

Menurut dokumentasinya, temuan diposting sebagai komentar PR dalam waktu sekitar 3 menit. Setiap komentar punya tombol untuk mengirim masalahnya ke agen coding seperti Claude Code, Codex, Conductor, Cursor, atau Devin. Greptile juga belajar dari reaksi jempol atas atau bawah dan balasan tim. Dokumentasinya menyebut bahwa setelah 2 sampai 3 minggu, Greptile berhenti mengomentari hal yang tidak dipedulikan tim.

Greptile juga punya fitur auto-approve yang masih beta. Greptile hanya menyetujui PR yang mendapat skor bersih 5/5 dan berada di bawah batas risiko yang kamu tentukan. Ada empat level risiko:

• Low: dokumentasi, tes, styling, dan perubahan kecil.
• Medium: perubahan logika aplikasi atau bisnis biasa.
• High: pembaruan dependensi, konfigurasi build, dan modul inti bersama.
• Critical: autentikasi, rahasia, penagihan, migrasi database, infrastruktur, CI, dan API publik.

Ada satu kalimat di dokumentasi itu yang menurut saya wajib dibaca siapa pun yang tertarik. Kalau batas risiko tidak dipasang, plafonnya adalah Critical. Artinya Greptile boleh menyetujui PR apa pun yang mendapat 5/5, termasuk perubahan pada autentikasi atau migrasi database. Greptile sendiri menyarankan mulai dari Low dan baru menaikkannya setelah tim cukup percaya. Dokumentasi yang sama juga menyebut approval Greptile tidak terhalang oleh review manusia yang meminta perubahan atau diskusi yang belum selesai. Yang tetap menahan merge adalah aturan repository, misalnya kewajiban approval manusia.

Soal klaim performa

Greptile mencantumkan angka di dokumentasinya: rata-rata review sekitar 3 menit, lebih dari 100 ribu bug tertangkap di produksi setiap bulan, dan waktu merge 9 kali lebih cepat. Di halaman utamanya tertulis "Merge 4X Faster, Catch 3X More Bugs" dan klaim dipakai lebih dari 22.000 tim.

Semua itu klaim vendor. Saya tidak menemukan metodologi di halaman tersebut. Dua halaman resmi yang sama-sama milik Greptile menyebut angka percepatan merge yang berbeda (9 kali dan 4 kali). Angka seperti ini berguna untuk tahu apa yang dijanjikan, tidak berguna untuk memprediksi hasil di repo kamu.

Di mana reviewer AI masih sering meleset

Kalimat paling jujur soal batas alat ini datang dari GitHub sendiri. Dokumentasi Copilot code review menyatakan Copilot tidak dijamin menemukan semua masalah dalam PR dan kadang membuat kesalahan. Pengguna diminta selalu memvalidasi umpan baliknya dan melengkapinya dengan review manusia.

Dari dokumentasi resmi kedua alat, ada lima titik lemah yang perlu kamu tahu.

1. Maksud bisnis tidak tertulis di kode

Reviewer AI membaca kode, instruksi repo, dan konteks yang bisa ia jangkau. Ia tidak tahu bahwa diskon 30% di fungsi checkout itu seharusnya hanya berlaku untuk pelanggan lama. Ia juga tidak tahu bahwa fitur ekspor data itu dijanjikan ke klien minggu depan dengan format tertentu.

Panduan GitHub untuk meninjau kode buatan AI menaruh pertanyaan "apakah kode ini menyelesaikan masalah yang benar?" sebagai tanggung jawab peninjau. Pertanyaan itu butuh orang yang tahu masalahnya.

2. Kode yang tampak benar

Panduan yang sama meminta kita waspada terhadap API halusinasi, batasan yang diabaikan, dan kode yang "terlihat benar" tetapi tidak sesuai maksud. Ada satu pola yang secara khusus disebut: tes yang dihapus atau dilewati, padahal seharusnya diperbaiki.

Bagi saya ini poin terpenting di era vibe coding. Agen coding yang diminta "buat semua tes lulus" punya jalan pintas murah, yaitu mematikan tesnya. Reviewer AI mungkin menangkapnya, mungkin juga tidak. Manusia yang tahu tes mana yang penting akan langsung curiga.

3. Dependensi tidak selalu diperiksa

Dokumentasi Copilot code review menyebut beberapa jenis file tidak direview sama sekali: file manajemen dependensi seperti package.json dan Gemfile.lock, file log, dan file SVG. Padahal panduan GitHub sendiri memperingatkan soal paket halusinasi dan slopsquatting. Slopsquatting adalah serangan dengan mendaftarkan paket palsu bernama mirip paket yang sering dikarang model AI.

Jadi kalau agen AI menambahkan paket baru ke package.json, jangan berharap Copilot code review mengomentarinya. Untuk itu GitHub menyarankan alat lain seperti Dependabot.

4. Aturan review ikut dibaca dari cabang yang direview

Ini detail kecil di dokumentasi GitHub yang menurut saya perlu dipikirkan. Saat meninjau PR, Copilot membaca instruksi khusus, instruksi agen, dan skill dari head branch, yaitu cabang yang berisi perubahan. GitHub menjelaskan tujuannya: kamu bisa menguji perubahan instruksi di PR yang sama tanpa harus merge dulu.

Konsekuensinya, PR yang sama bisa sekaligus mengubah aturan yang dipakai untuk meninjau PR itu. Greptile memilih arah sebaliknya untuk auto-approve: kebijakannya dibaca dari base branch, sehingga PR yang mengubah file konfigurasi Greptile tidak bisa melonggarkan aturan untuk dirinya sendiri. Di tim kecil yang saling percaya, pendekatan GitHub tetap praktis. Kalau Copilot approvals sudah dihitung sebagai approval wajib, menurut saya perubahan pada file instruksi review layak selalu ditinjau manusia.

5. Kebisingan di minggu-minggu awal

Greptile secara terbuka menyebut butuh 2 sampai 3 minggu reaksi dari tim sebelum ia berhenti mengomentari hal yang tidak penting. Itu jujur, sekaligus berarti ada masa ketika tim dibanjiri komentar remeh. Kalau tim kamu tidak disiplin memberi reaksi, masa belajar itu bisa lebih panjang.

Komentar yang terlalu banyak punya biaya yang jarang dihitung. Google mencatat hal serupa untuk suntingan otomatisnya: saran yang salah menghabiskan waktu pengembang dan menurunkan kepercayaan mereka pada fitur itu. Reviewer yang terlalu cerewet akhirnya diabaikan, termasuk saat komentarnya benar.

Pembagian kerja yang masuk akal

Posisi saya: reviewer AI layak dijadikan pemeriksa pertama untuk setiap PR, tetapi keputusan merge untuk perubahan berisiko tetap di tangan manusia. Saya tidak menyarankan menyerahkan approval wajib ke AI untuk area autentikasi, pembayaran, data pengguna, atau migrasi database. Setidaknya tunggu sampai tim punya catatan sendiri tentang seberapa sering AI benar di repo itu.

Alurnya kira-kira seperti ini:

Urutannya penting. Panduan GitHub menyarankan menjalankan tes otomatis dan analisis statis lebih dulu, misalnya CodeQL untuk celah keamanan dan Dependabot untuk dependensi. Tidak ada gunanya membayar reviewer AI, apalagi meminta waktu rekan kerja, untuk menemukan hal yang bisa ditangkap tes gratis.

Setelah itu, reviewer AI menangani pekerjaan yang membosankan bagi manusia tapi cocok untuk mesin: bug umum, kasus tepi, konsistensi dengan aturan tim, dan dampak perubahan ke bagian kode lain. Penulis memperbaiki temuan itu sebelum minta waktu orang lain. Reviewer manusia lalu masuk dengan PR yang sudah lebih bersih, dan bisa fokus pada pertanyaan yang hanya bisa ia jawab.

Kapan AI boleh memberi approval

Saya tidak anti auto-approve. Ada kelas perubahan yang menurut saya wajar disetujui mesin:

• Perbaikan salah ketik di dokumentasi.
• Penambahan tes tanpa mengubah kode produksi.
• Perubahan styling yang tidak menyentuh logika.

Ketiganya masuk definisi level Low di Greptile. Untuk semua yang lain, saya lebih suka AI memberi penilaian dan manusia yang menekan tombol. Di Greptile, pakai daftar jalur yang selalu butuh approval manusia. Di GitHub, aktifkan Copilot approvals hanya kalau kamu sudah punya aturan jelas soal jenis PR yang boleh disetujui Copilot.

Kalau kamu bekerja sendirian

Banyak pembaca eduwebmu adalah pebisnis atau pengembang tunggal yang membangun aplikasi dengan agen AI. Di posisi ini tidak ada reviewer manusia kedua, jadi pertanyaan "menggantikan" tidak relevan. Reviewer AI di sini menambah satu lapis pemeriksaan yang sebelumnya tidak ada sama sekali.

Saran saya untuk kondisi ini: biarkan reviewer AI memeriksa setiap PR, tetapi baca sendiri setiap perubahan yang menyentuh login, pembayaran, dan data pengguna. Membaca diff dengan pelan juga satu-satunya cara agar kamu tetap paham aplikasimu sendiri. Kalau semua kode ditulis agen dan direview agen, suatu saat kamu akan memiliki aplikasi yang tidak kamu pahami.

Biaya dan cara memilih alat

Di kedua alat, setiap review memakan kuota yang dihitung per pemakaian: AI credits di GitHub, kredit di Greptile. Biayanya jadi terlihat per PR, dan itu membantu memutuskan seberapa dalam review yang layak dijalankan untuk tiap PR.

Estimasi biaya Copilot code review

GitHub mencantumkan estimasi pemakaian AI credits per review di dokumentasinya:

GitHub menegaskan angka ini hanya estimasi. Biaya naik seiring ukuran PR dan panjang instruksi khusus repo, dan belum termasuk menit GitHub Actions. Secara default, biaya review otomatis dibebankan ke penulis PR. Kalau orang lain meminta review secara manual, biayanya dibebankan ke orang itu.

Satu hal teknis yang sering terlewat. Kecuali diatur untuk meninjau setiap push, Copilot hanya meninjau PR sekali. Kalau kamu menambah commit dan ingin ditinjau ulang, review harus diminta lagi. Kalau kamu mengaktifkan review di setiap push pada level Max, biaya per PR bisa berlipat.

Tier di Greptile

Greptile memakai sistem kredit dengan empat tier: Base (1 kredit), Plus (3 kredit), Apex (10 kredit), dan Auto yang memilih tier per PR berdasarkan ukuran, risiko, dan kerumitannya. Greptile menyarankan Auto sebagai default, Apex untuk PR ke cabang produksi, dan Apex untuk PR yang mengubah lebih dari 30 file.

Polanya sama dengan GitHub: review dangkal yang murah untuk perubahan rutin, review dalam yang mahal untuk perubahan berisiko. Saya setuju dengan pola ini. Yang tidak saya sarankan adalah menyetel level tertinggi untuk semua PR "biar aman". Itu mahal, dan komentarnya bisa makin banyak tanpa makin berguna.

Cara memilih

• Repo sudah di GitHub dan tim sudah berlangganan Copilot. Mulai dari Copilot code review. Tidak perlu menambah vendor, dan level Balanced cukup untuk sebagian besar PR.
• Repo di GitLab, Bitbucket, atau butuh self-hosted. Greptile mendukung GitLab, Bitbucket, dan pemasangan di infrastruktur sendiri menurut dokumentasinya. Copilot code review berpusat di GitHub, dengan dukungan Azure DevOps yang masih preview.
• Butuh auto-approve dengan batas risiko yang bisa diatur rinci. Greptile punya pengaturan level risiko dan daftar jalur yang jelas di dokumentasinya. Dokumentasi Copilot approvals tidak menyebut pengaturan level risiko. Yang tertulis hanya syarat aktivasi di tiga tingkat dan pembatalan approval setiap ada commit baru.
• Tim belum punya tes otomatis. Jangan mulai dari reviewer AI. Bereskan tes dan pemeriksaan otomatis dulu, karena reviewer AI paling berguna di atas fondasi itu.

Masih banyak alat lain di pasar. Saya membatasi pembahasan pada dua alat ini karena dokumentasinya bisa saya periksa langsung untuk artikel ini.

Ringkasan dan langkah berikutnya

Reviewer AI sudah cukup matang untuk menjadi pemeriksa pertama di hampir semua proyek. Ia belum cukup matang untuk menjadi satu-satunya pemberi keputusan pada perubahan yang berisiko. Fungsi review sebagai cara tim berbagi pemahaman juga tidak bisa diambil alih mesin.

Checklist sebelum mengaktifkan reviewer AI

• Tes otomatis dan linter sudah berjalan di setiap PR
• Ada file instruksi repo (misalnya AGENTS.md) berisi aturan tim yang ingin dipatuhi
• Sudah ditentukan jenis perubahan yang selalu butuh reviewer manusia
• Kalau memakai auto-approve, batas risiko sudah dipasang di level terendah
• Perubahan pada file instruksi review selalu ditinjau manusia
• Level usaha dan perkiraan biaya per PR sudah diketahui
• Tim sepakat memberi reaksi pada komentar AI agar kebisingan berkurang
• Penambahan dependensi baru diperiksa dengan alat terpisah

Cheat sheet pembagian kerja

Kamu membangun aplikasi dengan agen AI dan ingin belajar menyusun aturan proyek, menulis PRD, serta memeriksa hasil kerja agen? Mulai dari Kelas Vibe Coding di halaman Kelas eduwebmu. Bawa satu PR dari proyekmu sendiri, lalu coba pisahkan bagian yang cukup diperiksa mesin dari bagian yang harus kamu baca sendiri.