Bu sabah üç kodlama ajanını başlattınız. Biri kimlik doğrulama modülünü refactor ediyor, biri test yazıyor, diğeri ise dengesiz (flaky) bir CI işinin peşinde koşuyor. Bir saat sonra önünüzde açık beş terminal, arka planda çalışan iki tmux bölmesi ve iç kemiren bir his var: En azından bir tanesi muhtemelen bir süre önce durdu ve siz bakmıyorken boşta bekliyor. Alt-tab yapıyorsunuz, log'ları kaydırıyorsunuz ve tahmin yürütüyorsunuz.
Ajanları paralel çalıştırmanın asıl maliyeti de işte bu tahmin yürütme sürecidir. Artık birden fazla kodlama ajanını aynı anda başlatmak oldukça kolay. Ancak hangisinin size ihtiyacı olduğunu, hangisinin tıkandığını ve hangisinin sessizce tamamlandığını kestirmek öğleden sonranızı heba eden kısımdır. Paralel kodlama ajanlarını izlemek, beş ayrı pencere açmak zorunda kalmadan anlık olarak dört soruyu yanıtlayabilmek demektir: Her bir ajan ne yapıyor, ne kadar ilerledi, onu ne engelliyor ve inceleme bekleyen ne çıktı üretti?
Bu rehberde öncelikle kendi imkanlarınızla kurabileceğiniz (DIY) izleme yapısını ele alacak, her adımdaki hata modlarını belirtecek, ardından bu kurulumun nerede tıkanmaya başladığını ve paylaşımlı bir görev katmanının neler kattığını göstereceğiz. Bu paylaşımlı katman Sharkly'dir: Halihazırda kodlama ajanlarına sahipsiniz ve Sharkly, her ajanın ilerlemesini, engelleyicilerini ve sonuçlarını terminallere saçılmış halde bırakmak yerine tek bir yerde görünür kılarak onları bir takıma dönüştürür. İzleme altyapısının büyük kısmını manuel olarak da kurabilirsiniz. İki yöntemi de adım adım incelememizin amacı, el yapımı yöntemin ne zaman tasarruf sağladığından daha fazla maliyet yaratmaya başladığını tam olarak görmektir.
Takip etmeye değer dört sinyal
İzleme tek bir boyuttan ibaret değildir. İnsanlar bir ajanın çalışması için "sorunsuz görünüyor" dediğinde, genellikle dört ayrı sinyalden birini kastederler ve bunların her biri farklı şekillerde aksar.
- Durum (State). Süreç çalışıyor mu, girdi mi bekliyor, bitti mi yoksa çöktü mü? Tamamlanmış bir ajan da donup kalmış bir ajan da yeni çıktı üretmez; bu nedenle tek başına sessizlik size hiçbir şey anlatmaz.
- İlerleme (Progress). Görevin ne kadarı tamamlandı? Planda işaretlenen adımlar, değiştirilen dosyalar, geçen testler. İlerleme, çalışan bir ajanın sonsuz bir döngüde debelenmek yerine gerçekten yol aldığını gösteren şeydir.
- Engelleyiciler (Blockers). Ajan neyi bekliyor? Bir izin onayı, eksik bir ortam değişkeni (environment variable), bir merge çakışması veya sorduğu ama kimsenin yanıtlamadığı bir soru.
- İnceleme gerektiren çıktı (Output needing review). Ajan, bir insanın kabul veya reddetmesini gerektiren ne üretti? Bir diff, bir PR veya değişikliklerin bir özeti.
Yalnızca durumu izlerseniz, çalışır görünen ancak yeniden deneme döngüsüne sıkışmış ajanı kaçırırsınız. Yalnızca ilerlemeyi izlerseniz, yirmi dakika önce işini bitirmiş olanı fark edemezsiniz. İyi bir izleme kurgusu, her bir ajan için bu dört sinyalin tamamını tek bakışta görünür kılmalıdır.
1. Adım: El yordamıyla izleme ve her adımın nerede açık verdiği
El yapımı kurulum, zaten sahip olduğunuz araçları kullanır. Her adımın ardında bıraktığı boşluklarla birlikte meselenin dürüst özeti şöyledir:
Neyin çalıştığını görmek. Her ajan kendi git worktree dizininde çalışıyorsa, bunları ve dallarını listeleyin:
git worktree list
tmux ls # if each agent runs in a tmux session
Hata modu: Bu yöntem size bir oturumun var olduğunu söyler, ancak içindeki ajanın çalışıp çalışmadığını ya da bekleyip beklemediğini göstermez. Bir Continue? (y/n) isteminde takılıp kalmış bir tmux bölmesi ile görevin ortasında çalışan bir bölme tamamen aynı görünür. Bunu ancak oturuma bağlandığınızda (attach olduğunuzda) anlarsınız.
İlerlemeyi takip etmek. Her ajanın çıktısını tail edin ve değişiklikler için worktree'yi yoklayın:
tail -f /path/to/agent-1.log
watch -n 5 'git -C ../wt-auth status --short'
Hata modu: Bu yaklaşım ajan sayısıyla doğrusal olarak ölçeklenir. Üç log okunabilir düzeydedir. Ancak birbirine karışan altı log tail'ı kesinlikle okunamaz ve watch döngüleri size anlamlı bir bilgi değil, yalnızca dosya hareketliliği sunar. Değişikliğin doğru olup olmadığı veya ajanın kendini tekrar edip etmediği hakkında hiçbir fikriniz olmadan dosyaların değiştiğini izlersiniz.
Tamamlanmaları yakalamak. Süreç sonlandığında size bildirim göndermesi için her ajanı bir komutla sarın:
your-agent-command "$TASK"; \
curl -s -X POST "$WEBHOOK_URL" -d "agent-1 exited $?"
Hata modu: Çıkış kodunun 0 olması yalnızca sürecin bittiğini gösterir; işin kaliteli, hatta tamamlanmış olduğu anlamına gelmez. Birçok ajan, hiç görmediğiniz bir soru sorduktan sonra da temiz bir şekilde çıkış yapar. "Bitti" bildirimi, aslında işin bittiğini garanti etmeyen bir sinyale güvenmenize yol açar.
Çakışmaları tespit etmek. Birden fazla ajan aynı depoyu paylaştığında, worktree'ler çalışma dizinlerini birbirinden ayrı tutar; ancak iki ayrı dalda aynı dosyayı düzenleyen iki ajan merge sırasında yine de çakışır.
git worktree list --porcelain | grep branch
Hata modu: Çakışmayı ancak merge etmeye çalıştığınızda fark edersiniz, bu da durumu öğrenmek için en maliyetli andır.
Bunların hiçbiri yanlış değildir. Birbiriyle ilgisiz görevlerde çalışan iki veya üç ajan için birkaç tmux bölmesi ve bir watch döngüsü makul bir izleme yöntemidir ve daha karmaşık bir araca ihtiyaç duymazsınız. Duvara tosladığınızı hissedene kadar hareketli parça sayısını minimumda tutun.
El yapımı izlemenin yetersiz kaldığı an
Bu sınır, tek bir ekrana sığmayacak kadar çok ajan çalıştırmaya başladığınız noktada kendini gösterir. Üç temel sorun birleşerek büyür:
Sürekli yoklama (polling) durumu söyler, sebebi değil. git status ve log tail'ı size bir şeylerin değiştiğini veya çıktının durduğunu gösterir. Ancak ajanın bir girdi isteminde mi takıldığını, eksik bir bağımlılık yüzünden mi durduğunu yoksa işini bitirdiğini mi söyleyemez. Teşhis koymak için oturumlara tek tek bağlanmak zorunda kalırsınız; bu da paralelleştirmenin ortadan kaldırması gereken terminal değiştirme trafiğinin tam olarak ta kendisidir.
Paylaşılan bir durum yoktur. İzleme mekanizmanız dizüstü bilgisayarınızda, tmux sunucunuzda veya kabuk geçmişinizde yaşar. Bir ekip arkadaşınız hangi ajanın hangi görevi üstlendiğini göremez; kapağı kapattıktan sonra siz de göremezsiniz. Bir ajan uzak bir makinede çalıştığında ise yerel tail yaklaşımı tamamen işlevsiz kalır.
İnceleme süreci darboğaza dönüşür. İnsanların en çok hafife aldığı nokta budur. Çıktıların incelenmesi tek kişilik bir sıraya geri dönüp seri hale geliyorsa, ajanları paralel çalıştırmanın hiçbir faydası kalmaz. "İncelendi / değişiklik istendi / merge edildi" durumlarını takip edecek ortak bir yer olmadan tamamlanan beş diff, beş ayrı tarayıcı sekmesi ve akılda tutulmaya çalışılan notlardan ibarettir. Ajanlar hızlanmış, insan ise yavaşlamıştır.
O noktada eksikliğini duyduğunuz şey daha fazla terminal değildir. Eksik olan, paylaşılan ortak bir kayıt sistemidir.
Görev panosunun kattıkları: Sonuçlar tek bir yerde toplanır
Bir görev katmanı, izlemenin temel birimini "bir bölmedeki süreç" olmaktan çıkarıp "durumu olan bir Göreve (Task)" dönüştürür. Sharkly'nin etrafında inşa edildiği temel dönüşüm budur ve bahsettiğimiz dört sinyalle doğrudan örtüşür.
Her ajan çalıştırması bir Göreve (Task) bağlanır. Durum, ilerleme, engelleyiciler ve sonuçlar, yalnızca sizin görebildiğiniz bir log dosyasında kalmak yerine o Görevin zaman çizelgesine yansıtılır. Sürekli yoklamak yerine bir panoyu takip edersiniz: Hangi Görevler devam ediyor, hangileri engellendi, hangileri tamamlandı ve sizden onay bekliyor. Sharkly'nin Gelen Kutusu (Inbox), insan müdahalesi gerektiren çalışmaların yüzeye çıktığı yerdir; böylece soru "bir şeyler bitti mi?" olmaktan çıkar, "işte kararıma ihtiyaç duyanlar" haline gelir. Ajanlar araştırır, yürütür, test eder ve raporlar; insanlar ise yönü belirler, yetki verir ve sonucu kabul eder. Muhakeme gerektiren yerde otomasyon durur.
Buradaki sınır önemlidir, çünkü yanlış varsayımlarda bulunmak kolaydır: Sharkly ajanı çalıştırmaz veya kodu yazmaz. Claude Code, Codex ve halihazırda kullandığınız diğer çalışma zamanları (runtime) yürütme işini yapmaya devam eder. Sharkly, bunların etrafına paylaşımlı görev, bilgisayar, bağlam ve inceleme katmanını ekler; böylece bir çalışmanın ilerlemesi ve oluşturduğu diff, talepten yayına kadar tüm ekibin görebileceği bir yere aktarılır. Ayrıca her çalışmayı kendi izole worktree'sinde tutar, böylece normalde merge sırasında fark edeceğiniz aynı dosya çakışmaları Görev bazında kontrol altına alınır.
Dürüst karar kuralı şudur: Birbirinden bağımsız işlerde bir veya iki ajan çalıştırıyorsanız ve işi asla başkasına devretmiyorsanız, el yapımı izleme yeterlidir ve Sharkly gereksiz bir ek yük (overhead) olur. Ancak ajan sayısı ekranlarınızı aştığında, işler başında oturmadığınız makinelerde çalıştığında veya diğer insanların aynı panoyu görmesi gerektiğinde denklem değişir. Tek bir ekosisteme bağlı kalmak yerine birden fazla kodlama ajanını bir arada kullanmaya devam etmek istiyorsanız, bu ortak görünüm tam da Sharkly'nin çözmek için tasarlandığı problemdir. Bu panoda nelerin yer alması gerektiğine dair daha geniş bir bakış açısı için bir yapay zeka kodlama ajanı kontrol panelinin gerçekte neler göstermesi gerektiğine göz atabilirsiniz.
Bugün uygulayabileceğiniz izleme kontrol listesi
İster el yapımı yöntemle devam edin ister paylaşımlı bir katmana geçin, paralel çalışan ajanları izleme sistemi tek bir oturuma bile bağlanmanıza gerek kalmadan şu sorulara yanıt verebilmelidir:
- Her ajan adı belirlenmiş bir göreve atanmıştır. Anonim bir "agent-3" yoktur. Her birinin ne için çalıştığını söyleyebilmelisiniz.
- Durum bir bakışta görülebilir. Çalışıyor, girdi bekliyor, tamamlandı veya başarısız oldu gibi durumlar sessizlikten tahmin edilmez, açıkça ayırt edilir.
- Engellenen ajanlar el kaldırır.
y/nonayı bekleyen bir komut istemi, eksik bir gizli anahtar (secret) veya yanıtsız bir soru, sessizce beklemek yerine dikkatinize sunulur. - Tamamlanma, yalnızca çıkış yapmak değil, incelenebilir olmak demektir. Biten bir çalıştırma yalnızca bir çıkış kodunu değil, bir diff'i veya PR'ı işaret eder.
- İncelemenin kendi durumu vardır. İncelendi, değişiklik talep edildi ve merge edildi durumları takip edilir; böylece paralel ilerleyen işler yeniden teker teker incelenen bir kuyruğa dönüşmez.
- Görünüm dizüstü bilgisayar kapandığında da korunur ve paylaşılabilirdir. Durum bilgisi kabuk geçmişinizden başka bir yerde tutulur.
- Aynı depodaki çalışmalar izole edilmiştir. Her ajanın kendi worktree'si vardır ve dosya çakışmaları merge sırasında değil, öncesinde ortaya çıkar.
Mevcut kurulumunuzu bu listeye göre gözden geçirin. Bugün işaretleyemediğiniz maddeler, yarın size bir öğleden sonraya mal olacak olanlardır. Zaten birden fazla ajan çalıştırıyorsanız, Sharkly onların görevlerini ve sonuçlarını tek bir yerden yönetmenizi sağlar. Ayrıca halihazırda kullandığınız çalışma zamanlarını koruyarak mevcut kodlama ajanlarınızı Sharkly üzerinden çalıştırabilirsiniz.
