Harness engineering : ce que font vraiment Anthropic et OpenAI avec leurs agents
Un agent qui déraille au bout de vingt minutes sur une tâche complexe, ce n’est pas un problème de modèle. C’est un problème d’infrastructure. Le harness, c’est cette infrastructure — tout ce qui entoure l’appel LLM pour le rendre efficace sur des tâches longues : feedback loops, gestion du contexte, artefacts de handoff, agents spécialisés, environnement rendu lisible par l’agent.
En l’espace de quelques semaines, Anthropic et OpenAI ont tous les deux publié leurs retours d’expérience sur le sujet. Deux équipes, deux problèmes différents, des conclusions qui se recoupent sur l’essentiel.
Ce que les deux articles documentent
L’article d’Anthropic part de deux failure modes récurrents sur les tâches longues : la context anxiety (le modèle bâcle son travail en approchant sa fenêtre de contexte) et le self-evaluation bias (un agent qui évalue son propre travail répondra toujours positivement, même sur du médiocre). La réponse : une architecture tri-agents — planner, generator, evaluator — où l’evaluator est délibérément séparé du generator et calibré pour être sceptique, avec un MCP Playwright qui lui permet de tester l’application en cours d’exécution comme un vrai utilisateur. Le résultat sur un jeu rétro 2D : 6h de run, $200, une application fonctionnelle. Contre 20 min, $9, et un mode jeu cassé sans la moindre indication visible.
L’article d’OpenAI documente une expérience plus radicale : livrer un million de lignes de code avec trois ingénieurs, zéro ligne écrite manuellement, en quelques mois. Leur insight central est différent mais complémentaire — l’agent ne peut travailler que sur ce qu’il peut lire. Tout ce qui vit dans un Slack, dans un Google Doc ou dans la tête d’un ingénieur est invisible. La réponse : un repo organisé comme système de référence, un AGENTS.md court (~100 lignes) qui sert de table des matières vers des sources détaillées, des contraintes architecturales appliquées mécaniquement par des linters plutôt que documentairement.
Ce qui est intéressant dans cette convergence
Les deux équipes arrivent à la même conclusion par des chemins opposés : le modèle seul ne suffit pas, mais la valeur ajoutée de l’ingénieur ne consiste plus à écrire du code — elle consiste à concevoir l’environnement dans lequel l’agent travaille. Anthropic l’exprime ainsi : chaque composant du harness encode une hypothèse sur ce que le modèle ne sait pas faire seul. Quand le modèle s’améliore, cette hypothèse peut devenir fausse — et le composant devient du overhead à supprimer.
Les deux articles valent la lecture complète pour les détails d’implémentation. Les prochains articles ici iront plus loin sur les patterns concrets : comment concevoir une boucle generator-evaluator, comment structurer un repo pour la lisibilité agent, et comment décider quand un harness est réellement nécessaire.