Le Harnais

OpenAI a discrètement publié Symphony sur GitHub cette semaine. C'est un daemon de longue durée qui surveille votre board Linear pour détecter du travail, crée un espace de travail isolé par ticket, lance un agent Codex, renvoie des preuves de travail — statut CI, revue de PR, vidéo de démonstration — et fusionne la PR une fois acceptée. Les ingénieurs ne supervisent pas chaque exécution d'agent individuellement. Ils gèrent le travail.

Une ligne dans le README :

« Symphony fonctionne mieux dans les codebases ayant adopté le harness engineering. »

Alors vous cliquez sur le lien.

Harness Engineering est une autopsie de cinq mois. Un produit, zéro ligne de code écrite manuellement, environ un million de lignes livrées, trois ingénieurs passés à sept, ~1 500 pull requests. 3,5 PR par ingénieur par jour. Le débit augmentait à mesure que l'équipe grandissait — et c'est le chiffre qui compte. L'effet composé est réel quand l'architecture est juste.

À mi-chemin de l'article, ils renvoient vers le Ralph Wiggum Loop.

Si vous suivez Forgeloop-kit, vous savez que le Ralph loop est l'architecture que nous utilisons depuis janvier 2026 — avant que le post sur le harness engineering n'existe. Le même schéma : routage de tâches piloté par git, exécution par agents, vérification de preuve de travail, boucle. L'équipe d'OpenAI l'a découvert indépendamment, l'a utilisé en interne pendant cinq mois, puis a publié le manuel. Symphony est ce qu'ils ont construit par-dessus.

La preuve que le pattern fonctionne, ce n'est pas un article de blog. C'est le système qui publie celui-ci.

Ce qu'ils ont réellement construit

Ce qu'ils construisaient en réalité — sous le produit, à travers le produit — c'était un environnement capable de construire des produits.

Cinq mois à comprendre ce qui casse quand les humains arrêtent d'écrire du code et commencent à concevoir l'environnement dans lequel les agents écrivent du code. De quoi le dépôt a-t-il besoin pour qu'un agent puisse y naviguer ? De quoi la stack d'observabilité a-t-elle besoin pour qu'un agent puisse déboguer ? De quoi la suite de tests a-t-elle besoin pour qu'un agent puisse vérifier son propre travail ?

Ce sont des questions différentes de « que doit faire cette fonctionnalité ? ». Le basculement s'opère du constructeur vers l'ingénieur de harnais.

La phrase du post qui mérite d'être tatouée quelque part :

« ce qui change quand le travail principal d'une équipe d'ingénierie logicielle n'est plus d'écrire du code, mais de concevoir des environnements, spécifier l'intention et construire des boucles de rétroaction qui permettent aux agents de faire un travail fiable. »

C'est la fiche de poste de ce qui vient après. J'en ai parlé sous l'angle principal/travail — c'est la même chose vue de l'intérieur du codebase.

Le problème AGENTS.md qu'ils ont rencontré en premier

Au début de l'expérience, ils ont tenté l'approche évidente : un gros fichier AGENTS.md avec tout ce que l'agent doit savoir. Ça a échoué de manière prévisible.

Encombrement de contexte. Un fichier d'instructions géant ne laisse plus de place pour la tâche, le code, la documentation pertinente. Les agents font du pattern-matching local au lieu de naviguer intentionnellement. Les règles pourrissent instantanément — les humains arrêtent de maintenir un manuel monolithique, les agents ne peuvent pas distinguer ce qui est encore vrai. Aucune vérification mécanique.

Leur solution : AGENTS.md comme table des matières, ~100 lignes, avec des pointeurs vers un répertoire docs/ structuré. La connaissance vit dans le dépôt ; le fichier ne fait que la cartographier.

SkDD a résolu ce problème sous un angle différent. Les skills sont modulaires par conception — des fichiers SKILL.md discrets, chacun faisant une chose, chacun maintenable indépendamment. L'équivalent de leur structure docs/, mais en forme de skill plutôt que de documentation. Même principe : la connaissance du dépôt doit être navigable, pas monolithique.

Si votre AGENTS.md dépasse 200 lignes, c'est déjà un passif.

Quel est réellement le goulot d'étranglement

Le débit de code n'est pas le goulot d'étranglement. Ça fait un moment que ce n'est plus le cas.

L'équipe d'OpenAI l'a compris vite. Une fois que Codex livrait des PR de manière fiable, la contrainte est devenue la capacité humaine de QA. Leur réponse a été de rendre tout ce dont l'agent a besoin pour la vérification directement lisible par l'agent — des instances applicatives par worktree, le Chrome DevTools Protocol câblé dans le runtime de l'agent, des stacks d'observabilité éphémères (logs, métriques, traces) par worktree.

Des prompts comme « assurer que le démarrage du service s'effectue en moins de 800 ms » deviennent traitables quand l'agent peut effectivement interroger les métriques de démarrage. Des prompts comme « aucun span dans ces quatre parcours utilisateur critiques ne dépasse deux secondes » deviennent traitables quand l'agent a accès à PromQL.

C'est le principe depth-first que le post décrit : quand quelque chose échoue, la solution n'est jamais « essayer plus fort ». La question est toujours « quelle capacité manque, et comment la rendre lisible pour l'agent ? ». Vous construisez la capacité, vous la rendez accessible, et l'agent l'utilise.

La boucle ne cale pas sur les tâches difficiles. Elle cale sur les tâches où l'environnement n'a pas été instrumenté pour ce type de travail.

Ce qui est identique et ce qui diffère

L'architecture de Forgeloop correspond presque exactement. git sync → routage de tâches → plan → construction → vérification → push. Le Ralph loop est la même boucle qu'ils décrivent — les agents opèrent sur des tâches discrètes, commitent des preuves de travail, bouclent. La différence est la surface : OpenAI avait trois ingénieurs à temps plein et cinq mois. Forgeloop est portable, conçu pour s'installer dans n'importe quel dépôt et fonctionner dès le premier jour.

Une différence concrète qui mérite d'être nommée : Symphony est construit autour de Linear comme file d'attente de travail. Forgeloop utilise GitHub Projects ou des fichiers markdown locaux — IMPLEMENTATION_PLAN.md, REQUESTS.md. Aucune dépendance à Linear, aucun SaaS externe requis. Pour les équipes qui vivent déjà dans GitHub, c'est le bon choix par défaut. Les primitives sont différentes ; le pattern est identique.

Les patterns qui se sont transférés naturellement : la connaissance modulaire pilotée par skills, l'exécution pilotée par tâches (pas par conversation), la revue agent-to-agent, le temps humain comme ressource véritablement rare.

Les patterns sur lesquels ils sont allés plus loin : l'isolation par worktree pour les exécutions d'agents en parallèle, la lisibilité UI via DevTools Protocol, l'observabilité éphémère. Ceux-là ne sont pas encore dans Forgeloop-kit. Ils sont dans la roadmap — et maintenant il y a une spécification publique contre laquelle construire.

Le pattern dont je n'ai vu personne parler assez clairement : quand le goulot d'étranglement se déplace vers la vérification, le harnais devient le produit. Pas le code. L'environnement qui rend le code vérifiable.

Symphony : un niveau au-dessus

Symphony est ce que le harness engineering rend possible.

Une fois que le dépôt est conçu pour que les agents puissent y naviguer — documentation structurée, vérification automatisée, observabilité lisible — Symphony est le daemon qui supprime la dernière étape manuelle : un développeur ouvrant son ordinateur portable et lançant une exécution. Il surveille Linear, crée un espace de travail par ticket, lance Codex et fusionne les PR. La boucle ne vous attend pas. Elle tourne pendant que vous dormez.

La politique vit dans WORKFLOW.md, versionnée avec le code, chargée à chaque exécution. Même principe que AGENTS.md-comme-carte : le dépôt possède ses propres instructions opérationnelles, et ces instructions évoluent avec le codebase.

Un détail que le README enterre : il indique que vous pouvez demander à votre agent de coder d'implémenter Symphony à partir de la spécification. L'outil conçu pour exécuter des agents est lui-même conçu pour être construit par un agent. Ce n'est pas une récursion mignonne — c'est la méthodologie qui se valide elle-même. Si votre dépôt est harnais-engineered, construire Symphony devient une tâche d'agent traitable.

Symphony est marqué « low-key engineering preview for trusted environments ». Pas encore prêt pour la production dans toutes les équipes. Mais la spécification est publique et l'implémentation de référence existe. La cible est visible.

La stack que personne n'a encore nommée

SkDD, le harness engineering et Symphony ne sont pas des méthodologies concurrentes. Ce sont des prérequis séquentiels.

SkDD est la couche de connaissance. Les agents forgent des skills en construisant. Le dépôt accumule des capacités réutilisables. Chaque session laisse quelque chose derrière — appelable, découvrable, composable.

Le harness engineering est la couche d'environnement. Le dépôt est conçu pour que les agents puissent y naviguer. AGENTS.md est une carte. L'observabilité est interrogeable par les agents. La vérification est automatisée. L'environnement rend le travail traitable.

Symphony est la couche d'orchestration. Un daemon lit la file d'attente de travail, dispatche des agents par ticket, collecte les preuves de travail, fusionne les PR. Les humains gèrent le travail, pas les agents.

Vous ne pouvez pas faire tourner Symphony sur un dépôt non harnaisé — cela ne fait que produire du chaos plus rapidement. Vous ne pouvez pas construire un bon harnais sans les primitives de connaissance pour le remplir. L'ordre compte. Commencez par la couche de connaissance, construisez l'environnement, et l'orchestration devient possible.

Forgeloop-kit couvre la couche intermédiaire — un harnais portable que les équipes peuvent installer dès le premier jour, sans une équipe de trois ingénieurs, sans cinq mois de runway, sans abonnement Linear. Il fonctionnait avant qu'OpenAI ne publie le manuel. Symphony est le barreau suivant. La distance entre l'état actuel de la plupart des dépôts et celui qu'ils doivent atteindre, c'est le travail.

Ce qu'il faut retenir si vous construisez

Le post contient des leads enterrés. Ce qui compose réellement :

Commencez par le harnais, pas par les tâches. Avant de donner une liste de tâches à votre agent, demandez-vous de quoi le dépôt a besoin pour qu'un agent puisse y naviguer. Qu'y a-t-il dans AGENTS.md ? Quels documents existent ? Que peut exécuter l'agent pour vérifier son travail ? La qualité du harnais est le plafond du débit des agents.

Faites d'AGENTS.md une carte, pas un manuel. ~100 lignes. Des pointeurs. Laissez la structure du dépôt porter le reste. Si vous êtes tenté de tout écrire dans un seul fichier, écrivez un skill à la place.

Instrumentez pour l'accès agent, pas pour la lisibilité humaine. Logs, métriques, état de l'UI — si un agent peut l'interroger, l'agent peut le vérifier. Construisez-le une fois, utilisez-le sur chaque tâche. C'est le multiplicateur.

Le goulot d'étranglement n'est jamais la génération. Votre agent n'est pas trop lent. Votre environnement n'est pas assez lisible. Déboguez le harnais avant de déboguer le modèle.

La décomposition depth-first des tâches est la seule qui compose. Quand une tâche échoue, trouvez la capacité manquante. Construisez-la. Rendez-la lisible. Maintenant, toute la classe de tâches est débloquée. Le width-first donne de la couverture. Le depth-first donne de la composition.

OpenAI a mené une expérience de cinq mois pour confirmer ce que le Ralph loop fait en production. Puis ils ont livré Symphony comme barreau suivant. La question maintenant est de savoir si votre dépôt est prêt pour ça.

La stack, c'est : SkDD → harnais → Symphony. L'ordre compte.

Forgeloop-kit : forgeloop.zakelfassi.com
SkDD : github.com/zakelfassi/skills-driven-development
Symphony : github.com/openai/symphony