Benchmark'a göre yapay zekâ ile üretilen pull request'ler insan incelemesi için 4,6 kat daha uzun bekliyor

Darboğaz incelemeye kaydı

DX Heroes danışmanlık firmasından Prokop Simek'in dev.to'daki yazısı, kodlama agent'larının yazılım teslimatındaki kısıtı kaydırdığını savunuyor: kod dakikalar içinde yazılıyor, ardından pull request bir kişi tarafından ele alınmayı beklerken kuyrukta bekliyor. İşaret ettiği kanıtlar oldukça somut.

4.800'den fazla organizasyondan 8,1 milyondan fazla pull request'i kapsayan LinearB'nin 2026 Software Engineering Benchmarks Report'una göre, yapay zekâ tarafından yazılan PR'ler incelemeye başlanmadan önce 4,6 kat daha uzun bekliyor; ancak biri ele aldığında yaklaşık iki kat daha hızlı inceleniyorlar. Tamamen agent'a ait PR'lerde fark daha da büyük: ele alınma süresi, desteksiz PR'lere kıyasla 5,3 kat daha uzun sürüyor.

1.255 ekibin 10.000'den fazla geliştiricisinden alınan telemetriye dayanan Faros AI'nin AI Productivity Paradox Report 2025'i ilgili bir bulgu daha ekliyor: yapay zekâ kullanımı yüksek olan ekipler %21 daha fazla görev tamamlıyor ve %98 daha fazla pull request birleştiriyor, ancak PR inceleme süresi %91 artıyor. Aynı rapor, yapay zekâ benimsenmesini ortalama PR boyutunda %154'lük bir artışla ilişkilendiriyor. GitHub ise Ekim 2025'te, kodlama agent'ının ayda yaklaşık 1,2 milyon pull request'e katkıda bulunduğunu açıkladı.

Agent PR'leri neden kayboluyor

Simek'in temel gözlemi, bir agent'ın PR'sinin kuyruğunuzda görünüp görünmediğinin platformun onu nasıl atfettiğine bağlı olduğu ve agent'ların bu konuda farklı davrandığıdır. Simek bunları üç gruba ayırıyor.

Birincisi, kendi hesabınız altında açılan PR'ler. Claude Code rutinleri commit'leri ve pull request'leri GitHub kullanıcınıza atfeder; GitLab Duo ise uyumluluk gerekçesiyle merge request'leri akışı tetikleyen kişiye atfeder. Başarısızlık modu, PR'yi aslında hiç yazmadığınız için unutmanızdır.

İkincisi, bir bot tarafından taslak olarak açılan ve sizin reviewer olarak atandığınız PR'ler. Copilot işini bitirdiğinde inceleme ister ancak kendi PR'lerini incelemeye hazır olarak işaretleyemez ve GitHub, PR'yi isteyen kişinin onu onaylamasını engeller; bu yüzden ikinci bir reviewer bulunması gerekir. Kuyruğunuz taslakları gizliyorsa bunlar tamamen görünmez olur.

Üçüncüsü, hiçbir bireye bağlı olmayan PR'ler. Varsayılan Claude Code GitHub Action'ı bir branch push eder ve PR oluşturmayı kullanıcıya bırakır; özel iş akışları claude[bot] veya github-actions[bot] olarak dosyalanır; Cursor'ın bulut agent'ları bir uygulama entegrasyonu üzerinden çalışır ve taslak PR'ler açar; Devin, bir yönetici aksini yapılandırmadıkça PR'leri kendi kimliği altında açar. Hiçbir kişisel filtre bunları yakalamaz.

Boşlukları kapatan dört kayıtlı görünüm

Tek bir filtre üç grubun tamamını kapsamadığı için yazı, her biri tek bir soruyu yanıtlayan dört kayıtlı görünüm öneriyor. GitHub'da bunlar 9 Temmuz 2026'dan beri genel kullanıma açık olan yeni pull request panelinde yer alabilir; GitLab'in Reviewer, Author ve Label filtreleriyle merge request listesi aynı işi görür.

Birincisi, taslakları da içeren bir review-requested filtresi; çünkü bulut agent'ları PR hâlâ taslakken inceleme ister. İkincisi, adınıza dosyalayan agent'ları yakalayan ve 18 Haziran 2026'dan beri Copilot'un talimatınızla açtığı PR'leri de kapsayan authored-by-me görünümü. Üçüncüsü, agent PR'lerini etikete göre hedefler: bulut agent'ları copilot/, claude/, codex/, cursor/ ve devin/ gibi tanınabilir öneklerle branch push eder ve GitHub'ın labeler action'ı bu önekleri temel alarak bir agent etiketi uygulayabilir; yerel agent'lara ise CLAUDE.md gibi dosyalarla agent/ öneki kullanmaları söylenebilir. Dördüncüsü, organizasyon genelinde takılmış her şeyi gösteren bir yönetici görünümüdür: başarısız CI, istenen değişiklikler veya birkaç iş günü boyunca hiç etkinlik olmaması; dependency-bot PR'leri hariç tutulur.

Sadece filtreler değil, alışkanlıklar

Simek kuyrukları çalışma alışkanlıklarıyla eşleştiriyor: bir sonraki görevi atamadan önce son agent PR'sini inceleyin, günde iki sabit inceleme penceresi tutun, birleştirme süresi yerine ilk yanıt süresi için bir ekip hedefi belirleyin, bildirimleri yalnızca inceleme istekleri, değişiklik istekleri ve CI hatalarıyla sınırlayın ve agent görevlerini küçük tutun ki ortaya çıkan PR'ler bir inceleme penceresine sığsın.

Ayrıca GitHub ve GitLab hesapları için bu kuyrukları widget olarak gösteren, MIT lisanslı ücretsiz bir macOS menü çubuğu uygulaması olan Gitwall'ı da geliştirdi. Yazı kısmen bu aracın tanıtımı olsa da, kuyruk kurulumunun kendisi kayıtlı aramalardan fazlasını gerektirmiyor.

Neden önemli

Yapay zekâ destekli geliştirmede artık sınırlayıcı adım üretim değil; insanın incelemeyi ele alması. Ekipler agent başarısını çıktı hacmiyle ölçerken, inceleme gecikmesinin ve PR boyutunun aynı anda büyüdüğünü ve kazanımları sessizce aşındırdığını gözden kaçırabilir. Buradaki çareler örgütseldir, modelle ilgili değil: tutarlı atıf, agent işini gerçekten görünür kılan kuyruklar, açık bir ilk yanıt beklentisi ve daha küçük devredilen görevler. Agent'lar giderek daha fazla PR dosyaladıkça, inceleme kapasitesi ekiplerin bilinçli olarak yönetmesi gereken kaynak haline geliyor.