Kodu yapay zekâ yazıyorsa kim okuyor? Claude Code ekibinin katmanlı inceleme düzeni

Sorun: Kod çoğaldı, göz çoğalmadı

Anthropic’in Claude Code ekibi 15 Ekim’de kod incelemesini nasıl yaptığını anlatan uzun bir yazı yayımladı. Başlangıç noktası çarpıcı: Claude Code’un kendi kodunun yaklaşık %90’ını Claude yazıyor. Şirketin ana kod deposunda günde birleşen değişiklik sayısı Mayıs’ta 2.500 civarındayken Eylül’de 30.000’i geçmiş.

Bu hızda her satırı bir insanın okuması mümkün değil. Ekip de soruyu değiştirmiş: “Bu kodu bir insan okudu mu?” yerine “Bu değişiklikte ne ters gidebilir ve bunu hangi kontrol yakalamalı?” Hedef, PR’ların çoğunun en fazla bir insanla (bu kişi yazarın kendisi olabilir) birleşmesi. Şart da net: Geri alınan değişiklik ve olay (incident) sayısı artmayacak. Artarsa insan zamanı kazanılmamış, sadece başka yere kaymış demektir.

Tek kapı değil, katmanlar

Her değişiklik birkaç elekten geçiyor. Her biri bazı hataları yakalıyor, bazılarını kaçırıyor:

• PR açılmadan önce doğrulama. Claude’a çalıştırabileceği bir şey veriliyor (test, build, tasarımla karşılaştırılacak ekran görüntüsü) ve “bitti” demek yerine çıktıyı göstermesi isteniyor. Sonra temiz bağlamlı bir alt ajan diff’i ayrıca inceliyor.
• Her PR’a yapay zekâ incelemesi. Birkaç ajan paralel olarak hata arıyor, başka bir grup her bulguyu oyluyor. Yeterince ajan “bu gerçek” demezse bulgu yayımlanmıyor. Her bulgu ya düzeltiliyor ya da gerekçe yazılarak kapatılıyor.
• Engelleyici güvenlik incelemesi. Açık bir güvenlik ya da hata bulgusu varken PR birleşemiyor.
• Klasik CI. Lint, tip kontrolü, her platformda testler.
• Riske göre insan onayı. Belge düzeltmesi ya da bayrak arkasındaki ek bir özellik için insan onayı gerekmiyor. Sıradan ürün değişikliğine bir, en riskli kod yollarına iki kişi bakıyor. Seviyeyi yazar değil, değişikliği okuyan bir sınıflandırıcı seçiyor. Bir ajanın onayı hiçbir zaman insan onayı yerine sayılmıyor.
• Merge queue, özellik bayrakları, kademeli yayın ve hızlı geri alma. Bir şey kaçarsa bayrak deploy gerektirmeden kapatılıyor.

İki dosya burada önemli rol oynuyor. CLAUDE.md projenin ne olduğunu, kurallarını ve hedeflerini anlatıyor; kısa tutuluyor. REVIEW.md ise kodun sahiplerinin “bizim bölümde hata neye benzer?” sorusuna cevabı. Aynı yorum incelemede sürekli tekrar ediyorsa, çözüm bu dosyalara, bir lint kuralına ya da bir beceriye (skill) taşınıyor.

50 turluk döngü

Yazının en öğretici kısmı bir hata hikâyesi. Ajan yazar ile ajan inceleyici birbirini sonsuza kadar meşgul edebiliyor: Bir PR, yazarı durdurana kadar bir gecede 50’den fazla inceleme-düzeltme turu geçirmiş. Ekip git blame ile bakınca, inceleyicinin işaretlediği kodun yaklaşık %59’unun ilk turdan beri orada olduğunu görmüş. Yani her turda yeni hata değil, birkaç eski hata daha bulunuyormuş.

Çözüm basit kurallar: Üç turdan sonra inceleyici yazara yaklaşımı yeniden düşünmesini söylüyor, sonraki turlarda sadece yeni diff inceleniyor, bulgular tek satır yerine hata türü olarak bildiriliyor ve aynı bulgu iki kez yazılmıyor. İnceleyici de geçmiş olaylardan oluşturulan bir test setine karşı her gün ölçülüyor.

İnsan ne yapıyor?

İnsanlar her diff’i okumaktan, makinelerin kötü olduğu kararlara geçmiş: Bunu yapmalı mıyız, ödeme ya da otomatik güncelleme gibi riskli kod, başkalarının kopyalayacağı mimari kararlar ve test kanıtını okumak. Kural da şu: “Sen birleştirdiysen, sen sahiplenirsin.” Bozulursa genelde sen düzeltirsin; amaç suçlamak değil, en çok bağlamın sende olması. Aynı hızın kaynak kontrolünü nasıl zorladığını Anthropic’in Scion yazısında anlattık.

Dikkat edilecek noktalar

Better Stack videosu iki uyarı ekliyor. Birincisi, %40’lık düşüş bir oran. PR sayısı aynı dönemde iki katına çıktığı için toplam geri alma sayısı videonun hesabına göre yine de yaklaşık %20 artmış olabilir. İkincisi, maliyet. Code Review hizmetinin sabit bir fiyatı yok, token kullanımına göre ücretleniyor; videoya göre ortalama bir inceleme 15–25 dolar tutuyor. Anthropic’in token bütçesi herkesin bütçesi değil.

Yine de bedava kopyalanabilecek kısımlar var: Kısa bir CLAUDE.md, bir REVIEW.md, tur sınırı, riske göre onay ve “bot onayı insan onayının yerini tutmaz” kuralı. İncelemenin çoğunu kuralların yaptığı bir alternatif için Open Code Review yazımıza, ajanın büyük değişikliklerini anlamak için Whiteboard yazımıza bakabilirsin. Güveni satır satır okumak yerine testler ve üretimdeki gözlemle kurma fikrini Charity Majors yazısında anlattık.

Düşün

• Senin projende hangi değişiklik hiçbir insan bakmadan birleşebilir, hangisi asla?
• İnceleme turlarının “yakınsadığını” nasıl ölçerdin?

Kendi cümlelerimizle yazılmış bir özettir, çeviri değildir. Tüm kaynaklar yukarıda.