Con più agenti il conto lo paga chi deve rileggere

OpenAI compra Pierre e si dice che Git non regge più. Le fonti raccontano altro: il tempo si perde nell’unione dei pezzi, non nella scrittura.

📌 Se fai vibe coding (cioè costruisci un sito o un’app descrivendo a un’AI cosa vuoi, senza scrivere il codice a mano), questo pezzo ti serve per un motivo preciso: quando lavorano più agenti insieme, il tempo non si perde dove pensi. Ti spiego dove si perde e cosa puoi fare già da lunedì. Se vuoi il contesto, ne ho parlato in Oltre l’80% del codice di Anthropic non lo scrive più un umano.

Immagina un foglio sulla scrivania e quattro persone che ci scrivono sopra nello stesso momento. Ognuna è convinta di avere l’ultima versione. Ognuna finisce il suo pezzo, soddisfatta. Poi qualcuno deve prendere i quattro fogli, metterli insieme e capire se il risultato ha ancora un senso.

Quel qualcuno sei tu.

Questa è, più o meno, la scena che si apre quando fai lavorare più agenti AI sullo stesso progetto. E ieri è diventata una notizia: il 4 novembre 2026 OpenAI ha annunciato l’accordo per acquisire Pierre Computer Company, un’azienda che costruisce strumenti attorno a Git (The Decoder, 4/11/2026).

I titoli, come spesso succede, hanno alzato il volume: “Git non regge più”, “Git va in tilt”, “l’acquisizione lo dimostra”. Ho letto le fonti. La storia è più interessante, e soprattutto più utile per te.

La notizia, ridimensionata

Partiamo da cosa è successo, senza aggettivi.

OpenAI ha annunciato l’accordo per acquisire Pierre. L’operazione non è conclusa: serve ancora l’approvazione delle autorità di regolazione. Il prezzo non è stato dichiarato (The Decoder; conferma indipendente su DEV Community, 4/11/2026). Su questo non c’è altro da dire.

Cosa fa Pierre? Prima di tutto un servizio chiamato Code Storage: un archivio di codice basato su Git, pensato per essere usato dalle macchine invece che dalle persone. Poi alcuni strumenti aperti, cioè liberi da usare e da guardare dentro. Si chiamano Trees (per sfogliare i file di un progetto), Diffs (per vedere le modifiche, cosa è cambiato rispetto a prima) e Highlights (per evidenziare il codice, anche mentre un agente lo sta scrivendo) (The Decoder; sito di Pierre).

Due dettagli che contano. Trees e Diffs sono già dentro l’app Codex di OpenAI. E i progetti aperti di Pierre restano aperti (The Decoder; DEV Community).

E lo scopo? Secondo la ricostruzione di The Decoder, OpenAI vuole far funzionare meglio i flussi di lavoro con Git quando sviluppatori e agenti scrivono codice insieme, anche in parallelo. Attenzione: è la parafrasi del giornale, non una frase di OpenAI.

C’è poi una lettura che circola: Axios la presenta come una mossa contro GitHub, il grande servizio di Microsoft dove milioni di persone tengono il proprio codice. È un’interpretazione di Axios. Nell’annuncio, GitHub non compare (DEV Community). Teniamola come un’ipotesi di giornalisti, non come un fatto.

Un ultimo pezzo di contesto: OpenAI usa già un proprio sistema Git interno, chiamato Pando, presentato pochi giorni prima (The Decoder).

Il verbo giusto per questa notizia è “segnala”. Segnala che chi vende gli agenti di coding ritiene importante possedere lo strato dove il codice viene conservato e mostrato. Non “dimostra” che qualcosa si sia rotto.

Tre piani, non uno: strumento, piattaforma, metodo

Il motivo per cui le notizie sembrano più drammatiche di quello che sono è che mescolano tre cose diverse.

Lo strumento è Git: il programma che tiene la storia di un progetto. Pensalo come un quaderno condiviso in cui ogni modifica viene annotata, con data e autore.

La piattaforma è GitHub: la biblioteca dove tutti depositano il proprio quaderno per farlo vedere agli altri.

Il metodo è come tu e i tuoi agenti vi dividete il lavoro.

I numeri impressionanti che leggi in giro riguardano quasi tutti la biblioteca. Il rapporto Octoverse 2026 di GitHub dice che a settembre 2026 gli agenti hanno avviato oltre il 40% delle richieste di modifica (le “pull request”, cioè le proposte di inserire un cambiamento nel progetto), contro il 17% di marzo. Sono circa 110 milioni nel solo mese di settembre. GitHub precisa che il dato conta solo gli agenti che riesce a riconoscere, quindi è una stima per difetto (GitHub Blog, Octoverse 2026, 28/10/2026).

Sull’intero anno, fino a fine settembre 2026: 34,3 miliardi di modifiche salvate (i “commit”), 17,9 miliardi di invii al server (i “push”, più del 2024 e del 2025 messi insieme) e 1,3 miliardi di richieste di modifica unite al progetto (GitHub Blog).

Cosa significa, in pratica? Che il traffico è cresciuto tanto. Non che Git cede. La biblioteca è affollata: il quaderno funziona.

Anche la parte “sotto carico” ha una fonte: un portavoce di Microsoft, citato da Business Insider e riportato da DevX, avrebbe detto che l’impennata dello sviluppo con gli agenti, iniziata alla fine dello scorso anno, “ha messo alla prova i limiti della nostra infrastruttura”. È una dichiarazione che riguarda i server di una piattaforma, non il programma Git.

E il guasto di aprile?

Il 9 aprile 2026 GitHub ha avuto un problema serio, e vale la pena raccontarlo con la causa giusta. Il report ufficiale di GitHub parla di un errore nel sistema che limita il numero di richieste, applicato per sbaglio a livello globale, aggravato da un aggiornamento di un programma client che ha portato il traffico verso le API a 3-4 volte il normale. A farne le spese è stato l’agente di coding di Copilot: circa l’84% delle nuove sessioni è stato ritardato, con attese fino a 54 minuti contro i 15-40 secondi abituali (GitHub availability report, aprile 2026, 14/5/2026).

L’agente ha subito il danno, non l’ha provocato. E un episodio solo non basta a dire che gli agenti stiano affogando GitHub. Sono errori di GitHub, non limiti di Git.

Git non è “sequenziale”: è nato per il parallelo, ma umano

In questi giorni gira una frase che suona bene: Git è stato pensato per modifiche una dopo l’altra, e gli agenti lo mettono in crisi. L’ho controllata. È sbagliata.

Git nasce nel 2005, dopo la rottura tra la comunità di sviluppo di Linux e l’azienda che produceva BitKeeper, lo strumento che il progetto usava fino a quel momento. L’azienda ritirò la gratuità (Pro Git, cap. 1.2; Linux Journal, Zack Brown, 27/7/2018).

Gli obiettivi di partenza, nel libro ufficiale del progetto, sono questi: velocità, un disegno semplice, e un’indicazione che a leggerla oggi fa effetto:

“Strong support for non-linear development (thousands of parallel branches)”

Cioè: supporto forte allo sviluppo non lineare, con migliaia di rami paralleli. Aggiunge che doveva essere completamente distribuito, e capace di gestire progetti enormi come il kernel di Linux (Pro Git). Linus Torvalds, secondo Linux Journal, non poteva permettersi di aspettare più di pochi secondi nemmeno per l’operazione più grande e complessa (Linux Journal).

Quindi Git è stato pensato per il lavoro in parallelo da subito. Che cosa è cambiato? Questa è una mia lettura, non una frase delle fonti: è cambiato il ritmo, e chi produce il lavoro che qualcuno poi deve rileggere. Prima erano persone che lavoravano a velocità umana. Adesso il lavoro da rileggere arriva molto più in fretta, e da più agenti nello stesso momento: a settembre 2026, su GitHub, oltre il 40% delle richieste di modifica l’hanno avviato gli agenti.

Le contromisure ufficiali: isolano, ma non parlano di unione

Chi costruisce questi agenti il problema lo ha visto, e ha una risposta. Si chiama worktree.

Traduzione: una copia di lavoro separata per ogni agente, dello stesso progetto. Ogni agente ha il suo tavolo, e non toccate gli stessi fogli mentre lavorate.

Anthropic, nella documentazione di Claude Code, lo scrive così:

“Work on a feature in one terminal while Claude fixes a bug in another, without the edits colliding. Each git worktree is a separate checkout on its own branch”

In italiano: lavora su una funzione in un terminale mentre Claude corregge un errore in un altro, senza che le modifiche si scontrino; ogni worktree è una copia separata, su un suo ramo. Esiste anche un comando apposito, claude --worktree <nome> (Claude Code docs, Common workflows). La stessa pagina consiglia di procedere per incrementi piccoli e verificabili (“small, testable increments”).

OpenAI per Codex fa la stessa cosa:

“Worktrees let Codex run multiple independent chats in the same project without interfering with each other.”

Cioè: le worktree permettono a Codex di far girare più conversazioni indipendenti nello stesso progetto senza che si disturbino. C’è un limite documentato: Git consente a un ramo di essere “aperto” in un solo posto alla volta. E Codex conserva le 15 copie gestite più recenti, numero modificabile (Codex docs, Git worktrees).

Se Codex e Claude Code sono i tuoi strumenti quotidiani, ho già raccontato come si confrontano in Perché OpenAI con Codex ha copiato brillantemente la strategia di Anthropic.

Fin qui, tutto bene. Ma c’è un dettaglio che ho notato leggendo: le pagine ufficiali spiegano come far lavorare gli agenti separati. Nessuna delle due spiega come rimettere insieme il lavoro quando hanno finito. Lo dico per quello che ho letto: strumenti per unire il lavoro di più agenti magari esistono, ma la documentazione ufficiale si ferma prima.

Una nota su Jujutsu

Se frequenti gente che sviluppa, ti capiterà di sentire il nome Jujutsu: un’alternativa a Git che, secondo un blog di settore, tratta i conflitti come uno stato registrato invece che come un blocco. Non l’ho verificato sulla documentazione ufficiale, quindi resta una nota a margine. Lo stesso blog, Wavect, avverte che Jujutsu non supporta ancora alcune funzioni di Git (le worktree, gli hook, i submodule, LFS) (Wavect, Kevin Riedl, 22/7/2026). Per te, oggi, c’è un solo messaggio: c’è chi ci prova.

Dove si perde davvero tempo: l’unione e la rilettura

Torniamo ai quattro fogli sulla scrivania.

Anche se ognuno scrive sul suo foglio, a un certo punto i fogli vanno uniti. E qui c’è un problema che nessuna copia separata risolve. Due agenti possono modificare file diversi, senza toccarsi mai, e rompere comunque il progetto: uno cambia il modo in cui si chiama una funzione, l’altro scrive nuovo codice che usa il vecchio nome. Sulla carta nessun conflitto. Nella realtà, il progetto non parte più.

Wavect lo dice con queste parole: “No VCS can remove semantic conflict”, nessun sistema di versionamento può eliminare il conflitto di significato. E aggiunge che Git “is not automatically the bottleneck”, non è automaticamente il collo di bottiglia (Wavect). Ricorda che è l’opinione di un’agenzia, argomentata ma pur sempre un’opinione, non un dato.

E Pierre? Guarda cosa fanno i suoi strumenti: mostrare le modifiche (Diffs), evidenziare il codice (Highlights), sfogliare i file (Trees). Sono tutti strumenti per vedere e rileggere. È un indizio, ed è una mia lettura: OpenAI non ha dichiarato niente del genere. Ma se il nodo fosse la revisione, un’acquisizione di questo tipo avrebbe senso.

Il punto, per te che non scrivi codice a mano, è questo: la velocità dei tuoi agenti non si misura da quando finiscono. Si misura da quando tu ti fidi abbastanza da dire “va bene, lo unisco”. Se non sai leggere una lista di modifiche, il tuo controllo passa da un’altra strada: chiedi all’agente di spiegarti cosa ha cambiato, in parole semplici, e provi il risultato con le tue mani. Un’idea simile la trovi in L’AI ricrea i programmi Adobe e Microsoft in una settimana, e se fosse la parte sbagliata della notizia?: la parte facile è generare, quella che conta è il resto.

Cosa fare lunedì

Metto in fila le cose pratiche. Alcune vengono direttamente dalle documentazioni, altre sono mie sintesi, e te lo dico caso per caso.

1. Un agente, una copia di lavoro separata. È la contromisura documentata sia da Anthropic che da OpenAI. Se usi strumenti che lo fanno in automatico, bene; altrimenti chiedi all’agente di impostarla.
2. Compiti piccoli. Anche qui la documentazione di Claude Code consiglia incrementi piccoli e verificabili. Un compito che puoi controllare in cinque minuti vale più di uno enorme che richiede un’ora di rilettura.
3. Unisci spesso, un pezzo alla volta, e dopo ciascuno prova che il progetto funzioni. Questa è una mia sintesi, non una regola scritta nelle documentazioni.
4. Misura prima di cambiare strumento. Il consiglio di Wavect è proprio questo: capire dove si perde il tempo prima di cambiare sistema. Annota per una settimana quanto ci metti a far lavorare gli agenti e quanto a verificare e unire. Scoprirai da che parte pende.

E la prossima volta che un annuncio dice “più agenti in parallelo”, fai la domanda giusta: a chi tocca rileggere?

Articoli correlati

• Oltre l’80% del codice di Anthropic non lo scrive più un umano
• Perché OpenAI con Codex ha copiato brillantemente la strategia di Anthropic
• OpenAI ha copiato Anthropic. E per una volta copiare è una buona notizia
• L’AI ricrea i programmi Adobe e Microsoft in una settimana, e se fosse la parte sbagliata della notizia?

---

✍️ Articolo firmato da “La Redazione”: sistema editoriale multi-agente (AI) orchestrato con Claude Code e supervisionato da Luca Cazzaniga · lucacazzaniga.it