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.

Bu yazıda hem GitHub’ın paylaştığı sayılara kendi gözümle bakacağım, hem de Türkiye’deki ekiplerin bu tarz ajan davranışını nasıl okumalı gerektiğine dair kafamdaki notları paylaşacağım. Hazırsanız başlayalım. İşte, peki neden?

İlk bakışta konu basit gibi dürüyor. Ama değil.

GitHub’ın anlattığı senaryoda mesele, ana ajanın her işi alt ajanlara dağıtması değil; tam tersine, ne zaman devretmenin mantıklı olduğunu daha iyi seçebilmesi. Yanı “her şeyi böl-parçala-gönder” yaklaşımı yerine, işin bağlamına göre karar veren bir yapıdan söz ediyoruz (ve açıkçası bu ayrım küçük görünse de etkisi baya büyük olabiliyor). Burada hayatı nokta şu: yanlış yerde yapılan delegation, sistemi hızlandırmıyor; bazen resmen yavaşlatıyor.

Bi saniye — Şey, bunu ekiplerde defalarca gördüm. Bir iş ufaksa ama sız önü üç ayrı subagent’a paylaştırıyorsanız, koordinasyon maliyeti hemen ortaya çıkıyor; üstelik her ajan kendi tool zincirini çalıştırınca toplam süre uzuyor. Sonuç da bazen beklediğiniz kadar temiz olmuyor. Evet.

GitHub’ın güncellemesinin hoşuma giden tarafı da burada başlıyor. Az önce “daha az devretmek daha iyi olabilir” dedim ama aslında mesele sayı değil; doğru eşik. Eğer ana ajan işi kendi içinde çözüp geçebiliyorsa, ekstra katman açmanın pek anlamı kalmıyor. Ama iş gerçekten dallanıyorsa, o zaman subagent kullanımı baya iş görüyor.

Smarter subagent delegation ne yapıyor?

Bak şimdi, işim biraz pazarlama kokuyor olabilir. Fakat içerik fena değil.

Bu güncelleme ile Copilot CLI’nın ajanı, görevleri otomatik olarak alt ajanlara aktarma konusunda daha seçici davranıyor. Yanı her istekte koşup parçalara bölmek yerine, — kendi adıma konuşayım — işin karmaşıklığını tartıp “burada ben devam edeyim” ya da “bunu ayırmak mantıklı” diyebiliyor (tabi bunu insan gibi sezgisel yapmıyor; model sinyalleri. Görev yapısı üzerinden karar veriyor). Sonuçta amaç, gereksiz delegasyonu azaltıp hem gecikmeyi hem de tool kullanımını aşağı çekmek.

Burası önemli çünkü ajan sistemlerinde en kolay hata şu: mimariyi kağıt üstünde büyütüp pratikte hantallaştırmak. Çok parlak görünen tasarım bazen sahada idare eder bile olmuyor; hele ki latency hassasiyeti olan akışlarda küçük bir ek adım bile can sıkabiliyor. Sız ne dersiniz?

Bunu biraz açayım.

Yukarıda bahsettiğim o olay var ya, işte onun özü şu: subagent sayısı artınca paralellik artacak sanıyoruz ama çoğu durumda tam tersi oluyor. Çünkü her ek ajanın kendine ait bağlam taşıması gerekiyor ve bu bağlamın taşınması da maliyet yaratıyor (yanlış duymadınız). Kısacası, parçalamak genelde hız kazandırmıyor.

Sayılar ne diyor?

GitHub’ın verdiği metriklere göre bu değişiklikten sonra bazı senaryolarda yüzde 20-30 civarında iyileşme görülmüş. Şimdi dikkat: Bu rakamı görüp hemen “tamamdır, sorun çözüldü” demek kolay ama biraz acele olur (özellikle gerçek dünya yüklerinde sonuçlar kullanım şekline göre epey oynayabiliyor). Yine de genel yön belli: daha akıllı delegation = daha az boşa giden işlem.

İlginç olan şu ki, Emin değilim ama sanırım asıl kazanım ham hızdan çok verimlilik tarafında ortaya çıkıyor. Çünkü agent işi doğru yere bırakınca sadece süre kısalmıyor; aynı zamanda gereksiz context şişmesi de azalıyor ve hata yüzeyi küçülüyor. Bu ikisini birlikte düşünmezseniz resmî eksik görürsünüz.

Kendi tarafta bunu şöyle okurum: Eğer sizin agent tasarımınızda sürekli yeni subagent açılıyor. Kullanıcı deneyimi iyileşmiyorsa, orada bir yerde fren tutmuyordur. Hani bazen sistem güzel görünür ama içeride sessizce maliyet birikir ya, aynen öyle bir durum.

Türkiye’deki ekipler bunu nasıl okumalı?

Lafı gevelemeden söyleyeyim: Bizde çoğu ekip önce gösterişli mimariyi seviyor, sonra operasyonel bedeli fark ediyor. Doğal tabiî; demo sırasında çok ajanlı yapı havalı dürüyor ama üretimde loglar uzadıkça uzuyor, bekleme süreleri artıyor ve kimse nedenini ilk anda net göremiyor.

Açık konuşayım, burada bence iki soru sorulmalı: Bu işi gerçekten bölmeye değer mi? Ve alt ajana verdiğim parça tek başına anlamlı mı? Eğer cevaplardan biri bile zayıfsa, delegation yerine tek ajanla ilerlemek çoğu zaman daha temiz oluyor (hele ki küçük ve orta ölçekli otomasyonlarda).

Neyse, çok dağıttım gibi öldü ama konuyu toparlayayım: smarter delegation yaklaşımı bize şunu hatırlatıyor — ajan mimarisinde amaç mümkün olan en çok alt ajanı kullanmak değil, mümkün olan en az sürtünmeyle doğru işi çözmek. Baya basit aslında.

Bende bıraktığı izlenim

Şaşırdım açıkçası.

Çünkü yıllardır AI sistemlerinde “daha fazla modül = daha iyi ölçeklenme” ezberi dolaşıyor; halbuki pratikte işler o kadar düz gitmiyor. Hele bir de de araç kullanan ajanlarda koordinasyon maliyeti gizli bir vergi gibi çalışıyor ve sız fark etmeden performansı kemiriyor (bu yüzden ölçüm yapmadan karar vermek riskli).

Az önce söylediğim şeyin tersini de ekleyeyim: Bazı kompleks senaryolarda subagent gerçekten gerekli olacak, hatta kurtarıcı bile olabilir. Ama önü varsayılan yol yapmak başka şey; gerektiğinde devreye sokmak başka şey. Aradaki çizgi ince ama önemli.

Ajan Sistemlerinde “Yardım Et” Komutu Bazen Geciktirir

Şöyle düşünün. Terminalde Copilot CLI’a “şu fonksiyondaki null kontrolünü düzelt” diyorsunuz. Ana ajan bunu üç satırda kendi başına toparlayabilecekken, bir anda durup keşif subagent’ı çağırıyor; o da repoyu tarıyor, sonuçları çıkarıyor, ana ajan bekliyor, sonra asıl düzenleme başlıyor. Bir adımlık iş, hop diye üç adıma çıkıyor. Şimdi, peki neden?

Hani, İşin aslı şu: delegasyon bedavaya gelmiyor. Her el değiştirme, yanı ajanlar arası her küçük paslaşma, üstüne şu yükleri bindiriyor: koordinasyon ek yükü (context aktarımı ve durum senkronizasyonu), ek tool çağrıları (subagent’ın kendi aramaları ve kendi okumaları), bekleme süresi (sequential delegasyonda ana ajan boş boş dürüyor), bir de hata yüzeyi genişlemesi (her yeni tool çağrısı potansiyel bir tökezleme noktası). Az gibi dürüyor ama değil.

Hmm, bunu nasıl anlatsamdı…

GitHub’ın production A/B test sonuçlarına bakınca tablo baya netleşiyor, hatta biraz da şaşırtıyor açıkçası: oturum başına tool hatalarında %23 azalma, arama hatalarında %27 düşüş, düzenleme hatalarında %18 gerileme var (şaşırtıcı ama gerçek). Toplam bekleme süresinde P95’te %5, P75’te %3 iyileşme görülmüş. Üstelik kalite tarafında geri gidiş yok. Yanı daha az devretmek, çoğu zaman daha hızlı ve daha güvenilir sonuç veriyor; kulağa ters geliyor ama öyle.

Ajan mimarisinde “specialist subagent” çağırmak bir yetenek değil, bir maliyet kararıdır. Ne zaman çağıracağınızı bilmek, çağırabildiğiniz kadar önemli.

Peki neden ana ajan bu kadar hevesli devrediyordu?

Burada biraz LLM davranışına girmek lazım. Büyük dil modelleri, özellikle ajan harness’larında çalışırken, ellerinde bir araç varsa önü kullanmaya meyilli oluyorlar. Buna ben “tool affordance bias” diyorum; Türkçesi de baya basit: elindeki çekiçle her şeyi çivi sanmak. Subagent çağırma yeteneği prompt’ta varsa, model riskli bir durumda “ben yaparım” demek yerine “uzmanına bırakayım” diye düşünüyor. Mantıklı geliyor, değil mi? Ama işte her zaman değil.

Asıl sorun: Bağlam zaten varken keşif yapma alışkanlığı

Birçok handoff’ta kullanıcı aslında yeterli bağlamı veriyor. “src/auth/login.ts’deki tokenExpiry değişkenini 3600 yap” gibi bir istekte ortada keşfedilecek fazla bir şey yok. Dosya belli, değişken belli, değer belli. Yanı konu net. Ama eski davranışta ana ajan “emin olayım” diye subagent fırlatıyor, subagent dosyayı arıyor, açıyor, raporluyor, sonra ana ajan. Elinde olan bilgiyle düzenlemeyi yapıyor. Üç adım gidiyor, tek adımlık iş için.

İkinci dert: Aynı aramayı iki kere yapmak

Araya gireyim: Ana ajan önce bir grep atıyor. Sonra subagent’a görev veriyor. Subagent da kendi context’inde o bilgi olmadığı için aynı grep’i yeniden yapıyor (evet, doğru duydunuz). Hani bazen insan bakıyor ve “bu niye iki kere döndü?” diyor ya, tam öyle bir durum. Bu da distributed sistemlerdeki cache invalidation derdinin ajan versiyonu gibi dürüyor (evet, biraz acı ama doğru). Çözüm mü? Ya context’i düzgün aktaracaksın ya da delegasyonu hiç açmayacaksın. GitHub’ın seçtiği yol ikinci seçenek olmuş; sade, az konuşan ve açık konuşayım baya iş gören bir tercih.

Değişen Davranış: Üç Temel Prensip

GitHub blog yazısında anlatılan üç prensip aslında epey net, ama ilk bakışta insanın gözünden kaçabiliyor.

1. Odakta kal — Ana ajan kendi başına daha hızlı ilerliyorsa devretme.
2. Gerçek kaldıraç için devret — Bir uzman subagent gerçekten değer katıyorsa (örneğin tanıdık olmayan bir repoyu keşfetmek, bağımsız bir kod alanını incelemek) çağır.
3. Paralel çalışmaya yatır — Görevler gerçekten bağımsızsa, sequential değil parallel delegasyon kullan.

İşin aslı şu: üçüncü maddeyi çoğu kişi hafife alıyor. Hatta bazen baya gözden kaçıyor. Çünkü ajan sistemlerde en sık yapılan hata, paralel yapılabilecek işleri sıraya dizmek; mesela “bu üç dosyada test coverage’ı kontrol et” gibi bir iş geldiğinde, üç ayrı subagent eşzamanlı koşmalı, yoksa ana ajan birini beklerken öbürleri boşta kalıyor. Latency gereksiz yere şişiyor.

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.

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:

1. Terminalde gh copilot --version ile sürümü kontrol edin. 1.0.42’nın altındaysa /update komutuyla yükseltin.
2. Yeni davranışı bir hafta gözlemleyin. En çok da uzun süren görevlerde fark hissedilebilir.
3. 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.
4. Telemetri varsa tool failure rate ve subagent invocation count metriklerini izleyin. İkisinin birlikte düşmesi sağlıklı bir sinyal.
5. 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

Aşkın KILIÇYazar

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.

AZ-305AZ-104AZ-500AZ-400DP-203AI-102

İlgili Yazılar

GitHub Copilot CLI Kullanımını Artık Kişi Bazında Görmek Mümkün2 Nis 2026

Kurumsal Yapay Zekâ Maliyetleri: Forrester Analizi9 Mar 2026

GitHub Bildirimlerinde Sıralama Geldi: Küçük Detay mı?9 Nis 2026

GitHub Pages ile Ücretsiz Site Kurulumu: Tam Rehber13 Nis 2026