Üç AI kod inceleme botunu 315 PR'da ölçtük

Bir kod inceleme botunu denemek kolay: kurarsın, iki PR'da ne yazdığına bakarsın, "fena değil" dersin. Ölçmek zordur, çünkü botun bulduğu şeyin gerçekten hata olup olmadığını ancak sen bilirsin, ve bulmadığı şeyin var olup olmadığını hiç bilmezsin. 30 Ağustos'ta repomuza üçüncü botu ekledik ve o günden itibaren üç bot aynı pull request'leri, aynı anda, aynı koşullarda inceledi. 35 gün sonra elimizde bot etkinliği olan 315 PR, 1.070 satır içi bulgu ve tek bir soru vardı: hangisi kritik hatayı buluyor?

Kısa cevap: mutlak sayıda CodeRabbit, bulgu başına isabette Seer. Ama bu cevap ölçümün ilk yarısında doğruydu, ikinci yarısında değil. On yedinci günden sonra CodeRabbit'in inceleme kapasitesi daraldı, PR'ların yarısına bakamaz oldu ve o dönemde Seer kritik bulguda onu geçti. Sourcery'nin düşük hacminin sebebi ise kötü bakması değil, PR'ların yarısından fazlasına hiç bakmaması. Uzun cevap aşağıda, ölçümün bizi iki kez yanılttığı yerler dahil.

Bu yazının ilk sürümü ilk 18 günün verisiyle Medium'da yayımlandı. Burada aynı yöntemle 35 güne genişletildi; ilk sürümdeki sayılar bu yüzden buradakilerden farklı.

Ortam

Ölçülen repo, Next.js ve PostgreSQL üzerinde çalışan çok kiracılı bir operasyon platformu: müşteri paneli, faturalama, kart ve bakiye ödemeleri, alan adı ve sunucu siparişleri, muhasebe entegrasyonu, bir de sunucuları yöneten bir yapay zeka ajanı. Yani buradaki hataların bir kısmının birimi para, bir kısmının birimi kiracı sınırı. Bir botun "kritik" dediği şeyin gerçekten kritik olup olmadığını bu bağlamda değerlendirdik.

Pencere içinde bot etkinliği olan 315 PR açıldı ve 293 commit ana dala girdi. Medyan PR 533 satır değişiklik taşıyor (ortalama 5.238, çünkü birkaç dev PR var), medyan PR açılıştan merge'e 86 dakikada gidiyor. PR'lar tek bir geliştirici ve bir yapay zeka kodlama ajanı tarafından yazıldı; botların yanında bir de iç inceleme zinciri var (görev başına ajan incelemesi ve merge öncesi bütün dal incelemesi). Botlar bu zincirin yerine değil, yanına konumlanmış durumda.

Üç bot: CodeRabbit (30 Ağustos'ta eklendi, pencerenin başlangıcı bu tarih), Sentry'nin Seer'i (PR inceleme özelliği) ve Sourcery. Üçü de her PR'da otomatik koşuyor. Kotalar ve inceleme limitleri plan kademesine göre değişiyor; aşağıda verdiğimiz limitler bizim planımızda gördüklerimiz.

Yöntem

Veri GitHub API'den geldi: her PR'ın satır içi yorumları, inceleme turları ve PR yorumları, ayrıca her PR'ın son commit'indeki check-run'lar. Botları kullanıcı adından ayırdık ve her yorumu botun kendi işaretleyicisiyle sınıflandırdık.

Bulgu dediğimiz şey, botun satır içi bıraktığı ve kendi işaretiyle bulgu olduğunu söylediği yorum. CodeRabbit her bulguya bir sınıf ve önem başlığı koyuyor ("Functional Correctness | Major" gibi) ve gövdeye gizli bir işaret ekliyor. Sourcery her yorumu issue (bug_risk), issue (security), suggestion gibi etiketliyor. Seer her bulguyu Bug: ile açıp Severity: HIGH gibi bir seviye veriyor. Özet gövdelerindeki toplu listeler sayılmadı; CodeRabbit'in özetlerinde ayrıca 66 nitpick ve 78 "diff dışı" kalem var, onlar bu sayının dışında.

Düzeltildi dediğimiz şey botun kendi damgası. Üç bot da düzeltme içeren bir push gelince kendi yorumunu işaretliyor: CodeRabbit "Addressed in commits", Seer "Resolved in", Sourcery "Addressed in". Biz elle işaretlemedik. Bu yüzden düzeltme sayıları alt sınır: başka bir PR'da kapanan ya da botun eşleştiremediği düzeltmeler sayılmıyor.

Baktı dediğimiz şey, botun o PR'ı gerçekten incelemiş olması. Bir botun PR'da görünmesi yetmiyor; kota ya da limit notu bırakıp geçtiyse o PR'a bakmamış sayılıyor. Seer temiz koşuda PR'a yorum bırakmadığı için onun baktığı PR'ları check-run'lardan okuduk.

Kritik için botların ölçekleri uyuşmuyor: CodeRabbit'in en üst seviyesi neredeyse hiç kullanılmıyor, Seer'in CRITICAL'i başka bir şey, Sourcery'nin önem ölçeği yok. Bu yüzden ikinci bir ölçüm yaptık: para ve kimlik yollarındaki (faturalama, ödeme, muhasebe, kimlik doğrulama, yetki) düzeltilmiş bulguları tek tek okuduk ve kendi tanımımızla saydık. Bizim tanımımızda kritik: yanlış hareket eden para, kiracı sınırının aşılması, rıza ve hukuki kayıt, veri kaybı, kesinti. Bu sayım öznel; o yüzden yaklaşık veriyoruz.

Sınırlar açık: tek repo, tek ekip, 35 gün, botların kendi damgası, bizim kritik okumamız. Bu bir benchmark değil, bir saha ölçümü.

Ölçümün kapsamı dışında kalanlar da var. Aynı PR'larda Semgrep, GitGuardian ve Dependabot da koşuyor, ama onlar bu karşılaştırmaya girmedi, çünkü başka bir soruya cevap veriyorlar. Üç bot "bu değişiklik yanlış mı?" diye soruyor ve niyet okuyarak cevap veriyor; Semgrep bilinen bir kötü kalıbı, GitGuardian bir sırrı, Dependabot bilinen açıklı bir bağımlılığı arıyor. Onlar kural tabanlı ve deterministik, çıktıları pass/fail bir kapı; sessizlikleri kural setlerinin kapsamında gerçekten temiz demek. "Bulgu sayısı", "düzeltildi damgası" ya da turdan tura değişen sonuç gibi ölçüler onlara uymuyor. İki sınıf rakip değil, katman: CodeRabbit'in "critical" etiketli bulgularından biri, test dosyasına gömülmüş bir özel anahtarın Semgrep kapısını düşürdüğünü söylüyordu; tarayıcının bulgusunu bağlamıyla taşıdı.

Sayılar

35 günün tamamı:

Önem dağılımı, parantez içinde botun düzeltildi damgası:

CodeRabbit kendi sınıflandırmasında bulgularının 223'ünü işlevsel doğruluk, 159'unu veri bütünlüğü, 123'ünü güvenlik ve gizlilik, 75'ini kararlılık, 49'unu bakım kolaylığı, 6'sını performans olarak etiketledi.

Reddettiğimiz bulgu sayısına dikkat: üçünde de düşük, ama aynı değil. Seer'in 235 bulgusunun 12'sini thread'de ölçerek geçersiz bulduk (yüzde 5), CodeRabbit'in 635 bulgusunun 7'sini (yüzde 1), Sourcery'nin 200 bulgusunun 1'ini. Seer'in reddedilenlerinin 8'i ikinci döneme düşüyor, birini aşağıda anlatıyoruz.

İki dönem: bir plan limiti sıralamayı nasıl değiştirdi

Ölçümü ilk 18 günün sonunda yazmıştık. Sonraki 17 günde tablo değişti, ve değişimin sebebi botların zekâsı değil, kapasitesiydi.

PR temposu iki dönemde aynıydı: günde dokuz civarı. Değişen CodeRabbit'in kapasitesiydi. İlk günlerde limit mesajı "8 dahil inceleme hakkının hepsini kullandın" diyor ve iki ila dört dakika sonra yeniden açılıyordu; altı PR'da görüldü, beşinde inceleme kısa süre sonra devam etti. 17 Eylül'den sonra mesajdaki hak sayısı ikiye, dörde düştü ve bekleme 24 ila 51 dakikaya çıktı. İkinci dönemde 143 PR'ın 103'üne "Review limit reached" notu düştü ve CodeRabbit PR'ların yarısından fazlasına (74) hiç bakmadı. Not kendiliğinden yeniden denemiyor; kapasite açıldığında elle tetiklemek gerekiyor, ve @coderabbitai review o commit'i "zaten incelendi" sayıp hiçbir şey yapmıyor, @coderabbitai full review gerekiyor. Her push de kapasiteden yiyor; bizim gibi bir PR'a bot bulguları yüzünden üç dört tur push yapan bir ekipte hak hızla tükeniyor.

Sonuç: ilk dönemde kritik bulguda yaklaşık iki kat önde olan bot, ikinci dönemde Seer'in gerisine düştü. Kodun kalitesi ya da botun yeteneği değişmedi; PR'ların yarısı incelenmeden geçti. Aynı dönemde medyan merge süresi 59 dakikadan 250 dakikaya çıktı. Bunun bir kısmı her merge'den önce yeniden rebase edip CI'ı yeniden koşturma kuralımızdan, bir kısmı inceleme kapasitesini beklemekten geliyor; ikisini ayıramıyoruz. CodeRabbit limitin ötesi için dosya başına 0,25 dolarlık kullanım bazlı faturalama öneriyor; biz açmadık.

İkinci dönemde Seer'in isabeti de düştü. Merge edilen PR'larda düzeltildi oranı yüzde 81'den yüzde 69'a indi ve thread'de açıkça reddettiğimiz bulgu sayısı 4'ten 8'e çıktı. Reddedilenlerden biri CRITICAL etiketliydi: bir Zod şemasının CPU ve bellek verisinde zorunlu alanlar istediğini, ayrıştırmanın hep düşeceğini söylüyordu. Şemada o alanlar .nullish() idi; sağlayıcının o gün döndürdüğü gerçek veriyle ölçtük, ayrıştırma geçiyordu. Bir diğeri next/dynamic'in doğrudan bileşen kabul etmediğini söylüyordu; Next'in kendi yükleyicisi iki biçimi de açıkça işliyor. Seer'in seviye etiketi ilk dönemde güvenilir bir sinyaldi; ikinci dönemde bir HIGH'ı okumadan düzeltmeye girişmek boşa iş olurdu. Sourcery ise iki dönemde de aynı davrandı: bütçesi olduğu PR'larda isabetli, ikinci dönemde merge edilen PR'larda düzeltildi oranı yüzde 80, ama 131 PR'ın 85'ine bütçeden bakamadı.

Ders: ilk 18 günün sıralaması bir ölçümdü, bir özellik değil. Bir inceleme botunun değeri, yeteneği çarpı baktığı PR oranı; ikinci çarpan plan kademesine ve kendi push alışkanlığına bağlı, ve sessizce değişiyor.

Kritik hatayı kim buldu

Para ve kimlik yollarındaki düzeltilmiş bulguları iki dönem için de tek tek okuduk:

• CodeRabbit: yaklaşık 31 kritik (ilk dönem 25, ikinci dönem 6).
• Seer: yaklaşık 19 kritik (12 ve 7).
• Sourcery: yaklaşık 13 kritik (10 ve 3); bunların bir kısmı para ve kimlik yolunun dışındaki güvenlik bulguları (kiracılar arası hafıza sızması, kabuk ayracı).

Yani 35 günün toplamında mutlak sayıda CodeRabbit önde. Yoğunlukta Seer önde: bulgu başına kritik oranı en yüksek, düzeltildi oranı yüzde 75. Sourcery baktığı yerde bulgu başına isabette Seer'in hemen arkasında; sorunu kapsam. Ve yukarıdaki tablo bu sıralamanın sabit olmadığını gösteriyor.

Vakalar sayıdan daha iyi anlatıyor. Hepsi düzeltildi, hiçbiri üretimde patlamadı.

Kart çekildi, kayıt yok. Kayıtlı kartla ödeme akışında kart sağlayıcıdan çekiliyor, sonra ödeme satırı veritabanına yazılıyor. Yazım düşerse finally bloğu çekim kilidini serbest bırakıyordu ve geriye ne kayıt ne yeniden deneme yolu kalıyordu: müşteriden para alınmış, sistemde izi yok. Seer bunu CRITICAL olarak işaretledi. Aynı dosyada CodeRabbit başka bir şey buldu: süresi dolmuş bir kilit tutamacı, kendisinden sonra alınmış yeni kilidi serbest bırakabiliyordu. İki bot aynı modülde iki farklı deliği gördü.

Aynı hizmet iki kez faturalandı. Yönetilen sözleşmesi olan bir müşteri kendi kendini faturalayan bir hizmet de aldığında, sözleşme yenileme cron'unun o hizmetin kalemini dışlaması gerekiyor. Yeni bir hizmet tipi eklenirken dışlama sorgusu güncellenmemişti; Seer bunu sözleşme yenileme rotasında yakaladı. Bu, "kardeşi unutuldu" sınıfından bir hata: düzeltme bir yere uygulanmış, aynı kuralı taşıyan ikinci yer atlanmış.

Rıza yokluğu onay sayıldı. Reklam dönüşümü gönderen kodda pazarlama rızası false değilse gönderim yapılıyordu. null, yani hiç karar verilmemiş durum, bu koşuldan geçiyordu. Seer bunu HIGH olarak işaretledi; bizim için hukuki bir kayıt olduğu için kritik. İkinci dönemde aynı sınıftan bir tane daha geldi: sipariş rotası işlemin dilini aktarmadığı için İngilizce onay metnini kabul eden müşterinin rızası Türkçe dil damgasıyla kaydediliyordu. Bunu üç bot da ayrı ayrı buldu.

Onay ekranı liste fiyatı gösterdi, indirimli tutar çekildi. Alan adı siparişinde indirim uygulandıktan sonra tahsilat indirimli tutardan yapılıyor, ama müşteriye dönen pricing nesnesi indirimden önce hesaplanmış değerleri taşıyordu. Onay ekranında gösterilen tutar ile çekilen tutar arasında yüzde doksan dokuza varan bir ayrışma ölçtük. CodeRabbit bunu ilk turunda, Major etiketiyle buldu.

İade edilmiş fatura, ödenmiş dönem açtı. Ödeme alındığında askıdaki hizmetleri açan yolda, kurumsal e-posta ve trafik yönetimi hizmetleri için bekleyen faturanın durumu okunuyor, hizmet sonra ayrı bir yazımla güncelleniyordu. İki adım arasında o fatura iade edilirse, hizmet yine de açılıyor ve iade edilmiş bir fatura için ödenmiş dönem kaydediliyordu. CodeRabbit bunu iki hizmette de buldu ve okuma ile yazımın aynı kilitli transaction'da olmasını istedi; Sourcery aynı dosyada bekleyen yenileme işaretçisinin başka bir yarışını ayrıca gösterdi.

Plan dokümanı üretimde migration koşturuyordu. Bir uygulama planında "doğrulama için drizzle:migrate koş" adımı vardı; aynı dokümanın üst kısmı bu makinenin veritabanı bağlantısının üretim olduğunu söylüyordu. CodeRabbit iki paragrafı yan yana koyup Major verdi. Bu bir kod hatası değil, ama koşulsaydı kod hatasından pahalıya patlayacak bir talimat.

Kalkanın deliği. Kimlik satırlarının (2FA sırrı taşıyan kullanıcı tabloları) istemciye sızmasını engelleyen bir tarama testimiz var. Sourcery testin regex'inin yalnız boşlukla ayrılmış .select().from(users) kalıbını yakaladığını, araya giren bir yorumun ya da şema takma adının taramayı atlattığını gösterdi. Kalkan vardı, ama kalkanın etrafından dolaşılabiliyordu.

Kiracılar arası hafıza sızması, fail-open. Sunucuları yöneten ajanın hafıza katmanında, firmanın sunucu envanterini okuyan sorgu düşerse boş liste dönüyordu ve süzgeç boş listeyi "kapsam yok" diye okuyup başka sunucuların hafızasını da bu sunucunun görevine enjekte ediyordu. Sourcery'nin issue (security) sınıfından, düzeltildi. Aynı sınıftan bir başkası: uzaktan kabukta koşan curl komutunun URL grameri & kabul ediyordu; kabukta & komut ayracıdır.

Commit gövdelerinde kimin bulgusunu kapattığımızı yazıyoruz. 293 commit'in 90'ı CodeRabbit'e, 60'ı Seer'e, 42'si Sourcery'ye atıf taşıyor.

Sessizlik üç botta üç ayrı şey demek

Bu ölçümün en çok işimize yarayan bulgusu bir hata sayısı değil, bir davranış farkı oldu.

Seer temizken yorum bırakmıyor. Seer 315 PR'ın 194'ünde hiç görünmedi. Check-run'lara bakınca 179'unda "No issues found" yazıyordu, 15'inde hiç koşmamıştı. O 179 temiz PR'ın 54'ünde CodeRabbit'in, 36'sında Sourcery'nin düzeltildi damgalı bulgusu var. Seer'in "temiz" demesi PR'ın temiz olduğu anlamına gelmiyor; o turda bir şey bulamadığı anlamına geliyor. Aynı commit'te ikinci kez tetiklenince yeni bulgu getirdiğini birden fazla kez gördük; reklam dönüşümü PR'ında dört Seer turunun ikisi bulgu taşıdı, ikisi boştu.

Sourcery 166 PR'a hiç bakmadı. Sourcery'nin inceleme yorumlarının büyük kısmı şu cümleydi: "this account has used its review budget of 2,500,000 diff characters for the last 7 days." Birkaç PR da tek PR boyut limitine takıldı (500.000 diff karakteri). Yani 302 PR'da görünen Sourcery gerçekte 136 PR'ı inceledi. Baktığı 136 PR'ın 31'inde bulgu vermedi; o 31'in 5'inde CodeRabbit, 5'inde Seer düzeltildi damgalı bulgu bulmuştu. Sourcery'nin gerçek zayıflığı isabet değil, kapsam. Bütçe kayan yedi günlük pencere olduğu için büyük PR'lar sonraki günlerin incelemesini de yiyor.

CodeRabbit'in sessizliği iki türlü. Baktığı 233 PR'ın 57'sinde bulgu bırakmadı; o 57'nin 12'sinde Seer, 8'inde Sourcery bulgu vermişti. Bu, üçü arasındaki en güvenilir sessizlik. Ama 78 PR'da sessizliğin sebebi temizlik değil, kapasiteydi: limit notu, taslak PR ya da ana dala açılmamış PR. Not PR'da görünür ama kolay gözden kaçar, ve bir PR'ın incelenmiş gibi görünüp incelenmemiş olması en pahalı sessizlik.

Tek başına bulgu veren PR sayısı bu tabloyu özetliyor: CodeRabbit 44, Sourcery 20, Seer 16. CodeRabbit ile Seer birlikte kapsamın büyük kısmını taşıyor; ama CodeRabbit'in kapasitesi daraldığında Sourcery'nin ve Seer'in tek başına bulduğu PR'lar arttı.

Ölçümün kendi hatası. İlk okumamızda "Sourcery bu pencerede kota yemedi" yazdık. Sınıflandırıcımız "rate limit" dizesini arıyordu, Sourcery "review budget" diyordu. Aynı gün ikinci hata: Sourcery'nin güvenlik bulguları 🚨 issue (security) diye başlıyordu ve emoji regex'i geçiremedi, bulgular sayılmadı. Bot yokluğunu ölçerken botun kendi ret cümlesini ara, bulgu sayarken botun bugünkü biçimini oku; ikisini de biz yanlış yaptık ve düzelttik. Bu yazıdaki sayılar düzeltilmiş hâli.

Karakter portreleri

Seer: para burnu. En iyi olduğu yer durum makineleri: kısmi başarı, yeniden deneme, idempotensi, iki para biriminin yanlışlıkla toplanması. Muhasebe entegrasyonundaki bölünmüş ödeme mantığında art arda üç HIGH bulgu verdi ve üçü de gerçekti. Diff'te olmayan, mevcut bir hatayı da buldu; bunu açıkça söylüyoruz çünkü bazı botlar yalnız değişen satırlara bakar. Zayıf yanları: yavaş kuyruk (p90 74 dakika, bizim merge medyanımıza yakın), temizken susması, aynı commit'te turdan tura farklı sonuç vermesi, ve ikinci dönemde görünür biçimde artan yanlış pozitif. Test dosyalarına neredeyse bakmıyor; düzeltildi damgalı 176 bulgusunun yalnız ikisi bir testte.

CodeRabbit: hacim ve genişlik. Diff dışına bakıyor (78 "diff dışı" kalem), doküman, plan ve runbook dosyalarını okuyor (düzeltildi damgalı 386 bulgusunun 101'i docs ve scripts altında), ve iddiasını repo üzerinde betik koşturarak doğruluyor; birçok yorumun altında "Supported by static analysis" bloğu ve koştuğu rg komutları var. Güvenlik bulgularına CWE etiketi koyuyor. Yanlış pozitifi üçü arasında en az olan bot. Bedeli okunacak hacim, ve kapasite: hacmi ancak baktığı PR'da üretebiliyor. Bir de etiket uyarısı: Minor etiketi bazen para taşıyor. Muhasebe API'sinden yalnız ilk sayfayı okuyup sonraki sayfadaki açık faturayı görmeyen kod ve iki paralel --execute sürecinin aynı farkı iki kez uygulaması Minor ile Major arasında dolaştı. Etiketi değil, gövdeyi oku.

Sourcery: kalkanın kalkanı. Regresyon ve tarama testlerinin kaçak deliklerini ve yutulan hataları (catch(() => {}), boş catch bloğu, alarmı hiç doğurmayan cron) bulmakta en iyisi. issue (security) sınıfı gerçek bulgular taşıyor: kiracılar arası hafıza sızması, kabuk ayracı, denetlenmeyen bir IDOR denemesi. 35 günde thread'de reddettiğimiz tek bir bulgusu var. Reviewer's Guide'ı saniyeler içinde geliyor ve PR'ı okumaya başlamak için iyi bir harita. Bedeli bütçe.

Ne öder, ne alırsın

Üç bota ödediğimiz aylık ücret: CodeRabbit 60 dolar, Sentry 79 dolar, Sourcery 30 dolar; toplam 169 dolar. Sentry'nin ücreti hata izleme platformunun tamamını kapsıyor, Seer incelemesi bunun bir parçası; bu yüzden Seer'in bulgu başına maliyeti bir üst sınır. Plan kademesi ve koltuk sayısı fiyatı değiştirir; burada kendi faturamızı yazıyoruz. 35 günlük pencere 1,15 ay; ücretleri buna göre böldük.

Bulgu başına ve kritik başına en ucuz hâlâ CodeRabbit, ama ilk 18 günde kritik başına 1,44 dolardı; kapasite daralınca aynı ücret daha az PR satın aldı. Sourcery PR başına en ucuz görünüyor ama 30 dolar 302 PR'ın 136'sını satın aldı; bütçe dolunca eksilen para değil, bakış. Daha fazla kapsam üst plan ya da kullanım bazlı faturalama demek; ikisi için de karar, botun bulduğu bir hatanın bize kaça mal olacağıyla verilmeli. Seer'in kritik başına 4,78 doları, Sentry faturasının geri kalanını sıfır saymak; gerçek payına bölünse daha düşük.

Üçü birlikte: 35 günde 195 dolar, yaklaşık 63 kritik bulgu, kritik başına yaklaşık 3,1 dolar. Kaydedilmemiş bir kart çekiminin ya da iki kez kesilen bir faturanın maliyeti bunun katları.

Ne yapıyoruz

Beş kural çıkardık.

1. İki bot zorunlu. CodeRabbit ve Seer birlikte kapsamın büyük kısmını taşıyor. Sourcery bütçesi varken üçüncü göz.
2. Kapasiteyi bir metrik olarak izle. Bir botun kaç PR'a gerçekten baktığını haftalık say. Limit notu düşmüş PR'ı merge'e hazır sayma; kapasite açılınca full review ile tetikle, gelmezse bunu bilerek merge et.
3. Para ve kimlik PR'ında Seer'i bir kez daha tetikle. Check-run temiz dese bile. İkinci tur, ilk turun görmediğini görüyor. Ama HIGH ve CRITICAL'i de ölçmeden düzeltme.
4. Sessizliği temiz sayma. Üç botta üç ayrı anlam: bütçe ya da limit reddi, temiz koşu, hiç koşmamış. Ayrımı yalnız check-run ve botun kendi mesajı yapıyor.
5. Bot, inceleme zincirinin yerine geçmiyor. İç zincirimizin bulduğu ve üç botun da kaçırdığı hatalar oldu; botların bulduğu ve iç zincirin kaçırdığı hatalar da. İkisi de gerekli, ikisi de tek başına yetmiyor.

Bir de merge disiplini: pencerede hiçbir bulgu merge'den sonra gelmedi, çünkü botları bekliyoruz. Bu, Seer'in p90'ı göz önüne alındığında bazen bir saatten fazla demek. Bir saatlik bekleme, kaydedilmemiş bir kart çekiminden ucuz.

Kendi reponda tekrarla

Ölçüm birkaç yüz satırlık betik ve GitHub API'den ibaret.

1. Pencereyi seç: ilk botun ilk yorumundan bugüne. Haftalarca sürüyorsa dönemlere böl; tek bir ortalama, bizim gördüğümüz kırılmayı saklar.
2. Her PR için pulls/{n}/comments (satır içi), pulls/{n}/reviews, issues/{n}/comments ve son commit'in commits/{sha}/check-runs uçlarını çek.
3. Yorumları botun kullanıcı adına göre ayır. Bulguyu botun kendi işaretiyle tanı: CodeRabbit'te gövdedeki cr-indicator-types işareti ve önem başlığı, Sourcery'de **issue (...)** etiketi (emoji önekine izin ver), Seer'de Bug: ve Severity:.
4. Düzeltmeyi botun damgasından oku; kendin işaretleme. Henüz merge edilmemiş PR'ları düzeltme oranından ayrı tut.
5. Botun yokluğunu botun kendi ret cümlesiyle ara: "review budget", "Review limit reached", "Draft PR not reviewed", check-run'da "No issues found".
6. PR meta verisiyle birleştir: satır değişikliği, açılış ve merge zamanı. Bulgu/1000 satır ve gecikme buradan çıkar.
7. Önem karşılaştırması için botların ölçeğine güvenme; kendi kritik tanımını yaz ve bulguları oku.

En çok işine yarayacak sayı muhtemelen bizde olduğu gibi kapsam asimetrisi olacak: hangi bot hangi PR'a hiç bakmadı. O sayıyı görmeden "bu bot az buluyor" demek, ölçümü botun yerine yapmak. Ve o sayı zamanla değişiyor; bir kere ölçüp bırakmak, ilk 18 günümüzün sıralamasını kalıcı sanmak olur.