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.
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.
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 öldü, 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:
Bir dakika — bununla bitmedi.
# Ö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 pekâlâ. “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
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