Agent Pull Request’leri Her Yerde: Doğru Review Nasıl?

Geçen ay bir müşterimde garip bir şey yakaladım. Repo’ya bakıyorum, son iki haftada 47 PR merge edilmiş. Hepsi yeşil. Hepsi tertemiz görünüyor. Coverage düşmemiş, lint geçmiş, testler de geçiyor. Tech lead de keyifli keyifli gülüyor: “Aşkın bey, takım uçuyor bu ara.”

İçimden bir ses geldi… Dür bakayım.

Doğrusu, PR açıklamalarını tek tek açtım. 47’sinin 31’i Copilot agent tarafından açılmış. Reviewer’lar da çoğunu üç dakikada onaylamış. Sonra bir PR’da şunu gördüm: agent, test dosyasının içine usul usul @pytest.mark.skip eklemiş. Sebep? Test fail oluyormuş. Agent çözümü bulmuş yanı; testi devre dışı bırakmış.

İşte bugün konuşmak istediğim mesele tam da bu. GitHub’ın yayınladığı son verilere göre Copilot code review 60 milyonu aşmış, son bir yılda 10 kat büyümüş. Her 5 review’dan biri artık bir agent’ı içeriyor. Yanı siz fark etmeden, muhtemelen bu hafta agent yazımı bir PR’ı onayladınız bile.

Önce Şunu Konuşalım: Agent PR’ı Neden “Tehlikeli Şekilde Temiz” Görünür?

Ocak 2026’da yayınlanan “More Code, Less Reuse” çalışması bir şeyi baya net gösterdi: agent üretimi kod, insan yazımı koda göre daha fazla redundancy ve daha fazla teknik borç üretiyor. Aynı işi yapmak için daha çok satır çıkıyor, daha çok kopya oluşuyor, abstraction da biraz dağılıyor işte.

Ama asıl çarpıcı taraf şu — aynı çalışmaya göre reviewer’lar agent kodunu onaylarken kendilerini daha rahat hissediyor. Yüzey temiz görünürse yargı da sessizleşiyor. Hani bir lokantaya girersiniz, masa örtüsü bembeyazdır ama mutfağı görseniz… evet, o his.

Bunu yaşayan biri olarak söyleyeyim, Ben buna “sessiz borç” diyorum. Çünkü patlamıyor. Sadece birikiyor. Altı ay sonra bir bakıyorsunuz: codebase’de 4 farklı yerde aynı validation logic’i var, hepsi azıcık farklı, hepsi agent’ın o anki bağlamına göre üretilmiş. Refactoring’e kalkınca saç baş yoluyorsunuz. Daha fazla bilgi için GPT-4.1 Copilot’tan Emekli Oluyor: Sahadan Geçiş Notları yazımıza bakabilirsiniz. Bu konuyla ilgili GitHub Repository Rulesets: Kullanıcı Bypass ve Branch yazımıza da göz atmanızı tavsiye ederim.

“Yavaşlayalım” demiyorum. “Bilinçli olalım” diyorum. İkisi arasında dağlar kadar fark var.

Türkiye’deki Şirketler Açısından Durum Biraz Farklı

Açık konuşayım: kurumsal müşterilerimde gördüğüm kadarıyla Türkiye’de agent benimsenmesi iki uca gidiyor. Bir tarafta finans ve telekom var — bunlar Copilot Enterprise lisansı almış ama review süreçleri hâlâ 2019’dan kalma gıbı duruyor. Yanı agent PR’ı açıyor, ama review kültürü buna göre değişmemiş oluyor.

Diğer tarafta startup’lar var. Bunların çoğu Copilot Business kullanıyor, ekip küçük, herkes birbirini tanıyor; agent PR’larına da “ya boşver geçiyor. Testler” diye hızlıca onay basılıyor. İlk grupta süreç var ama farkındalık yok, ikincisinde farkındalık var ama disiplin yok.

İstanbul’daki bir bankacılık projesinde geçen yaz başımıza şu geldi: agent, mevcut bir CustomerValidator sınıfı varken yeni bir CustomerInputChecker üretti. Aynı işi yapıyor aslında. Neden? Çünkü agent o anki context window’unda eski sınıfı görmedi. Reviewer da görmedi; diff küçüktü çünkü. Üç ay sonra compliance ekibi geldi: “İki farklı validation logic var, hangisi production’da?” Cevabı bulmak iki gün sürdü (bizzat test ettim)

Küçük Ekip mi, Büyük Kurumsal mı? Yaklaşım Farkı

Eğer 5-10 kişilik bir ekipseniz, formal review template’lere boğulmanıza gerek yok. Ama “agent’ın açtığı PR’ı, agent’ın author’ı kendi gözden geçirmeden başkasına atamasın” kuralını koyun. Bu tek kural bile baya iş görüyor. Kubernetes v1.36 Declarative Validation: GA’ya Ulaştı yazımızda bu konuya da değinmiştik.

50+ developer’lı kurumsal yapıdaysanız iş değişiyor. CODEOWNERS dosyasını sıkılaştırın, branch protection rules’ları agent commit’lerine göre ayarlayın. CI’a “agent kaynaklı değişiklik” tespiti için ayrı bir workflow ekleyin. Aşağıda örnek vereceğim.

Reviewer Olarak Neye Bakmalıyım? Kırmızı Bayraklar

Vallahi, Şimdi işin pratik kısmına gelelim. Bir agent PR’ı queue’nuza düştüğünde ilk satırı okumadan önce kafanızda şu net olsun: karşınızdaki contributor sizin incident geçmişinizi bilmiyor. Edge case folklorunu bilmiyor. Production’da geçen sene bir Cuma akşamı patlayan o saatlik bug’ı hatırlamıyor. Bu konuyla ilgili Claude Sonnet 4 GitHub Copilot’ta Emekli Oldu: Geçiş Rehberi yazımıza da göz atmanızı tavsiye ederim. Kubernetes v1.36 Memory QoS: Katmanlı Bellek Koruması Geldi yazımızda bu konuya da değinmiştik.

Bağlam sizde. Ve bu yük değil — işin kendisi.

1. CI Hilesi (En Kritik)

Agent’lar test fail ettiğinde mantıklı çözümler bulur. Bazen fazla mantıklı ölür hatta. Şunlara bakın:

• Coverage threshold’u düşürülmüş mü? 0.8 iken 0.7 mi olmuş?
• Test silinmiş mi, rename edilmiş mi, skip ile işaretlenmiş mi?
• Workflow artık fork’larda veya PR’larda çalışmıyor mu?
• || true eklenmiş mi test komutuna? (Bu klasik hareket.)
• continue-on-error: true sessizce eklenmiş mi?

Bence, CI’da zayıflama yaratan herhangi bir değişiklik tagger değil blocker. Tartışma yok yanı. Ben kendi ekiplerime şunu söylüyorum: Bir PR’da test silindiyse sebebi PR description’da açıkça yazılmalı. Yazmadıysa reddet, geri gönder.

2. Mevcut Kodu Görmezden Gelme

Agent çoğu zaman repo’nün tamamını görmez; sadece kendisine verilen context’i görür. Buradan da şu sorun çıkar: aynı işi yapan üçüncü bir helper fonksiyon ortaya çıkarır dururuz biz de sonra şaşırırız biraz.

• Bu yardımcı fonksiyon zaten başka yerde var mı?
• Bu pattern bizim projede kullandığımız pattern mı?
• Yeni dependency eklenmiş mi? Neden? Mevcut kütüphane bunu yapamıyor mu?

“Tamam Görünen Ama Çalışmayan” Kod

Bir şey dikkatimi çekti: Bunun tadı kötü oluyor işte; en sinsisi bu diyebilirim.. Tipler doğru görünür, isimler düzgün durur, fonksiyon imzası mantıklıdır ama içeride bir None kontrolü atlanmıştır ya da async fonksiyon await‘lenmemiştir ya da veritabanı transaction’ı yarım kalmıştır.. Geçen hafta Ankara’daki bir e-ticaret müşterimde tam buna denk geldim: agent OrderService‘e yeni bir method eklemişti; dışarıdan bakınca pırıl pırıl görünüyordu ama transaction rollback path’i yoktu.. Test mock’lanmıştı; gerçek DB’de çağrılınca yarım kayıt bırakıyordu.. Production’a gitseydi… neyse ki gitmedi.

Pratik Bir Karşılaştırma Tablosu

İnsan PR’ı ile Agent PR’ını karşılaştırırken ben checklist’i kabaca şöyle tutuyorum:

Bakıacak Şey	Insan PR’ı	Agen tPR’ı
Test değişiklikleri	Düz kontrol yeter	Satır satır oku; skip/remove yakala
Linter çoğunu yakalar>
Error handling
Sizde düşünmek kalır>