Anthropic Neden Kendi Sürüm Kontrol Sistemini Geliştirdi?

Yapay zekâ destekli yazılım geliştirmeyi konuşurken genellikle modelin ne kadar iyi kod yazdığına odaklanıyoruz. Daha doğru sonuç veren, daha büyük bağlamı anlayan, daha az müdahale isteyen araçları karşılaştırıyoruz. Ben ise bu hız artışının geliştirme sürecinin geri kalanında neyi değiştirdiğini daha ilginç buluyorum.

Bir ekip eskisinden çok daha fazla kod üretebiliyorsa o kodun incelenmesi, test edilmesi, birleştirilmesi ve güvenle yayına alınması da aynı ölçüde önem kazanıyor. Üretim kapasitesi arttığında sistemin başka bir yerinde bekleme oluşabiliyor.

Anthropic’in Scion kararı, bu durumu kaynak kontrolü üzerinden incelemek için iyi bir örnek.

Şirketin 13 Ekim 2026 tarihli açıklamasına göre günlük birleştirilen kod değişikliği sayısı mayısta yaklaşık 2.500 iken eylülde 30.000’i aşmış. Anthropic, ana kod deposunu kendi geliştirdiği Scion’a beş ayda taşımış. Bunlar şirketin kendi iş yükü için açıkladığı veriler. Anthropic’in teknik açıklaması

Bu ölçekte benim dikkatimi çeken nokta, kaynak kodun büyüklüğü kadar ona erişme sıklığı. Tek bir geliştiricinin bilgisayarında kabul edilebilir olan hazırlık maliyeti, çok sayıda geçici çalışma ortamında tekrarlandığında önemli bir altyapı giderine dönüşebilir.

Git’in tasarımını bu açıdan düşünmek gerekiyor. Git, birçok işlemi yerel verilerle yapabilmemizi sağlıyor. Geçmişi incelemek, sürümler arasındaki farkları görmek ve commit oluşturmak için sürekli sunucuya bağlı kalmak zorunda değiliz. Bu özellik, geliştiriciye bağımsızlık kazandıran temel avantajlardan biri. Git’in çalışma modeli

Ancak birkaç dakikalığına oluşturulup sonra silinen bir otomasyon ortamının ihtiyaçları farklı olabilir. Yalnızca belirli bir değişikliği inceleyecek bir iş için hangi verilerin gerçekten gerekli olduğunu sorgulamak, bu yüzden önemli.

Burada Git’in mevcut optimizasyonlarını da doğru ayırmak lazım:

Yöntem	Azaltmaya çalıştığı yük
Shallow clone	İndirilen geçmişin derinliği
Partial clone	Başlangıçta getirilen nesnelerin kapsamı
Sparse checkout	Çalışma dizininde bulunan dosyaların kapsamı

Örneğin, sunucunun ilgili özellikleri desteklediği bir depoda şöyle bir başlangıç yapılabilir:

git clone --filter=blob:none --sparse \
  https://example.com/team/platform.git

cd platform

git sparse-checkout set src/Identity tests/Identity

Bu örnekte dosya içerikleri başlangıçta filtrelenir; çalışma dizini de seçilen klasörlerle sınırlandırılır. İhtiyaç duyulan eksik içerikler daha sonra getirilebilir. Derleme ortak kütüphanelere veya kök dizindeki yapılandırmalara bağlıysa seçimin buna göre genişletilmesi gerekir. Partial clone, sparse checkout, clone seçenekleri

Dolayısıyla büyük bir depoyla karşılaşıldığında ilk adımın yeni bir sürüm kontrol sistemi yazmak olması gerektiğini düşünmüyorum. Önce mevcut araçların doğru kullanıldığından ve maliyetin gerçekten nerede oluştuğundan emin olmak gerekir.

Anthropic’in Scion’da seçtiği mimari ise bazı sorumlulukları sunucuya taşıyor:

Alan	Scion’un yaklaşımı
İşlemler	Commit, merge ve rebase sunucuda yürütülüyor.
İstemci	Sınırlı yerel önbellek tutuyor; veriyi ihtiyaç oldukça alıyor.
Sorgular	Diff, geçmiş ve ortak ata sorguları API üzerinden sunuluyor.
Çalışma kopyası	Bazı otomasyonlar yerel depo oluşturmadan çalışabiliyor.

Değişiklikler, write-ahead log içindeki changeset kayıtlarıyla temsil ediliyor. Bu kayıtlar ilk ebeveyne göre değişen dosyaları ve içerik referanslarını taşıyor. Geçmiş ve blame gibi sorgular için ayrıca türetilmiş veri yapıları oluşturuluyor. Scion’un veri modeli ve mimarisi

Bu ayrım bana uygulama mimarisinde sık karşılaştığımız bir tercihi hatırlatıyor: Veriyi güvenilir biçimde kaydetmek için uygun olan yapı ile o veri üzerinde hızlı sorgu yapmak için uygun olan yapı her zaman aynı olmayabilir.

Örneğin değişiklik geçmişini saklamak başka, belirli bir dosyanın geçmişini düşük gecikmeyle sorgulamak başka bir erişim ihtiyacıdır. Sorgu desenleri belirginleştiğinde bunlara özel indeksler tasarlamak mantıklı hale gelir. Buna karşılık indekslerin oluşturulması, güncelliği ve yeniden üretilebilmesi de sistemin sorumluluğuna eklenir.

İçerik adresleme konusunda da bir ayrımı önemsiyorum. İçeriğin hash üzerinden tanımlanması Git’te zaten bulunan temel bir özellik. Böyle bir yapı aynı içeriğin yeniden tanınmasını ve paylaşılmasını kolaylaştırır. Tek başına bu özelliğin varlığı, bütün erişim ve ölçekleme problemlerini çözmez. Git’in nesne modeli

Ben bir mimariyi değerlendirirken hangi verinin değişmez olduğunu, hangi bilginin zaman içinde değişebildiğini ayrı ele alırım. Belirli bir içerik nesnesini önbelleğe almak ile bir dalın en güncel durumunu önbelleğe almak aynı tutarlılık ihtiyacına sahip değildir. Benzer biçimde, içeriğin doğrulanabilir olması kullanıcının o içeriğe erişmeye yetkili olduğunu göstermez.

Performans tasarımı; tutarlılık, yetkilendirme ve hata durumlarıyla birlikte düşünülmek zorunda.

Bunun ekonomik tarafı da oldukça somut. Tamamen örnek bir hesap yapalım: Bir otomasyon işi, ihtiyaç duymadığı 200 MB veriyi indiriyorsa ve bu işlem günde 10.000 kez tekrarlanıyorsa yaklaşık 2 TB gereksiz aktarım oluşur. Bu, Anthropic’in ölçümü değil; küçük birim maliyetlerin tekrar sayısıyla nasıl büyüdüğünü göstermek için verdiğim varsayımsal bir örnek.

Üstelik maliyet yalnızca ağ trafiği değildir. Dosyaların açılması, diske yazılması, taranması ve ortamın işe hazır hale gelmesi de kaynak tüketir. Bu nedenle ben bir CI süresini incelerken test süresiyle hazırlık süresini ayrı görmek isterim. Testleri hızlandırmaya çalışırken asıl bekleme kaynak kodun hazırlanmasında yaşanıyor olabilir.

Kaynak kontrolü hızlandığında da geliştirme sürecinin tamamı otomatik olarak hızlanmış sayılmaz.

Bunu bir kuyruk problemi olarak düşünmek mümkün. Bir doğrulama hattına dakikada 100 değişiklik geliyor, hat dakikada 80 değişikliği tamamlayabiliyorsa basitleştirilmiş hesapla her dakika 20 değişiklik birikir. Daha fazla kod üreten ajan eklemek, bu hattın kapasitesini artırmadığınız sürece beklemeyi büyütür.

Bu yüzden benim AI destekli geliştirme süreçlerinde izlemek isteyeceğim metrikler şunlar olur:

• Değişikliğin oluşturulmasından doğrulanmasına kadar geçen süre.
• İnceleme bekleyen değişikliklerin sayısı ve yaşı.
• Hatalı değişikliklerin hangi aşamada yakalandığı.
• Değişiklik başına kullanılan altyapı kaynağı.
• Canlıya çıkan değişikliklerin geri alınma oranı.

Bu metrikler olmadan günlük commit sayısındaki artışın işletmeye ne kazandırdığını değerlendirmek zorlaşır. Çok sayıda küçük ve güvenilir değişiklik değerli olabilir. Birbirini bozan, sürekli yeniden test isteyen değişiklikler ise aynı hacimde farklı bir sonuç üretir.

GitLab’ın aynı dönemde açıkladığı çalışma da bu açıdan dikkate değer. Şirket, Git uyumluluğunu koruyarak sunucu mimarisini ve ajanların veri erişimini geliştiren yeni kaynak kontrol altyapısını özel beta aşamasında sunduğunu belirtiyor. Böylece sektörün önünde farklı geçiş yolları bulunduğunu görüyoruz. GitLab’ın açıklaması

Ben kurumsal bir ekip için karar verecek olsam önce darboğazın ölçümünü isterim. Mevcut Git sunucusunun, runner yapısının, önbelleklerin ve pipeline tasarımının hangi noktada yetersiz kaldığını görmeden altyapıyı değiştirmek istemem. Yeni sistemin performans kazancıyla birlikte yedekleme, felaket kurtarma, erişim yönetimi, araç entegrasyonu ve bakım maliyetini de hesaba katarım.

Anthropic de Scion’u genel kullanım için uygun bir Git ikamesi olarak konumlandırmıyor; çözümün devasa depolar ve yoğun ajan iş yükleri için tasarlandığını açıkça söylüyor. Scion’un kullanım sınırları

Bu örnekten çıkardığım mühendislik dersi, kullandığımız araçların varsayımlarını düzenli olarak yeniden değerlendirmek. Kullanıcı profili, işlem hacmi ve erişim biçimi değiştiğinde yıllardır doğru çalışan bir mimarinin maliyet dengesi de değişebilir.

Benim için iyi bir AI geliştirme altyapısının başarısı, daha fazla kod üretebilmenin yanında o kodun gerekçesini anlayabilmek, doğruluğunu sınayabilmek ve etkisini güvenle yönetebilmekle ölçülür. Scion’u ilginç bulmamın nedeni de kaynak kontrolünü bu daha geniş sürecin içinde yeniden düşünmeye zorlaması.