Insights

Le harness est le système

Quand un agent de code se trompe, changer de modèle n’est souvent pas la réponse. Le comportement vient surtout du harness autour.

Agent = modèle + harness : règles, outils, bac à sable, hooks, traces, routage

Quand un agent de code se trompe, le réflexe est de changer de modèle. Le papier d’Osmani, Saboo et Kartakis (mai 2026) dit l’inverse. Le modèle est le moteur. Le harness est la chaîne autour : fichiers de règles, outils, bac à sable, routage entre agents, hooks déterministes, observabilité. Sans ça, on n’a pas un agent. On a un modèle qu’on relance.

Le comportement vient du harness

Les auteurs le formulent ainsi : le comportement qu’on croit être « Claude », « Cursor » ou « Codex » est surtout celui du harness. Ils citent deux mesures publiques. Sur Terminal Bench 2.0, une équipe serait passée hors du top 30 au top 5 en ne changeant que le harness. Une autre, chez LangChain, aurait gagné 13,7 points sur le même bench en ne touchant qu’au prompt, aux outils et au middleware, modèle fixe. On n’a pas refait ces mesures. Le point tient même sans elles : la plupart des échecs d’agent, regardés de près, sont des échecs de configuration. Outil manquant, règle vague, garde-fou absent, contexte saturé de bruit.

Présent partout dans le cycle

Dans le cycle, le harness n’est pas une phase. Il est présent partout. Avant le code, on le configure : ce que l’agent a le droit de lire, ce qu’il ne doit jamais faire. Pendant l’implémentation, il borne l’exécution. Au test, il renvoie l’échec au modèle pour qu’il réessaie, dans une limite. À la revue et au déploiement, des hooks bloquent ce qu’un prompt oublie, un secret en dur par exemple, et les traces disent pourquoi l’agent a fait ce geste.

C’est la même thèse que pour un agent métier. L’autonomie impressionne. Ce qui tient en production, c’est le pourtour : permissions, tests, journal. Le développeur qui « vibe code » et celui qui fait de l’ingénierie agentique peuvent ouvrir le même outil le matin. Le second a écrit les contraintes avant de lancer la tâche.

L’usine, pas le fichier

Le modèle mental du papier est l’usine. Le livrable du développeur n’est plus le fichier. C’est le système qui produit le fichier : specs, agents, portes de qualité, boucle de correction, garde-fous. On ne donne plus la marche à suivre ligne à ligne. On donne le critère de succès, et on vérifie la sortie.

Position YOWE

Quand un agent déçoit, on inspecte le harness avant de changer de modèle. Règles, outils, bac à sable, hooks, traces. C’est là que se joue la différence entre une démo et un système.