GitHub Copilot Kullanım Ölçümleri: CCA Artık Görünüyor
Geçen hafta bir müşteride tam da şu soruyla uğraştık: “Copilot’u kim kullanıyor,. Gerçekten nerede kullanıyor?” Çünkü mesele sadece IDE içinde yazılan kod değil. İşin içine issue atamak, pull request yorumunda @copilot demek, ajanı devreye sokmak gibi şeyler girince tablo biraz dağılıyor. GitHub’ın yeni güncellemesi de tam bu dağınıklığı toparlamaya çalışıyor.
İşin özü basit: artık Copilot kullanım metrikleri, Copilot coding agent etkinliği olan kullanıcıları ayrı şekilde gösterebiliyor. Yanı bir ekipteki günlük veya 28 günlük rapora bakarken “bu kişi IDE’de mi Copilot kullandı, yoksa ajan tarafında mı iş yaptı?” sorusuna daha net cevap alıyorsunuz. Kağıt üstünde küçük bir değişiklik gibi dürüyor. Pratikte işe baya işe yarıyor.
Neden önemli? Çünkü ölçemediğini yönetemezsin
Ben bu cümleyi yıllardır duyuyorum; klişe gibi geliyor ama bazı yerlerde gerçekten cuk oturuyor. Bilhassa kurumsal yapılarda Copilot yayılımını takip ederken tek başına IDE metriğine bakmak eksik kalıyordu. Bir ekip VS Code içinde epey aktif görünüp, diğer tarafta issue tabanlı ajan kullanımında sessiz kalabiliyordu. Sonra yöneticiler dönüp “Copilot yatırımı karşılığını veriyor mu?” diye sorunca cevap biraz havada kalıyordu.
Peki neden?
İlginç olan şu ki, AZ-305 sınavına hazırlanırken bile mimarı kararların ölçümle nasıl beslendiğini tekrar tekrar görmüştüm. Azure tarafında log, metric, diagnostic setting ne kadar önemliyse; yapay zekâ araçlarında da adoption sinyalleri o kadar önemli. Burada fark şu: Copilot artık tek bir yüzeyde yaşamıyor. IDE başka dünya, GitHub Issues başka dünya, PR comment’leri bambaşka bir kanal.
Bir de dürüst olayım: bazı müşterilerde en büyük sorun teknik değil, organizasyonel oluyor. 2024 sonlarında Ankara’da finans sektöründen bir ekipte konuşurken şunu fark etmiştim; takım liderleri “ajan” kelimesini duyunca otomatik olarak güvenlik alarmına geçiyordu. Halbuki doğru kurgulanırsa ajan kullanımı sadece hız değil, izlenebilirlik de getiriyor. Tabiî burada ince çizgi var — her şeyin raporda görünmesi güzel ama yanlış okunursa insanı yanıltır (ciddiyim)
Copilot kullanımını yalnızca IDE ile okumak artık yetmiyor; issue ve pull request üzerinden başlayan agent akışları da resmin içine girdiğinde gerçek geçiş yapma seviyesi ortaya çıkıyor.
Yeni alan neyi gösteriyor?
GitHub’ın API yanıtına eklediği used_copilot_coding_agent alanı kullanıcı seviyesinde geliyor. Bu alanın anlamı şu: ilgili kişi Copilot coding agent oturumu başlatmış mı? Eğer başlatmışsa, bunu hangi yolla tetiklemiş olduğu da senaryoya göre anlaşılıyor; mesela bir issue’ya Copilot atanması ya da PR yorumunda @copilot kullanılması gibi.
Burada kritik ayrım şu iki kavram arasında:
used_agent: IDE içindeki agent mode kullanımını gösteriyor.used_copilot_coding_agent: GitHub yüzeyinde başlayan coding agent aktivitesini gösteriyor.
Bana göre bu ayrım küçük görünüyor ama raporlama tarafında ciddi fark yaratıyor. Bir telekom müşterimizde geçen yıl benzer bir analiz yapmıştık; ekiplerin çoğu VS Code’dan veri üretirken asıl otomasyon kazancı pull request akışından geliyordu (bu beni çok şaşırttı). O zaman elimizde böyle net bir ayırım yoktu ve raporlar biraz kör topal gidiyordu… şimdi iş daha temiz.
Küçük ekip için ne değişir?
Küçük startup’larda genelde soru şudur: “Kaç kişi kullanıyor?” Yeni metrik burada çok detaylı görünmese de işe yarar (bizzat test ettim). Team lead hemen şunu anlayabilir: insanlar AI’ı sadece deniyor mu, yoksa gerçek iş akışına sokmuş mu? Mesela beş kişilik bir ekipte iki kişinin issue bazlı ajan kullandığını görmek fena değil; bu, deneysel aşamadan üretime geçiş sinyali olabilir.
Ama dikkat: küçük ekiplerde veri sayısı az olduğu için dalgalanma fazla olur. Bir haftalık sıçrama seni kandırmasın. Dün yoğundu diye bugün trend oluştu sanma… hani bazen dashboard’a bakıp gereksiz heyecanlanıyoruz ya, işte o tuzağa düşmemek lazım.
Enterprise tarafta neden daha kıymetli?
Büyük kurumlarda mesele sayıdan çok dağılım oluyor. Hangi departman kodlama ajanını benimsedi? Hangi takımlar hâlâ sadece IDE içinde kalıyor? Hangi repo türlerinde ajan daha verimli çalışıyor? Bunları ayırabilmek FinOps kafasına da uyuyor aslında; kaynak nereye gidiyor belli olunca yatırım kararı daha sağlıklı çıkıyor.
Şöyle ki, Logosoft’ta geçtiğimiz Mart ayında İstanbul’daki bir kurumsal müşteriyle yaptığımız değerlendirmede benzer bir durum yaşadık. Üst yönetim “Copilot lisansı var ama fayda nerede?” diye soruyordu. Asıl farkı gördüğümüz yer PR yorumlarıyla başlayan agent aktiviteleri öldü. Ekipler kendiliğinden akışı oraya taşımıştı. Açık konuşayım, beklediğimden daha temiz sinyal verdi.
Bakın, burayı atlarsanız yazının kalanı anlamsız kalır.
| Metrik | Neyi anlatır? | Nerede güçlü? |
|---|---|---|
used_agent |
IDE içi agent mode kullanımı | Editör odaklı ekipler |
used_copilot_coding_agent |
İssue / PR üzerinden başlayan CCA aktivitesi | GitHub merkezli iş akışları |
| User-level daily / 28-day reports | Kullanıcı bazlı adoption görünümü | Ekip ve portföy analizi |
Sahada bunun karşılığı ne oluyor?
Neyse, şimdi gelelim pratik tarafa… Bu metrik bana üç farklı şeyi düşünduruyor: geçiş yapma takibi, yönetişim ve eğitim planı. Eğer elinizde hangi kullanıcıların ajana dokunduğu bilgisi varsa eğitim ihtiyacını daha doğru çıkarırsınız. “Herkese aynı workshop” yaklaşımı yerine gerçekten ihtiyaç olan gruba özel aksiyon alırsınız. Daha fazla bilgi için GitHub Actions 2026 Güvenlik Yol Haritası: Sırada Bizi Neler Bekliyor? yazımıza bakabilirsiniz.
Tuhaf ama, Bir de şu var: bazı takımlar aracı seviyor ama sessiz kullanıyor. Yanı insanlar tek tıkla sonuç alıp bunu rapora yansıtmayınca yöneticiler “ben pek hareket görmüyorum” diyebiliyor. Bu yeni ayrım tam burada işe yarar çünkü davranışı daha açık hâle getiriyor.
Hmm, bunu nasıl anlatsamdı… Daha fazla bilgi için github ile ilgili önceki yazımız bakabilirsiniz.
Aman ha, unutmayın: noktalar
Bence en önemli risk yanlış yorum yapmak. Mesela üç kişi ajanı sık kullanıyor — en azından ben öyle düşünüyorum — diye tüm ekip dönüşmüş sayılmazsınız; belki onlar pilot grubudur ve geri kalanlar hâlâ bekliyordur (olur böyle şeyler). Aynı şekilde düşük sayı gördünüz diye proje başarısız demek de acele olur.
Buna ek olarak gizlilik. Rol tabanlı erişim konusu var ki orası ayrı başlık isterdi ama kısa geçeyim: admin panelinde görünen veri ile son kullanıcı algısı aynı olmayabilir. Kurum içi iletişim iyi yapılmazsa insanlar “takip ediliyoruz” hissine kapılabiliyor — gereksiz gerginlik çıkabiliyor yanı.
{
"login": "example-user",
"days_active": {
"daily": true,
"twentyeight_day": true
},
"used_agent": false,
"used_copilot_coding_agent": true
}
Bana göre asıl mesaj ne?
Açık söyleyeyim, bu güncelleme teknik olarak devrim değil ama operasyonel olarak değerli. Çünkü Copilot’u sadece kod yazan bir yardımcı olarak değil, iş akışının parçası olarak okumaya zorluyor bizi. Ben buna “AI kullanımının sis perdesinin kalkması” diyorum biraz kendi dilimde.
Araya gireyim: Marmara bölgesinde bir üretim firmasındaki projede geçen sene şöyle olmuştu: geliştiricilerin çoğu editörde AI önerilerini kullanıyormuş gibi görünüyordu ama asıl hız kazancı code review sürecinde ortaya çıkmıştı
— özellikle tekrarlayan düzeltmelerde — fakat bunu dashboard’da yakalayamıyorduk. Şimdi benzer kurumlarda bu tip ayrımlar çok daha rahat yapılacak gibi dürüyor. Daha fazla bilgi için GitHub Actions’da Agentic Workflow Ayarlarını Anında Görmek: Gerçekten Oyun Değiştirici mi? yazımıza bakabilirsiniz. Daha fazla bilgi için GitHub Actions’da Özel Runner İmajları: Kontrol Artık Sizde! yazımıza bakabilirsiniz.
Küçük bir detay: E tabiî her güzel gelişmenin yanında ufak hayal kırıklığı da olur; keşke metrikler varsayılan olarak biraz daha açıklayıcı bağlamla gelseydi dedirtiyor insana. Yanı alan adı var ama yöneticiyi direkt doğru yoruma götürmeyebilir, orada yine insan eli lazım. copilot ile ilgili önceki yazımız bu konuya da değinmiştik.
Kimin işine yarar?
Açıkçası, Cevap kısa: neredeyse herkese yarar ama en çok platform sahiplerine ve yöneticilere yarar.
Eğer DevOps dönüşümü yürütüyorsanız bu veri altın değerinde olabilir.
Güvenlik ekibi de bundan faydalanır; çünkü hangi yüzeylerden otomasyon başladığını bilmek kontrol modelini iyileştirir.
Bir startup iseniz ürün geliştirme hızınızı okursunuz.
Enterprise iseniz adoption haritası çıkarırsınız.
Basitçe böyle.
Lafı gevelemeden söyleyeyim: ben bu tip küçük görünen güncellemeleri seviyorum. Tahmin eder mısınız? Sahada etkisi büyük oluyor.
En çok da Azure danışmanlığı yaptığım projelerde hep şunu gördüm — iyi telemetri yoksa iyi karar da zor çıkıyor.
Copilot tarafında telemetri büyüdükçe kurumlar daha bilinçli hareket edecek.
Bu güzel.
Ama henüz ham.
Biraz pişmesi lazım!
Sıkça Sorulan Sorular
Copilot usage metrics içinde used_copilot_coding_agent ne demek?
used_copilot_coding_agent, bir kullanıcının Copilot coding agent aktivitesi olup olmadığını gösterir. Genelde issue atama veya pull request yorumunda @copilot etiketleme gibi aksiyonlarla tetiklenen oturumları kapsar.
This update used_agent ile aynı şeyi mi gösteriyor?
Bence, Hayır, aynı şey değil. used_agent IDE içindeki agent mode kullanımını anlatırken, yeni alan GitHub yüzeyindeki coding agent kullanımını ayırıyor.
Bunu günlük ve 28 günlük raporlarda görebilir mıyım?n
Evet, güncelleme enterprise ve organization admin’lerinin günlük ve 28 günlük raporlarda aktif kullanıcıları ayırt etmesine yardımcı oluyor. Böylece adoption trend’i daha net okunuyor.
Küçük ekiplerde bu metrik neden önemli?
Küçük ekiplerde bile AI benimsemesini anlamak için faydalı olur çünkü sadece kaç kişinin kullandığı değil, nerede kullandığı da önemlidir. Böylelikle eğitim ve süreç iyileştirmesi daha nokta atışı yapılır.
Büyük kurumlarda en büyük faydası ne?
Büyük kurumlarda farklı takımların farklı yüzeylerde AI kullandığını görmek kolaylaşır. Bu da lisans değeri, güvenlik yaklaşımı. Değişim yönetimi açısından ciddi avantaj sağlar.
Kaynaklar ve İleri Okuma
GitHub Blog – Copilot usage metrics now identify active Copilot coding agent users
İnanın, GitHub Docs – Copilot Usage Metrics API Documentation
GitHub Docs – GitHub Copilot Resmî Dokümantasyon
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.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
Yorum gönder