OpenAI présente Pando, son backend Git pour le développement à l’échelle de Codex

Ce qui est nouveau

OpenAI présente Pando, un nouveau backend — la partie serveur — pour ses dépôts Git. Il prend déjà en charge l’ensemble du développement dans son monorepo, le dépôt qui rassemble son code. Selon l’entreprise, la migration n’a interrompu ni le travail des équipes ni modifié leur manière d’utiliser Git : Pando conserve la compatibilité avec le protocole et le client existants.

En production, OpenAI annonce une latence médiane d’envoi des modifications presque divisée par cinq et un volume de données Git distribué proche d’un pétaoctet par jour. Ces mesures portent sur son infrastructure interne.

Ce qui change et pourquoi

OpenAI attribue la pression sur son infrastructure à Codex : davantage de travaux menés en parallèle entraînent plus de branches, d’envois de modifications, de fusions et de téléchargements. Les tâches d’intégration continue multiplient encore les lectures du même code. L’entreprise rapporte que son système précédent souffrait de lenteurs et d’échecs de fusion.

Pando coordonne les mises à jour branche par branche. Des écritures sur des branches distinctes peuvent ainsi avancer en parallèle. En contrepartie, une lecture portant sur plusieurs branches peut les observer à des instants différents.

Pour les lectures, Pando réutilise des fichiers compressés d’objets Git, les packfiles, plutôt que d’en produire un spécifique à chaque client. Le serveur peut distribuer les mêmes données depuis des caches avec moins de calcul, au prix du téléchargement éventuel d’objets déjà présents chez le client.

Pourquoi c’est important

Le cas illustre les effets du développement assisté par agents sur l’infrastructure de gestion du code, au-delà de la génération elle-même. OpenAI a choisi de reconstruire le serveur sans imposer un nouvel outil aux ingénieurs et aux agents.

Les gains annoncés concernent toutefois son propre dépôt, pas une mesure générale des performances de Git. OpenAI indique aussi vouloir proposer à la communauté Git les améliorations apportées à sa copie du logiciel ; cela ne signifie pas qu’elles sont déjà intégrées au projet principal.