Açık konuşayım: GitHub Copilot’un code review özelliğini kurumsal müşterilerimde devreye aldığımdan beri, en sık duyduğum soru hep aynı öldü. “Aşkın Bey, biz bu Copilot’a para veriyoruz da, gerçekten ne kadar değer üretiyor? Hangı tıp hataları yakalıyor? Geliştiriciler önerilerin ne kadarını gerçekten uyguluyor?”
İşin aslı, eskiden bu sorulara net bir cevap veremiyordum. Elimde sadece kaba kullanım sayıları vardı — kaç PR’da Copilot review aktif, kaç öneri üretildi falan. Ama “hangı tür öneri” sorusu havada kalıyordu. E biraz can sıkıcıydı.
Açık konuşayım, Geçen hafta GitHub bunu çözen bir güncelleme yayınladı. Copilot usage metrics API’si artık review yorumlarını tipine göre kırıyor. Yanı security önerisi mi, bug riski mi, performans mı — hepsini ayrı ayrı görebiliyorsunuz. Üstelik uygulanma oranlarıyla birlikte. Fena değil.
Bakın şimdi, bu bana küçük gıbı görünen ama FinOps ve DevOps tarafında baya iş görecek bir değişiklik gıbı geliyor. Detaylara girelim.
Tam Olarak Ne Değişti?
Kendi deneyimimden konuşuyorum, Kısaca özetlemem gerekirse: pull_requests objesinin altına yeni bir array eklendi. Adı copilot_suggestions_by_comment_type. Hem enterprise hem de organization seviyesindeki raporlarda var. Yanı tek yerde değil, iki tarafta da görüyorsunuz.
Her bir kayıt şu üç alanı içeriyor:
- comment_type — Copilot’un öneriye verdiği kategori (örnek:
security,bug_risk, vb.) - total_copilot_suggestions — O tipte raporlama döneminde üretilen toplam öneri sayısı (bence en önemlisi)
- total_copilot_applied_suggestions — Bu önerilerden geliştiricinin gerçekten uyguladıklarının sayısı
Garip gelecek ama, Hem günlük (single-day) hem de 28 günlük rolling window raporlarda mevcut. Repo seviyesine drill-down yok şu an — ama GitHub bunun üzerinde çalıştığını söylüyor. Açıkçası repo bazlı kırılım gelmeden bu metriğin tam potansiyeli ortaya çıkmaz, ben öyle düşünüyorum. Çünkü asıl hikâye çoğu zaman orada başlıyor.
“Copilot ne kadar kullanılıyor” sorusundan, “Copilot ne tür değer üretiyor” sorusuna geçiş — aslında bu metriklerin asıl hikâyesi bu.
Niye Bu Kadar Önemli? Sahadan Bir Hikâye
Geçen ay İstanbul’da bir banka müşterimizde tam olarak bu probleme tosladık. CTO bana dönüp “Aşkın, biz 800 geliştirici için Copilot Enterprise lisansı aldık. Yıllık fatura ciddi. Bana ROI gösterebilir mısın?” dedi.
Şimdi gelelim işin can alıcı noktasına.
O zaman elimde sadece şu vardı: kullanıcı sayısı, aktif PR sayısı, üretilen öneri sayısı. Ama “üretilen 12.000 önerinin kaç tanesi gerçek bir güvenlik açığı yakaladı?” sorusuna cevap veremiyordum. Excel’de manuel sample alıp tahmin yürüttüm. Profesyonelce değildi, kabul ediyorum. Hatta biraz el yordamıydı.
Şimdi bu API ile aynı soruya 5 dakikada cevap verebiliyorum. Mesela diyelim ki security tipinde 1.200 öneri çıkmış, bunların 480’i uygulanmış (ilk duyduğumda inanamadım). Yanı %40 adopsiyon oranı. Bu, geliştiricilerin Copilot’un güvenlik uyarılarını ciddiye aldığını gösteriyor gıbı duruyor. Ama eğer style kategorisinde %85 uygulanma oranı varken security %15’de kalıyorsa… orada bir şeyler ters gidiyor demektir.
Türkiye’deki Şirketler İçin Anlamı
Türkiye’de Copilot Enterprise benimseme süreci biraz farklı ilerliyor. Avrupa veya ABD’deki müşterilerime kıyasla, — ki bu tartışılır — Türk şirketleri “lisansı aldık. Gerçekten kullanıyor müyüz?” sorusuna çok daha hassas yaklaşıyor. Çünkü TL bazında bu lisanslar baya tutuyor — kişi başı aylık $19’lık Enterprise lisansını 500 kişi için hesaplayın; yıllık 4 milyon TL’yi geçen bir kalem oluyor.
Böyle bir tabloda bu yeni metrikler CFO’ya gösterilecek somut delile dönüşüyor desek yeridir. “Bakın, Copilot bu çeyrekte 230 potansiyel SQL injection açığını PR aşamasında yakaladı, geliştiriciler bunların 180’ını düzeltti” demek — bu konuşma artık yapılabilir hâle geliyor.GitHub Copilot Build Performance: Proje Bazlı Analiz Geldi yazımda da değindiğim gıbı, ölçüm olmayan yerde optimizasyon olmaz. Bu konuyla ilgili Kubernetes v1.36 Volume Group Snapshot: Sonunda GA Oldu yazımıza da göz atmanızı tavsiye ederim.
Durun, bir saniye.
API Yanıtının Pratikte Nasıl Göründüğü
Doğrusu, Lafı dolandırmadan örnek bir response göstereyim; çünkü soyut anlatınca konu hemen uçup gidiyor. Tipik bir günlük raporda pull_requests objesi şuna benzer bir şey dönduruyor: Daha fazla bilgi için copilot konusundaki yazımız yazımıza bakabilirsiniz. Azure SQL’de AI_GENERATE_EMBEDDINGS GA Oldu: Saha Notları yazımızda bu konuya da değinmiştik.
{
"pull_requests": {
"total_pull_requests": 342,
"total_copilot_review_comments": 1847,
"copilot_suggestions_by_comment_type": [
{
"comment_type": "security",
"total_copilot_suggestions": 234,
"total_copilot_applied_suggestions": 98
},
{
"comment_type": "bug_risk",
"total_copilot_suggestions": 612,
"total_copilot_applied_suggestions": 287
},
{
"comment_type": "performance",
"total_copilot_suggestions": 145,
"total_copilot_applied_suggestions": 41
},
{
"comment_type": "style",
"total_copilot_suggestions": 856,
"total_copilot_applied_suggestions": 723
}
]
}
}Peki ilk bakışta ne görünüyor? Style önerilerinin %84’ü uygulanırken, performance önerilerinin sadece %28’i kabul edilmiş durumda. Bu tek başına hüküm vermek için yetmez tabi; belki performance önerileri fazla agresif geliyor, belki false positive oranı yüksek, belki de geliştiriciler bunları geç aşamada (mesela merge öncesi son beş dakikada) görüyor. Kapatıp geçiyorlar.
Adopsiyon Oranı Tablosu — Nasıl Yorumlanır?
| Kategori | Adopsiyon | Bence Anlamı |
|---|---|---|
| Security | >%50 | Sorun yok gıbı duruyor; geliştiriciler ciddiye alıyor. |
| Security | <%20 | Dikkat etmek lazım; false positive yüksek olabilir ya da ekip eğitimi şart olabilir. |
| Bug risk | %30-50 | IDare eder; bug risk yorumları zaten biraz subjektif olabiliyor. |
| Style | %70+ | Beklenen sonuç; düzeltmesi kolay olduğu için direnç az oluyor. |
| Performance | <%30 | Önerinin context’i zayıf olabilir; manuel inceleme şart gıbı. |
Tabi bu rakamlar büyük ölçüde benim sahada gözlemlediklerime dayanıyor; GitHub’ın resmî bir benchmark’ı yok henüz diye biliyorum (en azından benim deneyimim böyle). Ama yaklaşık 12 farklı kurumsal projedeki gözlemlerimden çıkardığım bir özet diyelim.
Evet, doğru duydunuz.
E Peki Hangı Senaryolarda İşe Yarıyor?
Senaryo 1: Güvenlik Komitesi Raporlaması
Bak şimdi, Birkaç ay önce bir telekom müşterimizde her ay güvenlik komitesine “shift-left security” başlığı altında rapor sunuyorduk.
Eskiden Snyk + SonarQube + manuel review verilerini karıştırıp slide hazırlıyorduk.
Şimdi Copilot’un security kategorisindeki yakalamalarını da o tabloya ekliyoruz.Defender for Cloud + GHAS Entegrasyonu: Code-to-Cloud GA‘yı da yanına koyunca code-to-cloud güvenlik resmî iyice toparlanıyor diyebilirim.
Senaryo 2: Geliştirici Eğitimi Hedefleme
Eğer bir kategoride sürekli yüksek hacimli öneri çıkıyor ama uygulanma oranı düşükse — burada eğitim ihtiyacı kokusu alırsınız hemen.
Mesela bug_risk önerilerinin %80’i null reference ile ilgiliyse ve uygulanma oranı düşükse, ekibe defensive coding workshop’u düzenlemek mantıklı olabilir.
Basit gıbı duruyor ama etkisi şaşırtıcı olabiliyor.
Senaryo 3: Lisans Yenileme Müzakeresi
Bu çok pragmatik bir kullanım.
Microsoft ile yıllık lisans yenilemesinde elinizde “
Küçük Ekipler vs Enterprise: Farklı Yaklaşımlar
Şimdi şunu açık söyleyeyim:
5-10 kişilik bir startup’sanız,bu metriklerle saatlerce uğraşmaya değer mi? Pek değil. Sezgisel olarak da görebilirsiniz — kendi adıma konuşayım — nelerin işe yaradığını.
Ama100+ geliştirici varsa tablo değişiyor; çünkü iş büyüyünce sezgi tek başına yetmiyor, veri istiyor insan. Ve yönetim de bunu istiyor, açık konuşayım.
- ;Sezgi yetmiyor, veri gerekiyor
- Yönetim raporlama bekliyor
- Farklı ekiplerin (backend, frontend, mobile) farklı kullanım profilleri var; bunları ayrıştırmak gerekiyor
- Lisans maliyeti ciddi; ROI hesabı kaçınılmaz
Açık konuşayım, Küçük ekipseniz benim önerim şu ölür: bu API’yi üç ayda bir,manuel curl ile çek,JSON’u Excel’e at,gözünle bak.Yeter.Yıllık50.000 TL’lık lisans için Power BI dashboard kurmak biraz overkill kalır.
Enterprise tarafındaysanız iş ciddi; Power BI veya Grafana üzerinde otomatik bir dashboard kurmanızı tavsiye ederim.Agent Pull Request’leri Her Yerde: Doğru Review Nasıl?başlıklı yazımda da bahsetmiştim—agent ekosistemi büyüdükçe,sadece insan review değil, makine review’larını da ölçmek gerekiyor. Kubernetes v1.36 Declarative Validation: GA’ya Ulaştı yazımızda bu konuya da değinmiştik.
Daha doğrusu çağıramazsınız demek daha doğru.
Evet.
Tam da öyle.
Manuel kontrol burada devreye giriyor.
Ve evet,biraz uğraştırıyor.
İşte böyle.
Şey…
Bak şimdi:
Bunu bilmeden başlayınca insan boş yere vakit kaybedebiliyor.
Bu yüzden önce yetkiyi doğrulayın.
Sonra veri gelir.
Bazen sıra böyle çalışıyor.
Önce erişim,gerekirse sonra heyecan.
Bu arada html yapısını bozmayalım,dediğim gıbı devam edelim.
Bir cümle daha:
Sadece admin olanlar görebiliyor.
Kısacası durum bu.
Bilgi:
Bu metriklere erişmek için gerekli izinler olmadan endpoint boş dönebilir ya da hata verebilir.
Not düşeyim.
Her şey oradan başlıyor.
Çok uzattım.
Neyse,kapatıyorum.
Rahat olun.
Devam edelim.
Doğru yer burasıdır.
Aynen öyle.
Erişim yoksa veri de yok.
İşin aslı bu.
Yetki kısmını atlamayın.
Ek not:
Organization owner ya da enterprise admin olmak gerekiyor.
Başka yolu pek yok.
Bu kadarı yeterli.
Son söz:
Önce izin,kalanını sonra konuşuruz.
Pratik Uygulama Rehberi: İlk Adımlar
Size bir şey söyleyeyim, Hadi somutlaştıralım.Bu metrikleri kendi organizasyonunuzda kullanmak istiyorsanız,ilk hafta için şu yol haritasını öneririm: Daha fazla bilgi için Kubernetes v1.36 DRA: Yeni Sürücüler ve Sahadan Notlar yazımıza bakabilirsiniz.
- Erişim doğrulama: Personal Access Token ‘ınızda
manage_billing :copilotveyaread :enterprisescope ‘u olduğundan emin olun. — ciddi fark yaratıyor - İlk çekim:28 günlük rolling window raporu çekin.Tek seferlikbirısınma türü olsun.
- Baseline kaydedin: İlk ay için her kategori için adopsiyon oranını not alın.Sizin baseline ‘ınızbu olacak.
- Anomali avı:Dikkat edin; hangı kategoride %20’nın altında adopsiyon var? O kategoriyi mercek altına alın.Sample10 PR seçip manuel inceleyin—false positive mi,yoksa eğitim mi gerekli?
- Aylık takıp:Aylık review toplantınıza busayıları ekleyin.Trend görmek tek seferlik snapshot’tan çok daha değerli ölür.
Bence, (Ha,bir de şunu söyleyeyim—bu metrikler tek başına anlamsız.Mutlaka PR throughput, mean time to merge gıbı geleneksel DevOps metriklerinizle birlikte yorumlayın.Yoksa “Copilotto” gıbı sevindiğiniz anda aslında merge süresinin üç katına çıktığını fark etmeyebilirsiniz.) Denge önemli.Burada mesele sadece sayı değil, bağlamdır.Evet.Bu kadar mı? Hayır tabii ki değil.Ama temel fikir bu.Hmm… Kurcalayın derim.
Eksi Kalan Yönler — Eleştirmeden Olmaz
Bak şimdi, Açık konuşayım, her şey gül bahçesi değil.Bu yeni metriklerin bence iki büyük eksiği var:
bircisi,repoz bazlı kırılım yok.Neyse,düzeltelim:Yani200 repo’lu bir organizasyonda hangı repo’da Copilotu’n en çok değer ürettiğini göremiyorsunuz.Bu büyük kayıp çünkü gerçek aksiyonlar genellikle repo seviyesinde alınıyor.Bir takım iyi kullanırken diğeri kullanmıyorsa,bunu ancak repo bazlı görebilirsiniz.GitHub’ın yol haritasında olduğunu söylüyorlar ama tarih yok.Azıcık beklemek gerekecek galiba.
İkinciSI,”applied” tanımı biraz muğlak.Biraçıklama yapayım:Geliştirici Copilotu’nönerisinden ilham alıp benzer ama farklıbir kod yazarsa ne olacak? Yoksa sadece”Apply suggestion” butonuna tıklanırsa mı applied sayılıyor? Dokümantasyonda bunun cevabı net değil.Kendi testlerimde direkt apply’ların sayıldığı izlenimini edindim ama doğrulanmaya muhtaç.Hmm,burasıda önemli.
Bir de küçükbir hata anlatayım—ilk denediğimde28 günlük rapora geçtiğimde array boş geldi.Telaşlandım,”yeni feature bozuk mu?” dedim.Sonra fark ettim ki organizasyondaki bazı repolarda Copilo t code review henüz aktif edilmemiş.Aktif olmayan yerden veri gelmiyor tabi.Aşikar gelebilir ama o an saatimi yedi.Dedik ya,bazen problem kodda değil yetkidedir.Evet,Basitmiş meğer.Olsun.））
Bence İleri Vadede Ne Ölür?
Tahminim şu: GitHub bumetrikleri6 ay içinde repo seviyesine indirecek.Ardından”by language”,”by team”gıbı ek kırılımlar gelecek.Belki2027’deCopiot ROI Calculatorgibi hazırbir UI bile çıkar—şu anmanuel hesapladığımız şeyleri otomatik gösteren.Nasıl desem,biraz gecikir ama gelir gıbı duruyor.
Diğer tahminimde şu:yakındaCopilo t Agent Evaluations:Ajan Kalitesini Ölçen CLI Geldi siga bağlantılıbirmetrik birleşmesi olacak.Yani sadece review değil,agent’l arın ürettiği PR’l arın kalitesi de aynı dashboard’da görülecek.Mantıklıbir evrim.Baya mantıklı aslında.）
Sıkça Sorulan Sorular
Bu metrikleri kim çekebilir?
Enterprise admin’leri ve organization owner’ları çekebiliyor. Geliştiriciler ya da sıradan üyeler erişemiyor. Token’ınızda read:enterprise veya benzeri uygun bir scope olması gerekiyor.
Hangı comment_type değerleri var?
Resmî listede şu an security, bug_risk, performance, style gıbı kategoriler var. Ama GitHub bu listeyi zaman içinde genişletebilir — yanı bence kodunuzda hard-coded liste tutmak yerine gelen büyük çoğunluk kategorileri dinamik işlemek çok daha sağlıklı.
Repo bazlı kırılım ne zaman gelecek?
GitHub yol haritasında olduğunu söyledi ama net bir tarih vermedi. Şu an sadece organizasyon ve enterprise seviyesinde mevcut. Bu süreçte alternatif olarak Copilot review yorumlarını PR API’si üzerinden manuel toplayıp repo bazlı analiz yapabilirsiniz — hani biraz zahmetli. Işe yarıyor.
“Applied suggestion” tam olarak ne demek?
Aslında geliştiricinin Copilot’un önerisini doğrudan kabul etmesi anlamına geliyor, mesela “Commit suggestion” butonuyla. Geliştirici öneriden esinlenip elle benzer bir kod yazarsa bu sayılmıyor. Yanı metrik biraz muhafazakâr — açıkçası gerçek etkinin altında bir rakam gösteriyor olabilir.
Bu API’yi otomatik olarak nasıl çekebilirim?
Bir scheduled GitHub Action veya Azure Function ile günlük çekim ayarlayabilirsiniz (buna dikkat edin). Çekilen JSON’u bir storage’a (Blob, S3 vb.) atın, üzerine Power BI veya Grafana bağlayın. Tecrübeme göre haftalık çekim daha mantıklı — günlük data noise’u arttırıyor, trendi görmek zorlaşıyor.
Kaynaklar ve İleri Okuma
GitHub Changelog: Copilot code review comment types now in usage metrics API
GitHub REST API: Copilot Usage Metrics Resmî Dokümantasyonu
GitHub Docs: Copilot Code Review Kullanım Kılavuzu
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.
