Copilot CLI Metrikleri Artık Birleşik: Ne Değişti?
Geçen hafta bir müşterimizin Copilot dashboard’ünü karıştırırken garip bir şeye denk geldim — CLI üzerinden yapılan kod üretim aktiviteleri, toplam rakamlara hiç yansımıyordu. Yanı adam terminalde Copilot CLI ile bir sürü iş yapıyor, sen takım bazlı raporlara bakıyorsun, orada sıfır. Sanki o kişi Copilot’a hiç dokunmamış gibi görünüyor. Halbuki en aktif kullanıcılardan biriydi — bunu biliyordum çünkü bizzat yanındaydım.
Neyse. GitHub bu sorunu nihayet çözdü. Copilot CLI aktiviteleri artık Usage Metrics API’deki üst seviye toplamlara ve özellik bazlı kırılımlara dahil ediliyor. Kağıt üstünde küçük bir güncelleme gibi görünüyor, ama pratikte — özellikle kurumsal raporlama yapan ekipler için — ciddi bir fark bu. Gerçekten ciddi.
Öncesi Nasıldı? Manuel Birleştirme Çilesi
Biraz geriye gidelim. GitHub, Copilot CLI metriklerini ilk eklediğinde bunları ayrı bir totals_by_cli bölümüne koydu. Session sayıları, request sayıları, token kullanımı… Hepsi oradaydı, tamam güzel, — ki bu tartışılır — ama tamamen izole bir şekilde. Sız hiç denediniz mi? Üst seviye toplamlar sadece IDE aktivitesini yansıtıyordu — VS Code’dan, JetBrains’den, Neovim’den gelen veriler bir yerde, CLI’dan gelenler bambaşka bir yerde, hiçbir bağlantısı yok.
Kısa bir not düşeyim buraya.
Bu ne anlama geliyor biliyor musunuz?
Dashboard’unuza baktığınızda gördüğünüz rakamlar eksikti. Nokta. 2025 sonlarında Logosoft’ta bir finans kuruluşunun Copilot kullanım raporunu hazırlarken tam olarak bu duruma takıldık — müşteri “Bizim geliştiriciler Copilot’u yeterince kullanmıyor, lisanslar boşa mı gidiyor acaba?” diyordu, biz de rakamlara bakıp “Evet, gerçekten düşük görünüyor” diyorduk, içimiz sıkışıyordu. Meğer ekibin yaklaşık %30’u ağırlıklı olarak CLI üzerinden çalışıyormuş ve o veriler hiç toplama girmiyormuş. Tam bir kör nokta.
Ne yalan söyleyeyim, Bunu düzeltmek için ne yapıyorduk? Manuel birleştirme. totals_by_cli verisini ayrıca çekip IDE toplamlarıyla kendimiz toplayıp, Excel’de ya da Power BI’da elle birleştiriyorduk. Küçük bir ekip için belki idare eder. Ama 500+ geliştirici olan bir enterprise ortamda bu iş çok zahmetli — hem hata yapma riski yüksek, hem de otomasyon pipeline’larınızı gereksiz yere karmaşıklaştırıyor.
İşte tam da bu noktada devreye giriyor.
Yeni Güncellemede Tam Olarak Ne Değişti?
Bakın şimdi, değişiklikleri tek tek anlatayım çünkü şeytanın detayda gizlendiği durumlardan biri bu. Sakın “evet evet, anladım” deyip geçmeyin.
Üst Seviye Toplamlar Artık CLI Dahil
Dürüst olmak gerekirse, Aşağıdaki alanlar artık IDE + CLI birleşik değerleri gösteriyor:
| Alan | Önceki Durum | Şimdiki Durum |
|---|---|---|
code_generation_activity_count |
Sadece IDE | IDE + CLI |
code_acceptance_activity_count |
Sadece IDE | IDE + CLI |
user_initiated_interaction_count |
Sadece IDE | IDE + CLI |
loc_added_sum / loc_deleted_sum |
Sadece IDE | IDE + CLI |
Bu tabloya bakınca “e ne var bunda?” diyebilirsiniz. Dur bir saniye — eğer bu alanlara threshold koyduysanız, üzerine alarm kurduysanız ya da trend analizi yapıyorsanız, rakamlarınız bir anda artacak. Haberiniz olmazsa “Vay be, kullanım patlamış!” diyeceksiniz, halbuki sadece CLI verileri eklendi. Anomali yok, kapsam genişledi. Önemli fark.
Boyutsal Kırılımlarda CLI Görünüyor
CLI aktivitesi artık feature=copilot_cli olarak şu kırılımlarda yer alıyor:
totals_by_feature— Özellik bazlı toplamtotals_by_model_feature— Model + özellik bazlıtotals_by_language_feature— Dil + özellik bazlıtotals_by_language_model— Dil + model bazlı (bu kritik)
Ha, bir de şunu söyleyeyim: CLI verisi totals_by_ide kırılımına dahil edilmiyor. Bu mantıklı zaten — CLI bir IDE değil ki (en azından benim deneyimim böyle). Mevcut totals_by_cli bölümü olduğu gibi dürüyor, per-user CLI alanları da değişmemiş. Yanı geriye dönük uyumluluk bozulmuyor — en azından teoride öyle. PHP 8.5 Azure App Service’te: Ne Değişti? yazımızda bu konuya da değinmiştik.
Pratikte Bu Neden Bu Kadar Önemli?
Açık konuşayım: bu güncelleme “nice to have” değil, “should have been there from day öne” kategorisinde. Neden mi?
Bir aracın değerini ölçemiyorsanız, o aracın organizasyondaki geleceğini savunmak çok zor. Copilot lisansları ucuz değil — enterprise seviyede kişi başı aylık maliyetler düşünülünce, yönetim “Bu paraya değiyor mu?” sorusunu büyük ihtimalle soruyor.
2025 Aralık’ta bir telekomünikasyon şirketinde Copilot ROI sunumu hazırlıyorduk. Dashboard’daki rakamlara göre bazı geliştiricilerin Copilot’u neredeyse hiç kullanmadığı görünüyordu, yönetim lisanslarını iptal etmeyi ciddi ciddi tartışmaya başlamıştı. Sonra bir baktık — o geliştiriciler ağırlıklı olarak CLI üzerinden çalışan DevOps mühendisleriydi. Shell scriptleri, Terraform modülleri, pipeline YAML dosyaları… Hepsi terminalden, IDE’ye hiç geçmeden. API’den gelen veride bunların izi yoktu. Sıfır.
Şimdi bu güncellemeyle birlikte o tarz bir körlük ortadan kalkıyor. Tek bir API çağrısıyla büyük çoğunluk yüzeylerdeki Copilot kullanımını görebiliyorsunuz. Manuel birleştirme yok, eksik veri yok. Sonunda.
Startup vs Enterprise: Kimin İçin Daha Kritik?
Küçük bir startup — diyelim 10-15 kişilik bir ekip — için bu değişiklik belki o kadar hissedilmez. Zaten herkes VS Code’da çalışıyor olabilir, CLI kullanımı minimal kalabilir. Ama 200+ geliştirici olan bir enterprise ortamda? Çok farklı tablo. DevOps ekipleri, SRE’ler, platform mühendisleri — bu insanların önemli bir kısmı gün boyu terminalden çıkmıyor, IDE açmıyor bile. Onların Copilot kullanımını görmemek, resmin yarısını kaçırmak demek. Kör bir karar mekanizması kurmak demek. Bu konuyla ilgili Azure MCP Server 2.0: Kendi Sunucunuzda Ajan Otomasyonu yazımıza da göz atmanızı tavsiye ederim.
Bir de şunu düşünün: FinOps perspektifinden bakınca, Copilot lisans maliyetini optimize etmeye çalışan bir ekip, CLI verisini görmeden doğru karar veremez. AZ-305 sınavına hazırlanırken maliyet optimizasyonu konusunda epey çalışmıştım — orada da aynı prensip çıkıyordu karşıma: ölçemediğiniz şeyi optimize edemezsiniz. Klasik ama doğru.
Dashboard’larınızı Güncellemeniz Gerekiyor — Hemen
İşin aslı şu ki bu güncelleme “kutlayalım, geçelim” tipinde bir şey değil. Eğer mevcut dashboard’larınız veya raporlama pipeline’larınız varsa, bunları gözden geçirmeniz lazım. Ciddi ciddi.
Mesela Power BI’da “haftalık Copilot kullanım trendi” diye bir rapor yapıyorsanız, bu hafta itibariyle grafikte anı bir sıçrama göreceksiniz. Bunu açıklayan bir annotation eklemezseniz yönetim “Ne oldu, herkes mi Copilot’a sardı?” diye soracak — garanti (inanın bana). Ya da tam tersi: geçmişe dönük karşılaştırma yapıyorsanız, eski veriler IDE-only, yeni veriler IDE+CLI. Elma ile armut karşılaştırması. Grafikler yalan söylemez ama yanlış yorumlatır.
Bir şey dikkatimi çekti: Pratik bir ipucu vereyim (ben de ilk duyduğumda şaşırmıştım). API’den veri çekerken, geçiş döneminde hem totals_by_cli bölümünü hem de üst seviye toplamları ayrı ayrı kaydedin. Böylece CLI’ın toplama olan katkısını izole edebilirsiniz — bir nevi “before/after” analizi. Şöyle bir şey yazabilirsiniz: Bu konuyla ilgili GitHub Copilot Pro Denemeleri Neden Durdu? yazımıza da göz atmanızı tavsiye ederim.
Bir dakika — bununla bitmedi. Daha fazla bilgi için GitHub Actions’ta 50 Yeniden Çalıştırma Sınırı: Sahada Ne Değişiyor? yazımıza bakabilirsiniz.
# Örnek: Python ile CLI katkısını izole etme
import requests
response = requests.get(
"https://api.github.com/orgs/{org}/copilot/usage",
headers={"Authorization": f"Bearer {token}"}
)
data = response.json()
for day in data:
total = day.get("code_generation_activity_count", 0)
cli_only = sum(
item.get("code_generation_activity_count", 0)
for item in day.get("totals_by_cli", [])
)
ide_only = total — cli_only
print(f"Tarih: {day['day']} | Toplam: {total} | IDE: {ide_only} | CLI: {cli_only}")
Basit bir script ama geçiş döneminde işinizi bayağı kolaylaştırır (kendi tecrübem). Tabi production’da bunu daha sağlam hâle getirmeniz lazım — hata yönetimi, rate limiting filan. Fikir olarak bu yeterli, gerisini sız yaparsınız zaten.
Benim İlk İzlenimim ve Birkaç Eleştiri
Güzel bir güncelleme, bunu inkâr edemem. Ama açıkçası… beklediğim kadar heyecan verici gelmedi. Neden? Çünkü bu zaten en başından böyle olmalıydı. CLI desteği ilk geldiğinde neden ayrı bir silo olarak eklendi, bunu gerçekten anlamıyorum — sanki aceleyle “CLI metrikleri de var” deyip, entegrasyonu sonraya bırakmışlar gibi bir his var. Teknik borç değil, tasarım borcu.
Bir de şu var: CLI verisi totals_by_ide‘ye dahil edilmiyor, tamam bu mantıklı. Ama totals_by_editor gibi daha kapsayıcı bir isimlendirme ya da belki totals_by_surface gibi bir alan olabilirdi pekala. “IDE” kelimesi orada durduğu sürece insanlar “E, CLI nerede?” diye sormaya devam edecek — buna eminim.
Bunu biraz açayım.
Gel gelelim, bu değişiklik tek günlük ve 28 günlük raporların hepsini etkiliyor — enterprise, organizasyon ve kullanıcı bazlı. Yanı kapsam geniş, küçümseme. Daha önce Copilot Cloud Agent Metriği: Kullanımı Ölçmek Kolaylaştı yazısında da benzer bir metrik birleştirme konusunu ele almıştım. Aynı tema tekrar karşıma çıkıyor: GitHub, Copilot’un farklı yüzeylerini tek bir raporlama çatısı altında toplamaya çalışıyor. Doğru yöndeler, doğru — ama yol uzun, sabır lazım.
Bir bakıma, dürüst olmak gerekirse, Ha bu arada, Copilot’un lisanslama tarafında da son dönemde epey hareketlilik var. Copilot’ta Yeni Limitler: Ne Değişti, Ne Beklemeli? yazısına da göz atmanızı öneririm — limit değişiklikleri ile metrik değişikliklerini birlikte değerlendirmek çok daha sağlıklı bir resim çiziyor.
Ne Yapmalısınız? Kısa Bir Checklist
Lafı gevelemeden sıralayayım:
- Dashboard’larınızı kontrol edin. Üst seviye toplamlara dayanan her raporu gözden geçirin. Baseline’ları güncelleyin.
- Threshold ve alertleri revize edin. “Kullanım şu seviyenin altına düşerse uyar” gibi kurallarınız varsa, yeni rakamlarla kalibre edin.
- Geçiş dönemi için annotation ekleyin. Trend grafiklerinde “bu tarihten itibaren CLI dahil” notu düşün — yoksa herkes şaşırır.
- Ekibinizi bilgilendirin. Bilhassa raporlara bakan yöneticilere kısa bir mail atın: “Rakamlar arttı ama bu iyi bir şey, CLI verileri artık dahil” deyin. Kimse paniklesin istemezsiniz.
- Eski birleştirme scriptlerini emekliye ayırın. Manuel
totals_by_cli+ IDE toplamı yapan kodlar artık gereksiz, karmaşıklığı azaltın. (bence en önemlisi)
Hmm, bir düşüneyim… Aslında bir 6. madde daha var. Eğer totals_by_cli verisini ayrıca saklıyorsanız, bunu hemen kaldırmayın — geriye dönük analiz için işe yarayabilir. Ama yeni raporlarınızı birleşik toplam üzerinden kurun. İkisini birden tutun bir süre, sonra karar verirsiniz.
Sıkça Sorulan Sorular
Bu güncelleme mevcut API endpoint’lerini değiştiriyor mu?
Küçük bir detay: Hayır, endpoint’ler aynı kalıyor. Değişen şey, üst seviye toplam alanlarının artık CLI verilerini de içermesi. totals_by_cli bölümü de hâlâ mevcut, yanı geriye dönük uyumluluk korunuyor.
CLI verileri totals_by_ide kırılımında görünüyor mu?
Hayır, CLI verisi totals_by_ide‘ye dahil edilmiyor. CLI aktivitesi totals_by_feature, totals_by_model_feature, totals_by_language_feature ve totals_by_language_model kırılımlarında feature=copilot_cli olarak görünüyor.
Dashboard’umdaki rakamlar neden aniden arttı?
Bu güncellemeyle birlikte üst seviye toplamlar artık IDE + CLI birleşik değerleri gösteriyor. Eğer organizasyonunuzda CLI kullanımı varsa, toplam rakamlar doğal olarak artacaktır. Bu bir anomali değil, sadece verinin kapsamı genişledi.
Per-user CLI alanları değişti mi?
Açıkçası, Hayır, kullanıcı bazlı CLI alanları ve mevcut totals_by_cli bölümü olduğu gibi dürüyor. Sadece üst seviye toplamlar ve boyutsal kırılımlar güncellendi.
Bu değişiklik hangi rapor türlerini etkiliyor?
İnanın, Tek günlük ve 28 günlük raporların hepsini etkiliyor — enterprise, organizasyon ve kullanıcı bazlı raporlar dahil. Kapsam oldukça geniş.
Kaynaklar ve İleri Okuma
İlginç olan şu ki, GitHub Copilot Usage Metrics API Dokümantasyonu
GitHub Blog — Copilot CLI Activity Now Included in Usage Metrics
İçeriği paylaş:
İlgili Yazılar
📬 Bu yazıyı faydalı buldunuz mu?
Azure, DevOps ve bulut teknolojileri hakkında güncel içerikler için beni takip edin!
Yorum gönder