L’IA genera così tanto codice che Anthropic ha dovuto reinventare il proprio Git: anatomia di Scion

Il 13 ottobre 2026, l'engineering team di Anthropic ha pubblicato un articolo destinato a fare scuola nel mondo dell'ingegneria del software: Redesigning source control at Anthropic.

La premessa è di quelle che segnano un cambio d'epoca: la velocità con cui gli agenti di intelligenza artificiale generano codice ha superato la capacità di Git di accoglierlo, verificarlo e archiviarlo.

Per far fronte a un'esplosione senza precedenti di modifiche concorrenti sul proprio monorepo interno, Anthropic ha sviluppato e migrato in produzione Scion, un sistema proprietario di controllo versione pensato specificamente per carichi di lavoro guidati da macchine e modelli autonomi.

Prima di gridare al "funerale di Git", però, è fondamentale analizzare i numeri reali, chiarire i confini di questa scelta ed evitare facili generalizzazioni.

1. I numeri reali: la rottura di scala a 30.000 merge al giorno

La transizione non è nata da un capriccio ingegneristico, ma da una pura necessità di sopravvivenza infrastrutturale:

• Il balzo dei merge: A maggio 2026, il monorepo di Anthropic registrava circa 2.500 merge di modifiche al giorno. A settembre 2026, la quota ha sfondato i 30.000 merge giornalieri (un aumento di oltre 10 volte in quattro mesi), spinto massicciamente da Claude e da agenti che scrivono, verificano e aprono pull request in autonomia.

• Le dimensioni del repository: La cronologia del branch principale si avvicina ai 100 GB, mentre una copia di lavoro compressa supera i 25 GB.

• Il traffico CI: Anthropic stima circa 25 milioni di checkout al giorno per la sola Continuous Integration, a cui si aggiungono ambienti di test e sandbox per agenti. Un approccio ingenuo con cloni Git integrali comporterebbe un volume teorico superiore a 600 Petabyte di traffico di rete al giorno.

Per reggere il carico, Anthropic gestiva una flotta di diverse centinaia di mirror Git interni. Quando però sia la RAM che il disco dei nodi hanno iniziato a saturarsi sotto la frequenza dei merge, la manutenzione dei packfile e la serializzazione delle code hanno raggiunto il limite fisico.

2. Perché Git fa fatica con gli agenti (ma resta perfetto per i team tradizionali)

È bene sgomberare subito il campo da equivoci: Anthropic ha chiarito esplicitamente che Scion non è pensato per sostituire Git al di fuori del proprio contesto, né verrà rilasciato come software generico.

Per la stragrande maggioranza delle aziende, delle PMI e dei progetti open source, Git resta insostituibile, solido e scalabile. Il modello distribuito di Linus Torvalds è stato progettato per programmatori umani con un assunto chiaro: il client può lavorare offline, possiede una copia integrale della cronologia e calcola localmente diff, merge e blame.

Tuttavia, quando il "client" è uno sciame di migliaia di agenti IA e container effimeri nel cloud:

1. L'assunto dell'offline cade: I container e i bot CI/CD sono sempre online e connessi tramite dorsali cloud ad altissima capacità.

2. Il costo computazionale sul client è uno spreco: Far calcolare a ogni sandbox la cronologia completa o la risoluzione dei conflitti spreca cicli macchina.

3. I lock di riferimento globale scalano male: In un sistema distribuito con merge queue convenzionali, far concordare centinaia di server sullo stato dei branch ad ogni frazione di secondo genera colli di bottiglia computazionali non sostenibili.

3. L'architettura di Scion: il client diventa "stupido", il server fa tutto

Costruito da un team snello di sette ingegneri in circa cinque mesi, Scion ribalta le logiche di Git:

• Asimmetria client-server radicale: Tutte le operazioni complesse (creazione di commit, merge, rebase, blame e query sulla cronologia) avvengono lato server. Il client gestisce una cache locale limitata e dispone i file su disco.

• Changeset incrementali al posto dei commit monolitici: Il costo di una modifica scala con l'entità delle righe toccate, non con la dimensione complessiva del repository.

• Sparse e Virtualized Checkout via API: Molti job di CI non scaricano più il codice: richiedono direttamente i diff tramite API. Se un container ha bisogno dei file fisici, li riceve in modalità virtualizzata/on-demand (sparse checkout).

• Infrastruttura scalabile a tre livelli:

  1. scion-daemon: un demone locale su ciascun nodo di calcolo condiviso dai job.

  2. scion-cache: nodi di caching regionali in memoria con un hit rate superiore al 99%.

  3. scion-server: backend autorevole basato su Google Spanner e storage a oggetti per dati immutabili.

I risultati sul campo: Scion impiega circa 200 volte meno risorse di CPU e memoria rispetto alla vecchia flotta di mirror Git, ha ridotto i tempi di checkout da svariati minuti a pochi secondi e ha liberato il 25% della capacità di calcolo della CI.

Il paradosso ricorsivo: Una nota di colore tecnico riportata dal team riguarda la pipeline di migrazione dei dati da Git a Scion: riscritta e ottimizzata con l'assistenza di una versione di Claude, ha ottenuto una riduzione di 20 volte nell'uso della memoria e un'esecuzione 4 volte più veloce. L'IA che ha messo in crisi Git ha aiutato a costruire il motore per archiviare il suo stesso codice.

4. La riflessione di WebDesignLAB: il collo di bottiglia non è più scrivere codice

Cosa insegna questa vicenda a chi sviluppa software ogni giorno?

La tesi più forte espressa da Anthropic è che il collo di bottiglia dello sviluppo si è definitivamente spostato: non riguarda più la digitazione della logica applicativa, ma l'infrastruttura circostante (controllo versione, orchestrazione dei test, build system e CI/CD).

Monorepo vs Multi-repo: la nostra prospettiva architetturale

È importante ribadire una distinzione fondamentale: un monorepo non è necessariamente un monolite applicativo. Come dimostrano da decenni le architetture di Google (con Piper) o di Meta (con Sapling), un monorepo può ospitare centinaia di servizi e librerie indipendenti.

Tuttavia, dal nostro punto di vista in WebDesignLAB, la scelta di Anthropic di difendere a tutti i costi l'integrità del monorepo anziché disperdere il codice in un arcipelago di decine di micro-repository separati offre uno spunto cruciale:

• La frammentazione in multi-repo, spesso adottata acriticamente per aggirare i limiti di scalabilità del tooling o per imitare modelli a microservizi distribuiti, sposta la complessità a valle: disallinea le dipendenze, crea colli di bottiglia nelle pull request incrociate e frantuma il contesto.

• Per gli agenti IA, avere una visione d'insieme unificata e atomica della codebase è un vantaggio competitivo enorme rispetto all'accesso parcellizzato a repo isolati.

• Un'architettura coerente (sia essa un monolite ben strutturato o un monorepo modulare con confini chiari) semplifica i test cross-sistema, garantisce build atomiche ed evita la proliferazione di pipeline CI orfane.

5. Conclusioni: pragmatismo per il mondo reale

Nessuna azienda comune si troverà domani a gestire decine di milioni di checkout giornalieri o 30.000 merge bot-driven. Git rimarrà il fidato compagno di lavoro della comunità globale per moltissimi anni.

La lezione di Scion è un'altra: man mano che strumenti come Claude Code, GitHub Copilot e agenti di automazione aumentano il volume di codice prodotto, le inefficienze dell'infrastruttura di rilascio non possono più essere nascoste.

Ottimizzare le pipeline CI/CD, eliminare passaggi ridondanti nei workflow e mantenere architetture pulite e coese è la vera priorità per qualsiasi team che voglia farsi trovare pronto per il futuro.