Review Kode Otomatis di 2026: Jalankan di Setiap PR Tanpa Membeli Seat

Peninjauan kode otomatis adalah job CI yang mengirim diff Anda ke model bahasa, memposting temuan pada baris yang terpengaruh, dan menggagalkan pemeriksaan status ketika menemukan masalah serius. Cara menjalankannya di setiap pull request tanpa langganan per-seat adalah dengan self-host perangkat open-source: salin alur kerja sekitar lima belas baris ke repositori Anda, tambahkan satu kunci API, dan bayar hanya untuk token yang dikonsumsi setiap peninjauan. Tidak ada jumlah seat yang perlu dibeli, karena memang tidak ada seat. Implementasi referensi yang kami pelihara adalah repositori Orca-Code-Review — publik, berlisensi MIT, dan sejak pembuatannya pada 25 Juni 2026 merupakan kode di balik OrcaCode Review GitHub Action. Resep perutean yang disertakan menetapkan proses peninjauan secara default ke DeepSeek V4 Flash dan penilai verifikasi independen ke GLM-5.3, dan keduanya bebas Anda ubah. Artikel ini membahas apa yang sebenarnya berjalan pada setiap push, apa yang Anda konfigurasikan, berapa biaya tokennya, dan mode kegagalan yang akan Anda temui di minggu kedua.

Versi singkatnya. Setiap push mendapat satu review. Temuan diposting langsung pada baris yang diubah. Temuan P0 dan P1 membuat pemeriksaan gagal dan memblokir merge; jika bersih, pemeriksaan lolos. Anda dapat meninjau ulang kapan saja dengan memberi komentar /orcacode-review. Workflow-nya berada di repositori Anda; logika review-nya berada di action yang dipublikasikan; pilihan modelnya berada di resep routing yang dapat Anda edit di workspace Anda sendiri. Reviewer membaca diff dan file-file repositori, dan tidak pernah mengeksekusi kode PR Anda. Dan catatan jujurnya di awal: ia menangkap bug sungguhan, tetapi tetap melewatkan bug yang membutuhkan manusia yang paham mengapa kode dibuat seperti itu.

• Satu alur kerja + satu rahasia + tagihan token. Tidak ada lisensi per kursi sama sekali.

• Harness ini bersifat sumber terbuka. Salin, fork, audit, dan sematkan ke commit SHA.

• Model adalah pengaturan, bukan vendor. Ubah peninjau dengan mengedit resep perutean, bukan dengan menulis ulang YAML atau mengubah aksi.

• Diff yang terlalu besar tidak memakan biaya. Penjaga ukuran berjalan sebelum model dijalankan.

• Ia membaca kode Anda, tidak pernah menjalankannya. Itulah properti keamanan yang membuat pull_request_target aman untuk digunakan sama sekali.

Bagaimana tinjauan kode otomatis sebenarnya bekerja

Setiap sistem review otomatis adalah tiga bahan yang sama dengan pakaian berbeda: sebuah peristiwa, seorang pelaksana, dan seorang peninjau.

Peristiwa tersebut adalah pemicunya. Alur kerja yang disertakan berjalan pada peristiwa pull request — opened, synchronize (push baru), ready_for_review (draf menjadi siap) — dan pada komentar PR. Karena berjalan pada pull_request_target, definisi alur kerja dibaca dari cabang dasar, itulah sebabnya alur kerja harus ada di cabang dasar sebelum dapat berjalan untuk sebuah PR. Satu ulasan per push; blok concurrency membatalkan proses sebelumnya, sehingga rangkaian push yang cepat tidak mengantrekan lima ulasan untuk kode usang.

tersebutRunneradalah GitHub Actions pada ubuntu-latest. Tugas ini membutuhkan tiga izin: akses baca ke konten, akses tulis ke pull request (untuk memposting komentar sebaris), dan akses tulis ke isu (untuk memposting ringkasan dan membersihkan komentar usang).

tersebutPeninjau adalah model bahasa. Aksi mengambil head PR, menyusun diff dan konteks repositori yang dipilih oleh mesin, lalu mengirimkannya ke model peninjauan. Hasilnya adalah sekumpulan temuan, yang masing-masing diberi label tingkat keparahan dan dikaitkan ke file dan baris. Aksi mempostingnya sebagai komentar PR inline dan menulis satu komentar ringkasan ke dalam area penanda di bagian atas deskripsi PR, yang diganti di tempatnya pada setiap push.

gate adalah sebuah status check. GitHub tidak tahu apa arti “review”; ia hanya tahu apakah review check lolos. Anda membuat gate tersebut nyata dengan menandai check itu sebagai wajib dalam branch protection. Itulah seluruh mekanisme pemblokiran merge — tanpa panggilan API admin, tanpa label, hanya check wajib yang gagal.

Yang tidak terjadi: tidak ada yang mengeksekusi kode PR. Mesin hanya membaca. Satu-satunya invarian itulah yang membuat pemicu pull_request_target yang memiliki hak istimewa aman digunakan dengan kunci API berbayar.

Kerangka kerja sumber terbuka adalah pembedanya.

Semua hal di atas berlaku untuk banyak alat. Yang tidak berlaku bagi kebanyakan alat adalah bahwa keseluruhannya dapat diperiksa dan dihosting sendiri, itulah yang Anda dapatkan dari repositori Orca-Code-Review. Ini adalah repositori GitHub publik berlisensi MIT (JavaScript, dibuat 25 Juni 2026) yang mengemas tinjauan sebagai GitHub Action komposit yang dapat digunakan kembali ditambah penginstal, dan ini adalah kode yang sama aplikasi OrcaCode Review yang dihosting jalankan.

Luangkan sepuluh menit di tree dan kamu bisa menyebutkan setiap bagian yang menyentuh PR-mu:

• action.yml — aksi komposit dengan sekitar lima belas input terdokumentasi. Tidak ada nama model yang di-hardcode di dalamnya.

• workflows/orca-code-review.yml — contoh alur kerja konsumen, sekitar lima belas baris yang Anda salin ke .github/workflows/.

• recipes/ — DSL routing. Di sinilah model sebenarnya dipilih.

• rules/ — rubrik tingkat keparahan (P0–P3), bentuk keluaran yang wajib, dan arahan konvensi yang memasukkan dokumen konvensi proyek itu sendiri ke dalam peninjauan sebagai data referensi yang tidak tepercaya.

• scripts/ — filter presisi (L1 plus juri L2), pengawal diff, gerbang penggabungan, laporan run, dan meter token. Masing-masing adalah kecil dan mudah dibaca, yaitu .mjs file dengan tes.

• skills/setup-orca-code-review — skill yang disematkan installer ke dalam agen pengodean Anda, meliputi instalasi, konfigurasi ulang, pemecahan masalah, dan penghapusan instalasi.

• .claude-plugin/ — yang memungkinkan Claude Code menginstal skill sebagai plugin yang dapat memperbarui diri sendiri.

Memasangnya adalah satu baris perintah yang mengajari AI Anda apa produk tersebut, lalu berhenti:

npx @orcarouter/code-review

CLI mendeteksi agen coding mana yang Anda gunakan — katalognya mencakup 36 platform, dari Claude Code, Cursor, Codex, OpenCode, dan Windsurf hingga GitHub Copilot, Gem​ini CLI, Amazon Q Developer, Cline, RooCode, dan lainnya — menginstal skill tersebut, lalu menyerahkan kendali. Anda kemudian bertanya kepada agen Anda dalam bahasa sederhana: “siapkan OrcaCode Review di repo ini,” “blokir hanya P0,” “kenapa review-nya tidak berjalan?” Skill tersebut menangani siklus hidup: skill menulis alur kerja, memandu Anda melalui kunci API, menetapkan gate, dan hanya menanyakan pertanyaan yang benar-benar milik Anda.

Claude Code dapat menginstal skill sebagai plugin sebagai gantinya, yang membuatnya tetap diperbarui seiring pergerakan repo:

/plugin marketplace tambah Continuum-AI-Corp/orca-code-review

Instal plugin orca-code-review

Tidak ada agen sama sekali? Siklus hidup yang sama hanyalah subperintah biasa — init menulis alur kerja, reconfigure mengubah aturan pemblokiran dan batas diff, doctor mendiagnosis ulasan yang tidak berjalan atau tidak diposting, uninstall menghapusnya (menghilangkan pemeriksaan wajib terlebih dahulu). Skill adalah pintu depan, bukan satu-satunya pintu. Atau rangkai secara manual: salin alur kerja, tambahkan satu secret bernama ORCAROUTER_API_KEY, dan tandai review sebagai pemeriksaan wajib.

Mesin yang mendasarinya adalah Open Code Review milik Ali​baba, dipatok pada versi yang tepat dan dilisensikan di bawah Apache-2.0. OrcaCode memutuskan cara meninjau; OrcaRouter memutuskan model apa yang menjalankannya. Perbandingan antara self-host dan hosted — apa sebenarnya biaya “gratis” saat Anda men-self-host peninjau sumber terbuka — diuraikan dalam artikel kami tentang open code review.

Apa yang berjalan, secara berurutan, pada setiap push

Mengetahui urutannya membantu, karena setiap langkah dapat gagal atau dilewati secara independen:

• Penjaga diff dijalankan lebih dulu, sebelum model sempat berjalan. Jika diff merge-base melebihi 512 KB atau menyentuh lebih dari 300 file, peninjauan dilewati dan sebuah pemberitahuan diposting. Defaultnya adalah on-oversized-diff: fail, sehingga diff yang diberi padding hingga melewati batas tidak dapat melewati gerbang wajib tanpa ditinjau. Ini juga merupakan kontrol biaya: PR yang terlalu besar menghabiskan nol token.

• Mesin memeriksa diff.Satu kali proses, konkurensi per file secara default 24, dengan batas atas waktu wall-clock 20 menit per proses.

• Filter presisi melakukan pasca-pemrosesan terhadap temuan mentah. L1, filter deterministik, memverifikasi cuplikan kode yang sudah ada yang diklaim oleh setiap temuan terhadap commit yang ditinjau dan menempatkan kembali atau membuang ketidakcocokan. L2, penilai LLM, mengelompokkan temuan berdasarkan akar penyebab dan membuang kelompok dengan keyakinan rendah. Kedua lapisan bersifat soft-fail: kesalahan akan mempertahankan temuan tahap sebelumnya dan tidak pernah membatalkan peninjauan.

• Gate berlaku. Temuan P0 dan P1 menyebabkan pemeriksaan gagal; ringkasan PR menghitung setiap temuan, termasuk yang dibisukan dari diff.

• Meter mencetak biayanya. Input meter mencatat akuntansi token per panggilan — prompt, completion, token cache, dan model yang dipilih router — serta mencetak tabel total di log pekerjaan.

• Laporan run opsional mengirim jumlah tingkat keparahan dan metadata gerbang ke bidang kontrol OrcaRouter untuk dasbor analitik. Laporan ini tidak membawa kode, diff, maupun teks temuan.

Apa yang sebenarnya Anda konfigurasi

Ada tiga permukaan, dan mereka memiliki radius ledakan yang sangat berbeda.

1. File workflow. Workflow pengguna memang sengaja dibuat ramping. Input yang perlu diubah ada di dalam action: block-on (severitas mana yang membuat pemeriksaan gagal — bawaan P0,P1), fix-first (severitas mana yang menghentikan review menyeluruh lebih awal), auto-review-authors (allowlist untuk siapa yang di-review otomatis), max-diff-kb dan max-diff-files dan on-oversized-diff (penjaga ukuran), timeout-minutes, concurrency, meter, dan report. Semuanya memiliki bawaan yang terdokumentasi, jadi workflow baru cukup lima baris YAML ditambah sebuah secret.

2. Dasbor. Dengan settings: true (default), setiap run mengambil pengaturan per-repositori dari OrcaRouter → Apps → OrcaCode Review: model, mode review, kebijakan merge, tingkat keparahan laporan, mode senyap, review menyeluruh, rubrik kustom, dan pagar pengaman. Setel settings: "false" dan file alur kerja bersifat otoritatif — tidak ada nilai dasbor yang dapat menggantinya. Jika Anda tidak pernah membuka konsol, Anda tidak kehilangan apa pun dari perangkat ini; Anda cukup mengonfigurasi di YAML.

3. Resep routing — yang sering dilewatkan orang. Aksi tidak pernah menyebut model. Sebaliknya, ia menyuntikkan fakta mentah sebagai header permintaan — tingkat di mana run dicatat, apakah pass sebelumnya menemukan P0/P1, dan penanda lensa saat permintaan adalah penilai L2 — dan resep DSL router ruang kerja memetakan header-header tersebut ke model konkret. Secara default, resep yang disertakan menetapkan review ke DeepSeek V4 Flash dan penilai ke GLM-5.3, dengan sengaja merutekan keduanya ke model yang terpisah. Mengubah model yang meninjau kode Anda adalah pengeditan pada resep tersebut di ruang kerja Anda sendiri: tanpa kenaikan versi aksi, tanpa penulisan ulang YAML, tanpa redeploy.

Kontrak tingkat keparahan adalah dua pengaturan independen, bukan satu. Kebijakan penggabungan menentukan apa yang memblokir penggabungan; pelaporan tingkat keparahan menentukan apa yang diposting di diff. Default bawaan adalah P0/P1 memblokir, P2/P3 lulus. Tingkat keparahan yang memblokir selalu diposting, apa pun yang dikatakan pengaturan laporan — pemeriksaan yang gagal tanpa penjelasan apa pun di diff lebih buruk daripada yang berisik. P0 berarti celah keamanan yang dapat dieksploitasi, kehilangan data, crash pada jalur normal, atau build yang rusak; P1 berarti bug yang nyata tetapi terbatas; P2 berarti cacat sejati yang hanya muncul pada kondisi awal yang abnormal; P3 adalah gaya. Ketika ragu antara dua tingkat, rubriknya mengatakan pilih yang lebih rendah.

Berapa biayanya

Per token, bukan per kursi. Anda memilih model di OrcaRouter, penagihan dihitung per token yang dikonsumsi, dan meter membuat angka per proses terlihat, bukan misterius. Mekanisme GitHub, tinjauan kode terukur Copilot sejak 1 Juni 2026, dan bagaimana peninjau pihak ketiga masuk ke alur kerja tersebut dibahas dalam panduan tinjauan kode GitHub kami. Perbandingan biaya bidang demi bidang secara lengkap — produk per kursi vs produk per token, dengan contoh perhitungan — ada dalam perbandingan alat tinjauan kode AI kami, dan pertanyaan tentang berapa token yang dihabiskan untuk satu kali proses tinjauan ketika peninjau benar-benar menjelajahi repositori (perbedaan bot vs agen) dibahas dalam artikel agen tinjauan kode kami. Poin yang ditambahkan artikel ini adalah bentuk tagihannya: ia berskala dengan kode yang Anda tinjau, bukan jumlah orang yang meninjaunya.

Dua kontrol pengeluaran penting di hari pertama. Pada repositori publik, pull_request_target melewati gerbang persetujuan fork GitHub, dan kunci review dikenai biaya dari wallet — orang asing dapat membuka PR dan memicu review berbayar. Tetapkan anggaran wallet dengan peringatan pada kunci tersebut, dan atur auto-review-authors menjadi sesuatu seperti OWNER,MEMBER,COLLABORATOR,CONTRIBUTOR sehingga kontributor tidak dikenal tidak akan direview otomatis. Dan penjaga diff, sebagaimana dicatat, berarti PR yang terlalu besar tidak memakan biaya sama sekali.

Apa yang rusak

Tinjauan otomatis adalah CI. Ia gagal seperti CI, dan mode kegagalannya sebagian besar bukan salah model:

• Alur kerja tidak pernah berjalan. Untuk pull_request_target, alur kerja dibaca dari cabang dasar — alur kerja yang hanya ditambahkan di cabang PR tidak akan berjalan sampai digabungkan. Periksa juga apakah aplikasi diaktifkan, auto_review aktif, PR bukan draft (draft dilewati dalam mode ready_for_review), dan Actions diaktifkan di repositori (repositori fork secara bawaan memiliki Actions dinonaktifkan).

• /orcacode-review tidak melakukan apa-apa. Pemicu komentar mengharuskan komentar dimulai dengan salah satu dari empat ejaan — /orcacode-review, /orcacode review, @orcacode-review, @orcacode review — dan pemberi komentar haruslah OWNER, MEMBER, atau COLLABORATOR. Spasi di awal akan membuat format tidak cocok. Perintah dari kontributor luar diabaikan secara diam-diam, dengan sengaja: perintah tersebut menjalankan alur kerja istimewa yang memegang kunci berbayar.

• Kesalahan autentikasi. Rahasia tersebut salah nama atau hilang, kunci dicabut atau di luar anggaran, atau alur kerja dialihkan ke pull_request (yang tidak dapat membaca rahasia dari fork).

• Pemeriksaan berwarna merah dengan pemberitahuan “diff terlalu besar”. Itu adalah pengaman ukuran, bekerja sesuai konfigurasi. Pisahkan PR, atau naikkan batasnya, atau atur on-oversized-diff: pass — dan pahami bahwa dengan pemeriksaan wajib, pass berarti PR yang cukup besar langsung melewati gerbang tanpa direview.

• Review berjalan tetapi tidak ada komentar yang muncul. Tiga penyebab, semuanya tidak berbahaya atau dikonfigurasi: proses yang bersih memposting ringkasan daripada komentar inline; mode senyap membisukan P2 pada saat posting (gate dan laporan tetap menghitungnya); atau filter presisi membuang temuan — L1 membuang temuan yang cuplikannya tidak cocok dengan commit, L2 membuang klaster dengan kepercayaan rendah. Hitungan tingkat keparahan pada log pekerjaan memberi tahu Anda yang mana.

Postur keamanan ini perlu dinyatakan secara gamblang karena itulah yang membuat seluruh desain ini aman. Mesin hanya membaca file diff dan repositori; mesin tidak pernah mengeksekusi kode PR. Peninjau tidak memiliki kewenangan merge — temuan dapat memblokir penggabungan atau menambahkan komentar, tetapi tidak ada jalur kode yang memungkinkan keluaran model menyetujui atau mengubah repositori. Temuan yang tidak diberi tag gagal dengan aman, diperlakukan sebagai pemblokir, bukan sekadar imbauan. Dan laporan proses (run report) tidak memuat kode atau teks temuan. Pengaturan dua lapis yang menangkap apa yang terlewat oleh tinjauan satu langkah (single-pass review) merupakan pokok bahasan dalam artikel keamanan AI code review kami; model ancaman di atas didokumentasikan dalam SECURITY.md repositori.

Ketika peninjauan otomatis bukan alat yang tepat.

Ini salah lebih sering daripada yang diakui vendor perkakas. Lewati hal ini ketika:

• Masalahnya adalah konteks, bukan volume. Jika peninjauan kode lambat karena peninjau harus memahami mengapa kode ditulis dengan cara ini, LLM yang membaca diff hanya memberi sedikit manfaat. Ia tidak memiliki ingatan tentang utas bulan lalu dan tidak memiliki pemahaman tentang sejarah sistem.

• Diff ini sebagian besar adalah kode hasil generate atau kode vendor. Output yang diformat otomatis, file hasil scaffold, snapshot dependensi. Meninjaunya menghabiskan token dan menghasilkan noise, dan justru di sinilah arahan konvensi paling tidak membantu — kode tersebut bukan gaya proyek, dan itu bukan karena pilihan.

• Tim sudah melakukan pair-review untuk semua hal. Review otomatis adalah pengungkit volume. Jika setiap perubahan sudah ditinjau oleh manusia yang hadir di ruangan, mesin menambahkan opini kedua yang biasanya kurang informasi dibanding opini pertama.

• Tidak ada yang membaca temuan-temuan tersebut. Ulasan yang tidak ditindaklanjuti siapa pun adalah alur kerja yang selamanya terlihat hijau padahal gagal. Ini adalah kegagalan diam-diam yang paling umum, dan tidak ada filter presisi yang dapat memperbaikinya.

• Ulasan harus menjalankan kode. Jika yang Anda butuhkan adalah rangkaian pengujian terhadap PR, ulasan LLM adalah alat yang salah. Ia membaca; ia tidak mengeksekusi. Pemindaian keamanan yang perlu membangun dan menjalankan artefak sebaiknya berada dalam pekerjaan terpisah dengan cakupan yang cermat — ingat, alur kerja ulasan tidak boleh diperluas untuk menjalankan kode yang dikendalikan PR.

• Repositori tersebut kecil atau hanya bersifat sementara. Di bawah tingkat perubahan tertentu, proses peninjauan lebih menjadi beban daripada bug yang berhasil dicegahnya.

Positif palsu, dan apa yang tidak dan tidak diperbaiki oleh pemfilteran presisi

Tuduhan terhadap setiap peninjau AI adalah bahwa ia berteriak serigala. Kerangka kerja ini menyerang masalah tersebut dalam dua lapisan, dan penting untuk memahami secara tepat lapisan mana yang memperbaiki kegagalan yang mana.

Lapisan deterministik (L1) menghilangkan temuan hantu: sebuah engine kadang mengklaim kode yang tidak ada — cuplikan yang menyimpang, temuan yang disalin ke file saudara. L1 memverifikasi cuplikan kode yang ada dari setiap temuan terhadap commit yang benar-benar direview dan menempatkan kembali atau membuang yang tidak cocok. Itu memperbaiki kelas false positive “baris ini bahkan tidak ada”, yang bersifat mekanis dan dapat diverifikasi.

Lapisan penilai (L2) menghilangkan duplikat dan klaim yang tidak didukung: penilai LLM mengelompokkan temuan berdasarkan akar penyebab dan membuang kelompok yang tingkat kepercayaannya berada di bawah ambang batas penilai (default 0.5). Ini memperbaiki “bug yang sama dilaporkan dengan tiga cara” dan temuan spekulatif.

Apa yang tidak diperbaiki oleh kedua lapisan itu patut dikatakan secara gamblang. Temuan yang salah tetapi percaya diri lolos dari penilai — penilai adalah LLM, dan LLM yang terdengar yakin tidak sama dengan temuan yang benar. Penilai yang menggunakan model yang sama dengan model peninjau setuju dengan dirinya sendiri, dan proses penilaian tersebut menjadi tidak aktif sambil tetap melaporkan keberhasilan; itulah sebabnya resep bawaan mengarahkan penilai ke model yang berbeda dari model peninjau. Dan rubrik tingkat keparahan sengaja dibuat konservatif — "jika ragu di antara dua tingkat, pilihlah yang lebih rendah" — yang berarti bug yang nyata tetapi bersyarat lebih mungkin dikategorikan sebagai advisori P2 daripada P1 yang memblokir. Itu adalah kalibrasi yang tepat untuk alat yang tidak boleh memblokir segalanya, tetapi itu tetaplah sebuah kalibrasi: ia menukar blocker yang terlewat dengan lebih sedikit alarm palsu. Ringkasan PR selalu menghitung setiap temuan, jadi P2 yang diredam masih ada untuk dibaca. Jika trade-off ini tidak tepat untuk tim Anda, rubrik dan ambang batas penilai adalah konfigurasi, bukan tiket dukungan.

Intinya

Untuk tim yang sudah menggunakan GitHub Actions, harness open-source adalah cara termurah untuk mendapatkan tinjauan kode otomatis pada setiap PR: satu file workflow, satu secret, tagihan token yang berskala dengan kode yang ditinjau, dan pilihan model yang Anda miliki. Beli produk per-seat ketika Anda menginginkan nol operasi dan vendor untuk dihubungi — bukan karena tinjauannya lebih baik, tetapi karena Anda membeli masalah orang lain alih-alih menangani masalah Anda sendiri. Dan sebelum Anda menyiapkan semua ini, tanyakan apakah tinjauan tersebut akan dibaca. Harness dapat membuat tinjauan terjadi secara otomatis. Ia tidak dapat membuat siapa pun membacanya.

Ingin mendapatkan reviewer yang sama tanpa menjalankannya sendiri? OrcaCode Review menjalankan harness yang sama persis ini sebagai aplikasi GitHub yang di-host — resep terbuka yang sama, tagihan per-token yang sama, tanpa kursi.