Anthropic, l’azienda di intelligenza artificiale guidata da Dario Amodei, ha presentato Scion, il proprio sistema di version control (VCS) pensato per sostituire git all’interno del gigantesco monorepo aziendale. Il passaggio, iniziato nel 2025, è durato cinque mesi e ha visto il numero di merge giornalieri crescere da circa 2.500 a oltre 30.000, una crescita che ha messo in evidenza i limiti di git in ambienti altamente automatizzati.
Perché git non bastava più
Nel suo Engineering Blog del 13 ottobre 2026, il team di Source Control di Anthropic spiega che git, nato per sistemi decentralizzati e per sviluppatori che effettuano pochi commit al giorno, non riesce a tenere il passo con il ritmo di un’organizzazione in cui migliaia di agenti – CI jobs, sandbox, servizi di revisione – generano cambiamenti continuamente.
Le statistiche sono impressionanti: nel maggio 2026 il monorepo vedeva circa 2.500 merge al giorno; a settembre lo stesso periodo superava i 30.000. La cronologia del ramo principale supera i 100 GB, mentre una copia di lavoro compressa arriva a più di 25 GB.
Le operazioni di checkout – il processo di copia dei file su una macchina per lavorarci – sono particolarmente onerose. Solo la CI genera circa 25 milioni di checkout al giorno; se si includessero gli ambienti di sviluppo, le sandbox degli agenti e i job di ricerca, il traffico git supererebbe i 600 PB giornalieri.
Scion: caratteristiche e architettura
Scion è stato sviluppato da un team di sette persone con l’obiettivo di gestire un unico, enorme repository usato prevalentemente da client connessi in rete. Il modello di base è diverso da quello di git: invece di richiedere una copia completa della storia su ogni client, Scion si basa su un server autoritario e su client sempre connessi che richiedono i dati solo quando necessario.
La struttura di Scion si compone di tre componenti principali:
- scion-daemon: gira su ogni nodo, mantiene un snapshot aggiornato del repository.
- scion-cache: istanze regionali che forniscono oggetti dalla memoria.
- scion-server: server autoritari che leggono da Spanner (il database distribuito di Google Cloud) o da Cloud Storage.
Questa gerarchia è intenzionalmente rigida: un cache regionale che incontra problemi non può trasferire il carico ai livelli superiori, garantendo stabilità e prevedibilità.
Come funziona il trasferimento dei dati
In git il client comunica al server quali oggetti possiede e il server costruisce un packfile contenente le differenze, spesso di dimensioni gigabyte. Scion, al contrario, parte dal “root tree” e scende verso il basso, richiedendo solo le directory e i file effettivamente necessari. La risposta è piccola, può essere interrotta e ripresa, e riduce drasticamente la banda consumata.
Changeset e gestione della cronologia
Il nucleo di Scion è il changeset, una riga di un write‑ahead log. A differenza di un commit git, che punta a un intero albero, il changeset elenca i file modificati rispetto al primo genitore e utilizza un indirizzo calcolato sul contenuto (content‑addressed) per puntare al blob compresso nello storage.
Gli indici di cronologia, blame e altri metadati sono derivati in modo ricorsivo salendo lungo i genitori. Questi dati possono essere generati on‑demand o pre‑calcolati, senza che il client debba gestirli direttamente.
Le referenze (branches, tags) sono gestite tramite operazioni compare‑and‑swap su una singola riga di Spanner, separata dalla creazione dei changeset. Poiché i dati sono immutabili, i server possono cachearli liberamente, trasformandosi in grandi cache frontali a Spanner.
Confronto dettagliato: Scion vs git
| Aspetto | git | Scion |
|---|---|---|
| Modello | Decentrato, copia completa su ogni client | Server autoritario, client sempre connessi |
| Storico, blame, merge | Calcolati localmente | Gestiti dal server, disponibili via API |
| Commit e rebase | Locale, poi push | Direttamente sul server, nessun push |
| Trasferimento dati | Packfile basato su differenze | Richiesta di alberi/blobs a partire dalla radice |
| Riferimenti (refs) | Branches e tags liberi | Solo main e release, altri evitati |
| Working copy | Completa (o parziale con sparse/partial clone) | Opzionale, file forniti on‑demand |
| Offline | Sì | No, richiede rete |
| Disponibilità | Open source, per tutti | Strumento interno ad Anthropic |
Risultati operativi
Secondo le cifre interne fornite da Anthropic, Scion ha raggiunto:
- Cache‑hit‑rate superiore al 99 % su ogni livello.
- Riduzione dell’infrastruttura CPU e memoria di circa 200 volte rispetto ai precedenti git‑mirrors.
- Checkout fino a due ordini di grandezza più rapidi (secondi anziché minuti).
- Risparmio del 25 % di capacità CPU nella CI.
Questi dati, sebbene non verificabili da fonti esterne, indicano un miglioramento significativo in termini di costi e performance.
Esempi di problemi risolti con Scion
L’articolo di Anthropic cita due casi in cui gli ingegneri hanno dovuto intervenire su Claude, il modello interno:
- Alcuni sistemi cercavano di capire quando una modifica fosse arrivata su
mainleggendo il log dei commit riga per riga, invece di interrogare lo strumento di code‑review. Scion, con la sua API, ha eliminato la necessità di analizzare il log. - Un “adversarial review” ha indotto Claude a introdurre validazioni superflue e complessità aggiuntiva in un servizio interno, a causa di un comportamento difensivo eccessivo. L’intervento umano ha permesso di rimuovere il codice inutile, dimostrando i limiti di un sistema di revisione automatizzato.
Distinzione da Scion di Google
È importante non confondere Scion di Anthropic con il progetto omonimo di Google, che è un testbed sperimentale per orchestrare più agenti in container e che utilizza ancora git e i suoi worktree. Le due iniziative sono indipendenti e hanno obiettivi diversi.
Impatto sul flusso di lavoro degli ingegneri
Con l’introduzione di Scion, la routine quotidiana degli sviluppatori è cambiata. Ora l’architettura, i compromessi e i requisiti di rete sono parte integrante della progettazione del codice. Gli ingegneri devono considerare che i dati sono forniti “on‑demand” e che le operazioni di merge e blame sono gestite dal server, riducendo il carico locale ma richiedendo una connessione stabile.
Il progetto è stato avviato quando le versioni Claude Mythos Preview e Claude Tag erano già operative. Un prototipo manuale della pipeline di importazione della cronologia da git a Scion è stato riscritto da Mythos Preview, ottenendo un consumo di storage 20 volte inferiore e una velocità quattro volte superiore, mantenendo le invarianti del codice originale.
Conclusioni
Scion rappresenta una risposta concreta ai problemi di scalabilità che emergono quando un monorepo diventa l’unico punto di ingresso per migliaia di agenti automatizzati. La sua architettura server‑centrica, l’uso di changeset content‑addressed e la forte integrazione con Spanner e Cloud Storage hanno permesso ad Anthropic di gestire un volume di merge giornalieri senza precedenti.
Tuttavia, gli autori sottolineano che Scion non è concepito per sostituire git in progetti tipici. Git rimane lo strumento di riferimento per la maggior parte dei repository, soprattutto quando la decentralizzazione, la possibilità di lavoro offline e la compatibilità con l’ecosistema open source sono requisiti fondamentali.
Il caso di Anthropic dimostra che, in scenari estremi di automazione e volume di cambiamenti, può essere necessario ripensare le fondamenta del version control, ma la scelta di un VCS proprietario resta una decisione altamente contestualizzata.