Anda menjalankan tiga coding agent untuk tiga tugas, lalu menghabiskan dua puluh menit berikutnya berpindah-pindah tab terminal demi menjawab satu pertanyaan: mana yang membutuhkan saya sekarang? Satu masih berjalan. Satu menunggu jawaban y/n yang tidak pernah Anda lihat. Satu lagi selesai dengan status hijau sejam lalu dan diam-diam mengerjakan hal yang salah. Tidak ada apa pun yang memberi tahu Anda soal itu. Anda harus mencarinya sendiri.
Kesenjangan itulah yang seharusnya ditutup oleh observabilitas coding agent. Observabilitas, yang dipinjam dari rekayasa sistem, adalah kemampuan memahami apa yang sedang dilakukan sebuah proses yang berjalan dari sinyal-sinyal yang dipancarkannya, tanpa harus menempel langsung ke proses tersebut (OpenTelemetry punya primer yang bagus). Untuk coding agent, standarnya begini: Anda harus bisa menjawab "apa yang sedang dilakukan setiap agent, apa yang gagal, dan apa yang butuh campur tangan manusia" dari satu tampilan bersama, bukan dari menguntit satu sesi. Sebagian besar setup tidak bisa. Mereka punya status di suatu tempat dan log di tempat lain, lalu menyebutnya observabilitas. Bukan begitu.
Artikel ini membahas tiga sinyal yang benar-benar dipancarkan coding agent, sinyal kegagalan mana yang layak dipasangi alert, dan di mana lapisan tugas bersama seperti Sharkly mengubah output mentah menjadi sesuatu yang bisa Anda tindak lanjuti. Sharkly berada di atas agent yang sudah Anda jalankan; Anda sudah punya coding agent, dan intinya di sini adalah membuat pekerjaan mereka mudah dibaca ketika jumlahnya lebih dari satu.
Status, log, dan sinyal kegagalan adalah tiga hal yang berbeda
Ketiga istilah ini sering dipakai bergantian, dan kebingungan inilah akar dari sebagian besar setup monitoring yang buruk. Ketiganya menjawab pertanyaan yang berbeda.
Status adalah ringkasan keadaan sebuah run. Running, menunggu input, selesai, atau gagal. Ia hanya satu field, murah dibaca, dan hanya memberi tahu di mana sebuah run berada, bukan apa yang dilakukannya. Status bukan observabilitas; ia hanyalah fakta terkecil tentang sebuah run.
Log adalah jejak eksekusi mentah. Setiap pemanggilan tool, pengubahan file, dan respons model, berurutan. Log memberi tahu apa yang terjadi setelah Anda sudah tahu ada sesuatu yang gagal. Log sangat diperlukan untuk post-mortem dan tidak berguna sebagai sinyal langsung, karena tidak ada yang mengawasi lima log yang bergulir sekaligus. Log bukan sinyal sampai ada sesuatu yang mengekstraksi makna darinya.
Sinyal kegagalan adalah alert turunan. Ia adalah kondisi spesifik yang layak mengganggu Anda: agent berhenti bergerak, sebuah run selesai hijau ke arah yang salah, anggaran habis di tengah tugas. Sinyal kegagalan adalah hal yang sebenarnya Anda inginkan, dan itulah lapisan yang dilewati hampir semua setup rakitan sendiri, karena menurunkannya berarti memproses log menjadi event, bukan sekadar menyimpannya.
Jebakannya adalah berhenti di dua lapisan pertama. Status plus log terasa seperti observabilitas karena Anda punya state dan catatan. Tapi satu-satunya pertanyaan yang tetap masuk akal saat skala membesar, "agent saya yang mana yang membutuhkan saya?", sepenuhnya hidup di lapisan ketiga.
Sinyal kegagalan yang benar-benar penting
Observabilitas layanan web mengawasi crash dan latensi. Coding agent gagal dengan cara berbeda, dan kegagalan yang menghabiskan waktu seharian Anda jarang yang muncul sebagai status merah. Inilah sinyal-sinyal yang layak diturunkan.
| Sinyal | Artinya | Kenapa status dan log melewatkannya |
|---|---|---|
| Stall senyap | Agent menunggu prompt atau secret yang hilang, tanpa menghasilkan output | Status masih terbaca "running"; tidak ada yang mengangkat tangan |
| Hijau tapi salah | Run selesai dengan sukses tapi mengerjakan hal yang salah | Status "done"; hanya dengan membaca diff baru terlihat |
| Verifikasi yang dilewati | Melaporkan selesai tanpa menjalankan typecheck, tes, atau build | Log memuat kelalaian itu, tapi tidak ada yang membaca log yang lolos |
| Anggaran habis | Kuota model atau batas pengeluaran tercapai di tengah tugas | Kegagalan muncul sebagai respons yang terpotong, bukan alert |
| Konflik laten | Dua agent mengubah file yang sama di worktree terpisah | Kedua run "done"; benturannya menunggu di tahap merge |
| Thrash | Agent mengubah, membatalkan, dan mengubah lagi file yang sama dalam loop | Setiap langkah individual terlihat baik-baik saja di log |
Polanya di keenam sinyal ini: kegagalan tak terlihat di lapisan status dan terkubur di lapisan log. "Hijau tapi salah" adalah yang paling diremehkan orang. Coding agent yang dengan percaya diri menyelesaikan tugas yang salah terlihat identik dengan yang berhasil menyelesaikannya dengan benar, sampai review dengan bukti tingkat tugas menangkapnya. Observabilitas yang hanya melaporkan exit code akan melaporkan kegagalan itu sebagai kesuksesan.
Dua di antaranya bersifat struktural, bukan perilaku. Konflik laten adalah alasan mengapa kerja paralel di repo yang sama membutuhkan worktree terisolasi per tugas, agar tumpang tindih file muncul sebelum merge, bukan saat merge. Anggaran yang habis adalah alasan mengapa melacak pengeluaran lintas agent harus ada di tampilan yang sama dengan status; run yang diam-diam berhenti karena kehabisan kuota adalah sinyal kegagalan, bukan tugas yang selesai.
Seberapa banyak observabilitas yang Anda butuhkan, berdasarkan ukuran tim
Anda tidak perlu keenam sinyal itu di hari pertama. Jumlah instrumentasi yang tepat berskala seiring berapa banyak agent yang berjalan dan berapa banyak orang yang perlu melihatnya.
| Setup | Apa yang perlu diinstrumentasi | Di mana ia jebol |
|---|---|---|
| Satu agent, satu tugas | Status saja; baca log kalau gagal | Tidak ada, sampai Anda menjalankan agent kedua |
| Beberapa agent solo | Status per run plus sinyal stall dan hijau-tapi-salah | Anda menyimpulkan state dari keheningan dan melewatkan stall |
| Tim kecil, repo bersama | Keenam sinyal, plus status review, dalam satu tampilan bersama | Monitoring Anda hidup di satu laptop yang tidak bisa dilihat orang lain |
| Tim lebih besar, banyak repo | Semua di atas plus kepemilikan per run, anggaran, dan jejak audit | Tidak ada yang bisa menjawab "siapa menjalankan apa" seminggu kemudian |
Bacaan jujurnya: developer solo yang menjalankan satu agent untuk pekerjaan yang tidak berkaitan sudah punya semua observabilitas yang dibutuhkan di satu terminal. Persamaannya berubah begitu jumlah agent melebihi jumlah layar Anda, pekerjaan berjalan di mesin yang tidak Anda duduki, atau orang lain perlu melihat board yang sama. Setelah garis itu, satu field status dan satu direktori log tidak lagi cukup.
Kapan log mentah dan satu runtime sudah cukup
Berikan versi terbaik dari alat bawaan, karena untuk banyak pekerjaan, alat-alat itu menang. Claude Code dan Codex sama-sama menyimpan jejak sesi yang mudah dibaca, dan untuk satu agent pada satu tugas, jejak itu adalah observabilitas Anda. Anda yang memulainya, Anda yang mengawasinya, Anda akan membaca log kalau ia berhenti. Menambahkan lapisan manajemen di situ murni overhead.
Gunakan output runtime itu sendiri ketika Anda menjalankan satu atau dua agent, untuk pekerjaan yang tidak berkaitan, yang tidak pernah diserahkan ke orang lain. Barulah beralih ke lapisan observabilitas bersama ketika jumlah run melebihi perhatian Anda, ketika run dijalankan di tempat yang tidak bisa Anda pantau, atau ketika review harus menjadi aktivitas tim alih-alih aktivitas pribadi. Kasus terakhir ini adalah pembunuh diam-diam: lima agent selesai secara paralel bukanlah kemenangan kalau me-review diff mereka malah menyerialkan kembali menjadi antrean satu manusia. Agent-nya makin cepat; Anda makin lambat. Itu juga masalah observabilitas, dan tidak ada satu runtime pun yang bisa menyelesaikannya, karena sinyal yang penting, "run ini sudah selesai dan menunggu review Anda", hidup lintas agent, bukan di dalam satu agent.
Observabilitas ketika hasil kembali ke Task
Lapisan tugas mengubah unit observabilitas dari "sebuah proses di sebuah pane" menjadi "sebuah Task dengan state." Inilah pergeseran yang menjadi dasar Sharkly dibangun, dan ia memetakan ketiga sinyal sekaligus.
Setiap run agent terhubung ke sebuah Task. Status, progres, penghambat, dan hasil kembali ke timeline Task tersebut alih-alih hidup di log yang hanya bisa Anda lihat. Sinyal kegagalan muncul di satu tempat: run yang butuh manusia masuk ke Inbox, sehingga pertanyaannya berhenti menjadi "ada yang selesai tidak?" dan berubah menjadi "inilah yang butuh keputusan saya." Agent meneliti, mengeksekusi, menguji, dan melaporkan; manusia menetapkan arah, memberi otoritas, dan menerima hasilnya. Otomasi berhenti di titik yang membutuhkan pertimbangan tim.
Batas ini penting, karena mudah salah berasumsi. Sharkly tidak menjalankan agent atau menulis kode. Claude Code, Codex, dan runtime lain yang sudah Anda gunakan tetap yang melakukan eksekusi. Sharkly menambahkan lapisan tugas bersama, Computer, konteks, dan review di sekitarnya, sehingga konteks, progres, penghambat, hasil, dan review manusia tetap terlihat dari permintaan sampai rilis. Untuk gambaran lebih lengkap tentang apa yang harus ditampilkan board bersama itu, lihat apa yang sebenarnya dibutuhkan dashboard coding agent AI, dan untuk sudut pemantauan langsung, cara memantau coding agent yang berjalan paralel.
Jika Anda ingin tetap memakai beberapa coding agent alih-alih berkomitmen pada satu ekosistem, tampilan bersama yang mengutamakan sinyal itulah masalah yang dirancang untuk dipecahkan Sharkly. Anda bisa menjalankan coding agent yang sudah ada melalui Sharkly dan tetap memakai setiap runtime yang sudah Anda gunakan.
FAQ
Apakah observabilitas coding agent sama dengan logging? Tidak. Logging menyimpan apa yang terjadi. Observabilitas adalah kemampuan menjawab apa yang sedang dilakukan setiap agent, apa yang gagal, dan apa yang membutuhkan Anda, tanpa membaca log-log itu satu per satu. Log hanyalah salah satu input untuk observabilitas, bukan keseluruhannya.
Apa sinyal kegagalan paling penting yang harus diinstrumentasi lebih dulu? Stall senyap. Agent yang terbaca "running" sementara ia menunggu selamanya pada prompt yang tidak pernah Anda lihat adalah cara paling umum pekerjaan paralel mati diam-diam. Buatlah run yang terhambat mengangkat tangan sebelum Anda mengejar yang lebih canggih.
Bisakah saya mendapatkan ini dari output bawaan coding agent saya? Untuk satu agent, ya. Jejak sesi runtime itu sendiri sudah cukup. Output bawaan tidak punya tampilan lintas agent, jadi ia tidak bisa memberi tahu Anda mana dari lima run yang membutuhkan Anda, dan itulah justru pertanyaan yang muncul begitu Anda melewati skala satu agent.
