Anthropic git yerine Scion'u neden geliştirdi?

Anthropic’te kod yazmak artık sistem kurmanın ya da araştırma yapmanın darboğazı değil. Claude araştırma döngülerini otonom olarak yineleyebiliyor, karmaşık programları mikro düzeyde optimize edebiliyor ve sıfırdan yeni servisler kurabiliyor. Şirketin mühendislik ekibine göre yeni darboğaz, insan ölçeği için kurulmuş geliştirici altyapısı: kaynak kontrolü, build sistemleri ve CI.

Anthropic, Mayıs 2026’da günde ortalama 2.500 kod değişikliği birleştirirken Eylül itibarıyla bu sayı günde 30.000’i aştı. Şirket bu büyümenin yavaşlamasını beklemiyor; ortadan kaldırılan her darboğaz hemen daha fazla kod üretimine yol açıyor.

Ocak-Eylül 2026 arasında monorepo'ya günlük birleştirilen değişiklik sayısı — Ocak-Eylül 2026 arasında monorepo’ya günlük birleştirilen değişiklik sayısı

Bu büyümeyi karşılamak için Anthropic, şirket içi bir sürüm kontrol sistemi olan Scion‘u geliştirdi ve monorepo’sunu beş ay içinde git’ten tamamen taşıdı. Aynı dönemde Antique adlı bir kod inceleme arayüzü, kod arama, kapsamlı bir kaynak kontrol IAM sistemi ve büyük miktarda incelenmiş kodu yönetip birleştirmenin yeni yollarını da kurdu. Şirket, durumun ilginç bir vaka olduğunu söylüyor: Claude’un kod yazma yeteneği hem bu sorunu yaratan şey oldu hem de sorunu çözecek ölçeklenebilir sistemin hızla kurulmasını sağladı. Yazı 15 Ekim’de Scion’daki tekniklerin öncüsü olan projeler hakkında ek bilgilerle güncellendi.

Monorepo büyüyünce

Anthropic iş yükünün alışılmadık olduğunu kabul ediyor: Claude’u yazılım yazmak için neredeyse tüm şirketlerden fazla kullandığı için insan ölçeğindeki araçların zorlandığı noktaları ilk görenlerden. Şirket, kısa vadede pek çok kurumun bu sorunları yaşamasını beklemiyor; ama yapay zekâ kodlama araçları kullananların aynı baskıyla karşılaşmasının uzun sürmeyeceğini düşünüyor.

Git dağıtık bir sistem: Her klon diff hesaplayabilen, geçmişi ve blame’i okuyabilen, herhangi bir sürümü tamamen çevrim dışı checkout edebilen eksiksiz bir depo. Depoların büyük çoğunluğu için doğru tasarım bu. Ancak Anthropic’in monorepo’su bu tasarımın dışına çıkıyor:

Yalnızca ana dalın geçmişi yaklaşık 100 GB, sıkıştırılmış bir çalışma kopyası 25 GB’ın üzerinde.
Geliştirici ortamları, ajan sandbox’ları ve araştırma işleri hariç yalnızca CI için günde 25 milyon civarında checkout yapılıyor.
Bunlar saf şekilde fetch edilseydi günde 600 PB’ın üzerinde git trafiği oluşurdu.

Şirket; shallow clone, sparse checkout, promisor remote, iç git aynaları ve blob depolamada tutulan depo anlık görüntüleri (seed) gibi standart çözümlerin hepsini kullanmış. En yoğun döneminde yüzlerce iç git aynası işletmiş. Bunlar zaman kazandırsa da birleştirme hızı arttıkça işletmesi zorlaşmış: Seed’ler yenilemeler arasında ana daldan giderek uzaklaşmış, diff ve blame gibi geçmişe dayalı işlemleri kısmi klonlarda çalışır tutmak giderek daha fazla özen gerektirmiş.

Git checkout'larını ölçeklemek için tipik kurulum — Git checkout’larını ölçeklemek için tipik kurulum

Anthropic şunu fark etmiş: Çoğu şirket gibi kendisi de git’i tek bir yetkili kopyası olan merkezi bir sistem olarak kullanıyordu, ama istemcilerinin neredeyse tamamı tanım gereği çevrim içi olan ajanlar ve işlerdi. Git’i dağıtık ve çevrim dışı iş için mükemmel yapan özellikler, depo büyüdükçe ölçeklemeyi engelliyordu. Ekip şu soruyu sormuş: Kaynak kontrolünü baştan ajanların her zaman çevrim içi olduğunu bilerek tasarlasaydık nasıl olurdu?

Ajan ölçeğinde kaynak kontrolünün ilkeleri

Dev monorepo’lar için kaynak kontrolünde Google’ın Piper’ı ve Meta’nın Sapling’i (özellikle sunucu bileşeni Mononoke ve Bonsai veri modeli) gibi öncüler var; Scion bu deneyimlerden yararlanılarak geliştirildi. İlkeler şöyle:

İstemciler her zaman çevrim içi: İstemci ve protokoller her zaman erişilebilen bir sunucu etrafında tasarlandı; istemciler veriyi ihtiyaç duyduklarında çekiyor.
İstemci-sunucu asimetrisi: Dosya geçmişi ve blame sorularını sunucu yanıtlıyor; commit, merge ve rebase’i sunucu yapıyor. İstemci sınırlı bir yerel nesne önbelleği tutuyor, çalışma kopyasını diske yerleştiriyor ve dosya sistemi değişikliklerini izliyor. Kendi başına çok az şey hesaplayabiliyor ama karşılığında çok daha az yerel veri gerektiriyor.
Kapsamlı bir kaynak kontrol servisi yeni uygulamalara imkân veriyor: İstemcinin kullandığı tüm sorgular API olarak da sunuluyor; birçok iş yerel depoya hiç ihtiyaç duymuyor. Otomatik bisect ve revert hatları bu ucuz, programatik erişim olmadan ölçekte pratik olmazdı.
Her şey yatay ölçeklenebilir olmalı: Deponun verisi dağıtık; sunucuda bile tam olarak oluşturulmuş bir kopya yok. Packfile karşılığı olmadığı için depo bakımı da gerekmiyor.
Commit’ler ucuz, artımlı ve kilitsiz olmalı: Her commit, rebase ve merge sunucuda yapılıyor, bu yüzden push edilecek bir şey yok. Bir commit’in maliyeti deponun toplam boyutuyla değil değişikliğin boyutuyla ölçeklenmeli. Her sunucunun üzerinde anlaşması gereken global durum ölçek sorunu yarattığı için ana ref ve sürüm dalları dışında ref kullanımı teşvik edilmiyor.
Çalışma kopyası isteğe bağlı ve tasarım gereği sparse: Örneğin bir commit ile birleştirme tabanı arasındaki diff’e ihtiyaç duyan bir CI işi bunu sunucudan isteyebiliyor; birçok yazma işi de checkout’u atlayıp tamamen API üzerinden çalışabiliyor. Protokol, yalnızca istenen dizinleri içeren sparse checkout’lar ve dosyaları talep üzerine oluşturan sanallaştırılmış checkout’lar etrafında kurulu.

Scion nasıl çalışıyor?

Veri yapıları. Scion’da iş birimi “changeset”, yani bir write-ahead log girdisi. Git commit’i bir ağaca işaretçi tutarken changeset, ilk ebeveynine göre değişen dosyaların listesini ve blob depolamadaki sıkıştırılmış içeriklere içerik adresli işaretçileri tutuyor. Changeset’ler sunucuda oluşturuluyor ve her yerde anında erişilebiliyor. Packfile kabul etmek, kilitlemek, sunucular arası koordinasyon ya da ref taşımak gerekmediği için çok yüksek hızda kabul edilebiliyor; bir ref’i taşımak tek bir Spanner satırında compare-and-swap işlemi.

Scion'da bir changeset'in yapısı — Scion’da bir changeset’in yapısı

Changeset yalnızca değişeni kaydettiği için “bu satırı en son kim değiştirdi” gibi soruları tek başına hızlı yanıtlayamıyor. Bunun için Scion, changeset’lerden blame ve yol geçmişi yapıları ile commit grafiği için skip list’ler gibi ek veri yapıları üretiyor. Changeset’in doğrudan parçası olmayan her şeye “türetilmiş veri” deniyor ve hepsi tek bir genel mekanizmayla, ebeveynlerin değerlerinden özyinelemeli olarak hesaplanıyor. Bu sayede yeni bir veri yapısı kolayca eklenebiliyor, her tip için hesaplamanın hemen mi sonra mı yapılacağı seçilebiliyor ve istemci bu yapıların içini görmediği için istemciyi değiştirmeden optimize edilebiliyor.

Ölçekleme. Küçük bir Scion sunucu filosu; changeset alma, diff hesaplama, birleştirme tabanı bulma ve blob getirme gibi tüm işlemler için API sunuyor. Tüm veri içerik adresli olduğu için bir kez saklandıktan sonra değişmiyor ve her sunucu diğerlerine sormadan önbelleğe alabiliyor. Sunucular esasen türetilmiş veriyi anında hesaplayıp Spanner’a geri yazabilen büyük önbellekler.

scn istemcisi git’in fetch protokollerinden önemli ölçüde ayrılıyor. Müzakere, istemcinin elinde ne olduğunu sunucuya söylemek yerine yalnızca istemcinin istediği ağaç ve blob’lar üzerinden işliyor: Kök ağaçtan başlayarak eksik ağaçları, sonra blob’ları özyinelemeli istiyor. Her istek asla değişmeyen belirli bir nesne için olduğundan herhangi bir önbellek yanıtlayabiliyor; çok gigabaytlık tek bir packfile yanıtı olmadığı için süreç verimli ve kaldığı yerden devam edebiliyor.

Filoda istemci, düğümün tüm nesnelerini saklayan scion-daemon ile soket üzerinden konuşuyor. Her daemon düzenli yenilenen bir anlık görüntüden başlıyor ve yalnızca kendi bölgesindeki scion-cache sunucularıyla konuşuyor. Bu önbellekler nesneleri daemon’ın kullanacağı disk formatında doğrudan bellekten aktarıyor. Önbellekte olmayan nesneler yetkili scion-server‘lardan, onlar da Spanner ya da bulut depolamadan okunuyor. Üç katman aynı RPC’leri yanıtlıyor ama hata alanlarını izole etmek için katmanlama sıkı biçimde uygulanıyor.

Anthropic’in verdiği sonuçlar:

Her katmanda önbellek isabet oranı %99’un üzerinde; uzun ömürlü durum gerekmediği için kolay ölçekleniyor.
Scion altyapısı, CPU ve bellek açısından önceki git aynalama altyapısından 200 kat daha küçük.
CI ve araştırma işleri kodu iki kat büyüklük mertebesi daha hızlı, dakikalar yerine saniyeler içinde checkout ediyor.
Yalnızca CI’da %25 CPU kapasitesi kazanıldı.

Monorepo'da günlük kaynak kontrol komutlarının git ve scn ile medyan süreleri — Monorepo’da günlük kaynak kontrol komutlarının git ve scn ile medyan süreleri

Grafiğe göre geliştirici ortamlarında status komutu 3,9 saniyeden 19 milisaniyeye inmiş; ajan ortamlarında yeni worktree oluşturmak 7,1 dakikadan 5,1 saniyeye düşmüş. Değişiklik isteği başına toplam kaynak kontrol süresi ajan ortamlarında 34 dakikadan 3,7 dakikaya inerek günde yaklaşık 11.000 ajan saati tasarruf sağlamış.

Scion’u geliştirirken öğrenilenler

Scion, Claude Mythos Preview ve Claude Tag’in şirket içinde kullanılmaya başlandığı dönemde geliştirilmeye başlanmış; ikisi hem Scion ihtiyacını artırmış hem de geliştirmeyi hızlandırmış. Ekip yılın başında git’ten Scion’a aktarım hattının ilk sürümünü büyük ölçüde elle yazmış. Claude Mythos Preview’ın erken bir iç sürümünden tamamını yeniden yazmasını istediklerinde, başka bir talimat olmadan 20 kat daha az bellek kullanan ve 4 kat daha hızlı bir sürüm elde etmişler; üstelik aktarım sırası ve veri yapılarıyla ilgili örtük kuralları koruyarak.

Ocak-Eylül 2026 arasında Scion ve Antique kod tabanlarına haftalık birleştirilen değişiklikler

Küçük ekiplerle hızlı geliştirme yaygınlaşacak: Yedi kişilik bir ekip Scion’u, Antique’i ve yarım düzine ilişkili sistemi kurup beş ayda tamamen taşıdı; bu sırada günlük birleştirilen kod hacmi 10 kat arttı. Anthropic’e göre eskiden bu tür bir sistem yıllar ve çok daha fazla mühendis gerektirirdi.
Mühendisler daha az değerli değil, işleri değişiyor: Sistem üzerinde çalışan tüm mühendisler artık Claude’un kendilerinden daha iyi kod yazdığını söylüyor. Ama sistemler arası bileşenleri ve tasarım ödünleşimlerini anlayan, hangi ölçeğe ulaşılması gerektiğini bilen yine mühendisler. Çoğu zaman mühendisin görevi Claude’a “hayır” demek oldu: Ajanlar bazen temel sistem kısıtlarını ihlal edebiliyor. Karşıt (adversarial) inceleme çok etkili olsa da dar görüşlü olabiliyor ve varsayımsal endişelere aşırı mühendislikle yanıt verebiliyor. Ekip her değişikliği hâlâ inceliyor, ama artık her satırı değil değişikliğin amacını değerlendiriyor.
Optimizasyon ve kalite önemli ölçüde arttı: Scion, ekibin üzerinde çalıştığı en iyi test edilmiş kod tabanlarından biri; önemsiz olmayan her altyapı ve kaynak kontrol etkileşimi için hermetik simülasyonlar, fuzzing ve gelişmiş hız sınırlama var. Claude, bir uzmanın günler ya da haftalarca analiz edeceği algoritmik optimizasyonları da buldu.
Monorepo güvenliğinde yeni bir temel: Scion depo düzeyinde zengin erişim kontrolünü ve en hassas kodu korumak için dizin düzeyinde izinleri destekliyor. Kod inceleme aracı onaylarda karmaşık anlamsal kurallar tanımlayabiliyor; örneğin yalnızca yorum içeren değişiklikleri hassas mantık değişikliklerinden ayırıp insan incelemesini en önemli değişikliklere yönlendiriyor.
Yeni bir operasyonel mükemmellik seviyesi: Ekip, Claude Tag ile her bileşen için ayrı Slack kanalları oluşturup Claude’u tek bir bileşenin sağlığına odaklanmakla görevlendirmiş. Bu Claude’lara “superfan” deniyor: scion-daemon superfan’ı, scion-cache superfan’ı, Antique merge queue superfan’ı gibi. Telemetri ve loglara erişimleri var ve klasik uyarıların kaçırdığı ince ve yeni sorunları yakalayabiliyorlar.
Varsayımlar baştan sorgulanıyor: Testler çalışırken yüzlerce hatta binlerce değişiklik birleşebiliyorsa CI ne anlama geliyor? Ekip merge queue’da global depo kilidi standardını ajan ölçeğinde tekrarlayamadığı için birleştirme sonrası ve dağıtım öncesi otomatik testlere yatırım yapmış. Eşzamanlı değişiklikler çakışabiliyor, ama Claude bunları genellikle insanların fark etmesinden daha hızlı düzeltiyor.

Daha geniş ekosisteme katkı

Anthropic, Scion’un genel kullanım için git’in yerini tutmadığını açıkça söylüyor. Bu kavramlar yalnızca on binlerce mühendisi ya da yoğun kod yazan ajan sürüleri olan devasa monorepo’lar için anlamlı. Ayrıca Anthropic’in iç kullanım için harcayabildiği token miktarı, başka bir şirketin gerçekçi olarak harcamak isteyeceğinin çok üzerinde. Scion git’ten çok ayrıldığı ve kendi kod inceleme, kod arama ve CI bileşenlerini gerektirdiği için, şirket bunu herkese uygun bir ürün olarak sunmanın zor olduğunu belirtiyor.

Bununla birlikte Anthropic, bu tür sorunların önümüzdeki 6-12 ayda yaygınlaşacağını öngörüyor ve en etkili katkının düşüncelerini paylaşmak olduğunu söylüyor. Önerileri: Git sunucusu git istemcisiyle aynı şekilde çalışmak zorunda değil; git platformları Scion benzeri kapsamlı sunucu tarafı RPC’ler sunabilir, belki de farklı forge’lar arasında standart bir şekilde. Müzakere protokolü bugünkü gibi olmak zorunda değil ve git’teki sparse ile shallow özellikleri birbiriyle uyumlu hale getirilebilir. Şirket, git topluluğunun neredeyse yirmi yıldır platformu milyonlarca geliştirici için ölçeklediğini kabul ediyor ve GitHub, GitLab ve açık kaynak topluluğuyla birlikte çalışmak istediğini belirtiyor.

Yazının en dikkat çekici rakamları, günde 30.000’i aşan birleştirme ve yalnızca CI için günde 25 milyon checkout. Çoğu kurum için bu ölçek uzak; ama ajan kullanımı arttıkça git sunucularındaki yükün, checkout sürelerinin ve merge queue kilitlerinin ilk zorlanan yerler olacağına dair somut bir uyarı niteliğinde. Rakamların tamamı Anthropic’in kendi ölçümleri.

Kaynak: https://www.anthropic.com/research/redesigning-source-control