Bu sabah dört ajan başlattınız. Biri auth modülünü yeniden düzenledi, biri testleri yazdı, biri kararsız bir CI işinin peşine düştü, biri de hâlâ düşünüyor. Öğleden sonra olduğunda elinizde bir şeylerin olduğuna dair belirsiz bir his, bir yığın terminal sekmesi, yarattığınızı yarım yamalak hatırladığınız üç worktree ve okumadığınız iki pull request var. İş yapıldı. Ama ne olduğunu göremiyorsunuz.
AI kodlama ajanlarının tamamladığı işleri takip etmek, bu dağınıklığı bir kayda dönüştürme sorunudur: her ajanın neyi değiştirdiği, bunun sağlam olup olmadığı ve nereye ulaştığı. Bu gerçek bir sorun, çünkü ajanlar sizin onları inceleyebileceğinizden hızlı bitiriyor ve ne yaptıklarının kanıtı, tek başına çalışan bir kişi için tasarlanmış yerlerde duruyor. Bu kılavuz önce manuel kurulumu adım adım anlatıyor, nerede tıkandığını gösteriyor ve ardından Sharkly'nin her sonucu, onu isteyen göreve bağlı tutmak için kullandığı iş akışını sunuyor.
Kısa özet: bir iki ajanı git ve terminalinizle elle takip edebilirsiniz. Bunun ötesinde, sonuçların kendiliğinden geldiği ortak bir yere ihtiyacınız var; çünkü darboğaz artık kodlama değil, onu inceleyebilme kapasiteniz oluyor.
TL;DR
Tamamlanan ajan işlerini takip etmek, her çalıştırma için üç soruyu yanıtlamak demektir: ne değişti, doğru mu ve nereye ulaştı. Git geçmişi ve pull request'ler bir ya da iki ajan için ilkini yanıtlar. Birkaç ajan paralel çalışmaya başladığında kayıt worktree'lere, terminallere ve PR kuyruklarına dağılır ve görev ile sonucu arasındaki bağ kopar. Bir görev panosu bunu, yürütmeyi, engelleri, sonuçları ve insan incelemesini tek bir göreve geri döndürerek çözer; böylece tamamlanan iş yeniden kurgulanmak yerine incelenebilir olur.
Tamamlanan işleri takip etmek ne anlama gelir
Takip, bir etkinlik günlüğü değildir. Bitmiş bir çalıştırma hakkında, onu tersine mühendislik yapmadan üç soruyu yanıtlayabilme becerisidir.
- Ne değişti. Diff, dokunulan dosyalar ve her birinin gerekçesi.
- Doğru mu. Tip kontrolü, testler, derleme ve ajanın neyi doğruladığının bir özeti.
- Nereye ulaştı. Branch, PR, ait olduğu görev ve kimin kabul ettiği.
Sessizce biten bir ajan teknik olarak işi tamamlamıştır, ama onunla bir şey yapamazsınız. Sizin önemsediğiniz tamamlanma durumu, bir insanın inceleyip kabul edebileceği durumdur. Bu yüzden "testler geçti" demek, "iş takip ediliyor" demekle aynı şey değildir.
Kodlama ajanları için insan döngüde (human-in-the-loop) modeli sınırı çizer: ajanlar araştırır, yürütür, test eder ve raporlar; insanlar yön belirler ve sonucu kabul eder. Takip, ikinci yarıyı mümkün kılan mekanizmadır.
Kendin yap kurulumu, adım adım ve her adımın nerede tıkandığı
Tek branch'te tek bir ajan için yerleşik araçlar yeterlidir. İşte her adımda başarısızlık modunu da söyleyen dürüst versiyon.
1. Adım: Neyin değiştiğini görün. Bir çalıştırmadan sonra diff'i okursunuz.
git log --oneline -10
git diff main...HEAD --stat
Şu durumda tıkanır: iki ajan aynı branch'i paylaşıyorsa ya da bir ajan hiç commit yapmayıp değişiklikleri unuttuğunuz bir worktree'nin working tree'sinde bırakıyorsa. Okuduğunuz diff, sevk edilen diff değildir.
2. Adım: Her ajanın işini izole edin. Çakışmasınlar diye her ajana kendi git worktree'sini verirsiniz.
git worktree add ../auth-refactor -b auth-refactor
git worktree list
Şu durumda tıkanır: liste, aklınızda tutabileceğinizin ötesine geçtiğinde. git worktree list size yolları söyler; her birinde hangi ajanın olduğunu, hangi göreve hizmet ettiğini ya da bitip bitmediğini söylemez. Mekanik için resmi git-worktree dokümanlarına bakın; onlar da kayıt tutmanın ötesine geçmez.
3. Adım: Sonuçların bir PR'a ulaşıp ulaşmadığını kontrol edin. GitHub'a yaslanırsınız.
gh pr list --author "@me" --state open
gh pr view 214 --json title,statusCheckRollup
Şu durumda tıkanır: PR var ama kimse nedenini yazmamışsa, ya da değişiklik yanlışken kontroller yeşilse, ya da PR'ın onu başlatan talebe geri giden bir bağlantısı yoksa. gh pr list referansı size açık PR'ları gösterir, niyeti değil.
4. Adım: Ne istediğinizi hatırlayın. Bu adımın bir komutu yok. Asıl gereksinim bir Slack mesajında, bir notta ya da hafızanızda yaşıyor. Üç gün sonra PR'ı incelerken kabul kriterlerini tahmin ediyorsunuz.
Her adım çalışıyor. Sorun, aralarındaki ek yerlerinde. Diff, izolasyon, PR ve niyet, birbirinden habersiz dört farklı sistemde yaşıyor ve onları birbirine bağlayan tek şey sizsiniz.
Manuel kurulum nerede ölçeklenmeyi bırakır
Kırılma tek bir an değil. Bir eğim ve onun neresinde olduğunuzu söyleyebilirsiniz.
| Paralel ajan sayısı | Takibin maliyeti | İlk bozulan şey |
|---|---|---|
| 1 | Tek diff, tek PR okumak | Hiçbir şey |
| 2-3 | Worktree'ler arasında bağlam değiştirmek | Hangi ajanın ne yaptığını kaybediyorsunuz |
| 4-6 | Her PR için niyeti yeniden kurgulamak | Sonuçlar inceleme kapasitenizi aşıyor |
| 7+ | Tam zamanlı koordinasyon | Tamamlanan iş günlerce incelenmeden bekliyor |
Gerçek maliyet, ajan hızıyla değil inceleme kapasitesiyle ölçülür. Ajanlar tamamlanmış işi, bir kişinin inceleyebileceğinden daha hızlı üretir; bu yüzden birkaç çalıştırmadan sonra veriminiz, ajanların ne kadar hızlı kodladığıyla değil, sizin üç soruyu ne kadar hızlı yanıtlayabildiğinizle sınırlanır. Daha fazla ajan eklemek teslimat sorununu değil, takip sorununu büyütür.
Bir görev panosu ne katar
Çözüm, tamamlanan bir çalıştırmayı bir diff olarak görmeyi bırakıp göreve geri dönen bir şey olarak görmeye başlamak.
Sharkly'de görev, ortak kayıttır. Bir görevi bir ajana ya da bir Crew'e atarsınız ve çalıştırma izole bir worktree'de gerçekleşir; böylece paralel ajanlar aynı dosyalara asla dokunmaz. İş bittiğinde yürütme, engeller, sonuçlar ve takip işleri görev zaman çizelgesine döner. Değişiklik özeti, doğrulama sonuçları ve bilinen sınırlar, hâlâ açık tutmak zorunda olduğunuz bir terminale değil, görevin kendisine bağlanır.
Bir günlük ile bir kayıt arasındaki fark budur. Günlük size bir şeylerin olduğunu söyler. Kayıt ise neyin değiştiğini, doğru olup olmadığını ve nereye ulaştığını, hepsini tek bir yerde, onu başlatan talebe bağlı olarak söyler. Tamamlanan işi görevden incelersiniz, kabul edersiniz ya da geri gönderirsiniz ve kararın altında sizin adınız vardır.
Kendin yap yaklaşımının ek yerleri tam burada kapanır. Niyet, diff, kontroller ve kabul tek bir nesnede yaşar. Ajanlarınızın zaten kullandığı araçları korursunuz; yürütmeyi hâlâ Claude Code ve Codex yapar, Sharkly ise etraflarına görev, bağlam ve inceleme katmanını ekler. Böylece bir AI ajanına iş atamak, bir ekip arkadaşına atamak gibi okunur ve sonuç, bulabileceğiniz bir yere geri döner.
Ölçeklemeden önce tek bir gerçek görevde denemek için Sharkly'yi indirip bir Computer bağlayabilirsiniz.
Bunların hiçbirine ihtiyacınız olmadığında
Eşik konusunda dürüst olun. Tek bir repoda tek bir kodlama ajanı çalıştırıyorsanız ve merge edilmeden önce her diff'i okuyorsanız, git ve terminaliniz tamamlanan işlerinizi zaten takip ediyor. Bir görev panosu, ihtiyacınız olmayan bir tören katardı. Claude Code'un yerleşik proje görünümü, tek ajanlı bir iş akışı için şaşırtıcı derecede çok şey kapsıyor.
Denklem, üç şey üst üste bindiğinde değişir: aynı anda birkaç ajandan fazlası, bittiği gün inceleyemeyeceğiniz işler ve sizden başkasına ulaşması gereken sonuçlar. İşte o zaman ortak bir görev kaydı, fazlalık olmaktan çıkıp tamamlanan işin talepten sürüme kadar görünür olmasının tek yolu haline gelir.
Bugün uygulayabileceğiniz bir kontrol listesi
Bir ajan daha eklemeden önce, hâlihazırda çalışanlar için şu maddelerin her birine evet diyebildiğinizden emin olun:
- [ ] Bitmiş herhangi bir çalıştırma için, terminal açmadan bir dakikadan kısa sürede diff'i bulabiliyor musunuz?
- [ ] Tamamlanan her çalıştırma, yalnızca yeşil kontroller değil, ajanın neyi doğruladığının bir özetini de taşıyor mu?
- [ ] Bir PR'ı onu başlatan gereksinime kadar izleyebiliyor musunuz?
- [ ] Hangi ajanın ne üzerinde olduğunu, neyin bittiğini ve neyin incelenmesi gerektiğini gösteren tek bir yer var mı?
- [ ] Tamamlanan işi kabul etmenin altında bir kişinin adı var mı?
- [ ] Bir ajan bitirdiğinde sonuç size mi geliyor, yoksa gidip onu bulmanız mı gerekiyor?
Herhangi bir "hayır", ajan ekledikçe genişleyecek bir ek yeridir. Bunu erkenden düzeltmek, bir haftalık takip edilmemiş çalıştırmayı sonradan yeniden kurgulamaktan daha ucuzdur.
SSS
Bir AI kodlama ajanının neyi değiştirdiğini nasıl takip ederim? Ajanın özetini değil, diff'in kendisini okuyun. Tek ajan için git diff ve PR yeterlidir. Birkaç ajan için her çalıştırmayı kendi worktree'sinde tutun ve diff ile bir doğrulama özetini ortak bir göreve yönlendirin; böylece onu terminal geçmişinden yeniden kurgulamak zorunda kalmazsınız.
AI ajan işlerini tek başına GitHub ile takip edebilir miyim? Bir ya da iki ajan için evet. GitHub size açık PR'ları ve kontrol durumunu gösterir. Hangi ajanın bir PR ürettiğini, o PR'ın hangi göreve hizmet ettiğini ya da değişikliğin asıl niyetle örtüşüp örtüşmediğini söylemez; bu yüzden birkaç ajan paralel çalışmaya başlayınca hızla yetersiz kalır.
Bir görev panosuna ihtiyaç duymadan önce kaç ajan çalıştırabilirim? Çoğu kişi ek yerlerini üç-dört paralel ajan civarında hisseder; o noktada her PR için niyeti yeniden kurgulamak, incelemenin kendisinden daha fazla zaman yemeye başlar. Tetikleyici, sabit bir sayı değil inceleme kapasitesidir. Paralel kodlama ajanlarını yönetme üzerine notumuza bakabilirsiniz.
Bir görev panosu hızlı ilerleyen ajanları yavaşlatır mı? Hayır. Ajanlar yine izole worktree'lerde tam hızda çalışır. Pano, tamamlanan işlerinin inceleyebileceğiniz bir yere inmesi için bir dönüş yolu ekler; bu da manuel yeniden kurgulama adımını ortadan kaldırır, yenisini eklemez.
