Anthropic, Claude blogunda ajanlı kodlamanın sürekli entegrasyon (CI) altyapısını nasıl zorladığını ve test etki analizi (test impact analysis / test selection) servisini nasıl yeniden ölçeklediklerini anlattı. Yazı 14 Eylül 2026 tarihli; yazar Sachin Malhotra.
Şirkete göre Anthropic mühendisleri, 2021–2025 ortalamasına kıyasla çeyrek başına ortalama 8 kat daha fazla kod üretiyor. Bu kodun yaklaşık yüzde 80’ini Claude yazıyor; Claude ayrıca PR inceleme ve onay süreçlerinde de büyük rol oynuyor. Kod tabanındaki test sayısı 10 kat artarken mühendis kadrosu nominal ölçüde büyümüş. Sonuç: altı ayda CI iş hacminde 25 kat artış.
Neden her test her PR’da koşmuyor?
Birçok ekip hâlâ her değişiklikte tüm testleri çalıştırıyor. Anthropic’e göre bu yaklaşım bir yere kadar işler; ölçekte CI kapıları uzar, pahalılaşır ve güvenilirliğini yitirir. Ayrıca insanlar hangi test hatalarının kendilerini ilgilendirmediğini ayırt etmekte iyidir; ajanlar ise daha fazla bağlam ve yönlendirme ister. Geçerli bir test kümesi verildiğinde ajanlar kendini doğrulayıp daha etkili yineleyebilir.
Anthropic, geçmiş performans ve paket ilgisine göre her değişiklikte hangi testlerin çalışacağını belirleyen deterministik bir test etki analizi / test seçimi servisi kurmuş. Servis, senkron kalması gereken iki deterministik bileşene dayanıyor. Birden fazla CI işi her saniye çalıştığında dinleyici (listener) PR kuyruğunun gerisine düşebiliyor. Örneğin 20 dakikalık dinleyici gecikmesi, seçiciye uygulanmayan onlarca binlerce test güncellemesine dönüşebiliyor.
İlk tasarım (v0) tek süreçte çalışıyordu: test başına çalışan geçmiş tutulduğu için sonuçları tek bir yazıcının uygulaması gerekiyordu. Bu da yatay parçalamayı (horizontal sharding) engelliyordu. Ekim 2025’te servis zaten zorlanmaya başlamış; iki gün üst üste alarm almışlar.
Üç yama, sonra yeniden tasarım
İlk düzeltme çekirdek sayısını ikiye katlamak olmuş; bunun geçici olduğu biliniyormuş. Claude Tag’in dahili bir sürümünde uzun soluklu bir oturum açılmış; dinleyici 50.000 işten fazla geride kaldığında Claude uyarı verip konuşmayı sürdürmüş. Claude sık sık kökten yenilemeyi savunmuş, ekip çoğu zaman başka bir yamayla yetinmiş.
Şubat’ta CI işlerinin üstel artışı servisi yeniden zorlayınca dinleyiciyi paket bazında parçalamışlar: her paket için ayrı durum ve işçi. Claude kodu üretmiş. Bu çözüm yalnızca 29 gün yetmiş.
Mart’ta süreç çoğu hafta içi öğleden sonra bellek limitine dayanmış. Günlük yeniden başlatmalar servisin giderek daha fazla geride kalmasına yol açmış; bir saatten fazla geride kalındığında dinleyici birçok iş sonucunu kaydedememiş. Bu, CI’nin hiç çalışmadığı veya test edilmemiş kodun üretime gittiği anlamına gelmiyor: seçici, hangi testlerin koşulacağına karar verirken bayat veri kullanmış; çoğu zaman zaten kırılgan veya yaygın başarısız testlerin tekrar koşulmasına yol açmış.
Yeniden tasarımda test seçimi servisine bellek içi bir veri deposu verilmiş. Böylece dinleyici işçileri sonucu bellekte tutmadan günlüğe (journal) yazıp geçebiliyor; durum bilgisi süreç dışına taşınmış ve yatay ölçeklenebilir hale gelmiş. Küçük bir tüketici süreç her birkaç saniyede günlüğü test başına geçmişe yuvarlıyor; seçici ilgili geçmişe hızlı bakabiliyor. Dağıtık mimari çalıştırması daha pahalı olsa da ölçeklemek ve bellek profillemek tekil (singleton) tasarıma göre daha kolay. Proje tek mühendisle üç haftada bitmiş; bir yıl önce bunun çeyrek yıla yakın süreceği belirtiliyor. Servis o zamandan beri stabil kalmış.
Çıkarılan dersler
Malhotra, Ekim 2025’e geri dönse üstel AI yükünü hesaba katacağını yazıyor: mühendis başına ajan sayısı ve hızlanan PR onayı CI işlerini üstel artırıyor. Claude’un daha küçük, taneli PR’ları tercih etmesi de günlük CI iş sayısını yükseltiyor; ajanlar gece ve hafta sonu da itiş yapınca taban aktivite yükseliyor, yine de insan onayları nedeniyle yük patlamalı kalıyor.
Ekipere öneri: ister kendi yapın ister satın alın, mimarinizin iki çeyrek içinde 25 kat yükte olacağını varsayın. Bütçe elverdiğince v0 tasarımlarda algılanan ölçeğin 10–20 katını hesaba katın. Servisleri Claude’un “gözü kulağı” olacak şekilde enstrümante edin; özellikle giren CI iş sayısının çıkanla eşit olduğundan emin olun. Durumu süreçten en baştan dışarıda tutun; kritik servisleri ölçüm ve canary olmadan tek örnek olarak çalıştırmaktan kaçının.
Kaynak: Agentic coding is straining CI. Here’s how we scaled test impact analysis at Anthropic – Claude Blog
Henüz yorum yok. İlk yorumu siz yapın!