Copilot CLI’da Akıllı Subagent Delegasyonu: Az Devretmek Daha İyi
İtiraf edeyim, Açık konuşayım: Ajan mimarileri konuşulunca herkesin aklına ilk “ne kadar çok subagent, o kadar iyi” fikri geliyor. Hâlbuki sahada gördüğüm şey biraz tersine — ki bu tartışılır — dönüyor; daha fazla devretme, çoğu zaman daha fazla bekleme, daha çok tool çağrısı ve arada bir de patlayan işlem demek oluyor. GitHub Copilot CLI tarafında geçtiğimiz haftalarda gelen “smarter subagent delegation” güncellemesi, işte tam bu sezgiye çarpıp yön değiştiren bir mühendislik kararı. Bence burada durup düşünmek lazım.
Evet.
Peki neden? Çünkü burada mesele sadece hız değil, akış da bozuluyor. Bir işi bölüp parçalıyorsun ama sonra o parçaları tek tek dolaştırıyorsan, subagent kullanmanın pek de tadı kalmıyor. Açık konuşayım, bu noktada biraz kendini kandırmış oluyorsun.
Bazen de tam tersi oluyor. Ana ajan işi tek (söylemesi ayıp) başına halledebilirken gereksiz delegation açılıyor; şey gibi düşünün, iki satırlık işi ekip toplantısına çevirmek gibi. Ben böyle durumlarda önce şuna bakarım: bu görev gerçekten ayrı kollara ayrılıyor mu, yoksa sadece “öyleymiş gibi” mi dürüyor?
Neyse uzatmayalım, buradaki kritik fark şu: doğru yerde devretmek lazım, yanlış yerde değil. Bir bakıma, yukarıda bahsettiğim o paralel kullanım var ya, işte orada kazanılan şey yalnızca süre değil; sistemin nefes alması da oluyor. Tabiî her iş paralel değildir, ama bağımsız olanları sıraya koymak da biraz inat olur — valla güzel iş çıkarmışlar —
Evet, doğru duydunuz.
Sayıları Biraz Açalım: %5 Hızlanma Az mı, Çok mu?
Şunu söyleyeyim, İlk bakışta P95 tarafında gelen %5 iyileşme ufak gibi dürüyor. Ama işin aslı biraz başka. Bu metrik, en yavaş %5’lık oturumların bekleme süresine bakıyor; yanı uzun süren, dallanan budaklanan görevlerde, hani kullanıcıyı en çok geren kısımda, gözle görülür bir rahatlama var. P75’teki %3 işe daha gündelik oturumların yavaşlayan üçünü gösteriyor.
Doğrusu, Daha da önemlisi, bu hızlanma kaliteyi bozup gelmiyor. Yanı “daha az delege ettim ama yanlış sonuç verdim” gibi sınır bozucu bir tablo yok. Güzel tarafı da burada zaten. Tahmin eder mısınız? Çünkü ajan optimize etmeunda en kolay düşülen tuzaklardan biri, hız uğruna doğruluğu biraz kenara itmek oluyor; sonra elinizde hızlı ama şaibeli bir sistem kalıyor.
Bakın, burayı atlarsanız yazının kalanı anlamsız kalır.
Evet.
| Metrik | Iyileşme | Anlamı |
|---|---|---|
| Tool hataları (oturum başı) | %23 azalma | Daha az başarısız işlem |
| Arama hataları | %27 azalma | Tekrarlı ve hatalı grep’ler düştü |
| Düzenleme hataları | %18 azalma | Stale context kaynaklı yanlış edit’ler azaldı |
| Bekleme P95 | %5 iyileşme | Uzun görevlerde belirgin hızlanma |
| Bekleme P75 | %3 iyileşme | Tipik oturumlarda hafif iyileşme |
Türkiye’deki Ekipler İçin Bu Ne Anlama Geliyor?
Şimdi asıl konuya gelelim. İlginç, değil mi? Bu değişiklik sadece “CLI biraz daha hızlı çalışıyor” demek değil, işin içinde daha derin bir ders var; bence ajan tasarımı yapan herkesin kulağına küpe olacak türden bir şey bu, hele Türkiye’de son bir yılda gördüğüm pratikleri düşününce.
Yerli ekipler ajan sistemleri kurarken iki uca savruluyorlar. Bir grup, “tek dev LLM call’la her şeyi hallederiz” deyip işi tek bir prompt’a sıkıştırıyor, diğer grup işe “her alt görev için ayrı agent” diyerek mikroservis gibi ajan zoo’su kuruyor; ikisi de açık konuşayım, pek iyi gitmiyor. GitHub’ın yaptığı şey tam burada ortayı bulmak: bir orkestratör var,. Mantıklı değil mi? Gereksiz delegasyon yapmayan bir orkestratör, yanı her gördüğü işi başkasına atmıyor.
Bunu kurumsal Azure danışmanlığında sık görüyorum. Foundry ya da Agent Framework üzerinde ajan tasarlayan ekipler, çoğu zaman “specialist agent” desenine fazla yaslanıp gereksiz latency biriktiriyor; halbuki ana ajan. Model olarak yetkin oluyor (özellikle GPT-4 sınıfı modellerde), o yüzden basit işi devretmek bazen çözüm değil, yeni dert çıkarıyor. Bu arada Microsoft Agent Framework’te Asıl Değişim: Harness, Hosted Agents ve CodeAct yazımda harness tasarımının önemine değinmiştim — orada da benzer mantık çalışıyor, yanı iş parçalamak her zaman daha iyi sonuç vermiyor.
Küçük ekipler için pratik öneri
Eğer 5-10 kişilik bir geliştirici ekibiniz varsa ve Copilot CLI’ı yeni deniyorsanız, özel bir delegasyon stratejisi tasarlamayın. Default davranışa güvenin; çünkü artık default taraf baya iş görüyor. Sadece terminalden /update komutuyla 1.0.42 veya üzerine geçtiğinizden emin olun, sonra bakın fark ediyor mu etmiyor mu — dürüst olayım, biraz hayal kırıklığı —
Kurumsal ekipler için
Eğer GitHub Enterprise üzerinde Copilot CLI’ı yaygınlaştırıyorsanız, telemetri tarafında dikkat etmeniz gereken şey subagent çağrı oranındaki düşüş. Bu düşüş normaldir, panik yapmayın; hatta bazen iyiye işaret bile olabilir. “Neden subagent kullanımı azaldı, sistem bozuldu mu?” diye sormak yerine “tool error rate düştü mü?” sorusuna odaklanın. Doğru metrik bu, gerisi biraz gürültü.
Maliyet Tarafı: Token Ekonomisi Açısından Bakınca
Bir de şu taraf var, pek konuşulmuyor ama aslında can sıkıyor: her subagent çağrısı ekstra token yiyor. Mantıklı değil mi? Çünkü subagent’ın kendi system prompt’u var, kendi context’i var, bir de üstüne tool tanımları geliyor; ana ajan tek başına 2K token harcayacaksa, subagent devreye girince iş 5-6K’ya kadar uzayabiliyor, yanı küçük gibi duran şey ay sonunda hiç de küçük kalmıyor.
Aylık ölçekte bakınca tablo daha netleşiyor. Mesela dolar bazlı faturalandırmada, Türkiye’deki kurumsal müşteriler için bu kalem baya hissediliyor. Smarter delegation burada dolaylı bir fayda da sağlıyor; GitHub net rakam vermemiş ama tool failure’ların %23 düşmesi, başarısız. Tekrar eden çağrıların azalması demek, bu da oturum başına token tüketimini aşağı çekiyor gibi dürüyor.
Hmm, bunu nasıl anlatsamdı…
Subscription bazlı bir üründe son kullanıcı çoğu zaman bunu fark etmiyor. Ama enterprise seat planlaması yapan IT yöneticisi için durum başka. Hani raporda küçük bir satır gibi dürüyor ya, işte tam orada bütçeyi etkileyen detay saklanıyor.
Aynı Prensip Diğer Ajan Sistemlerine de Uygulanır mı?
Bence evet, hatta çoğu yerde daha da net çalışıyor. Şöyle bir kontrol listesi var kafamda, ve açık konuşayım, yeni bir ajan mimarisi çizerken ilk baktığım şeylerden biri bu oluyor:
- Görev karmaşıklığı eşiği: Görev N adımdan azsa, ana ajan kendi yapsın. N için pratik bir başlangıç noktası: 3.
- Context yeterliliği: Kullanıcı isteği zaten dosya yolu, fonksiyon adı gibi spesifik bilgi içeriyorsa, keşif subagent’ı çağırma.
- Bağımsızlık testi: İki alt görev birbirinden gerçekten bağımsızsa paralel çalıştır. Bağımlıysa sequential bile değil, tek ajanda birleştir.
- Idempotency kontrolü: Subagent’ın yapacağı arama, ana ajanın son 5 dakika içinde yaptığı bir arama mı? Cache’le veya skip et.
- Wait-time budget: Subagent çağrısı için bir timeout koy. Belirli süre içinde dönmezse, ana ajan kendi yoluna devam etsin.
Bunu yaşayan biri olarak söyleyeyim, Peki neden? Çünkü her işi devretmek iyi fikir gibi dürüyor ama değil. Bazen ana ajan elindeki context ile işi zaten çıkarıyor (hatta daha hızlı çıkarıyor), bazen de subagent çağırınca gereksiz gürültü ekleniyor; özellikle kullanıcı isteği baştan yeterince netse, ekstra keşif biraz lüks kaçıyor.
Şimdi gelelim işin can alıcı noktasına.
Şu basit kod örneği, orkestratör mantığında karar ağacının nasıl kurulabileceğini gösteriyor. İlk bakışta baya sade dürüyor, ama işin aslı burada önemli olan şey kodun kendisi değil, hangi noktada “dur bakalım” deyip devretmediğiniz:
function shouldDelegate(task, context) {
// Görev basitse devretme
if (task.estimatedSteps < 3) return false;
// Kullanıcı zaten yeterli context vermişse keşfe gerek yok
if (context.hasExplicitTarget) return false;
// Son aramayla overlap varsa skip
if (context.recentSearches.overlaps(task.searchScope)) return false;
// Görev gerçekten bağımsız bir alan mı?
if (task.isIndependentScope) return true;
return false;
}
Evet.
Bu tabiî oldukça basitleştirilmiş bir mantık. Gerçek sistemlerde LLM’in bu kararı kendi başına vermesini beklemek yerine prompt seviyesinde küçük ipuçları vermek gerekiyor. Modele “şurada dur”, “burada devret”, “aynı şeyi tekrar arama” gibi sınırlar çiziyorsunuz. GitHub’ın yaptığı da büyük ihtimalle buna yakın — system prompt ve few-shot örneklerle modele ne zaman devretmeyeceğini öğretmek, sonra da geri kalanını modele bırakmak.
Tam da öyle.
Eksik Bulduğum Yanları
Yazıyı sadece övgüyle kapatmak istemiyorum, çünkü orada hâlâ canımı sıkan birkaç boşluk var. Birincisi şu: GitHub, delegation kararını hangi heuristic’lerle verdiğini pek açmamış; “daha seçici” diyorlar (buna dikkat edin). “seçici derken tam olarak neye göre?” sorusu havada kalıyor, açık kaynak olmadığını biliyorum tabi, ama community tarafında biraz daha şeffaflık fena olmazdı (yanlış duymadınız)
Burada, bi saniye — İkincisi biraz daha nüanslı. %5’lık P95 iyileşmesi baya iş görüyor, evet, ama tek başına insanı yerinden hoplatmıyor; asıl mesele, bu kazancın kaliteyi aşağı çekmeden gelmesi. Üçüncü nokta da şu: A/B test sonuçları aggregate verilmiş, yanı hangi iş tipinde ne öldü göremiyoruz, debugging mi daha çok kazandı, refactoring mi, yoksa exploration tarafı mı açıldı, ben açıkçası bunu da merak ederdim.
Şimdi gelelim işin can alıcı noktasına.
Bu arada konuyu yakından izleyenler için küçük bir not düşeyim. Copilot ekibinin son model geçişleri ve harness değişiklikleri hakkında yazdığım GPT-5.2’nın Veda Notu: Copilot Ekipleri Şimdi Ne Yapmalı? yazısında, model ile harness’ın birbirini nasıl itip çektiğine değinmiştim; ikisini ayrı ayrı konuşmak kolay ama işin aslı birlikte düşününce tablo daha netleşiyor.
Doğrusu, Tam da öyle.
Pratik Adımlar: Hemen Ne Yapmalısınız?
Lafı uzatmadan, somut bir aksiyon listesi bırakayım:
- Terminalde
gh copilot --versionile sürümü kontrol edin. 1.0.42’nın altındaysa/updatekomutuyla yükseltin. - Yeni davranışı bir hafta gözlemleyin. En çok da uzun süren görevlerde fark hissedilebilir.
- Eğer kendi ajan sisteminizi tasarlıyorsanız, delegation kararını LLM’e bırakırken prompt’ta açıkça “ne zaman devretmemesi gerektiğini” örneklerle anlatın.
- Telemetri varsa tool failure rate ve subagent invocation count metriklerini izleyin. İkisinin birlikte düşmesi sağlıklı bir sinyal.
- Token bütçenizi gözden geçirin — özellikle aylık enterprise raporlarınızda subagent kaynaklı tüketimin payını bilin.
Sıkça Sorulan Sorular
GitHub Copilot CLI’da subagent ne iş yapıyor?
Subagent, aslında ana ajanın “şunu sen halleder mısın?” diyerek devreye soktuğu yardımcı bir ajan örneği. Mesela repo keşfi, uzun süren bir komut, ya da bağımsız kod incelemesi gibi alt görevler için kullanılıyor. Ana ajan koordinasyonu sürdürürken subagent paralel çalışabiliyor — hani işleri bölerek ilerliyorlar. Ama açıkçası her subagent çağrısı ekstra token, ekstra bekleme süresi ve ekstra hata riski getiriyor. Bedavaya gelmiyor yanı.
Smarter subagent delegation güncellemesi nasıl aktif edilir?
Şöyle söyleyeyim, Zaten aktif, bence bu en güzel yanı. Güncelleme Copilot CLI üretim trafiğinin %100’üne yayılmış durumda. Tek yapman gereken /update komutuyla (söylemesi ayıp) CLI’ı 1.0.42 veya üzerine yükseltmek. Ekstra bir yapılandırma ya da feature flag falan gerekmiyor.
Peki bu değişiklik kaliteyi düşürüyor mu?
GitHub’ın A/B test sonuçlarına göre hayır — ve tecrübeme göre bu tür optimizasyonlarda genelde asıl korku kalite kaybı oluyor. Tool hataları %23 azalmış, bekleme süreleri iyileşmiş, görev tamamlama kalitesi işe sabit kalmış. Neyse, yanı daha az delegasyon, daha kötü sonuç demek değil. Aksine daha temiz, daha az gürültülü çıktılar elde ediyorsun.
Bu prensibi kendi ajan sistemime nasıl uygularım?
Küçük bir detay: Aslında — hayır dur, daha doğrusu üç basit kurala indirgeyebilirsin: (1) Görev basitse devretme, (2) Bağlam zaten yeterliyse keşif yapma, (3) Gerçekten bağımsız işleri paralel çalıştır. Bence en pratik yöntem bunları LLM’e prompt seviyesinde somut örneklerle anlatmak. Heuristic kurallar koymak yerine model davranışını şekillendirmek genelde çok daha esnek sonuç veriyor.
Subagent çağrılarındaki düşüş telemetri panellerinde alarm üretmeli mi?
Hayır, üretmemeli. Subagent invocation count’taki düşüş zaten smarter delegation’ın beklenen sonucu — yanı aslında iyi bir işaret. Asıl gözlemen gereken metrikler tool failure rate ve session wait time. Bu ikisi sabit kalıyor ya da iyileşiyorsa subagent sayısındaki düşüş sağlıklı bir sinyal olarak değerlendirilmeli.
Kaynaklar ve İleri Okuma
GitHub Blog: How we made GitHub Copilot CLI more selective about delegation
İşin garibi, GitHub Copilot in the CLI Resmî Dokümantasyonu
GitHub Copilot CLI GitHub Reposu
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
3 comments