Jawaban singkat: Anthropic Scion adalah sistem kontrol versi internal yang dikembangkan Anthropic setelah agen koding mendorong monorepo miliknya dari sekitar 2.500 merge per hari pada Mei 2026 menjadi lebih dari 30.000 per hari di bulan September. Scion menjalankan commit, merge, dan rebase di sisi server. Sistem ini bersifat internal, dan Anthropic menyatakan bahwa Scion bukan pengganti Git untuk penggunaan umum.
Apa yang dilakukan Anthropic dengan Scion, dan alasannya
Pada 13 Oktober 2026, tim rekayasa perangkat lunak Anthropic memublikasikan artikel Redesigning source control at Anthropic. Pernyataan pembukanya sangat lugas: “koding bukan lagi hambatan utama (bottleneck) dalam membangun sistem atau melakukan riset.” Hambatannya, tulis mereka, adalah “seluruh infrastruktur pengembang yang dirancang untuk skala manusia: kontrol versi, proses build, dan CI.”
Angka-angka yang ada menjelaskan alasannya. Pada Mei 2026, Anthropic melakukan merge sekitar 2.500 perubahan kode per hari. Pada bulan September, angkanya melonjak menjadi lebih dari 30.000. Itu adalah lonjakan dua belas kali lipat dalam empat bulan, dan Anthropic mengaitkannya dengan agen koding yang menulis kode tersebut.
Git mampu bertahan di skala manusia, tetapi kewalahan pada skala agen. Anthropic melaporkan sekitar 25 juta checkout CI per hari, riwayat cabang utama (main branch) mendekati 100 GB, dan beberapa ratus Git mirror internal pada puncaknya. Strategi fetch biasa bisa menghasilkan traffic Git lebih dari 600 PB per hari.
Maka, sebuah tim beranggotakan tujuh orang membangun Scion, alat peninjau kode (code review) bernama Antique, pencarian kode, serta sistem kontrol akses per direktori. Mereka memigrasikan monorepo tersebut dari Git dalam waktu lima bulan. Anthropic bahkan menggunakan Claude Mythos Preview untuk menulis ulang pipeline penyerapan (ingestion) dari Git ke Scion, dan hasilnya mengonsumsi memori 20 kali lebih hemat serta berjalan 4 kali lebih cepat.
Jika tim Anda menggunakan Claude Code, Codex, atau agen koding lainnya, artikel ini adalah gambaran awal dari bottleneck berikutnya yang akan Anda hadapi. Sharkly dirancang khusus untuk mengatasi masalah tersebut: menjaga pekerjaan agen, hasil, dan proses peninjauan tetap terpusat di Task bersama alih-alih tersebar di berbagai terminal.
Perbedaan Scion dengan Git
Git berasumsi bahwa setiap clone adalah salinan riwayat lengkap yang mandiri dan dapat bekerja secara offline. Scion berasumsi sebaliknya: klien selalu terhubung secara online dan hanya melakukan sedikit komputasi secara lokal.
| Git | Anthropic Scion | |
|---|---|---|
| Lokasi eksekusi commit, merge, dan rebase | Secara lokal, di laptop Anda | Di server |
| Data lokal | Riwayat lengkap | Cache objek terbatas, checkout sparse atau tervirtualisasi |
| Unit kerja | Commit yang menunjuk ke sebuah tree | Changeset dalam write-ahead log yang mencatat file-file yang diubah |
| Branch dan ref | Murah dan disarankan | Tidak disarankan, kecuali untuk branch main dan rilis |
| Fetch | Packfiles | Per objek (tree, lalu blob), tanpa pemeliharaan repositori |
| Bekerja offline | Bisa | Tidak |
| Klien utama | Manusia | Agen, CI, dan tugas riset |
Arsitekturnya memiliki tiga tingkatan: scion-daemon di setiap node, scion-cache per wilayah, dan scion-server otoritatif. CLI untuk klien adalah scn. Tingkat keberhasilan cache (cache hit rate) berada di atas 99% di setiap tingkatan.
Hasilnya sangat signifikan. Konsumsi CPU dan memori menjadi 200 kali lebih kecil dibandingkan konfigurasi Git mirroring lama. Proses checkout CI dan riset hanya memakan waktu beberapa detik alih-alih beberapa menit, dan CI memperoleh tambahan kapasitas CPU sebesar 25%.
Konsekuensi commit di sisi server
Commit di sisi server mengorbankan keunggulan utama yang membuat Git begitu populer: riwayat lokal lengkap yang bisa digunakan bekerja bahkan saat berada di pesawat tanpa internet. Anthropic menyatakannya secara terang-terangan: Scion “sama sekali bukan pengganti yang cocok untuk Git bagi penggunaan umum,” dan menyediakannya dalam bentuk yang bisa digunakan organisasi lain akan sangat sulit. Scion tidak dirilis ke publik, dan artikel tersebut juga tidak menyebutnya sebagai proyek sumber terbuka (open source).
Pengelolaan konkurensinya juga berbeda dari yang mungkin Anda bayangkan. Anthropic tidak menyusun setiap proses merge secara berurutan (serialize) di balik satu global lock. Perubahan yang berjalan bersamaan masih bisa memicu konflik, dan tim mendeteksinya melalui pengujian pasca-merge serta sebelum proses deploy.
Git untuk agen AI: pelajaran bagi tim tanpa Scion
Anda tidak akan mendapatkan Scion, dan Anda memang tidak membutuhkannya. Ukuran repositori Anda tidak mencapai 100 GB, dan Anda tidak menjalankan 25 juta checkout per hari. Bagian yang paling berguna dari artikel tersebut adalah pola masalahnya, yang akan muncul pada skala apa pun.
Ketika agen menulis kode, bottleneck bergeser ke tahap selanjutnya (downstream). Awalnya bergeser ke proses merging, lalu ke tahap peninjauan (review). Liputan DevOps.com dan artikel TechSpot sama-sama menggambarkan Scion sebagai infrastruktur yang berupaya mengejar laju output agen. Tim yang beranggotakan lima orang dan menjalankan sepuluh agen pun akan membentur dinding permasalahan yang sama dalam versi lebih kecil.
Anda pasti mengenali gejala-gejala ini:
- Dua agen mengedit file yang sama di siang hari yang sama dan Anda harus menyelesaikan konfliknya secara manual.
- Pull request menumpuk lebih cepat daripada kemampuan tim untuk meninjaunya.
- Antrean CI makin panjang setiap minggu, sementara agen terus bekerja dengan cepat.
- Tidak ada yang tahu agen mana yang mengubah kode apa, atau mengapa perubahan itu dilakukan.
- Branch dari hari Selasa menjadi berantakan saat di-rebase pada hari Jumat.
Anthropic mengatasi poin 1 dan 3 dengan infrastruktur baru. Namun, Anda dapat mengatasi kelima masalah tersebut menggunakan perbaikan proses dan fungsionalitas Git yang sudah Anda miliki saat ini.
Konflik merge agen koding: mengapa jumlahnya berlipat ganda
Konflik merge bertambah seiring tumpang tindihnya pekerjaan, bukan karena jumlah agen. Sepuluh agen yang mengerjakan satu tujuan luas akan terus-menerus menyentuh file yang sama. Sebaliknya, sepuluh agen yang mengerjakan sepuluh tugas terisolasi yang spesifik jarang mengalami benturan. Lingkup setiap tugas jauh lebih berpengaruh dibandingkan jumlah agen.
Branch yang berumur panjang memperparah situasi ini. Setiap jam branch dibiarkan terbuka, cabang utama (main) terus bergerak maju di bawahnya. Agen memperparah kondisi ini karena mereka membuka branch jauh lebih cepat daripada kemampuan manusia menutupnya. Artikel kami sebelumnya tentang berapa banyak hari kerja agen yang dapat ditinjau dalam satu hari kerja manusia menyajikan angka nyata dari ketimpangan tersebut.
Langkah yang bisa Anda ambil hari ini tanpa Scion
Kelima kebiasaan berikut sudah mencakup sebagian besar kebutuhan tim pada umumnya. Tak satu pun dari langkah ini memerlukan sistem kontrol versi baru.
Berikan worktree tersendiri untuk setiap tugas
Sebuah Git worktree adalah direktori kerja terpisah yang terhubung ke repositori yang sama. Menggunakan satu worktree per tugas memastikan dua agen tidak akan pernah menulis ke satu direktori secara bersamaan.
git worktree add ../tasks/COIN-212 -b agent/COIN-212 origin/main
cd ../tasks/COIN-212
# run the agent here, commit, push, open a PR
git worktree remove ../tasks/COIN-212
Kami membahas konfigurasinya dalam artikel Git worktrees for AI coding agents dan proses pembersihannya di managing worktrees without the cleanup pain.
Jaga tugas tetap kecil dengan cakupan yang jelas
Definisikan setiap tugas secara spesifik dengan menyebutkan file atau modul mana saja yang boleh dimodifikasi beserta pengujian yang membuktikan bahwa tugas tersebut selesai. Tugas yang menghasilkan diff ringkas dan mudah ditinjau akan dapat di-merge dengan lancar. Tugas yang hanya berbunyi “refaktor autentikasi” tidak akan demikian.
Gunakan merge queue sebelum branch main
Merge queue menguji setiap pull request terhadap commit terbaru di branch main beserta semua perubahan lain yang mengantre di depannya, lalu melakukan merge secara berurutan. Fitur merge queue di GitHub menyediakan fungsi ini untuk branch yang diproteksi. Ini adalah solusi versi tim kecil untuk mengatasi apa yang dihadapi Anthropic lewat pengujian pasca-merge: Anda tidak lagi mendapati kombinasi kode yang rusak setelah kode terlanjur di-merge.
Sertakan bukti konkret saat meninjau tugas
Sebuah diff kode saja tidak cukup memberi tahu reviewer apa instruksi yang diberikan kepada agen atau apa saja yang telah diuji olehnya. Peninjauan akan berjalan jauh lebih cepat jika permintaan, riwayat eksekusi, output pengujian, dan perbandingan diff berada di satu tempat yang sama. Baca selengkapnya tentang cara meninjau kode buatan AI dengan bukti di tingkat tugas dan mengapa peninjauan manusia menjadi bottleneck.
Wajibkan agen menunggu persetujuan
Biarkan agen melakukan riset, menulis kode, menguji, dan melaporkan hasilnya. Biarkan manusia yang menentukan arah, menyetujui tindakan berisiko, serta menerima hasil akhirnya. Agen yang berhenti dan menunggu persetujuan manusia sebelum melakukan merge hanya menyita waktu beberapa menit. Namun, agen yang langsung melakukan merge kode tanpa ditinjau ke branch main bisa menghabiskan waktu Anda seharian untuk perbaikan. Panduan kami tentang approval gates untuk agen koding menunjukkan di titik mana saja Anda perlu menempatkan jeda tersebut.
Peran Sharkly dalam alur kerja ini
Sharkly tidak menggantikan Git, dan tidak menyelesaikan konflik merge secara langsung. Agen Anda tetap melakukan commit ke repositori melalui layanan Git yang sudah Anda gunakan. Yang diatur oleh Sharkly adalah pengelolaan tugas di balik setiap commit tersebut.
Setiap pekerjaan agen direpresentasikan sebagai Task yang dilengkapi dengan Assignee, status, dan riwayat eksekusi. Agen berjalan di Computer milik Anda sendiri, memanfaatkan Claude Code, Codex, atau runtime lain yang Anda gunakan. Dalam mode Temporary, setiap Task mendapatkan direktori terisolasi, dan eksekusi berbasis repositori dapat menyiapkan worktree terpisah, sehingga Task yang berjalan bersamaan tidak akan menulis ke folder bersama yang sama.
Saat agen selesai bekerja, ia dapat membiarkan Task menunggu peninjauan manusia. Notifikasi tersebut akan masuk ke Inbox, di mana orang yang bertanggung jawab dapat membuka Task, membaca hasil dalam konteksnya, dan memutuskan untuk menerima, mencoba ulang, atau menugaskan kembali. Eksekusi Task beserta diskusi lanjutannya tercatat di timeline Task, sehingga papan kerja Anda berfungsi sebagai antrean peninjauan.
Kombinasi ini memadukan kebiasaan pengelolaan Git di atas dengan satu ruang terpusat untuk permintaan, eksekusi, bukti, dan pengambilan keputusan. Jika Anda sedang membandingkan berbagai opsi, rangkuman alat untuk mengelola agen koding paralel kami mengulas berbagai pilihan yang ada.
Siapa yang harus segera mengambil langkah ini
Tim dengan tiga atau lebih agen yang berjalan setiap hari. Anda sudah mendekati batas kapasitas merge. Terapkan worktree dan merge queue minggu ini.
Pengembang mandiri (solo developer) yang menjalankan beberapa agen secara paralel. Bottleneck Anda ada pada peninjauan, bukan merging. Perkecil cakupan tugas hingga setiap diff dapat dibaca dalam waktu kurang dari sepuluh menit.
Lead platform dan infrastruktur. Perhatikan waktu antrean CI dan usia PR Anda. Artikel Anthropic menyebutkan bahwa kontrol versi dan CI mengalami gangguan lebih dulu sebelum komponen lainnya; perkirakan sistem Anda akan mengalami masalah dalam urutan yang sama. Konfigurasi parallel agents with isolated worktrees dapat memberi Anda ruang dan waktu tambahan.
Kesimpulan
Anthropic Scion adalah sebuah indikator arah tren, bukan produk yang dapat langsung Anda adopsi. Volume merge Anthropic melonjak dua belas kali lipat dalam empat bulan, pendekatan offline-first milik Git tidak lagi memadai, dan tim beranggotakan tujuh orang membangun ulang sistem kontrol versi untuk klien yang sebagian besarnya adalah agen. Sebagian besar tim tidak akan pernah membutuhkan sistem seperti itu.
Kendati demikian, setiap tim yang menjalankan agen koding akan menghadapi pergeseran yang sama: menulis kode menjadi sangat murah dan cepat, sedangkan proses merge serta peninjauannya menjadi mahal dan memakan waktu. Isolasikan setiap tugas, buat lingkup tugas tetap kecil, antrekan proses merge Anda, dan lakukan peninjauan berdasarkan bukti nyata.
Untuk memusatkan alur peninjauan dalam satu tempat, hubungkan satu Computer ke Sharkly, buat satu Agent, lalu tugaskan sebuah Task kecil dengan risiko rendah. Amati bagaimana hasilnya disajikan, dan tentukan langkah selanjutnya dari sana.
FAQ
Apa itu Anthropic Scion?
Scion adalah sistem kontrol versi internal milik Anthropic. Sistem ini menggantikan Git untuk monorepo perusahaan pada tahun 2026. Server menangani eksekusi commit, merge, dan rebase, sementara klien hanya menyimpan cache lokal yang terbatas.
Mengapa Anthropic mengganti Git?
Agen koding meningkatkan volume merge harian dari sekitar 2.500 pada Mei 2026 menjadi lebih dari 30.000 pada September. Git mirroring, checkout, dan CI tidak sanggup mengimbangi beban sebesar itu, sehingga sistem kontrol versi menjadi bottleneck utama.
Apakah Scion bersifat open source atau bisa digunakan publik?
Tidak ada versi rilis publik. Anthropic menyatakan bahwa Scion bukan pengganti Git yang cocok untuk penggunaan umum dan akan sulit untuk disediakan bagi organisasi lain. Anthropic membagikan konsep desainnya agar pihak lain dapat menerapkan ide-ide tersebut pada Git.
Bagaimana cara mengurangi konflik merge antar agen koding?
Berikan worktree tersendiri untuk setiap tugas, jaga agar cakupan tugas cukup spesifik sehingga menghasilkan satu diff yang mudah ditinjau, lakukan merge sesering mungkin, dan tempatkan merge queue sebelum branch main. Konflik terjadi akibat tumpang tindih file, sehingga pembatasan cakupan jauh lebih penting daripada jumlah agen.
Apakah tim kecil membutuhkan sistem kontrol versi baru?
Hampir tidak pernah. Masalah yang dihadapi Anthropic berakar dari riwayat repositori sebesar 100 GB dan 25 juta checkout per hari. Pada skala normal, kombinasi worktree, merge queue, dan peninjauan berbasis tugas sudah lebih dari cukup untuk menangani beban kerja.
