# TD-092 · Kabul oranını tek başına başarı sayma

Kabul oranı öneriler iyileşince de kullanıcı bakmadan kabul edince de yükseliyor ve panoda ikisi aynı görünüyor. Desen her kabul metriğinin yanına kontrol grubuyla ölçülen bir iş sonucu koyar.

- Adres: https://tandem.komunite.com.tr/desen/kabul-oranini-tek-basina-basari-sayma
- Yer: Zamanla > Ölçüm
- Seviye: Temel. Her AI özelliğinde olmalı.
- Son inceleme: 28 Ekim 2026, Komünite editörlüğü

## 30 saniyede dene

1. Ekibinin AI özelliği için izlediği ana metriği bul. Kabul oranı mı, kabul edilen öneri sayısı mı, AI'ın yazdığı satır mı?
2. Son model ya da ayar değişikliğinin raporunu aç. Kabul oranının yanında işin sonucunu gösteren bir sayı var mı, görev süresi, geri alınan değişiklik ya da yeniden açılan iş gibi?
3. Kabul olaylarında önerinin gösterilmesiyle kabul edilmesi arasında geçen süreye bak. Okunamayacak kadar hızlı kabullerin payını hesapla.
4. Son değişiklikte gösterilen öneri sayısı düştü mü? Düştüyse kabul oranındaki artışın ne kadarının yalnız paydanın küçülmesinden geldiğini hesapla.

## Sorun

Bir kod asistanının ekibi yeni bir öneri ayarını iki hafta deniyor. Öneriler daha kısa geliyor ve daha sık görünüyor. Kabul oranı belirgin biçimde yükseliyor, ankette geliştiriciler daha hızlı yazdıklarını söylüyor. Ekip ayarı herkese açıyor. Üç ay sonra kimse işin daha hızlı bittiğini gösteremiyor. Birleştirmeden sonra geri alınan değişiklik ise artmış.

Kabul oranı iki ayrı yoldan yükselir. Öneriler daha isabetli olur ve kullanıcı işine yarayanı daha sık alır. Ya da kullanıcı öneriye daha az bakar ve kabul tuşu bir alışkanlığa döner. Panodaki sayı bu ikisini ayırmaz. Gösterme ayarı da sayıyı oynatır, çünkü oranın paydası gösterilen öneri sayısıdır. Gösterilmeyen öneri hiç reddedilmez.

Kabul oranı kullanıcının bir öneriyle devam ettiğini söyler. İşin daha hızlı ya da daha doğru bittiğini söylemez. Tek başına başarı sayılan kabul oranı iyileşmeyle alışkanlığı aynı yükseliş diye okur.

## Neden atlanıyor

Kabul oranı hem ucuz hem inandırıcı. Her gösterimde ve her kabulde kendiliğinden oluşur, günlük çizilir, model sürümleri arasında hemen karşılaştırılır. Arkasında bir dayanak da var. GitHub'tan Ziegler ve arkadaşlarının Copilot araştırmasında geliştiricilerin verimlilik algısını en iyi açıklayan ölçü [gösterilen önerilerin kabul edilme oranıydı](https://arxiv.org/abs/2205.06537). GitHub'ın metrik belgesi de yüksek kabul oranını önerilerin [ilgili ve işe yarar olduğunun işareti](https://docs.github.com/en/copilot/concepts/copilot-usage-metrics/copilot-metrics) diye anlatıyor. Bu sayıyı izleyen ekip haklı olduğunu düşünür.

Aynı makale sınırı da yazıyor. Algılanan verimlilik gerçek verimlilik demek değil, kabul oranını en üste çıkarmak geliştiriciyi memnun edip [işi kısaltmayabilir](https://arxiv.org/abs/2205.06537). Yazarlar sayının nasıl oynanabileceğini de gösteriyor. Bir öneriyi ikiye bölüp parçaları art arda göstermek tek bir kabulü iki kabule çevirir, reddi pek artırmaz ve kullanıcıya bir şey katmadan oranı yükseltir. Öneriyi ne zaman göstereceğine karar veren her ayar aynı etkiyi yapar. Mozannar ve arkadaşları gösterilen önerilerin [%25'ini, %95'inin zaten reddedileceğini garanti ederek gizleyebildi](https://arxiv.org/abs/2306.04930). Kullanıcıyı gereksiz öneriyle bölmemek için iyi bir iş. Panoda ise payda küçülür, kabul edilen öneri neredeyse aynı kalır ve oran kalite artışı gibi görünür.

Üçüncü neden, kabul oranının yanına konan ikinci sayı. Ekipler çoğu zaman bir memnuniyet anketi ekler ve iki sayının birlikte yükselmesini kanıt sayar. İkisi de kullanıcının nasıl hissettiğini ölçer. İşin süresi, hatası ve sonucu ikisinde de yok.

## Desen

Kabul oranı bir kullanım sinyali. Ürünün işe yarayıp yaramadığını işin sonucu söyler ve iki sayı aynı raporda durur.

1. **Kabul oranını adıyla koy.** Panoda kullanım bölümünde dursun, kalite ya da başarı başlığının altında durmasın. Yanında gösterilen ve kabul edilen öneri sayıları ayrı ayrı yazsın. Oran tek başına durduğunda paydanın küçüldüğünü kimse görmez.
2. **Her kabul metriğine bir iş sonucu eşle.** Önerinin hizmet ettiği işin sonunu tanımla ve ölç: görevin bitme süresi, birleştirmeden sonra geri alınan değişiklik, yeniden açılan talep, düzeltme gerektiren çıktı. Kabul yükselirken sonuç yerinde sayıyorsa yükselişi başarı sayma.
3. **Sonucu kontrol grubuyla ölç.** Ayar ya da model değişikliğini kullanıcıların rastgele seçilmiş bir kısmına aç, kalanını karşılaştırma grubu olarak tut. Önce ve sonra karşılaştırması mevsimi, iş yükünü ve ekipteki değişimi ayıramaz.
4. **Algıyı sonuç yerine koyma.** Anketteki “daha hızlıyım” cevabı kullanıcının deneyimini söyler. Ölçülen süreyle ayrı satırda raporla.
5. **Hızlı kabulü ayrı say.** Gösterimden çok kısa süre sonra gelen kabul okunmadan verilmiş olabilir. Oran yükselirken bu kabullerin payı da yükseliyorsa artışın bir kısmı azalan dikkatten geliyor olabilir.
6. **Gösterme kuralı değişince kıyası yeniden kur.** Gösterme eşiği, öneri uzunluğu ya da tetikleme anı değiştiyse kabul oranını önceki dönemle doğrudan karşılaştırma. Ziegler ve arkadaşları da oranın geçerliliğinin özellikle [çalışma koşulları büyük ölçüde değiştiğinde sınırlı kaldığını](https://arxiv.org/abs/2205.06537) yazıyor.

Kabul oranı model ekibine hızlı bir işaret vermeye devam eder. Yayına alma kararını işin sonucuyla ver.

## Önce ve sonra

Aynı deney, iki rapor. Soldaki yalnız kabul oranına ve memnuniyet anketine bakıyor ve ayarı kazanan sayıyor. Sağdaki kabulün yanına kontrol grubuyla ölçülen iş sonucunu koyuyor, gösterim sayısını ve çok hızlı kabulleri ayrı gösteriyor, ayarı açmadan önce oranın neden yükseldiğini soruyor.

Örnek ekran (kurgusal): Kod asistanında yeni bir öneri ayarı denendi, öneriler daha kısa ve daha sık geliyor. Ekip iki haftalık deneyin sonucuna bakıp ayarı herkese açıp açmayacağına karar veriyor.

### Önce: Deney · öneri ayarı B

- Bilgi: Deney 12 · ayar B · iki hafta · 380 geliştirici
- Adım (tamam): Kabul oranı yükseldi · %27 → %36
- Adım (tamam): Memnuniyet anketi olumlu · “daha hızlı yazıyorum” diyen: %68
- AI: Ayar B iki ölçütte de önde. Herkese açmayı öneriyorum.
- Düğmeler: Herkese aç

1. Rapor yalnız kabul oranına ve algıya bakıyor. Oran öneriler iyileşince de geliştiriciler daha az bakınca da yükselir.
2. Ayar, işin daha hızlı ya da daha doğru bitip bitmediği ölçülmeden herkese açılıyor.

### Sonra: Deney · öneri ayarı B

- Bilgi: Deney 12 · ayar B · iki hafta · 380 geliştirici · kontrol grubu 380
- Adım (tamam): Kabul oranı yükseldi · %27 → %36 · gösterilen öneri 41 bin → 70 bin
- Adım (bekliyor): Görev süresi değişmedi · kontrol grubu 3 sa 12 dk · ayar B 3 sa 15 dk
- Adım (hata): Birleştirmeden sonra geri alınan değişiklik arttı · %3,8 → %5,9
- Adım (hata): Okunmadan kabul edilmiş olabilecek öneri arttı · gösterimden sonraki ilk 400 ms'de kabul: %14 → %31
- AI: Kabul oranı yükseldi ama iş daha hızlı bitmedi ve geri alınan değişiklik arttı. Artışın bir kısmı çok hızlı kabullerden geliyor. Ayarı açmadan önce bu kabullerden örnek göstereyim mi?
- Düğmeler: Hızlı kabulleri incele · Deneyi uzat

1. Kabul oranının yanında kontrol grubuyla karşılaştırılan iş sonucu duruyor, görev süresi ve birleştirmeden sonra geri alınan değişiklik.
2. Gösterim sayısı ve okunmadan verilmiş olabilecek hızlı kabuller ayrı görünüyor. Ekip oranın neden yükseldiğini anlamadan ayarı açmıyor.

## Piyasada

GitHub'ın Copilot metrikleri kabul oranının yanında bir de çekme isteği yaşam döngüsü tanımlıyor: Copilot kullanımının [çekme isteği sonuçlarıyla ve teslim akışıyla nasıl ilişkili olduğu](https://docs.github.com/en/copilot/concepts/copilot-usage-metrics/copilot-metrics). Belge birleştirme sayısını ve birleştirmeye kadar geçen süreyi bu başlık altında sayıyor. Ayrıca kullanıcıları benimseme düzeyine göre gruplayıp bu grupları çekme isteği çıktısına bağlayan bir etki panosu sunuyor. Bu gruplar kullanıcıların kendi kullanımından oluşuyor. Yoğun kullanan geliştirici zaten daha çok çekme isteği açan biri olabilir. Bu farkı rastgele bir kontrol grubu ayırır.

Google iç kod tamamlamasını anlatırken soruyu açıkça koydu. Makine öğrenmesiyle kod tamamlamanın verimliliğe etkisi, [algılanan verimliliğin ve kabul edilen önerilerin ötesinde açık bir soruydu](https://research.google/blog/ml-enhanced-code-completion-improves-developer-productivity/). Şirket kabul oranını da raporladı, ama asıl sonucu tamamlamayı kullanan geliştiricileri bir kontrol grubuyla karşılaştırarak ölçtü. Derlemeler ve testler arasındaki kodlama döngüsü süresi [%6 kısaldı](https://research.google/blog/ml-enhanced-code-completion-improves-developer-productivity/). Kabul oranı bu raporda bir ara bilgi, iş sonucu ise kontrol grubuna göre ölçülen fark.

## Kanıt

METR 2025'te deneyimli açık kaynak geliştiricileriyle randomize bir deney yaptı ve geliştiricilerin kendi depolarındaki gerçek işleri rastgele iki gruba ayırdı: AI araçlarının serbest olduğu ve olmadığı işler. Geliştiriciler başlamadan önce AI'ın işi [%24 kısaltacağını tahmin etti, deneyden sonra %20 kısalttığını düşündü. Ölçülen süre ise %19 uzamıştı](https://arxiv.org/abs/2507.09089). Geliştiriciler yavaşladıklarını deneyimledikten sonra bile hızlandıklarına inanıyordu.

METR Şubat 2026'da yeni bir değerlendirme yayımladı. Katılımcılarla konuşmalarına göre geliştiriciler bugün AI araçlarıyla [büyük olasılıkla daha çok hızlanıyor](https://metr.org/blog/2026-02-24-uplift-update/). Yeni deneydeki seçilim etkileri yüzünden verilerinin bu artışın büyüklüğü için çok zayıf bir kanıt olduğunu da ekliyorlar. Aynı yazı geliştiricilerin kendi bildirdiği hızlanmanın [güvenilmez olabildiğini](https://metr.org/blog/2026-02-24-uplift-update/) yeniden söylüyor. Hız sonucu eskimiş olabilir, algıya dayanan tahminin sorunu eskimedi.

DORA'nın 2024 raporu aynı ayrımı ekip düzeyinde ve anket verisiyle gösteriyor. Raporun tahminine göre [AI benimsemesi %25 arttığında kişinin verimliliği yaklaşık %2,1 artıyor, teslimat hızı %1,5 ve teslimat istikrarı %7,2 düşüyor](https://dora.dev/research/2024/dora-report/2024-dora-accelerate-state-of-devops-report.pdf). Raporun varsayımına göre AI aynı sürede daha çok kod yazdırınca değişiklikler büyüyor olabilir. DORA'nın yıllardır gördüğü gibi büyük değişiklik daha yavaş ilerler ve daha sık sorun çıkarır. Kişinin hissettiği hız ekibin teslimatına kendiliğinden geçmiyor.

Bu çalışmaların hepsi yazılım üzerinde. METR'ın deneyi küçük bir grupla ve belirli bir dönemin araçlarıyla yapıldı. DORA'nınki ankete dayanıyor ve bir ilişki gösteriyor, nedenini göstermiyor. Senin ürünündeki kabul oranının neyi taşıdığını bu sayılar söylemez. Gösterdikleri şey, kullanıcının hissiyle işin sonucunun ayrı yönlere gidebildiği.

## Ölçüm

- **Kabul ile sonucun birlikte hareketi.** Her model ve ayar değişikliğinde kabul oranındaki değişimi iş sonucundaki değişimle yan yana koy. Kabul artıp sonuç yerinde sayıyorsa değişiklik başarı sayılmaz.
- **Kontrol grubuna göre fark.** Görev süresi, geri alınan değişiklik ya da yeniden açılan iş için deney grubuyla kontrol grubu arasındaki fark. Bu fark kabul oranından bağımsız olarak iyi yönde olmalı.
- **Hızlı kabul payı.** Gösterimden çok kısa süre sonra gelen kabullerin payı. Oranla birlikte yükseliyorsa artışın bir kısmı dikkatsizlikten geliyor olabilir.
- **Gösterim ve kabul sayıları.** Oranın yanında gösterilen ve kabul edilen öneri sayısı ayrı ayrı. Payda küçülerek yükselen oranı ancak böyle görürsün.
- **Algı ile ölçüm arasındaki açık.** Ankette bildirilen hızlanmayla ölçülen süre arasındaki fark. Açık büyüyorsa ekip kararlarını algıya göre veriyor.

## Ajanına ver

Üç metin var. Denetim promptu ürünündeki AI metriklerinin nerede tanımlandığını ve hangi kararları beslediğini tarar. Kabul oranının tek başına başarı ölçütü olarak kullanılıp kullanılmadığına, yanında bir iş sonucunun ve kontrol grubunun olup olmadığına bakar, yalnız rapor yazar ve hiçbir dosyayı değiştirmez. Uygulama promptu her kabul metriğine bir iş sonucu eşler, deney raporuna kontrol grubu karşılaştırmasını ve hızlı kabul payını ekler. Önce planı gösterir, onayınla uygular ve kabul oranı yükselip sonucu kötüleşen bir deneyin yayın kontrolünden geçmediğini sınayan bir test yazar. Kural kodlama ajanının kendi çalışması için. Senin ajanın da bir AI özelliğini kabul oranına bakarak başarılı ilan etmesin.

## Sınır

Kabul oranı işe yarar bir sinyal. Ziegler ve arkadaşları onu tek ve son kalite ölçütü olarak önermiyor, ama [modeldeki küçük değişiklikleri karşılaştırmak gibi pek çok iş için yararlı](https://arxiv.org/abs/2205.06537) buluyor. Bu desen oranı kaldırmaz, yanına bir sonuç koyar.

İş sonucunu ölçmek pahalı. Kontrol grubu kurmak, görev süresini tanımlamak ve geri alınan değişikliği öneriye bağlamak zaman ister. Küçük bir ekip her ayarda tam deney kurmak zorunda değil. Model ve arayüz değişikliklerinde kur, küçük ayarlarda gösterim sayısına ve hızlı kabul payına bak.

Kontrol grubunun kullanıcıya da bir bedeli var. Bir grubu yeni ayardan uzak tutmak ona bir süre daha zayıf bir ürün vermek olabilir. Süreyi kısa tut, grubu dönüşümlü kur.

Bu desen kabulün sağlığını tek başına ölçmez. Kabul edilen çıktının sonra ne kadarının kaldığını [kabulden sonraki düzeltme](/desen/kabulden-sonraki-duzeltmeyi-olc), yanlış çıktının ne sıklıkla kabul edildiğini [AI'ın haklı ve yanıldığı vakaları ayıran ölçüm](/desen/ai-hakliyken-ve-yanilirken-kabulu-ayri-olc) gösterir.

## Promptlar

### Denetim promptu

```
Bu depoda kullanıcıya öneri ya da çıktı sunan bir AI özelliği ve bu özelliğin başarısını izleyen metrikler var. Görevin, kabul oranının (ya da kabul edilen öneri sayısı, kabul edilen karakter, "AI'ın yazdığı satır" gibi kabule dayalı bir metriğin) tek başına başarı ölçütü olarak kullanılıp kullanılmadığını denetlemek. Hiçbir dosyayı değiştirme, yalnız rapor yaz.

1. AI özelliğiyle ilgili metriklerin tanımlandığı yerleri bul: analitik olayları, pano sorguları, deney (A/B) yapılandırması, yayın kontrolleri, haftalık rapor betikleri.
2. Kabule dayalı metrikleri listele. Her biri için paydayı (gösterilen öneri, tetiklenen öneri, aktif kullanıcı) ve paydanın nasıl belirlendiğini yaz.
3. Bu metriklerin yanında işin sonucunu ölçen bir metrik var mı: görev ya da talep süresi, birleştirmeden sonra geri alınan değişiklik, yeniden açılan iş, düzeltme gerektiren çıktı, müşterinin aynı soruyu yeniden sorması?
4. Model, prompt, öneri gösterme eşiği ya da arayüz değişikliği yayına çıkarken hangi metriğe bakılıyor? Rastgele bölünmüş bir kontrol grubu var mı, yoksa yalnız önce ve sonra karşılaştırması mı yapılıyor?
5. Öneri gösterme kuralını (eşik, gecikme, öneri uzunluğu, tetikleme anı) değiştiren kod nerede? Bu kural değiştiğinde kabul oranı önceki dönemle doğrudan karşılaştırılıyor mu?
6. Kabul olayında önerinin gösterilmesinden sonra geçen süre kaydediliyor mu? Okunamayacak kadar hızlı kabuller ayrı sayılıyor mu?
7. Memnuniyet anketi ya da "daha hızlı mıyım" sorusu varsa raporda iş sonucunun yerine mi kullanılıyor?

Rapor biçimi: her bulgu için dosya ve satır, hangi kararın yalnız kabule dayanarak verildiği ve bunun nasıl yanlış okunabileceği (örnek: gösterme eşiği yükseltilince payda küçülüyor ve kabul oranındaki artış kalite artışı diye raporlanıyor). Yayın kararını doğrudan besleyen metriklerden başla.

```

### Uygulama promptu

```
Bu depodaki AI özelliğinin ölçümüne "kabul oranını tek başına başarı sayma" desenini uygula. Önce planı göster, onayımı aldıktan sonra kodu değiştir.

Hedef davranış:
1. Panoda kabul oranını kullanım bölümüne taşı ve yanında gösterilen ve kabul edilen öneri sayılarını ayrı ayrı göster.
2. Her kabule dayalı metriğe bir iş sonucu eşle. Özelliğin hizmet ettiği işin sonunu tanımla (görev süresi, birleştirmeden sonra geri alma, yeniden açılan iş, düzeltme gerektiren çıktı) ve bunu ölçen olayı ekle.
3. Model, prompt, gösterme kuralı ya da arayüz değişikliğini rastgele bölünmüş bir kullanıcı grubuna aç ve iş sonucunu kontrol grubuyla karşılaştır. Rapor kabul oranındaki ve iş sonucundaki değişimi yan yana göstersin.
4. Kabul olayına önerinin gösterilmesinden sonra geçen süreyi ekle. Okunamayacak kadar hızlı kabullerin payını rapora koy. Eşiği ürünün için belirle ve tek yerde tanımla.
5. Yayın kontrolü, kabul oranı yükselse bile iş sonucu kötüleşen ya da değişmeyen bir değişikliği "başarılı" diye işaretlemesin, insan incelemesine göndersin.
6. Gösterme kuralı değiştiğinde rapor kabul oranının önceki dönemle doğrudan karşılaştırılamayacağını yazsın.

Uygularken:
- Memnuniyet anketini iş sonucunun yerine koyma, ayrı satırda raporla.
- Kontrol grubunu kısa süreli ve dönüşümlü tut. Grubun büyüklüğünü ve süresini rapora yaz.
- Mevcut kabul metriklerini silme. Kullanım sinyali olarak yeniden adlandır ve yanına sonuç metriğini ekle.
- Bir test ekle: kabul oranı yükselen ama kontrol grubuna göre görev süresi uzayan sahte bir deney sonucu ver ve yayın kontrolünün değişikliği başarılı saymadığını doğrula. Gösterilen öneri sayısının yarıya indiği bir senaryoda raporun paydayı ayrı gösterdiğini de doğrula.

```

### AGENTS.md kuralı

```
## Kabul oranını tek başına başarı sayma
- Bir AI özelliğinin başarısını kabul oranıyla, kabul sayısıyla ya da AI'ın yazdığı satırla ilan etme. Bunlar kullanım sinyali.
- Her kabul metriğinin yanına işin sonucunu ölçen bir metrik koy: süre, geri alma, yeniden açılan iş, düzeltme.
- Sonucu kontrol grubuyla ölç. Önce ve sonra karşılaştırması dönemin etkisini ayıramaz.
- Oranı raporlarken payı ve paydayı ayrı yaz. Gösterme kuralı değiştiyse oranı önceki dönemle karşılaştırma.
- Anketteki "daha hızlıyım" cevabını ölçülen sürenin yerine koyma.

```

## Kaynaklar

1. [Productivity Assessment of Neural Code Completion](https://arxiv.org/abs/2205.06537), Ziegler ve ark., GitHub (MAPS 2022, arXiv), 13 Mayıs 2022
2. [About Copilot usage metrics](https://docs.github.com/en/copilot/concepts/copilot-usage-metrics/copilot-metrics), GitHub Docs
3. [When to Show a Suggestion? Integrating Human Feedback in AI-Assisted Programming](https://arxiv.org/abs/2306.04930), Mozannar, Bansal, Fourney, Horvitz (AAAI 2024, arXiv), 2024
4. [ML-Enhanced Code Completion Improves Developer Productivity](https://research.google/blog/ml-enhanced-code-completion-improves-developer-productivity/), Google Research · Tabachnyk, Nikolov, 26 Temmuz 2022
5. [Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity](https://arxiv.org/abs/2507.09089), Becker, Rush, Barnes ve Rein, METR (arXiv), 25 Temmuz 2025
6. [We are Changing our Developer Productivity Experiment Design](https://metr.org/blog/2026-02-24-uplift-update/), METR, 24 Şubat 2026
7. [Accelerate State of DevOps Report 2024](https://dora.dev/research/2024/dora-report/2024-dora-accelerate-state-of-devops-report.pdf), DORA, Google Cloud, 2024

---

Kaynak: https://tandem.komunite.com.tr · Metin CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/deed.tr), promptlar ve kural MIT-0 (https://opensource.org/license/mit-0).