OpenAI accélère l'envoi de modifications vers Git de près de cinq fois avec Pando

L'agent a terminé sa modification, mais les tests n'ont pas encore commencé : il faut d'abord envoyer les changements et télécharger le code dans l'environnement de vérification. Avec des dizaines de tâches parallèles, l'attente liée à Git peut engloutir une partie du gain apporté par la génération rapide de code. L'histoire de Pando intéresse les équipes qui augmentent leur nombre d'agents et cherchent où se situera la prochaine file d'attente.

Ce qu'a montré OpenAI

Dans une analyse technique du 2 novembre, OpenAI décrit Pando, son backend Git interne. L'entreprise indique avoir réduit la latence médiane des push de près de cinq fois et distribuer près d'un pétaoctet de données Git par jour. La compatibilité avec le client et le protocole Git est préservée.

Deux choix sont au cœur du système : des mises à jour indépendantes des différentes branches et la réutilisation de paquets de données prêts à l'emploi en lecture. En revanche, la lecture de plusieurs branches ne garantit pas un instantané unique de l'ensemble du dépôt à un même moment. Pando fonctionne au sein d'OpenAI ; l'entreprise étudie des moyens de partager cette technologie, mais n'avance aucun calendrier de publication.

En pratique, la limite de la mesure compte. La médiane des push décrit la latence typique d'une seule opération. On ne peut pas en déduire à quel point une équipe livre son produit plus vite. Entre l'envoi des modifications et la mise en production, il reste les tests, les revues, les corrections et les validations. Une accélération de près de cinq fois sur cette étape ne promet pas, à elle seule, une accélération équivalente du développement.

Exemple : des agents préparent plusieurs modifications

Imaginons l'équipe d'une boutique en ligne. Un agent modifie la recherche, un deuxième répare le panier, un troisième met à jour les dépendances. Chacun travaille dans sa propre branche. Après l'envoi des modifications, le système de vérification doit récupérer la bonne version du code et lancer les tests. Si les vérifications démarrent en même temps, plusieurs lecteurs accèdent à la même histoire du dépôt.

La séparation du travail par branche permet de traiter ces opérations séparément. La modification de la recherche n'a pas à attendre la mise à jour du panier simplement parce que les deux vivent dans le même dépôt. Quant à la redistribution d'un paquet déjà prêt, elle ressemble à l'envoi d'une même archive à plusieurs destinataires : le serveur a intérêt à exploiter des données déjà préparées. Il s'agit d'une illustration simplifiée de deux principes de Pando, et non de la description de l'infrastructure d'une boutique réelle.

Mais une file d'attente distincte subsiste : il faut encore fusionner les modifications. Si deux agents modifient la même portion de code, un serveur rapide ne décidera pas à la place de l'équipe quelle version retenir. Il faut alors des règles d'attribution des tâches, une détection des conflits et une procédure de fusion claire. Les performances du stockage et la qualité du travail collaboratif doivent être mesurées séparément.

Il y a aussi une conséquence pour l'automatisation. Si un processus prend une décision à partir de plusieurs branches, il faut définir explicitement quelles versions il compare. Par exemple, la vérification de compatibilité de deux modifications doit figer des commits précis. Sinon, une nouvelle exécution pourrait tester une autre combinaison de code, et le développeur aurait du mal à reproduire le résultat.

Que vérifier chez soi

On peut commencer par mesurer une tâche complète, de la modification prête jusqu'au résultat de la vérification. Découpez le temps entre l'envoi des modifications, la récupération du code, l'attente d'un exécuteur libre et les tests eux-mêmes. Cette décomposition montrera quelle étape ralentit réellement le travail. Si l'essentiel du délai vient de la file d'attente des tests, remplacer le serveur Git n'aura qu'un effet limité.

Répétez ensuite la mesure avec un parallélisme normal puis de pointe. Pour l'équipe, le moment où des agents supplémentaires cessent de réduire le temps d'exécution des tâches est déterminant. Il est utile d'observer à la fois les latences typiques et les rares attentes très longues : ce sont elles qui peuvent retarder un correctif urgent. Les résultats doivent être comparés sur des tâches identiques et avec le même nombre de vérifications.

Pour un product manager ou un fondateur, ces données aideront à évaluer le coût de l'accélération. Un agent supplémentaire est utile si son résultat parcourt tout le chemin jusqu'à une modification acceptée. Si seuls le nombre de branches et de vérifications inachevées augmente, mieux vaut d'abord s'occuper de la file d'attente. L'enseignement pratique de Pando est d'inclure Git et la livraison du code dans la mesure de la performance du développement par agents. La décision d'investir dans une nouvelle infrastructure doit ensuite reposer sur vos propres mesures.