Git ajan hızına yetişemeyince: Anthropic kendi kaynak kontrol sistemi Scion'u yazdı

Sorun: Git’in varsayımı

Git, 2005’te Linux çekirdeği için tasarlandı. Temel varsayımı şu: Her geliştiricinin bilgisayarında deponun tam bir kopyası var, internet olmadan da çalışabiliyor, işini bitirince push ile paylaşıyor. İnsanlar için bu çok iyi çalıştı ve git’i standart yapan da buydu.

Anthropic’in 13 Ekim’de yayımladığı mühendislik yazısına göre şirketin durumu artık bu varsayıma uymuyor. Mayıs 2026’da günde ortalama 2.500 kod değişikliği birleşiyordu, Eylül’de bu sayı 30.000’i geçti. Bu artışın arkasında kod yazan ajanlar var. Tek büyük depodaki (monorepo) ana dalın geçmişi 100 GB’a yakın, sıkıştırılmış bir çalışma kopyası 25 GB’ın üstünde. CI her gün yaklaşık 25 milyon kez kodu çekiyor. Ekibin hesabına göre bunu düz git ile yapmak günde 600 petabayttan fazla trafik demek.

Git’in bunun için araçları var: sığ klon (shallow clone), sparse checkout ile deponun sadece bir kısmını almak, iç aynalar (mirror). Anthropic hepsini denemiş, en yoğun dönemde birkaç yüz git aynası işletmiş. Bu zaman kazandırmış ama birleşme hızı arttıkça işletmesi zorlaşmış.

Scion’un ilkeleri

Ekip beş ayda monorepo’yu kendi yazdığı Scion’a taşıdı. Scion, Google’ın iç sistemi Piper ile Meta’nın açık kaynak Sapling’inden (özellikle sunucu tarafı Mononoke’den) dersler alıyor. Git’ten ayrıldığı yerler:

• İstemci hep çevrim içi. Makinede tüm geçmiş durmuyor. İstemci sınırlı bir önbellek tutuyor, dosyaları diske yerleştiriyor ve değişiklikleri izliyor. Hangi dosya lazımsa o anda sunucudan geliyor.
• Push yok. Commit, rebase ve merge doğrudan sunucuda oluyor. Paylaşılacak bir şey kalmadığı için push adımı da yok. Karşılığında her işlemin hızlı ve kilitsiz olması gerekiyor.
• Değişiklik kümesi (changeset) temel birim. Her kayıt, ilk ebeveynine göre değişen dosyaları ve içeriklerin özet adreslerini (content-addressed) tutuyor. Git’in sıkıştırılmış paket dosyaları ve depo bakımı yok.
• Sorular API’den. “Bu satırı kim değiştirdi?” (blame) ya da bir dosyanın geçmişi gibi bilgiler sunucuda hesaplanıyor. Birçok iş hiç yerel depo açmadan bu API’lerle hallediliyor.

Yazıya göre altyapı artık eski git aynalarının 200’de biri kadar işlemci ve bellek kullanıyor. CI ve araştırma işleri kodu dakikalar yerine saniyeler içinde çekiyor. Sadece CI’da işlemci kapasitesinin yüzde 25’i boşa çıkmış.

Yedi kişi, bir sürü Claude

Scion’u ve şirketin kod inceleme aracı Antique’i yedi kişilik bir ekip yazmış. Ekip Claude’u yalnızca kod yazmak için kullanmamış. Örneğin git’ten Scion’a veri aktaran hattı, Claude Mythos Preview’ın erken bir iç sürümüne baştan yazdırmışlar. Çıkan sürüm 20 kat az bellek kullanıp 4 kat hızlı çalışmış. Mythos Preview’ı Nisan’daki yazımızda anlatmıştık.

İşletmede de ilginç bir düzen var: Her bileşen için ayrı bir Slack kanalında, sadece o bileşenin sağlığına odaklanmış bir Claude çalışıyor. Ekip bunlara “superfan” diyor. Telemetri ve loglara erişimleri var, grafiklerde tuhaf bir şey arıyorlar. Klasik alarmlar da duruyor. İnsanlar hâlâ her değişikliği inceliyor ama satır satır okumak yerine değişikliğin amacına bakıyor. Bu, Claude Code ekibinin inceleme düzenine çok benziyor.

Herkes git’i bırakmalı mı?

Hayır, Anthropic de bunu söylemiyor. Scion açık kaynak değil ve olmayacak. Ekibe göre sistem git’ten o kadar ayrılıyor ki geçmek için kod incelemeden kod aramaya ve CI’ya kadar tüm geliştirme hattını değiştirmek gerekiyor. Bu da yalnızca çok büyük monorepo’larda, on binlerce mühendisle ya da büyük ajan sürüleriyle çalışan yerlerde mantıklı.

Bir bedel de açıkça yazılmış: Testler çalışırken yüzlerce değişiklik birleşebildiği için klasik birleştirme kuyruğunun (merge queue) depo kilidi işlemiyor. Anthropic onun yerine birleşme sonrası ve yayın öncesi otomatik testlere geçmiş. Aynı anda gelen değişiklikler çakışabiliyor. Ekip bu çakışmaları Claude’un genelde insanların fark etmesinden hızlı düzelttiğini söylüyor.

Yazının asıl mesajı şu: Bu tür ölçek sorunlarının önümüzdeki 6–12 ayda daha çok şirkete geleceğini düşünüyorlar ve fikirlerin GitHub, GitLab ve açık kaynak topluluğu tarafından git’e taşınmasını umuyorlar.

OpenAI aynı soruna ters yönden yaklaştı: git’i bırakmadı, sadece sunucu tarafını yeniden yazdı. Bunu Pando yazısında anlattık.

Düşün

• Senin projende CI kodu günde kaç kez çekiyor? Ajanlar bu sayıyı on katına çıkarsa ilk nerede tıkanırdı?
• Değişikliklerin çoğunu ajanlar yazıyorsa, testi birleşmeden önce mi sonra mı yapmak daha mantıklı?

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