Anda mulai dengan satu terminal dan Claude Code. Lalu datang tugas kedua, jadi Anda membuka terminal kedua dan menjalankan Codex di sana. Perbaikan frontend masuk ke terminal ketiga. Sekarang Anda bolak-balik alt-tab di antara tiga jendela, berusaha mengingat mana yang sedang menunggu Anda, mana yang tadi bertanya sepuluh menit lalu, dan mana yang diam-diam sudah selesai dan menganggur sementara Anda membuang perhatian ke dua lainnya. Tidak ada yang sedang kacau. Tapi Anda telah menjadi pihak yang mengarahkan pekerjaan di antara para agen, dan pekerjaan itu skalanya jauh lebih buruk daripada agen mana pun.
Terminalnya bukan biayanya. Anda yang jadi biayanya. Saat agen dijalankan secara manual, setiap keputusan tentang apa yang terjadi selanjutnya hanya ada di satu tempat: kepala Anda. Agen mana yang mendapat tugas berikutnya, apakah diff terakhir aman, apa yang gagal saat Anda sedang membaca jendela lain. Koordinasi itu adalah kerja nyata, tidak dibayar, dan tumbuh lebih cepat daripada jumlah agen yang Anda tambahkan.
Artikel ini menguraikan berapa biaya sebenarnya menjalankan agen coding secara manual, di mana tagihannya tersembunyi sampai akhirnya menumpuk, dan alur kerja yang menghilangkan sebagian besar biaya itu. Sharkly adalah lapisan manajemen yang berada di atas agen Anda: Anda tetap memakai Claude Code, Codex, atau runtime apa pun yang sudah Anda gunakan, dan Sharkly menyimpan tugas, isolasi, serta review di satu tempat bersama, bukan tersebar di sepanjang dinding terminal.
TL;DR
Menjalankan agen coding secara manual tampak gratis karena tidak ada alat yang menagih untuk itu. Biaya sebenarnya adalah perhatian Anda: Anda menjadi penghubung antar agen, memori tentang apa yang sedang dilakukan masing-masing, dan satu-satunya peninjau yang harus mengejar setiap jendela. Biaya itu tetap kecil pada dua atau tiga agen dan menumpuk setelah lewat lima. Anda bisa terus melakukannya secara manual, atau mengarahkan agen yang sudah ada melalui lapisan tugas seperti Sharkly yang menugaskan pekerjaan, mengisolasi setiap proses, dan mengembalikan setiap hasil ke sebuah Task untuk ditinjau.
Masalahnya bukan terminalnya, melainkan Anda
Ini definisi yang layak diingat: terminal adalah tempat agen berjalan; task adalah pekerjaan yang dijalankannya. Saat Anda mengelola agen secara manual, tidak ada yang menghubungkan keduanya kecuali Anda. Terminal menampilkan output. Terminal tidak tahu apa task-nya, apakah sudah selesai, atau siapa yang memutuskan apa yang terjadi selanjutnya. Anda menyediakan semua itu dari ingatan, satu jendela demi satu jendela.
Itulah sebabnya "terlalu banyak terminal" hanyalah gejala, bukan penyakitnya. Memecah satu agen ke lima panel dengan tmux tidak mengurangi koordinasi; itu hanya menatanya. Anda tetap memegang peta tentang panel mana yang memiliki task mana, mana yang sedang berjalan, dan mana yang sudah selesai dan butuh dilihat manusia. Peta itu tidak berada di tempat bersama, jadi begitu Anda menjauh, peta itu jadi usang, dan begitu rekan setim membutuhkannya, peta itu tidak ada.
Berapa biaya sebenarnya menjalankan agen secara manual
Tagihannya dibayar dengan perhatian, dan perhatian punya harga yang terukur. Saat Anda berpindah antara tugas yang tidak berkaitan, Anda tidak langsung kembali fokus. Riset tentang pekerjaan pengetahuan yang terganggu oleh Gloria Mark dan rekan-rekannya, yang diterbitkan di CHI 2008, menemukan bahwa orang rata-rata butuh lebih dari dua puluh menit untuk kembali ke tugas yang terganggu setelah ditarik perhatiannya. Ringkasan riset perpindahan tugas dari American Psychological Association menyebut kehilangan produktivitas akibat berpindah antar tugas bisa mencapai 40 persen. Setiap kali seorang agen selesai dan Anda berpaling ke jendela lain, Anda membayar versi tertentu dari pajak itu.
Menjalankan agen secara manual mengubah perpindahan itu menjadi lingkaran utama Anda. Inilah tempat biaya menumpuk:
| Biaya tersembunyi | Bentuknya saat manual | Mengapa menumpuk |
|---|---|---|
| Routing | Anda memutuskan agen mana yang mendapat setiap tugas baru, dari ingatan | Makin banyak agen berarti makin banyak pasangan yang harus diingat |
| Muat ulang konteks | Anda membaca ulang tiap terminal untuk mengingat apa yang sedang dikerjakannya | Setiap perpindahan mengulang jam untuk masuk kembali ke tugas itu |
| Pergeseran status | Tiap terminal membawa branch, env, dan editan setengah jadi sendiri | Dua tugas di satu direktori diam-diam saling merusak |
| Tumpukan review | Hanya Anda yang melihat setiap proses berjalan | Pekerjaan yang selesai menunggu satu-satunya orang yang bisa meninjau |
| Tidak ada catatan bersama | Statusnya hidup di sesi Anda, bukan di tempat yang bisa dilihat rekan setim | Menjauh sebentar dan kemajuan jadi tak terlihat; tak ada yang bisa melanjutkannya |
Tidak satu pun dari ini muncul sebagai crash. Semuanya muncul sebagai hari yang terasa sibuk dan menghasilkan tiga PR yang di-merge, bukan delapan, tanpa satu momen pun yang bisa Anda tunjuk sebagai masalahnya.
Mode kegagalan tersembunyi sampai menumpuk
Pada dua agen, Anda bisa menampung seluruh peta di memori kerja dan biayanya hampir nol. Ini layak dikatakan terus terang, karena di sinilah banyak saran melebih-lebihkan masalahnya: jika Anda menjalankan satu atau dua agen di satu mesin dan meninjau masing-masing sebelum memulai yang berikutnya, Anda belum butuh lapisan manajemen. Jaga agar bagian yang bergerak tetap nol.
Persamaannya berubah saat pekerjaan tumpang tindih dalam waktu atau status. Jalankan tiga agen di checkout yang sama dan Anda kena masalah isolasi yang dibahas di beberapa agen coding di repositori yang sama: dua agen menyentuh file yang sama, dan satu diam-diam menimpa yang lain. Atasi itu dengan worktree per tugas, disiplin dalam coding agent worktrees, dan Anda menukar masalah merge dengan masalah pembukuan: direktori mana memetakan ke tugas mana, mana yang aman dihapus, mana yang sedang ditinjau manusia. Atasi itu dengan lebih banyak terminal dan Anda kembali ke titik awal, hanya dengan lebih banyak jendela.
Biaya terakhir adalah yang paling sunyi. Saat setiap proses berjalan di terminal privat, pekerjaan yang selesai tidak punya tempat lain untuk pergi selain perhatian Anda. Review menjadi penghambat, karena Anda satu-satunya orang yang menyaksikan agen bekerja dan satu-satunya yang bisa menilai apakah diff-nya bagus. Agen paralel tidak membantu jika meninjau output mereka harus diserialkan pada satu manusia. Itulah jebakan yang dijelaskan di mengapa agen coding terbaik kalah penting dibanding cara Anda mengelolanya: modelnya jadi lebih cepat, tapi antrean review Anda tidak.
Apa yang dihilangkan oleh lapisan manajemen
Papan tugas menghilangkan bagian yang tadinya Anda kerjakan secara manual: menjadi jaringan penghubung antara agen dan pekerjaan. Di Sharkly, Task adalah unit yang memiliki proses berjalannya. Anda menugaskan sebuah Task ke sebuah Agen, dan Sharkly menyiapkan worktree terisolasi untuknya di Computer yang terhubung, menjalankan sesi agen di sana, lalu mengembalikan diff, log, dan hambatan apa pun ke Task tersebut. Routing, isolasi, dan catatan yang tadinya Anda pegang di kepala kini menjadi properti dari Task.
Itu menjaga pembagian kerja tetap rapi. Agen meneliti, mengeksekusi, menguji, dan melapor; manusia menetapkan arah, memberi wewenang, dan menerima hasilnya. Sharkly bukan pengganti Claude Code, Codex, atau runtime yang sudah Anda gunakan; semuanya yang melakukan eksekusi. Sharkly menambahkan task bersama, Computer yang terhubung, dan lapisan review di sekitarnya, sehingga konteks, kemajuan, hambatan, hasil, dan review manusia tetap terlihat dari permintaan sampai rilis, bukan tersebar di lima sesi yang hanya bisa Anda lihat. Saat Anda perlu memantau beberapa proses berjalan sekaligus, itulah fungsi sebenarnya sebuah dashboard agen, dan itulah sebabnya tim akhirnya menginginkan lapisan di atas Claude Code dan Codex ketimbang terminal lain.
Jika Anda sudah menjalankan beberapa agen, itulah alur kerja yang menjadi dasar Sharkly dibangun. Anda bisa terus mengarahkan secara manual di antara terminal, atau menjalankan agen coding yang ada melalui Sharkly dan biarkan papan itu yang menyimpan petanya.
Kapan cara manual baik-baik saja, dan kapan tidak
Aturan keputusan yang jujur itu singkat:
- Jalankan agen secara manual ketika Anda punya satu atau dua, di satu mesin, dan Anda meninjau masing-masing sebelum yang berikutnya dimulai. Overhead alat apa pun belum sepadan.
- Beralih ke lapisan tugas ketika agen ketiga mulai bermunculan, pekerjaan mencakup lebih dari satu repositori, atau orang selain Anda perlu melihat apa yang sedang berjalan. Itulah titik ketika biaya koordinasi tak lagi muat di kepala satu orang.
Sinyalnya bukan jumlah terminal. Sinyalnya adalah momen ketika Anda mendapati diri bertanya, "tunggu, itu tadi di jendela mana?" Pertanyaan itu adalah pajak koordinasi yang muncul sebagai kalimat, dan itu juga kekacauan agen yang ingin diakhiri oleh papan tugas.
FAQ
Bukankah tmux atau terminal multiplexer sudah cukup? Itu menata jendela; bukan menghilangkan koordinasinya. Anda tetap memegang panel mana yang memiliki tugas mana, apa yang sudah selesai, dan siapa yang meninjaunya. Multiplexer menyelesaikan soal ruang layar. Biaya menjalankan agen secara manual adalah perhatian, bukan piksel.
Berapa banyak agen yang bisa saya jalankan secara manual sebelum terasa menyakitkan? Kebanyakan orang baik-baik saja pada satu atau dua dan mulai merasakannya sekitar tiga sampai lima, terutama di lebih dari satu repositori. Jumlah pastinya bergantung pada berapa lama tiap tugas berjalan dan seberapa banyak review yang dibutuhkan. Tandanya adalah ketika routing dan membaca ulang jendela menyita lebih banyak waktu harian Anda daripada review itu sendiri.
Apakah papan tugas membuat agen saya lebih cepat? Tidak, dan Sharkly tidak mengklaim demikian. Agen berjalan dengan kecepatan yang sama. Yang berubah adalah overhead Anda: routing, isolasi, dan review tidak lagi hidup di kepala Anda dan mulai kembali ke sebuah Task di mana pekerjaannya terlihat dan bisa ditinjau.
Bagaimana dengan menjaga konteks antar sesi? Terminal privat kehilangannya begitu Anda menutupnya. Mengikat sebuah proses ke sebuah Task menjaga tujuan, diff, dan diskusinya tetap bersama, yang merupakan masalah menjaga konteks antar sesi yang diselesaikan di tingkat catatan, bukan lewat ingatan.
Bisakah saya tetap memakai Claude Code dan Codex bersama dengan cara ini? Bisa. Sharkly mengelola pekerjaan di sekitar alat-alat itu; bukan menggantikannya. Lihat cara menjalankan Claude Code dan Codex bersama di satu codebase untuk polanya.
