Quando gli agenti AI intasano Git: la lezione di Pando (OpenAI) per chi gestisce un repository
Se in azienda avete iniziato a far scrivere codice a Codex, Copilot o Claude Code, probabilmente avete notato che il numero di commit e branch è salito molto più in fretta di quanto salisse con i soli sviluppatori umani. OpenAI ci è arrivata su scala estrema: il monorepo interno, sotto la pressione di Codex che genera lavoro in parallelo, ha iniziato a soffrire di push lenti, fetch che si impallano e merge falliti. La risposta è stata costruire da zero un backend compatibile con Git, chiamato Pando, in produzione da aprile 2026.
## Il problema non è Git, è il volume generato dagli agenti
Un'infrastruttura Git tradizionale regge bene un flusso di commit "a ritmo umano": un developer apre un branch, lavora qualche ora, fa push, apre una pull request. Quando gli agenti entrano in gioco, quel ritmo cambia natura: non uno sviluppatore che scrive, ma decine di processi che aprono branch, fanno push intermedi, eseguono job di CI e ricreano clone in parallelo. Il collo di bottiglia non è più la velocità di scrittura del codice, ma la capacità del server Git di gestire letture e scritture concorrenti su larga scala.
Secondo quanto riportato da OpenAI, Pando affronta il problema su tre fronti. Primo, abbandona l'idea di una "fotografia" coerente di tutto il repository in ogni istante, a favore di una consistenza garantita solo all'interno di ciascun branch: due push su branch diversi possono procedere in parallelo senza bloccarsi a vicenda, mentre l'ordine delle modifiche dentro lo stesso branch resta garantito. Secondo, riutilizza i pacchetti Git già generati invece di ricalcolarne uno nuovo per ogni client, appoggiandosi alla funzionalità packfile-uri del protocollo Git e a cache regionali. Terzo, comprime in background i pacchetti più piccoli in blocchi più grandi, un'idea mutuata dalle strutture dati a log (LSM-tree), così un client molto indietro non deve scaricare decine di migliaia di file separati.
## I numeri che contano
Alcuni dati, sempre dichiarati da OpenAI: la latenza mediana dei push si è ridotta di circa l'80%, quasi cinque volte più rapida di prima. Il sistema serve oggi quasi un petabyte di dati Git al giorno, con un picco superiore a 57 terabyte di pacchetti in una sola ora, di cui più del 99% servito dalla cache locale su disco (quindi senza dover andare a recuperare i dati altrove). Il progetto è stato sviluppato in circa dieci settimane, con il design centrale definito da un solo ingegnere e l'implementazione affidata in larga parte a team di agenti Codex.
## Cosa significa per chi non ha la scala di OpenAI
Nessuna PMI o team di sviluppo italiano ha bisogno di costruirsi un proprio backend Git. Ma il sintomo che Pando risolve — infrastruttura di versionamento che inizia a soffrire quando si introducono agenti di coding — è lo stesso che si presenta, in scala minore, in qualsiasi team che passa da "uno sviluppatore, un branch alla settimana" a "più agenti che aprono branch e push in parallelo". In un progetto tipico, questo si manifesta con CI che si accoda, clone che diventano lenti su repository molto grandi, o pipeline che falliscono in modo intermittente proprio nei momenti di picco.
La scelta di design più interessante da portare a casa, anche per chi lavora a scala molto più piccola, è quella di non inseguire una coerenza globale del repository quando non serve davvero: molti strumenti e automazioni interne vengono scritti assumendo che "leggere il repository" dia sempre una fotografia coerente di tutto, ma spesso basta la coerenza branch per branch. È un'assunzione da verificare prima di costruire automazioni fragili attorno al proprio Git.
Un limite da non sottovalutare: un modello di consistenza più permissivo, come quello scelto da Pando, può rompere tool che assumono letture coerenti su più branch contemporaneamente (dashboard che confrontano lo stato di branch diversi nello stesso istante, ad esempio). Prima di cambiare provider Git o abilitare funzionalità come il partial clone per inseguire velocità, vale la pena controllare che le proprie integrazioni non facciano quell'assunzione.
## In pratica
1. Monitora la crescita del numero di push, branch e job CI da quando usi agenti di coding: se cresce più rapidamente del numero di persone nel team, è un segnale da seguire prima che diventi un problema di produttività.
2. Verifica se il tuo provider Git (GitHub, GitLab, provider self-hosted) supporta già packfile-uri o partial clone: spesso la soluzione a un rallentamento non è cambiare infrastruttura, ma attivare funzionalità già disponibili.
3. Prima di costruire automazioni che leggono lo stato di più branch insieme, chiediti se davvero serve una coerenza globale istantanea o se basta la coerenza per singolo branch: la differenza cambia come vanno progettate quelle automazioni.
Se anche nel tuo team l'adozione di agenti di coding ha iniziato a far scricchiolare l'infrastruttura di versionamento, raccontalo nei commenti: è un problema che diventerà comune molto prima di quanto si pensi. Condividi l'articolo con chi gestisce CI/CD nella tua azienda, e se l'argomento ti interessa resta aggiornato sui prossimi approfondimenti.
Fonte: "Scaling Git at OpenAI", OpenAI, 2 novembre 2026 — https://openai.com/index/scaling-git-at-openai
## Il problema non è Git, è il volume generato dagli agenti
Un'infrastruttura Git tradizionale regge bene un flusso di commit "a ritmo umano": un developer apre un branch, lavora qualche ora, fa push, apre una pull request. Quando gli agenti entrano in gioco, quel ritmo cambia natura: non uno sviluppatore che scrive, ma decine di processi che aprono branch, fanno push intermedi, eseguono job di CI e ricreano clone in parallelo. Il collo di bottiglia non è più la velocità di scrittura del codice, ma la capacità del server Git di gestire letture e scritture concorrenti su larga scala.
Secondo quanto riportato da OpenAI, Pando affronta il problema su tre fronti. Primo, abbandona l'idea di una "fotografia" coerente di tutto il repository in ogni istante, a favore di una consistenza garantita solo all'interno di ciascun branch: due push su branch diversi possono procedere in parallelo senza bloccarsi a vicenda, mentre l'ordine delle modifiche dentro lo stesso branch resta garantito. Secondo, riutilizza i pacchetti Git già generati invece di ricalcolarne uno nuovo per ogni client, appoggiandosi alla funzionalità packfile-uri del protocollo Git e a cache regionali. Terzo, comprime in background i pacchetti più piccoli in blocchi più grandi, un'idea mutuata dalle strutture dati a log (LSM-tree), così un client molto indietro non deve scaricare decine di migliaia di file separati.
## I numeri che contano
Alcuni dati, sempre dichiarati da OpenAI: la latenza mediana dei push si è ridotta di circa l'80%, quasi cinque volte più rapida di prima. Il sistema serve oggi quasi un petabyte di dati Git al giorno, con un picco superiore a 57 terabyte di pacchetti in una sola ora, di cui più del 99% servito dalla cache locale su disco (quindi senza dover andare a recuperare i dati altrove). Il progetto è stato sviluppato in circa dieci settimane, con il design centrale definito da un solo ingegnere e l'implementazione affidata in larga parte a team di agenti Codex.
## Cosa significa per chi non ha la scala di OpenAI
Nessuna PMI o team di sviluppo italiano ha bisogno di costruirsi un proprio backend Git. Ma il sintomo che Pando risolve — infrastruttura di versionamento che inizia a soffrire quando si introducono agenti di coding — è lo stesso che si presenta, in scala minore, in qualsiasi team che passa da "uno sviluppatore, un branch alla settimana" a "più agenti che aprono branch e push in parallelo". In un progetto tipico, questo si manifesta con CI che si accoda, clone che diventano lenti su repository molto grandi, o pipeline che falliscono in modo intermittente proprio nei momenti di picco.
La scelta di design più interessante da portare a casa, anche per chi lavora a scala molto più piccola, è quella di non inseguire una coerenza globale del repository quando non serve davvero: molti strumenti e automazioni interne vengono scritti assumendo che "leggere il repository" dia sempre una fotografia coerente di tutto, ma spesso basta la coerenza branch per branch. È un'assunzione da verificare prima di costruire automazioni fragili attorno al proprio Git.
Un limite da non sottovalutare: un modello di consistenza più permissivo, come quello scelto da Pando, può rompere tool che assumono letture coerenti su più branch contemporaneamente (dashboard che confrontano lo stato di branch diversi nello stesso istante, ad esempio). Prima di cambiare provider Git o abilitare funzionalità come il partial clone per inseguire velocità, vale la pena controllare che le proprie integrazioni non facciano quell'assunzione.
## In pratica
1. Monitora la crescita del numero di push, branch e job CI da quando usi agenti di coding: se cresce più rapidamente del numero di persone nel team, è un segnale da seguire prima che diventi un problema di produttività.
2. Verifica se il tuo provider Git (GitHub, GitLab, provider self-hosted) supporta già packfile-uri o partial clone: spesso la soluzione a un rallentamento non è cambiare infrastruttura, ma attivare funzionalità già disponibili.
3. Prima di costruire automazioni che leggono lo stato di più branch insieme, chiediti se davvero serve una coerenza globale istantanea o se basta la coerenza per singolo branch: la differenza cambia come vanno progettate quelle automazioni.
Se anche nel tuo team l'adozione di agenti di coding ha iniziato a far scricchiolare l'infrastruttura di versionamento, raccontalo nei commenti: è un problema che diventerà comune molto prima di quanto si pensi. Condividi l'articolo con chi gestisce CI/CD nella tua azienda, e se l'argomento ti interessa resta aggiornato sui prossimi approfondimenti.
Fonte: "Scaling Git at OpenAI", OpenAI, 2 novembre 2026 — https://openai.com/index/scaling-git-at-openai
AI, OpenAI, Git, DevOps, sviluppo software
