OpenAI dernier projet open source « Symphony » : un service de planification d'agents de codage autonome, écoutant les outils de gestion de projet (Linear, etc.), attribuant automatiquement un espace de travail isolé pour chaque problème, lançant Codex pour réaliser ce problème, jusqu'à ce que la tâche soit terminée ou transférée à une révision humaine. En une phrase : les ingénieurs gèrent les demandes, Symphony gère Codex, Codex écrit du code ! Pourquoi OpenAI fait-il ce projet ? Symphony est le produit extériorisé d'une pratique plus grande au sein d'OpenAI. Au second semestre de 2025, une petite équipe de trois personnes d'OpenAI a mené une expérience avec une contrainte extrême : l'ensemble du code du produit, zéro ligne de code écrit à la main. Tout le code a été réalisé par Codex, générant environ un million de lignes de code en cinq mois, fusionnant environ 1500 PR, ce qui équivaut à 3,5 PR par ingénieur par jour. Cette méthodologie a été distillée en Harness Engineering : les ingénieurs n'écrivent pas de code, mais conçoivent l'environnement, écrivent des contraintes, construisent des boucles de rétroaction, permettant aux agents de travailler de manière fiable. Symphony est la couche de planification de cette chaîne de production. Noyau de l'architecture : six niveaux · Policy Layer : WORKFLOW.md dans le dépôt, définissant les modèles de prompts et les stratégies d'exécution · Configuration Layer : analyse du front matter YAML, gestion des valeurs par défaut et des variables d'environnement · Coordination Layer : boucle de sondage, évaluation de l'éligibilité à la planification des problèmes, contrôle de la concurrence, logique de réessai · Execution Layer : gestion du cycle de vie de l'espace de travail du système de fichiers + lancement de sous-processus Codex · Integration Layer : adaptation de l'API Linear, normalisation de la structure des données des problèmes · Observability Layer : journaux structurés, tableau de bord HTTP optionnel WORKFLOW.md : l'âme du système Symphony n'a pas placé la configuration sur le serveur, mais a mis WORKFLOW.md dans le dépôt de code lui-même, le versionnant avec le code. Le fichier se divise en deux parties : · YAML front matter : configuration d'exécution (tracker, nombre de concurrents, délais, scripts de hooks) · Markdown body : modèles de prompts envoyés à Codex (syntaxe Liquid, pouvant injecter des champs de problème) Symphony écoutera en temps réel les modifications de ce fichier, prenant effet sans redémarrage - y compris l'ajustement de l'intervalle de sondage, des limites de concurrence, et du contenu des prompts. Les détails subtils de la concurrence et de la planification...