Il sostituto di Git di Anthropic: quando il volume di codice supera la revisione umana

Quando uno strumento pensato per il passo umano incontra il passo della macchina

Secondo resoconti riconducibili alla ricostruzione di questo cambiamento fatta da Simon Willison, Anthropic ha costruito un proprio sostituto di Git. Il fattore scatenante non è stato un bug né un incidente di sicurezza. È stato il volume. Il ritmo dei cambiamenti che arrivavano nella codebase dell'azienda è salito bruscamente, e a maggio 2026 si attestava in media su circa 2.500 richieste per periodo, un carico che il controllo di versione tradizionale non era progettato per sostenere.

È facile archiviare la cosa tra gli strumenti interni e passare oltre. Sarebbe un errore. Git è uno dei software più importanti mai scritti, ed è costruito su una serie di presupposti su come cambia il codice che oggi vengono violati nella pratica.

I presupposti su cui è stato costruito Git

Il progetto di Git codifica una convinzione sul comportamento umano. I cambiamenti arrivano a un ritmo che una persona può guardare. Un branch rappresenta un'intenzione che dura abbastanza da poter essere nominata. La storia è preziosa, quindi non si butta via nulla. Un maintainer può leggere un diff e formarsi un'opinione prima di unirlo.

Ognuno di quei presupposti si indebolisce quando sono gli agenti a scrivere il codice.

Gli agenti non si stancano, quindi producono cambiamenti di continuo invece che in lotti delle dimensioni di una giornata lavorativa. Non mantengono un'intenzione per giorni, quindi i branch diventano così effimeri che nominarli è solo un costo. Generano molti più diff di quanti un revisore umano possa leggerne davvero, il che rende il passo di revisione, attorno al quale è organizzato l'intero flusso di lavoro di Git, un collo di bottiglia invece che una salvaguardia.

Il risultato è un sistema che opera ben oltre il suo involucro di progetto, mentre tutti insistono che nulla è cambiato. Il repository funziona ancora. Il processo che lo circonda smette di significare ciò che significava.

Cosa si rompe davvero per primo

La preoccupazione ingenua è lo spazio di archiviazione. Si rivela il problema minore. Il disco costa poco e Git comprime bene.

La prima vera vittima è la revisione. Una pull request il cui diff di 4.000 righe è stato generato da un agente è tecnicamente revisionabile e praticamente no. I revisori fanno ciò che gli umani fanno sempre sotto sovraccarico: scorrono, si fidano del riepilogo, approvano. La revisione sopravvive come cerimonia perdendo la sua funzione, il che è peggio che eliminarla, perché la cerimonia crea falsa sicurezza.

La seconda vittima è l'identità. La storia di Git è un registro di chi ha deciso cosa e quando. Quando la maggior parte dei commit è opera di un modello che agisce su un prompt, la storia contiene ancora nomi, ma i nomi non rispondono più alla domanda per cui la storia esiste. Non puoi chiedere a un agente perché sei settimane fa ha scelto un certo approccio, perché non se lo ricorda, e il messaggio del commit è stato generato dallo stesso sistema che ha fatto la scelta.

La terza vittima è il branch stesso. Creare branch in Git costa poco e in attenzione umana costa molto. Se i branch si moltiplicano più in fretta di quanto chiunque possa seguirli, si accumulano intenzioni che nessuno tiene, il che è un fallimento diverso da un conflitto di merge e più difficile da vedere.

Perché un sostituto è più di un Git più veloce

Se il problema fosse la capacità di elaborazione, la soluzione sarebbe un server più veloce. Che Anthropic costruisca qualcosa di nuovo suggerisce che il problema è strutturale.

Un sistema di controllo di versione ottimizzato per cambiamenti al passo della macchina sarebbe diverso in modi specifici. Presumerebbe che la maggior parte dei cambiamenti sia effimera e debba costare poco crearli e poco scartarli. Tratterebbe il diff come un riepilogo invece che come l'artefatto, e collegherebbe a ogni cambiamento un'intenzione leggibile dalla macchina, così che un agente possa ritrovarla dopo senza leggere il codice. Sarebbe costruito per il recupero, non per l'archeologia.

Dovrebbe anche rispondere a una domanda che Git non ha mai dovuto porsi. Git presume che l'artefatto interessante sia lo stato finale del codice. In un flusso di lavoro guidato dagli agenti, l'artefatto interessante è spesso il ragionamento che ha prodotto un cambiamento e i controlli che lo hanno validato. Se questi vivono fuori dal controllo di versione, allora il controllo di versione registra solo metà della storia.

Il registro a cui nessuno pensa finché non ne ha bisogno

Il controllo di versione non è solo un sistema di archiviazione. È il substrato per fatturazione, conformità e risposta agli incidenti. I revisori contabili vogliono sapere chi ha cambiato cosa e quando. I settori regolamentati vogliono un registro difendibile che resista a un esame. I team di sicurezza ricostruiscono le cronologie dai commit.

Se la risposta onesta a quelle domande diventa "l'ha fatto un agente, su un branch che non esiste più, e il ragionamento viveva in una finestra di contesto ormai scartata", allora il registro ha un buco. I buchi nei registri sono esattamente ciò che gli audit sono fatti per trovare, e uno strumento che li produce senza che nessuno se ne accorga sarebbe un problema serio molto prima di diventare uno scandalo.

Il segnale più ampio

Anthropic non è sola a sentire questa pressione, e le versioni ridotte della stessa storia sono già visibili altrove. GitHub ha recentemente rielaborato la sua API di cronologia delle stelle dei repository, così che i dati di tendenza arrivino in 24 richieste invece di circa 2.500, senza richiedere un lavoro illimitato sul database né esporre i singoli utenti che hanno messo la stella. GitHub ha anche distribuito un classificatore di rilevamento dei segreti consapevole del contesto che ha aumentato del 11,5 per cento il tasso di accettazione dei ritrovamenti reali e ridotto dell'86 per cento il tempo mediano di scansione.

Entrambi sono risposte alla stessa condizione di fondo: il volume di codice nel mondo sta salendo, e gli strumenti costruiti quando gli umani erano gli unici autori stanno iniziando a mostrare la loro età. Il rilevamento dei segreti è una bella illustrazione. Il rischio di una credenziale esposta cresce con la quantità di codice scritto, quindi un sistema adeguato a ritmi di produzione umani diventa inadeguato a ritmi di produzione degli agenti, anche se nulla del suo progetto è cambiato.

La parte che nessuno vuole dire ad alta voce

C'è una versione di questa storia in cui l'IA rende i team di software molto più produttivi, gli strumenti si adeguano e va tutto bene.

C'è un'altra versione in cui il volume di codice generato supera la capacità umana di capirlo, e il settore finisce con repository che nessuna singola persona comprende, tenuti insieme da test che nessuno ha scritto e revisioni che nessuno ha svolto. Il segnale di quella versione non è un crollo. È una deriva lenta in cui la codebase continua a funzionare e il numero di persone che capiscono perché continua a calare.

Sostituire Git è, in questa luce, un sintomo che vale la pena notare. Significa che una delle aziende più caute del settore ha deciso che lo strumento standard era diventato un passivo proprio nello strato in cui si tiene traccia della correttezza. Non è un'ammissione da poco. È il segnale che all'infrastruttura del software viene chiesto di cambiare più in fretta di quanto i suoi presupposti possano seguire.

La risposta pratica per tutti gli altri non è romantica. Misura quanto del tuo codice è scritto da una macchina. Guarda se il tuo passo di revisione cambia ancora qualcosa. Nota se la tua storia riesce ancora a rispondere al perché. Sono domande a basso costo, e le risposte ti diranno se ti serve un nuovo strumento o solo una nuova abitudine.