Anda menyerahkan satu bug kepada Claude Code dan sebuah fitur kecil kepada Codex, lalu pergi, dan ketika kembali, file-nya terlihat salah. Edit dari salah satu agen hilang. Atau kedua edit ada tetapi build-nya gagal. Atau, lebih parah lagi, semuanya berhasil dikompilasi dan sebuah tes gagal di tempat yang tidak disentuh oleh agen mana pun. Tidak ada yang crash saat Anda pergi. Kedua agen sama-sama mengerjakan apa yang Anda minta. File tersebut tidak bisa menampung dua penulis sekaligus, dan tidak ada yang memberi tahu Anda siapa yang menang.
Kesenyapan itulah masalah sebenarnya. Sebuah file bukanlah alat merge. Ketika dua agen coding menulis ke auth.ts di direktori yang sama pada waktu yang saling tumpang tindih, tidak ada lock, tidak ada antrean, tidak ada peringatan; yang ada hanyalah proses mana pun yang menyimpan terakhir. Artikel ini menelusuri tabrakan tersebut langkah demi langkah, menyebutkan mode kegagalan di setiap tahapnya, dan diakhiri dengan checklist yang bisa Anda jalankan sebelum sesi paralel berikutnya.
Artikel ini juga mengarah pada alur kerja yang menjadi tujuan dari perbaikan-perbaikan tersebut. Sharkly adalah platform perintah dan manajemen Agen serba-serbi yang berada di atas agen coding yang sudah Anda jalankan. Platform ini memberi setiap Task worktree-nya sendiri yang terisolasi dan menjaga konteks, progres, penghambat, hasil, serta tinjauan manusia tetap terlihat mulai dari permintaan hingga rilis. Anda bisa membangun disiplin yang sama secara manual dengan Git biasa, dan sebagian besar artikel ini menunjukkan caranya. Bagian terakhir membahas kapan melakukan semuanya secara manual sudah tidak lagi menguntungkan.
Tidak ada lock: yang menyimpan terakhir menang
Mulailah dari versi terburuk, karena inilah yang paling umum dan paling tidak terlihat. Kedua agen berjalan di direktori kerja yang sama. Agen A membaca auth.ts, merencanakan perubahan, dan mulai menulis. Agen B membaca auth.ts yang sama sesaat kemudian, merencanakan perubahan berbeda berdasarkan versi yang dibacanya, dan ikut menulis.
Keduanya tidak membaca edit milik yang lain, karena edit tersebut belum tersimpan saat mereka membacanya. Siapa pun yang menyimpan kedua akan menimpa file di disk dengan versi yang tidak pernah memuat hasil kerja agen pertama. Inilah last-write-wins, dan ini senyap. Tidak ada penanda konflik, tidak ada error, tidak ada exit code. Agen A melaporkan sukses. Agen B melaporkan sukses. Salah satu dari mereka membohongi Anda dan tidak menyadarinya.
Race pada lockfile adalah kegagalan yang sama di tempat yang lebih mahal. Agen A menjalankan npm install dan menulis ulang package-lock.json; Agen B, di tengah proses install, menulis ulang lagi dari kondisi awal yang berbeda. Hasilnya adalah lockfile yang tidak cocok dengan kedua dependency tree, dan kerusakannya baru muncul di mesin orang lain beberapa hari kemudian. Output build yang dibagi bersama, satu port dev-server, dan cache global semuanya gagal dengan cara yang sama.
Solusinya bukan agen yang lebih pintar. Solusinya adalah memberi setiap agen ruangnya sendiri.
Satu salinan kerja per agen: clobber senyap berubah menjadi konflik yang terlihat
Git worktree adalah salinan checkout kedua dari satu repositori, pada branch-nya sendiri, yang berbagi satu object store .git. Setiap agen mendapatkan direktori nyata untuk mengedit, membangun, dan menguji tanpa melihat pekerjaan yang sedang berjalan milik orang lain.
# From the main repo
git worktree add ../repo-agent-a -b agent/auth-refactor
git worktree add ../repo-agent-b -b agent/session-timeout
Arahkan Agen A ke ../repo-agent-a dan Agen B ke ../repo-agent-b. Sekarang edit yang belum tersimpan dari A ke auth.ts tidak terlihat oleh B, dan tidak ada agen yang bisa menimpa file milik agen lain di disk, karena mereka mengedit dua file berbeda pada dua branch berbeda. Model worktree dibahas lebih mendalam di Git worktrees untuk agen coding AI dan worktree agen coding: satu checkout per task.
Perhatikan apa yang dilakukan isolasi di sini. Isolasi tidak mencegah kedua agen mengedit file yang sama. Isolasi mengubah kehilangan data yang senyap menjadi konflik merge yang terlihat pada saat kedua branch bertemu kembali. Itu adalah peningkatan yang nyata: Git berhenti dan menunjukkan kepada Anda baris-baris persis yang berselisih, dan Anda menyelesaikannya dengan pandangan penuh atas kedua versi. Konflik yang bisa Anda lihat adalah masalah yang bisa Anda perbaiki. Clobber yang tidak bisa Anda lihat adalah yang membuatnya terkirim.
Satu batasan yang perlu dinyatakan dengan jelas: worktree mengisolasi file, bukan efek samping. Database bersama, satu port, atau path output yang di-hardcode tetap bertabrakan antar worktree. Isolasi juga hal-hal tersebut, atau serialkan agen yang membutuhkannya.
Konflik yang tidak bisa Anda lihat
Inilah mode kegagalan yang bertahan meski sudah diisolasi. Agen A, yang bekerja di worktree-nya sendiri, mengganti nama getUser() menjadi fetchUser() dan memperbarui setiap call site yang dimilikinya. Agen B, yang bekerja di worktree-nya sendiri pada saat yang sama, menulis tiga call site baru untuk getUser(), karena itulah nama fungsi tersebut saat B membaca file.
Kedua branch berhasil di-merge tanpa penanda konflik sama sekali. Git membandingkan baris, dan baris demi baris tidak ada yang tumpang tindih: A mengubah file-nya, B menambahkan file baru. Merge-nya bersih. Lalu build-nya gagal karena getUser yang tidak terdefinisi, atau berhasil dikompilasi dan gagal saat runtime di tempat yang tidak bisa dijangkau oleh type checker. Tidak ada tool yang menandainya, karena secara tekstual tidak ada tabrakan. Kedua edit tersebut berselisih tentang makna file, bukan teksnya.
Inilah alasan mengapa "cukup isolasi agennya" bukan jawaban lengkap. Isolasi menunda tabrakan sesama file menjadi tabrakan sesama interface, dan jenis kedua lebih pandai bersembunyi daripada yang pertama. Tuasnya di sini adalah scoping task, bukan tooling. Aturan yang berguna: jika Anda tidak bisa mendeskripsikan task dari dua agen tanpa menyebut file atau fungsi yang sama, sesungguhnya itu satu task, bukan dua. Memecah pekerjaan di sepanjang batas antar modul adalah sebagian besar dari apa yang menjaga Claude Code dan Codex bekerja bersama di satu codebase agar tidak berubah menjadi sore penuh debugging. Ketika dua task benar-benar berbagi satu interface, serialkan keduanya, atau merge dan rebase di antara langkah-langkahnya agar agen kedua membaca realitas agen pertama.
Di mana setup DIY berhenti berskala, dan apa yang ditambahkan oleh task board
Dua agen dan satu file bersama, masih bisa Anda kelola secara manual: dua worktree, scoping yang hati-hati, merge yang Anda awasi. Metode ini bertahan sampai penghitungannya mulai sulit. Agen mana yang di branch mana. Worktree mana yang memetakan ke task mana. Dari lima merge bersih, mana yang diam-diam mengubah interface bersama. Branch mana yang menunggu tinjauan Anda, dan mana yang sudah Anda lihat. Perintah Git tidak pernah menjadi lebih sulit; pembukuan di sekitarnya yang menjadi sulit, dan pembukuan itulah tempat tabrakan sesama file lolos, karena Anda menyetujui merge yang belum Anda baca sepenuhnya.
Task board mengubah apa yang Anda lacak. Alih-alih dinding berisi terminal dan worktree yang tercerai-berai, setiap unit pekerjaan adalah sebuah Task dengan pemilik, branch, dan status. Di Sharkly, sebuah Task otomatis mendapatkan worktree-nya sendiri yang terisolasi, sehingga isolasi tingkat file menjadi default alih-alih perintah yang harus Anda ingat untuk dijalankan. Eksekusi, penghambat, dan hasil kembali ke Task, sehingga Anda meninjau perubahan terhadap scope yang dinyatakan alih-alih merekayasabalik niat dari sebuah diff. Dan pembagian kerja tetap: agen meneliti, mengeksekusi, menguji, dan melaporkan; manusia menetapkan arah, memberi wewenang, dan menerima hasilnya. Otomasi berhenti di titik yang membutuhkan penilaian tim.
Poin terakhir itulah yang tidak pernah bisa dipecahkan oleh isolasi saja. Tool yang lebih baik membuat isolasi dan merge lebih mudah, tetapi tinjauan tidak berskala seiring jumlah agen; tinjauan berskala seiring perhatian Anda, dan tinjauan manusia adalah bottleneck nyata dalam kerja agen paralel. Lima agen menghasilkan lima branch dalam waktu yang Anda butuhkan untuk membaca satu dengan cermat. Task board tidak membaca kodenya untuk Anda. Task board menjaga antreannya tetap jujur agar edit yang tampak masuk akal tidak sekadar dipindai lalu di-merge karena Anda kehilangan jejak ada di tumpukan mana ia berada. Hitungan konflik yang sama juga muncul di tingkat repo, dibahas di beberapa agen coding di repositori yang sama.
Anda bisa membangun ini dengan worktree dan disiplin, atau memakai Sharkly untuk mengelola alur kerjanya. Jika Anda sudah menjalankan beberapa agen, nilainya adalah punya satu tempat di mana task dan hasil mereka berada, alih-alih tercerai-berai di berbagai terminal.
Checklist yang harus dijalankan sebelum sesi paralel berikutnya
Jalankan ini sebelum Anda mengarahkan dua agen ke apa pun:
- Beri setiap agen worktree-nya sendiri. Jangan pernah menaruh dua agen di satu direktori kerja.
git worktree add ../repo-<task> -b agent/<task>per task. Lihat agen paralel di worktree yang terisolasi. - Batasi scope task agar tidak menyebut file atau fungsi yang sama. Jika terpaksa, itu satu task; serialkan.
- Isolasi efek samping, bukan hanya file. Pisahkan database, port, path output, dan cache, atau serialkan agen yang berbagi hal-hal tersebut.
- Rebase sebelum merge ketika dua branch berjalan terhadap commit awal yang sama, agar pekerjaan agen kedua berada di atas agen pertama.
- Jalankan type check dan seluruh test suite setelah setiap merge, bukan hanya setelah merge terakhir. Konflik semantik lolos dari merge yang bersih dan gagal di sini.
- Tinjau setiap branch terhadap scope task-nya, satu per satu. Tumpukan tanda centang hijau yang belum dibaca adalah tempat konflik tak terlihat itu terkirim.
Dua agen mengedit satu file bukanlah kasus tepi yang langka; itulah wujud kerja paralel pada saat task Anda bersinggungan sedikit saja. Rencanakan tabrakannya, buat ia terlihat, dan pastikan satu orang yang memutuskan apa yang di-merge.
