25 milioni di checkout al giorno: il problema che Git non doveva risolvere

Venticinque milioni di checkout al giorno. Non è il numero di sviluppatori di un’azienda e non è nemmeno il numero di modifiche che arrivano in produzione. È quante volte, secondo Anthropic, la sua infrastruttura di integrazione continua deve procurarsi il codice per lavorarci. Un’operazione ordinaria, moltiplicata per una scala decisamente poco ordinaria, diventa una voce di costo capace di dettare l’architettura.

La notizia del 13 ottobre 2026 è che Anthropic ha migrato il proprio monorepo da Git a Scion, un sistema di versionamento costruito internamente. La lettura più pigra sarebbe dichiarare che gli agenti AI hanno ucciso Git. Peccato che sia la conclusione opposta a quella scritta dagli ingegneri che hanno realizzato Scion: Git continua a essere la scelta giusta per la maggior parte dei repository. Il loro problema era un altro, molto più concreto: pagare ripetutamente per trasportare e ricostruire informazioni che quasi nessun client aveva bisogno di possedere per intero.

Il numero importante non è quanti commit produci

Nel resoconto tecnico di Anthropic Engineering, i cambiamenti integrati ogni giorno passano da circa 2.500 a maggio a oltre 30.000 a settembre 2026. Sono misure interne dichiarate dall’azienda, non benchmark indipendenti. Servono a descrivere il profilo di carico, non a dimostrare che trentamila modifiche producano automaticamente dodici volte più valore.

La storia del branch principale sfiora i 100 GB; una working copy compressa supera i 25 GB. Alla scala dichiarata di circa 25 milioni di checkout CI giornalieri, un prelievo ingenuo delle copie complete porterebbe, nel calcolo teorico di Anthropic, a oltre 600 petabyte di traffico Git al giorno. Non è il traffico realmente misurato: è la dimensione del problema se si ignora ogni ottimizzazione. La distinzione conta, perché trasformare una stima di scenario in una metrica di produzione sarebbe un modo piuttosto creativo di fare performance engineering.

Per anni abbiamo misurato la velocità di sviluppo contando attività: righe, commit, pull request. Ma un processo software non finisce quando il codice viene generato. Deve essere recuperato, confrontato, testato, integrato, distribuito e, se necessario, annullato. È la differenza tra movimento e risultato, già affrontata ragionando di codice prodotto dagli agenti e software realmente consegnato. Scion rende visibile una parte meno appariscente di quel costo: la circolazione materiale e logica del repository.

Git non è sbagliato: sta mantenendo una promessa

Git nasce con una proprietà straordinaria: ogni clone può essere un repository completo, capace di consultare storia, diff e revisioni anche senza rete. Questa autonomia ha un valore enorme per sviluppatori distribuiti, contributori open source e progetti che devono poter sopravvivere a un server irraggiungibile. Non è un difetto da correggere.

Il punto è che Anthropic descrive un mondo in cui la maggior parte dei client sono agenti e job che, per definizione, operano già online. Continuare a trattarli come potenziali custodi indipendenti dell’intera storia significa far pagare a ogni esecuzione proprietà che non usa. L’azienda aveva provato strumenti esistenti come shallow clone, sparse checkout, promisor remote, snapshot e centinaia di mirror interni. Non li ha ignorati: racconta di averli sfruttati fino a quando la crescita dei merge ha reso costoso mantenerli.

Scion cambia il contratto. Il server diventa autorevole e gestisce commit, merge, rebase, diff, history e blame. Il client mantiene una cache locale limitata, segue i cambiamenti del filesystem e materializza soltanto ciò che serve. È una scelta che rinuncia a parte dell’autonomia offline in cambio di un costo per operazione più prevedibile su carichi estremi. Non è una legge universale: è un compromesso legato a chi usa il sistema e a quante volte lo usa.

Una proprietà architetturale è un vantaggio finché qualcuno la usa. Quando tutti pagano per una garanzia che nessuno esercita, quella garanzia diventa un costo da misurare.

Scion: meno copie complete, più richieste mirate

Il nucleo di Scion non è un trucco per comprimere meglio un repository gigantesco. Ogni modifica viene rappresentata da un changeset nel log, con i file cambiati rispetto al primo genitore e riferimenti content-addressed ai contenuti compressi. Dati immutabili identificati dal loro contenuto possono attraversare cache diverse senza chiedere continuamente chi possieda la versione corretta.

La storia necessaria a operazioni come blame e ricerca dei percorsi non deve essere ricostruita da ogni client. Il server calcola e conserva strutture derivate, alcune in anticipo e altre soltanto quando servono. Anche un job che deve conoscere la differenza fra due revisioni può interrogarlo senza creare una working copy. Questa è la vera riduzione del lavoro: evitare un checkout quando la domanda non richiede affatto file sul disco.

Quando il checkout serve, è sparso o virtualizzato. Il client chiede alberi e blob specifici, non un enorme pacchetto costruito sulla base di tutto ciò che potrebbe mancargli. Sulla macchina, un daemon condivide gli oggetti fra job; cache regionali servono gli oggetti più richiesti; i server autorevoli recuperano il resto. I livelli parlano lo stesso protocollo, ma la topologia è deliberatamente rigida per evitare che il guasto di una cache travolga l’origine.

Anthropic riferisce hit rate superiori al 99% per livello, una footprint di CPU e memoria dell’infrastruttura circa 200 volte inferiore rispetto ai precedenti mirror Git, checkout circa cento volte più rapidi e un risparmio del 25% di capacità CPU nella CI. Sono risultati dichiarati su quel sistema, non prestazioni trasferibili a qualsiasi azienda. Il loro valore editoriale sta nel meccanismo che li rende plausibili e nei limiti che li accompagnano, non nella tentazione di trasformarli in uno slogan.

Più throughput non elimina la necessità di decidere

Spostare meno byte risolve una parte del problema. Il resto riguarda il significato delle modifiche. Anthropic ha costruito anche Antique, il proprio sistema di code review, e racconta che i sette ingegneri coinvolti hanno completato lo sviluppo e la migrazione in cinque mesi, con ampio impiego di Claude. L’azienda attribuisce agli agenti una parte importante della velocità, ma specifica che gli ingegneri hanno dovuto custodire invarianti, scegliere i compromessi e fermare soluzioni apparentemente ragionevoli che violavano vincoli del sistema.

È una distinzione tecnica, non una difesa romantica del programmatore. Un agente può proporre di risalire linearmente il log per trovare quando una modifica è arrivata su main. La query può anche restituire il risultato corretto; a quella scala, però, potrebbe essere l’operazione sbagliata da eseguire. La competenza sta nel conoscere l’indice o il servizio che esprime quella domanda al costo giusto. E nel rifiutare una soluzione funzionante che degrada l’insieme.

La stessa tensione si vede nella review avversariale. Anthropic la considera utile ma segnala casi di eccesso di difese e validazioni, quando un agente tenta di proteggersi da scenari ipotetici introducendo complessità non necessaria. La verifica non è aggiungere controlli senza fine: è capire quali rischi esistono davvero e chi può assumerne la responsabilità.

La CI dopo il merge è una scelta, non una scorciatoia

Con centinaia di cambiamenti che possono essere integrati mentre una suite di test è ancora in esecuzione, il modello di una singola coda globale bloccante diventa difficile da mantenere. Anthropic dice di aver investito maggiormente in test post-merge e pre-deploy invece di riprodurre il lock globale tradizionale. Accetta che cambiamenti concorrenti possano entrare in conflitto, confidando nella capacità di rilevarli e risolverli rapidamente.

Qui bisogna essere precisi: non è la dimostrazione che testare dopo sia sempre meglio. È la descrizione di un sistema che ha scelto un diverso punto di controllo perché il costo dell’attesa era diventato enorme. La sicurezza di quella scelta dipende da isolamento, reversibilità, test affidabili, osservabilità e capacità di impedire che una regressione arrivi agli utenti. Senza questi presupposti, togliere un gate non aumenta la produttività: sposta semplicemente il guasto più avanti.

Il tema si collega a un altro caso già analizzato: l’architettura GitHub in cui più repliche potevano rallentare i push. Sono due sistemi diversi, ma la lezione comune è la stessa: se accoppi letture, scritture e coordinamento nello stesso meccanismo, prima o poi il costo di una dimensione determina la capacità delle altre.

Cosa imparare senza costruirsi un altro Git

Per quasi tutte le aziende, migrare a un VCS proprietario sarebbe un modo eccellente per aggiungere complessità a un problema che non hanno. Anthropic lo dice esplicitamente: Scion non è pensato come sostituto generalista, richiede code review, ricerca e CI progettate intorno a un modello diverso, e il suo profilo di consumo interno di modelli non è rappresentativo di quello di un’impresa normale.

La lezione applicabile è più modesta e più utile. Prima di sostituire uno strumento, misurare quanto lavoro ripetitivo gli chiediamo: quante copie integrali creiamo, quante query richiedono davvero file locali, quali passaggi serializzano inutilmente la pipeline, quanto tempo passa fra una modifica proposta e una modifica verificata. Poi distinguere ciò che deve restare disponibile offline da ciò che può essere servito come API, ciò che richiede coerenza globale da ciò che può essere calcolato in modo incrementale.

Gli agenti hanno accelerato una fase del processo e reso visibili i costi delle altre. Non significa che Git sia diventato obsoleto. Significa che, quando il profilo di carico cambia di un ordine di grandezza, la domanda giusta non è quale strumento sia più moderno. È quale promessa architetturale stiamo pagando, quante volte al giorno, e se ci serve ancora.