Scion di Anthropic: Sostituire Git per lo Sviluppo su Scala AI
Il Punto di Rottura di Git: Il Diluvio di Codice AI
Anthropic ha un problema che molte aziende invidierebbero: Claude, la loro AI, scrive codice in modo così prolifico che la loro infrastruttura di sviluppo sta collassando sotto il peso. A maggio 2026, l'azienda aveva in media circa 2.500 modifiche al codice unite al giorno. A settembre, quel numero era esploso a oltre 30.000 fusioni giornaliere, un aumento di oltre dieci volte in soli cinque mesi.
Questo aumento non ha solo stressato i loro sistemi; li ha rotti. Git, il sistema di controllo versione decentralizzato che alimenta lo sviluppo software moderno, non è mai stato progettato per questa scala. Mentre il monorepo di Anthropic cresceva fino a quasi 100 GB di storia e 25 GB di copie di lavoro compresse, l'azienda si è trovata di fronte a una situazione impossibile: 25 milioni di checkout giornalieri solo per la CI genererebbero oltre 600 PB di traffico di rete se recuperati ingenuamente.
Il risultato è stato Scion, un sostituto interno completo di Git. Un team di sette ingegneri ha costruito Scion, uno strumento di revisione del codice chiamato Antique, la ricerca del codice e un sistema IAM, quindi ha migrato l'intero monorepo in soli cinque mesi. È un caso di studio su come l'AI non stia solo cambiando ciò che costruiamo, ma anche come lo costruiamo.
Perché Git ha Fallito a Scala di Agenti
Il design fondamentale di Git presuppone un lavoro distribuito e offline. Ogni clone è un repository completo, in grado di calcolare diff, leggere la storia ed eseguire il checkout delle revisioni senza un server. Per la maggior parte dei progetti, questa è una caratteristica. Per Anthropic, è diventato un limite.
"Quasi tutti i nostri client sono agenti e lavori che sono online per definizione," ha notato l'azienda. Le proprietà che rendono Git eccellente per il lavoro distribuito stavano attivamente minando la capacità di Anthropic di scalare. Avevano distribuito centinaia di mirror git interni per gestire il carico, ma questi sono diventati sempre più difficili da gestire man mano che i tassi di fusione aumentavano. I seed (istantanee del repository) si allontanavano ulteriormente dalla punta del main tra gli aggiornamenti, e operazioni come diff e blame si rompevano sui cloni parziali.
L'intuizione di Anthropic è stata che stavano usando Git come un sistema centralizzato con una copia autorevole, ma tutti gli strumenti presupponevano la decentralizzazione. Quindi si sono chiesti: come sarebbe il controllo del codice se progettato fin dall'inizio per agenti sempre online?
Architettura di Scion: Server-Centric e Orizzontalmente Scalabile
Scion inverte le ipotesi fondamentali di Git. Invece di client che detengono repository completi, il server di Scion risponde a domande su storia, blame, commit, fusioni e rebase. I client mantengono una cache locale di oggetti limitata, dispongono copie di lavoro su disco e monitorano le modifiche al filesystem, ma calcolano molto poco da soli.
L'unità di lavoro è un "changeset", una voce in un log write-ahead. A differenza di un commit Git che punta a un albero completo, un changeset memorizza solo i file che sono cambiati rispetto al suo genitore, insieme a puntatori content-addressed a blob compressi. Questa struttura consente un'accettazione ad alta produttività perché non ci sono packfile da elaborare, nessun blocco e nessuna coordinazione tra server.
"Tutto deve essere orizzontalmente scalabile," ha sottolineato il team. I dati di Scion sono distribuiti su Spanner e cloud storage; non esiste una copia completamente materializzata da nessuna parte, nemmeno sul server. Questo elimina la necessità di manutenzione del repository e consente a qualsiasi componente di scalare in modo indipendente.
Architettura di Checkout: Impronta 200x Più Piccola
L'architettura di checkout di Scion è un sistema di cache a livelli. Un demone client (scion-daemon) memorizza oggetti per un nodo, partendo da un'istantanea aggiornata periodicamente. Comunica con server cache regionali (scion-cache), che trasmettono oggetti direttamente dalla memoria nel formato disco di cui il demone ha bisogno. Solo quando una cache non trova l'oggetto, interroga i server autorevoli scion-server, che leggono da Spanner o cloud storage.
Questo design raggiunge oltre il 99% di tassi di hit della cache a ogni livello. L'impronta infrastrutturale è 200 volte più piccola della loro precedente configurazione di mirroring git in termini di CPU e memoria. I lavori CI e di ricerca eseguono il checkout del codice due ordini di grandezza più velocemente—secondi invece di minuti—liberando il 25% della capacità della CPU nella sola CI.
Il sistema è anche riprendibile ed efficiente. Non ci sono risposte packfile multi-gigabyte; ogni richiesta è per un oggetto specifico e immutabile a cui qualsiasi cache può rispondere. I checkout sparsi e virtualizzati sono naturali perché i client semplicemente non chiedono alberi che non vogliono.
Lezioni Apprese: Claude ha Costruito la Propria Soluzione
Forse l'aspetto più sorprendente di questa storia è che Claude stesso ha aiutato a costruire Scion. La prima versione del team della pipeline di ingestione da git a Scion è stata scritta a mano. Poi hanno dato a un'istantanea interna anticipata di Claude Mythos Preview il compito di riscriverla. Senza ulteriori istruzioni, Claude ha prodotto una versione che consumava 20 volte meno memoria e girava 4 volte più veloce, preservando tutte le invarianti implicite.
Gli ingegneri del team ora valutano Claude come migliore di loro stessi nello scrivere codice. Ma hanno scoperto che il loro ruolo si è spostato dallo scrivere codice al fare compromessi a livello di design e, cosa cruciale, a dire "no" a Claude. Gli agenti a volte violavano i vincoli fondamentali del sistema o progettavano in modo eccessivo risposte a preoccupazioni ipotetiche da revisioni avversarie.
"I membri del nostro team rivedono ancora ogni richiesta di modifica per il sistema, ma ora esaminano l'intento della modifica invece di leggere ogni riga di codice," spiega il post. Questo cambiamento ha permesso a un team di sette persone di realizzare ciò che tradizionalmente avrebbe richiesto anni e dozzine di ingegneri.
Ridefinire CI, Sicurezza e Revisione per gli Agenti
Le implicazioni di Scion vanno oltre il controllo versione. Il team ha scoperto che le code di fusione tradizionali non hanno senso alla scala degli agenti. Invece di un blocco globale del repository, hanno investito in test automatizzati post-fusione e pre-distribuzione. Le modifiche concorrenti possono entrare in conflitto, ma Claude può risolvere i conflitti più velocemente di quanto gli umani possano identificarli.
Anche la sicurezza è stata ripensata. Scion supporta un controllo degli accessi granulare su repository e singole directory, proteggendo il codice sensibile senza perdere i vantaggi del monorepo. I loro strumenti di revisione del codice possono esprimere vincoli semantici complessi, differenziando le modifiche di solo commento dalle modifiche logiche sensibili in modo che i revisori umani si concentrino su ciò che conta.
L'eccellenza operativa ha raggiunto nuovi livelli con i "superfan"—istanze di Claude incaricate di monitorare ossessivamente singoli componenti. Questi monitor AI accedono a telemetria e log, rilevando problemi sottili che gli avvisi tradizionali perdono. Il team ha un superfan di scion-daemon, un superfan di scion-cache e un superfan della coda di fusione di Antique, tra gli altri.
Cosa Significa per l'Industria
Anthropic riconosce che Scion non è un sostituto generico di Git. Ha senso solo per monorepo davvero enormi con decine di migliaia di ingegneri o sciami di agenti. La capacità dell'azienda di spendere token internamente supera di gran lunga ciò che altre aziende vorrebbero realisticamente.
Tuttavia, prevedono che questa classe di problemi diventerà comune entro 6-12 mesi con la proliferazione degli strumenti di codifica AI. "Pensiamo che la cosa di maggior impatto che possiamo fare sia condividere il nostro pensiero," ha dichiarato il team. Stanno collaborando con GitHub, GitLab e la comunità open source per migliorare l'architettura lato server di Git.
GitLab ha già risposto, notando che l'esperienza di Anthropic "rafforza la direzione architetturale che abbiamo perseguito." GitLab sta costruendo la prossima generazione di SCM per prestazioni a scala di agenti, preservando al contempo la compatibilità con Git. Come ha detto Bill Staples, CEO di GitLab: "Gli agenti AI stanno cambiando fondamentalmente l'economia dello sviluppo software."
Scion di Anthropic non è solo un nuovo sistema di controllo versione—è un progetto di come l'infrastruttura di sviluppo deve evolversi quando l'AI diventa il generatore di codice primario. Il collo di bottiglia si è spostato dallo scrivere codice al gestirlo, e gli strumenti che servivano lo sviluppo su scala umana non sono più sufficienti.
Related News

OpenAI Engineer Arrested for Planting Bug in Executive Conference Room

Google's EmbeddingGemma 2 Repurposed as Blazing-Fast On-Device Speech-to-Text

L'AI è uno strumento: perché la padronanza, non l'adozione, definisce il successo

QGIS Bans AI-Assisted Contributions: A Hard Stance on Open Source Integrity

Pagare Utenti per Testare il Tuo README: Un Risveglio UX per Sviluppatori

