Anda memasang agen tinjauan kode AI ke dalam pipeline Anda, dan hasilnya berhasil. Agen itu menandai null check yang hilang, menemukan import yang tidak terpakai, dan meninggalkan tiga komentar rapi soal penamaan. Anda merge. Dua hari kemudian seorang pelanggan menemukan bug yang terlewat begitu saja oleh agen: perubahan itu bersih secara internal tetapi melakukan hal yang salah. Agen tinjauan memverifikasi kodenya. Agen itu tidak bisa memverifikasi niatnya.
Celah itulah inti dari keseluruhan cerita tentang agen tinjauan kode AI. Mereka bagus dalam menangani kelas masalah tertentu yang dapat diperiksa, dan buta terhadap kelas masalah lain yang terlihat identik dalam sebuah diff. Anggap persetujuan mereka sebagai acceptance, dan Anda akan meloloskan kelas yang buta itu. Pahami di mana batasnya, dan Anda akan mendapatkan first pass yang cepat yang membebaskan reviewer Anda untuk melakukan penilaian yang hanya bisa dilakukan manusia.
Artikel ini memetakan batas tersebut: apa yang bisa diverifikasi oleh agen tinjauan kode AI, apa yang tidak bisa, dan model operasional yang menjaga keduanya tetap lurus. Sharkly adalah lapisan yang akan kita bahas, ruang kerja bersama tempat tinjauan agen dan acceptance manusia menjadi dua status berbeda pada Task yang sama, bukan satu cap karet. Anda sudah punya coding agent; intinya di sini adalah meninjau output mereka tanpa berpura-pura bahwa agen kedua menutup siklusnya.
Apa yang bisa diverifikasi oleh agen tinjauan kode AI
Agen tinjauan kode AI adalah program yang membaca diff, menjalankan pemeriksaan terhadapnya, dan melaporkan temuan seperti cara seorang reviewer manusia meninggalkan komentar. Zona andalnya adalah segala hal yang bisa dikonfirmasi oleh reviewer yang teliti hanya dengan membaca perubahan tersebut dan bagian-bagian di sekitarnya:
- Kebenaran mekanis: sintaksis, tipe, penanganan null dan batas yang jelas, promise rejection yang tidak tertangani, kebocoran resource yang terlihat di diff.
- Logika lokal: kesalahan off-by-one, kondisi yang terbalik, cabang mati, variabel yang dibaca sebelum di-set.
- Konvensi: penamaan, format, kebersihan import, apakah fungsi baru punya test di sebelahnya.
- Anti-pattern yang sudah diketahui: SQL yang dibangun dari penggabungan string, secret yang di-commit dalam bentuk plaintext, method publik yang tidak punya validasi input.
Semuanya punya satu kesamaan. Buktinya ada di dalam diff. Agen tidak perlu tahu bisnis Anda untuk menangkapnya, dan agen menangkapnya lebih cepat serta lebih konsisten daripada manusia yang kelelahan pada pukul 6 sore. Itu nilai yang nyata, dan itulah alasan tim beralih ke alat-alat ini. Panduan code review Google menganggap pemeriksaan mekanis ini sebagai standar minimal agar perhatian manusia bisa difokuskan pada desain. Reviewer AI adalah cara yang sabar untuk menyelesaikan pemeriksaan itu setiap saat.
Apa yang tidak bisa diverifikasinya
Inilah batasnya, dinyatakan secara lugas: agen tinjauan kode AI tidak bisa memverifikasi bahwa perubahan tersebut adalah perubahan yang tepat. Semua hal di bawah ini membutuhkan konteks yang tidak terdapat dalam diff.
- Niat versus spesifikasi. Kode bisa sempurna dan menyelesaikan masalah yang salah. Hanya kriteria acceptance dari tiket yang bisa menentukan itu, dan agen jarang melihatnya.
- Kebenaran bisnis. Apakah aturan diskon, perhitungan pajak, atau batas izin sesuai dengan cara perusahaan bekerja adalah penilaian, bukan aturan lint.
- Perilaku lintas sistem. Perubahan yang terlihat baik-baik saja dalam satu file bisa merusak pemanggil tiga service jauhnya. Top Ten OWASP penuh dengan kegagalan seperti broken access control yang hanya muncul ketika Anda menelusuri seluruh jalur request, bukan hanya diff.
- Apakah test-nya jujur. Agen bisa memastikan sebuah test ada dan lulus. Agen tidak bisa memberi tahu Anda bahwa test tersebut menguji hal yang penting, atau bahwa agen yang menulis kodenya juga menulis test yang dibentuk agar lulus.
Yang terakhir itulah jebakan yang khas pada kode tulisan AI. Ketika kelas sistem yang sama menghasilkan perubahan dan tinjauannya, diff yang bersih dan check yang hijau bisa keduanya benar dan keduanya tidak relevan. Jadi persetujuan dari agen tinjauan adalah sinyal, bukan keputusan. Agen melaporkan; manusia menerima.
Model operasional yang menutupi celah tersebut
Solusinya bukan agen tinjauan yang lebih baik. Solusinya adalah model operasional di mana tugas agen tinjauan dan tugas manusia merupakan status yang berbeda, dan tidak ada satu pun yang dilewati.
Sharkly membuat status-status itu menjadi eksplisit sebagai Status Task. Sebuah Task bergerak melalui In progress, ke Ready for review, lalu ke Done. Aturannya sederhana dan sangat penting: agen memindahkan pekerjaan ke Ready for review; manusia memindahkannya ke Done. Agen, baik yang menulis kode maupun yang meninjaunya, tidak akan pernah bisa menandai pekerjaannya sendiri sebagai accepted. Agen meneliti, mengeksekusi, menguji, dan melaporkan. Manusia menetapkan arah, memberikan wewenang, dan menerima hasilnya. Otomasi berhenti di titik yang membutuhkan penilaian tim.
Setiap peran punya satu tugas. Coding Agent menghasilkan perubahan. Review Agent menjalankan pemeriksaan mekanis dan melampirkan temuannya. Reviewer manusia membaca temuan tersebut, memeriksa perubahan terhadap niat dari tiket, dan memutuskan. Semuanya kembali ke Task: diff, komentar Review Agent, output test, dan keputusan manusia berada di satu timeline alih-alih tersebar di PR, chat, dan ingatan seseorang.
Gunakan review agent sebagai gerbang pertama ketika perubahannya bersifat mekanis dan mandiri, seperti refactor, pembaruan dependency, perbaikan bug yang cakupannya jelas; biarkan agen membersihkan noise agar pemeriksaan manusia menjadi cepat. Jangan mengandalkannya sebagai satu-satunya gerbang ketika perubahan menyentuh uang, auth, migrasi data, atau kontrak publik; di sana manusia membaca lebih dulu dan pemeriksaan agen hanyalah checklist, bukan vonis.
Contoh nyata: dari tiket hingga PR yang di-merge
Ambil SH-312: "Tolak kode kupon yang kedaluwarsa saat checkout." Seseorang menulis kriteria acceptance dan menetapkan Task. Coding Agent mengambilnya, bekerja di worktree yang terisolasi, dan mengembalikan diff plus test yang lulus ke Task, memindahkannya ke Ready for review.
Sekarang Review Agent berjalan. Agen mengonfirmasi tipe-tipenya, menandai satu null guard yang hilang, dan mencatat bahwa test tersebut mencakup kasus kedaluwarsa. Pemeriksaan bersih. Dengan kebiasaan lama, persetujuan itu langsung di-merge.
Namun sebaliknya, reviewer manusia membuka Task dan membaca dengan mengacu pada niat. Kode tersebut menolak kupon yang kedaluwarsa, persis seperti yang tertulis. Tetapi kriteria acceptance juga menyiratkan bahwa kupon yang sudah ditukarkan seharusnya ditolak, dan baik coding Agent maupun Review Agent tidak mengetahuinya, karena hal itu ada di kepala reviewer dan di spesifikasi produk, bukan di diff. Reviewer meminta perubahan. SH-312 kembali ke In progress dengan catatan spesifik, Agent memperluasnya, dan baru setelah itu seseorang memindahkannya ke Done dan merge pull request-nya.
Review agent tersebut menjalankan tugasnya dengan baik dan tetap akan meloloskan sebuah celah. Model operasional menangkapnya, karena acceptance adalah tindakan terpisah oleh seseorang yang memiliki konteks. Itulah disiplin yang sama di balik meninjau kode yang dihasilkan AI dengan bukti tingkat Task: unit tinjauannya adalah Task dan niatnya, bukan diff secara terpisah.
Di mana menempatkan gerbang tinjauan Anda
Pertanyaan praktisnya bukanlah apakah akan menggunakan agen tinjauan kode AI. Pertanyaannya adalah di mana pemeriksaan mereka dihitung dan di mana manusia harus membaca lebih dulu. Beberapa aturan yang terbukti bertahan:
- Biarkan agen menjadi gerbang untuk gaya, format, dan bug mekanis pada setiap perubahan. Itu adalah pemeriksaan yang paling dikuasainya dan yang paling buruk dilakukan manusia saat lelah.
- Wajibkan gerbang manusia untuk apa pun yang menyentuh auth, billing, migrasi data, atau API publik. Zona buta terkonsentrasi di sana.
- Sesuaikan ukuran gerbang Anda dengan kapasitas tinjauan Anda. Agen menghasilkan lebih cepat daripada manusia menerima, jadi habiskan pemeriksaan manusia di tempat agen buta.
- Jadikan gerbang sebagai status, bukan kebiasaan. Gerbang persetujuan yang terdokumentasi dan memblokir Done bersifat dapat ditegakkan; norma bahwa "seseorang seharusnya memeriksa" tidak. Menjaga manusia tetap dalam loop hanya berhasil jika loop tersebut merupakan langkah yang diwajibkan alur kerja.
Agen tinjauan kode AI bukan pengganti reviewer manusia. Agen itu adalah pemeriksaan pertama yang membuat pemeriksaan manusia lebih cepat dan lebih tajam. Jika Anda sudah menjalankan beberapa coding agent dan ingin output mereka ditinjau serta diterima di satu tempat alih-alih di lima tab PR, itulah masalah yang menjadi dasar dibangunnya Sharkly: menetapkan, melacak, dan meninjau pekerjaan agen pada Task bersama, dengan temuan Review Agent dan keputusan manusia keduanya kembali ke catatan yang sama. Pertahankan coding agent dan review agent yang sudah Anda gunakan, lalu tambahkan lapisan yang memutuskan kapan pemeriksaan mereka sudah cukup.
