Quand les agents de code d'une entreprise se mettent à ouvrir des branches et à lancer des tâches en parallèle à grande échelle, la partie silencieuse de la chaîne d'outils à laquelle personne ne pense, la gestion de versions, devient ce qui casse. OpenAI dit que c'est exactement ce qui est arrivé à son propre service Git, et sa réponse a été de construire un nouveau backend à partir de zéro. Le signal utile ici n'est pas l'outil lui-même mais le profil de charge, que rencontrera toute équipe qui monte en charge ses agents dans sa propre intégration continue et sa gestion de versions.
La pression est venue de Codex, qui a permis aux ingénieurs d'OpenAI de faire bien plus de travail à la fois : plus de branches, plus de push, plus de fetch depuis les environnements de développement, les tâches de recherche et la CI. À partir de la fin de l'an dernier, les systèmes derrière son monorepo ont peiné, avec une fiabilité tombant parfois sous 90%, c'est-à-dire des push et merge lents ou échoués. Plutôt que d'abandonner Git, OpenAI a gardé le flux de travail familier et reconstruit le backend en dessous, nommant le résultat Pando. Les objectifs de conception étaient de scaler les écritures sur de nombreuses branches à la fois et de servir le même historique à de nombreux lecteurs depuis un cache.
Les résultats rapportés sont substantiels. Pando a réduit la latence d'un push médian de près de 80%, et sert désormais près d'un pétaoctet de données Git par jour, avec plus de 57 téraoctets en une seule heure et plus de 99% de ces octets venant du cache disque local. OpenAI l'a construit en Rust sans dépendances héritées, et dit être passé du lancement à la production en environ 10 semaines, Codex lui-même et un mélange de modèles faisant une grande partie du travail. Il a commencé à servir du trafic de production en avril.
La pertinence pour le reste d'entre nous est le profil, pas le produit. Pando n'est pas open source, la plupart des équipes ne peuvent donc pas l'adopter. Seules les améliorations côté client qu'OpenAI a reversées à Git sont publiques, via son propre fork, ce qui veut dire que cela se lit davantage comme un avertissement que comme un outil : les systèmes autour de Git ont été façonnés par deux décennies de flux de travail humains, et des essaims d'agents les poussent d'une façon pour laquelle ces outils n'étaient pas dimensionnés.
Les réserves honnêtes sont celles de tout billet d'ingénierie d'un fournisseur. Les chiffres de fiabilité et de latence viennent d'OpenAI et n'ont pas été vérifiés de façon indépendante, et un backend réglé pour un très grand monorepo peut ne pas se transposer à des dépôts plus petits ou de forme différente. Malgré tout, à mesure que davantage d'équipes pointent des agents sur leurs bases de code, la leçon que le travail machine parallèle met la CI et la gestion de versions sous tension de façons nouvelles mérite d'être prise au sérieux avant qu'elle n'apparaisse comme vos propres merge échoués. Nous testons OpenAI Codex, l'agent qui a créé cette charge en premier lieu.