SFEIR
Harness Engineering Concept

Harness Engineering

Discipline de conception du système (guides, sensors, outils) entourant un agent IA pour fiabiliser et amplifier ses résultats.

Définition : placer le système avant le modèle

Le harness engineering est une discipline émergente qui place la conception du système entourant un agent IA — et non le modèle lui-même — au centre de la performance. Le terme a été forgé par Mitchell Hashimoto (cofondateur de HashiCorp) en février 2026, puis amplifié par OpenAI et codifié par Birgitta Böckeler sur martinfowler.com. Le principe fondateur : chaque erreur d'un agent doit déclencher une amélioration du harnais pour que cette erreur ne se reproduise plus jamais.

Framework : guides et sensors, deux contrôles complémentaires

Le framework de Böckeler distingue deux types de contrôles complémentaires. Les guides (contrôles feedforward) anticipent le comportement de l'agent avant qu'il agisse : fichiers AGENTS.md, conventions de code, scripts de bootstrap, templates de topologie. Les sensors (contrôles feedback) observent après l'action et aident l'agent à s'auto-corriger : suites de tests, linters, vérificateurs de types, revues de code automatisées. La combinaison des deux forme un cybernetic governor qui régule la base de code vers son état souhaité.

Preuve empirique : Terminal-Bench 2.0 de Stanford

La preuve empirique la plus frappante vient de Terminal-Bench 2.0 (Stanford/Laude Institute, mars 2026) : le harness ForgeCode atteint 81,8 % avec Claude Opus 4.6, tandis que Claude Code obtient 58 % avec le même modèle — un écart de 23,8 points attribuable exclusivement au harnais. ForgeCode atteint d'ailleurs des scores identiques avec GPT-5.4 et Claude Opus 4.6, démontrant que le harness neutralise les différences entre modèles.

Harnessability : traçabilité et topologies claires

Le concept de harnessability (Böckeler) mesure la capacité d'une base de code à être harnachée efficacement. Les langages fortement typés, les frontières de modules claires et les frameworks structurés créent des ambient affordances qui rendent le code tractable pour les agents. La loi d'Ashby (variété requise) s'applique : les équipes doivent réduire la variété de ce que l'agent peut produire en définissant des topologies claires et des harness templates pour les patterns récurrents.

Superset du context engineering, résultats en production

Le harness engineering est un superset du context engineering. Böckeler le positionne explicitement : le context engineering fournit les moyens de rendre les guides et sensors disponibles à l'agent, tandis que le harness engineering englobe le cycle complet de conception, maintenance et amélioration continue du système de contrôle. En production, Stripe fusionne plus de 1 300 PRs générées par IA par semaine grâce à son système Blueprints, et OpenAI a construit 1 million de lignes de code avec 3 ingénieurs en 5 mois — des résultats impossibles sans un harnais industriel.

Questions fréquentes

Quelle est la différence entre harness engineering et context engineering ?

Le context engineering fournit les moyens de structurer l'information pour les agents IA. Le harness engineering est un superset qui englobe le cycle complet : guides (feedforward), sensors (feedback), templates de topologie, et amélioration continue du système de contrôle. C'est le passage de la structuration du contexte à la conception d'un système cybernétique complet.

Qu'est-ce qu'un guide et un sensor dans le harness engineering ?

Un guide (contrôle feedforward) oriente l'agent avant qu'il agisse — fichiers AGENTS.md, conventions, scripts de bootstrap. Un sensor (contrôle feedback) observe après l'action et aide l'agent à s'auto-corriger — tests, linters, vérificateurs de types. Les deux sont nécessaires : sans guides l'agent répète ses erreurs, sans sensors il encode des règles sans savoir si elles fonctionnent.

Qu'est-ce que la harnessability d'une base de code ?

La harnessability mesure la capacité d'une base de code à être contrôlée efficacement par un harness. Les bases fortement typées, avec des frontières de modules claires et des frameworks structurés, ont une harnessability élevée. C'est un argument fort pour les stacks AI-Ready : TypeScript, typage strict, conventions explicites.

Le harness engineering rend-il les modèles IA interchangeables ?

Partiellement. Terminal-Bench 2.0 montre que ForgeCode atteint 81,8% avec GPT-5.4 comme avec Claude Opus 4.6. Un bon harness réduit considérablement l'écart entre modèles, mais le choix du modèle reste pertinent pour les cas limites et les tâches à forte exigence de raisonnement.

Articles liés

Harness Engineering : le modèle compte moins que le harnais

Harness Engineering : le modèle compte moins que le harnais

Même modèle, 58% vs 81,8% de réussite. La variable décisive n'est pas l'IA — c'est le système qui l'entoure. Bienvenue dans l'ère du harness engineering.

L'ontologie n'est pas louable : le vrai fossé concurrentiel des agents IA

L'ontologie n'est pas louable : le vrai fossé concurrentiel des agents IA

Tony Seale vient de nommer l'évidence : la moitié qui manque aux agents IA n'est pas un framework supplémentaire, c'est l'ontologie de votre domaine. Pour la première fois, le fossé concurrentiel est clairement délimité — et il n'est pas technique.

Que devient DBT quand l'IA écrit le code ?

Que devient DBT quand l'IA écrit le code ?

Benoît Perigot (DBT Labs) raconte quatre ans d'investissement sur l'IA chez DBT Labs — trois leviers techniques (skills, MCP server, DBT Index), l'épineux problème du token design, les trous du benchmark Analytics Engineering, et l'angle mort que les agents ne savent toujours pas franchir.

Claude Code : l'agent de développement qui change la donne

Claude Code : l'agent de développement qui change la donne

De l'assistant au agent : une rupture qui redéfinit le développement logiciel Pendant des années, l'IA dans le développement logiciel a joué un rôle bien délimité : celui du copilote. Un outil intelligent, certes, capable de compléter une ligne de code, de suggérer une fonction...

Écrire du code est un anti-pattern : la provocation qui change tout

Écrire du code est un anti-pattern : la provocation qui change tout

La provocation qui remet tout en question « Écrire du code est désormais un anti-pattern. On ne doit plus produire de code manuellement. » Cette phrase, prononcée par Didier Girard, a de quoi faire bondir n'importe quel développeur. Elle semble absurde, voire pro...

Context Engineering : le guide complet pour 2026

Context Engineering : le guide complet pour 2026

Le Context Engineering est la discipline qui structure le contexte alimentant les agents IA. Architecture 3-Tier, CDLC, et Compound Engineering : tout comprendre.