La fabbrica dei via libera

19 Oct, 2026

Il 13 ottobre 2026 Anthropic annuncia che le modifiche integrate ogni giorno nel proprio archivio di codice sono passate da circa 2.500 a maggio a oltre 30.000 a settembre. L’aumento ha messo sotto pressione gli strumenti usati per conservare il codice e renderlo disponibile ai programmi che eseguono le verifiche. Per affrontare il problema, l’azienda ha sostituito Git con un sistema interno chiamato Scion.¹

Anthropic riunisce molti progetti in un unico archivio, un monorepo, la cui storia ha dimensioni ragguardevoli. I programmi che eseguono le verifiche automatiche richiedono continuamente versioni del codice: secondo l’azienda, circa 25 milioni di volte al giorno. Per distribuire il carico erano state predisposte centinaia di copie interne dell’archivio, sempre più impegnative da mantenere aggiornate.

Scion sposta molte operazioni sui server e permette ai programmi di richiedere i dati necessari. Anthropic dichiara che la nuova infrastruttura richiede una quantità di capacità di calcolo e memoria duecento volte inferiore rispetto al precedente sistema di copie interne di Git. Dichiara inoltre di aver recuperato il 25% della capacità di calcolo disponibile per la continuous integration, l’insieme delle operazioni automatiche che preparano e verificano le modifiche al codice.¹

Questi numeri sono forniti da Anthropic e riguardano la sua infrastruttura. Descrivono il confronto con il sistema precedente e il risultato ottenuto nelle verifiche automatiche. Non indicano quanto sia migliorata la produttività complessiva dello sviluppo, né quale vantaggio otterrebbe un’altra azienda adottando la stessa soluzione.

Git offre già strumenti per ridurre i dati da scaricare: si può limitare la storia delle modifiche da copiare, rinviare il trasferimento del contenuto dei file fino al momento in cui serve e scegliere quali cartelle rendere disponibili nella copia di lavoro.² Anthropic riferisce di aver usato queste possibilità prima di costruire Scion.

Anche i sistemi specifici per grandi archivi di codice hanno precedenti: Rachel Potvin e Josh Levenberg descrivevano nel 2016 le ragioni e i compromessi del monorepo di Google.³ Prima di sostituire una piattaforma, un responsabile IT deve quindi verificare se il problema possa essere risolto con gli strumenti esistenti o richieda un investimento diverso.

La scelta di Anthropic riguarda un’infrastruttura di dimensioni ragguardevoli. Il rapporto fra la velocità di sviluppo e le attività successive interessa però anche progetti più piccoli. Una modifica prodotta rapidamente deve ancora attraversare la revisione, le prove e le autorizzazioni necessarie per arrivare agli utenti.

Se il codice è pronto e aspetta un ambiente di collaudo, aggiungere agenti può aumentare le richieste in attesa senza anticipare la consegna. Nel capacity planning, la pianificazione delle risorse, occorre quindi considerare anche revisori, ambienti e strumenti di prova.

Immaginiamo che un componente sia pronto una settimana prima del previsto. Il project manager potrebbe essere tentato di anticipare la consegna. Prima deve controllare che cosa accade dopo: se il collaudo è fissato per il mese successivo e gli utenti non possono partecipare prima, il componente guadagna una settimana e la trascorre in attesa.

Nel piano, il critical path, o percorso critico, collega le attività dalle quali dipende la data finale. Per promettere una consegna più rapida bisogna verificare che il tempo risparmiato incida su quel percorso e che le attività successive possano procedere.

La velocità pone anche un problema di verifica. Gli ingegneri di Anthropic dichiarano di esaminare ogni richiesta di modifica concentrandosi sul suo intento, senza leggere ogni riga di codice. L’azienda riferisce inoltre di aver investito nei test successivi all’integrazione e precedenti al rilascio.¹ Sono momenti distinti: una modifica può essere entrata nell’archivio principale senza essere ancora disponibile agli utenti.

Pensiamo a un’applicazione per gli ordini. Una richiesta introduce uno stato che permette di distinguere gli ordini sospesi da quelli annullati. Chi approva l’intento può riconoscere l’utilità della distinzione. Le prove devono poi accertare che il programma registri correttamente lo stato e che gli altri servizi, per esempio la fatturazione, lo interpretino nel modo previsto. Una modifica utile e ben descritta può produrre un errore in una funzione collegata.

Se più interventi vengono integrati mentre le prove sono in corso, bisogna anche sapere su quale versione siano state eseguite. Un test superato conserva valore per ciò che ha verificato; una modifica successiva potrebbe richiedere una nuova prova sulla combinazione destinata al rilascio. La pipeline, la sequenza di operazioni che prepara e verifica il software, deve rendere riconoscibile questo rapporto.

Prima del rilascio, qualcuno deve stabilire se le prove siano sufficienti. Il quality gate definisce le condizioni per passare alla fase successiva. Una modifica ai permessi richiede di verificare chi possa accedere alle informazioni; per una correzione redazionale possono bastare controlli più leggeri. La gestione delle modifiche, o change enablement, serve anche a stabilire chi esamina i casi più delicati e chi può autorizzare un’eccezione.

Nel nostro esempio, il nuovo stato può coinvolgere chi sviluppa, chi gestisce il servizio e chi cura la fatturazione. Le responsabilità devono essere riconoscibili: una matrice RACI può indicare chi svolge le attività, chi risponde del risultato e chi viene consultato. Bisogna poi assegnare i poteri effettivi negli strumenti, compresa la possibilità di fermare il rilascio. Se un agente può modificare sia il programma sia i test che lo controllano, il gruppo deve prevedere verifiche indipendenti per i comportamenti più delicati.

Il lavoro prosegue dopo il via libera. Il servizio può aver bisogno di istruzioni per l’assistenza, monitoraggio e procedure di ripristino. Se il team considera conclusa l’attività quando il codice è integrato, questi compiti possono ricadere su chi dovrà gestire il nuovo comportamento. La Definition of Done, l’accordo su ciò che rende conclusa un’attività, aiuta a chiarire quali condizioni debbano essere soddisfatte prima della consegna.

Anche gli indicatori devono seguire il risultato oltre l’archivio del codice. DORA propone di osservare insieme velocità dei rilasci, tempi di recupero e instabilità, considerando il contesto del servizio.⁴ Una funzione disponibile prima è un risultato misurabile; per capire se abbia migliorato il lavoro dobbiamo osservare anche che cosa riescono a fare gli utenti e quali attività aggiuntive rimangono a loro carico.

Una volta in produzione, occorrono monitoraggio e capacità di intervento. Google descrive l’error budget come il margine di errore tollerato rispetto a un obiettivo di servizio: quando quel margine si riduce, il gruppo può rallentare i rilasci e dedicare più risorse all’affidabilità.⁵ Le misure devono però essere adeguate al servizio. Un’applicazione può essere disponibile e mostrare comunque dati errati.

Anche il ripristino richiede una decisione preventiva. Tornare alla versione precedente del programma può essere rapido; correggere dati già trasformati o ritirare comunicazioni inviate ai clienti può essere difficile. Il release management deve valutare queste conseguenze e stabilire quando distribuire una modifica gradualmente, chi possa fermarla e come intervenire.

Prove, monitoraggio e manutenzione entrano nel total cost of ownership, il costo complessivo nel tempo, insieme all’uso dei modelli e agli ambienti necessari. Una maggiore capacità di generazione può consentire di svolgere più lavoro, senza tradursi automaticamente in una riduzione della spesa. Anthropic stessa precisa che Scion risponde a condizioni estreme e che il proprio impiego di risorse per i modelli è superiore a quello realisticamente sostenibile da altre aziende.¹

Torniamo alla modifica degli ordini. Se ogni richiesta arriva accompagnata da un riepilogo convincente e da una serie di test superati, chi deve approvarla può sentirsi abbastanza rassicurato da passare alla successiva. Ma se le richieste aumentano più rapidamente del tempo disponibile per esaminarle, anche l’approvazione rischia di diventare un’operazione da sbrigare.

A quel punto il numero dei via libera ci dirà quante modifiche hanno superato il controllo. Per capire quanto sia stato efficace dovremo sapere chi le ha esaminate, con quali informazioni e con quanto tempo a disposizione.

#claude #intelligenza artificiale