Jalankan dua agen coding di checkout yang sama dan dalam hitungan satu jam Anda akan berhadapan dengan mode kegagalannya. Satu agen berpindah branch sementara agen lain masih di tengah proses edit. Perubahan yang sudah masuk staging lenyap ke dalam commit yang bukan miliknya. Test lolos terhadap file yang baru setengah ditulis ulang oleh agen lain. Semua ini bukan salah model. Working tree git adalah mutable state yang dipakai bersama, dan dua proses yang mengubah state bersama tanpa koordinasi pada akhirnya akan merusaknya.
Solusi standarnya sudah dikenal luas: beri setiap agen working tree-nya sendiri. Git worktree memungkinkan satu repositori melayani beberapa direktori hasil checkout sekaligus, sehingga branch paralel tidak pernah menyentuh file yang sama di disk. Banyak tim membuat skripnya sendiri secara manual; panduan kami tentang menggunakan git worktree dengan agen coding AI membahas setup DIY tersebut.
Postingan ini membahas jalur lainnya: apa yang terjadi ketika isolasi, penyiapan direktori, batas konkurensi, dan pembersihan ditangani oleh platform, bukan oleh skrip shell Anda.
TL;DR
Sharkly menjalankan agen AI secara paralel tanpa merge conflict dengan memberi setiap run Task direktori terisolasi miliknya sendiri di sebuah Computer yang terhubung. Layanan lokal di Computer tersebut menerima setiap run yang masuk antrean, menyiapkan direktori task (untuk pekerjaan berbasis repositori, satu git worktree terpisah per run), menjalankan Runtime yang dipilih, lalu mengalirkan progres, event trace, dan hasil kembali ke Task. Batas konkurensi pada Agent dan Computer membatasi berapa banyak run yang dieksekusi sekaligus, dan tidak ada yang di-merge sendiri: hasilnya kembali ke Task, tempat seseorang meninjau perubahan dan memutuskan langkah merge dan rilis. Agen tidak pernah berbagi working tree, sehingga Task paralel tidak bisa saling menimpa perubahan.
Mode kegagalan yang ingin dicegah Sharkly
Ada baiknya kita tepat dalam memahami apa yang salah ketika beberapa agen berbagi satu checkout, karena setiap gejalanya berkaitan dengan satu bagian dari solusinya.
Status branch bersifat global per working tree, jadi ketika agen A melakukan checkout branch-nya sendiri, file-file milik agen B berubah di bawahnya di tengah run. Index juga global, sehingga git add dan git commit mencampuradukkan pekerjaan dari task yang berbeda. State yang belum di-track saling bertabrakan: output build dan instalasi dependensi dari satu run mencemari hasil test run lain. Dan utang pembersihan pun menumpuk, karena setiap salinan repositori ad-hoc yang dibuat untuk menghindari tiga masalah pertama akan tetap ada di disk sampai ada orang yang ingat bahwa salinan itu ada.
Satu direktori bersama hanya bisa menjalankan satu agen dengan aman. Jika Anda mengakalinya dengan panel tmux dan kedisiplinan, postingan kami tentang menjalankan beberapa agen Claude Code secara paralel menjelaskan mengapa batas itu cepat tercapai.
Tumpukan eksekusi: Agent, Computer, Runtime, Task
Sharkly bukan pengganti Claude Code, Codex, atau tool eksekusi lainnya. Sharkly menambahkan lapisan task bersama, Computer, konteks, kontrol, dan review di sekitar tool yang sudah digunakan tim Anda. Posisi sebagai lapisan itulah yang membentuk cara kerja eksekusi paralel, karena tugas Sharkly adalah mengoordinasikan run, bukan menulis kode.
Empat peran berbagi pekerjaan ini, dan masing-masing punya tepat satu tugas:
- Agent mendefinisikan bagaimana pekerjaan harus ditangani: instruksinya, Skills, repositori, dan pengaturan run. Agent bukan host eksekusi.
- Computer menyediakan host dan sumber daya lokal: mesin lokal, server remote, container, atau cloud host yang didukung. Postingan terkait tentang Computer di Sharkly membahas cara menghubungkannya.
- Runtime menjalankan sesi agen yang sebenarnya. Runtime adalah tool konkret yang terpasang di Computer tersebut, seperti Claude Code, Codex, atau Gemini CLI.
- Task tetap menjadi catatan bersama untuk tim: tujuan, status, diskusi, trace eksekusi, dan hasil.
Yang menyatukan semuanya adalah layanan lokal kecil di Computer. Layanan ini mendaftarkan Computer, mendeteksi Runtime yang terpasang, menerima run dari antrean, menyiapkan direktori task untuk setiap run, menjalankan Runtime, dan melaporkan hasilnya kembali. Layanan inilah yang memulai koneksi ke server, sehingga setup pada umumnya tidak memerlukan inbound port.
Pemisahan itulah yang membuat paralelisme bisa dikelola. Karena direktori kerja disiapkan per run oleh layanan lokal, bukan dipilih oleh Agent, dua Agent yang ditugaskan ke dua Task bisa menyasar repositori yang sama di Computer yang sama tanpa pernah melihat file satu sama lain. Untuk cara Agent dikonfigurasi, lihat Agent di Sharkly.
Apa yang terjadi saat sebuah run dimulai
Tugaskan sebuah Task ke sebuah Agent dan pindahkan dari Backlog, lalu Sharkly memeriksa kesiapan eksekusi, memasukkan run yang memenuhi syarat ke antrean, dan mengirimkannya ke Computer yang dipilih. Setelah itu layanan lokal mengambil alih. Sebelum Runtime dimulai, layanan mungkin perlu menunggu kapasitas konkurensi, menyiapkan direktori sementara yang terisolasi atau menunggu direktori tertentu yang bebas, mengambil repositori yang dikonfigurasi, memproyeksikan variabel lingkungan yang diizinkan, dan menyusun pemanggilan Runtime.
Baru setelah itu Runtime mulai berjalan. Run melewati status-status yang eksplisit: Queued, Dispatched, Waiting for local directory, Running, dan akhirnya Completed, Failed, atau Canceled. Status-status tersebut muncul di log eksekusi Task, sehingga pertanyaan “kenapa belum ada yang terjadi” punya jawaban yang bisa diperiksa, bukan sekadar tebakan. Run yang tertahan di Queued karena batas konkurensi penuh terlihat berbeda dari run yang tertahan di Waiting for local directory, dan perbedaannya memberi tahu Anda knob mana yang harus diputar.
Perhatikan apa yang tidak ada di sini: Agent sama sekali tidak menentukan di mana run dijalankan. Agent membawa instruksi; infrastruktur yang menyediakan isolasi.
Worktree terisolasi: cara kerja mode Temporary
Agent mendukung dua mode direktori kerja, dan mode yang dirancang untuk pekerjaan paralel adalah mode Temporary. Setiap Task mendapatkan direktori terisolasi, dan untuk pekerjaan berbasis repositori, layanan lokal bisa menyiapkan git worktree terpisah untuk setiap run dari data repositori yang di-cache.
Satu kalimat itu merangkum seluruh cerita pencegahan konflik. Sebuah worktree memberi setiap run direktori hasil checkout dan status branch-nya sendiri, sementara objek repositori di bawahnya tetap dibagi. Empat mode kegagalan di atas hilang secara struktural: tidak ada branch pointer bersama, tidak ada index bersama, tidak ada artefak build bersama, dan direktorinya bisa dibersihkan platform nanti. Karena worktree dibuat dari data yang di-cache, bukan dari clone baru, biaya startup tetap wajar, meskipun sebuah run mungkin masih butuh akses jaringan untuk memuat ulang repositori.
Dokumentasi menyatakannya secara lugas: mode Temporary direkomendasikan untuk perubahan kode paralel, dan untuk situasi apa pun ketika beberapa Task mungkin memodifikasi codebase yang sama secara bersamaan.
Satu batasan perlu dinyatakan dengan jelas: isolasi mencegah tabrakan working tree, bukan konflik semantik. Jika dua Task sama-sama menulis ulang fungsi yang sama, kedua run tetap selesai dengan bersih di worktree masing-masing, dan seseorang masih harus menyelaraskan tumpang tindihnya saat review. Solusinya adalah membatasi cakupan Task agar keduanya tidak menyasar kode yang sama pada waktu yang berdekatan: ini keputusan perencanaan, bukan keputusan infrastruktur.
Kapan isolasi jadi pilihan yang salah: mode Specified
Mode kedua ada karena menyiapkan direktori baru untuk setiap run tidaklah gratis. Dalam mode Specified, Agent berjalan di dalam satu direktori lokal absolut yang dikonfigurasi dari pool-nya, menggunakan kembali repositori, dependensi, dan cache yang sudah ada di sana. Mode ini hanya tersedia di Computer lokal.
Pertukaran ini punya konsekuensi tegas: satu direktori specified hanya melayani satu run pada satu waktu, dan ketika semua direktori yang dikonfigurasi sedang sibuk, run berikutnya harus menunggu. Agent yang harus menjalankan beberapa Task secara bersamaan dalam mode Specified memerlukan beberapa direktori di pool-nya.
| Temporary mode | Specified mode | |
|---|---|---|
| Direktori per run | Direktori terisolasi baru, worktree untuk pekerjaan repositori | Satu direktori absolut yang dikonfigurasi dari pool |
| Keamanan paralel | Run tidak bisa menyentuh file run lain | Satu run per direktori pada satu waktu |
| Biaya startup | Menyiapkan direktori setiap run, dari data repositori yang di-cache | Menggunakan kembali kode, dependensi, dan cache yang sudah ada |
| Paling cocok untuk | Perubahan kode paralel, sebagian besar pekerjaan repositori | Repositori yang sangat besar, state lokal yang mahal, tooling yang terikat direktori |
| Ketersediaan | Computer apa pun yang terhubung | Hanya Computer lokal |
Isolasi membeli keamanan dengan biaya penyiapan; penggunaan ulang membeli kecepatan dengan biaya serialisasi. Sharkly membuat Anda memilih secara eksplisit per Agent, yang jauh lebih baik daripada menemukan trade-off itu di working tree yang rusak.
Batas konkurensi: paralel, tetapi terukur
Paralelisme tanpa batas adalah mode kegagalan tersendiri. Setiap run yang berjalan bersamaan mengonsumsi CPU, memori, disk, kapasitas penyedia model, dan bandwidth repositori; delapan agen yang berebut satu laptop menghasilkan hasil yang lebih buruk daripada tiga agen yang berjalan dengan nyaman.
Sharkly membatasi konkurensi di dua tingkat. Sebagai host, Computer memiliki batas konkurensi task, dan setiap Agent memiliki jumlah maksimum Task yang berjalan paralel plus timeout per Task. Nilai defaultnya konservatif: dalam mode Temporary, sebuah Agent mendapat 50 persen dari batas Computer; dalam mode Specified, jumlahnya sama dengan jumlah direktori yang dikonfigurasi. Jika Anda menetapkannya lebih tinggi dari jumlah direktori, produk akan memperingatkan bahwa penulisan bisa bertabrakan antar task. Peringatan itu adalah tesis postingan ini yang dipadatkan ke dalam satu kotak dialog.
Panduan dokumentasi tentang menaikkan batas bersifat bijak: naikkan konkurensi hanya setelah Computer dan Runtime yang ada menangani beban kerja saat ini dengan andal.
Streaming progres dan review sebelum merge
Isolasi akan menjadi beban jika berarti juga ketidakjelasan. Lima agen di lima direktori tersembunyi justru membuat pekerjaan menghilang ke dalam terminal pribadi. Karena itu, semua yang dihasilkan run mengalir kembali ke catatan bersama.
Selama run aktif, Task menampilkan status eksekusinya. Activity memuat komentar dan perubahan task dalam sebuah timeline; log eksekusi mencatat kapan run dimulai dan berakhir, pemanggilan tool dan event Runtime, sumber pemicunya, serta detail kegagalan jika ada; laporan Agent disimpan sebagai komentar yang tertaut ke trace eksekusinya. Konteks, progres, hambatan, dan hasil tetap terlihat sejak permintaan hingga rilis, meskipun pengeditan file terjadi di direktori yang tidak pernah dibuka siapa pun.
Lalu tibalah gerbangnya. Tidak ada yang di-merge sendiri di sini. Agen melakukan riset, eksekusi, pengujian, dan pelaporan. Manusia yang menentukan arah, memberi wewenang, dan menerima hasilnya. Ketika sebuah run selesai, Agent dapat membiarkan Task menunggu review manusia, yang akan muncul di Inbox penanggung jawabnya. Worktree terisolasi membuat eksekusi paralel aman; gerbang review membuatnya bisa dipercaya.
Satu bagian lagi menutup siklusnya: pembersihan. Run Agent meninggalkan direktori kerja dan artefak di Computer, dan pembersihan yang dapat dikonfigurasi akan mereklaim run yang sudah selesai setelah periode retensi, dengan ambang ruang kosong minimum sebagai pengaman. Pekerjaan yang sedang berjalan atau dalam antrean, run yang di-pin, dan run gagal yang masih perlu ditelusuri tidak pernah disentuh. Inilah pekerjaan rumah yang konsisten dilupakan setup DIY sampai disk penuh.
Apa yang diotomatisasi Sharkly versus setup DIY
Jika Anda sudah membaca panduan worktree DIY kami, pemetaannya langsung terlihat. git worktree add yang Anda skripkan per agen menjadi layanan lokal yang menyiapkan direktori terisolasi per run. Penilaian “berapa banyak agen yang terlalu banyak” menjadi batas konkurensi eksplisit dengan peringatan ketika pengaturannya tidak aman. git worktree prune yang Anda lupakan menjadi pembersihan berbasis retensi. Dan bagian yang tidak bisa diberikan skrip mana pun, yakni catatan bersama tentang run mana mengerjakan apa dan apakah seseorang menerimanya, adalah Task itu sendiri.
Prinsip keputusan yang jujur juga berlaku di sini. Developer yang bekerja sendiri dan menjalankan dua agen di satu mesin mungkin tidak memerlukan platform; skrip worktree dan kedisiplinan sudah cukup. Beralihlah ke Sharkly ketika koordinasinya lebih mahal daripada menulis kode: banyak orang yang menugaskan pekerjaan, banyak Computer, run yang butuh antrean dan review. Apa pun pilihannya, Anda tetap memakai Runtime yang sudah ada; penggunaan model tetap berjalan melalui langganan atau API key yang dikonfigurasi di tool tersebut.
Langkah awalnya sengaja dibuat kecil. Hubungkan satu Computer, buat satu Agent dalam mode Temporary, dan tugaskan satu Task berisiko rendah. Panduan memulai memandu siklus pertama dalam sekitar sepuluh menit, dokumentasi Sharkly membahas setiap konsep secara mendalam, dan apa itu Sharkly melengkapi gambaran platform di sekitar eksekusi.
FAQ
Bagaimana Sharkly mencegah merge conflict antar agen paralel?
Setiap run Task mendapat direktori terisolasi sendiri di Computer, dan run berbasis repositori masing-masing bisa mendapat git worktree terpisah yang disiapkan oleh layanan lokal. Agen tidak pernah berbagi checkout, index, atau file yang belum di-track, sehingga run yang berjalan bersamaan tidak bisa menimpa pekerjaan yang sedang berjalan satu sama lain. Tumpang tindih ketika dua Task memang sengaja mengubah kode yang sama tetap harus diselaraskan oleh manusia saat review.
Apakah saya perlu menyiapkan git worktree sendiri untuk menggunakan Sharkly?
Tidak. Dalam mode Temporary, layanan lokal menyiapkan direktori task untuk setiap run, termasuk worktree untuk pekerjaan berbasis repositori. Anda cukup mengonfigurasi mode pada Agent sekali; tidak ada perintah worktree per run yang perlu diskripkan. Untuk memahami mekanisme di baliknya, lihat dokumentasi git worktree.
Berapa banyak agen yang bisa berjalan paralel di satu Computer?
Computer memiliki batas konkurensi task sendiri, dan setiap Agent punya jumlah maksimum Task yang berjalan paralel. Secara default, Agent dalam mode Temporary mendapat 50 persen dari batas Computer, sedangkan yang berada dalam mode Specified mendapat satu slot per direktori yang dikonfigurasi. Run yang melebihi batas akan menunggu dalam antrean.
Apakah Sharkly melakukan merge perubahan agen secara otomatis?
Tidak. Hasil run, bukti, dan trace-nya kembali ke Task, dan seseorang meninjau ringkasan perubahan sebelum apa pun dirilis. Peninjau bisa menerima, meminta perubahan, atau memutuskan langkah merge dan rilis. Otomatisasi berhenti di titik yang memerlukan penilaian tim.
Kapan saya sebaiknya menggunakan mode Specified alih-alih worktree terisolasi?
Gunakan ketika menyiapkan direktori baru per run benar-benar mahal: repositori yang sangat besar, state atau cache hasil generate yang memakan biaya, atau tooling yang terikat pada satu path lokal. Terimalah bahwa setiap direktori specified hanya melayani satu run pada satu waktu. Untuk semua kasus lainnya, mode Temporary adalah default yang direkomendasikan.
