Coding agent yang bisa membuka pull request itu berguna. Coding agent yang bisa mem-merge-nya saat tidak ada yang mengawasi justru jadi risiko besar yang punya akses commit. Jarak di antara dua kalimat itulah inti persoalannya. Begitu sebuah agent bisa push ke branch, menjalankan test, dan menekan tombol merge, pertanyaannya bukan lagi “bisakah ia mengerjakan pekerjaannya”, melainkan “di mana batas kewenangannya”.
Sebagian besar tim menjawab pertanyaan itu tanpa sengaja. Agent memiliki izin apa pun yang diberikan oleh runtime-nya, review terjadi di terminal mana pun tempat run itu dimulai, dan catatan tentang siapa menyetujui apa hanya tersimpan di riwayat scroll satu orang. Pola ini bertahan sampai kamu menjalankan tiga agent di dua repository dan deploy hari Jumat mengirimkan sesuatu yang tidak dibaca siapa pun. Approval gate adalah solusinya, tapi hanya jika ia benar-benar checkpoint di sistem bersama, bukan sekadar kebiasaan yang kamu harap dipatuhi semua orang.
Sistem bersama itulah yang disediakan Sharkly. Kamu sudah punya coding agent; Sharkly mengubah run mereka menjadi Task dengan status, Assignee, dan langkah review yang harus dilakukan seseorang secara sengaja. Artikel ini membahas model operasional di baliknya: siapa yang menugaskan pekerjaan, siapa yang menjalankannya, siapa yang me-review-nya, siapa yang menerimanya, dan di mana tepatnya batas berhentinya agar agent tidak pernah mem-merge perubahannya sendiri tanpa di-review.
Apa sebenarnya approval gate itu
Approval gate adalah titik dalam siklus hidup sebuah task di mana eksekusi otomatis berhenti dan menunggu seseorang memutuskan langkah berikutnya. Bukan peringatan, bukan baris log yang bisa kamu lewati begitu saja: sebuah state tempat pekerjaan itu berhenti sampai ada manusia yang memindahkannya.
Perbedaan yang paling penting adalah antara agent yang mengusulkan perubahan dan agent yang menerapkannya. Membuka pull request adalah usulan. Mem-merge-nya adalah keputusan tentang production. Keduanya adalah tindakan kewenangan yang berbeda, dan yang kedua adalah tempat di mana pertimbangan tim harus berada. Sharkly membuat batas itu eksplisit: meski GitHub sudah terhubung, mem-merge pull request tidak mengubah status Task. Merge tetap menjadi tindakan manusia yang tercatat, bukan efek samping yang dipicu agent saat menyelesaikan pekerjaannya.
Ingatlah batas ini, karena sebagian besar cerita “agent merusak prod” sebenarnya adalah cerita tentang gate yang hilang antara usulan dan penerapan.
Model operasional: menugaskan, menjalankan, meninjau, menerima
Sharkly membagi sebuah task menjadi empat peran, masing-masing dengan satu tugas. Kontraknya jelas: Agent meneliti, mengeksekusi, menguji, dan melaporkan; People menetapkan arah, memberikan kewenangan, dan menerima hasilnya.
- Menugaskan. Seseorang menjelaskan kebutuhannya dan menetapkan Assignee. Sebuah Task membawa dua penetapan yang terpisah: People yang terlibat di dalamnya, dan satu Assignee eksekusi, yaitu Agent atau Crew yang menjalankan pekerjaan itu. Mengubah salah satunya tidak mengubah yang lain.
- Menjalankan. Assignee eksekusi mengerjakan tugasnya di git worktree yang terisolasi, sehingga run paralel tidak saling menyentuh file satu sama lain. Progres, hambatan, dan hasil dikembalikan ke Task.
- Meninjau. Saat Agent selesai, ia membiarkan Task menunggu review manusia alih-alih menutupnya. Diff, output test, dan ringkasan perubahan terlampir pada Task, bukan pada terminal.
- Menerima. Seseorang membaca buktinya dan memutuskan: minta perubahan, atau terima dan merge. Penerimaan adalah langkah terakhir, dan hanya manusia yang bisa melakukannya.
Nilainya di sini bukan karena Sharkly yang menjalankan agent-nya. Nilainya adalah keempat peran itu tetap terlihat di satu tempat, bukan melebur ke terminal mana pun yang kebetulan sedang terbuka. Untuk pembahasan lebih mendalam soal sisi review-nya, lihat human-in-the-loop coding agents.
Jadikan gate sebagai status, bukan kebiasaan
Gate yang harus kamu ingat adalah gate yang pada akhirnya akan kamu lewati. Karena itu, tanamkan ia ke dalam siklus hidup task.
Status di Sharkly membawa makna sistem melalui kategorinya. Backlog adalah status parkir: Task di sana tidak akan dieksekusi meski sudah ada Agent yang ditugaskan. Memindahkannya ke kategori siap dikerjakan itulah yang memungkinkan eksekusi dimulai. Completed bersifat terminal, dan mencapainya adalah tindakan manusia, bukan sesuatu yang diberikan Agent pada dirinya sendiri.
Status Task sengaja dipisahkan dari working state milik Agent. Saat status siklus hidupnya menunjukkan In Progress, Agent di bawahnya bisa sedang bekerja, menunggu balasan manusia, menunggu review manusia, atau melaporkan error. Pemisahan itulah gate-nya: Agent bisa menyelesaikan run-nya dan menampilkan “waiting for human review” tanpa Task pernah berpindah ke status yang menyiratkan bahwa perubahannya sudah dirilis. Pekerjaan itu kembali ke Task dan berhenti di sana sampai seseorang menerimanya.
Inilah juga yang membuat menjalankan banyak agent sekaligus menjadi aman. Ketika lima parallel agents in isolated worktrees semuanya masuk ke kolom review yang sama, kamu punya satu tempat untuk memilahnya alih-alih mengawasi lima terminal.
Satu contoh lengkap: dari tiket sampai PR yang di-merge
Mari kita telusuri satu Task, dengan format identifier SH-312 milik Sharkly.
- Buat tiketnya. Seseorang membuat
SH-312, sebuah task bug: “Pencarian mengembalikan hasil basi setelah filter diubah.” Deskripsinya memuat tujuan, langkah reproduksi, dan kriteria penerimaan. Assignee: Agent Claude Code yang terikat ke repository pencarian. - Rumuskan. Agent meneliti codebase dan riwayat terkait, mengonfirmasi cakupan, lalu memposting rencananya kembali ke Task. Orang tersebut membaca rencananya dan memindahkan
SH-312keluar dari Backlog ke status siap, yang menjadi sinyal untuk mulai. - Jalankan. Agent mengambil Task itu dan bekerja di worktree yang baru. Ia menulis perbaikannya, menjalankan typecheck dan test suite, lalu membuka pull request yang judulnya menyertakan
SH-312agar Sharkly menautkan PR tersebut kembali ke Task. - Berhenti di gate. Agent tidak melakukan merge. Ia melampirkan ringkasan perubahan, output test yang lulus, dan batasan yang diketahui, lalu membiarkan
SH-312menunggu review manusia. Pekerjaannya sudah kembali ke Task. - Review. Seseorang membuka
SH-312, membaca diff dan buktinya dalam satu tampilan, dan menyadari bahwa perbaikannya menyentuh helper query yang dipakai bersama. Ia meninggalkan komentar yang meminta perubahan yang lebih sempit. Pada Task dengan Agent Assignee yang siap, komentar itu memasukkan ulang run ke antrean, sehingga siklus permintaan perubahan tetap tercatat alih-alih dimulai ulang di chat pribadi. - Terima dan merge. Run kedua lolos review. Orang tersebut menyetujui pull request-nya, mem-merge-nya, dan memindahkan
SH-312ke Completed. Karena merge tidak menutup Task secara otomatis, penerimaan dan merge menjadi dua keputusan manusia yang tercatat, bukan satu rangkaian otomatis.
Setiap langkah dalam rantai itu bisa diperiksa kembali nanti, dan itulah inti dari traceable requirements-to-code workflow: kamu bisa menjawab “siapa yang menyetujui ini, dan berdasarkan bukti apa” tanpa harus mengubek-ubek riwayat scroll seseorang.
Di mana gate tidak perlu dipasang
Menambah gate tidak otomatis membuat semuanya lebih aman; gate hanya menambah friksi yang justru melatih orang untuk asal klik. Pasang gate di tempat yang biaya kesalahan merge-nya nyata. Untuk perubahan yang kecil, terdefinisi dengan baik, dan berisiko rendah yang ditugaskan ke satu Agent, berhenti di review-sebelum-merge sudah cukup, dan kamu tidak perlu menambahkan Crew atau langkah persetujuan tambahan di atasnya. Tambahkan review yang lebih ketat ketika dampak kesalahannya luas: kode bersama, migrasi, apa pun yang menyentuh auth atau billing.
Satu gate yang tidak pernah boleh dihapus adalah merge gate. Agent boleh meneliti, menulis, menguji, dan mengusulkan sepanjang hari. Apakah perubahannya sampai ke branch main kamu adalah keputusan manusia, dan harus tetap begitu bahkan ketika Agent benar hampir sepanjang waktu. Padukan review tingkat task dari Sharkly dengan branch protection yang sudah kamu miliki agar platform menegakkan apa yang dimaksudkan oleh alur kerjanya, dan tetap gunakan alat yang sudah dipakai timmu: hubungkan GitHub dan assign the ticket to an AI agent tanpa membangun ulang prosesmu.
Jika kamu sudah menjalankan beberapa coding agent dan mulai kehilangan jejak mana yang selesai, mana yang gagal, dan mana yang sedang menunggu kamu, kolom review itulah alasan untuk mencoba Sharkly. Jalankan agent yang sudah kamu miliki melaluinya dan biarkan keputusan merge tetap berada di tempat yang seharusnya.
FAQ
Bisakah Sharkly mencegah agent melakukan merge sendiri? Bisa. Mem-merge pull request tidak mengubah status Task di Sharkly, jadi sebuah run berakhir di “waiting for human review” alih-alih menerapkan perubahan. Padukan itu dengan branch protection GitHub untuk menegakkan review yang diwajibkan di tingkat repository.
Apa bedanya status task dan state agent? Status task adalah kategori siklus hidupnya (Backlog, Started, Completed, dan seterusnya). State agent adalah apa yang sedang dilakukan run saat ini: bekerja, menunggu balasan manusia, menunggu review, atau error. Sebuah Task bisa tetap In Progress sementara Agent menunggu kamu.
Apakah saya perlu Crew untuk setiap task yang di-review? Tidak. Untuk pekerjaan kecil dengan cakupan yang jelas, tugaskan Task ke satu Agent dan gunakan gate review-sebelum-merge. Simpan penggunaan Crew untuk tujuan yang memerlukan Agent pemimpin untuk mengoordinasikan beberapa anggota.
