Pagi ini Anda menjalankan tiga coding agent. Satu sedang merefaktor modul autentikasi, satu sedang menulis pengujian, dan satu lagi sedang menelusuri flaky CI job. Satu jam kemudian, Anda mendapati lima terminal terbuka, dua panel tmux yang terlepas (detached), dan rasa cemas bahwa setidaknya salah satu dari mereka sudah berhenti sejak tadi dan menganggur tanpa Anda sadari. Anda menekan alt-tab, menggulir log, lalu menebak-nebak.
Tebak-tebakan itulah kerugian nyata dari menjalankan agent secara paralel. Menjalankan beberapa coding agent sekaligus kini memang mudah. Namun, mengetahui agent mana yang membutuhkan bantuan Anda, mana yang macet, dan mana yang sudah selesai diam-diam adalah bagian yang menguras waktu sepanjang sore. Memantau coding agent yang berjalan paralel berarti menjawab empat pertanyaan langsung tanpa harus membuka lima jendela: apa yang sedang dikerjakan setiap agent, sudah sejauh mana perkembangannya, apa yang menghambatnya, dan hasil apa yang siap untuk ditinjau.
Panduan ini mula-mula mengulas konfigurasi pemantauan mandiri (DIY), mengidentifikasi potensi kegagalan di setiap langkahnya, lalu menunjukkan titik di mana konfigurasi tersebut tidak lagi memadai dan apa keunggulan yang dihadirkan oleh shared task layer (lapisan tugas bersama). Shared layer tersebut adalah Sharkly: Anda sudah memiliki coding agent, dan Sharkly menyatukannya menjadi sebuah tim dengan menampilkan progres, hambatan, serta hasil dari setiap agent di satu tempat terpusat—alih-alih tersebar di berbagai terminal. Anda sebenarnya bisa membangun sebagian besar pemantauan ini secara manual. Tujuan membandingkan keduanya adalah agar Anda tahu persis kapan metode manual mulai memakan lebih banyak biaya dan waktu daripada manfaat yang diberikannya.
Empat sinyal penting yang wajib dipantau
Pemantauan bukanlah proses tunggal yang sederhana. Ketika seseorang mengatakan kinerja sebuah agent "tampak baik-baik saja", biasanya yang mereka maksud adalah salah satu dari empat sinyal berbeda, dan masing-masing memiliki pola kegagalan tersendiri.
- Status (State). Apakah prosesnya sedang berjalan, menunggu input, sudah selesai, atau mati? Agent yang sudah selesai dan agent yang mengalami hang sama-sama tidak menghasilkan output baru, jadi ketiadaan log baru tidak memberi tahu Anda apa pun.
- Progres. Seberapa banyak tugas yang sudah selesai? Rencana kerja yang sudah dicentang, berkas yang diubah, pengujian yang lolos. Progres inilah yang memastikan bahwa agent yang sedang berjalan benar-benar membuat kemajuan dan tidak terjebak dalam perulangan (looping).
- Hambatan (Blockers). Apa yang sedang ditunggu oleh agent? Permintaan izin (permission prompt), variabel lingkungan (environment variable) yang belum disetel, konflik merge, atau pertanyaan yang belum dijawab oleh siapa pun.
- Output yang memerlukan peninjauan. Apa yang telah dihasilkan agent yang sekarang harus disetujui atau ditolak oleh manusia? Sebuah diff, PR, atau ringkasan perubahan.
Jika Anda hanya memantau status, Anda akan melewatkan agent yang aktif namun terjebak dalam siklus coba lagi (retry loop). Jika hanya memantau progres, Anda akan melewatkan agent yang sebenarnya sudah selesai dua puluh menit lalu. Sistem pemantauan yang baik harus menyajikan keempat sinyal tersebut untuk setiap agent dalam sekilas pandang.
Langkah 1: Memantau secara mandiri (DIY), dan celah di setiap langkahnya
Metode manual memanfaatkan alat-alat yang sudah Anda miliki. Berikut gambaran jujurnya, lengkap dengan celah yang tersisa di setiap langkah.
Melihat apa yang sedang berjalan. Jika setiap agent berjalan di dalam git worktree miliknya sendiri, tampilkan daftar worktree dan cabangnya:
git worktree list
tmux ls # if each agent runs in a tmux session
Failure mode: Perintah ini hanya memberi tahu bahwa sebuah sesi aktif, bukan apakah agent di dalamnya sedang bekerja atau justru sedang menunggu. Panel tmux yang terhenti pada konfirmasi Continue? (y/n) terlihat persis sama dengan panel yang sedang sibuk mengeksekusi tugas. Anda baru mengetahuinya setelah masuk (attach) ke sesi tersebut.
Memantau progres. Lakukan tail pada output setiap agent dan pantau perubahan pada worktree-nya secara berkala (polling):
tail -f /path/to/agent-1.log
watch -n 5 'git -C ../wt-auth status --short'
Failure mode: Pendekatan ini membebani Anda seiring bertambahnya jumlah agent. Tiga log mungkin masih terbaca. Namun enam log tail yang berjalan bersamaan akan sangat membingungkan, dan perintah watch hanya memperlihatkan riwayat perubahan berkas, bukan esensi pekerjaannya. Anda bisa melihat berkas terus berubah tanpa tahu apakah perubahannya sudah benar atau agent tersebut hanya mengulang proses yang sama.
Mengetahui kapan tugas selesai. Bungkus perintah agent agar mengirim notifikasi saat prosesnya selesai:
your-agent-command "$TASK"; \
curl -s -X POST "$WEBHOOK_URL" -d "agent-1 exited $?"
Failure mode: Kode keluar (exit code) 0 hanya menandakan proses telah berakhir, bukan berarti hasilnya bagus atau bahkan tugasnya selesai. Banyak agent keluar dengan bersih setelah mengajukan pertanyaan yang tidak pernah Anda lihat. Notifikasi "selesai" semacam ini membuat Anda keliru mempercayai sinyal yang sebenarnya belum tentu tuntas.
Mendeteksi konflik. Ketika beberapa agent berbagi satu repositori yang sama, worktree memang memisahkan direktori kerja mereka, tetapi dua agent yang mengedit berkas yang sama di dua branch berbeda tetap akan bertabrakan saat proses merge.
git worktree list --porcelain | grep branch
Failure mode: Anda baru menyadari adanya tumpang tindih saat mencoba melakukan merge—saat di mana biaya dan upaya untuk memperbaikinya justru paling besar.
Semua cara di atas tidaklah salah. Untuk dua atau tiga agent yang menangani tugas terpisah tanpa keterkaitan, beberapa panel tmux dan perulangan watch sudah sangat cukup sebagai pemantau, dan Anda belum memerlukan solusi yang lebih rumit. Pertahankan seminimal mungkin komponen tambahan sampai Anda benar-benar merasakan batas kemampuannya.
Titik di mana pemantauan DIY tidak lagi efektif
Keterbatasan ini mulai terasa saat jumlah agent yang berjalan sudah tidak muat lagi dalam satu layar. Tiga masalah berikut akan saling menumpuk:
Polling hanya menunjukkan status, bukan penyebab. git status dan log tail hanya memperlihatkan ada perubahan atau output terhenti. Keduanya tidak bisa memberi tahu apakah agent terhambat oleh permintaan konfirmasi, dependensi yang hilang, atau sudah selesai. Ujung-ujungnya, Anda harus memeriksa sesi satu per satu untuk mencari tahu—persis kebiasaan bolak-balik terminal yang seharusnya dihilangkan oleh eksekusi paralel.
Tidak ada status bersama (shared state). Pemantauan Anda tersimpan di laptop, di server tmux, atau di riwayat shell Anda. Rekan tim tidak bisa melihat agent mana yang menangani tugas tertentu, begitu pula Anda setelah menutup laptop. Dan saat agent berjalan di mesin remote, pendekatan local tail sama sekali tidak bisa diandalkan.
Peninjauan menjadi bottleneck. Hal inilah yang sering diremehkan. Menjalankan agent secara paralel tidak ada gunanya jika proses peninjauan hasilnya kembali menumpuk dalam satu antrean berurutan. Lima diff yang selesai tanpa tempat terpusat untuk melacak status "sudah ditinjau / diminta revisi / sudah di-merge" hanya akan berujung pada lima tab peramban dan catatan di kepala Anda. Kinerja agent semakin cepat, tetapi manusia yang memeriksanya justru kewalahan.
Pada tahap tersebut, masalahnya bukan kekurangan jendela terminal, melainkan ketiadaan pencatatan bersama (shared record).
Nilai tambah papan tugas: semua hasil bermuara di satu tempat
Lapisan tugas (task layer) mengubah unit pemantauan dari sekadar "sebuah proses di dalam panel" menjadi "sebuah Task dengan status yang jelas". Transformasi inilah yang menjadi fondasi Sharkly, yang selaras langsung dengan keempat sinyal pemantauan tadi.
Setiap eksekusi agent terhubung ke sebuah Task. Status, progres, hambatan, dan hasil kerja semuanya tersaji di linimasa Task tersebut, alih-alih terkubur di log yang hanya bisa Anda lihat. Daripada terus-menerus melakukan polling, Anda cukup memantau sebuah papan: Task mana yang sedang berjalan, mana yang terhambat, serta mana yang telah selesai dan menunggu tindakan Anda. Fitur Inbox di Sharkly adalah tempat berkumpulnya proses yang memerlukan intervensi manusia, sehingga fokus Anda bukan lagi menebak "apakah ada yang sudah selesai?", melainkan "inilah hal-hal yang membutuhkan keputusan saya." Agent bertugas meriset, mengeksekusi, menguji, dan melaporkan; manusia bertugas menentukan arah, memberi wewenang, dan menerima hasil akhirnya. Otomatisasi berhenti saat penilaian manusia (judgment) dibutuhkan.
Batasan ini sangat penting dipahami agar tidak salah mengira: Sharkly tidak mengeksekusi agent atau menulis kode secara langsung. Claude Code, Codex, serta runtime lain yang sudah Anda gunakan tetap menangani eksekusinya. Sharkly melengkapi alur tersebut dengan shared task, komputer, konteks, dan review layer, sehingga progres eksekusi beserta diff-nya tersimpan di tempat yang dapat diakses oleh seluruh tim, mulai dari permintaan hingga tahap rilis. Sharkly juga mengisolasi setiap proses di dalam worktree terisolasi masing-masing, sehingga konflik akibat perubahan pada berkas yang sama—yang biasanya baru ketahuan saat merge—dapat diantisipasi di setiap Task.
Panduan praktisnya: jika Anda hanya menjalankan satu atau dua agent untuk tugas yang tidak saling berhubungan dan tidak pernah menyerahkan hasilnya ke orang lain, pemantauan DIY sudah lebih dari cukup dan Sharkly justru akan menjadi beban tambahan. Namun situasinya berbalik ketika jumlah agent melampaui kapasitas layar Anda, saat tugas berjalan di mesin jarak jauh, atau ketika anggota tim lain perlu memantau papan yang sama. Jika Anda ingin tetap leluasa menggunakan berbagai coding agent tanpa terikat pada satu ekosistem tertentu, visibilitas bersama itulah masalah utama yang diselesaikan oleh Sharkly. Untuk gambaran lebih lengkap mengenai apa saja yang perlu ditampilkan pada papan tersebut, simak apa yang sebenarnya perlu ditampilkan oleh dasbor AI coding agent.
Daftar periksa pemantauan yang bisa Anda terapkan hari ini
Baik Anda tetap menggunakan metode manual maupun beralih ke shared layer, sistem pemantauan parallel-agent harus mampu menjawab hal-hal berikut tanpa mengharuskan Anda masuk ke sesi terminal mana pun:
- Setiap agent dipetakan ke tugas bernama jelas. Tidak ada lagi penamaan anonim seperti “agent-3”. Anda harus dapat mengetahui dengan pasti tujuan dari masing-masing agent.
- Status terlihat jelas dalam sekilas pandang. Apakah sedang berjalan, menunggu input, selesai, atau gagal—semuanya terbedakan dengan gamblang, bukan ditebak dari keheningan log.
- Agent yang terhambat segera memberi tanda. Konfirmasi yang menunggu input
y/n, secret yang hilang, atau pertanyaan yang belum terjawab langsung dimunculkan ke hadapan Anda, bukan berhenti diam-diam. - Penyelesaian berarti siap ditinjau, bukan sekadar proses keluar. Eksekusi yang selesai harus mengarah ke sebuah diff atau PR, bukan sekadar exit code.
- Proses peninjauan memiliki statusnya sendiri. Status seperti sudah ditinjau, revisi diminta, dan berhasil di-merge harus terlacak, sehingga pekerjaan paralel tidak kembali menumpuk menjadi antrean tinjauan satu per satu.
- Tampilan tetap tersimpan saat laptop ditutup dan dapat dibagikan. Informasi status tersimpan di tempat lain, bukan sekadar riwayat shell lokal Anda.
- Pekerjaan di repositori yang sama terisolasi dengan rapi. Setiap agent memiliki worktree tersendiri, dan tumpang tindih berkas dapat terdeteksi sebelum merge, bukan saat merge berlangsung.
Evaluasi konfigurasi Anda saat ini menggunakan daftar periksa di atas. Poin-poin yang belum bisa Anda centang hari ini adalah celah yang berpotensi membuang waktu Anda di kemudian hari. Jika Anda sudah menjalankan beberapa agent sekaligus, Sharkly menyediakan satu tempat terpusat untuk mengelola tugas dan hasil kerja mereka. Anda juga dapat menjalankan coding agent yang sudah Anda miliki melalui Sharkly tanpa perlu meninggalkan runtime yang biasa Anda gunakan.
