Il problema non è Git: è coordinare mille agenti che scrivono insieme

Git ha risolto molto bene un problema nato in un mondo in cui gli sviluppatori erano umani, relativamente pochi e lavoravano con una velocità compatibile con branch, commit, pull request e review. Quel modello non sparisce perché arrivano gli agenti AI. Ma quando gli attori diventano centinaia o migliaia, il collo di bottiglia cambia.

Cloudflare lo ha reso esplicito aprendo Artifacts in beta e lanciando una competizione per costruire la “prossima piattaforma Git” pensata per workflow agentici su larga scala. La provocazione è interessante non perché Git sarebbe improvvisamente vecchio, ma perché ci costringe a separare due problemi che fino a ieri coincidevano: versionare il codice e coordinare chi lo cambia.

Quando moltiplichi gli agenti, il costo non cresce soltanto nel codice prodotto. Cresce soprattutto nel numero di decisioni che devi rendere compatibili, verificabili e reversibili.

Un repository per agente risolve l’isolamento, non il coordinamento

Artifacts nasce come storage versionato compatibile con Git e progettato per creare repository in modo programmatico su scala molto ampia. La documentazione Cloudflare suggerisce esplicitamente un repository per agente, sessione o task quando serve isolamento: ogni unità di lavoro può partire da una baseline, modificare il proprio spazio e produrre un risultato confrontabile con gli altri.

È una primitive utile perché evita che cento agenti scrivano nello stesso workspace e trasformino ogni esecuzione in una gara a chi sovrascrive per ultimo. Ma l’isolamento è soltanto il primo pezzo.

Se dieci agenti partono dalla stessa base e producono dieci soluzioni diverse, il sistema deve ancora rispondere a domande molto più difficili: quali cambiamenti sono compatibili? Quali dipendono dallo stesso file o dalla stessa decisione? Quale soluzione ha superato i test? Quale va scartata? Chi decide l’ordine dei merge? E soprattutto: quale contesto ha portato ciascun agente a fare quella modifica?

Qui il problema smette di essere storage e diventa orchestrazione.

Il codice è solo metà dell’artefatto

Una piattaforma pensata davvero per agenti non può trattare il commit come unità informativa sufficiente. Un commit racconta cosa è cambiato; spesso racconta poco sul perché, su quali alternative sono state considerate, su quali vincoli sono stati letti o su quale verifica rende quella modifica accettabile.

Cloudflare insiste proprio sulla possibilità di conservare non solo codice, ma anche contesto di sessione. È un dettaglio importante: se un agente prende una decisione perché ha letto un file, una policy, un test fallito o una richiesta utente, quella catena causale diventa parte del lavoro da preservare.

È lo stesso motivo per cui un agente che “ha fatto progresso” non ha necessariamente prodotto un risultato utilizzabile. Il valore non è il numero di modifiche accumulate, ma la qualità dell’artefatto finale e la possibilità di verificare come ci siamo arrivati.

La review diventa un problema di scheduling

Nel workflow umano classico una pull request aspetta una review. Quando le pull request potenziali arrivano da centinaia di agenti, la review non è più una semplice coda: diventa un problema di priorità, dipendenze e budget.

Alcuni cambiamenti sono indipendenti e possono essere verificati in parallelo. Altri invalidano il lavoro partito pochi secondi prima. Alcuni agenti possono produrre alternative concorrenti allo stesso requisito. Altri possono limitarsi a preparare test, benchmark o migrazioni senza dover entrare subito nel ramo canonico.

Questo rende molto meno interessante chiedersi se un agente “sa fare Git”. La domanda utile diventa: il sistema sa decidere quale lavoro merita di avanzare?

È una domanda che ricorda da vicino il problema del tool retrieval sotto budget: non basta avere tutte le azioni disponibili, serve allocare risorse dove hanno più probabilità di produrre valore. Con repository agentici su larga scala lo stesso principio si applica a branch, review, test, merge e rollback.

Gli eventi contano quanto i repository

Una delle capacità più interessanti aggiunte ad Artifacts è la possibilità di reagire agli eventi del repository: creazione, fork, push, clone, fetch. Un Worker può ricevere questi eventi e avviare automaticamente CI, code review o altri workflow.

Questo è il punto in cui il repository smette di essere un contenitore passivo e diventa una sorgente di eventi per l’orchestrazione. Non aspetti che una persona apra una pagina e prema “review”: il push stesso può materializzare un task di verifica.

Il vantaggio è evidente, ma aumenta anche il rischio di creare pipeline che reagiscono a tutto senza capire cosa merita davvero attenzione. Se ogni commit di ogni agente genera altri tre agenti, non hai costruito automazione: hai costruito una moltiplicazione di lavoro.

La scala degli agenti rende economico produrre modifiche. Di conseguenza rende più costoso scegliere quali modifiche meritano di diventare realtà.

Il branch non basta se manca l’autorità

Cloudflare invita esplicitamente a ripensare branch, pull request, worktree, code review e merge conflict. Ma il concetto che secondo me diventa davvero centrale è l’autorità.

Un sistema con molti agenti deve sapere quali componenti possono proporre, quali possono verificare e quali possono rendere una modifica canonica. Dare a tutti la possibilità tecnica di fare push non significa dare a tutti la stessa autorità di pubblicazione.

Questo principio compare anche quando si parla di sicurezza degli agenti e enforcement esterno: i confini importanti non dovrebbero dipendere dal componente che stai cercando di controllare. Nel codice vale allo stesso modo. L’agente che produce una patch non dovrebbe essere automaticamente l’unico soggetto che decide se quella patch è corretta.

Artifacts è una primitive, non la piattaforma finale

Cloudflare è abbastanza chiara su questo punto: Artifacts fornisce il livello di storage e Git compatibility; la competizione chiede agli sviluppatori di costruire ciò che viene sopra. Ed è proprio qui che l’annuncio diventa più interessante di una semplice beta prodotto.

Artifacts permette repository programmatici, fork isolati, accesso da Workers, token con scope limitato, eventi, metriche, deploy verso Workers e scelta della giurisdizione dei dati. Sono primitive. La piattaforma per agenti deve ancora decidere come rappresentare intenzioni, dipendenze, review, conflitti, priorità e stato canonico.

La competizione stessa lo rende evidente: Cloudflare non chiede “costruisci GitHub con un chatbot”. Chiede di immaginare cosa cambia quando la concorrenza non è più qualche decina di sviluppatori, ma centinaia o migliaia di agenti.

Mille agenti non sono mille sviluppatori più veloci

Questo è il passaggio che spesso manca nel racconto sull’automazione software. Aumentare il numero di agenti non equivale linearmente ad aumentare il throughput. Oltre una certa soglia, la capacità produttiva si scontra con il costo di coordinamento.

Più agenti significano più branch potenziali, più test, più conflitti, più duplicazioni, più risultati da confrontare e più contesto da preservare. Il sistema che funziona non è quello che massimizza il numero di modifiche generate. È quello che minimizza il lavoro inutile prima che arrivi nel ramo canonico.

Da questo punto di vista, la vera piattaforma “Git per agenti” dovrebbe probabilmente avere almeno quattro proprietà: isolamento economico, verifica automatica, autorità esplicita e capacità di spiegare perché una modifica è stata scelta rispetto alle alternative.

La prossima piattaforma Git sarà soprattutto un sistema di decisione

Git continuerà a fare molto bene ciò per cui è nato: versionare alberi di file, creare commit, branch e merge. Il problema nuovo non richiede necessariamente di sostituirlo. Richiede di costruire sopra Git un modello operativo capace di trattare la concorrenza agentica come una caratteristica normale, non come un’eccezione.

Cloudflare Artifacts è interessante perché rende economico creare e forkare repository programmaticamente e perché espone quelle operazioni direttamente all’infrastruttura applicativa. Ma questo sposta il valore verso il livello superiore: chi orchestra il lavoro, chi valida gli effetti, chi conserva il contesto e chi decide cosa diventa vero.

Quando produrre codice diventa economico, la qualità del sistema dipende sempre meno dalla quantità di codice prodotto e sempre più dalla qualità delle decisioni che filtrano quel codice.