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.
📋 İçindekiler
-
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.
⚠️ Dikkat: Üst seviye toplamların anlamı değişti. Eğer bu alanlara dayanan threshold’larınız, alertleriniz veya karşılaştırmalarınız varsa, CLI katkısının eklenmesi nedeniyle rakamlar artacak. Bu bir anomali değil — sadece verinin kapsamı genişledi. Dashboard’larınızdaki baseline’ları güncellemeyi unutmayın.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_clibö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ı. Amatotals_by_editorgibi daha kapsayıcı bir isimlendirme ya da belkitotals_by_surfacegibi 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_cliverisini 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_clibö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 aktivitesitotals_by_feature,totals_by_model_feature,totals_by_language_featurevetotals_by_language_modelkırılımlarındafeature=copilot_cliolarak 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_clibö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
Bu yazı yapay zeka (büyük dil modelleri) ile hazırlanmış, insan editör tarafından incelenmiştir. İçerik üretim sürecimiz.
Tuğçe R.
Peki ya bu değişiklik geriye dönük olarak mı uygulanıyor, yoksa sadece bu tarihten itibaren mi sayılmaya başlıyor? Çünkü eski raporlarla karşılaştırma yapanlar için bu önemli bir fark yaratır.
Oğuz L.
CLI üzerinden yapılan işlemlerin metrik dışı kalması gerçekten büyük bir eksiklikti, özellikle terminal ağırlıklı çalışanlar için kullanım raporları hiç gerçeği yansıtmıyordu. Şimdi daha tutarlı bir tablo oluşacak en azından. Bu arada şu yazınız da güzeldi: PHP 8.5 Azure App Service’te: Ne Değişti? — https://www.askinkilic.com.tr/php-85-azure-app-servicete-ne-degisti/
Sibel V.
Bunu fark etmemiştim açıkçası, CLI kullanımım hiç görünmüyordu diye düşünüyordum ama sebebi buymuş demek. Peki bu değişiklik geçmiş verilere de yansıdı mı yoksa sadece yeni kayıtlardan mı geçerli?
Yorumlar kapalı.







3 comments