GitHub Copilot’un PR Etkisi Ölçülüyor: Yeni Metrikler
Eh, Bakın şimdi, GitHub tarafında küçük gibi görünen ama pratikte bayağı önemli bir güncelleme var. Copilot artık sadece kod yazan tarafta değil, kodu gözden geçiren tarafta da ölçülebiliyor (evet, doğru duydunuz). İşin aslı şu ki, ekipler uzun zamandır “Copilot gerçekten hız kazandırıyor mu?” diye soruyordu (kendi tecrübem). Şimdi bu sorunun cevabını biraz daha net görmeye başlıyoruz.
📋 İçindekiler
- Yeni olan ne? Kısa cevap: Review tarafı
- Neden önemli? Çünkü review görünmez kalıyordu
- Metrikleri nasıl okumalı? Yanlış yorumlamaya dikkat
- Sahada ben olsam nasıl kullanırım?
- Nerede eksik kalıyor? Biraz dürüst olalım
- Metrikleri birlikte okumak neden şart?
- Ekipler ne yapmalı? Pratik öneriler
- Sıkça Sorulan Sorular
- Kaynaklar ve İleri Okuma
Ben bu tip metriklere hep biraz şüpheyle yaklaşırım. Kağıt üstünde güzel durur. Ama sahada? Bazen bambaşka çıkar. Yine de Azure ve DevOps projelerinde yıllardır gördüğüm şey şu: ölçemediğiniz şeyi iyileştiremiyorsunuz — bu kadar basit, bu kadar net. 2024’ün sonlarında bir finans müşterisinde PR akışını toparlarken bunu çok net yaşadık; review süresi düşmüş mü, merge bekleme süresi azalmış mı, kimse hissiyatla konuşuyordu, herkes “sanki daha hızlı” ya da “sanki aynı” diyordu, ta ki sayılar gelene kadar. Evet. İş değişti.
Yeni olan ne? Kısa cevap: Review tarafı
Bilmem anlatabiliyor muyum, Hadi gelelim meselenin can alıcı kısmına. GitHub Usage Metrics API’ye iki yeni alan eklenmiş ve ikisi de Copilot code review aktivitesine odaklanıyor:
- pull_requests.total_merged_reviewed_by_copilot: Belirli raporlama döneminde hem merge edilmiş hem de Copilot code review almış pull request sayısı.
- pull_requests.median_minutes_to_merge_copilot_reviewed: Sadece Copilot tarafından review edilen pull request’lerin oluşturulmasından merge edilmesine kadar geçen medyan süre.
Önceki sürümde odak daha çok Copilot’un PR üretmesi üzerindeydi; yanı coding agent’ın açtığı PR’lar ve onların merge süreleri izleniyordu. Şimdi işin diğer yarısı da tabloya girdi. Önemli bu. Çünkü gerçek dünyada PR yaşam döngüsü tek yönlü değil — bir ajan kod yazar, başka bir ajan ya da insan bakar, sonra merge olur, ve zincirin sadece ilk halkasını görerek yorum yapmak biraz kör uçuşa benziyor, hani pusula var ama haritanın yarısı eksik gibi bir şey.
Tuhaf ama, Geçen ay Mart 2026’da Logosoft’ta iç değerlendirme toplantısında tam bu konu açıldı. Bir takım “Copilot bize hız kazandırıyor” diyordu, (söylemesi ayıp) başka bir takım işe “review tarafında hâlâ insan yükü çok” diye itiraz ediyordu. Tartışma döngüye girdi. İşte bu yeni metrikler o tartışmayı biraz daha somutlaştırıyor. Hani lafı gevelemeden söyleyeyim: artık his değil, veri konuşuyor.
Neden önemli? Çünkü review görünmez kalıyordu
Çoğu ekip Copilot’u kod yazma asistanı olarak düşünüyor. Doğru, ama eksik bir bakış bu. Review tarafı en az yazma kadar kritik (ciddiyim). Bazen daha bile. Hele bir de enterprise ortamlarda bir PR’ın hızlı merge olması sadece geliştiricinin moralini değil, release takvimini de, dolayısıyla bütçeyi de, müşteri vaatlerini de etkiliyor — domino etkisi tam anlamıyla (bu beni çok şaşırttı)
Bunu biraz açayım. Daha fazla bilgi için github konusundaki yazımız yazımıza bakabilirsiniz.
Açık konuşayım, AZ-305’e hazırlanırken ben hep şunu düşünürdüm: mimariyi kurmak ayrı şeydir, işletmek ayrı şeydir. Aynı mantık burada da geçerli. Bir aracın “işe yaradığını” söylemek kolay; zor olan hangi aşamada değer kattığını göstermek. Copilot’un review katkısını görmek bize şunu söylüyor: otomatik inceleme gerçekten PR’ları hızlandırıyor mu, yoksa sadece güzel bir yan özellik mi? Cevap önemli.
Bir de şu var. Bazı ekiplerde bottleneck yazan kişide değil, onay bekleyen yerde oluyor. 2025’in başında bir telekom müşterisinde bunu birebir gördük; kod üretimi hızlıydı ama inceleme kuyruğu uzuyordu. Geliştirici “ben işi bitirdim” diyor. PR üç gün açık kalıyor. Moral sıfır.
Küçük startup ile enterprise arasında fark büyük
Araya gireyim: Küçük bir startup için bu metrikler daha çok “takımımız hızlı mı?” sorusuna cevap verir. Orada birkaç kişi zaten her şeyi biliyor olabilir; yine de otomatik review’ün gerçekten merge süresini kısaltıp kısaltmadığını görmek faydalı — en azından kör nokta kalmaz.
Bunu biraz açayım.
Enterprise seviyede işe mesele bambaşka (şaşırtıcı ama gerçek). Orada branch policy’ler var, compliance var, güvenlik taramaları var, bazen coğrafi ekipler var (İstanbul başka saat dilimiyle Londra’ya yetişmeye çalışıyor). Böyle yerlerde medyan süre küçücük oynasa bile etkisi ciddi olur. Baya ciddi. Bu konuyla ilgili github ile ilgili önceki yazımız yazımıza da göz atmanızı tavsiye ederim.
Copilot reviewed pull request metriği bana göre tek başına “başarı” demek değil; ama review kültürünün gerçekten işe yarayıp yaramadığını anlamak için fena olmayan bir sinyal veriyor.
Metrikleri nasıl okumalı? Yanlış yorumlamaya dikkat
Burada en sık yapılan hata şu: sayı düştü mü hemen sevinmek. Ya da arttı mı hemen üzülmek. O kadar basit değil bu iş. Mesela median time-to-merge düşebilir çünkü ekip küçük ve disiplinli çalışıyordur; ya da tam tersi artabilir çünkü sistem daha karmaşık hâle gelmiştir ve review kalitesi yükselmiştir, yanı aslında iyi bir şey olmuştur ama grafiğe bakınca panik yapılır. Bu konuyla ilgili Copilot Code Review Metrikleri: Aktif mi Pasif mi? yazımıza da göz atmanızı tavsiye ederim.
Bunu geçen sene Nisan ayında bir SaaS müşterisinde yaşadık. PR sayısı azaldı diye herkes panikledi. Peki, maalesef. Meğer feature flag stratejisine geçilmişti ve işler daha kontrollü ilerliyordu. Yanı tek metrikle karar vermek bazen insanı yanlış yere götürüyor. Bayağı yanlış yere.
| Metrik | Ne anlatır? | Şuna dikkat: nokta |
|---|---|---|
| total_merged_reviewed_by_copilot | Copilot review alan merged PR sayısı | Sadece hacmi gösterir, kaliteyi tek başına göstermez |
| median_minutes_to_merge_copilot_reviewed | Copilot-reviewed PR’ların merge süresi | Düşüş çoğu zaman iyileşme anlamına gelmez; kapsam değişmiş olabilir |
| overall median time-to-merge | Tüm PR’ların genel temposu | Copilot etkisini kıyaslamak için baseline gerekir |
Tabiî burada baseline şart. Yoksa elinizdeki sayı havada kalır, yanı hiçbir anlam taşımaz. Genel ortalama ile Copilot-reviewed grubu yan yana gelmeden “iyi mi kötü mü” tartışması bitmez (inanın bana). Bitmez, bitmedi de zaten.
Sahada ben olsam nasıl kullanırım?
Açık konuşayım: ben bu metriği önce pilot olarak açarım. Enterprise’da direkt büyük çoğunluk organizasyona yaymak yerine önce birkaç repo seçerim — biri backend yoğun olsun, biri frontend olsun, biri de güvenlik hassasiyeti yüksek olsun, mesela ödeme servisi gibi bir şey. Sonra single-day raporla kısa dalgalanmaları izlerim, 28 günlük raporla trendi okurum. Sabırlı olmak şart burada.
Evet, doğru duydunuz.
Bana göre iyi çalışan kullanım senaryoları
- Release öncesi tempo analizi: Merge süresi uzuyor mu kısalıyor mu bakılır. — bunu es geçmeyin
- Ekip bazlı karşılaştırma: Copilot-reviewed PR oranı hangi takımda yüksek görülür.
- Kod standardı etkisi: Review sonrası düzeltme sayısı azalıyor mu anlaşılır.
Küçük bir detay: Bir dakika, şunu da ekleyeyim: bu metrikleri performans notu gibi kullanmayın derim. İnsanlar hemen savunmaya geçer. Sonra veri bozulur. Klasik. Benzer hatayı 2023’te kendi lab ortamımda yaptım; birkaç arkadaşla deneme yaparken herkesi skorlayınca davranış değişti ve sonuçlar çarpıldı. Emin olun, çarpılır. Bu konuyla ilgili AG-UI ile Çoklu Ajan Arayüzü: Gerçek Zamanlı Demo yazımıza da göz atmanızı tavsiye ederim.
Nerede eksik kalıyor? Biraz dürüst olalım
Kağıt üstünde sistem güzel görünüyor. Ama ham tarafları var, bunu söylemek lazım. Mesela metrikler size neden hızlı olduğunu söylemiyor; sadece ne kadar hızlı olduğunu gösteriyor. Team policy değiştiyse mi hızlandı, yoksa gerçekten Copilot iyi öneriler verdiği için mi — bunu ekstra analiz etmeniz gerekiyor. Sistem size o soruyu cevaplamıyor (buna dikkat edin)
Size bir şey söyleyeyim, Ayrıca quality boyutu hâlâ biraz sisli. Merge süresi kısa diye kod kaliteli olacak diye bir kural yok! Hatta bazen tam tersi oluyor. Hızlı merge edilen ama sonra bug çıkaran işler gördüm ben (bizzat test ettim). Maalesef. Birden fazla kez. MCP Apps’i Kolaylaştıran Fluent API: Sahada Ne Değişiyor? yazımızda bu konuya da değinmiştik.
Hani, 2026’nın Mart ayında bir kamu kurumunda yaptığımız gözlemde de aynı durum çıktı: otomatik review kabul oranı fena değildi ama bazı edge-case kontroller yine insana kalıyordu. Dur bir saniye — aslında burada mesele aracın kötü olması değildi. Ekiplerin beklentisi fazla büyüktü (yanlış duymadınız). Copilot yardımcı olur, ama son sözü genelde süreç söylüyor.
Metrikleri birlikte okumak neden şart?
Bir şey dikkatimi çekti: Bence en doğru yaklaşım çapraz okuma yapmak. Copilot-created PR metrikleri, Copilot-reviewed PR metrikleri ve genel repository throughput — bu üçlü birlikte bakılınca resim netleşiyor. Tek başına biri sizi yanıltabilir (ciddiyim). Üçü beraber işe bayağı sağlam sinyal verir. Nokta.
{
"single_day": {
"pull_requests.total_merged_reviewed_by_copilot": 42,
"pull_requests.median_minutes_to_merge_copilot_reviewed": 187
},
"rolling_28_days": {
"pull_requests.total_merged_reviewed_by_copilot": 980,
"pull_requests.median_minutes_to_merge_copilot_reviewed": 214
}
}
Böyle çıktıları görünce ben önce trend ararım. Tek güne takılmam. Eğer tek günlük veri uçuyorsa genelde orada gürültü vardır, bir şey değildir. Ama dört haftalık eğri düzgünse işte o zaman konuşulur, o zaman masa kurulur. Bir müşteri toplantısında grafiği böyle gösterince herkesin yüz ifadesi değişmişti; çünkü sayı ilk kez hikâye anlatmaya başlamıştı. Bayağı iyi hissettirmişti doğrusu.
Ekipler ne yapmalı? Pratik öneriler
- COPILOT-reviewed ve human-only PR gruplarını ayrı takip edin.
- Tamamen medyana bakmayın; dağılımı da kontrol edin. (bence en önemlisi)
- Kritik repolarda güvenlik ve kalite kontrollerini gevşetmeyin. (bence en önemlisi)
- Pilotu küçük başlatın, sonra genişletin.
Bence özellikle FinOps kafasıyla yaklaşınca iş daha sağlıklı oluyor: hangi kullanım size zaman kazandırdı, hangi akış gereksiz maliyet üretti, hangi ekip gerçekten fayda gördü — hepsini ayrı ayrı görmek lazım, toplu rakama bakıp “iyi gidiyor” demek yetmiyor. Ben AZ-104 ve AZ-500 çalışırken de aynı disiplini sevmiştim; önce görünürlük, sonra karar, sonra optimizasyon. Burada da formül aşağı yukarı aynı.
Sıkça Sorulan Sorular
COPILOT-reviewed pull request metriği neyi ölçüyor?
COPILOT code review alan ve ardından merge edilen pull request sayısını ölçüyor.
Ayrıca bu gruptaki pull request’lerin creation-to-merge medyan süresini veriyor.
Yanı hem hacmi hem hızı görüyorsunuz.
Bunu organization seviyesinde mi enterprise seviyesinde mi görebilirim?
Evet, ikisinde de görebilirsiniz.
Neyse, gitHub Usage Metrics API üzerinden single-day. 28 günlük rolling window raporları destekleniyor.
Erişim yetkisi olan enterprise admin veya organization owner kullanabiliyor.
COPILOT reviewed metric ile COPILOT authored metric aynı şey mi?
Hayır.
Authoring metriği Copilot coding agent tarafından oluşturulan pull request’leri izlerken,
bu yeni metrikler Copilot code review alan pull request’leri izliyor.
İki farklı katkıyı ayırmak gerekiyor (ki bu çoğu kişinin gözünden kaçıyor)
Metrikler performans değerlendirmesi için kullanılmalı mı?
Bence doğrudan kullanılmamalı.
Daha çok süreç iyileştirme ve trend analizi için uygunlar.
Performans puanı gibi kullanırsanız insanlar davranışını değiştirir ve veri kirlenir.
Kaynaklar ve İleri Okuma
GitHub Blog duyurusu: Copilor-review metrics update (orijinal duyuru)
GitHub Docs — Copilit usage metrics rehberi
Microsoft Learn — Pull Request süreçlerini yönetme (inanın bana)
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.
3 comments