Claude Code'a bir hata, Codex'e küçük bir özellik verip ortalıktan kayboluyorsunuz ve geri döndüğünüzde yanlış görünen bir dosyayla karşılaşıyorsunuz. Ajanlardan birinin düzenlemesi kayıp. Ya da her iki düzenleme de yerinde ama derleme başarısız oluyor. Ya da daha kötüsü, her şey derleniyor ve hiçbir ajanın dokunmadığı bir yerde bir test kırılıyor. Siz yokken hiçbir şey çökmedi. İki ajan da istediğiniz işi yaptı. Dosya aynı anda iki yazarı barındıramadı ve kimse size hangisinin kazandığını söylemedi.
Asıl sorun bu sessizlik. Bir dosya bir birleştirme aracı değildir. İki kodlama ajanı aynı dizindeki auth.ts dosyasına çakışan zamanlarda yazdığında ne bir kilit, ne bir kuyruk, ne de bir uyarı vardır; yalnızca en son kaydeden süreç kalır. Bu makale çakışmayı adım adım ele alıyor, her aşamada başarısızlık modunu adlandırıyor ve bir sonraki paralel oturumunuzdan önce uygulayabileceğiniz bir kontrol listesiyle sonlanıyor.
Aynı zamanda bu düzeltmelerin götürdüğü iş akışına da işaret ediyor. Sharkly, halihazırda çalıştırdığınız kodlama ajanlarının üzerinde konumlanan, hepsi bir arada bir Ajan komut ve yönetim platformudur. Her Göreve kendi izole worktree'sini verir ve bağlamı, ilerlemeyi, engelleri, sonuçları ve insan incelemesini talepten sürüme kadar görünür tutar. Aynı disiplini düz Git ile elle de kurabilirsiniz ve bu makalenin büyük kısmı bunun nasıl yapılacağını gösteriyor. Son bölüm, elle yapmanın ne zaman karşılığını vermeyi bıraktığıyla ilgili.
Kilit yok: son yazan kazanır
En kötü versiyonla başlayın, çünkü hem en yaygın olan hem de en görünmez olan bu. İki ajan da aynı çalışma dizininde çalışıyor. Ajan A, auth.ts dosyasını okur, bir değişiklik planlar ve yazmaya başlar. Ajan B, bir saniye sonra aynı auth.ts dosyasını okur, okuduğu sürüme karşı farklı bir değişiklik planlar ve o da yazar.
Hiçbiri diğerinin düzenlemesini okumadı, çünkü okudukları sırada düzenleme henüz kaydedilmemişti. İkinci kaydeden, diskteki dosyanın üzerine ilk ajanın işini hiç içermeyen bir sürümle yazar. Bu, son-yazan-kazanır durumudur ve sessizdir. Ne bir çakışma işaretleyicisi, ne bir hata, ne de bir çıkış kodu vardır. Ajan A başarı bildirir. Ajan B başarı bildirir. Biri size yalan söylüyor ve bundan haberi yok.
Lockfile yarışı, aynı başarısızlığın daha maliyetli bir yerdeki halidir. Ajan A npm install çalıştırır ve package-lock.json dosyasını yeniden yazar; kurulumun ortasındaki Ajan B ise onu farklı bir başlangıç durumundan tekrar yazar. Sonuç, iki bağımlılık ağacının hiçbirine uymayan bir lockfile'dır ve sorun günler sonra başkasının makinesinde ortaya çıkar. Paylaşılan derleme çıktısı, tek bir dev-server portu ve küresel bir önbellek de aynı şekilde başarısız olur.
Çözüm daha akıllı bir ajan değil. Her ajana kendi odasını vermek.
Her ajan için bir çalışma kopyası: sessiz ezme görünür bir çakışmaya dönüşür
Bir Git worktree, tek bir .git nesne deposunu paylaşan, kendi dalında bulunan, bir deponun ikinci bir checkout kopyasıdır. Her ajan, başkalarının devam eden işini görmeden düzenleme, derleme ve test yapabileceği gerçek bir dizin elde eder.
# From the main repo
git worktree add ../repo-agent-a -b agent/auth-refactor
git worktree add ../repo-agent-b -b agent/session-timeout
Ajan A'yı ../repo-agent-a dizinine, Ajan B'yi de ../repo-agent-b dizinine yönlendirin. Artık A'nın auth.ts üzerindeki kaydedilmemiş düzenlemeleri B için görünmezdir ve hiçbir ajan diğerinin dosyasının üzerine diskte yazamaz, çünkü iki farklı daldaki iki farklı dosyayı düzenliyorlar. Worktree modeli Git worktrees for AI coding agents ve coding agent worktrees: one checkout per task yazılarında daha ayrıntılı ele alınıyor.
İzolasyonun burada ne yaptığına dikkat edin. İki ajanın aynı dosyayı düzenlemesini engellemedi. Sessiz bir veri kaybını, dallar yeniden bir araya geldiği anda görünür bir birleştirme çakışmasına dönüştürdü. Bu gerçek bir iyileştirmedir: Git durur ve anlaşmazlık içindeki tam satırları gösterir, siz de her iki sürümü de tam olarak görerek bunları çözersiniz. Görebildiğiniz bir çakışma, düzeltebileceğiniz bir sorundur. Göremediğiniz ezme ise işe yayılan olandı.
Açıkça belirtilmeye değer bir sınır: worktree'ler dosyaları izole eder, yan etkileri değil. Paylaşılan bir veritabanı, tek bir port veya sabit kodlanmış bir çıktı yolu worktree'ler arasında hâlâ çakışır. Bunları da izole edin ya da onlara ihtiyaç duyan ajanları sıraya koyun.
Göremediğiniz çakışma
İşte izolasyondan sağ çıkan başarısızlık modu. Kendi worktree'sinde çalışan Ajan A, getUser() fonksiyonunun adını fetchUser() olarak değiştirir ve sahip olduğu her çağrı noktasını günceller. Aynı anda kendi worktree'sinde çalışan Ajan B ise getUser() için üç yeni çağrı noktası yazar, çünkü B dosyayı okuduğunda fonksiyonun adı buydu.
Her iki dal da sıfır çakışma işaretleyicisiyle birleşir. Git satırları karşılaştırır ve satır satır hiçbir şey örtüşmedi: A kendi dosyalarını değiştirdi, B yeni dosyalar ekledi. Birleştirme temizdir. Sonra derleme tanımsız bir getUser yüzünden başarısız olur ya da kod derlenir ve tip denetleyicisinin ulaşamadığı bir yerde çalışma zamanında başarısız olur. Hiçbir araç bunu işaretlemedi, çünkü metinsel olarak hiçbir çakışma yoktu. İki düzenleme, dosyanın metni üzerinde değil anlamı üzerinde anlaşmazlığa düşmüştü.
Bu yüzden "ajanları izole et yeter" tam cevap değildir. İzolasyon, aynı-dosya çakışmasını aynı-arayüz çakışmasına erteler ve ikinci tür birinciden daha iyi gizlenir. Buradaki kaldıraç araç değil, görev kapsamlandırmasıdır. İşe yarar bir kural: iki ajanın görevini aynı dosyayı veya aynı fonksiyonu adlandırmadan tanımlayamıyorsanız, bunlar iki görev değil tek görevdir. İşi modül sınırları boyunca bölmek, Claude Code ve Codex'in tek bir kod tabanında birlikte çalışmasını bir hata ayıklama öğleden sonrasına dönüşmekten alıkoyan şeyin büyük kısmıdır. İki görev gerçekten bir arayüzü paylaşıyorsa, onları sıraya koyun ya da adımlar arasında birleştirip rebase yapın ki ikinci ajan birinci ajanın gerçekliğini okusun.
DIY kurulumunun ölçeklenmeyi bıraktığı yer ve bir görev panosunun ekledikleri
İki ajan ve paylaşılan tek bir dosya, elle yönetilebilir: iki worktree, dikkatli kapsamlandırma, izlediğiniz bir birleştirme. Bu yöntem, sayım zorlaşana kadar işe yarar. Hangi ajan hangi dalda. Hangi worktree hangi göreve karşılık geliyor. Beş temiz birleştirmeden hangisi sessizce paylaşılan bir arayüzü değiştirdi. Hangi dallar incelemenizi bekliyor, hangilerine zaten baktınız. Git komutları hiç zorlaşmadı; onların etrafındaki kayıt tutma zorlaştı ve aynı-dosya çakışmaları tam da bu kayıt tutma sırasında sızıyor, çünkü tam olarak okumadığınız bir birleştirmeyi onayladınız.
Bir görev panosu, neyi takip ettiğinizi değiştirir. Bir terminal ve kopmuş worktree duvarı yerine, her iş birimi bir sahibi, bir dalı ve bir durumu olan bir Görevdir. Sharkly'de bir Görev otomatik olarak kendi izole worktree'sini alır, böylece dosya düzeyinde izolasyon hatırlamanız gereken bir komut değil, varsayılan hale gelir. Yürütme, engeller ve sonuçlar Göreve geri döner, böylece bir değişikliği bir diff'ten niyeti tersine mühendislikle çıkarmak yerine belirtilen kapsamına karşı incelersiniz. Ve iş bölümü sabit kalır: ajanlar araştırır, yürütür, test eder ve raporlar; insanlar yön belirler, yetki verir ve sonucu kabul eder. Otomasyon, ekip muhakemesinin gerekli olduğu yerde durur.
Bu son nokta, izolasyonun tek başına asla çözemediği noktadır. Daha iyi araçlar izolasyonu ve birleştirmeyi kolaylaştırır, ama inceleme ajan sayısıyla ölçeklenmez; dikkatinizle ölçeklenir ve paralel ajan çalışmasında asıl darboğaz insan incelemesidir. Beş ajan, siz birini dikkatlice okuduğunuz sürede beş dal üretir. Bir görev panosu sizin yerinize kodu okumaz. Kuyruğu dürüst tutar ki makul görünen düzenleme, hangi yığında olduğunu takip edemediğiniz için göz gezdirmeyle geçilip birleştirilmesin. Aynı çakışma matematiği repo düzeyinde de karşımıza çıkar; bu da aynı depodaki birden çok kodlama ajanı yazısında ele alınıyor.
Bunu worktree'ler ve disiplinle kurabilir ya da iş akışını yönetmek için Sharkly kullanabilirsiniz. Halihazırda birkaç ajan çalıştırıyorsanız, değer, onların görevlerinin ve sonuçlarının terminallere dağılmak yerine tek bir yerde yaşamasıdır.
Bir sonraki paralel oturumunuzdan önce uygulayacağınız kontrol listesi
İki ajanı herhangi bir şeye yöneltmeden önce bunu uygulayın:
- Her ajana kendi worktree'sini verin. Asla tek bir çalışma dizininde iki ajan olmasın. Her görev için
git worktree add ../repo-<task> -b agent/<task>. Bakınız: paralel agents in isolated worktrees. - Görevleri, aynı dosyayı veya fonksiyonu adlandırmayacak şekilde kapsamlandırın. Adlandırmaları gerekiyorsa, bu tek bir görevdir; sıraya koyun.
- Yalnızca dosyaları değil, yan etkileri de izole edin. Veritabanlarını, portları, çıktı yollarını ve önbellekleri ayırın ya da bunları paylaşan ajanları sıraya koyun.
- Birleştirmeden önce rebase yapın; iki dal aynı başlangıç commit'ine karşı çalıştıysa, ikinci ajanın işi birincinin üstüne otursun.
- Tip denetimini ve tam test paketini her birleştirmeden sonra çalıştırın, sonuncudan sonra değil. Anlamsal çakışmalar temiz bir birleştirmeyi geçer ve tam da burada başarısız olur.
- Her dalı, görevinin kapsamına karşı tek tek inceleyin. Okunmamış yeşil onay işaretlerinden oluşan bir yığın, görünmez çakışmanın işe yayıldığı yerdir.
İki ajanın tek bir dosyayı düzenlemesi nadir bir uç durum değildir; görevleriniz bir santim örtüştüğü anda paralel çalışmanın göründüğü şeydir. Çakışmayı planlayın, onu görünür kılın ve neyin birleşeceğine karar veren tek bir kişi olsun.
