Pando e Git: gli agenti accelerano il codice, ma chi regge la concorrenza?

Il problema non è quanti commit produce un agente

Quando si parla di sviluppo assistito dall’intelligenza artificiale, la discussione finisce quasi sempre sulla qualità del codice generato. È una domanda importante, ma incompleta. Se un sistema permette a più agenti di lavorare contemporaneamente, il problema si sposta: non basta produrre modifiche, bisogna trasferirle, verificarle, integrarle e renderle disponibili agli altri senza trasformare ogni operazione in una coda.

Il 2 novembre 2026 OpenAI ha raccontato l’architettura di Pando, un backend compatibile con Git che oggi serve il monorepo aziendale. La notizia interessante non è che OpenAI abbia costruito un altro servizio. È che abbia cambiato alcune assunzioni infrastrutturali mantenendo gli strumenti con cui gli sviluppatori lavorano già.

Git non era necessariamente il collo di bottiglia. Lo era il modo di servirlo

Un repository non è soltanto un insieme di file: contiene oggetti immutabili, commit, alberi e riferimenti ai branch. Il server deve ricevere nuovi oggetti, aggiornare le ref e garantire che chi legge un commit possa ottenere tutti gli oggetti necessari. In un team tradizionale, molte di queste operazioni si distribuiscono naturalmente nel tempo. Quando gli agenti moltiplicano branch, push, fetch e job CI, il profilo di carico cambia.

Secondo OpenAI, il precedente sistema aveva iniziato a soffrire rallentamenti e problemi di affidabilità, talvolta sotto il 90%. Il dato è dichiarato dall’azienda e non va scambiato per un benchmark indipendente. Il punto architetturale, però, è verificabile: se ogni aggiornamento di branch indipendenti deve passare da un unico ordine globale, la concorrenza si trasforma in contesa.

La scelta scomoda: rinunciare allo snapshot globale

Pando coordina gli aggiornamenti per singola ref. Due push sulla stessa branch devono ancora risolvere un conflitto; due push su branch diverse possono procedere senza aspettarsi. In cambio, un client che osserva più branch non riceve necessariamente una fotografia globale dello stesso istante. OpenAI descrive questo compromesso come consistenza causale, con serializzazione degli aggiornamenti sulla singola ref.

È una scelta da ingegneria dei sistemi distribuiti, non una scorciatoia. Prima si identifica quale garanzia serve davvero al consumatore, poi si evita di pagare il costo delle garanzie più forti quando non sono indispensabili. Ma il trade-off va dichiarato: un’automazione che pretende una vista atomica di tutte le branch non può semplicemente presumere che Pando gliela fornisca.

La scalabilità non nasce dal rendere tutto parallelo. Nasce dal capire quali operazioni devono davvero aspettarsi.

Meno lavoro ripetuto per ogni fetch

L’altro intervento riguarda i dati. Un server Git convenzionale può calcolare e comprimere un packfile specifico per ogni client, in base agli oggetti che quel client possiede già. È efficiente in termini di byte trasferiti, ma può essere costoso in CPU e I/O quando moltissimi client chiedono storie simili.

Pando conserva i packfile ricevuti dai push in uno storage a oggetti e li riutilizza. Attraverso la funzionalità Git packfile-uri, il server comunica al client gli indirizzi dei pack necessari, serviti tramite cache regionali. In questo modo parte del costo viene spostata dalla ricompressione ripetuta alla distribuzione di oggetti immutabili. La conseguenza è che un client può ricevere qualche oggetto ridondante: è un compromesso deliberato fra banda, cache e CPU.

OpenAI riferisce cache hit superiori al 99%, trasferimenti capaci di saturare link da 10 Gbps e quasi un petabyte di dati Git serviti al giorno. Sono metriche operative pubblicate dal produttore, non risultati di un confronto indipendente. Non autorizzano a promettere gli stessi guadagni su un repository aziendale più piccolo.

La compaction non è manutenzione accessoria

Conservare i packfile non basta. Se ogni push aggiunge un nuovo pack e un client deve scaricarne migliaia, la latenza di negoziazione diventa il problema successivo. Pando aggrega i pack in background in livelli di copertura, con una logica che ricorda le strutture log-structured merge. Questo riduce il numero di unità da pianificare per i fetch e migliora il riutilizzo delle informazioni sugli oggetti.

La lezione è più ampia di Git: ogni ottimizzazione che elimina lavoro sincrono può creare un nuovo debito nel lavoro asincrono. Senza compaction, osservabilità e criteri di recupero, il sistema rischia di spostare il collo di bottiglia anziché risolverlo.

Gli agenti hanno scritto Pando. La verifica non è stata delegata alla fiducia

OpenAI afferma di aver portato Pando dall’avvio alla produzione in dieci settimane, con implementazione in Rust e contributi di Codex. Il dettaglio che conta è il metodo di validazione descritto: suite di conformità rispetto al comportamento Git, simulazioni deterministiche, controlli sulle race condition e formalizzazioni con Lean e TLA+. Non è la prova che il codice generato dagli agenti sia automaticamente corretto; semmai dimostra quanta infrastruttura di verifica sia necessaria quando il software diventa distribuito e concorrente.

Questo si collega a un tema che ho già affrontato parlando di agenti che devono produrre test eseguibili. Il numero di righe generate è una metrica comoda da esibire. Le invarianti che il sistema continua a rispettare quando aumentano gli utenti, invece, sono ciò che permette di mandarlo in produzione.

Cosa può imparare chi sviluppa software senza avere il monorepo di OpenAI

Non serve costruire Pando per trarre un’indicazione utile. Prima di cambiare modello AI o acquistare altra capacità di calcolo, misurerei dove si accumula attesa nel ciclo completo: branch, build, test, code review, merge, deploy. Separerei le operazioni che richiedono coordinamento globale da quelle indipendenti. E distinguerei sempre il tempo di generazione del codice dal tempo necessario a renderlo verificato e utilizzabile.

C’è anche una scelta di prodotto: OpenAI ha mantenuto compatibilità con protocollo e client Git, anziché imporre un nuovo workflow agli sviluppatori. È una migrazione infrastrutturale più complessa, ma evita di scaricare sugli utenti il costo di un’ottimizzazione interna. Lo stesso principio vale in tanti progetti: un backend può cambiare radicalmente senza costringere ogni client a ricominciare da zero.

La conclusione non è che Git sia superato dagli agenti. È quasi il contrario: quando aumenta la capacità di produrre software, diventano ancora più importanti i protocolli, i contratti di consistenza e i sistemi che permettono di verificare ciò che è stato prodotto. Il modello accelera una fase. L’architettura decide se il resto del processo riesce a seguirla.