Ripensare il controllo del codice sorgente in Anthropic: Claude ha superato Git

Anthropic ha sostituito Git dopo che Claude ha contribuito a far crescere il suo monorepo da circa 2.500 merge giornalieri nel maggio 2026 a oltre 30.000 entro settembre. Questa impennata rende il ripensamento del controllo del codice sorgente in Anthropic molto più di una storia di migrazione infrastrutturale. Mostra cosa accade quando l'AI genera codice più rapidamente di quanto i sistemi di sviluppo possano assorbirlo in sicurezza.

L'azienda ha sviluppato Scion, un sistema interno di controllo del codice sorgente progettato attorno ad agenti online, operazioni lato server e accesso selettivo a un enorme repository. Sette ingegneri hanno inoltre creato Antique, un nuovo sistema di code review, insieme a diversi servizi correlati. Anthropic afferma che il team ha completato la migrazione in cinque mesi.

Il conflitto importante non è semplicemente Scion contro Git. È la produzione di codice alla scala degli agenti contro pratiche di sviluppo progettate attorno all'attenzione umana. Google e Meta hanno già sviluppato sistemi specializzati per monorepo enormi. Anthropic è arrivata a una destinazione simile attraverso una fonte di pressione diversa: sciami di agenti software che non hanno mai bisogno di lavorare offline.

Il ripensamento del controllo del codice sorgente in Anthropic è iniziato con 30.000 merge giornalieri

Anthropic non ha abbandonato Git perché ai suoi ingegneri non piacesse Git. Lo ha abbandonato perché Claude ha cambiato la forma e il volume del traffico nel repository.

Secondo il resoconto tecnico di Anthropic, i merge giornalieri sono aumentati di oltre dieci volte tra maggio e settembre 2026. L'azienda presenta questa crescita come una domanda continuativa, non come un picco temporaneo dovuto alla migrazione.

Il carico di lavoro risultante andava ben oltre la creazione di commit. La cronologia del ramo principale di Anthropic si avvicinava a 100 GB, mentre una copia di lavoro compressa superava i 25 GB. L'integrazione continua, o CI, effettuava circa 25 milioni di checkout del codice al giorno, prima ancora di contare gli ambienti per sviluppatori, le sandbox degli agenti e i job di ricerca.

Anthropic ha calcolato che recuperare questi checkout in modo ingenuo avrebbe generato oltre 600 petabyte di traffico Git giornaliero. L'azienda ha usato shallow clone, sparse checkout, snapshot del repository e diverse centinaia di mirror Git interni per controllare questo costo.

Queste misure hanno fatto guadagnare tempo, ma il repository ha continuato a cambiare più velocemente. Gli snapshot diventavano obsoleti tra un aggiornamento e l'altro. Anche i clone parziali complicavano operazioni come le ricerche nella cronologia, i diff e il blame, che identifica chi ha modificato per ultimo una riga.

Il problema dell'azienda derivava da una discrepanza tra i punti di forza di Git e i client predominanti di Anthropic. Git fornisce a ogni clone informazioni sufficienti per operare come repository autosufficiente. Questo design supporta lo sviluppo offline, la cronologia locale e la collaborazione decentralizzata.

Gli agenti e i job automatizzati di Anthropic erano già online. Non avevano bisogno della cronologia locale completa né della capacità di agire come server indipendenti. Eppure l'infrastruttura distribuiva e manteneva ripetutamente i dati del repository come se ogni client fosse uno sviluppatore umano con un laptop.

Scion ribalta questa ipotesi. Il suo server esegue query sulla cronologia, crea commit, calcola diff e gestisce merge o rebase. Un client leggero mantiene una cache con dimensione limitata e materializza soltanto i file richiesti dall'attività corrente.

Questa differenza conta quando un job di ricerca necessita di una directory anziché dell'intero monorepo. Conta anche quando un servizio CI ha bisogno soltanto di un diff o del calcolo di una merge base. Scion può rispondere a queste richieste tramite API senza creare una tradizionale copia di lavoro.

Secondo Anthropic, la nuova architettura ha prodotto notevoli miglioramenti interni. Ogni livello della cache mantiene, a quanto riferito, un hit rate superiore al 99%. L'infrastruttura usa 200 volte meno CPU e memoria rispetto alla precedente flotta di mirror Git.

Anthropic afferma inoltre che i checkout CI e di ricerca sono passati da minuti a secondi. Il cambiamento ha restituito il 25% della capacità CPU della CI alla più ampia flotta di calcolo.

Si tratta di misurazioni riportate dall'azienda su un sistema interno. Ricercatori esterni non possono riprodurle senza accesso ai carichi di lavoro, ai repository e all'infrastruttura di Anthropic. Tuttavia, i numeri spiegano perché un altro giro di ottimizzazioni di Git non apparisse più sufficiente.

Il sistema doveva supportare più di un grande repository. Doveva supportare un repository i cui principali autori, lettori e consumatori automatizzati operavano alla velocità delle macchine.

Claude ha trasformato l'infrastruttura software nel collo di bottiglia

Il vero significato di Scion è che la generazione di codice ha smesso di essere la risorsa scarsa di Anthropic. Capacità di revisione, infrastruttura e giudizio sono diventati i vincoli.

In origine, gli assistenti AI per la programmazione si inserivano in un processo di sviluppo familiare. Una persona richiedeva una funzione, ispezionava l'output, eseguiva i test e inviava una pull request. L'assistente aumentava la velocità di digitazione di un singolo sviluppatore senza modificare il sistema circostante.

Anthropic descrive un modello operativo più avanzato. Claude, secondo quanto riferito, procede in cicli di ricerca, ottimizza programmi complessi, crea servizi, monitora componenti in produzione e assiste nelle grandi migrazioni. Ogni attività può produrre nuove modifiche o richiedere nuovo accesso al repository.

Questo schema crea una pressione moltiplicativa. Un agente può avviare un'altra attività mentre una modifica precedente passa attraverso i test. I revisori automatizzati possono richiedere correzioni, che producono modifiche aggiuntive. I sistemi CI creano quindi checkout e invocano ulteriori query sul repository per ogni candidato.

Il grafico evidenziato da Simon Willison mostra un netto aumento nel corso del 2026. Willison ha collegato l'accelerazione alle più recenti generazioni di modelli interni di Anthropic, distinguendo con cautela la disponibilità interna dalle date di rilascio pubblico.

Anthropic stabilisce un collegamento più specifico. Afferma che lo sviluppo di Scion è iniziato nel periodo in cui Claude Mythos Preview e Claude Tag sono diventati disponibili internamente. Questi modelli, secondo quanto riportato, hanno aumentato la necessità di Scion contribuendo al contempo alla sua realizzazione.

Un esempio ha riguardato la pipeline che trasferiva dati da Git a Scion. Gli ingegneri di Anthropic avevano scritto a mano un prototipo iniziale. Una prima versione interna di Claude Mythos Preview ha poi riscritto la pipeline con poche istruzioni aggiuntive.

La sostituzione avrebbe usato 20 volte meno memoria e funzionato quattro volte più velocemente. Anthropic afferma che ha preservato requisiti impliciti riguardanti l'ordine di ingestione e le strutture dati. L'affermazione è notevole, ma rimane un risultato descritto dall'azienda e non un benchmark indipendente.

Il ciclo di feedback più ampio è più facile da stabilire. Una generazione di codice più rapida ha aumentato l'attività nel repository. Tale attività ha giustificato una nuova infrastruttura. Claude ha quindi contribuito a costruire l'infrastruttura, rimuovendo un altro limite alla generazione di codice.

Questo ciclo mette sotto pressione ogni parte del ciclo di vita dello sviluppo. Un servizio di build che gestisce modifiche al ritmo umano può diventare costoso quando gli agenti creano migliaia di attività simultanee. Una coda di revisione diventa meno utile se il repository avanza di centinaia di modifiche mentre viene eseguita una suite di test.

Anche l'accesso alla conoscenza diventa parte del vincolo. Gli agenti necessitano di specifiche, decisioni architetturali, cronologia degli incidenti e contesto sulle responsabilità, non solo dei file sorgente. I team che sviluppano flussi di lavoro simili hanno bisogno di una base di conoscenza ingegneristica ricercabile accanto a un'infrastruttura di codice più rapida.

Anthropic afferma di utilizzare ora monitor Claude persistenti chiamati “superfan” per singoli componenti di Scion. Questi agenti osservano telemetria e log attraverso canali Slack dedicati. Gli avvisi tradizionali rimangono attivi, mentre gli agenti cercano schemi che soglie fisse potrebbero non rilevare.

Questo modello operativo sposta il lavoro ingegneristico verso un livello più alto. Le persone definiscono gli invarianti, scelgono i confini architetturali, interpretano i guasti e decidono cosa debba arrivare in produzione. Gli agenti generano implementazioni e indagano la telemetria entro tali confini.

Il cambiamento non elimina l'ingegnere. Trasforma la competenza scarsa dalla produzione di codice alla decisione su quale codice meriti di esistere.

Scion sostituisce il modello offline di Git con un servizio alla scala degli agenti

Scion ottiene maggiore throughput rinunciando alla simmetria che definisce Git: un client non porta più con sé l'intera intelligenza del repository.

I commit Git contengono puntatori ad alberi completi di directory. I client scambiano raccolte compresse di oggetti chiamate packfile, consentendo ai repository locali di preservare la cronologia e operare in modo indipendente. Questo modello resta appropriato per la maggior parte dei progetti software.

Scion usa un changeset, una voce in un write-ahead log che registra i file modificati rispetto a un genitore. I contenuti dei file sono compressi, indirizzati in base al contenuto e archiviati separatamente. L'indirizzamento basato sul contenuto significa che la chiave di archiviazione deriva dai dati, perciò gli oggetti immutabili possono essere memorizzati nella cache in sicurezza.

I changeset vengono creati sul server e diventano disponibili nell'intero sistema. Non richiedono che un client costruisca e carichi un grande packfile. Evitano inoltre di spostare un puntatore globale del ramo durante ogni operazione di commit.

Scion supporta comunque i riferimenti, ossia puntatori come rami e tag. Tuttavia, Anthropic scoraggia la maggior parte dei riferimenti oltre alla linea principale e ai rami di rilascio. Lo stato coordinato globalmente diventa sempre più costoso all'aumentare dei tassi di commit.

Il sistema calcola separatamente le informazioni sulla cronologia come dati derivati. Costruisce indici dedicati per la cronologia dei file, il blame, la copia e le relazioni all'interno del grafo dei commit. Tali indici possono essere generati immediatamente o rinviati finché un consumatore non li richiede.

Questa separazione consente ad Anthropic di modificare un indice senza cambiare ogni client. Permette inoltre al servizio di evitare il calcolo di dati che non servono a nessuna attività.

Il protocollo di checkout di Scion segue lo stesso principio. I client richiedono alberi e oggetti file specifici anziché negoziare un quadro completo di ciò che già possiedono. I server cache regionali possono soddisfare la maggior parte delle richieste perché gli oggetti archiviati non cambiano mai.

Un daemon su ciascun nodo di calcolo condivide gli oggetti memorizzati nella cache tra i job locali. I servizi cache regionali si collocano quindi tra questi daemon e i server Scion autorevoli. Anthropic impone questa gerarchia per evitare che un guasto della cache regionale sovraccarichi il servizio centrale.

Gli sparse checkout richiedono solo directory selezionate. I checkout virtualizzati creano file quando un processo li legge. Alcuni job saltano completamente il filesystem e richiedono all'API un diff, un risultato della cronologia o una merge base.

Questo design ricorda precedenti risposte alla scala dei monorepo. Google ha descritto Piper come parte dell'infrastruttura a supporto di un'enorme codebase centralizzata. La sua analisi del monorepo ha documentato i vantaggi del codice condiviso, delle dipendenze unificate e delle modifiche a livello dell'intera organizzazione.

Meta ha seguito un'altra strada con Sapling, un sistema che conserva concetti familiari di controllo del codice sorgente distribuito, pur scalando al proprio repository interno. Meta afferma che il suo server può gestire decine di milioni di file, commit e rami. Il design pubblico di Sapling supporta inoltre i repository Git e i flussi di lavoro degli sviluppatori locali.

Scion prende in prestito lezioni da entrambe le storie, ma la sua ipotesi principale è più ristretta. Il client dominante è sempre online, spesso automatizzato, e difficilmente ha bisogno di un intero repository. Questo rende il server un database di controllo versione e un servizio di calcolo, anziché un partner di sincronizzazione.

Il compromesso è la dipendenza. Un client Scion non può riprodurre il pieno comportamento offline di Git perché conserva deliberatamente meno dati ed esegue meno operazioni in locale. Un guasto di rete o del servizio centrale assume quindi un peso diverso.

I costi di migrazione vanno anche oltre il client da riga di comando. Anthropic ha dovuto realizzare la ricerca nel codice, i controlli di identità e accesso, le integrazioni CI e Antique. Un’azienda che adottasse lo stesso design dovrebbe sostituire gran parte della propria piattaforma di sviluppo.

Questo spiega perché Scion non è un’alternativa Anthropic a Git per i team ordinari. È un sistema verticalmente integrato per un unico carico di lavoro eccezionale.

Merge più rapidi rendono la revisione del codice il problema più difficile

La questione irrisolta non è se Scion possa accettare 30.000 modifiche. È se Anthropic riesca a preservare la responsabilità a quella velocità.

Anthropic afferma che ogni modifica in Scion riceve ancora una revisione umana. Ora i revisori si concentrano sull’intento di una modifica invece di leggere ogni riga. Questa scelta deriva dal volume, ma sposta anche la fiducia verso i test, le spiegazioni degli agenti e l’analisi automatizzata.

La revisione dell’intento chiede se una modifica proposta sia coerente con gli obiettivi del sistema e le regole architetturali. La revisione riga per riga chiede se la sua implementazione si comporti correttamente. Solidi controlli automatizzati possono collegare questi due livelli, ma nessuna suite di test cattura ogni requisito nascosto.

Anthropic riconosce che gli ingegneri hanno spesso dovuto dire “no” a Claude. Gli agenti talvolta selezionavano schemi plausibili a livello locale che violavano vincoli dell’intero sistema. Alcuni componenti generati tentavano di analizzare linearmente il log dei commit invece di interrogare Antique per ottenere un momento di merge autorevole.

La revisione avversariale ha creato un’altra modalità di errore. Claude poteva rispondere a rischi ipotetici con validazioni e complessità eccessive. Gli ingegneri umani dovevano decidere quando la programmazione difensiva smetteva di migliorare il sistema.

Questi esempi complicano l’affermazione semplicistica secondo cui modelli migliori producono direttamente software migliore. Gli agenti possono individuare ottimizzazioni preziose creando al contempo meccanismi non necessari. Un elevato volume di output amplifica entrambi i comportamenti.

Anthropic afferma che il suo team ha sviluppato simulazioni, fuzz testing e limiti di velocità per Scion. Il fuzzing fornisce input inattesi per individuare difetti, mentre le simulazioni ermetiche riproducono il comportamento dell’infrastruttura in ambienti isolati. Questi controlli offrono prove più solide dei soli conteggi dei merge.

Tuttavia, il volume dei merge non è una metrica di qualità. Una modifica può essere minuscola, sperimentale, generata, annullata o non correlata ai progressi rivolti ai clienti. Trentamila modifiche giornaliere rivelano un’attività straordinaria, ma non dimostrano in modo indipendente affidabilità o valore aziendale.

Le reazioni pubbliche degli sviluppatori si sono concentrate su questa distinzione. Nella discussione su Hacker News, alcuni lettori si sono chiesti se Anthropic dovrebbe riconsiderare il suo monorepo. Altri hanno sostenuto che intento, provenienza e verifica continua contino più delle tradizionali meccaniche dei commit.

Un ingegnere di Anthropic che ha risposto in quella discussione ha difeso gli strumenti coerenti e le modifiche atomiche del monorepo. Lo stesso ingegnere ha chiarito che Scion blocca i conflitti testuali, ma non può eliminare i conflitti semantici tra modifiche concorrenti.

Un conflitto semantico si verifica quando due modifiche individualmente valide producono insieme un comportamento errato. Una modifica potrebbe alterare una funzione e aggiornarne i chiamanti, mentre un’altra aggiunge contemporaneamente un nuovo chiamante. I file possono essere uniti senza conflitti, anche se il programma risultante è errato.

Le code di merge tradizionali riducono questo rischio testando uno stato proposto del repository prima di accettare il lotto successivo. Anthropic afferma che un blocco globale del repository diventa impraticabile quando centinaia o migliaia di modifiche vengono integrate durante l’esecuzione di un test.

L’azienda ha spostato gli investimenti verso test post-merge e pre-deployment. Questo approccio consente al throughput del repository di proseguire mentre i controlli stabiliscono cosa possa raggiungere la produzione in sicurezza.

Questo è il compromesso centrale di Redesigning source control at Anthropic. Scion rimuove la serializzazione dal controllo versione, ma una qualche forma di serializzazione esiste ancora nei punti di deployment, migrazione dei dati o decisione umana. Il rischio si sposta, anziché scomparire.

Anthropic afferma che Claude può risolvere conflitti concorrenti più rapidamente di quanto le persone possano identificarli. Questa risposta riguarda la velocità di riparazione, non il costo di un’interazione non rilevata. La sicurezza dipende dalla rapidità con cui il monitoraggio rileva un problema e dall’efficacia con cui i sistemi lo isolano o lo annullano.

I controlli di accesso a livello di directory e le regole di approvazione semantica aiutano. Secondo Anthropic, Antique può distinguere una modifica che riguarda solo commenti da una modifica alla logica sensibile. L’attenzione umana può quindi concentrarsi sulle modifiche con conseguenze maggiori.

Il divario di verifica residuo è sostanziale. Anthropic non ha pubblicato tassi indipendenti di difetti, frequenza dei rollback, tendenze degli incidenti o la proporzione di modifiche scritte e revisionate dagli agenti. Senza queste misure, gli esterni non possono confrontare i guadagni di throughput con il rischio a valle.

La lezione più utile per gli altri team non è quindi inseguire il conteggio dei merge di Anthropic. È misurare l’intero percorso dalla specifica al deployment. Indicatori utili includono difetti sfuggiti ai controlli, latenza della revisione, modifiche fallite, rollback, lavoro duplicato e tempo dedicato a ripristinare il contesto.

Un workflow AI personale può aiutare gli ingegneri a preservare decisioni e provenienza mentre gli agenti generano più materiale. Tuttavia, il contesto archiviato è utile solo quando i team lo collegano a test applicabili, responsabilità e politiche di revisione.

Cosa cambia dopo l’esperimento di Anthropic sul controllo versione

La fase successiva verificherà se lo sviluppo su scala degli agenti diventerà un modello ingegneristico trasferibile o rimarrà una costosa eccezione di Anthropic.

Il primo segnale da osservare è l’annunciata discussione di Anthropic su Antique. Il controllo versione spiega come le modifiche siano archiviate e recuperate, ma la revisione del codice determina come intento, responsabilità e approvazione sopravvivano a un volume estremo.

I dettagli sul modello di revisione di Antique rafforzerebbero l’argomentazione di Anthropic se mostrassero una chiara provenienza e un intervento umano basato sul rischio. L’argomentazione si indebolirebbe se la revisione dipendesse principalmente da riepiloghi del modello senza una validazione misurabile.

Il secondo segnale è la qualità del software nel tempo. Le affermazioni di Anthropic sull’infrastruttura avranno maggiore peso se l’azienda pubblicherà tassi di rollback, difetti sfuggiti ai controlli, incidenti di servizio o altre misure di risultato insieme al throughput dei merge.

Un’affidabilità stabile o in miglioramento sosterrebbe l’idea che gli agenti possano aumentare il volume delle modifiche senza incrementare proporzionalmente il rischio. Un aumento delle regressioni o delle riparazioni d’emergenza suggerirebbe che Scion abbia accelerato la produzione più della governance.

Il terzo segnale riguarda la risposta delle piattaforme Git e delle grandi organizzazioni ingegneristiche. La maggior parte delle aziende non sostituirà Git, ma potrà adottare API di metadati lato server, spazi di lavoro virtualizzati, revisioni sensibili al rischio e un migliore supporto agli agenti paralleli.

Sapling di Meta dimostra già un percorso che mantiene la compatibilità con workflow familiari. Scalar di Microsoft e i relativi miglioramenti a Git dimostrano un altro approccio, estendendo Git per repository di grandi dimensioni invece di sostituirne il modello di dati.

Anthropic stessa prevede che queste pressioni si diffonderanno entro sei-dodici mesi. Questa previsione è una valutazione aziendale, non una tendenza di mercato misurata. La sua rilevanza dipende dal fatto che altre organizzazioni raggiungano limiti simili senza l’accesso interno ai token di Anthropic e l’insolita concentrazione dell’uso di Claude.

Scion introduce inoltre una dipendenza strategica che i concorrenti potrebbero evitare. Anthropic controlla il modello, il servizio repository, la superficie di revisione, gli agenti di osservabilità e il workflow di deployment. Questa integrazione accelera l’iterazione, ma rende l’ambiente di sviluppo più difficile da riprodurre o sostituire.

Per la maggior parte delle organizzazioni, Git rimarrà la scelta sensata. Offre ampia interoperabilità, strumenti maturi, cronologia portabile e resilienza offline. L’architettura di Scion diventa interessante solo quando il traffico del repository ha già sopraffatto tali vantaggi.

Il cambiamento più immediato riguarda la gestione. I responsabili dell’ingegneria devono smettere di considerare il volume di codice generato come l’obiettivo. Un maggiore output crea valore solo quando i team possono revisionarlo, testarlo, distribuirlo, osservarlo e annullarlo in sicurezza.

Anche gli sviluppatori dovrebbero aspettarsi un cambiamento nel proprio lavoro. Il resoconto di Anthropic attribuisce maggiore importanza alla progettazione di sistema, ai vincoli architetturali, alla valutazione e al rifiuto. L’ingegnere definisce sempre più il confine entro cui un agente può muoversi rapidamente.

Redesigning source control at Anthropic offre quindi un avvertimento insieme alla sua storia di prestazioni. Quando il codice diventa economico, ogni specifica debole, test mancante e confine di responsabilità poco chiaro può essere riprodotto alla velocità delle macchine.

La domanda utile non è se il vostro team abbia bisogno di Scion. È se i vostri attuali sistemi di revisione, CI e conoscenza rimarrebbero affidabili se gli agenti producessero dieci volte più modifiche il prossimo trimestre. Misurate questa capacità ora, individuate il primo controllo che fallisce e rafforzatelo prima che arrivi un volume di merge più elevato.