İçeriğe geç
edumintsBlog
LLM3 dk okuma

Claude Code Ekibi Kod İncelemesini (Code Review) Nasıl Yapıyor?

Kaynak: Hacker News

Paylaş
LLMEdumints Blog
İçindekiler 3 başlık

Yapay zeka ajanları yüksek hacimde kod ürettiğinde, bu kodları nasıl incelersiniz? Addy Osmani, Morgan Westlee Lunt ve Qing Wang tarafından kaleme alınan bu çalışma, Claude Code ekibinin kendi kodunun yaklaşık %90'ını Claude'a yazdırırken kaliteyi nasıl koruduğunu ele alıyor. Haziran ve Eylül ayları arasında birleştirilen (merge edilen) Pull Request (PR) sayısı iki katından fazla artarken, geri alınan (revert edilen) değişikliklerin oranı %40'tan fazla düştü. Ekip incelemeyi ortadan kaldırmadı; okuma yükünü makinelere devretti, insan zamanını optimize etti ve hataları geri almayı kolaylaştırdı.

Kod İncelemesinin Amacını Yeniden Düşünmek#

Ajanlar kod yazdığında değişiklik sayısı hızla artar. Anthropic'in monorepo'sunda günlük değişiklik sayısı Mayıs ayında 2.500 iken Eylül ayında 30.000'in üzerine çıktı. Bu hızda satır satır manuel inceleme yapmak neredeyse imkansızdır.

Kod incelemesi temel olarak iki işlevi yerine getirir:

  • Yayına alınmadan önce sorunları bulmak ve düzeltmek
  • Ekip genelinde ortak bağlam ve kod tabanı anlayışı oluşturmak

"Bir insan bu kodu okudu mu?" sorusu yerine "Bu değişiklikte ne ters gidebilir ve bunu yakalamak için hangi kontrol —otomatik mi yoksa insan mı— doğru olanıdır?" sorusuna odaklanmak inceleme sürecini değiştirdi. Eskiden inceleme yolun sonundaki bir kapıydı (kodu yaz, PR aç, çalışma arkadaşını bekle). Şimdi ise yazarken çalışan bir yazım denetimi (spellcheck) gibi sürekli işliyor. Çoğu değişiklik bir insanın önüne gelmeden önce Claude tarafından en az bir kez incelenip düzeltiliyor. Bu yaklaşım rutin hataları yakalayarak ekibin dikkatini üst düzey sorulara saklıyor.

Kıt Kaynak: İnsan Zamanı ve Dikkati#

Amacımız, insan zamanını ve dikkatini yalnızca insanların çözebileceği sorunlara ayırmak ve geri kalanını otomatik kontrollerin yakalamasını sağlamaktır. İnsan zamanı, inceleme maliyetinin her iki tarafını da kapsar: incelemeye harcanan zaman ve kötü kodun bozduğu şeyleri düzeltmeye harcanan zaman. İkinciyi artırarak birinciyi kısmanın hiçbir faydası yoktur.

Bu doğrultuda Claude Code depolarındaki (CLI, masaüstü, web ve mobil uygulamalar) çoğu PR'ın, geri alma veya olay (incident) oranlarında artış olmadan, süreçte en fazla bir insanla (bu kişi kodun yazarı da olabilir) birleştirilmesi hedeflenir. İnsan zamanını ölçmek için PR başına insan onayları (medyan ve 95. yüzdelik dilim), insan yorumları ve bir PR'ın bir kişiyi ne kadar beklediği takip edilir. Geri alma (revert) ve olay oranları ise temel güvenlik sınırımızdır (guardrail); eğer bu oranlar yükselirse insan zamanından tasarruf edilmemiş, sadece zamanın harcandığı yer değiştirilmiş demektir.

Bir Değişikliğin Yaşam Döngüsü ve Pratik Çıkarımlar#

Bir mühendisin bilgisayarından başlayan tipik bir değişiklik artık sürekli doğrulama döngüsünden geçer. Yazılım geliştirme ve öğrenme açısından bu yaklaşımdan çıkarılabilecek temel dersler şunlardır:

  • Sürekli İnceleme: Kod incelemesini PR aşamasına bırakmak yerine, geliştirme esnasında çalışan otomatik ajanlarla anlık geri bildirim döngüleri kurun.
  • Metrik Odaklı Güvenlik: Otomasyonu artırırken "revert" ve "incident" oranlarını kalite koruyucu metrikler olarak izleyin; hız uğruna sistem kararlılığından ödün vermeyin.

Kaynak ve atıf

Bu yazı, Hacker News üzerinde yayımlanan içerikten yararlanılarak Edumints tarafından yapay zekâ desteğiyle Türkçe hazırlandı. Ayrıntılar ve yazarların kendi anlatımı için orijinaline bakabilirsin:

  • claude.dev/blog/solving-code-review-at-anthropic