Uzun Yaşayan PR'lar, Kısa Yaşayan Mimariler: Değişikliğin Boyutu ve Ömrü

Son 12 ayda iki şey birlikte değişti: PR hacmi arttı ve onu yönetecek araçlar olgunlaştı. Harvard'dan Chen ve Stratton'ın 700'ü aşkın firmanın Jellyfish verisine dayanan Ağustos 2026 tarihli çalışmasına göre coding agent'lar PR sayısını yüzde 23, eklenen satırı yüzde 30 artırdı; çözülen Jira issue sayısında anlamlı bir değişim yok, PR'ın birleşmesine kadar geçen süre ise yüzde 49 uzadı. Faros AI'ın Nisan 2026 raporu da incelemede geçen medyan sürenin yüzde 441,5, PR boyutunun yüzde 51 arttığını gösterdi.

Araç tarafında Cursor, Aralık 2025'te stacked diffs ve AI review aracı Graphite'ı satın aldı. GitHub, Temmuz 2026'da public preview olarak açtığı stacked pull requests özelliğini 6 Ekim 2026'da genel kullanıma açtı: merge queue desteği, değişmeyen koda verilen onayları koruyan “Rebase stack” ve gh stack CLI eklentisi geldi. Thoughtworks Technology Radar'ın Nisan 2026 sayısı da coding agent'ları linter, test ve tip denetleyicisi gibi geri bildirim kontrolleriyle sınırlamayı öne çıkardı.

Bir PR açık kaldığı her gün ana dal ondan uzaklaşır. Üç gün içinde birleştirilen bir değişiklikte çatışma genellikle birkaç satırdır; üç hafta açık kalan bir dalda ise başka ekiplerin yaptığı refactor'lar, yeniden adlandırmalar ve şema değişiklikleri birikir. Çatışma çözümü sırasında yapılan hatalar en zor bulunan hatalardır, çünkü ne yazarın ne de incelemecinin dikkat ettiği yerlerde ortaya çıkar.

DORA'nın trunk-based development tanımı burada pratik bir eşik veriyor: dalların ömrü bir günü geçmemeli, ana dala günde en az bir kez entegrasyon yapılmalı ve aynı anda açık dal sayısı üç civarında kalmalı. Her ekip bu eşiğe hemen ulaşamaz, ama PR yaşını görünür kılmak ilk adım. 2026'da bu eşik daha da uzaklaştı: Chen ve Stratton'ın Harvard çalışmasında coding agent benimseyen firmalarda PR'ın birleşmesine kadar geçen süre ortalama 7 günden yaklaşık 10,5 güne çıktı. Basit bir uygulama: 72 saati geçen her PR'ı ekip kanalına otomatik düşürmek ve haftalık toplantıda yalnızca bu listeyi konuşmak.

İnceleme kalitesi PR boyutuyla ters orantılı. Google'ın mühendislik pratikleri rehberi yaklaşık 100 satırlık bir değişikliği makul, 1.000 satırlık bir değişikliği genellikle fazla büyük kabul ediyor. Pratikte gözlenen davranış da bunu doğruluyor: 50 satırlık PR'a on yorum gelirken 1.500 satırlık PR'a “LGTM” geliyor, çünkü inceleyen kişi tamamını zihninde tutamıyor.

AI destekli üretim bu sorunu büyütüyor. Faros AI'ın 2026 verisinde yüksek AI benimsemesinde PR boyutu yüzde 51 büyüdü ve hiç incelenmeden birleşen PR'lar yüzde 31,3 arttı; rapor bunu incelemecilerin hacmin gerisinde kalmasına bağlıyor. Çözüm, işi ajana verirken baştan dilimlemek: önce veri modeli ve migration, sonra servis katmanı, sonra API, en son arayüz. Her dilim ayrı PR, her PR kendi testiyle. Faros'a göre PR'ların yaklaşık dörtte biri artık bir AI agent tarafından da inceleniyor; bu iyi bir ilk filtre, ama sorumluluğu devretmez. Anti-pattern: “nasılsa AI yazdı, testler geçiyor” diyerek büyük PR'ı tek onayla birleştirmek; geçen testler incelemenin yerini tutmaz.

PR'ların uzun yaşamasının en yaygın nedeni, özelliğin “henüz bitmediği” için ana dala alınamaması. Feature flag (özellik bayrağı) bu bağı koparıyor: yarım kalan kod ana dala girer ama bayrak kapalı olduğu için kullanıcıya görünmez. Böylece birleştirme teknik bir olay, yayın ise ürün kararı haline gelir.

Next.js tarafında bu, sunucu bileşeninde bir bayrak kontrolüyle yeni rotayı ya da bileşeni koşullu göstermek kadar basit olabilir; mobilde ise uzaktan yapılandırma ile ekran bazında açıp kapatmak. Dikkat edilmesi gereken bedel bayrak borcu: her bayrak bir kod dalı ve test kombinasyonu ekler. Pratik kural, her bayrağa açılış anında bir sahibi ve bir son kullanma tarihi yazmak; 60 günü geçen bayrakları listeleyip ya kalıcı yapmak ya da silmek.

Sorunun ikinci yarısı ters yönde bir hastalığa işaret ediyor. Bazı ekiplerde mimari kararlar PR'lardan daha kısa ömürlü: bir çeyrekte mikroservis, sonraki çeyrekte modüler monolit, ardından yeni bir state yönetimi kütüphanesi. Her geçişte önceki yapı yarım kalıyor ve kod tabanında aynı problemi üç farklı şekilde çözen katmanlar birikiyor.

AI bu cazibeyi artırıyor, çünkü bir modülü yeni desene taşımak artık birkaç saatlik ajan işi gibi görünüyor. Oysa mimarinin asıl maliyeti kodda değil, ekibin zihinsel modelinde, operasyon bilgisinde ve izleme dashboard'larında. Bir mimarinin değerini görmek için genellikle en az iki üç release döngüsü boyunca onunla yaşamak gerekiyor. Sağlıklı bir soru: bu değişiklik ölçülmüş bir acıyı mı çözüyor, yoksa yeni bir şeyin heyecanını mı? Değişiklik önerisine bir ölçüm eklemek (gecikme, hata oranı, geliştirme süresi) tartışmayı zevk meselesinden çıkarır.

Mimari kararların kısa ömürlü olmasının bir nedeni, neden alındıklarının unutulması. Altı ay sonra ekibe katılan biri bir tercihi gereksiz bulup değiştiriyor, oysa o tercih yaşanmış bir olayın sonucuydu. Architecture Decision Record (ADR, mimari karar kaydı) bu hafızayı depoya taşıyor: bağlam, değerlendirilen seçenekler, karar ve sonuçları bir sayfalık markdown dosyasında.

ADR'nin AI çağında ek bir faydası var: coding agent'lar depodaki dokümanları okuyabildiği için, docs/adr klasöründeki kararlar ajanın da bağlamına girebiliyor. Bunu ajanın kendiliğinden yapacağını varsaymamak gerekiyor: ETH Zürih'in 2026'daki AGENTS.md çalışması, depo düzeyindeki bağlam dosyalarının görev başarısını genel olarak artırmadığını ve çıkarım maliyetini ortalama yüzde 20'den fazla yükselttiğini gösterdi. Kısa bir talimat dosyasından ilgili ADR'ye bağlantı vermek ve kuralı mümkünse bir linter ya da testle de denetlemek daha güvenilir. “Tüm veri erişimi repository katmanından geçer, ADR-007” gibi bir kural hem insan hem ajan için bağlayıcı hale geliyor. Bir kararı değiştirmek serbest, ama eski ADR'yi silmek yerine “yerini ADR-014 aldı” diye işaretlemek gerekiyor. Böylece mimari değişir ama gerekçe zinciri kopmaz. Şablon için Michael Nygard'ın önerdiği sade yapı yeterli; numaralandırılmış dosya adları kronolojiyi kendiliğinden korur.

Mimariyi gerçekten değiştirmek gerektiğinde uzun ömürlü bir “yeniden yazım” dalı açmak en riskli yol. Bu, yukarıdaki iki sorunu birleştirir: aylarca yaşayan bir PR ve yarım kalma ihtimali yüksek bir mimari. Martin Fowler'ın strangler fig (boğan incir) adını verdiği desen alternatif sunuyor: yeni yapı eski sistemin yanında büyür, trafik parça parça yeniye yönlendirilir, eski parçalar boşaldıkça silinir.

Somut senaryo: bir REST monolitindeki sipariş modülünü ayrı servise taşımak. Önce bir yönlendirme katmanı eklenir, yeni servis yalnızca okuma uçlarıyla canlıya çıkar, gölge trafikle sonuçlar eski sistemle karşılaştırılır, ardından yazma uçları taşınır. Her adım küçük bir PR, her adım geri alınabilir. Başarı ölçütü takvim değil, eski koddan silinen satır sayısı. Geçişin her aşamasında eski ve yeni yolun hata oranlarını aynı dashboard'da görmek, geri dönüş kararını tartışmasız hale getirir.