Review Pull Request dengan AI Agent: Panduan Setup 6 Langkah

Jawaban singkat: Untuk menerapkan peninjauan pull request oleh agen AI, serahkan proses review ke agen kedua yang memiliki instruksinya sendiri, checkout terpisah, dan jika memungkinkan, model yang berbeda. Jalankan agen ini secara otomatis saat progres pekerjaan mencapai status review, tugaskan untuk menjalankan pengujian dan memberikan penilaian PASS atau CHANGES REQUIRED, serta kirimkan kegagalan kembali ke agen pembuat (builder). Keputusan merge tetap berada di tangan manusia.

Mengapa agen AI sebaiknya meninjau pull request sebelum Anda

Setiap pull request yang ditulis oleh agen AI bermuara di meja yang sama: meja Anda. Ketika hanya satu agen yang mengirimkan satu PR per jam, ini tentu bukan masalah. Namun ketika lima agen berjalan secara paralel, antrean menumpuk lebih cepat daripada kemampuan Anda membaca diff, dan tahap review awal pun menjadi bottleneck.

Agen peninjau (reviewer agent) bertugas menangani tahap review awal tersebut. Agen ini tidak menggantikan pertimbangan Anda, melainkan menyaring PR yang gagal dalam pengujian, menyimpang dari cakupan (scope), atau membocorkan data rahasia (secrets), sehingga PR yang akhirnya sampai ke Anda benar-benar layak diperiksa. Di Sharkly, Anda dapat mengaturnya hanya dengan satu Agen tambahan dan dua Automations. Panduan ini akan membahas setiap langkahnya secara terperinci.

Jika ingin memahami batasan review otomatis terlebih dahulu, silakan baca apa saja yang bisa dan tidak bisa diverifikasi oleh agen code review AI. Artikel ini berfokus pada panduan penyiapannya.

Mengapa satu agen tidak bisa meninjau kodenya sendiri

Agen yang menulis kode juga menyusun narasi di balik kode tersebut. Saat Anda memintanya memeriksa pekerjaannya sendiri, agen hanya akan membaca ulang jalan pikirannya dan menyetujuinya. Titik buta (blind spot) yang memicu bug adalah titik buta yang sama saat proses peninjauan berlangsung.

Hal ini paling sering terlihat pada pengujian. Agen builder yang kesulitan meloloskan tes bisa saja melemahkan assertion dan menganggap tugas telah selesai. Kami telah mengulas pola-pola ini dalam artikel tentang cara memergoki agen coding yang mencurangi pengujian. Sebaliknya, agen reviewer yang netral akan membaca diff tanpa bias dan mengajukan pertanyaan berbeda: apakah perubahan ini menjalankan apa yang diminta tugas, dan tidak lebih dari itu?

Esai desain dari tim DeepSeek Harness mengenai super-agent juga menerapkan pemisahan serupa: beberapa Worker yang terhubung ke PR yang sama dapat melihat setiap aktivitas dan menyelesaikan konflik di antara mereka. Tulisan tersebut memang mendeskripsikan desain prototipe dan bukan produk akhir, namun gagasannya sangat relevan. Proses review berjalan jauh lebih efektif ketika peninjau merupakan pihak yang terpisah.

Langkah 1: Pisahkan builder dan reviewer

Buat dua Agen terpisah, bukan satu Agen dengan dua mode. Masing-masing memiliki instruksi, repositori, dan execution target tersendiri.

Agen di Sharkly tidak memiliki pemilih model langsung. Execution target-nya merupakan kombinasi Computer beserta Runtime yang terdeteksi di Computer tersebut. Oleh karena itu, “menggunakan model yang berbeda” berarti menghubungkan reviewer ke Runtime yang berbeda. Runtime kedua membawa perspektif dan karakteristik analisis yang berbeda terhadap diff. Biaya setiap eksekusi ditagihkan ke paket yang terhubung dengan Runtime tersebut, karena Sharkly tidak menjual token.

Atur direktori kerja reviewer ke mode Temporary. Dokumentasi Computers menjelaskan bagaimana setiap eksekusi mendapatkan direktori terisolasi, dan eksekusi repositori dapat menyiapkan Git worktree baru yang bersih. Reviewer melakukan checkout branch PR pada salinannya sendiri sehingga tidak akan menimpa berkas milik builder. Artikel kami tentang agen paralel dalam worktree terisolasi mengulas mengapa hal ini sangat penting ketika beberapa agen berbagi repositori yang sama.

Langkah 2: Tulis instruksi untuk reviewer

Instruksi agen mencakup peran, pemeriksaan yang perlu dilakukan, dan format pelaporan. Detail spesifik terkait tugas tetap berada pada deskripsi tugas masing-masing. Buat instruksi reviewer tetap ringkas dan terukur:

You are the code reviewer for this Space. You never push, merge or edit files.

1. Read the triggering task. If it is not a code task in this Space, reply "not mine" and stop.
2. Find the linked pull request (the task ID appears in its title, description or branch).
3. Check out the PR branch in your worktree. Run the test command from the repo README.
4. Compare the diff to the task's acceptance criteria.
5. Post one verdict comment on the task in the format below. Nothing else.

Langkah pertama lebih krusial dari yang terlihat. Saat ini, pemicu status (status trigger) dan pemicu komentar (comment trigger) mencakup seluruh Organisasi, sehingga instruksi harus memastikan kesesuaian tugas sebelum mengambil tindakan. Hal ini dijelaskan secara gamblang dalam dokumentasi Automations.

Langkah 3: Tentukan trigger

Sharkly Automations memadukan instruksi, Agen atau Crew, serta satu atau beberapa pemicu (trigger). Untuk review PR, terdapat dua trigger yang paling cocok.

Perubahan status tugas. Tambahkan status seperti In Review ke dalam alur kerja Space Anda. Builder memindahkan tugasnya ke status tersebut setelah membuat PR, dan reviewer pun mulai bekerja. Eksekusi yang dipicu oleh perubahan status akan membuat utas percakapan pada tugas tersebut, sehingga hasil penilaian beserta penggunaan tokennya tetap terikat pada pekerjaan terkait.

Tangkapan layar di atas adalah gerbang kendali yang digunakan blog ini untuk draf artikelnya sendiri: saat tugas mencapai status Ready for Release, Agen reviewer akan mengambil alih. Pola yang sama berlaku untuk peninjauan kode.

Webhook. Jika PR dibuat di luar task board Anda, arahkan webhook pull_request GitHub ke URL webhook Automation. Saat verifikasi tanda tangan aktif, Sharkly juga menerima header X-Hub-Signature-256 dari GitHub, sehingga Anda cukup menempelkan signing secret ke kolom Secret di GitHub. Karena eksekusi via webhook tidak terhubung ke tugas tertentu, reviewer akan mengunggah penilaiannya langsung pada PR tersebut menggunakan GitHub CLI.

Ujilah salah satu alur tersebut menggunakan tombol Run now sebelum menerapkannya secara penuh.

Langkah 4: Berikan checklist kepada reviewer

Reviewer tanpa checklist cenderung menulis esai panjang. Dengan checklist, ia akan menulis temuan konkret. Lima pertanyaan berikut mencakup sebagian besar evaluasi PR buatan agen:

1. Apakah pengujian berjalan dan lolos? Reviewer menjalankan pengujian sendiri dan tidak mengandalkan ringkasan dari builder semata.
2. Apakah cakupan (scope) tetap terjaga? Perubahan pada berkas di luar lingkup tugas dianggap sebagai temuan, meskipun perubahannya tampak tidak berbahaya.
3. Apakah ada kredensial rahasia yang terekspos? Token, kunci API, dan nilai .env pada diff maupun log.
4. Apakah ada perubahan yang merusak dependensi (breaking changes)? Perubahan signature fungsi, endpoint yang dihapus, atau migrasi tanpa mekanisme rollback.
5. Apakah ada pengujian yang diperlemah? Assertion yang dihapus, penambahan skip pengujian baru, atau pelonggaran nilai yang diharapkan (expected values).

Simpan daftar tersebut dalam sebuah Skill jika beberapa Agen reviewer membutuhkannya, sehingga satu pembaruan akan otomatis berlaku untuk semuanya.

Langkah 5: Tetapkan format penilaian (verdict)

Format penilaian yang bisa dipindai manusia dalam sepuluh detik jauh lebih efektif daripada uraian panjang yang akhirnya dilewati. Gunakan format baku:

VERDICT: CHANGES REQUIRED

Tests: 41 passed, 2 failed (test_refund_rounding, test_refund_zero)
Scope: OK, 3 files, all under billing/
Secrets: none found
Breaking changes: refund() now raises on amount=0; two callers in api/ not updated
Weakened tests: none

Required:
1. Handle amount=0 in refund() or update both callers.
2. Fix the rounding in test_refund_rounding; do not change the expected value.

Status PASS menggunakan struktur bidang yang sama dengan daftar Required yang dikosongkan. Format yang baku ini juga memudahkan penghitungan statistik: Anda dapat memantau seberapa sering setiap kriteria gagal dan memperketat instruksi builder secara tepat sasaran.

Langkah 6: Tutup loop kembali ke builder

Penilaian CHANGES REQUIRED semestinya mengaktifkan kembali agen builder secara otomatis tanpa perlu Anda teruskan secara manual. Buat Automation kedua yang dialokasikan untuk Agen builder, dengan pemicu komentar (comment trigger) berdasarkan frasa khusus.

Pencocokan komentar bersifat case-insensitive dan akan terpicu jika frasa tersebut muncul di mana saja dalam komentar. Pilihlah frasa unik yang tidak mungkin diketik secara tidak sengaja, dan instruksikan reviewer untuk hanya menuliskannya pada baris CHANGES REQUIRED. Jika builder mengutip kembali frasa tersebut dalam jawabannya, ia bisa memicu dirinya sendiri secara berulang. Oleh karena itu, instruksikan agar ia tidak pernah mengulanginya.

Batasi siklus pengulangan ini. Cukup dua putaran review dan perbaikan, setelah itu reviewer harus menyerahkan tugas tersebut kepada manusia lengkap dengan penilaian terakhirnya.

Peran penting yang tetap dipegang manusia

Keputusan merge tetap sepenuhnya berada di tangan Anda. Pada integrasi GitHub Sharkly, ID tugas pada judul PR menghubungkan PR ke tugas tersebut, dan proses merge tidak secara otomatis mengubah status tugas. Tidak ada kode yang di-deploy hanya karena agen menyatakan PASS.

Perkuat juga perlindungan ini di GitHub: fitur protected branches dengan persetujuan manusia wajib mencegah agen reviewer yang terlalu percaya diri menjadi benteng pertahanan terakhir. Anda juga memegang kendali atas keputusan strategis yang tidak bisa dinilai oleh checklist: apakah rancangan arsitektur ini sudah tepat, dan apakah fitur ini memang perlu dibuat? Untuk mengelola antrean PR yang masuk ke Anda, simak panduan tentang peringkat antrean PR agen dan mengapa review manual menjadi bottleneck.

Kesimpulan

Antrean PR dari agen AI tidak akan lagi menumpuk begitu agen kedua menangani tahap review awal. Pisahkan builder dan reviewer, sediakan worktree dan Runtime terpisah bagi reviewer, picu melalui perubahan status atau webhook, serta pastikan ia menjawab lima pertanyaan wajib dalam format baku. Teruskan hasil kegagalan menggunakan frasa pemicu khusus, batasi siklus maksimal dua putaran, dan simpan wewenang merge untuk Anda sendiri.

Jika Anda sudah menjalankan sepuluh agen coding sekaligus, langkah ini adalah kelanjutan penting berikutnya. Mulai gratis di Sharkly dan buat Agen reviewer Anda sekarang.

FAQ

Bisakah agen AI meninjau pull request miliknya sendiri?

Bisa, tetapi efektivitasnya jauh lebih rendah dalam mendeteksi masalah. Agen tersebut membawa asumsi yang sama dengan saat ia menulis kode. Agen reviewer terpisah dengan instruksi mandiri dan, idealnya, Runtime yang berbeda akan meneliti diff tanpa bias tersebut.

Haruskah reviewer menggunakan model yang berbeda dari builder?

Ya, jika memungkinkan. Di Sharkly, model ditentukan oleh Runtime, jadi hubungkan Agen reviewer ke Runtime yang berbeda dari builder—misalnya Codex yang meninjau pekerjaan Claude Code.

Apa yang sebaiknya diperiksa pertama kali oleh reviewer kode AI?

Pengujian (tests). Mintalah reviewer menjalankan seluruh test suite sendiri dan melaporkan jumlah tes yang lolos maupun gagal. Selanjutnya periksa cakupan (scope), rahasia (secrets), breaking changes, serta pengujian yang diperlemah, secara berurutan.

Bisakah agen reviewer menyetujui dan melakukan merge pada PR?

Sebaiknya jangan izinkan. Pertahankan hak merge hanya untuk manusia melalui fitur branch protection. Reviewer cukup memberikan komentar penilaian; keputusan akhir tetap berada di tangan manusia.

Bagaimana cara mencegah loop review berjalan tanpa henti?

Batasi maksimal dua putaran pada instruksi reviewer, dan gunakan frasa komentar yang tidak akan diulang oleh builder. Begitu batas tercapai, reviewer akan menyerahkan tugas tersebut kepada manusia.

Apakah ini berfungsi untuk pull request GitHub yang dibuat di luar Sharkly?

Ya. Hubungkan webhook GitHub ke pemicu webhook pada Automation. Sharkly dapat memvalidasi signature header GitHub saat verifikasi diaktifkan.