Scion di Anthropic: perché ha sostituito Git nel monorepo con 30.000 merge al giorno

Quando a scrivere la maggior parte del codice sono gli agenti, il collo di bottiglia smette di essere la scrittura e diventa tutto ciò che sta intorno: controllo di versione, build, integrazione continua. È la lezione che emerge da un post tecnico pubblicato il 13 ottobre 2026 sul blog di ingegneria di Anthropic, Redesigning Source Control at Anthropic, in cui l’azienda racconta di aver sostituito Git nel proprio monorepo con un sistema interno chiamato Scion.

I numeri che spiegano la scelta sono impressionanti: i merge giornalieri sono passati da circa 2.500 a maggio 2026 a oltre 30.000 a settembre. Un aumento di dodici volte in pochi mesi, trainato soprattutto da Claude.

Perché Git non bastava più ad Anthropic

Git è nato per un mondo preciso: sviluppatori sparsi, spesso offline, ciascuno con una copia completa del repository. Il modello decentralizzato è la sua forza, ma nel caso di Anthropic diventava un peso. Quasi tutti i client del monorepo sono agenti e job automatici che sono sempre online e che hanno bisogno di pochissimi file alla volta, non dell’intera storia del progetto.

Il repository, secondo il post, ha una storia del ramo principale di quasi 100 GB e una copia di lavoro compressa che supera i 25 GB. Ogni giorno partono circa 25 milioni di checkout per la CI. Scaricare tutto in modo ingenuo significherebbe oltre 600 PB di traffico Git quotidiano, una cifra che rende evidente perché il modello standard non reggesse.

I rimedi provvisori prima di Scion

Il team non è partito subito da zero. Ha provato le soluzioni che l’ecosistema Git offre per i repository enormi: cloni superficiali e parziali, promisor remote, seed del repository nello storage a blocchi. Al picco, Anthropic gestiva diverse centinaia di mirror Git interni, difficili da far funzionare e con seed che invecchiavano tra un aggiornamento e l’altro.

In altre parole, si stava costruendo un sistema distribuito sopra uno strumento pensato per non esserlo. Meglio ripartire dalle ipotesi giuste.

Come funziona Scion

Il principio di fondo è invertire l’assunzione di Git: i client sono sempre online, quindi possono chiedere i dati quando servono. Il server si occupa di storia, blame, commit, merge e rebase, mentre il client conserva solo una cache locale limitata e gestisce la copia di lavoro. Le operazioni di controllo di versione sono esposte come API, così molti job non hanno più bisogno di un repository locale.

Non esiste una copia completa del repository in nessun punto, nemmeno sul server. I dati sono distribuiti, non ci sono packfile e quindi non serve alcuna manutenzione.

Changeset, ref e dati derivati

L’unità di base è il changeset, registrato in un write-ahead log. Diversamente da un commit Git, che punta a un albero, un changeset elenca i file modificati rispetto al primo genitore, con puntatori indirizzati per contenuto verso i file compressi nello storage a blocchi. I changeset vengono creati lato server, quindi commit, rebase e merge hanno un costo che dipende dalla dimensione della modifica e non da quella del repository.

Spostare un ref è un’operazione di compare-and-swap su una singola riga di Spanner, separata dalla creazione dei changeset. Blame, storia dei percorsi e skip list del grafo dei commit sono calcolati con un unico meccanismo ricorsivo generico, che permette di aggiungere nuovi tipi di dati derivati e di calcolarli in modo eager o lazy senza toccare i client.

Tre livelli di cache

Il recupero dei dati negozia soltanto gli alberi e i blob che il client vuole, partendo da un albero radice. Ogni richiesta riguarda un oggetto immutabile, quindi qualunque cache può servirla, ed è ripristinabile senza un grosso packfile unico. La topologia ha tre livelli: scion-daemon su ogni nodo, scion-cache a livello regionale e scion-server come fonte autorevole che legge da Spanner e dallo storage cloud in caso di cache miss.

Tutti rispondono alle stesse chiamate RPC, perciò il client non deve conoscere la struttura. Ogni livello mantiene un tasso di successo della cache sopra il 99%.

I risultati dichiarati da Anthropic

Secondo il post, l’infrastruttura di Scion usa circa 200 volte meno CPU e memoria rispetto al vecchio sistema di mirror Git. I checkout per CI e ricerca sono scesi da minuti a secondi, circa due ordini di grandezza più veloci, e la sola CI ha guadagnato circa il 25% di capacità di calcolo.

Sono dati forniti dall’azienda stessa e non verificati da terzi, ma indicano bene l’ordine di grandezza del problema che stava risolvendo.

Antique e gli altri sistemi costruiti in parallelo

Insieme a Scion è nato Antique, lo strumento interno di code review. Può esprimere regole di approvazione semantiche, per esempio distinguere una modifica ai soli commenti da una che tocca logica sensibile, in modo che i revisori umani si concentrino sulle modifiche che contano davvero. Nello stesso periodo il team ha costruito anche un sistema di ricerca del codice, un controllo degli accessi per il controllo di versione, con permessi per singola directory, e nuovi modi per integrare grandi volumi di codice già rivisto.

Il ruolo di Claude nel costruire lo strumento che lo serve

Il dettaglio più interessante è chi ha fatto il lavoro. Un team di sette persone ha costruito Scion, Antique e circa mezza dozzina di sistemi collegati, completando la migrazione in cinque mesi mentre il volume dei merge cresceva di dieci volte. Gran parte del lavoro è stata svolta con Claude, un tema che avevamo già visto quando Torvalds ha usato Claude Code per riscrivere la page cache di Linux.

Per esempio, Claude ha riscritto da solo un prototipo artigianale della pipeline di ingestione, senza istruzioni aggiuntive, ottenendo circa 20 volte meno memoria e una velocità circa quadrupla, pur rispettando gli invarianti di ordinamento. Ha anche trovato ottimizzazioni, come un miglioramento di una query sugli antenati che ignorava un indice già esistente, e ha aiutato a costruire simulazioni ermetiche, fuzzing e limitazione del traffico.

Quando bisogna dire no

Il post non è una celebrazione acritica. Gli ingegneri raccontano di aver dovuto spesso dire di no a Claude quando violava i vincoli del sistema, per esempio scansionando il log dei commit invece di interrogare Antique, oppure introducendo validazioni troppo difensive sotto la pressione di una revisione avversariale. Il contributo umano si sposta verso l’architettura di alto livello, i compromessi e il controllo dell’intento delle modifiche, più che la lettura riga per riga.

Sono poi comparse le istanze di Claude che l’azienda chiama superfan: agenti che monitorano singoli componenti, come scion-daemon, scion-cache o la coda di merge di Antique, leggendo telemetria e log per cogliere problemi sottili che gli allarmi standard non vedono.

Scion è disponibile? No, e Anthropic lo dice chiaramente

Qui serve precisione, perché circolano ricostruzioni che parlano di un sostituto di Git open source. Il post di Anthropic non lo dice: l’azienda afferma che Scion non è un sostituto generale di Git e che i suoi concetti si adattano soprattutto a monorepo molto grandi con molti ingegneri o agenti. I componenti interni sono su misura e difficili da adottare per altre organizzazioni, quindi la scelta è stata condividere le idee e non un prodotto pubblico.

L’obiettivo dichiarato è che gli sviluppatori possano applicare parti dell’approccio a Git, come RPC lato server, nuove architetture dei server e funzioni sparse e superficiali più componibili. Anthropic dice di voler collaborare con GitHub, GitLab e la comunità open source.

Cosa cambia per te che sviluppi con gli agenti

Anche se non userai mai Scion, il caso racconta una tendenza che riguarda chiunque lavori con assistenti di programmazione. Il carico di lavoro cambia natura: meno commit umani sporadici, più modifiche automatiche, parallele e continue. Gli strumenti pensati per la collaborazione tra persone, dalle code di merge globali con lock ai flussi di review riga per riga, non scalano a quel ritmo.

Anthropic ha scelto di affidarsi a test dopo il merge e prima del rilascio, e osserva che Claude di solito risolve i conflitti più in fretta di quanto un umano riesca a individuarli. Non è una ricetta universale, ma suggerisce dove guardare. Una piattaforma come GitHub, che sta già portando gli agenti dentro l’ambiente di lavoro, come abbiamo raccontato per Copilot e il computer use sulle app desktop, dovrà probabilmente confrontarsi con le stesse pressioni.

Se vuoi approfondire come funziona l’assistente alla base di questa storia, trovi una guida completa a Claude AI, mentre per capire come l’azienda sta formando chi lo userà c’è l’articolo su Claude Frontier Academy e i 100 milioni per formare 10.000 ingegneri.

Conclusioni

Scion è un caso di studio prima ancora che un prodotto: mostra che, quando l’AI accelera la scrittura del codice di un fattore dieci, l’infrastruttura va ripensata dalle fondamenta, a partire dalle ipotesi su chi usa il sistema. Il nodo non è più solo generare codice, ma farlo entrare in produzione in modo sicuro e rapido.

Se gestisci un team che usa agenti di coding, prova a misurare dove si ferma il flusso: tempi di checkout, code di merge, carico della CI. Leggi il post originale di Anthropic, confrontalo con la tua situazione e seguici per i prossimi aggiornamenti sul tema.