Claude Code ekibinden kod inceleme ve sahiplik dersleri

Kod yazmak ucuzladı, okumak ucuzlamadı

Yapay zekâ kod asistanlarını yaygınlaştıran ekiplerde tanıdık bir tablo oluşuyor: PR sayısı artıyor, ama ürüne çıkan iş aynı hızla artmıyor. Faros AI'ın AI Productivity Paradox raporu, yüksek benimsemeli ekiplerdeki geliştiricilerin %21 daha fazla görev tamamladığını ve %98 daha fazla PR birleştirdiğini, buna karşılık PR inceleme süresinin %91 uzadığını gösteriyor; şirket düzeyine çıkıldığında yapay zekâ kullanımıyla temel performans metrikleri arasındaki bağ kayboluyor. Fiona Chen ve James Stratton'ın 718 şirketi kapsayan Harvard çalışma makalesi henüz hakem denetiminden geçmedi, ama bulgusu aynı yönde: kod ajanları devreye girince mühendisler yaklaşık %30 daha fazla kod ekledi, tamamlanan iş ölçülebilir biçimde artmadı ve kodu incelemeden geçirmek %49 daha uzun sürdü.

Sahadaki ruh hali de farklı değil: QA.tech'in aktardığına göre GOTO Copenhagen'daki canlı ankette 440 katılımcının yarısı en büyük sürtünme noktası olarak değişiklikleri incelemeyi gösterirken, Sonar'ın Ocak 2026 anketinde geliştiricilerin %38'i yapay zekâ kodunu incelemenin bir meslektaşın kodunu incelemekten daha zahmetli olduğunu söylemiş. Darboğaz klavyeden kalktı, inceleme ekranına taşındı. Bu yazının ana fikri de buradan çıkıyor: satırları kim yazmış olursa olsun, PR'ı açan kişi değişikliğin sahibidir. Claude Code ekibinin paylaştığı model, bu cümleyi süreç ve araçlarla nasıl ayakta tuttuğunu gösteriyor.

Claude Code ekibi kendi rakamlarıyla ne anlatıyor

Anthropic'in Claude Code ekibi, kod incelemesini nasıl yaptığını anlattığı yazıda bu soruna içeriden bakıyor. daily.dev'deki özete göre Claude Code'un kendi kod tabanının kabaca %90'ını Claude yazıyor. Yani yapay zekânın ürettiği kodu incelemek bu ekip için bir gelecek senaryosu değil, günlük iş rutini.

Paylaşılan sonuçlar dikkat çekici. Claude Code'a birleştirilen PR sayısı Haziran ile Eylül arasında iki katından fazla artarken geri alınan PR oranı %40'tan fazla düşmüş. Anthropic'in daha geniş monorepo'sunda günlük değişiklik sayısı Mayıs'taki yaklaşık 2.500'den Eylül'de 30.000'in üzerine çıkmış.

Bu rakamları okurken iki şeyi akılda tutmak gerekiyor. Birincisi, veriyi paylaşan şirket aynı zamanda bu yaklaşımı ürün olarak satıyor ve elimizde bağımsız bir doğrulama yok. İkincisi, Anthropic'in araç, işlem gücü ve mühendislik kapasitesi çoğu şirketin erişemeyeceği düzeyde. Bence yazının asıl değeri rakamlarda değil, kurulan yapının mantığında; o mantık ölçekten bağımsız olarak başka ekiplere uyarlanabiliyor.

İnceleme tek bir kapı değil, üst üste katmanlar

Ekibin yaptığı en önemli şey incelemeyi bırakmamak, ama okuma yükünü tek bir insanın sırtına da yüklememek. Yazıda altı kontrol katmanı ve hepsinin altında hızlı geri alma (rollback) yer alıyor. Bir şeklin altındaki not yaklaşımı iyi özetliyor: her katman bazı sorunları yakalar, bazılarını kaçırır. Kimse tek bir katmanın kusursuz olmasını beklemiyor.

Ayrıntılar öğretici. PR açılmadan önce Claude testleri, derlemeyi ve linter'ı çalıştırıyor, ardından ikinci bir ajan farkı (diff) gözden geçiriyor. Birleştirme kuyruğu, kontrolleri değişikliğin uygulandığı en güncel main üzerinde yeniden koşturuyor. Sonra değişiklik bir bayrak arkasında önce Anthropic çalışanlarının iç kullanımına açılıyor, ardından 'latest' kanalına, en son da 'stable' kanalına gidiyor.

Kaynak, bu düzenin insan incelemecinin işini nasıl değiştirdiğini ayrıca ölçmüyor. Benim yorumum şu: katmanlar mekanik kontrolleri makineye bıraktığında, kıdemli bir mühendisin sınırlı dikkatini tasarım, risk ve ürün davranışı sorularına ayırma imkânı doğuyor. Kıdemli mühendisin saatini en pahalı kaynak olarak gören her ekip için bu ayrımı bilinçli kurmak önemli.

• Doğrulamada yakalananlar: PR açılmadan önce test, derleme ve linter çalışıyor, ikinci bir ajan diff'i inceliyor
• Zorunlu CI: otomatik kontroller başarısız olursa birleştirme engelleniyor, kimse 'sonra düzeltiriz' diyerek geçemiyor
• Yapay zekâ incelemesi: yalnızca birden fazla oylayan ajanın doğruladığı bulgular PR'a yazılıyor
• Güvenlik incelemesi: genel incelemeden ayrı, güvenlik açıklarına odaklanan bir geçiş; Anthropic'in açık kaynak karşılığı PR açıldığında tetikleniyor ve önerilen düzeltmelerle satır içi yorum bırakıyor
• İnsan onayı: riske göre ölçeklenen, bazı kod yollarında her zaman zorunlu olan karar
• Birleştirme kuyruğu ve bayraklar: güncel main üzerinde yeniden kontrol, ardından iç kullanım, 'latest' ve 'stable' sırasıyla kademeli yayın
• Hepsinin altında: hızla kapatılabilen bayraklar ve bozuk derlemelerin geri alınması

Onay insanda kalıyor, sorumluluk birleştirmeyle bitmiyor

Yazıdaki diyagram otomatik adımları bir insanın vermesi gereken kararlardan açıkça ayırıyor ve bu kararları riske göre ölçekliyor. Bazı kod yollarının her zaman bir insan gerektirdiği de not edilmiş. Hangi yolların bu kapsamda olduğu yazıda genel düzeyde kalıyor; kendi kod tabanınızda bunu sizin belirlemeniz gerekiyor. Ödeme akışları, yetkilendirme ya da kalıcı veri silen işlemler çoğu şirket için akla gelen ilk adaylar.

Aynı ilke Anthropic'in sattığı üründe de var. Unite.AI'ın aktardığına göre Code Review for Claude Code'un GitHub kontrolü (check run) hiçbir zaman başarısız sonuçla bitmiyor ve inceleme bir PR'ı ne onaylıyor ne de engelliyor. Bu bilinçli bir tasarım tercihi: makine bulgu üretiyor, birleştirme kararı ekipte kalıyor.

Sorumluluk birleştirmeyle de bitmiyor. Claude Code ekibinde değişikliği yazan kişi ve nöbetçi mühendis değişikliği izliyor, bayraklar hızla kapatılabiliyor, bozuk derlemeler geri alınıyor. Girişteki cümle burada somutlaşıyor: 'Bu kodu yapay zekâ yazdı' bir savunma değil. PR'ı açan kişi değişikliğin sahibidir ve canlıdaki davranışından da o sorumludur.

Ajanlarla incelemenin kendi sorunları

Yazının dürüst tarafı, işlerin pürüzsüz gitmediğini kabul etmesi. daily.dev özetine göre ekip üç sorun tarif ediyor. Birinci sorun hiç yakınsamayan inceleme döngüleri: bir PR 50'den fazla tur dönmüş. Özet, döngünün neden bu kadar uzadığını açıklamıyor. Benim tahminim, kodu ajanın yazıp yine ajanın incelediği düzenlerde her düzeltmenin yeni bir yorum doğurabileceği; bu yüzden 'bu kadar yeterli' kararını kimin vereceğini önceden belirlemek akıllıca olur.

İkinci sorun gürültü. Ekip gürültüyü yazarların inceleme yorumlarına nasıl tepki verdiğine bakarak ölçüyor. Otomatik Claude incelemesi de yalnızca birden fazla oylayan ajanın doğruladığı bulguları işaretliyor. Bunu kendi ekibinizde şöyle uygulayabilirsiniz: birkaç hafta boyunca otomatik yorumların ne kadarının kodda değişikliğe yol açtığını, ne kadarının yanıtsız kapatıldığını sayın. Bu bizim önerimiz, ekibin kullandığı yöntemin birebir tarifi değil, ama kaba bir sinyal/gürültü oranı için yeterli.

Üçüncü sorun bilgi aktarımı: kod tabanı bilgisi artık diff'leri satır satır okuyarak değil, Claude'un ürettiği açıklamalar üzerinden yayılıyor. Bence üçü içinde en tartışmalısı bu. Hızlı ve ölçeklenebilir, ama yeni başlayan bir mühendisin sistemi kendi kafasında kurma biçimini değiştiriyor. Açıklamayı okumak ile kodu anlamak aynı şey değil ve bu farkı yönetmek liderlerin işi.

Ürün tarafında ne değişti

Anthropic'in InfoQ'ya verdiği iç verilere göre esaslı inceleme yorumu alan PR oranı %16'dan %54'e çıkmış; 1.000 satırı aşan PR'ların %84'ünde, 50 satırın altındakilerin ise %31'inde bulgu çıkmış. Mühendisler bulguların %1'inden azını hatalı olarak işaretlemiş.

Unite.AI'a göre ön izleme kullanıcıları daha sessiz, değişikliğin boyutuna göre ölçeklenen ve daha hızlı incelemeler istemiş; genel kullanımda depo bazında Quick, Standard ve Deep seviyeleri, doğruluk hatalarına odaklanan bir varsayılan ve REVIEW.md ile CLAUDE.md üzerinden ayar imkânı gelmiş. Bence buradaki ders araçtan bağımsız: büyük PR, hem insan hem makine için daha çok sorun saklıyor.

Büyük bütçe olmadan neler uygulanabilir

Çoğu ekip yönetilen bir inceleme ürününe hemen geçmeyecek, geçmesi de gerekmiyor. The New Stack'in aktardığına göre Anthropic'in mevcut kod inceleme GitHub Action'ı açık kaynak olarak duruyor; şirket onu Code Review'a göre daha az kapsamlı ve daha ucuz olarak tanımlıyor. Claude Code'daki /security-review komutu da açık kaynak güvenlik inceleme Action'ıyla aynı analizi sunuyor.

Bu hafif seçeneklerle neler yapılabileceğine dair somut bir örnek Deriv'den geliyor. Şirket Claude Code GitHub Actions üzerinde otomatik bir güvenlik incelemecisi kurmuş: PR açıldığında, güncellendiğinde ya da yeniden açıldığında tarama yapıyor ve insan görmeden önce önem derecesi, CWE sınıflandırması ve önerilen düzeltme içeren yapılandırılmış bir inceleme bırakıyor. Geliştiriciler PR yorumunda @claude yazarak soru sorabiliyor ya da düzeltme isteyebiliyor.

Sınırı da bilmek gerek. Anthropic'in yardım merkezi, otomatik güvenlik incelemelerinin mevcut güvenlik pratiklerini ve manuel kod incelemesini tamamlaması gerektiğini, onların yerine geçmemesi gerektiğini açıkça yazıyor. Bir otomatik tarayıcı kurup güvenlik incelemesini kapatmayı düşünen yöneticinin bu cümleyi ciddiye alması gerekir.

Araçtan bağımsız olarak uygulanabilecek pratikler ise oldukça sade; aşağıdakiler kaynaklardaki yapıdan çıkardığımız öneriler:

• PR açılmadan önce yerel doğrulamayı kural haline getirin: test, derleme ve linter geçmeden PR açılmasın
• CI'ı zorunlu yapın: kırmızı kontrolle birleştirme mümkün olmasın, istisnayı kimin verebileceği yazılı olsun
• Riskli kod yollarının listesini çıkarın ve bu yollarda insan onayını pazarlıksız tutun
• PR boyutuna üst sınır koyun; büyük değişiklikler bölünerek gelsin
• Yeni davranışları feature flag arkasında, önce iç kullanıcılara açarak yayına alın
• Geri alma sürecini prova edin; bayrağı kimin, ne kadar sürede kapatabileceği belli olsun
• İnceleme döngülerine tur sınırı koyun ve son sözü kimin söyleyeceğini önceden belirleyin
• İnceleme normlarını depoda yazılı bir dosyada toplayın; insan da ajan da aynı kuralları okusun

Araç satın almak kültürü değiştirmiyor

Harvard çalışmasının DEV Community'deki değerlendirmesine göre örneklemdeki şirketlerin yaklaşık %80'i Mart 2026'ya kadar bir yapay zekâ kod inceleme aracı kullanmış. Buna rağmen inceleme yorumlarının yalnızca %23,3'ü yapay zekâdan gelmiş ve PR'ların sadece %10,8'i herhangi bir yapay zekâ yorumu almış. Lisans almak ile süreci yeniden kurmak arasında büyük bir mesafe var.

LeadDev'in 2026 anketini aktaran David R. Longnecker'a göre mühendislerin %68'i yapay zekânın kod inceleme biçimlerini şimdiden değiştirdiğini söylüyor ve bunların %86'sı PR'ları ön elemeden geçirmek için yapay zekâ kullanıyor. Sonuç ise karışık: %29'u incelemelerin uzadığını, %24'ü zaman kazandığını, %47'si değişiklik olmadığını belirtiyor. Aynı yazıda aktarılan CodeRabbit analizi, 470 açık kaynak PR'da yapay zekâ ortak yazarlı olanlarda ortalama 10,83, yalnızca insan yazdığı varsayılanlarda 6,45 sorun bulmuş.

Benim çıkarımım şu: CI'ı zayıf, testi az, geri alma süreci belirsiz bir ekibe yapay zekâ incelemecisi eklemek çoğu zaman sadece daha fazla yorum üretir. Claude Code ekibinin modeli bir araç tercihi değil, temel mühendislik disiplininin üzerine kurulmuş bir katman. Temeli olmayan şirket için ilk adım ajan değil, zorunlu CI ve çalışan bir bayrak sistemi.

Yapay zekâyı henüz yoğun kullanmayan ekipler için de mesele aynı. Liderin sorması gereken soru 'incelemeyi kim yapacak' değil, 'hangi kararı kim verecek ve canlıda bir şey bozulunca kim ilgilenecek' olmalı. Bu sorunun cevabı netse, kodun ne kadarını yapay zekânın yazdığı ikincil bir ayrıntıya dönüşür.