Günde 30.000 merge: Anthropic neden git'i bırakıp kendi sürüm kontrol sistemi Scion'u yazdı?

Yapay zekanın yazılım geliştirmeye etkisini konuşurken genellikle modellerin ne kadar iyi kod yazdığına odaklanıyoruz. Anthropic'in 13 Ekim 2026'da mühendislik blogunda yayımladığı "Redesigning source control at Anthropic" yazısı ise bambaşka bir soruyu öne çıkarıyor: Kod yazmak artık darboğaz değilse, darboğaz nerede?

Anthropic'in cevabı net: Kaynak kontrolü. Şirket, monorepo'sunu git'ten tamamen çıkarıp kendi geliştirdiği Scion adlı sürüm kontrol sistemine taşıdığını açıkladı. Bu yazıda neler olduğunu, Scion'un git'ten nasıl ayrıştığını ve bunun bizim gibi "normal" ölçekte çalışan ekipler için ne anlama geldiğini ele alıyorum.

Rakamlar neden git'i zorladı?

Anthropic'in paylaştığı veriler, sorunun büyüklüğünü iyi anlatıyor:

• Monorepo'ya günlük birleştirilen değişiklik sayısı Mayıs 2026'da yaklaşık 2.500 iken Eylül'de 30.000'in üzerine çıkmış. Yani dört ayda on kattan fazla artış.
• Ana dal geçmişi yaklaşık 100 GB, sıkıştırılmış bir çalışma kopyası ise 25 GB'ın üzerinde.
• Yalnızca CI için günde yaklaşık 25 milyon checkout yapılıyor; geliştirici ortamları, ajan sandbox'ları ve araştırma işleri buna dahil değil.
• Şirketin hesabına göre bu hızda saf bir git fetch yaklaşımı günde 600 PB'ın üzerinde trafik demek.

Anthropic bu yükü bir süre bilinen yöntemlerle taşımaya çalışmış: shallow clone, sparse checkout, promisor remote'lar, yüzlerce iç git aynası (mirror) ve önceden hazırlanmış depo anlık görüntüleri. Ancak merge hızı arttıkça bu anlık görüntüler ana dalın gerisinde kalmış ve altyapıyı ayakta tutmak giderek zorlaşmış.

Burada kritik nokta şu: Bu artışın büyük kısmı insanlardan değil, yapay zeka ajanlarından geliyor. Yazıda, şirket içinde yeni Claude sürümlerinin ve ajan araçlarının kullanıma açılmasının hem Scion ihtiyacını büyüttüğü hem de Scion'un geliştirilmesini hızlandırdığı belirtiliyor.

Git'in tasarımı ile ajanların gerçekliği

Git, dağıtık ve çevrimdışı çalışmayı merkeze alan bir sistem. Her klon tam bir depodur; internet yokken de commit atabilir, geçmişi inceleyebilirsiniz. Bu, insan geliştiriciler ve açık kaynak dünyası için harika bir özellik.

Ancak Anthropic'teki istemcilerin neredeyse tamamı sürekli çevrimiçi ajanlar ve otomatik işler. Bir CI işi ya da kısa ömürlü bir ajan sandbox'ı için tüm geçmişi indirmek, tam olarak ihtiyaç duyulmayan bir yükü taşımak anlamına geliyor. Anthropic'in ifadesiyle git'in tasarımı bu ölçekte onların aleyhine çalışmaya başlamış.

Scion nasıl çalışıyor?

Scion, git'in varsayımlarını tersine çeviriyor. Öne çıkan tasarım ilkeleri şöyle:

• İstemci her zaman çevrimiçi: Veriler gerektiğinde sunucudan çekiliyor; tam bir yerel kopya yok.
• Ağır iş sunucuda: Geçmiş, blame, commit, merge ve rebase sunucu tarafında yapılıyor. İstemci sınırlı bir önbellek ve çalışma dosyalarını tutuyor.
• Push yok: Commit'ler doğrudan sunucuda oluştuğu için "gönderilecek" bir şey kalmıyor. Ana dal ve sürüm dalları dışında ref kullanımı teşvik edilmiyor.
• Programlanabilir API: Pek çok sorgu API üzerinden yanıtlanıyor; bu sayede birçok iş hiç yerel depo açmadan çalışabiliyor.
• Seyrek ve sanal çalışma kopyaları: CI, checkout yapmadan diff isteyebiliyor; sanal checkout'larda dosyalar ihtiyaç anında oluşturuluyor.

Mimari

Sistemin temel birimi changeset. Her changeset, ilk ebeveynine göre değişen dosyaları ve blob deposundaki sıkıştırılmış içeriklere işaret eden içerik adresli işaretçileri tutuyor. Ref güncellemeleri ise Google Spanner üzerindeki tek bir satırda compare-and-swap işlemiyle yapılıyor. Blame ve dosya geçmişi gibi "türetilmiş veriler" de changeset'lerden ortak bir mekanizmayla hesaplanıyor.

Katmanlar kabaca şöyle:

scn (istemci) -> scion-daemon (düğüm başına) -> scion-cache (bölgesel) -> scion-server (Spanner / bulut depolama)

İlginç bir ayrıntı: Git'teki pazarlıktan (negotiation) farklı olarak istemci, sunucuya elinde ne olduğunu söylemiyor. Kök ağaçtan başlayıp eksik ağaçları ve blob'ları tek tek istiyor. Her istek değişmez (immutable) bir nesneye ait olduğu için herhangi bir önbellek katmanı yanıt verebiliyor ve süreç kesintiye uğrarsa kaldığı yerden devam edebiliyor.

Sonuçlar

Anthropic'in açıkladığı kazanımlar dikkat çekici:

• Her önbellek katmanında isabet oranı %99'un üzerinde.
• CPU ve bellek kullanımı eski git aynası altyapısına göre yaklaşık 200 kat daha az.
• CI ve araştırma işlerinde checkout süresi dakikalardan saniyelere inmiş; yani iki mertebe hızlanma.
• Yalnızca CI tarafında %25 CPU kapasitesi kazanılmış.

Bir de ekip boyutu var: Scion'u, Antique adlı yeni kod inceleme aracını ve yarım düzine kadar yardımcı sistemi yedi kişilik bir ekip geliştirmiş ve geçişi beş ayda tamamlamış. Yazıya göre Claude, bu süreçte aktif rol oynamış; örneğin elle yazılmış bir git-Scion aktarım prototipini yeniden yazarak bellek kullanımını 20 kat azaltmış ve hızı 4 kat artırmış. Mühendislerin rolü ise giderek tasarım kararlarına ve Claude sistem kısıtlarını ihlal ettiğinde "hayır" demeye kaymış.

Bu, git'in sonu mu?

Hayır, ve bunu Anthropic de açıkça söylüyor. Scion'un genel amaçlı bir git alternatifi olmadığını, yalnızca çok büyük monorepo'larda anlam ifade ettiğini vurguluyorlar. Sınırlamalar da net:

• Scion git'ten ciddi biçimde ayrıştığı için benimsemek; kod inceleme, kod arama ve CI'ı da baştan kurmayı gerektiriyor.
• Trunk tabanlı geliştirmeyi varsayıyor; ağırlıklı olarak ana dal geçmişiyle ilgileniyor.
• Küresel bir merge kuyruğu kilidi olmadığı için eşzamanlı değişiklikler çakışabiliyor; Anthropic bunu birleştirme sonrası ve dağıtım öncesi testlerle yönetiyor.

Şirket Scion'u açık kaynak yapmayı planlamıyor. Bunun yerine tasarım fikirlerini paylaşıp sunucu tarafı RPC'ler ve yenilenmiş pazarlık mekanizması gibi parçaların git ekosistemine taşınması için GitHub, GitLab ve açık kaynak topluluğuyla çalışmak istediğini söylüyor.

Peki bizim için ne anlama geliyor?

Çoğumuzun günde 30.000 merge sorunu yok ve yakın zamanda olmayacak. Yine de bu yazıdan çıkarılacak birkaç pratik ders var:

1. Darboğaz kayıyor. Kod üretimi ucuzladıkça CI süresi, checkout maliyeti, test altyapısı ve kod inceleme kapasitesi asıl kısıt haline geliyor. Ekibinizde ajan kullanımı artıyorsa, önce CI kuyruğunuza ve runner maliyetlerinize bakın.
2. Bugünden kullanılabilecek araçlar var. git clone --filter=blob:none, sparse checkout ve shallow clone, CI'da checkout süresini kayda değer biçimde azaltabilir. Anthropic'in sonunda vazgeçtiği bu yöntemler, çoğu ekip için hâlâ fazlasıyla yeterli.
3. Ajanlar için ayrı bir istemci profili düşünün. İnsan geliştiriciyle kısa ömürlü bir ajan sandbox'ının ihtiyaçları farklı. Ajanlara tam depo yerine API üzerinden sorgu veya seyrek çalışma kopyası sunmak, ölçeklendikçe önem kazanacak.
4. Kod inceleme de yeniden tasarlanacak. Antique'in yorum değişikliklerini mantıksal değişikliklerden ayırabilmesi, insan inceleme kapasitesinin en değerli kaynak haline geldiğini gösteriyor.

Anthropic, bu tür sorunların önümüzdeki 6–12 ayda daha yaygın hale gelmesini beklediğini yazıyor. Bu tahminin ne kadar tutacağını zaman gösterecek, ama yön açık: Yapay zeka çağında geliştirici altyapısı, insan hızına göre değil ajan hızına göre tasarlanmak zorunda kalacak. Git yarın ortadan kalkmayacak; ancak GitHub ve GitLab'ın önümüzdeki dönemde sunucu tarafına daha fazla iş taşıyan özellikler getirmesi sürpriz olmaz.