Anda menjalankan agen coding untuk tugas nyata, menutup laptop, lalu pergi makan siang. Bagian itu mudah. Bagian sulitnya adalah apa yang Anda temukan saat kembali: terminal yang isinya sudah tergulir jauh ke atas, diff yang tidak sempat Anda lihat ditulis, dan tidak ada jawaban jelas untuk satu-satunya pertanyaan yang penting, yaitu apakah hasil kerjanya cukup bagus untuk dipertahankan.
Menjalankan agen tanpa pengawasan punya dua bagian, dan sebagian besar setup hanya menyelesaikan yang pertama. Bagian pertama adalah menjaga proses tetap hidup dan produktif saat tidak ada yang mengawasi. Bagian kedua adalah antrean review: tumpukan run yang selesai, setengah selesai, dan gagal yang menunggu keputusan manusia saat Anda kembali. Lewati bagian kedua, dan agen tanpa pengawasan hanya memindahkan bottleneck dari menulis kode menjadi merekonstruksi apa yang terjadi.
Artikel ini membahas kedua bagiannya: cara menyiapkan run tanpa pengawasan sendiri, mode kegagalan di setiap langkah, dan di mana setup buatan sendiri itu berhenti berskala. Saat satu terminal menjadi lima, papan tugas seperti Sharkly berada di atas agen coding Anda. Anda tetap membiarkan Claude Code, Codex, atau Gemini CLI mengerjakan tugasnya, dan Sharkly menyimpan tugas, run, dan review di satu tempat, bukan tersebar di terminal-terminal yang sudah Anda tutup.
Apa yang sebenarnya diperlukan untuk menjalankan agen tanpa pengawasan
Run tanpa pengawasan adalah agen coding yang mengeksekusi tugas di host yang tidak Anda awasi secara aktif, dengan outputnya direkam untuk direview nanti. Definisi itu punya tiga bagian penting: tugas yang bisa diselesaikan agen tanpa Anda, host yang tetap berjalan saat Anda terputus, dan catatan yang bisa Anda baca setelahnya.

Catatan adalah bagian yang paling sering diremehkan orang. Saat Anda mengamati agen secara langsung, Andalah log-nya: Anda melihatnya memilih file yang salah, Anda menghentikannya, Anda mengoreksi arahnya. Tanpa pengawasan, semua itu tidak terjadi. Segala hal yang dilakukan agen harus tetap bertahan dalam bentuk yang bisa Anda periksa dari nol, berjam-jam kemudian, tanpa ingatan tentang apa yang Anda minta. Agen meneliti, mengeksekusi, menguji, dan melaporkan. Manusia menetapkan arah, memberi wewenang, dan menerima hasilnya. Kontrak itu hanya berlaku jika laporannya nyata dan lengkap saat Anda kembali membacanya.
Jadi tujuannya bukan "membuat agen berjalan tanpa saya." Tujuannya adalah "membuat agen berjalan tanpa saya dan menyerahkan kembali sesuatu yang bisa saya review." Itu dua masalah yang berbeda, dan yang kedua adalah titik di mana alur kerja tanpa pengawasan biasanya rusak.
Menyiapkan run tanpa pengawasan sendiri
Berikut versi manual paling minimal, beserta mode kegagalan yang mengganggu di setiap langkah.
Langkah 1: isolasi pekerjaannya. Beri run itu checkout-nya sendiri agar tidak bertabrakan dengan editor Anda atau agen lain.
git worktree add ../task-auth-refactor -b task/auth-refactor
cd ../task-auth-refactor
Mode kegagalan: lewati langkah ini dan dua run di direktori yang sama akan saling menimpa perubahan yang belum di-commit. Lihat satu checkout per tugas untuk memahami mengapa worktree, bukan sekadar branch, yang menjadi batas isolasi.
Langkah 2: lepaskan prosesnya. Sesi SSH atau terminal Anda akan tertutup, dan proses foreground akan mati bersamanya (SIGHUP). Jaga agar tetap hidup dengan nohup atau sesi tmux:
nohup claude -p "Refactor auth to use the new token service; run the tests" \
> run.log 2>&1 &
Mode kegagalan: jalankan di shell foreground biasa dan menutup laptop akan mematikan agen di tengah pengeditan banyak file, sehingga meninggalkan tree yang rusak. nohup memperbaiki masa hidupnya tapi tidak memberi Anda cara untuk masuk kembali; tmux memungkinkan Anda menyambung ulang dan melihat apa yang sedang terjadi.
Langkah 3: rekam semuanya. > run.log 2>&1 di atas bukan opsional. Itulah antrean review dalam bentuk paling mentah.
Mode kegagalan: tanpa log yang terekam, Anda tidak bisa menjawab "kenapa berhenti?" Stall senyap yang paling umum adalah agen menunggu selamanya pada prompt interaktif yang tidak akan dijawab siapa pun, karena tanpa pengawasan berarti tidak ada orang yang mengetik "yes." Jalankan dalam mode non-interaktif dan setujui terlebih dahulu kumpulan tindakan terbatas yang dibutuhkan tugas itu.
Langkah 4: batasi radius dampaknya. Putuskan, sebelum Anda pergi, apa yang boleh dilakukan agen sendiri dan apa yang membutuhkan Anda. Batasi cakupan file, larang force-push, dan jangan pernah biarkan run tanpa pengawasan melakukan merge ke branch yang dilindungi.
Mode kegagalan: run dengan izin berlebihan yang langsung push ke main bukanlah kemenangan produktivitas, melainkan sebuah insiden. Approval gate ada agar agen berhenti di titik aman terakhir dan menunggu.
Langkah 5: ketahui kapan selesai dan bagaimana hasilnya. Periksa exit code, dan kirim sinyal ke diri Anda sendiri agar tidak perlu memantau log secara manual:
claude -p "..." > run.log 2>&1; echo "exit $?" | mail -s "auth run done" [email protected]
Mode kegagalan: tanpa sinyal penyelesaian, "tanpa pengawasan" berubah menjadi "saya memeriksa terminal setiap dua puluh menit," yang sebenarnya tetap dengan pengawasan plus latensi tambahan.
Di mana setup buatan sendiri berhenti berskala
Satu agen, satu worktree, satu file log: ini berhasil, dan untuk satu run Anda tidak perlu yang lebih berat. Setup ini rusak begitu jumlahnya lebih dari satu.
Jalankan tiga agen untuk tiga tugas dan Anda kini punya tiga worktree, tiga file log, tiga exit code, dan tiga email penyelesaian yang akan salah Anda baca sekilas. Isolasinya masih tetap terjaga. Yang berantakan adalah antrean review. Tidak ada yang memberi tahu Anda run mana yang selesai dengan bersih, mana yang gagal di pengujian, dan mana yang diam-diam menunggu prompt. Anda merekonstruksinya secara manual, membaca log satu per satu, yang justru merupakan pekerjaan yang ingin Anda serahkan ke agen.
Inilah biaya sebenarnya, dan mudah terlewat karena setiap bagian terlihat baik-baik saja sendiri-sendiri. Memantau beberapa run paralel menjadi masalah nyata begitu jumlahnya melebihi yang bisa ditampilkan satu layar. File log menjawab "apa yang dicetak run ini," bukan "dari enam run saya, mana tiga yang membutuhkan saya sekarang." Sinyal status dan kegagalan yang layak direkam tidak mengatur dirinya sendiri menjadi sebuah antrean. Dan antrean itulah inti dari bekerja saat Anda pergi: Anda ingin daftar keputusan yang berperingkat, bukan direktori output mentah.
Apa yang berubah dengan papan tugas
Papan tugas adalah tempat bagian kedua dari masalah ini diselesaikan. Run tanpa pengawasan tetap terjadi di Computer yang Anda hubungkan, dengan Runtime yang sudah Anda pakai untuk mengerjakan kodenya. Yang berubah adalah ke mana hasilnya bermuara.
Di Sharkly, pekerjaan, run, dan review berada dalam satu Task. Anda menugaskan Task itu ke sebuah Agent, konfigurasi tersimpan berisi instruksi, Runtime, dan repositori, bukan prompt sekali pakai yang Anda ketik ulang. Agent mengambil Task tersebut, berjalan di worktree terisolasi, dan eksekusi, hambatan, serta hasilnya kembali ke timeline Task. Saat Anda kembali, Anda tidak perlu grep enam file log. Anda membuka papan dan membaca antreannya: apa yang selesai, apa yang gagal, apa yang menunggu Anda.
Inilah batas yang perlu dinyatakan dengan jelas. Sharkly bukan pengganti Claude Code, Codex, atau alat eksekusi lainnya. Sharkly menambahkan lapisan task bersama, Computer, konteks, dan review di sekitar alat yang sudah digunakan tim Anda. Agen tetap yang menulis kode. Sharkly memastikan bahwa saat Anda pergi, kode itu kembali ke tempat yang bisa Anda lihat, lengkap dengan ringkasan perubahan dan hasil pengujian, serta penerimaan akhir tetap menjadi keputusan manusia. Otomasi berhenti di titik yang membutuhkan penilaian.
Anda bisa membangun semua ini secara manual dengan worktree, nohup, dan perintah mail. Aturan keputusan yang jujur: jika Anda sesekali menjalankan satu agen, setup manual sudah cukup dan Sharkly hanya menambah beban yang tidak Anda perlukan. Persamaannya berubah saat beberapa agen berjalan di berbagai tugas dan repositori serta antrean review menjadi hal yang menghabiskan pagi Anda. Jika Anda ingin terus memakai beberapa agen coding alih-alih terikat pada satu ekosistem, antrean itulah masalah yang dirancang untuk dipecahkan Sharkly.
Antrean review adalah bottleneck sebenarnya
Ada satu asumsi yang layak dipertanyakan: orang mengoptimalkan run tanpa pengawasan dan menganggap review sebagai hal sampingan. Itu terbalik. Menjalankan agen secara paralel saat Anda tidur hanya menguntungkan jika mereview output mereka keesokan paginya lebih cepat daripada mengerjakan sendiri pekerjaan itu. Saat lima agen selesai dalam semalam dan mereview kelima diff-nya lebih lama daripada menulis dua di antaranya, paralelisme itu tidak menghasilkan apa-apa.
Jadi rancang antrean review lebih dulu. Tentukan apa yang harus disertakan dalam status "selesai" sebelum sebuah run sampai ke Anda: pengujian yang lulus, typecheck, ringkasan perubahan, dan catatan batasan yang diketahui. Urutkan antrean berdasarkan risiko, bukan waktu selesai, agar run yang menyentuh auth mendapat perhatian Anda sebelum run yang hanya memperbaiki typo. Buat "request changes" semurah "approve," karena separuh run tanpa pengawasan akan hampir benar tapi tidak sepenuhnya tepat. Review adalah bottleneck dalam alur kerja agen paralel mana pun, dan di mana agen benar-benar berjalan, server Anda, laptop Anda, atau keduanya, jauh lebih tidak penting dibanding apakah outputnya datang sebagai antrean yang bisa Anda bereskan.
Checklist yang bisa Anda jalankan hari ini
Sebelum meninggalkan agen, pastikan:
- Isolasi: run memiliki worktree sendiri, bukan checkout kerja Anda.
- Masa hidup: proses bertahan setelah koneksi terputus (
nohup,tmux, atau Computer yang terkelola), sehingga menutup laptop tidak mematikannya di tengah pengeditan. - Perekaman: stdout dan stderr masuk ke log yang persisten atau timeline Task yang bisa Anda baca dari awal.
- Non-interaktif: agen tidak akan macet pada prompt yang tidak ada orang untuk menjawabnya.
- Radius dampak: cakupan file dibatasi, force-push dimatikan, dan tidak ada run tanpa pengawasan yang merge ke branch yang dilindungi.
- Sinyal penyelesaian: Anda diberi tahu kapan selesai dan apakah lulus, tanpa perlu memantau.
- Kontrak review: setiap run yang selesai datang dengan pengujian, ringkasan perubahan, dan batasan yang diketahui, dan penerimaan akhir tetap di tangan Anda.
Enam poin pertama membuat run menjadi tanpa pengawasan. Poin terakhir membuatnya layak dikerjakan. Jika Anda sudah menjalankan beberapa agen dan review pagi adalah tempat waktu Anda habis, jalankan agen coding Anda yang sudah ada melalui Sharkly agar antreannya datang kepada Anda dalam keadaan terorganisir, bukan tersebar.



