Immaginate di essere una startup AI. I vostri agenti scrivono così tanto codice che Git — sì, proprio Git, lo strumento che ha retto milioni di sviluppatori per quasi vent’anni — inizia a implorarvi pietà. Ora immaginate di dover costruire un sistema di version control completamente nuovo, migrare tutto il vostro monorepo, e farlo in cinque mesi. Con sette persone.
Benvenuti in Anthropic, dove il problema non è più scrivere codice. È gestirlo.
Quando Git diventa il collo di bottiglia
A maggio 2026, Anthropic faceva circa 2.500 merge al giorno. A settembre? Oltre 30.000. Trentamila modifiche al giorno. E non si aspettano che rallenti.
Il motivo è semplice: Claude non si limita più a suggerire codice. Itera autonomamente su loop di ricerca, ottimizza programmi complessi, costruisce servizi da zero. La velocità con cui produce codice ha superato — e di parecchio — la capacità dell’infrastruttura di stargli dietro. Git, build system, CI: tutto quello che funzionava per gli esseri umani ha iniziato a scricchiolare.
Il monorepo è cresciuto fino a quasi 100 GB di storia solo sul branch principale. Una copia di lavoro compressa pesa oltre 25 GB. Anthropic fa circa 25 milioni di checkout al giorno per CI, job di ricerca, sandbox degli agenti. Se scaricassero tutto in modo naive, sarebbero oltre 600 petabyte di traffico Git. Al giorno.
Hanno provato tutto: shallow clone, sparse checkout, mirror interni (a un certo punto ne avevano centinaia), snapshot in blob storage. Ha funzionato per un po’. Poi ha smesso di funzionare.
Ripensare tutto da zero: Scion
A quel punto si sono fatti una domanda semplice ma radicale: se dovessimo progettare un sistema di version control sapendo che i client sono sempre online — perché sono agenti, job, pipeline — come sarebbe?
La risposta è Scion. Un sistema di version control interno costruito e messo in produzione in cinque mesi, insieme ad Antique (il loro tool di code review), code search, IAM avanzato, e altro ancora. Sempre in quei cinque mesi. Con sette persone.
Scion parte da principi completamente diversi da Git:
- I client sono sempre online. Git assume che lavori offline e ti serve una copia completa del repo. Scion assume il contrario: il server è sempre raggiungibile, il client scarica solo quello che gli serve, quando gli serve.
- Asimmetria client-server. In Git ogni client può essere un server. In Scion il server fa tutto il lavoro pesante — merge, rebase, blame, history — e il client mantiene solo una cache locale limitata e materializza i file su disco.
- Scalabilità orizzontale. In Scion non esiste una copia completa del repo da nessuna parte, nemmeno sul server. I dati sono distribuiti, ogni componente scala indipendentemente. Niente packfile, niente manutenzione del repository.
- Commit veloci e senza lock. Ogni commit, rebase o merge avviene server-side, ma deve essere velocissimo. Il costo scala con la dimensione del cambiamento, non con la dimensione del repo.
- La working copy è opzionale. Molti job CI possono chiedere al server un diff senza scaricare nulla. Quando serve un checkout, il client materializza solo le directory richieste.
Il risultato: un’infrastruttura 200 volte più piccola rispetto ai mirror Git in termini di CPU e memoria. I checkout sono due ordini di grandezza più veloci — secondi invece di minuti. Solo la CI ha guadagnato il 25% di capacità CPU.
Come funziona Scion
L’unità di lavoro è un changeset, una entry in un write-ahead log. Memorizza le informazioni del commit, ma invece di puntare a un tree completo registra solo i file cambiati rispetto al primo parent, con puntatori content-addressed ai blob compressi in storage.
I changeset vengono creati server-side e sono disponibili ovunque, istantaneamente. Niente lock, niente coordinazione cross-server, niente ref da spostare. Tecnicamente Scion supporta le ref, ma spostarle è solo un compare-and-swap su una singola riga Spanner, separato dalla creazione dei changeset.
Un changeset da solo non può rispondere velocemente a domande tipo “chi ha editato per ultimo questa riga”. Per questo Scion costruisce strutture dati aggiuntive dai changeset: indici per blame, path history, skip list per il commit graph. Le chiamano derived data, calcolate con un meccanismo generico e ricorsivo.
Tre vantaggi: possono aggiungere nuovi tipi di derived data quando serve, scegliere se calcolarli subito o in differita, e ottimizzarli senza cambiare il client. Lo hanno fatto molte volte — nuovi indici per copy detection, ricerca path-based, e altro.
L’architettura di checkout
Il client parla con un daemon locale, scion-daemon, che memorizza gli oggetti per tutto il nodo. La maggior parte dei nodi ha bisogno del monorepo, e i job sullo stesso nodo riutilizzano gli stessi oggetti. Ogni daemon parte da uno snapshot periodico, poi parla solo con i server di cache nella sua region, i scion-cache, che servono oggetti direttamente dalla memoria nel formato che il daemon consumerà, senza delta compression.
Quando una cache non ha un oggetto, lo chiede ai scion-server autoritativi, che leggono da Spanner o cloud storage. Ogni tier mantiene un cache hit rate oltre il 99%, non richiede stato long-lived, ed è facile da scalare.
Il protocollo differisce da Git in un punto fondamentale: il client non dice al server cosa ha già. Opera esclusivamente sugli oggetti che vuole. Parte da un root tree, controlla il suo store locale per tree mancanti e li richiede ricorsivamente, poi ripete per i blob. Ogni richiesta riguarda un oggetto specifico che non cambia mai, quindi qualsiasi cache può rispondere. Niente packfile multi-gigabyte. Sparse e virtualized checkout non richiedono supporto speciale: il client semplicemente non chiede i tree che non vuole.
Claude ha riscritto Claude
Hanno iniziato a costruire Scion più o meno quando Claude Mythos Preview e Claude Tag sono diventati disponibili internamente. Entrambi i rilasci hanno amplificato il bisogno di Scion e accelerato la velocità con cui potevano costruirlo.
Un esempio: all’inizio dell’anno avevano scritto a mano la prima versione della pipeline di ingestion da Git a Scion. Pensavano fosse buona. Poi hanno ottenuto una snapshot interna di Claude Mythos Preview e gli hanno chiesto di riscrivere tutto. Senza ulteriori istruzioni, Claude ha prodotto una versione che consumava 20 volte meno memoria ed era 4 volte più veloce, preservando tutte le invarianti implicite su ordinamento e strutture dati.
Sette persone hanno costruito Scion, Antique, e mezza dozzina di sistemi correlati in cinque mesi, mentre il volume di merge giornalieri aumentava di 10x. In passato un progetto del genere avrebbe richiesto anni e molti più ingegneri.
Gli ingegneri valgono ancora. Ma il loro lavoro sta cambiando
Tutti gli ingegneri che hanno lavorato su Scion ritengono ora che Claude scriva codice meglio di loro. Ma sono stati loro a fornire la comprensione dei componenti ad alto livello, i tradeoff di design, le scelte informate sui problemi da risolvere e sulla scala da raggiungere.
Spesso il ruolo degli ingegneri era dire a Claude “no”. Gli agenti a volte violano vincoli fondamentali del sistema per soddisfare pattern che non avrebbero mai dovuto essere permessi. Per esempio, alcuni sistemi provavano a trovare con forza bruta il momento in cui un change era stato mergiato su main leggendo linearmente il commit log, invece di interrogare il tool di code review.
Il team usa anche l’adversarial review in modo estensivo — incredibilmente efficace, ma a volte miope. Gli ingegneri hanno dovuto frenare Claude quando over-engineerava parti del sistema in risposta a preoccupazioni ipotetiche. In un caso, una review era eccessivamente difensiva nel fidarsi di un altro servizio interno, e Claude aveva aggiunto validazione e complessità eccessive.
I membri del team esaminano ancora ogni change request, ma ora guardano l’intento del cambiamento invece di leggere ogni riga di codice.
Nuove forme di monitoraggio
Il team usa Claude Tag intensivamente per monitorare ogni componente del sistema. Hanno creato canali Slack dove Claude ha il compito di essere ossessivamente focalizzato sulla salute di un singolo componente. Li chiamano superfan.
C’è un superfan di scion-daemon, uno di scion-cache, uno della merge queue di Antique. Hanno accesso a telemetria e log, e si comportano come un ingegnere esperto che non ha niente di meglio da fare che controllare i chart e cercare anomalie. Gli alert tradizionali ci sono ancora, ma i superfan rilevano problemi sottili e nuovi che quegli alert non intercetterebbero.
E Git?
Scion non è un sostituto di Git per uso generale. I principi su cui si basa hanno senso solo per monorepo davvero enormi, con decine di migliaia di ingegneri o sciami di agenti che scrivono codice prolificamente. Anthropic è anche un caso particolare: la loro capacità di spendere token per uso interno supera di gran lunga quello che qualsiasi altra azienda vorrebbe realisticamente spendere, sia per le proprie esigenze di sviluppo, sia per testare le capacità di Claude.
Offrire Scion in una forma ampiamente utilizzabile è difficile. Diverge significativamente da Git, quindi le aziende dovrebbero migrare ogni pezzo del development lifecycle. E le versioni interne di code review, code search e CI sono altamente specifiche per Anthropic.
Il team si aspetta però che questa classe di problemi diventi più comune nei prossimi sei-dodici mesi. Sarebbe inefficiente che ogni azienda che usa Git affrontasse le stesse sfide da sola. La cosa più utile che possono fare è condividere il loro approccio, in modo che altri sviluppatori possano applicare le parti più efficaci di Scion a Git senza abbandonare il modello complessivo.
Un server Git non deve funzionare come un client Git. Architetture server innovative esistono e offrono miglioramenti significativi in termini di scaling. Le piattaforme Git possono esporre RPC server-side complete come Scion, forse in modo standardizzato. Il protocollo di negoziazione non deve restare quello attuale, e le varie funzionalità sparse e shallow in Git possono essere fatte comporre meglio.
Il team riconosce che la community Git ha passato quasi due decenni a scalare la piattaforma per milioni di sviluppatori. Il loro contributo è più ristretto: condividere una visione anticipata di come lo sviluppo software agenticointeragisce con questi sistemi, per collaborare con GitHub, GitLab e la community OSS nel supportare le esigenze in evoluzione degli sviluppatori.
