La première fois que Symphony a récupéré un de mes tickets Linear et a envoyé une pull request fonctionnelle sans que je touche un clavier, je suis resté assis là pendant une minute entière à essayer de comprendre ce que j'étais censé faire ensuite.
Mon ticket disait : "Ajouter un middleware de limitation de débit aux points de terminaison publics API, par défaut 60 req/min, autoriser les remplacements par route." Je l'avais déplacé dans "En cours" par habitude, lancé la boîte de développement Symphony et changé d'onglet pour répondre à un message Slack. Onze minutes plus tard, un projet de PR existait. L'agent avait créé un espace de travail isolé, lu ma base de code, écrit le middleware, ajouté des remplacements au niveau de la route, écrit trois tests et poussé une branche. La différence n'était pas parfaite – j'ai rejeté un test et resserré un commentaire – mais le travail était réel. Le travail était terminé.
Ce ticket a été le moment où l'orchestrateur d'agents OpenAI Symphony a cessé d'être une démo pour moi et a commencé à être un outil. Cela m'a également obligé à faire face à quelque chose d'inconfortable : la façon dont j'utilisais Codex et Claude Code au cours de l'année dernière – un terminal, une invite à la fois, un humain gardant un agent – était sur le point de paraître aussi obsolète que SSH sur un seul serveur pour déployer une application Web en 2014.
C’est le poste que j’aurais aimé que quelqu’un me confie avant de passer deux week-ends à recâbler ma façon de penser l’infrastructure des agents. Je vais vous montrer ce qu'est réellement Symphony (il est plus petit et plus étrange que ne le suggèrent les communiqués de presse), comment il s'inscrit dans le modèle plus large que les gens appellent "harness engineering", ce que j'ai cassé lorsque j'ai essayé de le plier à ma propre pile, et le seul changement mental qui a fait tout cliquer.
Un avertissement avant d'aller plus loin : un certain nombre circule : l'affirmation de OpenAI selon laquelle certaines équipes internes ont constaté une augmentation de 500 % des demandes de tirage reçues dans les trois semaines suivant l'adoption de Symphony (OpenAI). Je reviendrai sur ce chiffre plus tard dans cet article, car la façon dont vous le lisez détermine si vous construisez la bonne ou la mauvaise chose.
Qu'est-ce que OpenAI Symphony est réellement (et ce qu'il n'est pas)
Permettez-moi de tuer une idée fausse d'emblée : Symphony n'est pas un produit. Ce n'est pas un SaaS. Ce n'est pas un binaire fermé. Il n'y a pas de tableau de bord auquel vous vous connectez.
Symphony est un fichier SPEC.md. C'est tout l'artefact principal. OpenAI l'a publié en open source sous Apache 2.0 le 5 mars 2026 et, fin avril 2026, le dépôt openai/symphony GitHub avait franchi 15 000 étoiles (Help Net Security). La spécification décrit — en anglais simple, avec des diagrammes d'état — comment un orchestrateur de longue date devrait transformer un outil de suivi des problèmes en un plan de contrôle pour les agents de codage autonomes.
L'implémentation de référence est livrée dans Elixir. Oui, Élixir. Le même langage que Discord et WhatsApp utilisent sous le capot. OpenAI l'a choisi parce que BEAM (le runtime d'Elixir) vous offre gratuitement des arborescences de superviseurs, des processus légers et une sémantique de récupération après incident - exactement ce que vous voulez lorsque vous exécutez dix ou vingt agents de codage qui peuvent chacun prendre vingt minutes par tâche et dont l'un peut mourir silencieusement.
Mais voici la partie qui m'a surpris. L'équipe OpenAI a demandé à Codex de générer l'implémentation d'Elixir d'un seul coup à partir de la spécification, puis a demandé à Codex de réimplémenter la même spécification dans TypeScript, Go, Rust, Java et Python — en utilisant chaque implémentation comme fonction de forçage pour trouver des ambiguïtés dans la spécification elle-même (InfoWorld). La spécification est le produit. Le code Elixir n’est que l’exemple le plus raffiné.
C'est important car cela vous indique quel type d'outil vous évaluez réellement. Symphony n'est pas « le cadre d'orchestration de OpenAI ». Il s'agit d'un vocabulaire partagé décrivant à quoi ressemble une bonne orchestration d'agents de codage, avec une référence de travail que vous pouvez soit exécuter telle quelle, soit voler.
La boucle principale, en un seul paragraphe
Symphony interroge Linear toutes les 30 secondes. Lorsqu'il voit un ticket passer dans un état configuré "prêt", il prétend que ce ticket fait tourner un espace de travail isolé (un nouvel arbre de travail git sur une devbox), démarre un agent Codex dans cet espace de travail avec une invite structurée qui inclut le corps du ticket, laisse l'agent s'exécuter en continu jusqu'à ce qu'il produise un PR ou échoue, puis marque le ticket "prêt pour examen" ou "bloqué" avec une raison. La concurrence par défaut est de 10 agents. L'état est en mémoire dans un GenServer ; au redémarrage, il se reconstruit simplement à partir de Linear, il n'y a donc pas de base de données à exploiter (allthings.how).
C'est ça. C'est tout. Relisez ce paragraphe, car la simplicité est le point important.
Pourquoi le battage médiatique m'a pris au dépourvu
Je vais être honnête. Lorsque le billet de blog OpenAI est arrivé début mars, je l'ai parcouru à moitié et je suis passé à autre chose. "Un autre agent orchestrateur", telle était la pensée cynique. J'avais déjà joué avec Steve Yegge's Gas Town, j'exécutais Archon sur un projet parallèle pendant trois semaines et j'avais construit mon propre harnais Claude Code de longue durée pour un client. Aucun de ces outils n’avait besoin d’un quatrième concurrent.
Ce que j'ai manqué – ce que la plupart des reportages ont manqué – c'est que Symphony n'est pas vraiment en concurrence avec ces outils. Il est en concurrence avec la version de vous qui ouvre un terminal, tape codex ou claude et regarde un agent travailler sur une tâche. C'est en concurrence avec la supervision manuelle elle-même. Une fois que j'ai compris cela, ma semaine entière a changé.
Pour expliquer pourquoi, je dois faire un détour par le terme qui est devenu le concept le plus important dans la livraison de logiciels assistée par AI cette année : harness engineering.
Harness Engineering : Le vocabulaire qui a fait cliquer tout
En avril 2026, Birgitta Böckeler, responsable mondiale de Thoughtworks pour la fourniture de logiciels assistés par AI, a publié un article long et minutieux sur martinfowler.com intitulé « Ingénierie de harnais pour les utilisateurs d'agents de codage ». C'est l'article qui nous a donné la taxonomie canonique. (Le résumé vidéo sur lequel j'ai travaillé rendait phonétiquement son nom comme "Vetta Berkeler" - même personne, même cadre.)
Le cadrage est d’une simplicité trompeuse :
Agent = Modèle + Harnais
Le modèle est le LLM. Tout le reste – les invites, les outils, le bac à sable, la boucle, les validateurs, l'orchestrateur – est le harnais. Et une fois que vous avez commencé à nommer les parties du harnais, vous pouvez commencer à les concevoir délibérément plutôt qu'accidentellement.
Böckeler divise le harnais en deux couches et Symphony vit carrément dans l'une d'elles.
Harnais intérieur – Qu'y a-t-il à l'intérieur de l'agent
Le faisceau interne correspond au code et aux fonctionnalités fournis à l'intérieur de l'agent lui-même. Lorsque vous exécutez Claude Code, vous obtenez gratuitement le harnais interne : le protocole d'appel d'outils, les outils de lecture de fichiers et d'exécution de shell, les invites de planification, la génération de sous-agents, les portes d'autorisation, le système de hooks, les compétences que vous pouvez installer. Idem avec Codex. Idem avec le curseur.
Vous n’écrivez généralement pas le harnais intérieur. Vous le configurez. Vous activez les hooks. Vous installez des compétences. Vous écrivez un CLAUDE.md ou un AGENTS.md. Vous définissez les autorisations dans settings.json. Le harnais interne est ce qui fait d’un modèle un agent de codage.
Harnais extérieur – Ce qui entoure l'agent
Le faisceau externe est tout ce qui est extérieur à l'agent qui contrôle son cycle de vie, gère son contexte, décide quand il s'exécute, sur quoi il s'exécute, ce qui compte comme « terminé » et ce qui se passe en cas d'échec. C'est ici que vit Symphony. C'est également là que vivent Gas Town, Archon et Ralph loops.
Le harnais externe est ce qui transforme une session de terminal de Claude Code en une flotte de vingt agents parallèles en qui vous avez réellement confiance.
Voici l'image mentale que je dessine sur un tableau blanc lorsque j'explique cela aux clients :
┌──────────────────────────────────────────┐
│ OUTER HARNESS │
│ Symphony / Gas Town / Archon / Ralph │
│ - lifecycle, queues, isolation, retries │
│ ┌──────────────────────────────────┐ │
│ │ INNER HARNESS │ │
│ │ Claude Code / Codex / Cursor │ │
│ │ - tools, hooks, skills, perms │ │
│ │ ┌────────────────────────┐ │ │
│ │ │ MODEL │ │ │
│ │ │ GPT-5.x / Sonnet / │ │ │
│ │ │ Opus / etc. │ │ │
│ │ └────────────────────────┘ │ │
│ └──────────────────────────────────┘ │
└──────────────────────────────────────────┘
Une fois que vous voyez les calques, chaque "produit agent AI" se positionne sur cette image. Et une fois que cela se produit, la vraie question cesse d'être « quel agent dois-je utiliser ? » » et devient « Qu'est-ce que mon harnais extérieur doit faire pour que personne d'autre ne puisse le faire ? »
C'est la question à laquelle Symphony vous oblige à répondre.
Guides et Sensors — Les deux leviers de chaque harnais
À l’intérieur des deux couches, Böckeler introduit une autre distinction à laquelle je pense désormais chaque fois que j’écris une invite d’agent ou que je configure une étape CI. Chaque élément significatif d'un harnais effectue l'une des deux tâches suivantes.
Guides dirige l'agent avant qu'il n'agisse. Ce sont des contrôles anticipés. Votre CLAUDE.md. Les compétences que vous installez. Le playbook que vous collez dans l'invite. L'exemple engage votre référence. La décision d'architecture enregistre les lectures de l'agent avant d'écrire du code. Guides augmente la probabilité que l'agent réussisse dès la première tentative.
Sensors observez l'agent après son action et décidez si ce qu'il a produit est acceptable. Ce sont des contrôles par rétroaction. Sensors est disponible en deux versions :
- Capteurs informatiques — déterministes, rapides et bon marché. Linters. Tapez les dames. Tests unitaires. Validateurs de schéma. Créez des résultats. Ils s'exécutent en millisecondes ou en secondes et vous donnent une réponse binaire (Martin Fowler).
- Capteurs inférentiels — non déterministes, lents et coûteux. Révisions du code LLM-as-juge. Vérifications de similarité sémantique. Critiques de style. Ils fonctionnent sur un GPU, prennent de quelques secondes à quelques minutes et vous donnent des réponses probabilistes.
Voici la partie qui m'a pris un temps embarrassant à intérioriser : la plupart des équipes avec lesquelles j'ai travaillé sous-utilisent les capteurs informatiques et s'appuient trop sur les capteurs inférentiels. Elles mettront en place un "réviseur AI" avant d'avoir configuré eslint --max-warnings 0 dans un hook de pré-validation. Ils bénéficieront d'une couverture de test de niveau LLM en tant que juge avant d'ajouter un seuil de couverture à CI.
Les capteurs informatiques sont fondamentalement gratuits. Ils sont prouvés. Ils fonctionnent dans les pipelines CI depuis quinze ans. La raison pour laquelle ils sont ignorés dans les flux de travail des agents est que les praticiens oublient que l'agent peut lire leur sortie et s'auto-corriger. Au moment où vous connectez npm test dans la boucle de l'agent et que vous renvoyez les échecs comme contexte, votre taux d'erreur diminue d'un facteur que je ne peux vraiment pas estimer sans mentir. C'est beaucoup.
J'y reviendrai lorsque je vous montrerai à quoi ressemble un véritable fichier de workflow Symphony, car les guides et capteurs constituent l'ensemble du vocabulaire que vous utilisez pour en créer un. Pour l'instant, restez assis avec ceci : un harnais est un ensemble soigneusement choisi de guides et de capteurs disposés autour d'un modèle. L'orchestrateur est simplement la chose qui fait fonctionner le harnais dans une file d'attente.
Où Symphony s'intègre dans la famille des harnais extérieurs
Symphony n'est pas le seul harnais extérieur disponible dans la nature, et ce n'est pas toujours la bonne réponse. Permettez-moi de passer en revue les quatre que j'ai utilisés dans le travail de production cette année, car les compromis sont importants.
1. Symphony — Orchestration native de suivi des problèmes
Le choix déterminant de Symphony est que le système de suivi des problèmes est la file d'attente. Les tickets Linear sont les unités de travail. Il n’existe pas d’interface utilisateur Symphony distincte à gérer. Vous déplacez un ticket vers « Prêt pour Codex », Symphony le récupère, un agent court, un PR apparaît lié au ticket et vous examinez le ticket comme vous l'avez toujours fait. La charge cognitive liée à son adoption est à peu près nulle, car vous n'apprenez pas un nouvel outil de gestion de projet.
Le compromis est que la surface de Symphony est petite. Il fait une chose : transformer les billets en courses – et il le fait bien. Si votre travail ne rentre pas dans des tickets discrets (recherche de longue durée, refactoristes sur plusieurs semaines, pics exploratoires), Symphony n'est pas votre outil.
2. Gas Town – Colonies multi-agents, style Steve Yegge
Gas Town est le framework de Steve Yegge pour exécuter 20 à 30 agents Claude Code parallèles organisés en rôles (les maires orchestrent, les putois exécutent), avec un état persistant dans Git via la pile MEOW (Cloud Native Now). Là où Symphony suppose « un ticket, un agent, un PR », Gas Town suppose des essaims coordonnés travaillant sur des travaux connexes avec des transferts explicites.
J'ai couvert le modèle "style essaim" plus en détail dans mon [article sur l'architecture d'essaim d'agents Claude Code] (/claude-code-agent-swarm-architecture/) - si vous construisez quelque chose où plusieurs agents doivent se coordonner sur la même tâche plutôt que sur des tâches parallèles, c'est l'article à lire après celui-ci.
3. Archon — Flux de travail déterministes autour de n'importe quel agent de codage
Archon se présente comme « le premier constructeur de harnais open source » — le cadrage est exact. Là où Symphony code en dur le flux de travail (interrogation Linear → agent d'exécution → PR), Archon vous permet de créer le flux de travail en tant que pipeline YAML avec des phases explicites, des portes de validation et des artefacts. Chaque exécution obtient son propre arbre de travail git. Vous pouvez exécuter cinq correctifs en parallèle sans conflit (MindStudio).
Je contacte Archon lorsque le travail comporte des phases connues – « enquêter, planifier, mettre en œuvre, tester, documenter » – et je souhaite que chaque phase soit une étape validée distincte plutôt qu'une longue exécution d'agent. C'est également le cousin le plus proche des approches spec-driven comme celle dont j'ai parlé dans ma [pièce Traycer BART-mode spec-driven AI] (/traycer-bart-mode-spec-driven-ai/).
4. Boucles Ralph — Le harnais extérieur minimum viable
La boucle Wiggum Ralph (oui, du nom du personnage des Simpsons : "J'aide !") est le harnais externe le plus simple possible : une boucle while true qui réinvoque l'agent jusqu'à ce qu'une vérification déterministe réussisse. Il existe un plugin Anthropic officiel dans le dépôt Claude Code et Vercel Labs expédie ralph-loop-agent pour le SDK AI.
La philosophie Ralph : ne visez pas la perfection du premier coup. Laissez la boucle s'affiner. L'agent lit un fichier de plan, progresse, la boucle vérifie l'achèvement par rapport aux critères et si ce n'est pas fait, l'agent s'exécute à nouveau avec le dernier état (beuke.org).
Ralph n'est pas compétitif avec Symphony — il est complémentaire. Un ticket Symphony peut exécuter une boucle Ralph dans son espace de travail. Symphony gère la file d'attente et l'isolation. Ralph gère l'itération jusqu'à ce qu'elle soit correcte. Connectez-les ensemble et vous obtenez quelque chose de véritablement puissant.
Configuration de Symphony sur un vrai dépôt
Assez de théorie. Laissez-moi vous montrer exactement ce que j'ai fait pour faire fonctionner Symphony sur un projet parallèle la semaine dernière. Le tout m'a pris environ 90 minutes de git clone au premier PR, et la majeure partie était la configuration de Linear, et non Symphony lui-même.
Étape 1 : Obtenez la clé Linear API
Dans Linear, accédez à Paramètres → Sécurité et accès → Clés personnelles API et créez une nouvelle clé. Définissez-le comme LINEAR_API_KEY dans votre environnement. Symphony utilise ce jeton via son outil dynamique linear_graphql : il n'expose pas le jeton brut aux sous-agents, ce qui constitue un choix de sécurité modeste mais réfléchi (allthings.how).
Étape 2 : clonez le dépôt et choisissez une implémentation
git clone https://github.com/openai/symphony.git
cd symphony
Le dépôt a la spécification SPEC.md et la référence Elixir sous elixir/. Si Elixir est installé (brew install elixir sur macOS), vous pouvez l'exécuter en deux minutes. Si vous ne le faites pas, la simplicité de la spécification signifie réécrire l'orchestrateur dans un langage que vous savez véritablement traitable - c'est tout l'intérêt de distribuer une spécification au lieu d'un binaire.
Pour le reste de cette procédure pas à pas, je montrerai le chemin de l'Élixir car c'est ce que j'ai utilisé.
cd elixir
mix deps.get
mix compile
Étape 3 : Configurez votre flux de travail
Copiez le modèle WORKFLOW.md dans le dépôt cible (celui sur lequel vous souhaitez que les agents travaillent, et non le dépôt Symphony lui-même). C'est là que le vocabulaire du harnais s'avère payant, car WORKFLOW.md est essentiellement votre spécification de guide et de capteur pour chaque exécution d'agent. Une version réduite de la mienne ressemblait à ceci :
## Avant de commencer
- Lisez README.md et ARCHITECTURE.md
- Exécutez `npm install` et `npm test` pour confirmer les passes de base
## Implémentation
- Effectuer le plus petit changement qui satisfait le ticket
- Ajouter ou mettre à jour des tests pour tout nouveau comportement
- Exécutez `npm test` et `npm run lint` avant de considérer que c'est terminé
- Exécutez `npm run typecheck` — aucune erreur requise
## Définition de terminé
- Tous les tests réussissent localement
- Réussite des peluches et des contrôles de type sans aucun avertissement
- Le titre PR correspond au titre du billet
- La description du PR fait référence à l'ID du ticket Linear.
That document is doing serious work. The "Before you start" section is a guide. The four sensor commands (npm test, npm run lint, npm run typecheck, plus the ticket-link convention) are computational sensors. There's not a single LLM-as-judge in there yet, and the system already works. Don't reach for inferential sensors until your computational ones are saturated.
Step 4: Point Symphony At Linear
In your .env:
LINEAR_API_KEY=lin_api_your_key_here
SYMPHONY_TARGET_REPO=/Users/you/code/your-project
SYMPHONY_LINEAR_TEAM_ID=votre_équipe_id
SYMPHONY_TRIGGER_LABEL=prêt pour le codex
SYMPHONY_MAX_CONCURRENT=4
I cap concurrency at 4 on my laptop because Codex sessions are not free and I'd rather watch four serious runs than ten degraded ones. On a devbox you'd raise this.
Step 5: Run It
mix run --no-halt
C'est la configuration complète. Symphony interroge désormais Linear toutes les 30 secondes. Marquez n'importe quel ticket avec ready-for-codex et un agent le réclamera.
La première fois que j'ai fait cela, j'ai créé un ticket délibérément petit — "Ajouter un point de terminaison /health qui renvoie { status: 'ok', uptime_seconds: <number> }" — et j'ai regardé. L'agent l'a récupéré en 31 secondes. Il lit la base de code. Il a trouvé mon application Express. Il a écrit l'itinéraire, écrit un test, exécuté le test (qui a réussi au deuxième essai après avoir résolu un petit problème d'inférence TypeScript), ouvert un PR et étiqueté le ticket Linear comme « révision nécessaire ». Temps total du mur : 4 minutes 18 secondes. J'ai lu le différentiel. J'ai fusionné.
Je me suis assis là et j'ai regardé l'écran.
Ce que je me suis trompé en chemin
Je veux passer du temps réel sur cette section parce que c'est là que j'ai le plus appris, et parce que chaque article de « premier aperçu » que j'ai lu sur Symphony la passe sous silence. J'ai commis quatre erreurs qui méritent d'être signalées.
Erreur 1 : j'ai traité Symphony comme Claude Code
Pendant les deux premiers jours, j'ai continué à ouvrir le terminal devbox Symphony dans l'espoir de parler aux agents en cours d'exécution. Symphony ne fonctionne pas de cette façon. Les agents sont sans tête. Vous communiquez avec eux via des tickets. Si vous souhaitez donner plus de contexte à un agent, vous modifiez la description du ticket Linear (ou ajoutez un commentaire) et laissez le cycle d'interrogation suivant prendre en compte la modification. Si vous souhaitez rediriger un agent en cours de vol, la réponse dans 90 % des cas est ne pas le faire : arrêtez la course, modifiez le ticket, laissez-le repartir à zéro.
C’était un changement mental. Il m'a fallu quelques jours pour arrêter de traiter les agents comme des collaborateurs avec lesquels je faisais de la programmation en binôme et commencer à les traiter comme des travailleurs à qui je délivrais des tickets. Soit dit en passant, ce changement est exactement ce que la conception de Symphony essaie de vous imposer. Concevez vos tickets comme des spécifications de produit, pas comme des messages Slack.
Erreur 2 : j'ai écrit des billets vagues
Mes premiers tickets étaient le même genre de phrases que je donnerais à un coéquipier senior : "Refactoriser le middleware d'authentification". Un coéquipier senior comble les lacunes avec un contexte partagé. Ce n’est pas le cas d’un agent. Lorsque j'ai écrit "Refactorisez le middleware d'authentification pour extraire la validation JWT dans une fonction distincte, conservez le API public existant de requireAuth(req, res, next), ajoutez des tests pour la fonction extraite et ne modifiez pas les enregistrements de route", l'agent a envoyé un PR propre lors de la première exécution.
Le principe : chaque ambiguïté dans votre ticket devient un tirage au sort dans le comportement de votre agent. Les billets sont des guides. Plus vous chargez le guide en avant, moins vous aurez besoin des capteurs pour rejeter les mauvaises sorties.
Erreur 3 : j'ai ignoré le calcul Sensors
Mon dépôt cible avait npm test et npm run lint, mais je ne les avais pas ajoutés à la définition WORKFLOW.md de done. Techniquement, l’agent effectuait des tests quand il en avait envie. Environ un PR sur trois a échoué à ses tests à son arrivée, ce que j'ai dû rebondir. Le correctif consistait en trente secondes de modification de WORKFLOW.md pour rendre les commandes du capteur non négociables. Le taux d'échec est tombé à environ un sur quinze, conformément à ce que je vois lorsque j'exécute Codex manuellement.
Vous n'imaginez pas combien de fois la réponse est « ajoutez une vérification déterministe à votre fichier de flux de travail ».
Erreur 4 : j'ai essayé d'exécuter Symphony sans isolation Worktree
Par paresse, j'ai pointé deux exécutions parallèles à la même caisse du même dépôt. Un carnage prévisible. La conception de Symphony suppose – et la référence Elixir l'applique – l'isolation de git worktree par ticket. Ne le combattez pas. Chaque agent obtient sa propre copie de travail. C'est ainsi que cinq agents touchant différentes parties de votre base de code ne finissent pas par piétiner les WIP de chacun.
C'est également là que la conception de Symphony commence à ressembler beaucoup à l'approche d'Archon « chaque exécution de workflow a son propre arbre de travail git ». La convergence n'est pas un accident. L'arbre de travail par course est en train de devenir la convention portante de tous les harnais extérieurs sérieux.
Si vous préférez confier ce type de configuration à quelqu'un qui l'a déjà fait, Ramlit Limited construit et exploite exactement ces pipelines d'orchestration pour les équipes d'ingénierie qui souhaitent obtenir un débit sans la courbe d'apprentissage de huit week-ends. Mais le chemin est véritablement praticable par vous-même – c'est l'essentiel de ce que j'essaie de vous montrer ici.
Comment lire le nombre de 500 % ?
Je vous ai dit plus tôt que j'y reviendrais. L'indicateur principal de OpenAI est que certaines équipes internes ont vu les demandes d'extraction reçues augmenter de 500 % au cours des trois premières semaines d'utilisation de Symphony (OpenAI).
Voici la lecture honnête.
Ce nombre est réel, au sens étroit du terme. Le débit des relations publiques a augmenté. C’est mesurable, reproductible et indiscutable. Mais les « PR obtenus » sont une mesure de génération, et comme plusieurs analystes l'ont souligné, la génération évolue sans effort. La validation ne le fait pas. (opentools.ai).
Dans mon propre (petit) échantillon sur trois semaines de travail en parallèle avec Symphony, mon débit de relations publiques a été multiplié par 3 à 4 sur les types de tickets pour lesquels Symphony est bon : bien étendu, à fonctionnalité unique, pouvant être couvert par des tests. Sur les tickets ambigus, les performances étaient pires que celles de moi-avec-Claude-Code, car chaque tirage au sort dans la spécification s'aggravait.
Le modèle mental sur lequel j'ai opté : Symphony déplace le goulot d'étranglement de "l'écriture du code" à "l'écriture de la spécification et la révision du PR". Il s'agit d'un véritable gain de productivité si et seulement si votre processus de rédaction et de révision des spécifications peut suivre le rythme. Si la révision devient le goulot d'étranglement et que vous commencez à approuver les PR pour libérer la file d'attente, vous avez vous-même conçu un moyen plus rapide de produire de la dette technique.
Ainsi, lorsque vous voyez « 500 % », traduisez-le par : « cette équipe disposait de processus de rédaction et de révision de spécifications suffisamment matures pour que 5 fois plus de code soit réellement livrable ». C'est la question à vous poser avant d'adopter Symphony, et non « puis-je exécuter plus d'agents ? mais "puis-je examiner les résultats de plus d'agents sans que la qualité ne s'effondre ?"
Ce que cela signifie pour la façon dont je construis maintenant
La semaine après avoir lancé Symphony, j'ai réécrit la façon dont je structure le travail sur mon projet client principal. Trois changements concrets.
Un : chaque numéro que j'ouvre se termine maintenant par une section "Définition de terminé". Non pas parce que Symphony le récupérera (le projet client n'exécute pas encore Symphony) mais parce que l'écriture de tickets sous cette forme est désormais ma référence. La discipline exigée par un agent de codage est la même discipline dont bénéficie un ingénieur junior.
Deux – J'ai ajouté npm test, npm run lint et npm run typecheck comme étapes obligatoires dans les fichiers de flux de travail de mon agent partout. Aucune exception. Les capteurs informatiques sont gratuits. Utilisez-les.
Trois : j'ai arrêté de faire la distinction entre les « outils AI que j'utilise » et « l'infrastructure AI que j'utilise ». Cette distinction est morte. Codex, Claude Code, Cursor — ce sont des harnais intérieurs. Ils sont assis à l'intérieur de quelque chose. La question est de savoir à quoi ressemble ce quelque chose. Le mien va ressembler de plus en plus à Symphony plus une boucle interne de style Ralph avec des capteurs informatiques. Le vôtre pourrait être différent. Mais ça va être quelque chose.
Si vous souhaitez une lecture plus approfondie de la transition plus large vers l'agent en tant qu'infrastructure, [mon article sur le harnais d'agents de longue durée d'Anthropic] (/anthropic-long-running-agent-harness/) couvre le côté du harnais interne sous un angle Claude, et l'[étude de cas Paperclip sur l'orchestration d'entreprises AI zéro humain] (/paperclip-orchestrating-zero-human-ai-companies/) montre ce qui se passe lorsque vous poussez le modèle de harnais externe jusqu'à sa conclusion logique. Pour le côté pratique de Codex, ma comparaison de Codex Claude Code en remplacement du curseur indique où Codex bat véritablement les autres agents de codage en 2026.
Un mot sur la suite des choses
Trois prédictions, classées de « Je suis confiant » à « Je parierais un café ».
Confiant. D'ici douze mois, toute organisation d'ingénierie sérieuse aura quelque chose en forme de Symphony en production. Cela pourrait être Symphony lui-même, cela pourrait être Gas Town, cela pourrait être Archon, cela pourrait être un emballage local. La forme – suivi des problèmes en tant que file d’attente, espace de travail isolé par tâche, capteurs déterministes dans la boucle, examen humain à la fin – est l’avenir. Le vocabulaire converge déjà. Les mises en œuvre suivront.
Raisonnablement confiant. Le goulot d'étranglement pour la plupart des équipes ne sera pas l'orchestrateur. Ce sera le harnais à l'intérieur de l'agent – les invites, les compétences, les playbooks, les commandes des capteurs. Les équipes qui investissent déjà dans une discipline de type CLAUDE.md adopteront Symphony plus rapidement que les équipes qui ne le font pas, et l'écart se creusera. (Si vous avez ignoré les compétences des agents, il est maintenant temps d'arrêter.)
Pariez un café. D'ici six mois, Linear fournira un support natif de style Symphony et OpenAI ou un tiers publiera un runtime Symphony hébergé qui fait abstraction de la partie devbox. Le modèle actuel « louez votre propre devbox » est trop lourd sur le plan opérationnel pour être la réponse à long terme.
Mais voici le point le plus profond. Symphony n'est pas important car c'est le meilleur orchestrateur. C'est important car cela nous a donné une spécification partagée – un vocabulaire que tout le monde peut implémenter, copier ou voler. C'est le mouvement qui transforme un outil en catégorie.
Revenez au moment que j'ai décrit dans l'ouverture : le ticket Linear de onze minutes expédié sans moi. Ce moment n’est pas impressionnant à cause de ce qu’un agent a fait. C'est impressionnant en raison de ce que une spécification partagée, exécutée comme un harnais externe, autour de n'importe quel harnais interne, autour de n'importe quel modèle rend possible à grande échelle.
Si vous ne lisez qu'une seule chose aujourd'hui, lisez le Symphony SPEC.md d'un bout à l'autre. Cela fait douze pages. Une fois que vous aurez terminé, vous verrez différemment votre flux de travail AI actuel. Et c’est là – ni les 500 %, ni les 15 000 étoiles – le véritable changement qui mérite d’être optimisé.
Maintenant, va t'attribuer un vrai ticket. Celui que vous avez reporté. Écrivez-le comme une spécification. Ajoutez une définition de terminé. Imaginez qu'un agent que vous n'avez jamais rencontré va le lire.
Alors demandez-vous : le travail serait-il terminé ?
Si la réponse est non, le problème n’est jamais l’agent.
Questions fréquemment posées
Qu'est-ce que OpenAI Symphony et comment ça marche ?
Symphony est une spécification open source de OpenAI qui transforme un outil de suivi des problèmes tel que Linear en un plan de contrôle pour les agents de codage autonomes. Il interroge le tracker toutes les 30 secondes, revendique les tickets correspondant à une étiquette de déclencheur, lance un arbre de travail git isolé par ticket, exécute un agent Codex ou Claude Code dans cet espace de travail jusqu'à ce qu'il produise un PR et relie le PR au ticket. L'implémentation de référence est dans Elixir, mais la spécification est indépendante du langage. Voir Configuration de Symphony sur un dépôt réel ci-dessus pour la procédure pas à pas complète.
En quoi Symphony est-il différent de Gas Town, Archon et Ralph loops ?
Symphony suppose un ticket, un agent, un PR — et le suivi des problèmes est la file d'attente. Gas Town gère des colonies coordonnées de 20 à 30 agents parallèles avec des rôles explicites. Archon crée des flux de travail YAML déterministes autour de tout agent de codage avec des portes de phase explicites. Ralph loops est la boucle interne minimale viable – while not done: run agent again with latest state. Ils sont complémentaires : un ticket Symphony peut envelopper une boucle Ralph dans son espace de travail.
La demande d'augmentation de 500 % des relations publiques de OpenAI Symphony tient-elle la route dans la pratique ?
Cette affirmation est réelle pour les tickets à portée restreinte des équipes dotées de processus matures de rédaction et de révision des spécifications : le débit de génération augmente fortement. Mais les « PR atterris » sont une métrique de génération, et la validation n'évolue pas de la même manière. Lors de mes propres tests, j'ai vu 3 à 4 fois sur les tickets bien ciblés et pire que la référence sur les tickets ambigus. La lecture honnête : Symphony déplace le goulot d'étranglement du codage à la rédaction et à la révision des spécifications.
Qu'est-ce que harness engineering et pourquoi est-ce important pour les agents de codage ?
L'ingénierie du harnais est la discipline qui consiste à concevoir tout ce qui autour du modèle le transforme en un agent fiable : guides (pilotage par anticipation : invites, compétences, manuels de jeu) et capteurs (validation par rétroaction : linters, tests, vérificateurs de type, LLM en tant que juge). L'article de Martin Fowler de Birgitta Böckeler est la référence canonique. Le framework distingue le harnais interne (à l'intérieur de l'agent) du harnais externe (autour de l'agent), et Symphony est carrément un harnais externe.
Dois-je connaître Elixir pour utiliser Symphony ?
Non. L’implémentation d’Elixir est une référence et non une exigence. La spécification est l'artefact réel et OpenAI a démontré que Codex peut réimplémenter la spécification dans TypeScript, Go, Rust, Java et Python. Si votre équipe utilise déjà l'un de ces langages, la réimplémentation de l'orchestrateur est un projet de week-end réalisable. Si vous êtes à l'aise avec Elixir ou si vous souhaitez apprendre les bases, la référence est prête à l'emploi.
Travaillons ensemble
Vous cherchez à créer des systèmes AI, à automatiser les flux de travail ou à faire évoluer votre infrastructure technologique ? J'aimerais aider.
- Fiverr (versions et intégrations personnalisées) : fiverr.com/s/EgxYmWD
- Portefeuille : mejba.me
- Ramlit Limited (solutions d'entreprise) : ramlit.com
- ColorPark (conception et image de marque) : colorpark.io
- xCyberSecurity (services de sécurité) : xcybersecurity.io
