Nell’articolo Intelligence is eating software sono partito da un’idea: quando scrivere codice costa poco, il valore e i problemi si spostano altrove. Ieri, 13 ottobre, Anthropic ha pubblicato sul blog del suo gruppo Engineering un caso concreto di dove si spostano. Fra maggio e settembre le modifiche integrate ogni giorno nel suo monorepo sono passate da circa 2.500 a oltre 30.000. Secondo Anthropic il collo di bottiglia è diventato l’infrastruttura costruita per una velocità tipica delle persone: controllo di versione, build e integrazione continua.
Quando git diventa il collo di bottiglia
I numeri descrivono la scala. La storia del ramo principale pesa quasi 100 GB, una copia di lavoro compressa supera i 25 GB, e la sola integrazione continua esegue circa 25 milioni di checkout al giorno, senza contare ambienti di sviluppo, sandbox degli agenti e job di ricerca. Scaricando il repository in modo ingenuo, stima Anthropic, sarebbero oltre 600 petabyte di traffico git al giorno.
Git è nato decentralizzato: ogni clone è un repository completo che funziona anche offline. Anthropic lo usava invece come un sistema centralizzato, con client quasi tutti sempre connessi, e ha tenuto in piedi la situazione con clone parziali, checkout sparsi e, al picco, diverse centinaia di mirror interni. Con l’aumento delle modifiche quell’architettura era diventata difficile da gestire.
Un controllo di versione costruito per gli agenti
La risposta di Anthropic è Scion, un sistema di controllo di versione interno costruito su sei principi.
- Client sempre online. Il client scarica quello che gli serve quando gli serve, invece di tenere una copia completa.
- Lavoro sul server. Storia, blame, commit, merge e rebase avvengono sul server; il client tiene una cache limitata e prepara i file di lavoro.
- Controllo di versione come servizio. Ogni interrogazione passa da un’API, e molti job, come le pipeline automatiche di bisezione e di revert, non hanno bisogno di un repository locale.
- Scalabilità orizzontale. I dati sono distribuiti, non esiste una copia completa da nessuna parte, nemmeno sul server, e non servono packfile né manutenzione.
- Commit economici e senza lock. L’unità di lavoro è un changeset, una voce di un registro scritta sul server, che elenca i file cambiati rispetto al genitore e punta a contenuti salvati per hash. Aggiornare un riferimento è un’operazione atomica su una singola riga di Spanner, e i rami, a parte il principale e quelli di rilascio, sono scoraggiati.
- Copia di lavoro opzionale e sparsa. La CI può chiedere direttamente le differenze al server, e i checkout materializzano solo i file letti.
Il traffico passa per tre livelli che rispondono alle stesse chiamate: un daemon per nodo, una cache per regione e i server. La separazione è rigida, così il guasto di una cache regionale non travolge i server a monte. Anthropic cita come precedenti Piper di Google e Sapling di Meta.
I risultati
Sette persone hanno costruito Scion e migrato l’intero monorepo in cinque mesi. Nello stesso periodo hanno realizzato anche un sistema di revisione del codice chiamato Antique, la ricerca nel codice e un sistema di permessi per directory.
- Un’infrastruttura circa 200 volte più piccola dei vecchi mirror, in CPU e memoria.
- Checkout di CI e ricerca circa cento volte più veloci, da minuti a secondi.
- Il 25% di capacità di CPU recuperato nella sola CI.
- Una percentuale di risposte servite dalla cache superiore al 99% a ogni livello.
Una versione preliminare interna di Claude ha riscritto la pipeline che importava i dati da git: la nuova usa 20 volte meno memoria ed è 4 volte più veloce, con gli stessi vincoli di ordinamento.
Anthropic è esplicita sui confini del risultato. Scion non sostituisce git in generale, ha senso solo per monorepo molto grandi con molti ingegneri o agenti, e adottarlo vuol dire migrare l’intero ciclo di sviluppo. L’azienda non lo pubblicherà: vuole condividere le idee con GitHub, GitLab e la comunità open source, e prevede che problemi di questa scala diventino comuni entro sei-dodici mesi.
Il lavoro degli ingegneri cambia
La parte più interessante del resoconto di Anthropic riguarda le persone. Gli ingegneri portano la comprensione del sistema e le scelte di progetto, e spesso il loro compito è stato dire «no» a Claude, per esempio quando proponeva di scorrere per forza bruta il registro dei commit invece di interrogare il sistema di revisione. Oggi rivedono l’intento delle modifiche, non ogni riga.
Il funzionamento quotidiano segue la stessa logica. Istanze di Claude dedicate sorvegliano i singoli componenti leggendo telemetria e log, e secondo Anthropic colgono problemi che gli allarmi statici non vedono. La coda di merge con un lock globale è stata abbandonata perché non regge la scala degli agenti: le modifiche vengono integrate e poi testate prima del rilascio. Le modifiche concorrenti possono andare in conflitto, ma di solito Claude risolve i conflitti prima che una persona se ne accorga.
Cosa ne penso
Comincia l’era a due velocità, e il software è il primo settore in cui si vede. C’è una corsia agentica, oggi AI e in prospettiva superintelligenza, che produce, integra, verifica e sorveglia a una cadenza di decine di migliaia di modifiche al giorno. E c’è una corsia umana, che decide l’intento, rivede le scelte di progetto e risponde dei risultati. Il caso di Anthropic mostra che le due corsie esistono già, nella stessa azienda e sullo stesso codice.
Per questo la governance della corsia agentica deve diventare la priorità assoluta di quella umana. Le pratiche nate per persone che scrivono e rivedono codice, la revisione riga per riga, la coda di merge, la manutenzione fatta a mano, non tengono il passo, e in Anthropic i conflitti si risolvono già prima che qualcuno li veda. Restare un passo avanti, come si è sempre provato a fare con la sicurezza e i controlli, potrebbe non essere più possibile.
Per provarci servono paradigmi nuovi, che non ripartano da zero. Gli strumenti esistono e sono tanti: l’EU AI Act, il NIST AI RMF, la ISO/IEC 42001, le liste OWASP per le applicazioni agentiche, i modelli di gestione del rischio di ogni settore. Il problema è tenerli insieme e renderli verificabili alla velocità della prima corsia. È il motivo per cui ho proposto OISG, Open, Intelligent, Secure, Governed: un vocabolario che indicizza questi framework e traduce i loro obblighi in proprietà misurabili, con evidenze che si possono produrre in automatico.
- Anthropic, Redesigning source control at Anthropic, 13 ottobre 2026 — https://www.anthropic.com/engineering/redesigning-source-control
- Stefano Noferi, Intelligence is eating software, l’articolo precedente — https://noferi.it/blog/intelligence-eating-software/
- OISG, il sito e il paper 1.0 — https://oisg.ai/
- Meta, Sapling, il sistema di controllo di versione citato come precedente — https://sapling-scm.com/
- Rachel Potvin e Josh Levenberg, Why Google Stores Billions of Lines of Code in a Single Repository, il sistema Piper, Communications of the ACM 2016 — https://doi.org/10.1145/2854146
Immagine di copertina: The Horse in Motion di Eadweard Muybridge, 1878. La cavalla Sallie Gardner, di proprietà di Leland Stanford, al galoppo il 19 giugno 1878 sulla pista della sua tenuta di Palo Alto, dove pochi anni dopo sarebbe nata la Stanford University. Muybridge la fotografò con dodici apparecchi a scatto automatico, fissando per la prima volta un movimento troppo veloce per l’occhio umano. Nell’ultimo fotogramma il cavallo è fermo — pubblico dominio — https://commons.wikimedia.org/wiki/File:The_Horse_in_Motion_high_res.jpg