# AI Code Review sebagai Merge Gate CI: Apa yang Boleh Block

> Menambahkan AI reviewer ke CI cuma butuh satu sore, mengkalibrasinya butuh berbulan-bulan, dan kalibrasi itulah masalah sebenarnya. Ini pembagian antara finding blocking dan advisory, pengukuran shadow mode yang membuat sebuah class berhak memblokir merge, dan aturan yang mencabut hak itu kembali.

URL: https://www.matthewswong.com/id/blog/ai-code-review-merge-gate-ci/

- Author: Matthews Wong (https://www.matthewswong.com/id/about/)
- Published: 2026-09-11
- Updated: 2026-09-11
- Category: AI

> **Key takeaway:** Sebuah AI code review merge gate sebaiknya hanya memblokir finding yang objektif, murah diverifikasi, dan jarang salah: secret di dalam diff, route baru tanpa authorization check, atau migration yang menghapus column yang masih dibaca release yang sedang jalan. Semua yang butuh selera tetap advisory sampai shadow mode mengukurnya.

Reviewer itu dipasang pada hari Kamis. Pertengahan pekan berikutnya ia sudah mengomentari setiap pull request yang terbuka di repository, termasuk satu perubahan teks dua baris. Komentarnya tidak salah, sebenarnya: nama variabel, helper yang seharusnya bisa jadi map, komentar yang sudah tidak cocok dengan baris di bawahnya. Dan di bagian bawah salah satu review itu, jauh melewati titik di mana orang masih membaca, ada catatan bahwa sebuah migration di dalam diff menghapus column yang masih dibaca release yang sedang ter-deploy.

Itulah kegagalan yang layak ditulis: bukan reviewer yang melewatkan sesuatu, tapi yang cukup sering benar untuk dipasang dan cukup berisik untuk di-mute. Memasangnya ke CI butuh satu sore. Memutuskan apa yang boleh dia blokir, dan membuktikan keputusan itu dengan angka sebelum dia memblokir apa pun, itu pekerjaan sesungguhnya, dan itu bagian yang saya salah lakukan lebih dulu. Berikut pembagian yang sekarang saya pakai, pengukuran yang membuat sebuah class berhak memblokir, dan aturan yang mencabut hak itu kembali.

## Gate yang di-mute lebih buruk daripada tidak ada gate

Adopsi dan kepercayaan bergerak ke arah yang berbeda, dan sebuah merge gate harus dirancang untuk jarak itu. Stack Overflow Developer Survey 2025 mencatat 84% responden sedang memakai atau berencana memakai AI tools dalam proses development mereka, naik dari 76% tahun sebelumnya, dan 51% developer profesional memakai AI tools setiap hari. Survei yang sama mencatat lebih banyak developer yang justru tidak mempercayai akurasi AI tools, 46%, dibanding yang mempercayainya, 33%, dan hanya 3% yang sangat mempercayai outputnya. Pemakaian naik; kepercayaan pada akurasi jatuh ke titik terendah.

Itulah alasan sebuah gate butuh bukti, bukan antusiasme. Tim yang meragukan akurasi sebuah tool tidak akan berdebat dengannya secara terbuka; mereka cuma akan hafal di mana tombol collapse-nya. Minggu pertama orang membaca komentarnya, minggu kedua mereka melewatinya dan langsung ke diff, minggu ketiga ada yang bertanya apakah check itu masih jalan atau tidak, dan pertanyaan itu adalah ukuran paling jujur dari gate yang di-mute: tidak ada yang tahu jawabannya. Gate yang di-mute lebih buruk daripada tidak ada gate, karena tim sekarang percaya ada sesuatu yang memeriksa, dan reviewer manusia membaca lebih longgar kalau merasa mesin sudah melihat lebih dulu.

## Tiga sifat yang harus dipenuhi sebuah class sebelum boleh block

Sebuah class finding boleh memblokir merge hanya kalau ketiga sifat ini terpenuhi sekaligus. Dua dari tiga berarti komentar advisory, dan itu bukan hadiah hiburan.

Objektif. Ada fakta yang bisa disepakati engineer kedua tanpa perlu tahu siapa penulisnya atau kapan deadline-nya. Sebuah route entah punya authorization check atau tidak punya.

Murah diverifikasi. Penulis bisa membenarkan atau membantahnya dalam waktu sekitar satu menit hanya dari komentarnya, karena komentar itu menyebut file, baris, dan hal yang hilang. Finding yang butuh rapat untuk diselesaikan bukan gate, itu agenda meeting.

Jarang salah, diukur dan bukan diasumsikan. Blocking class yang salah satu kali dari tiga mengajari tim bahwa merah berarti mungkin, dan pelajaran itu tidak berhenti di review bot. Pelajaran itu menular ke test suite.

Tiga class lolos standar itu, dan ketiganya membosankan. Migration yang menghapus atau mengganti nama column yang masih dibaca release yang sedang ter-deploy, bisa diputuskan dengan grep pada tag yang ter-deploy untuk nama column itu, dan cukup mahal di production untuk pantas dapat tanda merah. Route HTTP baru tanpa authorization check, risiko yang ditaruh OWASP Top 10:2021 di peringkat pertama, muncul pada 94% aplikasi yang diuji untuk salah satu bentuk Broken Access Control, dan aturan pencegahannya cuma satu kalimat yang bisa dijalankan mesin: kecuali untuk resource publik, tolak secara default. Dan credential aktif di baris yang ditambahkan, yang sebenarnya hampir bukan finding AI sama sekali.

## Semua yang butuh selera otomatis jadi advisory

Separuh aturan yang lain lebih mudah. Penamaan, tata letak file, apakah sebuah function bisa lebih sederhana, apakah sebuah abstraction datang terlalu cepat: inilah finding yang paling lancar diproduksi AI reviewer dan paling tidak punya dasar untuk dipaksakan. Reviewer manusia menyelesaikan ini dengan kosakata, bukan dengan tooling. Panduan engineering practices Google menyuruh reviewer memberi awalan Nit untuk komentar kecil, artinya secara teknis sebaiknya dikerjakan tetapi dampaknya tidak besar, memakai Optional atau Consider untuk ide yang tidak wajib, dan FYI untuk hal yang memang tidak diharapkan dikerjakan pada perubahan ini. Label itu menahan penulis dari membaca setiap komentar sebagai keharusan. AI reviewer yang dirilis tanpa kosakata itu adalah reviewer yang setiap ucapannya terbaca sebagai perintah.

| Class finding | Apa yang memutuskan | Gate |
| --- | --- | --- |
| Credential aktif di baris yang ditambahkan | Pattern match pada rentang diff, tanpa model | Block |
| Route baru tanpa authorization check | Diff route dicek silang dengan daftar guard | Block |
| Migration menghapus column yang masih dibaca | Grep tag yang ter-deploy untuk nama column | Block |
| Cabang logika baru tanpa test yang menutupinya | Delta coverage pada baris yang berubah, lalu penilaian | Advisory |
| Penamaan, struktur, bisa lebih sederhana | Tidak ada. Ini preferensi dengan argumen yang bagus | Never |

Baris terakhir itulah yang membuat saya rugi. Saran penyederhanaan adalah output dengan volume tertinggi dari reviewer, sering kali masuk akal, dan membiarkannya memblokir selama satu sprint saja sudah cukup mengajari semua orang untuk mengabaikan bot itu selamanya. Itu bentuk kesalahannya: sebuah gate di-mute oleh class yang paling terdengar bisa dibela, bukan oleh class yang paling jelas salah.

*Perhatikan band paling bawah, bukan yang paling atas. Saran penyederhanaan terlihat seperti class paling membantu di daftar itu, dan justru class itulah yang mematikan gate begitu ia diizinkan memblokir merge.*

## Pasang blocking sebagai required check tersendiri

Pembagian itu harus hidup di pipeline, bukan di prompt. Satu job yang mengomentari segalanya lalu gagal pada sebagiannya menaruh perilaku gate di dalam output sebuah model, tempat yang tidak bisa Anda ubah tanpa redeploy dan tidak bisa diaudit sama sekali. Dua job, satu required dan satu tidak, memindahkan kebijakan itu ke YAML, tempat ia bisa direview, di-diff, dan di-revert seperti perubahan lain.

Job blocking menjalankan check deterministik lebih dulu, lalu reviewer yang dibatasi pada class yang sudah layak, dengan setiap finding model ditahan di belakang verifier: reviewer menyebut route, column, atau file-nya, dan sesuatu yang bukan model harus menemukannya di sana. Secret adalah kasus paling jelas untuk sama sekali tidak melibatkan model, karena gitleaks memindai rentang git log secara langsung, keluar dengan exit code 1 saat menemukan sesuatu, dan menyensor secret dari outputnya sendiri. Hanya job blocking yang masuk ke aturan branch protection; job advisory memakai continue-on-error, jadi keputusannya tercatat dan tidak pernah dipaksakan.

> Kegagalan yang berbahaya pada sebuah required check bukan merah palsu, tapi hijau palsu. Referensi status checks GitHub menyatakan bahwa job yang skipped melaporkan statusnya sebagai Success, dan tidak akan mencegah pull request di-merge bahkan ketika ia adalah required check. Kondisi apa pun pada job blocking Anda, entah filter paths, guard untuk draft, atau pengecualian fork, diam-diam mengubah gate itu jadi centang hijau. Buka satu pull request yang sengaja memicu kondisi itu dan pastikan merge-nya masih tertahan.

## Shadow mode: ukur dulu pada pull request yang sudah merged

Sebelum reviewer boleh memblokir apa pun, jalankan dia di tempat yang tidak bisa dia rusak: pada pull request yang sudah merged. Diff-nya nyata, hasil akhirnya sudah diketahui, dan tidak ada satu pun ucapannya yang sampai ke penulis kode. Dua ratus pull request yang sudah merged memberi hitungan per class yang layak diperdebatkan, dan biayanya satu laptop dan satu malam, bukan niat baik orang lain.

Lalu hitung. Precision per class adalah angka yang benar-benar menentukan keputusan gate: dari semua finding yang diangkat reviewer di sebuah class, berapa yang akan disetujui manusia. Recall juga penting, dan komentar review manusia pada diff yang sama adalah pengganti paling murah yang ada, karena class yang tidak pernah diangkat reviewer bukan berarti presisi, itu berarti bisu. Tahap penilaian adalah bagian yang paling sering salah, jadi lakukan secara buta.

Buta di sini bukan formalitas. Penilai yang tahu bahwa pull request itu sudah merged dan jalan tanpa insiden akan menandai hampir semuanya sebagai noise, karena tidak adanya insiden terasa seperti bukti bahwa semuanya aman. Buang label class dan hasil akhirnya, acak barisnya, lalu ajukan satu pertanyaan per baris: apakah Anda akan meminta perubahan di sini. Angka yang keluar dari cara itu satu-satunya yang layak dimasukkan ke aturan branch protection.

## Aturan promosi dan demosi, ditulis sebelum Anda membutuhkannya

Simpan aturan ini di repository sebagai kebijakan, bukan diputuskan di bawah tekanan saat sebuah release terblokir dan tiga orang menunggu. Punya saya ada lima baris.

Class baru mulai di shadow mode dan tidak memposting apa pun ke mana pun. Ia tinggal di sana sampai punya minimal 20 finding yang dinilai secara buta, karena angka yang dihitung dari empat sample itu cuma suasana hati.

Ia naik ke advisory pada precision berapa pun, dilabeli nit, dan tetap advisory minimal dua minggu kerja seberapa pun bagusnya angka shadow mode-nya.

Ia hanya boleh dipromosikan menjadi blocking pada precision 90% atau lebih dari penilaian buta, dan hanya kalau ada verifier deterministik yang bisa memastikan finding itu tanpa model.

Setiap blocking class punya owner bernama dan jalur override yang meninggalkan jejak, berupa label di pull request, bukan bisik-bisik ke siapa pun yang punya hak admin.

Ia diturunkan pada hari yang sama begitu ada satu blokir salah yang terkonfirmasi, atau precision di bawah 80% dalam satu bulan. Demosi tidak butuh rapat dan tidak butuh konsensus. Hanya promosi yang butuh.

Asimetri itu memang disengaja. Promosi punya biaya yang datang belakangan dan tersebar tipis ke semua orang, jadi ia harus lambat dan butuh bukti. Demosi mencegah tepat kegagalan yang jadi topik tulisan ini, jadi ia harus langsung dan tidak butuh apa pun. Pada praktiknya aturan demosi inilah yang membuat orang mau mempromosikan apa pun, karena ia mengubah keputusan yang terasa permanen jadi keputusan yang bisa dibatalkan.

> Simpan harness shadow mode setelah gate menyala, dan jalankan lagi setiap bulan pada merge bulan sebelumnya. Versi model berubah tanpa Anda sadari dan codebase Anda berubah di bawah model itu, jadi class yang lolos standar di bulan Maret belum tentu masih lolos di bulan September. Menjalankan ulang juga cara paling murah untuk menyadari sebuah class jadi bisu, bukan jadi bersih.

*Bukti bergerak dari kiri ke kanan dalam hitungan minggu, sementara satu blokir salah yang terkonfirmasi mengembalikan sebuah class ke kiri dalam satu hari, dan asimetri itulah yang membuat orang mau mempromosikan sebuah class sejak awal.*

## Nilai terbesarnya memang ada di check yang membosankan

Setelah semua kalibrasi itu, output reviewer yang benar-benar berguna ternyata tidak keren sama sekali. Ringkasan sebuah diff besar yang membuat manusia bisa memilih empat file mana yang perlu dibaca teliti. Test yang di-copy dan dibiarkan tanpa assertion apa pun. Route yang ditambahkan tanpa guard yang dimiliki semua route tetangganya. Column yang dihapus di pull request yang sama yang masih membacanya tiga file dari situ. Cepat, mekanis, dan setiap satunya bisa dilacak ke satu fakta di dalam diff.

Pendapat soal desain adalah bagian yang saya harap paling bernilai, dan justru bagian yang harus dicabut gigi-giginya. Itu bukan keterbatasan satu tool atau satu model; itu justru yang diprediksi angka kepercayaan tadi. Tim yang tidak percaya akurasi sebuah mesin tetap akan menerima keputusannya soal fakta dan menolak keputusannya soal selera, dan gate yang dibangun melawan arah itu akan di-mute sebagus apa pun modelnya nanti. Jual check yang membosankan ke dalam tim, dan reviewer itu akan bertahan melewati minggu buruk pertamanya.

Satu aturan untuk dibawa pulang: sebuah class boleh memblokir merge hanya kalau ia objektif, murah diverifikasi, dan terukur jarang salah, dan ia tetap advisory sampai ketiganya benar sekaligus. Bangun harness shadow mode sebelum gate-nya, bukan setelah perdebatannya, tulis aturan demosi selagi tidak ada yang terbakar, dan terima kenyataan bahwa karya terbaik AI reviewer yang bagus lebih mirip checklist daripada kritik.

## Sumber & bacaan lanjutan

- Stack Overflow Developer Survey 2025, bagian AI: adopsi, pemakaian harian, dan kepercayaan pada akurasi
- Google engineering practices, How to write code review comments: label Nit, Optional, dan FYI
- GitHub Docs, referensi status checks: required check, dan kenapa job yang skipped melaporkan success
- OWASP Top 10:2021 A01 Broken Access Control: tolak secara default, dan angka insidennya
- gitleaks, secret scanner deterministik: pemindaian rentang log-opts, redaksi, dan exit code

## Source links

- https://survey.stackoverflow.co/2025/ai
- https://google.github.io/eng-practices/review/reviewer/comments.html
- https://docs.github.com/en/pull-requests/reference/status-checks
- https://owasp.org/Top10/A01_2021-Broken_Access_Control/
- https://github.com/gitleaks/gitleaks

## FAQ

### Apakah AI code review sebaiknya boleh memblokir merge?

Hanya untuk sekumpulan finding yang sempit. Sebuah class boleh memblokir kalau ia objektif, murah diverifikasi penulisnya cuma dari komentarnya, dan terukur jarang salah, yang pada praktiknya mencakup hal seperti secret di dalam diff, route baru tanpa authorization check, dan migration yang menghapus column yang masih dibaca release yang sedang jalan. Sisanya, termasuk penamaan dan struktur, sebaiknya cuma berkomentar tanpa membuat check jadi merah.

### Apa itu shadow mode untuk AI code reviewer?

Shadow mode berarti menjalankan reviewer pada pull request yang sudah merged, tanpa memposting apa pun dan tanpa memberi tahu siapa pun. Diff-nya nyata dan hasil akhirnya sudah diketahui, jadi Anda bisa menghitung berapa finding per class yang akan disetujui manusia sebelum gate diizinkan memblokir apa pun. Simpan harness-nya setelah itu dan jalankan lagi tiap bulan, karena versi model dan codebase sama-sama bergerak.

### Bagaimana cara mengukur false positive rate AI reviewer sebelum gate dinyalakan?

Kumpulkan finding dari shadow mode, buang label class dan hasil merge-nya, acak barisnya, lalu minta manusia menjawab satu pertanyaan per baris: apakah Anda akan meminta perubahan di sini. Dari situ Anda mendapat precision per class, dan penilaian buta itu penting karena penilai yang tahu pull request-nya jalan tanpa insiden akan menandai hampir semuanya sebagai noise. Di bawah sekitar dua puluh finding yang dinilai dalam satu class, laporkan sample tidak cukup, bukan sebuah angka.

### Kenapa tim saya mulai mengabaikan bot AI code review?

Biasanya karena bot itu diizinkan memblokir finding yang butuh selera. Saran penyederhanaan dan penamaan adalah output dengan volume tertinggi dari sebagian besar AI reviewer sekaligus yang paling tidak bisa dipaksakan, jadi memblokir berdasarkan itu mengajari semua orang bahwa keputusan bot bisa dinegosiasikan. Begitu komentarnya di-collapse karena kebiasaan, finding yang benar-benar berguna di dalamnya juga tidak terbaca, dan itulah kenapa gate yang di-mute lebih buruk daripada tidak ada gate.

### Bisakah required status check lolos padahal job AI review tidak benar-benar jalan?

Bisa, dan justru inilah kegagalan yang harus Anda uji. Referensi status checks GitHub menyatakan bahwa job yang skipped melaporkan statusnya sebagai Success dan tidak akan mencegah pull request di-merge walaupun ia required check. Kondisi apa pun pada job itu, misalnya filter paths atau pengecualian fork, bisa mengubah gate menjadi centang hijau, jadi buka satu pull request yang sengaja memicu kondisi itu dan pastikan merge-nya masih tertahan.

---

- HTML version: https://www.matthewswong.com/id/blog/ai-code-review-merge-gate-ci/
- English: https://www.matthewswong.com/en/blog/ai-code-review-merge-gate-ci/
- Site index for agents: https://www.matthewswong.com/llms.txt
- Sitemap: https://www.matthewswong.com/sitemap.xml
- API description (OpenAPI): https://www.matthewswong.com/openapi.json