Sebuah pull request masuk ke antrean Anda dengan 340 baris perubahan di sembilan file. Yang menulisnya adalah coding agent. Diff tidak memberi tahu Anda apa yang diminta kepada agen, pendekatan apa saja yang dicobanya lalu ditinggalkan, apa yang dijalankannya untuk meyakinkan diri bahwa perubahannya berfungsi, atau di mana ia tahu telah mengambil jalan pintas. Jadi Anda melakukan salah satu dari dua hal: membaca sekilas lalu menyetujui, atau menurunkan ulang seluruh perubahan dari awal. Yang pertama adalah cara kode buruk terkirim. Yang kedua berarti agen tidak menghemat waktu Anda sama sekali.
Meninjau kode hasil AI dengan baik adalah pekerjaan yang berbeda dari meninjau PR rekan kerja, karena penulisnya tidak bisa duduk di samping Anda dan menjelaskan alasan di baliknya. Solusinya adalah meninjau diff beserta buktinya: tujuan, pemeriksaan yang dijalankan, dan batasan yang sudah ditandai oleh agen. Itulah yang menjadi dasar Sharkly dibangun. Sharkly berada di atas coding agent Anda (Claude Code, Codex, Gemini, dan lainnya) dan menyimpan tujuan, perubahan, hasil verifikasi, serta tinjauan manusia atas setiap eksekusi dalam satu Task, alih-alih tersebar di berbagai terminal dan deskripsi PR.
Panduan ini menguraikan model operasi di baliknya: siapa yang menugaskan pekerjaan, siapa yang menjalankannya, siapa yang meninjaunya, siapa yang menerimanya, status dan gerbang yang memisahkan tugas agen dari tugas manusia, serta satu contoh nyata dari tiket hingga PR yang di-merge.
Jawaban singkat
Tinjau kode hasil AI pada tingkat Task, bukan pada tingkat diff. Minta agen melampirkan ringkasan perubahan, hasil typecheck/test/build yang dijalankannya, dan batasan yang diketahuinya ke sebuah Task bersama, lalu pindahkan Task tersebut ke status peninjauan. Seorang manusia membaca bukti itu berdampingan dengan diff, meminta perubahan atau menerima, lalu mengambil keputusan merge. Agen menghasilkan dan memverifikasi; manusia menerima.
Mengapa meninjau diff saja tidak cukup
Membaca kode lebih sulit daripada menulisnya. Satu kenyataan dalam code review yang sudah banyak didokumentasikan adalah bahwa peninjau memegang konteks lebih sedikit daripada penulis, dan ketika penulisnya adalah agen, kesenjangan itu menjadi mutlak. Diff GitHub hanya menunjukkan tujuan, tidak pernah rutenya. Anda tidak bisa melihat bahwa agen sempat mencoba lapisan cache, menemui race condition, lalu membatalkannya. Anda juga tidak bisa melihat bahwa ia menjalankan test suite dan ada satu flaky test yang gagal tanpa kaitan dengan perubahan tersebut.
Tanpa konteks itu, peninjauan runtuh menjadi dua mode kegagalan. Menyetujui asal-asalan akan meloloskan kode yang terlihat masuk akal tetapi diam-diam merusak edge case yang tidak pernah dipikirkan agen. Menurunkan ulang semuanya memaksa Anda merekonstruksi penalaran sendiri, dan pada titik itu keunggulan kecepatan agen sudah hilang. Keduanya tidak bisa diskalakan saat tiga agen membuka PR bersamaan. Jalan keluarnya adalah membuat pekerjaan agen dapat ditinjau, bukan hanya outputnya.
Apa sebenarnya yang dimaksud bukti tingkat Task
Bukti tingkat Task adalah catatan yang dilampirkan Agen pada Task-nya: tujuan yang menjadi dasarnya, perubahan yang dihasilkan, pemeriksaan yang dijalankan, dan batasan yang diketahuinya. Alih-alih diff telanjang, Anda mendapat diff dengan jejak asal-usul.
Dalam praktiknya, paket bukti terdiri dari empat hal:
- Tujuan dan kriteria penerimaan, di deskripsi Task, agar peninjauan diukur terhadap apa yang diminta, bukan terhadap apa yang tampak masuk akal.
- Ringkasan perubahan, dalam kata-kata agen sendiri: apa yang diubahnya dan mengapa.
- Hasil verifikasi: output typecheck, test, dan build yang dijalankan agen sebelum menyerahkan pekerjaan.
- Batasan yang diketahui: edge case, asumsi, dan tindak lanjut yang ditandai agen alih-alih disembunyikan.
Semuanya kembali ke Task. Eksekusi, hambatan, hasil, dan diskusi tindak lanjut berada dalam satu linimasa, sehingga peninjau cukup membuka satu catatan alih-alih menyatukan PR, utas Slack, dan prompt yang setengah terlupa. Inilah disiplin di balik alur kerja dari kebutuhan ke kode yang dapat dilacak: bukti adalah bagian dari hasil kerja.
Model operasi: siapa yang menugaskan, siapa yang menjalankan, siapa yang meninjau, siapa yang menerima
Peninjauan yang baik bergantung pada peran yang jelas. Kontraknya singkat: agen meneliti, mengeksekusi, menguji, dan melaporkan; manusia menetapkan arah, memberikan wewenang, dan menerima hasilnya. Otomasi berhenti di titik yang memerlukan pertimbangan tim.
| Peran | Siapa | Tugas |
|---|---|---|
| Penugasan | Seseorang (biasanya Pemilik Task) | Menjelaskan kebutuhan, menetapkan kriteria penerimaan, menugaskan Task |
| Pelaksana | Agen, di Komputer yang terhubung, melalui Runtime | Mengambil Task, mengeksekusi di worktree terisolasi, melampirkan bukti |
| Peninjau | Seseorang | Membaca diff berdampingan dengan bukti, meminta perubahan atau menyetujui |
| Penerima | Seseorang (Pemilik atau approver yang ditunjuk) | Mengambil keputusan akhir penerimaan dan merge/rilis |
Sharkly bukan pengganti Claude Code, Codex, atau alat eksekusi lain. Sharkly menambahkan lapisan Task, Komputer, konteks, dan peninjauan bersama di sekitar alat yang sudah digunakan tim Anda. Runtime-lah yang menulis kode; Sharkly menentukan ke antrean siapa peninjauan masuk dan bukti apa yang harus ada sebelum manusia melihatnya. Jika Anda ingin versi lebih mendalam soal sisi penugasan, lihat siapa yang menugaskan dan siapa yang menerima pekerjaan agen.
Status dan gerbang peninjauan: agen memindahkan ke Ready for review, manusia memindahkan ke Done
Gerbang peninjauan adalah batas status. Di Sharkly, setiap status task termasuk dalam kategori tetap yang punya makna sistem: Backlog (diparkir), Unstarted (siap, belum dimulai), Started (sedang berjalan), dan Completed (terminal). Beberapa status yang terlihat bisa berbagi satu kategori, sehingga alur kerja suatu tipe task dapat menjalankan Development dan Ready for review sebagai dua status Started yang berbeda sebelum apa pun mencapai Completed.
Struktur itulah yang membuat gerbang ini nyata. Agen dapat membawa Task dari Development ke Ready for review, dan dapat membiarkan Task menunggu peninjauan manusia. Agen tidak boleh memindahkan Task ke status Completed atas kemauannya sendiri. Penerimaan adalah transisi yang dilakukan manusia, memang begitu desainnya.
| Status | Kategori | Siapa yang memindahkannya ke sini |
|---|---|---|
| Backlog | Backlog | Seseorang, saat memarkir pekerjaan |
| Todo | Unstarted | Seseorang, saat Task sudah siap |
| Development | Started | Agen, saat mengambil dan mengerjakan Task |
| Ready for review | Started | Agen, saat bukti sudah dilampirkan |
| Done | Completed | Seseorang, setelah menerima |
Konfigurasikan alur kerja sehingga transisi ke status Completed Anda mengharuskan kehadiran manusia, dan Anda punya gerbang peninjauan yang tetap berlaku meski agen berproduksi lebih cepat daripada kemampuan Anda mengawasi. Ini adalah versi mekanis dari menjaga human in the loop untuk coding agent, dan di sinilah Anda menentukan di mana harus menghentikan agen sebelum mereka melakukan merge.
Contoh nyata: dari tiket hingga PR yang di-merge
Ambil SH-312: "Tambahkan rate limiting pada endpoint pencarian publik, 60 permintaan per menit per API key."
- Seseorang membuat SH-312 dengan tujuan tersebut dan dua kriteria penerimaan: permintaan yang melebihi batas mengembalikan HTTP 429, dan batasnya dihitung per key, bukan per IP. Task dimulai di Todo.
- Agen mengambilnya, memindahkannya ke Development, dan berjalan di worktree terisolasi agar checkout-nya tidak bertabrakan dengan agen lain yang mengerjakan repo yang sama. (Worktree inilah alasan eksekusi paralel tetap bersih; lihat satu checkout per task.)
- Agen mengimplementasikan limiter token-bucket, membuka PR, dan melampirkan buktinya ke SH-312: ringkasan perubahan, hasil typecheck dan unit test yang lulus, hasil build, serta satu batasan yang diketahui: "Bucket berada di memori proses, jadi batasnya tereset saat deploy dan tidak dibagi antar instance."
- Agen memindahkan SH-312 ke Ready for review. Task itu masuk ke antrean manusia dengan diff dan bukti dalam satu paket.
- Peninjau membaca catatan batasan lebih dulu, memutuskan bucket in-memory cukup untuk saat ini, dan meminta satu perubahan: kembalikan header
Retry-Afterpada respons 429. Agen melakukan perubahan tersebut dan melampirkan ulang output test yang diperbarui. - Peninjau menerima, melakukan merge PR, dan memindahkan SH-312 ke Done, dengan tiket tindak lanjut untuk limiter bersama yang sudah ditautkan.
Peninjauan hanya memakan waktu beberapa menit karena peninjau tidak perlu merekonstruksi perubahan; bukti yang mengerjakannya. Ini loop yang sama dengan manajemen proyek Claude Code dari issue hingga peninjauan, dengan paket bukti yang membuat peninjauan cepat alih-alih menjadi penghambat.
Cara cepat meninjau bukti, dan kapan cukup ringan
Tidak setiap perubahan perlu perlakuan penuh. Gunakan aturan keputusan.
Lakukan peninjauan menyeluruh saat perubahan menyentuh auth, billing, migrasi data, API publik, atau apa pun yang sulit dibatalkan: baca diff baris per baris, jalankan ulang test sendiri, dan cocokkan catatan batasan dengan edge case versi Anda. Cukup ringan saat perubahannya sekadar penyesuaian teks, refactor internal yang sudah teruji baik, atau pembaruan dependensi dengan semua pemeriksaan hijau: baca ringkasannya, pindai diff-nya, pastikan verifikasi lulus, lalu terima.
Daftar periksa singkat untuk peninjauan menyeluruh:
- Apakah diff memenuhi setiap kriteria penerimaan, bukan hanya happy path?
- Apakah agen benar-benar menjalankan pemeriksaannya, atau hanya mengklaim? Verifikasi output yang dilampirkan.
- Baca catatan batasan. Apakah ada batasan yang sifatnya penghambat, bukan sekadar tindak lanjut?
- Apakah perubahan terbatas pada permintaan, atau agen menyentuh file yang tidak berkaitan?
Jika Anda sudah menjalankan beberapa coding agent, inilah alur kerja yang bisa Anda kelola di satu tempat dengan Sharkly: tugaskan Task, biarkan agen melampirkan bukti, tinjau di gerbangnya. Anda bisa merakit sendiri komponennya dengan worktree, template PR, dan papan status, atau Unduh Sharkly dan dapatkan Task, bukti, serta gerbang sebagai satu sistem.
FAQ
Apa itu bukti tingkat Task untuk kode hasil AI? Yaitu catatan yang dilampirkan agen ke Task-nya bersama diff: tujuan, ringkasan perubahan, hasil typecheck/test/build yang dijalankannya, dan batasan yang diketahuinya. Meninjau paket itu lebih cepat dan lebih aman daripada meninjau diff saja.
Bisakah agen AI menyetujui kodenya sendiri? Tidak, dan itulah inti dari gerbang peninjauan. Agen dapat memindahkan Task ke Ready for review, tetapi transisi ke status Completed adalah keputusan manusia. Agen menghasilkan dan memverifikasi; manusia menerima.
Bagaimana cara meninjau kode AI lebih cepat tanpa sekadar menyetujui asal-asalan? Sesuaikan upaya dengan tingkat risiko. Baca bukti untuk setiap perubahan, tetapi simpan peninjauan baris per baris dan menjalankan ulang test untuk area berisiko tinggi seperti auth dan migrasi. Lihat bagaimana kapasitas peninjauan berkembang saat agen melampaui kecepatan manusia.
Apakah saya tetap memakai pull request? Ya. Agen membuka pull request sungguhan di GitHub; lapisan Task menambahkan bukti dan gerbang di sekitarnya sehingga PR bukan satu-satunya tempat konteks berada.
