Geçen yılın Eylül ayında, önceki şirketimde bir cuma günü, merge bekleyen PR sayımız 47'ye ulaştı. İki kıdemli geliştiricimiz — ekipteki fiili inceleme mercileri — biri izinde, öteki kritik bir canlıya alma ile boğuşuyordu. Junior arkadaşlar kodlarını bekletiyor, bekledikçe branch'ler eskiyip conflict biriktiriyor, conflict çözümü yeni inceleme yükü doğuruyordu. Klasik kısır döngü. O gün beyaz tahtaya şunu yazdım: "Kod incelemesi ekibin en pahalı iki insanının boş vaktine emanet edilemez." Yapay zekâ destekli incelemeye geçişimiz o cümleyle başladı; bugün geldiğimiz nokta, itiraf edeyim, baştaki beklentimden hem daha iyi hem daha farklı.
İlk deneme: her şeyi okuyan, hiçbir şeyi anlamayan robot
İlk kurulumumuz naifti: her PR açıldığında bir model diff'i okusun, yorum bıraksın. İki hafta içinde ekip yorumları görmezden gelmeye başladı. Çünkü ajan diff'i görüyordu ama projeyi görmüyordu; "bu fonksiyona docstring ekleyin" tarzı jenerik tavsiyeler, bizim konvansiyonlarımızla çelişen öneriler, hatta projede zaten var olan bir helper'ı yeniden yazmayı öneren yorumlar... Gürültü, sinyali boğdu. Kod incelemesinde güven bir kez kaybedildi mi, doğru yorumlar da okunmuyor.
Dönüm noktası, incelemeyi diff'ten bağlama taşımak oldu. Ajanı MCP üzerinden üç kaynağa bağladık: kod tabanının kendisine (sadece diff değil, çağrılan her fonksiyonun gerçek tanımı), yazılı mühendislik standartlarımıza ve — bence en kıymetlisi — geçmiş inceleme yorumları arşivimize. Artık ajan "genel olarak iyi kod neye benzer" değil, "bu ekipte iyi kod neye benzer" sorusuna cevap veriyor. Aynı hatayı 2024'te bir insanın PR yorumunda düzelttiyse, ajan bugün o yorumu emsal gösteriyor.
Bağlam kaynaklarından geçmiş yorum arşivinin değerini biraz daha açayım, çünkü bu kısmı çoğu ekip atlıyor. Yıllar içinde kıdemlilerin PR'lara yazdığı binlerce yorum, aslında o ekibin yazılı olmayan anayasasıdır; hangi kestirmelerin kabul gördüğü, hangi desenlerin daha önce canlıda yangın çıkardığı orada saklı. Bu arşivi ajana açmak, yeni bir kıdemliye ekibin on yıllık hafızasını bir günde yüklemek gibi bir şey. Standart dokümanımızda hiç yazmayan ama arşivde otuz kez tekrarlanmış bir itirazı, ajan artık otuz birinci kez insan beklemeden yapıyor.
Fark dramatikti. Yorum başına "işe yaradı" oranını ölçüyoruz (geliştirici yorumu uygulamışsa ya da açıkça onaylamışsa sayılıyor); bağlamsız dönemde yüzde 20'lerde sürünen bu oran, MCP entegrasyonundan sonra yüzde 70'in üstüne çıktı.
Ajanın avlandığı bölge, insanın avlandığı bölge
Bir yılın sonunda elimizdeki iş bölümü kabaca şöyle netleşti. Ajan, insandan açık ara iyi olduğu işleri devraldı: null kontrolü unutulmuş kenar durumlar, kapatılmayan kaynaklar, yarış koşulu kokan desenler, bizim standartlardan sapmalar, N+1 sorgu tuzakları ve — bunu özellikle seviyorum — PR'ın dokunmadığı ama etkilediği dosyalar. İnsan gözü diff'te olmayanı göremez; ajan "bu fonksiyonun davranışını değiştirdiniz, şu üç modül buna dayanıyor" diyebiliyor.
İnsan incelemesi ise yukarı kata taşındı: bu değişiklik doğru problemi mi çözüyor, mimariyi doğru yönde mi esnetiyor, bu API'yi iki yıl sonra devralan kişi ne hissedecek? Kıdemlilerimiz artık satır satır virgül avcılığı yapmıyor; tasarım konuşuyor. Ve şunu net söyleyeyim: insan incelemesini kaldırmayı hiç düşünmedik. Ajan onayıyla merge edilen tek satır yok; ajan ön eleme yapıyor, nihai onay her zaman bir insanın.
Bu ayrım kâğıt üstünde zarif duruyor ama kendiliğinden oturmadı. İlk aylarda bazı arkadaşlar ajanın işaretlemediği her şeyi temiz sayma eğilimine girdi — otomasyonun en sinsi yan etkisi budur, dikkat körelmesi. Çözümümüz biraz alaycı ama etkili oldu: ajanın bilerek sessiz kaldığı PR'lar rastgele seçilip çift insan incelemesine giriyor ve bulunan her kaçak, ekip toplantısında vaka olarak konuşuluyor. Amaç ceza değil, "ajan da eksik bırakır" bilgisini taze tutmak.
Junior gelişimi: korktuğumuzun tersi çıktı
Geçiş öncesi en büyük endişem şuydu: junior'lar kıdemli yorumlarından öğrenir; incelemeyi robota verirsek çıraklık zinciri kopar. Bir yılın sonunda tablo tam tersine döndü. Eski düzende bir junior, PR'ına yorum almak için bazen üç gün bekliyordu; şimdi otuz saniyede, üstelik yargılanma hissi olmadan geri bildirim alıyor. Ajana "neden" diye sorabiliyor, aynı soruyu beşinci kez sormaktan utanmıyor. Kıdemliyle yaptığı incelemeler ise artık virgül tartışması değil, tasarım sohbeti — yani tam da çıraklığın değerli olduğu katman.
Somut bir ölçüsü de var elimde: işe yeni başlayan bir geliştiricinin ilk PR'ının merge'e kadar geçen ortalama tur sayısı (kaç kez düzeltmeye geri döndüğü) 4,2'den 1,8'e indi. Junior kodu daha mı iyi yazıyor? Hayır — kod, insana gelmeden önce iki-üç ajan turundan geçmiş oluyor. İnsanın gördüğü ilk versiyon, eskiden üçüncü turda gördüğü versiyon.
Kabullenmemiz gereken masraflar ve huysuzluklar
Pembe tablo çizmek istemem; bu sürecin faturaları da var. Ajan bağlamı ne kadar iyi görürse maliyeti o kadar artıyor — büyük bir PR'ın tam bağlamlı incelemesi hesaplı değil, bu yüzden PR boyutuna göre kademeli derinlik uyguluyoruz (ki bunun tatlı bir yan etkisi oldu: ekip PR'ları küçük tutmayı öğrendi, çünkü küçük PR daha derin ve daha hızlı inceleme alıyor). Ajanın ısrarcı olduğu ama haksız çıktığı desenler var; bunlar için bir "susturma listesi" tutuyoruz ve listeyi üç ayda bir gözden geçiriyoruz, çünkü bugün haksız olan uyarı, kod tabanı değişince haklı hâle gelebiliyor.
Kurumsal tarafta da beklemediğim bir konuşma doğdu. Güvenlik ve uyum ekipleri, kod tabanına ajan erişimini ayrı bir başlık yapmak istedi — hangi model, veri nerede işleniyor, inceleme kayıtları kimde kalıyor. Haklılar da. Artık yazılı iç politikamızda ajan destekli inceleme ayrı bir madde; hangi bağlam kaynaklarının kullanılacağı, telemetrinin nerede tutulacağı belli. Bunu angarya değil olgunluk işareti sayıyorum: sürecinize giren her aracın hesabını verebilmelisiniz, aracın zekâsı bu sorumluluğu kaldırmıyor.
Ve bir kültür meselesi: ajan yorumlarının tonunu bilerek yumuşak tutmuyoruz. Fazla kibar robot yorumu ciddiye alınmıyor; net, gerekçeli ve kaynak gösteren yorum ciddiye alınıyor. "Bunu değiştirin" değil, "bu desen X vakasında şu hataya yol açtı, emsal: PR #841" formatı, tartışmayı otoriteden kanıta taşıdı.
47 PR'lık o cuma gününden sonra kuyruk bir daha 10'un üzerini görmedi ve ortalama merge süresi üç günden yedi saate indi. Aynı düzeni şubattan beri, şu an CTO'su olduğum platformun ekibinde neredeyse aynen kuruyoruz; çünkü bu işte zor olan model değil, modelin ekibin bağlamına bağlanması — süreç tasarımı, araç seçiminden önce geliyor. Robot kod okuyor evet — ama süreci hâlâ insanlar tasarlıyor ve iyi ki öyle. Bu dönüşümü konuşmayı severim; iletişim sayfası açık.