Anthropic ha rifatto git da zero: com’è fatto Scion

Nel giro di cinque mesi Anthropic ha lasciato git per il proprio monorepo e ha costruito da zero un sistema di controllo di versione, Scion. Non perché git sia fatto male, ma perché non è stato pensato per un mondo in cui a scrivere codice sono soprattutto gli agenti.

Quando il codice non è più il problema

Per anni il collo di bottiglia dello sviluppo software è stato scrivere codice. In Anthropic, raccontano gli ingegneri nel loro articolo, non è più così: Claude riesce a lavorare in autonomia su cicli di ricerca, ottimizzare programmi complessi e costruire servizi da zero a una velocità mai vista prima. A rallentare tutto è diventata l’infrastruttura pensata per la scala umana: controllo di versione, build e CI.

I numeri rendono l’idea. A maggio 2026 Anthropic univa nel proprio monorepo circa 2.500 modifiche al giorno, a settembre più di 30.000. Più di dieci volte in pochi mesi, e secondo gli autori il ritmo non accennerà a rallentare: ogni ostacolo rimosso fa produrre ancora più codice.

La risposta si chiama Scion, un sistema di controllo di versione sviluppato internamente. Il monorepo è stato migrato da git in soli cinque mesi, e nello stesso periodo il team ha costruito anche Antique (lo strumento di code review), un sistema di ricerca nel codice e una gestione dei permessi molto granulare. Qui ci concentriamo su Scion, che è anche un caso curioso: la capacità di Claude di scrivere codice ha creato il problema, ed è stata anche lo strumento per risolverlo.

Perché git non basta più

Prima di dire che git “non funziona” serve una premessa: per la stragrande maggioranza dei progetti è la scelta giusta, ed è il motivo per cui è diventato lo standard. Git è un sistema decentralizzato: ogni clone è un repository completo, in grado di calcolare differenze, storia e blame e di spostarsi tra le revisioni anche senza connessione.

Il problema è che un monorepo come quello di Anthropic esce da questo schema:

• la sola storia del ramo principale pesa quasi 100 GB;
• una copia di lavoro compressa supera i 25 GB;
• ogni giorno ci sono circa 25 milioni di checkout solo per la CI, senza contare ambienti di sviluppo, sandbox degli agenti e job di ricerca.

Scaricati nel modo classico, farebbero oltre 600 PB di traffico git al giorno.

Git offre strumenti per lavorare su una porzione del repository (clone superficiali, sparse checkout, promisor remote) e ci sono i soliti rimedi per i monorepo enormi, come i mirror interni e gli “snapshot” conservati su un archivio a blob. Anthropic li ha usati tutti, arrivando a gestire diverse centinaia di mirror git interni. Ha funzionato per un po’, ma più il ritmo dei merge cresceva più diventava difficile da mantenere: gli snapshot restavano indietro rispetto alla punta del ramo principale e far funzionare diff e blame sui cloni parziali richiedeva sempre più attenzione.

A quel punto il team ha fatto un passo indietro e si è accorto di una cosa: come quasi tutte le aziende, usava git come sistema centralizzato, con una sola copia di riferimento, ma i suoi client erano quasi tutti agenti e job, per definizione sempre online. Le proprietà che rendono git ottimo per il lavoro distribuito e offline stavano diventando il freno. Da qui la domanda: come sarebbe un controllo di versione progettato partendo dal fatto che gli agenti sono sempre connessi?

I principi di Scion

Per costruire Scion il team non è partito da zero: nel controllo di versione per monorepo giganti esiste una storia importante, a partire da Piper di Google e da Sapling di Meta (in particolare dal suo componente server, Mononoke), che ha aperto la strada a molte delle tecniche usate in Scion. Su questa base Anthropic ha scelto sei principi, in diversi punti molto lontani da quelli di git.

1. I client sono sempre online. Niente copia completa del repository in locale: i client scaricano i dati solo quando servono.
2. Client e server non sono uguali. In git ogni client può fare da server. In Scion il server risponde alle domande su storia e blame, crea i commit, esegue merge e rebase. Il client tiene una piccola cache locale, ricostruisce i file su disco e osserva le modifiche al filesystem: calcola pochissimo, ma in cambio ha bisogno di molti meno dati.
3. Un servizio completo apre a nuove applicazioni. Tutte le query che usa il client sono esposte anche via API. Un job di CI che vuole sapere chi ha modificato una riga o come sono legati due commit non ha più bisogno di un repository locale, e strumenti interni come le pipeline di bisect e revert automatici diventano praticabili su larga scala.
4. Tutto deve scalare in orizzontale. I dati del repository sono distribuiti e non esiste una copia completa da nessuna parte, nemmeno sul server. Non ci sono packfile, quindi nessuna manutenzione del repository.
5. I commit sono economici, incrementali e senza lock. Ogni commit, rebase e merge avviene direttamente sul server, quindi non c’è nulla da “pushare”. Il costo deve dipendere dalla dimensione della modifica, non da quella del repo. Per questo Scion scoraggia l’uso di branch e tag, salvo il ramo principale e quelli di rilascio: lo stato globale su cui tutti i server devono essere d’accordo è un problema di scalabilità in agguato.
6. La copia di lavoro è opzionale e parziale. Se un job ha bisogno del diff tra un commit e il suo merge base, lo chiede al server senza fare un checkout. E anche molte scritture possono avvenire solo via API. Quando i file servono davvero, il protocollo si basa su checkout sparse o virtualizzati, che materializzano i file solo quando vengono letti.

Come funziona Scion

Il changeset al posto del commit

L’unità di lavoro di Scion è il changeset, una voce in un write-ahead log. Dove un commit git punta a un albero di file, il changeset contiene l’elenco dei file modificati rispetto al primo genitore, più i puntatori (indirizzati per contenuto) ai file compressi nello storage a blob. Viene creato direttamente sul server ed è disponibile ovunque all’istante.

Il risultato è che il sistema può accettare modifiche con un throughput altissimo: niente packfile, niente lock, niente coordinamento tra server e niente riferimenti da spostare. I riferimenti (i ref) esistono ancora, ma spostarne uno è un’operazione compare-and-swap su una singola riga di Spanner, separata dalla creazione dei changeset.

I dati derivati

Un changeset registra solo ciò che è cambiato, quindi da solo non sa rispondere a domande come “chi ha scritto l’ultima volta questa riga?”. Per questo Scion costruisce dati derivati: strutture dedicate per blame e storia dei percorsi e skip list per il grafo dei commit. Ogni tipo è definito in modo ricorsivo, perché il suo valore per un changeset si calcola a partire da quello dei suoi genitori.

I vantaggi sono tre:

• si può aggiungere un nuovo tipo di dato quando una struttura renderebbe più veloce un’operazione;
• per ciascun tipo si può scegliere se calcolarlo subito o rimandare il lavoro;
• il client non vede mai i dettagli interni, quindi si possono ottimizzare senza toccarlo.

Il team li ha aggiunti più volte strada facendo, ad esempio per il rilevamento delle copie e per la ricerca di file per percorso.

Scaricare il codice: un sistema a cache

Il client di Scion (scn) si discosta dal protocollo di git. La negoziazione non dice al server cosa il client ha già: parte da un albero radice, controlla nello store locale quali parti mancano e le richiede ricorsivamente, poi ripete il processo per i file. Ogni richiesta riguarda un oggetto specifico che non cambia mai, quindi qualsiasi cache può rispondere, e non esiste una singola risposta enorme da molti gigabyte. Anche i checkout sparse e virtualizzati non richiedono supporto speciale: il client semplicemente non chiede gli alberi che non gli servono.

La catena, dal basso verso l’alto, è questa:

1. scion-daemon: su ogni nodo della flotta, conserva gli oggetti per tutti i job che girano lì e parte da uno snapshot aggiornato periodicamente;
2. scion-cache: server di cache regionali che inviano gli oggetti direttamente dalla memoria, già nel formato su disco usato dal daemon, senza calcoli né compressione delta;
3. scion-server: i server di riferimento, che leggono da Spanner o dal cloud storage quando una cache non ha l’oggetto.

Tutti e tre rispondono alle stesse chiamate RPC, quindi il client non deve conoscere la topologia. In teoria ogni livello potrebbe parlare con qualsiasi altro, ma Anthropic impone la gerarchia per isolare i guasti: un problema in una cache regionale non deve sommergere i server a monte e fermare tutto il sistema.

I numeri

Secondo Anthropic i risultati sono netti. Ecco i dati principali dichiarati nell’articolo (sono misure interne, non verificate da terzi):

C’è anche un effetto collaterale che chi gestisce infrastrutture apprezzerà: né client né cache devono occuparsi della manutenzione del repository, e questo semplifica la vita dei job.

Cosa ha imparato il team

La parte più interessante dell’articolo, almeno per me, non è l’architettura ma quello che racconta su come si lavora oggi. Il team ha iniziato Scion più o meno quando Claude Mythos Preview e Claude Tag sono diventati disponibili internamente, e questo ha accelerato tutto. L’esempio più chiaro è la pipeline che porta la storia di git dentro Scion: la prima versione era stata scritta in gran parte a mano, come prototipo. Quando hanno avuto accesso a uno snapshot interno di Mythos Preview gli hanno chiesto di riscriverla da capo, senza altre istruzioni, e il risultato ha usato 20 volte meno memoria ed era 4 volte più veloce, rispettando tutte le regole implicite sull’ordine di ingestione e sulle strutture dati.

Pochi sviluppatori, tempi da startup

Sette persone hanno costruito Scion, Antique e una mezza dozzina di sistemi collegati, migrando tutto in cinque mesi mentre il volume di codice unito ogni giorno cresceva di dieci volte. Con i metodi tradizionali, scrive Anthropic, per una migrazione simile sarebbero serviti anni e molti più ingegneri.

Gli ingegneri servono ancora, ma fanno altro

Tutti gli ingegneri coinvolti ritengono Claude più bravo di loro a scrivere codice. Il loro contributo resta la comprensione di come i sistemi si incastrano e dei compromessi di progetto. E spesso il loro ruolo è stato dire “no” a Claude: gli agenti a volte violano vincoli fondamentali pur di rispettare un pattern che non avrebbe dovuto essere permesso. Per esempio, più sistemi cercavano di capire quando una modifica fosse arrivata nel ramo principale leggendo il log dei commit, invece di chiederlo allo strumento di code review. Anche la revisione “avversaria” tra agenti, molto usata in azienda, può diventare miope: in un caso ha portato Claude ad aggiungere validazioni e complessità inutili, per eccesso di cautela verso un altro servizio interno.

Il team continua a rivedere ogni richiesta di modifica, ma ora guarda l’intento del cambiamento invece di leggere ogni riga di codice.

Qualità, sicurezza e operatività

• Test e ottimizzazione. Scion è tra le basi di codice più testate e difese che il team abbia mai visto: simulazioni isolate di ogni interazione complessa con l’infrastruttura, fuzzing e limitazione del traffico. Claude ha anche trovato un’ottimizzazione algoritmica per le query sugli antenati che sfuggiva a uno degli indici, un lavoro da giorni o settimane per un esperto.
• Sicurezza. I permessi si possono applicare anche a singole directory, per proteggere il codice più sensibile senza rinunciare al monorepo. Gli strumenti di review distinguono tra modifiche semplici, come i soli commenti, e modifiche logiche delicate, così i revisori umani si concentrano su ciò che conta.
• I “superfan”. Con Claude Tag il team ha creato canali Slack in cui un Claude si occupa in modo quasi ossessivo di un solo componente (lo scion-daemon, la scion-cache, la coda di merge di Antique) leggendo telemetria e log come farebbe un ingegnere esperto con tempo da vendere. Gli allarmi tradizionali restano, ma i superfan individuano problemi sottili che gli allarmi non vedono.

Ripensare i flussi pensati per gli umani

Il progetto ha spinto il team a rimettere in discussione altri processi nati per la scala umana. Una coda di merge classica, per esempio, ha poco senso quando centinaia o migliaia di modifiche entrano mentre i test sono ancora in corso. Non essendo riusciti a replicare il blocco globale sul repository, tipico delle code di merge, hanno puntato su test automatici dopo il merge e prima del deploy. Le modifiche concorrenti possono quindi entrare in conflitto, ma secondo Anthropic Claude di solito risolve i conflitti più in fretta di quanto un umano riesca a individuarli.

Scion sostituirà git?

No, e Anthropic lo dice senza giri di parole. Scion non è un sostituto di git per l’uso generale: i suoi concetti hanno senso solo per monorepo enormi, con decine di migliaia di ingegneri o sciami di agenti che scrivono codice di continuo. Inoltre Anthropic è un caso particolare, perché può permettersi di spendere in token per uso interno molto più di quanto qualsiasi altra azienda vorrebbe, sia per le proprie esigenze sia per mettere alla prova Claude.

Offrire Scion al pubblico sarebbe poi poco pratico. Si discosta molto da git, quindi chi lo adottasse dovrebbe migrare ogni pezzo del ciclo di sviluppo, e servirebbero anche code review, ricerca nel codice e CI su misura, che internamente sono molto personalizzati.

La strada scelta è un’altra: condividere il ragionamento, così che chi usa git possa prendere le parti migliori di Scion senza uscire dal suo modello. Le idee proposte dagli autori:

• un server git non deve per forza funzionare come un client git, e architetture di server diverse possono dare grandi vantaggi di scalabilità;
• le piattaforme git potrebbero offrire RPC lato server complete come quelle di Scion, magari in modo standardizzato tra i vari forge e con un client git capace di usarle;
• il protocollo di negoziazione può cambiare rispetto a oggi, e le funzioni sparse e shallow di git possono essere rese più componibili.

Anthropic riconosce inoltre che la community git ha passato quasi vent’anni a far scalare la piattaforma per milioni di sviluppatori, e dichiara di voler collaborare con GitHub, GitLab e il mondo open source.

Cosa resta da dimostrare

Va detto con chiarezza che tutti i dati dell’articolo vengono da Anthropic, che li ha misurati sui propri sistemi e che ha un interesse evidente a mostrare cosa sa fare Claude. Non ci sono confronti indipendenti, né è possibile ripetere i test: Scion è un sistema interno e Claude Mythos Preview non è disponibile al pubblico. Anche il confronto con i mirror git riguarda l’infrastruttura specifica di Anthropic, non git in generale.

Ci sono poi alcune scelte che hanno un prezzo e che l’articolo racconta con onestà. Rinunciare alla coda di merge con blocco globale significa accettare che le modifiche concorrenti possano entrare in conflitto, contando sul fatto che Claude le sistemi più in fretta di un umano. Rivedere l’intento di una modifica invece di ogni riga funziona bene con un team piccolo e molto competente, e resta da vedere quanto regga altrove.

Infine, il punto di partenza è un caso estremo: più di 30.000 modifiche al giorno in un solo monorepo non sono la realtà della maggior parte delle aziende. L’indicazione più utile per tutti gli altri è quella degli stessi autori: il problema si presenterà anche a chi usa strumenti di programmazione con l’IA, probabilmente nei prossimi sei-dodici mesi. Gli effetti sul resto dell’ecosistema git saranno da seguire.

E voi, nella vostra azienda, avete già visto il controllo di versione o la CI diventare un collo di bottiglia con l’arrivo degli assistenti di programmazione? Fatemelo sapere nei commenti.

Fonti

• Redesigning source control at Anthropic, Anthropic Engineering, 13 ottobre 2026 (aggiornato il 15 ottobre)
• Piper, il sistema di controllo di versione di Google
• Sapling, il sistema di controllo di versione di Meta
• Mononoke, il server di Sapling