# TD-009 · Kabulden sonraki düzeltmeyi ölç

Kabul oranı yükseliyor, kabul edilen önerinin büyük kısmı ise sonradan elle düzeltiliyor ve bu panoya hiç ulaşmıyor. Desen kabul edilen çıktıyı iş bitene kadar izler ve kalanını kabul oranının yanında raporlar.

- Adres: https://tandem.komunite.com.tr/desen/kabulden-sonraki-duzeltmeyi-olc
- Yer: Zamanla > Ölçüm
- Seviye: Temel. Her AI özelliğinde olmalı.
- Son inceleme: 28 Ekim 2026, Komünite editörlüğü

## 30 saniyede dene

1. Ürünündeki AI önerisinin metne girdiği bir yere git ve bir öneriyi kabul et. Sonra yarısını sil, kalanını kendi cümlenle yeniden yaz.
2. Ürününün ölçüm kaydına ya da panosuna bak. Bu öneri nasıl sayıldı, kabul edilmiş bir öneri olarak mı, düzeltilmiş bir öneri olarak mı?
3. Kabul edilen metnin gönderilen e-postada, birleştirilen kodda ya da kaydedilen belgede ne kadarının kaldığını söyleyen bir sayı ara.
4. Bulamıyorsan son haftada kabul ettiğin on öneriyi elle izle. Kaçı işin sonuna değişmeden ulaştı? Sayı panodaki kabul oranından çok düşükse bu desen ürününde eksik.

## Sorun

Bir e-posta uygulamasının yazım asistanı cümlenin devamını öneriyor. Kullanıcı Tab'a basıyor ve öneri metne giriyor. Ürünün panosu bunu bir kabul olarak sayıyor, kabul edilen karakterleri asistanın katkısına ekliyor. İki dakika sonra kullanıcı önerinin yarısını siliyor, tarihi düzeltiyor, kapanış cümlesini baştan yazıyor. Bu kısım panoya hiç ulaşmıyor.

Ekip haftalık raporda kabul oranının yükseldiğini görüyor ve modelin iyileştiğine karar veriyor. Kullanıcı için aynı hafta başka türlü geçti. Öneriler daha uzun geldi, kabul etmek tek tuştu, düzeltmek dakikalar sürdü. Asistanın katkısı diye sayılan metnin önemli bir kısmı gönderilen e-postada yoktu.

Kabul anında kullanıcı yalnız bu metinle devam etmeye karar veriyor. Önerinin işe yarayıp yaramadığı sonra belli oluyor, e-posta gönderildiğinde, kod birleştirildiğinde, belge kapandığında. Kabulde duran ölçüm, kullanıcının sonradan sildiği metni de AI'ın katkısı diye sayar.

## Neden atlanıyor

Kabul, AI özelliğinin kendi ekranında olan tek olay. Öneri gösterilir, kullanıcı tuşa basar, kod bir satır günlük yazar. Kabulden sonrası başka yerde olur: düzenleyicide, belgede, gönderilen e-postada, birleştirilen değişiklikte. Orada bir öneriyi izlemek, metne giren her parçaya kimlik vermeyi ve sonraki düzenlemeleri o parçaya bağlamayı ister. Ekipler ucuz olayı sayar ve orada durur.

İkinci neden, kalıcılığı ölçen ekibin bulduğu şey. GitHub'ın araştırma ekibi Copilot'ta kabul edilen tamamlamanın kodda değişmeden ya da küçük bir düzeltmeyle kalıp kalmadığını kabulden sonra farklı sürelerde izledi. Geliştiricilerin verimlilik algısını bu kalıcılık ölçülerinden daha iyi açıklayan sinyal [kabul oranı çıktı](https://arxiv.org/abs/2205.06537). Bu bulgu kabul oranını savunan ekibin elinde güçlü bir gerekçe olur. Oysa algı, kabul edilen kodun ne kadarının kodda kaldığını söylemez.

Üçüncü neden, düzeltmenin sessiz olması. Kullanıcı önerinin yarısını sildiğinde ne bir düğmeye basar ne bir şikâyet yazar. Modelin de bundan haberi olmaz. Bir sonraki öneri aynı uzunlukta, aynı kalıpla gelir. Düzeltmeyi kimse kaydetmediği için ne pano ne model ondan bir şey öğrenir.

## Desen

Kabul ölçümün başladığı yerdir. Kabul edilen çıktıyı iş bitene kadar izle ve kalanını say.

1. **Kabul edilen parçaya kimlik ver.** Öneri metne girdiği anda yerleştiği aralığı, uzunluğunu, hangi modelden ve hangi prompt sürümünden geldiğini kaydet. Sonraki her düzenlemeyi bu kimliğe bağla. Kimliği olmayan parça kullanıcının yazdığı metne karışıp kaybolur.
2. **Birden çok anda bak.** Parçayı kabulden kısa bir süre sonra, birkaç dakika sonra ve iş bittiğinde yeniden oku: e-posta gönderildiğinde, değişiklik birleştirildiğinde, belge paylaşıldığında. İlk an kaza kabulünü, son an gerçek katkıyı gösterir. GitHub'ın ekibi de tek bir süreye bağlanmadı, [birkaç süreyi yan yana ölçtü](https://arxiv.org/abs/2205.06537).
3. **Düzeltmeyi derecesine göre ayır.** Değişmeden kalanı, küçük düzeltileni, büyük ölçüde yeniden yazılanı ve silineni ayrı say. Birkaç düzeltme isteyen uzun bir öneri yine de katkı olabilir. Küçük düzeltmenin sınırını düzenleme mesafesiyle koy ve yaz.
4. **Geri almayı ayrı say.** Kabulün hemen ardından gelen geri alma tuşu, ilk dakikada silinen paragraf ve birleştirmeden sonra geri çevrilen değişiklik farklı şeyler söyler. Biri tuş kazasını, öteki fark edilen hatayı, sonuncusu kullanıcının kaçırdığı hatayı gösterir.
5. **Kalan payı kabul oranının yanına koy.** Panoda kabul oranının hemen yanında iş bittiğinde değişmeden ya da küçük düzeltmeyle kalan pay durur. İki sayı ters yöne gidiyorsa model, prompt ya da arayüz değişikliğini yayına almadan incele.

Kullanıcı yine istediği gibi düzeltir. Düzeltme artık panoda görünür ve ekip neyin yeniden yazıldığını örnekleriyle okur.

## Önce ve sonra

Aynı model değişikliği, iki haftalık rapor. Soldaki rapor kabul anında duruyor ve kabul oranının yükselmesini başarı sayıyor. Sağdaki kabul edilen metni gönderilen e-postaya kadar izliyor, kabul artarken kalan payın düştüğünü ve en çok neyin yeniden yazıldığını gösteriyor.

Örnek ekran (kurgusal): E-posta uygulamasının yazım asistanı yeni bir modele geçti. Ekip ilk haftanın raporuna bakıp modeli bütün kullanıcılara açıp açmayacağına karar veriyor.

### Önce: Yazım asistanı · haftalık rapor

- Bilgi: Hafta 43 · yeni model · cümle tamamlama
- Adım (tamam): Kabul oranı yükseldi · %41 → %52
- Adım (tamam): Asistanın yazdığı metin arttı · kabul edilen karakter: 1,4 milyon → 1,9 milyon
- AI: Yeni model daha çok kabul alıyor. Asistanın katkısı bir haftada belirgin biçimde arttı.
- Düğmeler: Herkese aç

1. Rapor kabul anında duruyor. Kabul edilen metnin e-posta gönderilene kadar ne olduğunu bilmiyor.
2. Kullanıcılar yeni modelin uzun önerilerini kabul edip yarısını siliyor. Silinen metin de asistanın katkısı diye sayılıyor.

### Sonra: Yazım asistanı · haftalık rapor

- Bilgi: Hafta 43 · yeni model · cümle tamamlama
- Adım (tamam): Kabul oranı yükseldi · %41 → %52
- Adım (hata): Gönderilen e-postada kalan pay düştü · değişmeden ya da küçük düzeltmeyle kalan: %63 → %38
- Adım (hata): Kabulden sonra silinen öneri arttı · ilk iki dakikada silinen: %8 → %22
- İçerik (En çok yeniden yazılanlar): Tarih ve tutar içeren cümleler · kapanış cümleleri · özür kalıpları
- AI: Yeni model daha uzun öneriler getiriyor. Kullanıcılar ilk yarısını tutup kalanını siliyor. Öneriyi cümle sonunda kesip bir hafta daha ölçeyim mi?
- Düğmeler: Kısa öneriyle yeniden ölç · Örnekleri aç

1. Rapor kabul edilen metni gönderilen e-postaya kadar izliyor. Değişmeden kalan, küçük düzeltilen ve silinen ayrı sayılıyor.
2. Kabul oranı yükselirken kalan pay düştü. Ekip modeli herkese açmadan önce en çok neyin yeniden yazıldığını görüyor.

## Piyasada

GitHub'ın Copilot metrikleri eklenen satırı [kabul edilen tamamlamalardan, uygulanan kod bloklarından ve ajan düzenlemelerinden](https://docs.github.com/en/copilot/reference/copilot-usage-metrics/copilot-usage-metrics) sayıyor. Silinen satır alanı ise şimdilik yalnız ajan düzenlemelerinden besleniyor. Kullanıcının kabul ettiği bir satırı sonradan silmesi bu alanlarda ayrı bir iz bırakmıyor. Şirketin kendi araştırma ekibi kalıcılığı ölçtü, ama yöneticinin gördüğü pano kabulde duruyor.

Google iç kod asistanının katkısını kabul edilen karakterlerle ölçüyor. 2024 yazısında AI desteğiyle yazılan kodun payı, [AI önerilerinden kabul edilen karakterlerin, elle yazılan ve kabul edilen karakterlerin toplamına oranı](https://research.google/blog/ai-in-software-engineering-at-google-progress-and-the-path-ahead/) diye tanımlanıyor. Aynı yazı modeli kabuller, retler ve düzeltmeler içeren kullanım günlükleriyle ayarladıklarını da söylüyor. Düzeltme eğitime giriyor, katkı ölçüsüne girmiyor.

Meta'nın CodeCompose makalesi aynı yöntemi kullanıyor. Kabul edilen her önerinin uzunluğunu kaydedip geliştiricilerin yazdığı kodun [karakter düzeyinde ne kadarının kabul edilen önerilerden geldiğini](https://arxiv.org/abs/2305.12050) hesaplıyor. Makalede kabul edilen kodun sonra ne kadarının kaldığına bakan bir ölçü geçmiyor.

## Kanıt

GitHub'ın 2022 çalışması kalıcılığı neden ölçtüğünü açık yazdı: kabul edilip sonra yanlış çıkan bir tamamlama geliştiricinin zamanını iki kez harcar, önce incelerken, sonra [geri dönüp silerken](https://arxiv.org/abs/2205.06537).

METR'ın 2025 deneyi kabulden sonrasını geliştiricilerin ağzından anlatıyor. Deneyimli açık kaynak geliştiricileri AI'ın ürettiği kodu kabul ettikten sonra da onu kendi standartlarına getirmek için uzun süre okuyup düzelttiklerini söyledi. Geliştiricilerin [%56'sı AI kodunu temizlemek için sık sık büyük değişiklik yapması gerektiğini, sorulduğunda hepsi AI kodunu değiştirmek zorunda kaldığını](https://arxiv.org/abs/2507.09089) bildirdi. Ekran kayıtlarında AI'ın serbest olduğu işlerde zamanın [yaklaşık %9'u AI çıktısını incelemeye ve temizlemeye](https://arxiv.org/abs/2507.09089) gitti.

Mozannar ve arkadaşlarının Copilot oturumlarını inceleyen çalışması bu düzeltmenin nereden geldiğini gösteriyor. Programcılar öneriyi bazen [hemen kabul edip incelemeyi sonraya bırakıyor](https://arxiv.org/abs/2210.14306). Yazarlar buna doğrulama borcu diyor. Kabul anında ölçülen katkı bu borcu görmez. Borç, kullanıcı geri dönüp düzelttiğinde ödenir ve o an hiçbir panoda yoktur.

Bu çalışmaların hepsi kod üzerinde yapıldı. METR'ın düzeltme verisi geliştiricilerin kendi beyanına ve sınırlı sayıda ekran kaydına dayanıyor. Yazım asistanında, e-postada ya da belgede kalan payı kendi ürününde ölçmen gerekiyor.

## Ölçüm

- **Kalan pay.** Kabul edilen metnin iş bittiğinde (gönderim, birleştirme, kayıt) değişmeden ya da küçük düzeltmeyle kalan payı. Kabul oranıyla birlikte izle. Model ve arayüz değişikliğinde düşmemeli.
- **Erken silme.** Kabulden sonraki ilk dakikalarda silinen ya da geri alınan önerilerin payı. Yükseliyorsa kullanıcılar okumadan kabul ediyor ya da kabul tuşu yazmayla çakışıyor.
- **Yeniden yazma derecesi.** Kalan parçalarda ortalama düzenleme mesafesi. Küçük düzeltmeden büyük yeniden yazmaya kayış, önerinin taslak olarak da işe yaramadığını gösterir.
- **Sonradan geri çevrilen.** Birleştirildikten ya da gönderildikten sonra geri alınan, düzeltme e-postası gerektiren işler. Bu sayı kullanıcının kaçırdığı hataları gösterir.
- **Düzeltmenin yeri.** En çok yeniden yazılan cümle türleri: tarih, tutar, ad, kapanış. Model ekibinin somut iş listesi bu dağılımdan çıkar.

## Ajanına ver

Üç metin var. Denetim promptu ürünündeki AI önerilerinin nasıl kaydedildiğini tarar. Kabulden sonra önerinin izlenip izlenmediğine, düzenlemenin ve silmenin öneriye bağlanıp bağlanmadığına ve panoda kalan payın görünüp görünmediğine bakar, yalnız rapor yazar ve hiçbir dosyayı değiştirmez. Uygulama promptu kabul edilen parçaya kimlik verir, birkaç ölçüm anı ekler, düzeltmeyi derecesine göre sınıflar ve panoya kalan payı koyar. Önce planı gösterir, onayınla uygular ve kabul edilip yarısı silinen bir önerinin kalan paydan düştüğünü sınayan bir test ekler. Kural kodlama ajanının kendi çalışması için. Senin ajanın da bir AI özelliğinin başarısını raporlarken kabulde durmasın.

## Sınır

Düzeltilen her öneri başarısız sayılmaz. GitHub'ın ekibi bunu kendisi yazdı: üzerinde oynanacak işe yarar bir taslak, [yalnız birkaç tuşu kurtaran bariz ve doğru bir satır kadar, hatta ondan daha değerli olabilir](https://arxiv.org/abs/2205.06537). Kalan payı tek hedef yapan ekip kısa ve bariz önerilere kayabilir. Kalan payı kabul oranının ve işin sonucunun yanında oku. Kabul oranının neden tek başına yetmediği [ayrı bir desen](/desen/kabul-oranini-tek-basina-basari-sayma).

İzlemenin gizlilik bedeli var. Kabul edilen metni gönderime kadar izlemek kullanıcının yazdığını saklamayı gerektirebilir. Metnin kendisini saklama. Aralığı, uzunluğu ve düzenleme mesafesini kaydet. Örnek okumak gerekiyorsa kullanıcının iznini al ve erişimi sınırla.

Bitiş anı ürüne göre değişir. Kod için birleştirme, e-posta için gönderim, belge için paylaşım doğal bir bitiş. Sohbetten kopyalanıp başka bir uygulamaya yapıştırılan cevapta böyle bir an yok. Orada kalan payı ölçmeye çalışma, yalnız kopyalamayı ve hemen ardından gelen yeniden üretmeyi say.

Bu desen düzeltmeyi görünür kılar. Düzeltmeyi modele ve ürüne geri bildirim olarak taşımak [başka bir desenin işi](/desen/geri-bildirimi-isin-icinden-topla).

## Promptlar

### Denetim promptu

```
Bu depoda kullanıcıya öneri ya da taslak üreten bir AI özelliği var (satır içi tamamlama, yazım önerisi, sohbetten metne ekleme, ajanın önerdiği kod değişikliği). Görevin, kabul edilen AI çıktısının kabulden sonra ne olduğunun ölçülüp ölçülmediğini denetlemek. Hiçbir dosyayı değiştirme, yalnız rapor yaz.

1. Kabul olayının kaydedildiği yerleri bul: analitik ve telemetri çağrıları ("accept", "accepted", "insert", "apply" gibi olay adları), panoya ya da veri ambarına giden alanlar.
2. Kabul kaydında öneriye bir kimlik veriliyor mu? Önerinin metne yerleştiği aralık (belge ya da dosya kimliği, başlangıç ve bitiş), uzunluğu, model ve prompt sürümü kaydediliyor mu?
3. Kabulden sonraki düzenlemeler bu kimliğe bağlanıyor mu? Kabul edilen aralığın sonradan değişip değişmediğine ya da silinip silinmediğine bakan bir kod var mı? Varsa hangi anlarda bakıyor: birkaç saniye, birkaç dakika, kayıt, gönderim, birleştirme?
4. Geri alma (undo), kabulden hemen sonra silme ve birleştirmeden ya da gönderimden sonra geri çevirme (revert) ayrı olaylar olarak kaydediliyor mu?
5. Düzenlemenin derecesi ölçülüyor mu: değişmeden kalan, küçük düzeltilen, büyük ölçüde yeniden yazılan, silinen? Düzenleme mesafesi ya da benzeri bir eşik var mı, nerede tanımlı?
6. Panolar ve raporlar neyi gösteriyor? Kabul oranının ve "AI'ın yazdığı satır" ya da "kabul edilen karakter" sayısının yanında kalıcılığı gösteren bir sayı var mı? Kabul edilip sonra silinen metin hâlâ AI katkısı diye sayılıyor mu?
7. Model, prompt ya da arayüz değişikliği yayına çıkarken hangi metriğe bakılıyor? Kabul oranı yükselirken kalıcılık düşerse bunu yakalayan bir kontrol var mı?
8. İzleme kullanıcının yazdığı metni mi saklıyor, yoksa yalnız aralık, uzunluk ve mesafe gibi meta veriyi mi?

Rapor biçimi: her bulgu için dosya ve satır, neyin ölçüldüğü, neyin ölçülmediği ve bunun panoda nasıl yanlış okunabileceği (örnek: kabul edilip iki dakika sonra silinen öneri "AI'ın yazdığı satır" sayısına ekleniyor). Model ve arayüz kararlarını besleyen metriklerden başla.

```

### Uygulama promptu

```
Bu depodaki AI önerilerine "kabulden sonraki düzeltmeyi ölç" desenini uygula. Önce planı göster, onayımı aldıktan sonra kodu değiştir.

Hedef davranış:
1. Kabul edilen her öneriye bir kimlik ver. Kabul anında önerinin yerleştiği aralığı (belge ya da dosya kimliği, başlangıç ve bitiş), uzunluğunu, model ve prompt sürümünü kaydet.
2. Kabul edilen aralığı birkaç anda yeniden oku: kabulden kısa bir süre sonra, birkaç dakika sonra ve iş bittiğinde (kayıt, gönderim, birleştirme). Her anda aralığın ne kadarının kaldığını hesapla.
3. Sonucu dört sınıfa ayır: değişmeden kalan, küçük düzeltilen, büyük ölçüde yeniden yazılan, silinen. Sınırı düzenleme mesafesiyle koy (örnek: özgün uzunluğun üçte birinden az değişiklik küçük düzeltmedir) ve eşiği tek yerde tanımla.
4. Kabulden hemen sonraki geri almayı, ilk dakikalardaki silmeyi ve birleştirmeden ya da gönderimden sonraki geri çevirmeyi ayrı olay olarak kaydet.
5. Panoda kabul oranının yanına iş bittiğinde kalan payı ekle. "Kabul edilen karakter" ya da "AI'ın yazdığı satır" sayısını kalıcılıkla birlikte göster. Model, prompt ya da arayüz değişikliğinin raporunda iki sayıyı önceki sürümle karşılaştır.

Uygularken:
- Kullanıcının metnini saklama. Aralığı, uzunluğu, mesafeyi ve sınıfı kaydet. Örnek incelemesi gerekirse ayrı izin ve sınırlı erişimle yap.
- Kabul edilen aralığın içine kullanıcının sonradan yazdığı metni AI çıktısı sayma, ayrıca say.
- Ölçüm kullanıcının akışını yavaşlatmasın. Yeniden okumayı arka planda ve toplu yap.
- Bir test ekle: bir öneriyi kabul et, ardından yarısını sil ve kalanını değiştir. Kaydın bu öneriyi "büyük ölçüde yeniden yazıldı" diye sınıfladığını ve panodaki kalıcılık payının düştüğünü doğrula. Kabulden hemen sonra geri alınan bir önerinin "geri alındı" diye ayrı sayıldığını da doğrula.

```

### AGENTS.md kuralı

```
## Kabulden sonrasını ölç
- Bir AI özelliğinin başarısını raporlarken kabul oranında durma. Kabul edilen çıktının iş bittiğinde ne kadarının kaldığını da raporla.
- Kabul edilen parçaya kimlik ver, sonraki düzenlemeleri o kimliğe bağla.
- Değişmeden kalanı, küçük düzeltileni, yeniden yazılanı ve silineni ayrı say. Eşiği yaz.
- Kabul edilip sonra silinen metni AI katkısı diye sayma.
- Kullanıcının metnini saklamadan ölç: aralık, uzunluk ve düzenleme mesafesi yeter.

```

## 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. [Data available in Copilot usage metrics](https://docs.github.com/en/copilot/reference/copilot-usage-metrics/copilot-usage-metrics), GitHub Docs
3. [AI in software engineering at Google: Progress and the path ahead](https://research.google/blog/ai-in-software-engineering-at-google-progress-and-the-path-ahead/), Google Research · Chandra, Tabachnyk, 6 Haziran 2024
4. [AI-assisted Code Authoring at Scale: Fine-tuning, deploying, and mixed methods evaluation](https://arxiv.org/abs/2305.12050), Murali vd., Meta (FSE 2024, arXiv), Temmuz 2024
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. [Reading Between the Lines: Modeling User Behavior and Costs in AI-Assisted Programming](https://arxiv.org/abs/2210.14306), Mozannar, Bansal, Fourney, Horvitz (CHI 2024, arXiv), 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).