Aynı checkout içinde iki kodlama agent'ı çalıştırın, bir saat içinde o hata moduyla karşılaşırsınız. Bir agent branch değiştirirken diğeri düzenlemenin tam ortasındadır. Stage'lenmiş değişiklikler, ait olmadıkları bir commit'in içinde kaybolur. Testler, diğer agent'ın yarısını yeniden yazdığı bir dosyaya karşı geçer. Bunların hiçbiri modelin suçu değil. Bir git çalışma ağacı paylaşılan ve değiştirilebilir bir durumdur; paylaşılan durumu koordine olmadan değiştiren iki süreç eninde sonunda onu bozar.
Standart çözüm herkesçe bilinir: her agent'a kendi çalışma ağacını verin. Git worktree'ler, tek bir deponun aynı anda birden fazla checkout dizinine hizmet etmesini sağlar; böylece paralel branch'ler diskteki aynı dosyalara asla dokunmaz. Pek çok ekip bunu elle script'liyor; AI kodlama agent'larıyla git worktree kullanma rehberimiz bu DIY kurulumunu adım adım anlatıyor.
Bu yazı ise diğer yolu ele alıyor: izolasyon, dizin hazırlığı, eşzamanlılık sınırları ve temizlik, shell script'leriniz yerine platform tarafından üstlenildiğinde ne oluyor?
TL;DR
Sharkly, bağlı bir Computer üzerinde her Task çalıştırmasına kendi izole dizinini vererek AI agent'larını merge çakışması olmadan paralel çalıştırır. O Computer üzerindeki yerel bir servis, kuyruğa alınan her çalıştırmayı alır, task dizinini hazırlar (depo tabanlı işlerde her çalıştırma için ayrı bir git worktree), seçilen Runtime'ı başlatır ve ilerlemeyi, iz olaylarını ve sonucu Task'a aktarır. Agent ve Computer üzerindeki eşzamanlılık limitleri, aynı anda kaç çalıştırmanın yürütüleceğini sınırlar ve hiçbir şey kendiliğinden merge edilmez: sonuç Task'a döner, orada bir kişi değişikliği inceler ve merge ile release adımına karar verir. Agent'lar hiçbir zaman bir çalışma ağacını paylaşmaz, dolayısıyla paralel Task'lar birbirlerinin değişikliklerini ezemez.
Sharkly'nin önlemek için tasarlandığı hata modu
Agent'lar bir checkout'u paylaştığında tam olarak neyin ters gittiğini net biçimde ortaya koymakta fayda var, çünkü her belirti çözümün bir parçasına karşılık geliyor.
Branch durumu her çalışma ağacı için globaldir; yani A agent'ı kendi branch'ine geçtiğinde, B agent'ının dosyaları çalışma sürerken ayağının altında değişiverir. Index de globaldir, bu yüzden git add ve git commit farklı task'lardan gelen işleri birbirine karıştırır. İzlenmeyen (untracked) durum çakışır: bir çalıştırmanın build çıktıları ve bağımlılık kurulumları, başka bir çalıştırmanın test sonuçlarını kirletir. Üstüne temizlik borcu birikir; ilk üç sorundan kaçınmak için yapılan her ad-hoc depo kopyası, bir insan onun varlığını hatırlayana kadar diskte durur.
Tek bir paylaşılan dizin, güvenli biçimde ancak bir agent çalıştırabilir. Bunu tmux panelleri ve disiplinle idare ediyorsanız, birden fazla Claude Code agent'ını paralel çalıştırma yazımız bu tavanın neden bu kadar çabuk geldiğini anlatıyor.
Yürütme yığını: Agent, Computer, Runtime, Task
Sharkly, Claude Code, Codex veya diğer yürütme araçlarının yerini almaz. Ekibinizin zaten kullandığı araçların etrafına paylaşılan task, Computer, bağlam, kontrol ve inceleme katmanını ekler. Bu katman konumu, paralel yürütmenin nasıl işlediğini belirler; çünkü Sharkly'nin işi kod yazmak değil, çalıştırmaları koordine etmektir.
İşi dört rol paylaşır ve her birinin tam olarak tek bir görevi var:
- Agent, işin nasıl ele alınacağını tanımlar: talimatları, Skills'leri, depoları ve çalıştırma ayarları. Agent, yürütmenin yapıldığı makine değildir.
- Computer, ana makineyi ve yerel kaynakları sağlar: yerel bir makine, uzak bir sunucu, bir container veya desteklenen bir bulut ortamı. Sharkly'deki Computer'lar hakkındaki kardeş yazımız bunların nasıl bağlanacağını ele alıyor.
- Runtime, gerçek agent oturumunu yürütür. O Computer'da kurulu olan somut araçtır: Claude Code, Codex veya Gemini CLI gibi.
- Task ise ekibin paylaşılan kaydı olarak kalır: hedef, durum, tartışma, yürütme izi ve sonuç.
Bunları birbirine bağlayan şey, Computer üzerindeki küçük bir yerel servistir. Computer'ı kaydeder, kurulu Runtime'ları algılar, kuyruktaki çalıştırmaları alır, her çalıştırma için task dizinini hazırlar, Runtime'ı başlatır ve sonuçları geri bildirir. Sunucuya bağlantıyı kendisi başlatır, dolayısıyla tipik bir kurulumda gelen port gerekmez.
Paralelliği yönetilebilir kılan şey bu ayrımdır. Çalışma dizinini Agent değil de yerel servis her çalıştırma için hazırladığından, iki Task'a atanmış iki Agent aynı Computer'daki aynı depoyu hedefleyebilir ve birbirlerinin dosyalarını hiç görmez. Agent'ların nasıl yapılandırıldığını görmek için Sharkly'deki Agent'lar yazısına bakın.
Bir çalıştırma başladığında ne olur
Bir Task'ı bir Agent'a atayıp Backlog'dan çıkardığınızda Sharkly yürütme hazırlığını kontrol eder, uygun bir çalıştırmayı kuyruğa alır ve seçilen Computer'a gönderir. Buradan sonrasını yerel servis devralır. Runtime başlamadan önce eşzamanlılık kapasitesini beklemesi, izole bir geçici dizin hazırlaması ya da boş bir tanımlı dizini beklemesi, yapılandırılmış depoları çekmesi, izin verilen ortam değişkenlerini yansıtması ve Runtime çağrısını oluşturması gerekebilir.
Runtime ancak bundan sonra başlar. Çalıştırma belirli durumlardan geçer: Queued, Dispatched, Waiting for local directory, Running ve son olarak Completed, Failed veya Canceled. Bu durumlar Task'ın yürütme günlüğünde görünür; böylece "neden hâlâ hiçbir şey olmadı" sorusunun tahmin yerine incelenebilir bir yanıtı olur. Eşzamanlılık limiti dolduğu için Queued'da bekleyen bir çalıştırma, Waiting for local directory'de bekleyenden farklı görünür ve bu fark hangi ayarı çevirmeniz gerektiğini söyler.
Olmayan şeye dikkat edin: Agent hiçbir aşamada nerede çalışacağına karar vermez. Talimatları Agent getirir; izolasyonu altyapı getirir.
İzole worktree'ler: Temporary mode nasıl çalışır
Agent'lar iki çalışma dizini modunu destekler ve paralel çalışma için tasarlanmış olanı Temporary mode'dur. Her Task izole bir dizin alır ve depo tabanlı işlerde yerel servis, önbelleğe alınmış depo verisinden her çalıştırma için ayrı bir git worktree hazırlayabilir.
Bu tek cümle, çakışma önleme hikâyesinin tamamını taşıyor. Bir worktree, alttaki depo nesnelerini paylaşırken her çalıştırmaya kendi checkout dizinini ve kendi branch durumunu verir. Yukarıdaki dört hata modu tasarım gereği ortadan kalkar: paylaşılan branch işaretçisi yok, paylaşılan index yok, paylaşılan build çıktısı yok ve platformun sonradan temizleyebileceği dizinler var. Worktree'ler yeni bir clone yerine önbelleğe alınmış veriden oluştuğu için başlangıç maliyeti makul kalır; yine de bir çalıştırmanın depoyu yenilemek için ağ erişimine ihtiyacı olabilir.
Dokümanlar bunun ne zaman kullanılacağı konusunda net: Temporary mode, paralel kod değişiklikleri ve birden fazla Task'ın aynı kod tabanını aynı anda değiştirebileceği her durum için önerilir.
Açıkça belirtmeye değer bir sınır var: izolasyon, çalışma ağacı çakışmalarını önler, anlamsal çakışmaları değil. İki Task da aynı fonksiyonu yeniden yazarsa, her iki çalıştırma da kendi worktree'sinde sorunsuz tamamlanır ve örtüşmeyi yine bir kişi inceleme sırasında uzlaştırır. Bunun çözümü, Task'ları aynı öğleden sonra aynı kodu hedeflemeyecek şekilde kapsamlandırmaktır: bu bir altyapı kararı değil, planlama kararıdır.
İzolasyonun yanlış seçim olduğu durum: Specified mode
İkinci mod, her çalıştırma için yeni bir dizinin bedava olmaması nedeniyle var. Specified mode'da Agent, havuzundaki yapılandırılmış tek bir mutlak yerel dizin içinde çalışır ve orada zaten bulunan depoyu, bağımlılıkları ve önbellekleri yeniden kullanır. Yalnızca yerel Computer'larda kullanılabilir.
Bu değiş tokuşun katı bir sonucu var: tanımlı bir dizin aynı anda tek bir çalıştırmaya hizmet eder ve yapılandırılmış tüm dizinler meşgulse sıradaki çalıştırma bekler. Specified mode'da birden fazla Task'ı eşzamanlı çalıştırması gereken bir Agent'ın havuzunda birden fazla dizin olmalıdır.
| Temporary mode | Specified mode | |
|---|---|---|
| Çalıştırma başına dizin | Yeni izole dizin; depo işleri için worktree | Havuzdan yapılandırılmış tek bir mutlak dizin |
| Paralel güvenlik | Çalıştırmalar birbirlerinin dosyalarına dokunamaz | Her dizinde aynı anda tek çalıştırma |
| Başlangıç maliyeti | Her çalıştırmada dizini önbellekteki depo verisinden hazırlar | Mevcut kodu, bağımlılıkları ve önbellekleri yeniden kullanır |
| En uygun olduğu durumlar | Paralel kod değişiklikleri, çoğu depo işi | Çok büyük depolar, maliyetli yerel durum, dizine bağlı araçlar |
| Kullanılabilirlik | Bağlı her Computer | Yalnızca yerel Computer'lar |
İzolasyon, hazırlık maliyeti karşılığında güvenlik satın alır; yeniden kullanım ise sıralama maliyeti karşılığında hız. Sharkly bu seçimi her Agent için açıkça yapmanızı sağlar; bu da bozulmuş bir çalışma ağacında bu dengeyi keşfetmekten çok daha iyidir.
Eşzamanlılık limitleri: paralel ama sınırlı
Sınırsız paralellik başlı başına bir hata modudur. Her eşzamanlı çalıştırma CPU, bellek, disk, model sağlayıcı kapasitesi ve depo bant genişliği tüketir; tek bir dizüstü bilgisayarı perişan eden sekiz agent, rahatça çalışan üç agent'tan daha kötü sonuç üretir.
Sharkly eşzamanlılığı iki düzeyde sınırlar. Ana makine olarak Computer'ın bir task eşzamanlılık limiti vardır ve her Agent'ın bir maksimum paralel çalışan Task sayısı ile bir Task başına zaman aşımı vardır. Varsayılanlar temkinlidir: Temporary mode'da bir Agent, Computer'ın limitinin yüzde 50'sini alır; Specified mode'da bu sayı yapılandırılmış dizin sayısına eşittir. Dizin sayısından daha yüksek bir değer ayarlarsanız ürün, yazmaların task'lar arasında çakışabileceği konusunda uyarır. Bu uyarı, bu yazının tezinin tek bir iletişim kutusuna sıkıştırılmış hâlidir.
Dokümanların limitleri yükseltme konusundaki tavsiyesi aklı başında türden: eşzamanlılığı ancak mevcut Computer ve Runtime mevcut iş yükünü güvenilir biçimde kaldırdıktan sonra artırın.
İlerleme akışı ve merge öncesi inceleme
İzolasyon, görünmezlik anlamına gelseydi bir dezavantaja dönüşürdü. Beş gizli dizindeki beş agent, işin özel terminallerde kaybolmasının tam olarak nasıl gerçekleştiğidir. Bu yüzden çalıştırmanın ürettiği her şey paylaşılan kayda geri akar.
Bir çalıştırma etkinken Task, yürütme durumunu gösterir. Activity, yorumları ve task değişikliklerini bir zaman çizelgesinde taşır; yürütme günlüğü çalıştırmanın ne zaman başlayıp bittiğini, araç çağrılarını ve Runtime olaylarını, tetikleyici kaynağı ve varsa hata ayrıntılarını kaydeder; Agent'ın raporu, yürütme izine bağlı bir yorum olarak saklanır. Bağlam, ilerleme, engeller ve sonuçlar, dosya düzenlemeleri hiçbir insanın açmadığı bir dizinde gerçekleşmiş olsa bile talepten release'e kadar görünür kalır.
Sonra kapı geliyor. Burada hiçbir şey kendiliğinden merge edilmez. Agent'lar araştırır, yürütür, test eder ve raporlar. İnsanlar yön belirler, yetki verir ve sonucu kabul eder. Bir çalıştırma tamamlandığında Agent, Task'ı insan incelemesi bekleyecek şekilde bırakabilir; bu da sorumlu kişinin Inbox'ında görünür. İzole worktree'ler paralel yürütmeyi güvenli kılar; inceleme kapısı ise onu güvenilir kılar.
Döngüyü kapatan bir parça daha var: temizlik. Agent çalıştırmaları Computer üzerinde çalışma dizinleri ve çıktı dosyaları bırakır; yapılandırılabilir temizlik, saklama süresi dolduktan sonra tamamlanmış çalıştırmaları geri kazanır ve son bir güvence olarak minimum boş alan eşiği uygular. Çalışan veya kuyrukta bekleyen işlere, sabitlenmiş (pinned) çalıştırmalara ve hâlâ incelenmesi gereken başarısız çalıştırmalara asla dokunulmaz. DIY kurulumların disk dolana kadar tutarlı biçimde unuttuğu angarya tam da budur.
Sharkly'nin otomatikleştirdikleri ve DIY kurulumu
DIY worktree rehberimizi okuduysanız eşleşme birebir. Her agent için script'lediğiniz git worktree add, yerel servisin her çalıştırma için izole bir dizin hazırlamasına dönüşür. "Kaç agent fazla olur" kararı, bir ayar güvensiz olduğunda uyarı veren açık eşzamanlılık limitlerine dönüşür. Unuttuğunuz git worktree prune, saklama süresine dayalı temizliğe dönüşür. Hiçbir script'in size veremeyeceği kısım ise — hangi çalıştırmanın ne yaptığının ve bir kişinin bunu kabul edip etmediğinin paylaşılan kaydı — Task'ın kendisidir.
Dürüst karar ikilisi burada da geçerli. Tek bir makinede iki agent çalıştıran tek kişilik bir geliştirici bir platforma ihtiyaç duymayabilir; bir worktree script'i ve disiplin bir yere kadar yeter. Sharkly'ye, koordinasyonun yazmaktan daha pahalıya geldiği durumlarda uzanın: işi birden fazla kişinin ataması, birden fazla Computer, kuyruklama ve inceleme gerektiren çalıştırmalar. Her iki durumda da hâlihazırda sahip olduğunuz Runtime'ları korursunuz; model kullanımı o araçlarda yapılandırılmış abonelikler veya API anahtarları üzerinden devam eder.
Başlangıç kasıtlı olarak küçük tutulmuş. Bir Computer bağlayın, Temporary mode'da bir Agent oluşturun ve ona düşük riskli bir Task atayın. Başlangıç rehberi ilk döngüyü yaklaşık on dakikada adım adım anlatıyor, Sharkly dokümanları her kavramı ayrıntılı biçimde ele alıyor ve Sharkly nedir yazısı yürütmenin etrafındaki platformu tamamlıyor.
SSS
Sharkly paralel agent'lar arasındaki merge çakışmalarını nasıl önler?
Her Task çalıştırması Computer üzerinde kendi izole dizinini alır ve depo tabanlı çalıştırmaların her biri için yerel servis tarafından ayrı bir git worktree hazırlanabilir. Agent'lar bir checkout'u, bir index'i veya untracked dosyaları asla paylaşmaz; böylece eşzamanlı çalıştırmalar birbirlerinin devam eden işini ezemez. İki Task'ın bilinçli olarak aynı kodu değiştirdiği örtüşmeler ise inceleme sırasında yine bir kişi tarafından uzlaştırılır.
Sharkly'yi kullanmak için git worktree'leri kendim mi kurmalıyım?
Hayır. Temporary mode'da yerel servis, depo tabanlı işler için worktree'ler dahil olmak üzere her çalıştırma için task dizinini hazırlar. Modu Agent üzerinde bir kez yapılandırırsınız; script'lemeniz gereken çalıştırma başına worktree komutu yoktur. İşleyişin arkasındaki mekanizmayı anlamak için git worktree dokümantasyonuna bakın.
Bir Computer üzerinde kaç agent paralel çalışabilir?
Computer'ın kendi task eşzamanlılık limiti vardır ve her Agent'ın bir maksimum paralel çalışan Task sayısı bulunur. Varsayılan olarak Temporary mode'daki bir Agent, Computer'ın limitinin yüzde 50'sini alır; Specified mode'daki bir Agent ise yapılandırılmış her dizin için bir slot alır. Limiti aşan çalıştırmalar kuyrukta bekler.
Sharkly agent'ın değişikliklerini otomatik olarak merge eder mi?
Hayır. Çalıştırmanın sonucu, kanıtları ve izi Task'a döner ve herhangi bir şey yayına çıkmadan önce bir kişi değişiklik özetini inceler. İnceleyen kişi kabul eder, değişiklik ister veya merge ve release adımına karar verir. Otomasyon, ekip muhakemesinin gerektiği yerde durur.
İzole worktree'ler yerine Specified mode'u ne zaman kullanmalıyım?
Her çalıştırma için yeni bir dizin hazırlamak gerçekten pahalıysa kullanın: çok büyük bir depo, maliyetli üretilmiş durum veya önbellekler ya da tek bir yerel yola bağlı araçlar. Her tanımlı dizinin aynı anda tek bir çalıştırmaya hizmet ettiğini kabul edin. Diğer her şey için önerilen varsayılan Temporary mode'dur.
