Anthropic Bangun Scion: Sistem Version Control Sendiri untuk 30.000 Merge per Hari

Anthropic membangun sistem version control sendiri bernama Scion dan memindahkan seluruh monorepo-nya dari git dalam lima bulan. Alasannya ada di angka: pada Mei 2026 mereka rata-rata melakukan sekitar 2.500 merge kode per hari, dan pada September angka itu melonjak menjadi lebih dari 30.000 merge per hari. Menurut tulisan di blog engineering mereka, source control berubah dari alat pendukung menjadi bottleneck terbesar pengembangan begitu agen AI menulis kode jauh lebih cepat daripada kemampuan manusia meninjaunya.

TL;DR

• Anthropic membangun Scion, sistem version control in-house, dan memigrasikan monorepo dari git dalam lima bulan.
• Merge kode naik dari sekitar 2.500 per hari pada Mei 2026 menjadi lebih dari 30.000 per hari pada September 2026.
• Sejarah branch utama saja hampir 100 GB, dan salinan kerja terkompresi lebih dari 25 GB.
• Ada sekitar 25 juta checkout kode per hari untuk CI; kalau diambil naif, itu lebih dari 600 PB trafik git per hari.
• Pada puncaknya Anthropic mengoperasikan beberapa ratus mirror git internal untuk menahan beban.

Kenapa git tidak lagi cukup untuk monorepo Anthropic?

Karena git dirancang untuk kerja terdistribusi dan offline, sementara hampir semua klien Anthropic adalah agen dan job yang selalu online. Git mengasumsikan setiap klon adalah repositori lengkap yang bisa menghitung diff, membaca sejarah, dan checkout revisi apa pun tanpa jaringan. Asumsi itu justru menjadi beban ketika repositori tumbuh besar dan jumlah klien meledak.

Angka-angkanya menunjukkan tekanannya. Sejarah branch utama mereka saja hampir 100 GB, dan salinan kerja terkompresi lebih dari 25 GB. Untuk CI saja, mereka melakukan sekitar 25 juta checkout kode per hari. Kalau setiap checkout mengambil data secara naif, totalnya bisa melewati 600 PB trafik git per hari, angka yang tidak masuk akal untuk dioperasikan.

Git sebenarnya menyediakan jalan keluar untuk sebagian masalah ini, seperti shallow clone, sparse checkout, dan promisor remote. Anthropic memakai semuanya, plus mirror git internal dan snapshot repositori di penyimpanan blob. Pada puncaknya mereka mengoperasikan beberapa ratus mirror internal. Cara-cara itu membeli waktu, tetapi makin sulit dirawat seiring naiknya laju merge, karena snapshot makin jauh dari ujung branch utama dan operasi yang bergantung sejarah seperti diff dan blame makin rapuh.

Apa itu Scion dan bagaimana ia berbeda dari git?

Scion adalah sistem version control yang dirancang dengan asumsi klien selalu online dan bisa menghubungi server kapan saja. Kalau git memberi setiap klien salinan lengkap supaya bisa bekerja offline, Scion justru membangun protokol client-server dengan asimetri: klien mengambil data hanya saat dibutuhkan dari server yang selalu tersedia. Dengan begitu, pertumbuhan repositori tidak lagi berarti setiap klien harus menanggung ukurannya.

Anthropic menyebut mereka belajar dari prior art monorepo besar, terutama Google Piper dan Meta Sapling. Dari sana mereka mengambil pelajaran yang sudah teruji dan menyesuaikannya untuk beban kerja yang didominasi agen. Selain Scion, mereka juga membangun permukaan tinjauan kode bernama Antique, pencarian kode, sistem IAM untuk source control, dan cara baru mengelola serta mendaratkan kode dalam jumlah besar, semuanya dalam periode yang sama.

Yang menarik, alat yang memicu masalah ini sekaligus menjadi solusinya. Claude yang menulis kode dalam jumlah besar itulah yang membuat git kewalahan, dan Claude pula yang membantu mereka membangun sistem pengganti berkualitas tinggi dalam waktu singkat. Menurut tulisan itu, kode kini bukan lagi bottleneck di Anthropic; yang tersisa adalah infrastruktur pengembangan yang dibangun untuk skala manusia.

Apa pelajaran yang bisa diambil tim lain?

Pelajaran pertamanya soal urutan bottleneck. Selama bertahun-tahun, menulis kode dianggap bagian paling lambat dalam pengembangan software. Ketika agen AI menulis kode jauh lebih cepat, bottleneck berpindah ke infrastruktur di sekitarnya: tinjauan kode, build, CI, dan source control. Tim yang mengadopsi coding agent cepat akan menabrak dinding yang sama, hanya saja pada skala yang lebih kecil.

Pelajaran kedua soal kapan harus membangun sendiri. Anthropic tidak langsung menulis sistem version control baru; mereka lebih dulu memakai semua trik untuk memperpanjang umur git, termasuk ratusan mirror internal. Keputusan membangun Scion diambil setelah cara-cara itu tidak lagi cukup, bukan sebagai langkah pertama. Untuk hampir semua organisasi, membangun sistem version control sendiri masih berlebihan, dan pelajaran yang lebih berguna adalah mengenali tanda kapan tool yang ada sudah menyerah.

Pelajaran ketiga soal desain ulang asumsi. Git mengasumsikan klien bisa offline, dan asumsi itu benar untuk sebagian besar repositori di dunia. Scion menang dengan membalik asumsi itu karena kondisi Anthropic memang berbeda: hampir semua kliennya online. Intinya bukan bahwa git salah, melainkan bahwa asumsi yang benar di satu konteks bisa menjadi beban di konteks lain.

Aspek	Git	Scion
Asumsi klien	Bisa offline, punya salinan lengkap	Selalu online, ambil data saat perlu
Model	Terdistribusi, setiap klon setara	Client-server dengan asimetri
Cocok untuk	Repositori umum, kerja offline	Monorepo raksasa dengan klien agen
Beban per klien	Menanggung ukuran repositori	Hanya data yang dibutuhkan
Contoh lain	Standar industri	Google Piper, Meta Sapling

Apakah ini relevan untuk tim kecil?

Belum, dan Anthropic sendiri mengakui hal itu. Mereka menyebut beban kerja mereka tidak biasa karena memakai Claude untuk menulis software jauh lebih banyak daripada hampir semua perusahaan lain, sehingga sering menjadi yang pertama merasakan titik ketika tool skala manusia mulai jebol. Untuk tim kecil, git masih jauh lebih dari cukup.

Meski begitu, arahnya layak diperhatikan. Anthropic memperkirakan tidak butuh waktu lama sebelum organisasi lain yang memakai tool coding AI merasakan tekanan serupa. Kalau timmu mulai melihat CI melambat, jumlah merge naik cepat, dan waktu checkout membengkak, itu tanda awal yang sama dengan yang mereka alami, hanya dalam skala lebih kecil. Menyadari tanda itu lebih berguna daripada langsung meniru solusinya.

Yang bisa ditiru sekarang bukan Scion-nya, melainkan kebiasaan mengukur. Anthropic tahu persis berapa merge per hari, berapa checkout, dan berapa besar repositori mereka, karena angka-angka itulah yang menunjukkan kapan sebuah tool sudah menjadi bottleneck. Tim yang mengukur hal serupa akan tahu kapan harus mengubah proses, jauh sebelum perlu memikirkan membangun sistem sendiri.

Apa saja yang dibangun Anthropic selain Scion?

Selain Scion, mereka membangun dan merilis beberapa komponen pendukung dalam periode yang sama. Ada permukaan tinjauan kode bernama Antique, sistem pencarian kode, sistem IAM khusus untuk source control, serta cara-cara baru untuk mengelola dan mendaratkan kode dalam jumlah besar yang sudah ditinjau. Semua itu dibangun dalam rentang lima bulan yang sama dengan migrasi monorepo.

Keberadaan komponen-komponen itu menunjukkan bahwa masalahnya bukan sekadar kecepatan checkout. Ketika laju merge naik lebih dari sepuluh kali, setiap bagian dari alur kerja ikut tertekan. Tinjauan kode yang biasanya dilakukan manusia perlu disesuaikan supaya bisa menangani volume besar, dan sistem izin akses perlu dirancang ulang agar tetap aman saat jumlah perubahan dan klien tumbuh cepat.

Anthropic menyebut bahwa kode bukan lagi bottleneck di perusahaan mereka. Kalimat itu penting karena menggeser pertanyaan dari bagaimana menulis kode lebih cepat menjadi bagaimana membangun infrastruktur yang mampu menampung kode yang sudah ditulis. Untuk organisasi yang baru mulai memakai coding agent, urutan masalahnya kemungkinan akan sama: kode dulu, lalu tinjauan, lalu build dan CI, dan akhirnya source control.

Bagi tim yang ingin bersiap, langkah paling praktis bukan membangun sistem baru, melainkan mengukur. Catat berapa merge per hari, berapa lama CI berjalan, dan berapa besar repositori. Angka-angka itu akan menunjukkan bagian mana yang lebih dulu menjadi penghambat, dan memberi waktu untuk memutuskan apakah cukup mengoptimalkan tool yang ada atau memang perlu pendekatan yang berbeda.

Apa risiko membangun sistem version control sendiri?

Risikonya besar dan sering diremehkan. Source control adalah fondasi yang disentuh setiap hari oleh setiap pengembang dan setiap job otomasi, jadi bug di lapisan ini bisa melumpuhkan seluruh alur kerja. Migrasi yang gagal berisiko membuat kode tidak bisa diakses, sejarah hilang, atau alur tinjauan macet, dan biaya pemulihannya jauh lebih besar daripada membangunnya.

Risiko kedua soal perawatan jangka panjang. Sistem buatan sendiri harus terus dikembangkan seiring kebutuhan berubah, dan itu berarti tim yang membangunnya tidak bisa lepas tangan setelah migrasi selesai. Anthropic menyebut mereka membangun banyak komponen pendukung sekaligus, dan itu menggambarkan beban perawatan yang menyertai keputusan ini.

Karena itu, membangun sistem version control sendiri hanya masuk akal kalau kamu sudah menabrak batas tool yang ada, seperti yang dialami Anthropic setelah mencoba semua cara memperpanjang umur git. Untuk hampir semua tim, memilih alternatif yang sudah matang jauh lebih murah daripada membangun dan merawat sistem baru yang harus tetap andal setiap hari.

Kalau kamu ingin tahu kapan saatnya berpikir ke arah itu, ukur dulu bebannya. Selama git masih bisa dioptimalkan dengan shallow clone, sparse checkout, dan mirror, belum ada alasan untuk membangun sendiri. Tandanya adalah ketika cara-cara itu tidak lagi cukup meski sudah dipakai semua, persis seperti yang Anthropic alami sebelum memutuskan pindah.

FAQ

Apakah Anthropic meninggalkan git sepenuhnya?

Ya, untuk monorepo utama mereka. Tulisan resminya menyebut monorepo itu dimigrasikan penuh dari git ke Scion dalam lima bulan, meski proyek lain di luar monorepo bisa saja masih memakai git.

Berapa lama migrasinya?

Sekitar lima bulan, menurut tulisan blog engineering Anthropic. Dalam periode yang sama mereka juga membangun permukaan tinjauan kode, pencarian kode, sistem IAM, dan cara baru mengelola kode dalam jumlah besar.

Apakah Scion tersedia untuk umum?

Belum ada indikasi bahwa Scion dirilis sebagai produk atau proyek open source. Tulisan itu berfokus pada apa yang mereka bangun dan pelajaran yang didapat, bukan pada rencana distribusi.

Kalau begitu, apa yang bisa saya pakai sekarang?

Untuk monorepo besar, Meta Sapling adalah alternatif yang sudah open source dan bisa dicoba. Untuk sebagian besar tim, git dengan shallow clone, sparse checkout, dan mirror internal masih cukup, seperti yang juga dipakai Anthropic sebelum pindah.

Apakah masalah ini akan menimpa semua tim yang pakai AI coding?

Tidak semua, tetapi trennya jelas. Anthropic menyebut beban mereka tidak biasa, namun memperkirakan organisasi lain yang memakai tool coding AI akan mengalami titik tekanan serupa, hanya saja pada skala yang lebih kecil dan waktu yang lebih lama.

Tulisan lengkap soal arsitektur Scion ada di blog engineering Anthropic. Untuk membandingkan dengan alternatif yang sudah matang, Meta menyediakan Sapling dengan kode sumbernya di GitHub. Latar belakang mengapa monorepo raksasa menuntut pendekatan berbeda pernah dibahas panjang di Communications of the ACM, dan bacaan itu masih relevan untuk memahami kompromi yang diambil sistem seperti Scion.

Rekomendasi Tools & Layanan

Beberapa layanan yang dipake di panduan ini: free trial Alibaba Cloud (coba gratis, sesuaikan kebutuhan), dan halaman promo terbaru buat cek diskon yang lagi jalan bulan ini.