Anthropic Mengganti Git dengan Scion: Apa yang Berubah di Source Control Skala Agent

Pada 13 Oktober 2026 blog engineering Anthropic menerbitkan Redesigning source control at Anthropic, dan dalam sehari satu angka ada di mana-mana: 30.000 merge per hari. Post di X yang paling jauh menyebar merangkumnya dalam satu kalimat, “anthropic getting bottlenecked by git so they wrote their change-list based version control system called scion”. Angka yang membuat saya berhenti ada dua paragraf di bawahnya: sekitar 25 juta checkout CI per hari, sebelum satu pun developer environment, agent sandbox, atau research job menyentuh repository itu.

Tulisan ini membaca sumber primernya dengan teliti, memakai enam figure milik Anthropic sendiri, lalu mencocokkannya dengan lima liputan, dokumentasi protokol git, dan thread Hacker News yang berisi lebih dari 600 komentar. Saya menjalankan agent Claude Code secara headless di repository saya sendiri, jadi saya membacanya untuk mencari apa yang berubah bagi tim yang tidak akan pernah me-merge 30.000 perubahan per hari. Setiap angka Scion di bawah ini dilaporkan oleh perusahaannya sendiri, dan belum ada yang diverifikasi secara independen.

Angka yang membuat git kewalahan: merge adalah write, checkout adalah read

Figure pertama Anthropic sudah menceritakan sebagian besar kisahnya. Monorepo itu me-merge sekitar 1.000 perubahan per hari pada Januari, sekitar 2.500 pada Mei, dan memuncak di 30.401 pada 9 September. Perubahan warnanya sama pentingnya dengan tingginya: pull request berwarna biru tergantikan oleh change request oranye di Antique, tool code review yang dibangun Anthropic bersamaan dengan Scion, sepanjang Juni dan Juli. Pada Agustus hampir semua perubahan yang di-merge sudah lewat sistem baru itu.

Yang jadi headline adalah laju merge, tetapi pendorong biayanya ada di sisi read. History branch main hampir 100 GB, dan satu working copy yang terkompresi lebih dari 25 GB. Anthropic menghitung sekitar 25 juta checkout CI per hari dan menulis bahwa “fetched naively, that would be over 600 PB of git traffic per day.” Angka itu bukan hiperbola. 600 PB dibagi 25 juta hasilnya 24 GB, hampir persis satu working copy terkompresi untuk setiap checkout.

Write dan read juga saling memperbesar. Dengan 30.000 merge per hari, main bergerak kira-kira setiap tiga detik, sehingga salinan repository mana pun yang di-cache sudah basi hampir begitu selesai di-refresh, dan setiap job yang butuh tip main harus mengambil selisihnya. Kalimat pembuka Anthropic adalah tesis seluruh tulisannya: “At Anthropic, coding is no longer the bottleneck to building systems or doing research.” Yang menjadi bottleneck justru infrastruktur yang memindahkan kode ke sana kemari.

Yang dicoba Anthropic lebih dulu: playbook standar untuk menskalakan git

Sebelum membangun apa pun, Anthropic menjalankan playbook yang akan dikenali setiap perusahaan dengan git berskala besar: shallow clone, sparse checkout, promisor remote untuk partial clone, mirror git internal, dan seed snapshot yang disimpan di blob storage supaya node baru langsung mulai dalam keadaan hangat. Di puncaknya mereka menjalankan beberapa ratus mirror. Ini playbook tersebut dalam bentuk command, yang sama dengan yang akan saya pakai untuk repository besar hari ini.

# The standard git scaling playbook. Every line still assumes the client
# is a full git peer that merely holds less of the repository.

# Shallow: truncate history. Cheap to clone, but blame and log stop early.
git clone --depth=1 https://git.example.com/monorepo.git

# Partial (blobless): fetch commits and trees, defer file contents.
# The server becomes a "promisor remote" that sends missing blobs on demand,
# and git fetches them one object at a time when a command trips over one.
git clone --filter=blob:none --sparse --no-checkout \
  https://git.example.com/monorepo.git
git -C monorepo sparse-checkout set services/billing libs/shared
git -C monorepo checkout main

# Seeds: start new nodes from a bundle in blob storage, then fetch the delta.
# The delta grows with every merge since the bundle was cut.
git clone --bundle-uri=https://blobs.example.com/seeds/monorepo.bundle \
  https://git.example.com/monorepo.git

# Mirrors: replicate the whole repository closer to the jobs reading it.
git clone --mirror https://git.example.com/monorepo.git /srv/mirror.git
git -C /srv/mirror.git remote update --prune

Setiap teknik itu berhasil, dan setiap teknik itu membawa asumsi yang sama: client tetap peer git yang lengkap, hanya saja menyimpan lebih sedikit. Anthropic menyebut dua titik di mana asumsi itu patah. Seed makin jauh tertinggal dari main di antara dua refresh seiring laju merge naik, dan diff serta blame di partial clone makin sulit dijaga agar tetap jalan. Dokumentasi partial clone milik git sendiri menjelaskan yang kedua. Dynamic fetching memanggil fetch-pack sekali untuk setiap item yang hilang dan cenderung lambat karena object datang satu per satu. Blame menelusuri history dan butuh versi lama sebuah file, yang di blobless clone justru object yang tidak ada.

Diagnosisnya: git itu terdesentralisasi, client Anthropic tidak pernah begitu

Kalimat yang menjadi pangkal seluruh desainnya ada di bagian pertumbuhan tulisan itu: Anthropic “using git as a centralized system with one authoritative copy”, sementara hampir semua client-nya adalah agent atau job yang selalu online. Model git yang offline-first, di mana setiap clone adalah peer lengkap, adalah fitur bagi maintainer yang bekerja di kereta. Bagi agent di sandbox yang hidup dua puluh menit, itu biaya yang dibayar setiap kali ia mulai. Anthropic menyebut Piper milik Google dan Sapling milik Meta sebagai prior art, dan deskripsi change-list di X menunjuk ke garis keturunan yang sama: unit perubahan yang disimpan di server pusat, bukan snapshot yang disalin ke setiap client.

Baca kolom kanan dari atas ke bawah dan satu aturan muncul dengan sendirinya, yang dirumuskan Developers Digest paling baik: anggap client selalu online, lalu tanya server. Setiap baris memindahkan pekerjaan dan state dari banyak client ke satu service. Itulah trade-off yang sengaja dihindari git sejak 2005, dan trade-off itu baru menguntungkan kalau client-nya adalah mesin yang tidak pernah offline.

Isi Scion: changeset di dalam log, tree diturunkan saat dibutuhkan

Unit kerja Scion adalah changeset, sebuah entry di write-ahead log. Commit git menunjuk ke sebuah tree, snapshot lengkap repository pada saat itu. Changeset Scion justru mendaftar file yang berubah relatif terhadap parent pertamanya, masing-masing dengan pointer content-addressed ke blob terkompresi. Figure Anthropic memperlihatkan pembagiannya: metadata di Spanner, isi file di Cloud Storage, immutable dan di-deduplikasi berdasarkan hash.

Ini pembalikan yang patut diperhatikan. Git menyimpan snapshot dan menghitung diff; Scion menyimpan diff dan menghitung snapshot, menurunkan root tree dan directory tree di server ketika ada yang memintanya. Mencatat perubahan hanya terhadap parent pertama, menurut Anthropic sendiri, adalah pilihan gaya: dalam trunk-based development orang kebanyakan peduli pada history di sepanjang trunk. Perbedaannya paling mudah dilihat berdampingan.

# git: a commit names a complete tree. The diff is computed when asked.
$ git cat-file -p HEAD
tree e3a1c07f...            # a snapshot of the entire repository
parent 9a1f03b2...
author Jane Dev <jane@example.com> 1757899509 +0000
committer Jane Dev <jane@example.com> 1757899509 +0000

fix: retry blob fetch on timeout

# Scion: a changeset names only what changed against its first parent.
# Fields as drawn in Anthropic's "Shape of a Scion changeset" figure.
changeset      9f2c...7ab0
parents        d41c...88e2
author         Claude <noreply@anthropic.com>
committer      Scion <noreply+scion@anthropic.com>     # optional
message        scion-cache: serve blobs from the memory tier
file_changes
  docs/guide.md    3e1f...a2c4    regular file
  src/legacy.rs    deleted
  tools/build.sh   9b07...5d18    executable

# No tree field. The root tree (5c0e...d1a9) is derived by the server
# when a client asks for it, and file contents live in Cloud Storage,
# immutable and deduplicated by hash.

Sisanya, termasuk blame, path history, dan skip list commit graph, adalah derived data yang dibangun oleh satu mekanisme generik. Setiap nilai didefinisikan secara rekursif dari nilai parent-nya dan bisa dihitung di awal atau ditunda. Anthropic kemudian menambahkan index copy detection dan pencarian file berbasis path dengan cara yang sama, tanpa client menyadarinya. Ref berada sepenuhnya di luar jalur utama: membuat dan mengambil commit tidak pernah menyentuhnya, dan alasan yang ditulis cukup lugas, “global state that every server has to agree on is a looming scaling problem.”

Jalur checkout: tiga tier yang menjawab RPC yang sama

Dalam negosiasi fetch git, seperti dijelaskan dokumentasi protocol v2, client mengirim baris have untuk object yang sudah ia punya dan baris want untuk yang ia butuhkan, lalu server menjawab dengan packfile yang dibangun khusus untuk percakapan itu. Scion membalik percakapannya. Client tidak menjelaskan apa yang ia punya. Ia menyebut tree dan blob yang ia mau, mulai dari root tree, lalu meminta object yang belum ada secara rekursif. Tidak ada packfile berukuran gigabyte, jadi transfer bisa dilanjutkan kalau terputus, dan sparse checkout maupun virtual checkout tidak butuh dukungan khusus: client cukup tidak pernah meminta tree yang tidak ia perlukan.

Figure itu memisahkan control plane dari object plane. Branch, history, dan diff langsung menuju scion-server untuk setiap client. Tree dan isi file mengalir lewat cache: scion-daemon di setiap node, dipakai bersama oleh semua job di node itu dan diisi dari snapshot berkala, lalu scion-cache regional yang men-stream object dari memori dalam format disk milik daemon, lalu scion-server yang membaca dari Spanner atau Cloud Storage. Ketiga tier menjawab RPC yang sama, jadi client tidak bisa tahu sedang bicara dengan yang mana.

Dua sifat membuat sistem ini murah dijalankan. Object yang content-addressed tidak pernah berubah, jadi tier mana pun bisa meng-cache-nya tanpa koordinasi dan tidak ada yang perlu di-invalidate. Selain itu tiering-nya ditegakkan secara ketat, sehingga cache regional yang gagal tidak bisa membanjiri server di atasnya. Anthropic melaporkan hit rate di atas 99% di setiap tier, tanpa state berumur panjang di satu pun.

Hasilnya, command demi command

Hasil utama yang dilaporkan Anthropic adalah footprint CPU dan memori sekitar 200x lebih kecil dibanding armada mirror git, checkout CI dan research dua orde magnitudo lebih cepat, dan tambahan kapasitas CPU 25% untuk CI saja. Bukti yang lebih berguna adalah grafik waktu median per command. Bagian agent dan CI ditampilkan di bawah, dan tabelnya memuat setiap baris dari grafik aslinya.

Pola di tabel itu adalah prinsip desainnya yang terlihat. Kemenangan terbesar ada di operasi yang biayanya di git tumbuh mengikuti ukuran repository: status di mesin developer (×207), di mana git memeriksa seluruh working tree sementara client Scion mengawasi filesystem, dan worktree agent yang baru (×84). Yang terkecil adalah commit developer (×1,3), yang di git memang sudah sebanding dengan ukuran perubahannya. Scion tidak membuat semuanya cepat. Scion membuat setiap operasi berbiaya sebesar perubahannya.

Anotasinya juga cocok dengan bagian lain tulisan itu, dan itu pertanda baik. Menghemat 27,5 detik untuk masing-masing dari 25 juta checkout CI per hari hasilnya sekitar 191.000 jam, dekat dengan ≈195.000 machine hours per hari di grafik. Menghemat 30 menit per change request terhadap ≈11.000 agent hours per hari berarti kira-kira 22.000 change request per hari, satu orde dengan grafik merge. Semua ini tetap median milik Anthropic sendiri. explainx dan Developers Digest sama-sama mengingatkan bahwa belum ada yang diaudit secara independen, dan angka 200x diukur terhadap armada mirror yang tidak pernah dibangun oleh kebanyakan tim.

Tanpa global merge lock, review berbasis intent, dan Claude di dalam tim

Keputusan yang paling diperdebatkan sama sekali tidak ada di dalam Scion. Anthropic menulis bahwa merge queue yang semestinya “doesn't make much sense at agent scale”. Ratusan sampai ribuan perubahan bisa masuk selama satu test run berjalan, dan tim itu tidak berhasil mereplikasi standar industri berupa global repository lock. Mereka berinvestasi di testing setelah merge dan sebelum deploy, dan menerima bahwa perubahan yang berjalan bersamaan kadang akan conflict, karena “Claude can typically fix these conflicts faster than humans can even identify them.”

Bentuk review ikut berubah. Engineer tetap me-review setiap change request, tetapi untuk intent-nya, bukan setiap baris, dan semantic approval rule bisa memisahkan perubahan yang hanya menyentuh komentar dari perubahan yang menyentuh logika sensitif. Claude yang masing-masing fokus pada satu komponen, yang oleh tim disebut superfan, mengawasi telemetry dan log untuk scion-daemon, scion-cache, dan merge queue Antique, berdampingan dengan alert biasa. Pekerjaan engineer yang paling sering, menurut mereka sendiri, adalah bilang “tidak” ke Claude: ketika ia membaca commit log untuk mencari tahu apakah sebuah perubahan sudah di-merge alih-alih bertanya ke tool review, atau ketika adversarial review mendorong validasi defensif terhadap service internal yang sebenarnya sudah dipercaya.

Thread itu layak dibaca untuk argumen tandingannya. Satu komentator memperkirakan sekitar sepuluh pull request per engineer per hari dan bilang Anthropic sudah “crossed the rubicon of not gating PRs on tests”. Komentator lain berargumen bahwa perusahaan era Perforce melayani puluhan ribu engineer dan bahwa “30k CLs per day isn't much.” Kedua poin itu wajar, dan tidak ada yang menyentuh klaim yang lebih sempit: pada laju ini, desain apa pun yang menserialisasi merge di belakang test run penuh akan tertinggal. Rangkuman AI Weekly mencatat bahwa The Register membingkai para engineer sebagai penjaga gerbang, bukan penulis kode, dan itu dekat dengan cara tulisan Anthropic sendiri menggambarkan pekerjaannya.

Claude juga membangun sebagian besar sistem yang sedang ia lampaui. Direktori scm dan antique menerima 12.257 perubahan antara Januari dan September, untuk tim berisi tujuh orang. Ketika snapshot internal awal Claude Mythos Preview diminta menulis ulang pipeline ingestion git-ke-Scion yang ditulis tangan, tanpa instruksi tambahan, hasilnya memakai memori 20x lebih sedikit, berjalan 4x lebih cepat, dan tetap menjaga invariant urutan yang implisit. Para engineer bilang mereka sekarang menilai Claude lebih baik dalam menulis kode daripada diri mereka sendiri, dan menyebut Scion salah satu codebase dengan testing terbaik yang pernah mereka kerjakan, berkat hermetic simulation, fuzzing, dan rate limiting.

Apa yang layak ditiru kalau kalian tidak akan pernah me-merge 30.000 perubahan per hari

Anthropic menyatakan dengan jelas bahwa “Scion is by no means a suitable replacement for git for general use.” Scion hanya masuk akal untuk monorepo yang sangat besar dengan puluhan ribu engineer atau kawanan agent yang besar, belanja token internal perusahaan itu bukan sesuatu yang akan dipilih kebanyakan bisnis, dan mengadopsinya berarti ikut memigrasikan code review, search, dan CI. Tidak ada rilis yang bisa diunduh, apa pun kesan yang ditimbulkan sebagian headline. Ringkasan AI TLDR menyebut audiens yang tepat, yaitu engineer platform dan developer infrastructure, yang bisa meminjam commit di sisi server dan fetching sesuai kebutuhan tanpa kodenya. Sebagian besar idenya bisa dipakai di git biasa hari ini.

1. Ukur dulu sebelum mengubah apa pun. Catat waktu untuk worktree agent yang baru, status, dan pull di repository terbesar kalian. Tes dari Developers Digest adalah yang tepat: kalau checkout agent sudah selesai dalam hitungan detik, masalah Scion belum jadi masalah kalian.
2. Beri setiap agent blobless clone yang sparse dan worktree-nya sendiri, memakai command di playbook di atas, supaya ia membayar untuk direktori yang ia sentuh saja, bukan untuk seluruh history.
3. Jawab pertanyaan tentang repository di server. Job yang hanya butuh diff, merge base, atau isi file di sebuah commit bisa bertanya ke API forge kalian alih-alih melakukan clone, dan itu versi murah dari prinsip service milik Scion.
4. Jaga jumlah ref tetap sedikit. Branch berumur pendek per agent tidak masalah, tetapi dokumentasi partial clone git mencatat jumlah ref yang besar sebagai sumber overhead yang signifikan di setiap koneksi, dan armada agent melipatgandakan ref dengan cepat.
5. Naikkan review manusia satu level sebelum volume memaksa kalian. Tentukan path mana yang butuh review baris per baris dan mana yang bisa disetujui berdasarkan intent ditambah test yang hijau, lalu tuliskan aturannya di tempat yang dibaca manusia dan agent.

# 1. Measure what an agent pays for source control before it writes a line.
#    If all three finish in seconds, Scion's problem is not yours yet.
time git worktree add ../agent-1 -b agent/1 origin/main
time git -C ../agent-1 status
time git -C ../agent-1 pull --rebase origin main

# 2. Ask the server instead of cloning. A job that only needs to know what
#    changed can read it from the forge's API with no local repository:
#    GitHub's "compare two commits" endpoint takes BASE...HEAD.
gh api repos/acme/monorepo/compare/main...agent/1 \
  --jq '.files[] | [.status, .filename] | @tsv'

# 3. Keep refs few. Every fetch has to reckon with them; count before
#    an agent fleet multiplies them.
git ls-remote --heads origin | wc -l

Dua catatan sebelum kalian membawa semua ini ke rapat perencanaan. Seperti ditunjukkan explainx, tulisan itu menggambarkan sebuah keberhasilan dan hampir tidak bercerita soal pendekatan yang gagal atau insiden migrasi, jadi anggap lima bulan itu sebagai versi yang berhasil. Selain itu, hal-hal yang diminta Anthropic dari komunitas git kemungkinan besar adalah jalur yang membawa semua ini ke kita semua: RPC sisi server yang lengkap dan bisa distandarkan oleh forge, protokol negosiasi yang baru, serta fitur sparse dan shallow yang bisa dikombinasikan dengan baik. Jalur itu lewat GitHub, GitLab, dan git sendiri, bukan lewat Scion.

Pelajaran yang bertahan dari Scion bukan bahwa git gagal. Pelajarannya adalah asumsi paling mendasar git, yaitu client sebagai peer yang lengkap dan mandiri, berhenti cocok dengan siapa client-nya. Ketika sebagian besar pembaca sebuah repository adalah agent yang selalu online, desain paling murah menyimpan state di server, menyebut konten lewat hash supaya setiap cache bisa melayaninya, dan membuat setiap operasi berbiaya sebesar perubahannya. Ukur berapa yang dibayar agent kalian untuk source control sebelum merencanakan apa pun berdasarkan angka milik orang lain.