Agent coding dengan human-in-the-loop biasanya digambarkan sebagai sebuah pengaturan: mode di mana alat tersebut bertanya sebelum melakukan edit. Itu satu loop, dan itu loop yang paling kecil. Loop itu berjalan di dalam terminal satu developer, untuk satu sesi, dan menguap begitu sesi berakhir. Tim yang merasa memiliki pengawasan manusia karena semua orang membiarkan Claude Code dalam mode Manual sebenarnya hanya mengawasi ketukan tombol, bukan hasil akhirnya.
Panduan ini memaparkan alur kerja review sebagai lima gerbang, mulai dari prompt izin di dalam runtime hingga keputusan penerimaan pada catatan bersama, dan menjelaskan siapa yang memutuskan di setiap gerbang serta di mana keputusan itu dicatat. Gerbang runtime berasal dari dokumentasi resmi alat-alat tersebut. Gerbang tim menggunakan Sharkly, karena Sharkly mencatatnya pada Task, bukan di scrollback seseorang. Jika Anda ingin definisi praktiknya terlebih dahulu, panduan kami tentang manajemen proyek AI agent membahas loop tempat alur kerja ini berada.
TL;DR
Alur kerja review human-in-the-loop untuk coding agent memiliki lima gerbang: mode izin runtime, konfirmasi rencana sebelum pekerjaan menjadi Task, batas eksekusi yang menentukan kapan sebuah run boleh dimulai, sinyal perhatian yang mengarahkan review ke orang tertentu, dan penerimaan yang dicatat sebagai perubahan status oleh orang tersebut. Hanya gerbang pertama yang merupakan pengaturan alat. Empat gerbang lainnya adalah keputusan tim, dan semuanya memerlukan catatan bersama agar benar-benar nyata. Agent melakukan riset, eksekusi, pengujian, dan pelaporan. Manusia yang menetapkan arah, memberikan wewenang, dan menerima hasilnya.
Gerbang 1: Mode izin di dalam runtime
Setiap coding agent yang serius menyediakan tombol persetujuan. Mode izin Claude Code berkisar dari default, yang diberi label Manual, yang bertanya sebelum melakukan edit, perintah shell, dan akses jaringan, hingga acceptEdits, plan, dan auto, di mana model kedua yang disebut classifier meninjau tindakan menggantikan Anda, sampai bypassPermissions yang hanya untuk container terisolasi. Beralihlah dengan Shift+Tab atau --permission-mode. Codex menawarkan ide yang sama melalui perintah /permissions-nya, yang mengatur kapan Codex boleh mengedit file atau menjalankan perintah tanpa bertanya.
Gerbang ini perlu tetapi tidak cukup. Gerbang ini bersifat per sesi dan per developer, melindungi mesin alih-alih kebutuhan, dan tidak meninggalkan catatan yang bisa dibaca rekan tim. Pada paket Pro, Max, dan Team, Claude Code kini dimulai dalam mode auto secara default, yang merupakan pilihan wajar justru karena classifier lebih cepat dan lebih konsisten daripada manusia lelah yang mengklik "ya". Pelajarannya bukan melawan tombol tersebut. Pelajarannya adalah berhenti menganggap tombol itu sebagai review.
Gerbang 2: Konfirmasi rencana
Gerbang tingkat tim yang pertama terjadi sebelum ada kode sama sekali. Di Agent chat Sharkly, mode Plan memungkinkan Agent mengusulkan tindakan untuk Anda tinjau, dan Task serta sub-task yang direncanakan baru dibuat setelah seseorang mengonfirmasi proposal tersebut. Anda bisa mengonfirmasi tanpa memulai, atau mengonfirmasi sekaligus memulai.
Di sinilah cakupan kerja ditentukan, dan biayanya murah: mengedit sub-task yang diusulkan memakan waktu satu menit, meninjau refactor yang tidak diminta memakan waktu satu sore. Biarkan Explore tetap dipilih jika Anda hanya ingin analisis. Gunakan Crew ketika seorang leader perlu menafsirkan tujuan dan melibatkan anggota Agent lain; gunakan satu Agent saja, dan lewati seremoni, jika satu peran sudah mencakup pekerjaannya. Panduan kami tentang mengobrol dengan AI agent atau menetapkan Task membahas ketiga mode tersebut.
Gerbang 3: Batas eksekusi
Task yang ditugaskan ke Agent tidak akan dimulai selama berada di Backlog. Memindahkannya ke status yang kategorinya siap untuk dikerjakan itulah yang memulai run, dan kategori completed, canceled, serta duplicate tidak pernah memulai run awal. Kategori status karenanya merupakan gerbang yang dijalankan manusia dengan sengaja, dan terlihat di board.
Dua hal membuat gerbang ini lebih dari sekadar formalitas. Setiap run mendapat direktori terisolasi, dan run yang didukung repositori menyiapkan worktree baru, sehingga run yang disetujui tidak bisa merusak run yang tidak disetujui siapa pun. Selain itu, run membawa deskripsi Task, komentar terbaru, dan Workflow tipe Task, yang membatasi status yang boleh dipilih Agent. Agent tidak bisa menandai pekerjaannya sendiri sebagai accepted jika Workflow tidak memberinya status tersebut. Artikel kami tentang Git worktree dengan AI coding agent menjelaskan isolasinya.
Gerbang 4: Sinyal perhatian
Agent mengakhiri sebuah run di salah satu dari dua tempat yang berguna: dengan hasil, atau dengan pertanyaan. Sharkly menamai keduanya. Agent dapat meninggalkan Task dalam keadaan menunggu balasan manusia atau menunggu review manusia, dan pekerjaan yang gagal atau terblokir muncul sebagai item perhatian. Sinyal-sinyal itu masuk ke Inbox, di bagian Primary, untuk orang yang bertanggung jawab, dan kegagalan run ditujukan kepada orang yang ditugaskan, bukan ke semua pelanggan.
Gerbang di sini adalah perutean, dan inilah yang paling sering salah dilakukan tim secara tidak sengaja. Review yang masuk ke sebuah channel tidak sampai ke siapa pun. Review yang ditujukan ke assignee manusia, pada Task, dengan log eksekusi hanya berjarak satu klik, sampai ke seseorang yang bisa ditanya soal itu nanti. Panduan kami tentang inbox AI agent membahas mekanisme antreannya.
Membalas juga merupakan cara pekerjaan berlanjut. Komentar anggota pada Task dengan assignee Agent yang siap dapat memasukkan run berikutnya ke antrean, sehingga umpan balik review melanjutkan pekerjaan yang sama alih-alih memulai proses kedua. Menyebut seseorang, atau menggunakan all-mention, tidak dengan sendirinya memulai Agent, sehingga percakapan antar-manusia tidak membangunkan Agent.
Gerbang 5: Penerimaan pada catatan
Penerimaan adalah ketika seseorang mengubah status Task setelah membaca buktinya. Bacalah dengan urutan ini: kriteria penerimaan dalam deskripsi, komentar Agent yang menyebutkan pemeriksaan yang dijalankannya dan apa yang masih belum pasti, log eksekusi, lalu diff-nya. Log mencatat mengapa run dimasukkan ke antrean, kapan dimulai dan berakhir, panggilan tool dan event Runtime, sumber pemicunya, serta detail kegagalan; inilah yang membedakan antara meninjau perubahan dan meninjau cerita tentang sebuah perubahan.
Dua aturan melindungi gerbang ini. Menggabungkan pull request yang tertaut tidak mengubah status Task, sehingga merge tidak pernah disalahartikan sebagai penerimaan. Dan run Automation yang selesai menggambarkan run-nya, bukan janji bahwa setiap hasil di hilir sudah benar. Keduanya berasal langsung dari dokumentasi produk, dan keduanya ada karena tim terus-menerus mengacaukan "selesai" dengan "benar".
Alur kerja dalam satu tabel
| Gerbang | Pertanyaan yang dijawab | Siapa yang memutuskan | Di mana dicatat |
|---|---|---|---|
| Mode izin | Bolehkah sesi ini menyentuh hal itu? | Developer | Tidak dicatat di mana pun secara bersama |
| Konfirmasi rencana | Apakah pemecahan ini sudah tepat? | Seseorang, atas proposalnya | Sub-task yang dikonfirmasi |
| Batas eksekusi | Bolehkah Task ini berjalan sekarang? | Siapa pun yang memindahkannya keluar dari Backlog | Perubahan status di Activity |
| Sinyal perhatian | Siapa yang harus melihat, dan pada apa? | Sharkly mengarahkannya ke assignee | Inbox Primary dan Task |
| Penerimaan | Apakah hasilnya sudah benar? | Assignee manusia | Perubahan status oleh orang tertentu |
Kapan membuka gerbang lebih lebar
Tidak setiap Task layak mendapat lima perhentian, dan berpura-pura sebaliknya justru membuat review menjadi sandiwara. Pekerjaan read-only seperti audit repositori hanya perlu gerbang 1 dan gerbang 5. Pekerjaan yang bisa dibalik di worktree terisolasi, seperti pembaruan dependensi dengan pengujian, bisa melewati konfirmasi rencana. Automation yang berjalan sesuai jadwal sebaiknya mencantumkan dalam instruksinya kapan seseorang harus meninjau atau memutuskan, dan sebaiknya dijalankan secara manual serta diperiksa sebelum ada yang bergantung pada jadwal tersebut; panduan kami tentang Automation di Sharkly membahas hal itu.
Pertahankan kelima gerbang untuk apa pun yang mengubah antarmuka publik, menyentuh data, atau tidak dapat dibalik dengan satu perintah. Dan pertahankan satu aturan di mana pun: assignee manusia yang disebutkan namanya pada setiap Agent Task. Sharkly memisahkan tanggung jawab manusia dari eksekusi Agent dengan sengaja, sehingga sebuah Task dapat memiliki orang yang ditugaskan dan Agent yang ditugaskan pada saat yang sama. Akuntabilitas tidak didelegasikan, dan catatannya harus menunjukkan siapa yang memegangnya.
Apa yang bukan human-in-the-loop
Bukan seseorang yang mengawasi terminal. Bukan prompt izin dengan peninjau yang kelelahan di belakangnya. Dan bukan status yang bertuliskan Completed. Automation berhenti di titik di mana penilaian tim diperlukan dan mengembalikan pengiriman dengan konteks lengkap serta bukti yang dapat diperiksa. Kalimat itu adalah keseluruhan alur kerjanya; gerbang-gerbang hanyalah tempat penerapannya. Sharkly bukan pengganti Claude Code, Codex, atau alat eksekusi lain; Sharkly adalah lapisan yang mencatat keputusan-keputusan ini.
FAQ
Apakah mode auto di Claude Code menghilangkan manusia dari loop? Mode itu menghilangkan manusia dari prompt izin. Classifier meninjau tindakan terhadap permintaan Anda; classifier tidak meninjau apakah hasilnya memenuhi kebutuhan. Gerbang 2 hingga 5 tetap milik manusia.
Bagaimana cara menghentikan Agent di tengah run? Eksekusi yang dalam antrean atau sedang berjalan dapat dibatalkan. Memindahkan Task ke status Canceled atau Duplicate juga menghentikan run yang aktif; memindahkannya ke Completed tidak, jadi batalkan dulu jika Agent masih bekerja.
Siapa yang sebaiknya menjadi peninjau? Assignee manusia pada Task tersebut. Sharkly mengirim sinyal menunggu-review dan kegagalan kepada orang itu, itulah sebabnya setiap Agent Task sebaiknya mencantumkan satu orang. Panduan kami tentang Agent di Sharkly menjelaskan dua slot penugasan tersebut.
Bisakah umpan balik review dikembalikan ke Agent tanpa Task baru? Bisa. Komentar pada Task dapat memasukkan run lanjutan ke antrean untuk Agent yang ditugaskan, dan komentar yang beruntun digabungkan agar tidak membuat run duplikat.
