Saat pertama kali menjalankan tiga agen coding sekaligus, eksekusi bukan lagi bagian yang lambat. Anda serahkan sebuah bug ke Claude Code, sebuah refactor ke Codex, dan celah cakupan tes ke Runtime ketiga, lalu empat puluh menit kemudian tiga branch siap. Di situlah penantian sesungguhnya dimulai, karena ketiganya kini menunggu Anda. Anda membaca diff pertama, menyetujuinya, dan dua lainnya menganggur. Anda punya eksekusi paralel tapi review yang serial, jadi paralelismenya nyaris tidak memberi manfaat apa pun.
Inilah jebakan yang menimpa setiap tim yang sudah mahir menjalankan agen secara paralel. Hambatannya tidak hilang; ia berpindah, dari "seberapa cepat agen bisa menulis kode" menjadi "seberapa cepat manusia bisa membaca, menilai, dan menerima hasilnya." Menambah agen keempat justru memperburuk keadaan: antrean pekerjaan selesai makin panjang, sementara reviewernya tetap satu orang.
Solusinya bukan me-review lebih cepat atau lebih percaya. Solusinya adalah merancang review sebagai bagian eksplisit dari alur kerja, bukan sebagai pikiran belakangan yang hanya ada di kepala Anda. Itulah alur kerja yang dibahas artikel ini, dan itulah masalah yang menjadi dasar pembangunan Sharkly: menyimpan tujuan, diff, bukti, dan review dari setiap run agen dalam satu Task, sehingga antrean review menjadi sesuatu yang bisa Anda lihat dan kelola, bukan tumpukan tab browser yang terbuka.
Mengapa agen paralel memindahkan hambatan ke tahap review
Review adalah sebuah antrean. Run agen yang selesai datang dengan laju tertentu, seseorang menyelesaikannya dengan laju tertentu, dan jika kedatangan lebih cepat daripada penyelesaian, antrean itu tumbuh tanpa batas. Itu inti persoalannya, dan itulah sebabnya throughput agen mentah bukan angka yang tepat untuk dioptimalkan. Jika sepuluh agen selesai dalam satu jam sementara Anda hanya sanggup menerima tiga perubahan per jam dengan cermat, Anda telah membangun pabrik yang dermaga bongkar-muatnya hanya satu orang berbekal papan klip.
Sebagian besar perkakas menyembunyikan hal ini. Tumpukan pull request memang memperlihatkan pekerjaannya, tapi tidak menunjukkan mana item yang benar-benar menunggu keputusan, mana yang masih berjalan, dan mana yang sudah di-merge. Antreannya nyata, tetapi tersebar di tab, notifikasi, dan ingatan. Tujuan desain pertama adalah membuatnya terlihat, karena Anda tidak bisa mengelola hambatan yang tidak bisa Anda lihat. Artikel pendamping tentang matematika kapasitas review membahas apa yang terjadi saat tingkat konkurensi naik.
Model operasional: siapa yang menugaskan, siapa yang menjalankan, siapa yang me-review, siapa yang menerima
Sebelum menyentuh status, beri nama pada keempat peran itu. Keempatnya adalah peran yang berbeda, dan mencampuradukkannya itulah yang membuat review terasa kacau.
Seseorang menugaskan pekerjaan: mengubah sebuah niat menjadi Task yang terdefinisi dengan kriteria penerimaan. Sesuatu menjalankannya: sebuah Agent, di atas sebuah Computer, yang dieksekusi dalam sebuah Runtime, menghasilkan perubahan dan catatan tentang apa yang dilakukannya. Seseorang me-review hasilnya: membaca diff dan buktinya, lalu memutuskan apakah sudah memenuhi kriteria. Seseorang menerimanya: mengambil keputusan untuk merge dan rilis, yang merupakan keputusan berbeda dari "kodenya sudah oke."
Sharkly merumuskan kontraknya dalam satu kalimat yang layak ditempel di sticky note: agen meneliti, mengeksekusi, menguji, dan melaporkan; manusia menetapkan arah, memberikan wewenang, dan menerima hasilnya. Otomasi berhenti di titik yang membutuhkan pertimbangan tim. Assign dan accept memang dirancang untuk manusia. Run adalah tugas Agent. Review adalah pekerjaan yang harus dirancang dengan sengaja, karena di situlah antrean terbentuk.
Satu batas yang berguna: PR yang sudah di-merge tidak sama dengan hasil yang diterima. Merge adalah operasi git. Penerimaan adalah saat seseorang memutuskan bahwa perubahan tersebut melakukan apa yang diminta Task. Ketika keduanya melebur jadi satu klik, kualitas review turun sebatas energi yang dimiliki reviewer pada menit itu.
Peran, status, dan gate review
Beri bentuk pada antrean itu dengan memberi Task sekumpulan kecil status yang bisa dilalui agen dan manusia. Task adalah unit kerja utama: di dalamnya tersimpan tujuan, percakapan, dan run. Inti dari status adalah agar agen bisa memajukan sebuah Task sampai tepat di gate review, dan hanya manusia yang bisa melewatinya.
| Status | Siapa yang memindahkannya ke sini | Arti |
|---|---|---|
| Backlog | Manusia | Sudah terdefinisi, belum dimulai. Tidak ada run yang terjadi di sini. |
| Ready | Manusia | Sudah boleh dijalankan; Agent bisa mengambilnya. |
| In progress | Agent | Sebuah run sedang dieksekusi di worktree yang terisolasi. |
| Ready for review | Agent | Run selesai, perubahan dan bukti sudah dilampirkan, menunggu manusia. |
| Changes requested | Manusia | Dikembalikan dengan komentar; run lanjutan berjalan pada Task yang sama. |
| Done | Manusia | Diterima, di-merge, dirilis. |
Gate adalah transisi masuk ke Ready for review dan keluar menuju Done. Agen bisa mencapai gate itu sendiri; mereka tidak bisa melewatinya. Aturan tunggal itulah yang memungkinkan Anda menjalankan sepuluh agen dengan aman: mereka mengisi kolom Ready for review secara paralel, dan Anda mengosongkannya dengan laju yang menjaga kualitas tetap terjaga. Panjang kolom itulah hambatan Anda, yang kini terlihat.
Inilah dua keputusan yang jujur. Beri gate pada setiap perubahan yang sampai ke pengguna atau menyentuh uang, auth, migrasi data, atau API publik. Jangan beri gate pada spike sekali pakai, boilerplate hasil generate yang toh akan digenerate ulang, atau pekerjaan di balik flag yang belum bisa diakses siapa pun. Gate pada semua hal hanya memindahkan hambatan kembali ke reviewer untuk perubahan yang sebenarnya tidak butuh manusia. Approval gates membahas di mana harus memasang titik henti untuk pekerjaan berisiko lebih tinggi.
Rancang review agar tetap skalabel
Me-review output agen paralel tidak sama dengan me-review PR rekan setim. Jumlahnya lebih banyak, datangnya beruntun, dan Anda sering kali kurang tahu bagaimana hasil itu dibuat. Tiga langkah berikut menjaga biaya review per item tetap rendah.
Lampirkan bukti ke Task, bukan ke ingatan Anda. Sebuah run harus mengembalikan ringkasan perubahan, output typecheck dan tes, hasil build, serta batasan yang diketahui, semuanya tercatat. Saat Anda membuka item Ready for review, Anda sedang membaca berkas kasus, bukan menyusun ulang apa yang terjadi. Itulah bedanya antara me-review dengan bukti tingkat Task dan menjalankan ulang semuanya sendiri untuk membangun kembali kepercayaan.
Review keputusannya, bukan ketukan tombolnya. Properti yang bisa diperiksa mesin—format, keamanan tipe, apakah tes lulus—harus di-gate oleh mesin sebelum Task sampai ke Anda. Panduan code review dari Google membuat pemisahan yang sama: otomatiskan apa yang bisa diverifikasi alat, agar manusia memusatkan perhatian pada desain dan kecocokan. Penilaian Anda yang terbatas diarahkan ke "apakah ini perubahan yang tepat", bukan "apakah tadi berhasil dikompilasi."
Batasi pekerjaan yang sedang berjalan. Batas keras pada berapa banyak Task yang boleh berada di In progress sekaligus mencegah kolom Ready for review menjadi dinding yang tak akan pernah bisa Anda daki. Inilah gagasan batas WIP kanban yang diterapkan pada agen: memulai run keenam saat lima run sudah menunggu Anda tidak menambah throughput, melainkan menyembunyikan antrean. Akan membantu juga untuk memantau agen yang sedang berjalan agar Anda bisa membedakan run yang macet dari run yang lambat sebelum mencapai gate.
Satu contoh nyata, dari tiket hingga PR yang di-merge
Ambil contoh Task yang terlihat nyata, SH-312: "Batasi laju endpoint pencarian publik." Seseorang menyusunnya di Backlog dengan kriteria penerimaan (429 setelah N permintaan per menit per key, header yang terdokumentasi, satu tes) lalu memindahkannya ke Ready.
Tiga Agent sedang menggarap Space itu secara paralel. Satu di antaranya mengambil SH-312, meng-clone repositori yang dikonfigurasi ke sebuah Computer, dan berjalan di worktree terisolasi sehingga branch-nya tidak pernah bentrok dengan dua run lain yang sedang berjalan. Agen itu menulis limiter, menambahkan tes, menjalankan typecheck dan seluruh suite, membuka PR yang judulnya memuat ID Task, lalu memindahkan SH-312 ke Ready for review beserta ringkasan perubahan, output tes yang lulus, dan satu batasan yang dicatat: counter-nya bersifat in-process, tidak dibagi antar instance.
Anda membuka Task-nya, bukan lima belas tab. Buktinya ada di sana, dan catatan batasan itu justru bagian yang berguna: tesnya lulus, tapi state bersama antar instance adalah keputusan desain yang harus Anda ambil. Anda meninggalkan komentar dan memindahkannya ke Changes requested. Komentar itu memulai run lanjutan pada Task yang sama; Agent mengalihkan counter ke penyimpanan bersama dan mengembalikan bukti yang diperbarui. Kali ini Anda menerimanya. Memindahkan SH-312 ke Done adalah keputusan Anda, tercatat sebagai perubahan status dengan nama Anda di dalamnya, bukan efek samping senyap dari sebuah merge git.
Sementara itu, dua Agent lainnya berada di Ready for review. Karena antreannya berupa kolom dan bukan kotak masuk Anda, Anda menyelesaikannya berikutnya, secara berurutan, tanpa kehilangan alurnya.
Batas yang tetap dijaga untuk manusia
Agen paralel adalah kisah tentang throughput sampai review menjadi kendalanya, dan setelah itu ia menjadi kisah tentang antrean. Tim yang benar-benar mendapat manfaat dari banyak agen memperlakukan review sebagai infrastruktur yang dirancang: status yang eksplisit, gate yang bisa dicapai agen tapi tidak bisa dilewati, bukti pada Task, pemeriksaan mesin sebelum pemeriksaan manusia, dan batas atas berapa banyak pekerjaan yang boleh berjalan sekaligus.
Anda bisa membangunnya sendiri dengan worktree, konvensi penamaan branch, dan disiplin. Atau Anda bisa membiarkan Sharkly mengelola alur kerjanya: Agent yang bisa ditugaskan, Task yang membawa run beserta buktinya, dan sebuah board tempat Ready for review menjadi kolom yang Anda kosongkan, sehingga agen meneliti, mengeksekusi, menguji, dan melaporkan sementara manusia tetap memegang keputusan terakhir. Jika Anda sudah menjalankan beberapa agen, ini satu tempat untuk mengelola tugas dan hasilnya, alih-alih mengandalkan ingatan.
FAQ
Apakah menjalankan agen secara paralel menghemat waktu jika review-nya serial? Hanya sampai titik ketika run yang selesai datang lebih cepat daripada kemampuan Anda menerimanya. Setelah titik itu, agen tambahan hanya memperbesar antrean review tanpa mempercepat rilis apa pun. Manfaatnya datang dari membuat review terlihat dan hanya memberi gate pada hal yang memang membutuhkan manusia.
Apakah setiap perubahan dari agen perlu di-review manusia? Tidak. Beri gate pada perubahan yang sampai ke pengguna atau menyentuh auth, data, uang, atau API publik. Biarkan pekerjaan berisiko rendah atau yang bisa digenerate ulang lolos hanya dengan pemeriksaan mesin. Memberi gate pada semuanya hanya memindahkan hambatan kembali ke reviewer untuk perubahan yang tidak pernah membutuhkannya.
Bukankah merge PR sama dengan menerima pekerjaannya? Tidak. Merge adalah operasi git; penerimaan adalah saat seseorang memutuskan bahwa perubahan tersebut memenuhi kriteria Task. Menjaga keduanya tetap terpisah mempertahankan kualitas review saat volumenya tinggi. Lihat human-in-the-loop coding agents untuk tahu di mana keputusan manusia sebaiknya dipertahankan.
