Sebuah agen coding dapat mengubah tiket menjadi pull request selagi Anda ngopi. Kecepatan itu memunculkan pertanyaan yang lebih senyap yang tidak pernah dijawab oleh tooling untuk Anda: begitu diff-nya ada, siapa yang memilikinya? Bukan siapa yang mengetiknya, agen yang melakukannya. Siapa yang bertanggung jawab atas apakah perubahan itu dirilis, apakah itu perubahan yang tepat, dan apa yang terjadi saat sistem rusak pukul 2 pagi. Eksekusi berpindah ke agen. Kepemilikan tidak, dan tidak bisa.
Kekaburan ini makin parah begitu Anda menjalankan lebih dari satu agen. Berikan satu bug ke Claude Code dan bug lain ke Codex, dan sekarang Anda memiliki dua branch, dua ringkasan, dan tidak ada jawaban bersama untuk pertanyaan sederhana: nama siapa yang ada di masing-masing branch ini saat di-merge? Kepemilikan yang hidup di scrollback terminal bukanlah kepemilikan. Itu tebakan yang bertahan sampai git log berikutnya.
Inilah masalah yang melatarbelakangi dibuatnya Sharkly. Sharkly berada di atas agen coding Anda sebagai lapisan yang mencatat siapa yang menugaskan pekerjaan, agen mana yang menjalankannya, siapa yang meninjau hasilnya, dan siapa yang menerimanya. Artikel ini memaparkan model operasi tersebut sebagai empat peran dan serangkaian status, lalu menelusuri satu tiket dari penugasan hingga PR yang sudah di-merge. Untuk mekanisme tinjauan di bawahnya, panduan kami tentang agen coding human-in-the-loop membahas lima gate yang menegakkan keputusan-keputusan ini.
TL;DR
Kepemilikan manusia atas pekerjaan agen berarti akuntabilitas atas suatu perubahan tidak pernah berpindah ke agen, bahkan ketika eksekusinya berpindah. Model operasi ini memiliki empat peran: seseorang menugaskan, Agen menjalankan, manusia yang disebutkan meninjau, dan manusia yang sama menerimanya. Agen dapat memindahkan sebuah Tugas hingga Siap ditinjau; hanya manusia yang memindahkannya ke Selesai. Agen meneliti, mengeksekusi, menguji, dan melaporkan. Manusia menetapkan arah, memberikan wewenang, dan menerima hasilnya.
Siapa yang memiliki pekerjaan yang dihasilkan agen
Kepemilikan dan eksekusi adalah dua pekerjaan yang berbeda, dan mencampuradukkannya adalah kesalahan mendasar. Eksekusi adalah menghasilkan perubahan: membaca basis kode, mengedit file, menjalankan tes, membuka PR. Agen melakukannya dengan baik dan cepat. Kepemilikan adalah bertanggung jawab atas hasil: bahwa perubahan itu layak dilakukan, bahwa perubahan itu memenuhi kriteria penerimaan, dan bahwa seseorang dapat ditanya tentangnya tiga bulan dari sekarang. Akuntabilitas itu tetap pada manusia, karena agen tidak bisa dimintai justifikasi atas suatu trade-off setelah kejadian atau menanggung konsekuensinya.
Cara paling bersih untuk menyatakan pembagian ini adalah kontrak manusia-agen: agen meneliti, mengeksekusi, menguji, dan melaporkan; manusia menetapkan arah, memberikan wewenang, dan menerima hasilnya. Otomatisasi berhenti di tempat penilaian tim dibutuhkan. Segala hal hingga “menerima hasilnya” dapat diserahkan ke agen. Penerimaan itu sendiri tidak bisa, dan keputusan untuk merilis juga tidak. Artikel kami tentang asisten AI vs rekan tim AI menarik garis yang sama dari arah sebaliknya.
Model operasi: tugaskan, jalankan, tinjau, terima
Setelah Anda memisahkan kepemilikan dari eksekusi, alur kerja terbagi menjadi empat peran dengan satu tugas masing-masing. Memberi nama pada peran-peran itulah yang mencegah lima agen paralel berubah menjadi lima branch yang terbengkalai.
| Langkah | Siapa yang bertindak | Yang mereka miliki |
|---|---|---|
| Tugaskan | Seseorang | Memutuskan pekerjaan itu layak dilakukan, menulis kriteria penerimaan, dan menyebutkan siapa yang bertanggung jawab |
| Jalankan | Agen, melalui Runtime di sebuah Komputer | Menghasilkan perubahan, menjalankan tes, dan melaporkan apa yang dilakukan serta apa yang belum pasti |
| Tinjau | Penanggung Jawab manusia | Menilai hasil terhadap kriteria penerimaan dan bukti |
| Terima | Penanggung Jawab manusia yang sama | Keputusan untuk merge dan merilis |
Detail pentingnya ada di baris pertama dan terakhir: orang yang sama memiliki penugasan dan penerimaan. Itulah cara siklus ini ditutup. Siapa pun yang memutuskan pekerjaan itu penting, dialah yang mengonfirmasi bahwa pekerjaan itu selesai. Sharkly mendukung ini dengan menyimpan dua slot penugasan pada satu Tugas sekaligus, Penanggung Jawab manusia dan penanggung jawab Agen, sehingga tanggung jawab dan eksekusi tercatat sebagai fakta terpisah, bukan satu “ditugaskan kepada” yang ambigu. Untuk mengetahui bagaimana pekerjaan sampai ke agen, lihat panduan kami tentang menugaskan, melacak, dan meninjau pekerjaan agen di satu tempat.
Status dan gate: agen mencapai Siap ditinjau, manusia memindahkan pekerjaan ke Selesai
Model operasi menjadi nyata ketika dipetakan ke status Tugas, karena perubahan status adalah keputusan yang bisa Anda tunjuk di kemudian hari. Di sini aturannya ketat dan perlu dinyatakan dengan gamblang: agen dapat memajukan pekerjaan hingga Siap ditinjau; hanya manusia yang memindahkan Tugas ke Selesai.
| Kategori status | Siapa yang memindahkannya | Arti |
|---|---|---|
| Backlog | Manusia | Belum dimulai. Menugaskan Agen di sini tidak menjalankan apa pun |
| Siap dikerjakan | Manusia | Memindahkan Tugas ke kategori inilah yang memulai proses Agen |
| Sedang dikerjakan | Agen | Proses sedang berjalan di worktree yang terisolasi |
| Siap ditinjau | Agen | Proses selesai dan menunggu manusia yang ditunjuk |
| Selesai / Diterima | Manusia | Manusia membaca bukti dan menerima hasilnya |
Dua batas melindungi ini. Pertama, Agen tidak dapat memilih status yang tidak diberikan oleh Alur Kerja Tugasnya, sehingga ia tidak dapat menandai pekerjaannya sendiri sebagai diterima. Ia membiarkan Tugas menunggu tinjauan manusia, dan sinyal itu masuk ke Inbox orang yang bertanggung jawab, bukan ke kanal yang tidak dibaca siapa pun. Kedua, menggabungkan pull request yang tertaut tidak mengubah status Tugas. Merge adalah peristiwa Git, bukan keputusan penerimaan, dan Sharkly memisahkan keduanya agar “PR sudah di-merge” tidak pernah disalahartikan sebagai “seseorang menilai ini benar.” Jika kapasitas tinjauan menjadi kekhawatiran Anda, analisis kami tentang mengapa tinjauan manusia adalah hambatan yang sebenarnya membahas cara merancangnya.
Dari tiket hingga PR yang di-merge: satu contoh langkah demi langkah
Berikut model yang berjalan dari awal hingga akhir pada satu Tugas, SH-312, “Tambahkan rate limiting ke endpoint pencarian publik.”
- Tugaskan. Seorang engineer menulis Tugas: endpoint, batas target, dan kriteria penerimaan (429 saat overflow, tes yang ada tetap lulus, tes baru untuk batas tersebut). Ia menetapkan dirinya sebagai Penanggung Jawab manusia dan memilih penanggung jawab Agen. Tugas berada di Backlog. Belum ada yang berjalan.
- Jalankan. Ia memindahkan
SH-312ke status Siap dikerjakan. Perubahan status itulah yang memulai proses. Agen mengambil Tugas, menyiapkan worktree baru agar pekerjaan ini tidak bertabrakan dengan apa pun, membaca deskripsi dan komentar terbaru, mengedit endpoint, menambahkan tes, dan menjalankan rangkaian tes. - Laporkan. Agen membuka pull request dan memposting komentar di Tugas: ringkasan perubahan, tes yang dijalankan dan hasilnya, serta satu catatan jujur bahwa ia tidak melakukan uji beban pada batas tersebut di bawah trafik nyata. Ia memindahkan
SH-312ke Siap ditinjau. Ia berhenti di situ. Ia tidak bisa melangkah lebih jauh. - Tinjau. Sinyal menunggu-tinjauan mencapai Inbox engineer tersebut. Ia membaca secara berurutan: kriteria penerimaan, komentar Agen, log eksekusi, lalu diff. Log menunjukkan mengapa proses diantrekan dan panggilan tool apa yang dilakukan, sehingga ia meninjau perubahan dan bukan cerita tentangnya. Kesenjangan uji beban itu nyata, jadi ia berkomentar meminta tes pada batas maksimum yang didokumentasikan. Komentar itu mengantrekan proses lanjutan untuk Agen yang sama; ia tidak membuka Tugas kedua.
- Terima. Agen menambahkan tes, melaporkan lagi, dan mengembalikan Tugas ke Siap ditinjau. Kali ini bukti cocok dengan kriteria. Ia menggabungkan PR dan memindahkan
SH-312ke Selesai, dua tindakan yang disengaja oleh orang yang memiliki pekerjaan itu sejak awal.
Setiap langkah kembali ke Tugas: proses, tautan PR, komentar tinjauan, penerimaan. Tidak ada yang hanya hidup di terminal. Panduan kami tentang meninjau kode yang dihasilkan AI dengan bukti tingkat tugas membahas lebih dalam tentang apa yang harus dibaca sebelum Anda menerima.
Di mana kepemilikan diam-diam terputus
Anda tidak perlu menjalankan seluruh seremoni ini pada setiap Tugas, dan berpura-pura sebaliknya akan membuat tinjauan menjadi sandiwara. Gunakan versi ringan saat pekerjaan bersifat hanya-baca atau mudah dikembalikan: audit repositori atau pembaruan dependensi dengan tes yang lulus bisa langsung dari proses ke penerimaan cepat. Gunakan loop empat peran lengkap, dengan manusia yang ditunjuk di kedua ujungnya, setiap kali perubahan menyentuh data, mengubah antarmuka publik, atau tidak dapat dibatalkan dengan satu perintah.
Mode kegagalan yang perlu diwaspadai bukanlah agen yang melakukan terlalu banyak. Yang perlu diwaspadai adalah kepemilikan yang tidak ditugaskan. Tugas dengan penanggung jawab Agen dan tanpa Penanggung Jawab manusia memiliki eksekusi tanpa akuntabilitas: masalah branch terbengkalai yang dibungkus sebagai kemajuan. Solusinya adalah satu aturan di mana-mana: setiap Tugas Agen menyebutkan manusia yang memilikinya. Saat Anda mengoordinasikan serah-terima antar beberapa agen, panduan kami tentang pola serah-terima agen-ke-agen dan agen-ke-manusia menunjukkan di mana pemilik manusia berada dalam rantai tersebut.
Kesimpulan
Kepemilikan manusia atas pekerjaan agen bukanlah penghambat otomatisasi. Justru itulah yang membuat otomatisasi aman untuk diskalakan. Biarkan agen melakukan eksekusi, semuanya, dengan kecepatan apa pun yang mereka bisa. Simpan empat keputusan pada manusia: apa yang ditugaskan, apakah wewenang untuk menjalankan diberikan, apakah hasilnya memenuhi standar, dan apakah akan dirilis. Tuliskan keputusan-keputusan itu sebagai perubahan status pada Tugas bersama, sehingga akuntabilitas menjadi fakta yang bisa dibaca siapa pun, bukan tebakan di scrollback seseorang.
Jika Anda sudah menjalankan beberapa agen coding, Sharkly memberi Anda satu tempat untuk menugaskan pekerjaan mereka, memantau prosesnya, dan mencatat siapa yang meninjau dan menerima setiap hasil. Anda dapat merakit model ini secara manual dengan worktree dan spreadsheet, atau unduh Sharkly dan biarkan Tugas yang membawanya. Untuk gambaran lengkap lapisan ini, mulai dengan manajemen agen coding di atas Claude Code dan Codex.
FAQ
Apakah kepemilikan manusia berarti seseorang mengawasi setiap proses agen? Tidak. Kepemilikan adalah akuntabilitas, bukan supervisi. Seseorang menugaskan pekerjaan dan menerima hasilnya; agen berjalan tanpa pengawasan di antaranya. Memantau terminal tetap tidak bisa diskalakan melewati satu agen.
Bisakah agen menandai pekerjaannya sendiri sebagai selesai? Tidak. Agen dapat memajukan Tugas ke Siap ditinjau, tetapi Alur Kerja Tugasnya tidak memberinya status diterima. Manusia membaca bukti dan memindahkan Tugas ke Selesai.
Apakah menggabungkan pull request berarti menerima tugas? Tidak. Menggabungkan PR yang tertaut adalah peristiwa Git dan tidak mengubah status Tugas di Sharkly. Penerimaan adalah perubahan status terpisah yang dilakukan oleh pemilik manusia setelah tinjauan.
Siapa yang seharusnya memiliki tugas agen? Orang yang memutuskan pekerjaan itu layak dilakukan. Sharkly menyimpan slot Penanggung Jawab manusia di samping penanggung jawab Agen, sehingga sinyal tinjauan diarahkan ke orang tersebut dan mereka menerimanya.
Apa yang terjadi jika tidak ada manusia yang ditugaskan? Anda mendapatkan eksekusi tanpa akuntabilitas. Aturan amannya adalah setiap Tugas Agen menyebutkan pemilik manusia, sehingga proses yang selesai selalu memiliki seseorang yang bertanggung jawab atasnya.
