Harness engineering et loop engineering : ce qui les distingue

Qu’est-ce qu’un harness ?

Seul, un modèle de langage reçoit une entrée et produit du texte. Il ne peut ni exécuter de code, ni garder la mémoire d’une conversation à l’autre, ni accéder à ce qui est apparu après son entraînement. Pour qu’il en soit capable, on construit autour de lui un dispositif : une boucle qui l’appelle encore et encore, des outils qu’il peut appeler, des fichiers qu’on lui fournit à chaque session et des vérifications qui testent sa sortie. Ce dispositif s’appelle un harness.

Parmi les sources que nous avons lues, la définition la plus large se trouve dans l’article de LangChain : « A harness is every piece of code, configuration, and execution logic that isn’t the model itself. » Autrement dit, tout code, toute configuration, toute logique d’exécution qui n’est pas le modèle lui-même. Une couche de ce type tourne aussi au cœur des agents de codage : OpenAI appelle « Codex harness » la couche qui fournit la boucle de l’agent et la logique d’exécution ; Anthropic appelle « agent harness » celle qui fait tourner Claude Code.

Le harness engineering consiste à concevoir ce dispositif. Nous en construisons un nous aussi : diffox est un outil de revue de code par IA qui examine les pull requests. Les exemples plus bas viennent de son pipeline de review et de la boucle qu’il entretient tout au long d’une pull request (son fonctionnement fait l’objet d’un article à part).

Comment les sources définissent le harness engineering

Le terme est récent, et les sources que nous avons lues ne le définissent pas de la même façon. Le tableau reprend chaque source avec ses propres mots, et sa date.

Source : la page de chaque article, 15 octobre 2026. Citations en langue originale.

Hashimoto décrit une habitude, et écrit dans le même paragraphe qu’il ne sait pas s’il existe déjà un terme établi pour cela. LangChain, lui, trace une frontière : tout ce qui est hors du modèle est le harness. Le premier vous dit quoi faire, le second où regarder.

Deux détails n’apparaissent pas dans le tableau. La formule « Agent = Model + Harness » figure dans l’article de LangChain, pas dans celui de Hashimoto. Et le mot « harness » est plus ancien que le terme : le 26 novembre 2025, Anthropic qualifiait déjà le Claude Agent SDK de « general-purpose agent harness ». L’expression « harness engineering » n’apparaît dans aucun des cinq articles d’Anthropic que nous avons lus.

Ce que vous changez à chaque couche

Les quatre termes ne sont pas interchangeables : ce sont quatre couches emboîtées. Selon la définition d’Anthropic, le prompt engineering désigne les méthodes pour écrire et organiser les instructions d’un modèle. Le context engineering, lui, regroupe les stratégies pour choisir et maintenir les tokens que le modèle a devant lui pendant l’inférence. Cela inclut toute information qui y arrive en dehors du prompt. Le contexte, c’est tout ce que le modèle voit lors de cet appel.

Nous n’avons trouvé aucune source primaire qui attribue le context engineering à une seule personne. Les deux emplois que nous avons lus datent de juin 2025 : le 19 juin, Tobi Lütke a écrit qu’il préférait ce nom à « prompt engineering » (« the art of providing all the context for the task to be plausibly solvable by the LLM »), et Andrej Karpathy l’a rejoint le 25 juin. La définition d’Anthropic date du 29 septembre 2025.

Le harness engineering se situe une couche plus à l’extérieur. Il ne s’arrête pas à ce que voit le modèle ; il conçoit aussi ce qui se passe après sa réponse : par quelle vérification passe la sortie, comment le travail est découpé, ce qui change quand une erreur se répète. Les couches s’emboîtent : selon LangChain, les harness d’aujourd’hui servent surtout à mettre en œuvre un bon context engineering. Le loop engineering se situe encore un cran plus à l’extérieur : il conçoit non pas une exécution, mais les exécutions dans la durée. Nous lui consacrons une section à part, plus bas.

De quoi se compose un harness

Les articles que nous avons lus donnent aux composants des noms différents. Chacune des six familles ci-dessous apparaît dans au moins deux sources.

La boucle est au cœur du dispositif. Anthropic décrit les agents comme des modèles qui utilisent des outils dans une boucle, guidés par la rétroaction de leur environnement. Dans l’article sur l’Agent SDK, les étapes de la boucle sont : rassembler le contexte, agir, vérifier le travail, recommencer. Les outils et l’observabilité montrent au modèle le résultat de son travail : dans le dépôt que décrit OpenAI, l’agent a accès aux logs, aux métriques et aux traces. Les sous-agents se partagent le travail ; selon Anthropic, chacun reçoit une tâche ciblée et part d’une fenêtre de contexte vierge.

Les vérifications sont à part, parce que c’est vous qui les écrivez, pas le modèle. Selon l’article sur l’Agent SDK, la meilleure rétroaction, ce sont des règles clairement définies pour la sortie, avec l’explication de la règle enfreinte et de la raison. OpenAI fait respecter ses règles d’architecture de façon automatique, avec des linters sur mesure et des tests structurels.

Qu’est-ce que le loop engineering ?

Le harness s’occupe d’une seule exécution. Le loop engineering pose une question de plus : qui lance l’agent, quand, et qui décide si le travail est fini ? C’est Addy Osmani qui lui a donné son nom, dans un article du 7 juin 2026 : « Loop engineering is replacing yourself as the person who prompts the agent. You design the system that does it instead. » Autrement dit : cesser d’être celui qui écrit à l’agent tour après tour, et concevoir le système qui le fait à votre place.

Deux phrases ont fait naître le terme. Le même jour, Peter Steinberger conseillait de concevoir des boucles qui écrivent les prompts des agents, plutôt que de les écrire soi-même. Et selon Osmani, Boris Cherny, à la tête de Claude Code, avait dit : « My job is to write loops ». Aucun des deux n’emploie l’expression « loop engineering » ; le nom vient de l’article d’Osmani.

Source : la page de chaque article, 15 octobre 2026. Citations en langue originale.

Les sources s’accordent sur six composants. La synthèse les énumère ainsi : des exécutions déclenchées, des conditions d’arrêt vérifiables par une machine, des fichiers d’état persistants, des sous-agents vérificateurs, des budgets de tokens et des points de passage à un humain.

• Déclencheur. Ce qui lance l’exécution : un minuteur ou un événement.
• Condition d’arrêt. Un critère qui permet à une machine de décider que le travail est fini : les tests passent, la liste est vide.
• État. Ce qui reste d’une exécution à la suivante ; il vit hors de la fenêtre de contexte.
• Vérificateur. Un contrôleur distinct de l’agent qui fait le travail.
• Budget. Une limite de tours ou de tokens ; une fois dépassée, la boucle s’arrête.
• Passage à un humain. L’endroit où le travail que la boucle ne résout pas revient à une personne.

L’article d’Anthropic montre trois de ces composants ensemble. Chaque fois que Claude Code veut s’arrêter, un modèle évaluateur distinct vérifie la condition. Il le remet au travail jusqu’à ce que l’objectif soit atteint, ou jusqu’au nombre de tours que vous avez fixé. Comme le dit Osmani, l’agent qui a écrit le code n’est ainsi pas celui qui note son propre travail.

Sur un point, les sources divergent : quelle boucle le mot « loop » désigne-t-il ? La synthèse en distingue deux. Dans la boucle de l’agent, le modèle appelle des outils au sein d’une seule exécution et agit selon leur résultat ; cette boucle fait partie du harness. Le loop engineering, lui, s’occupe des structures qui lancent ces exécutions, les vérifient et les relancent dans le temps. Certains articles d’éditeurs emploient le mot au premier sens ; le blog d’ingénierie d’Anthropic définit lui aussi le harness comme « la boucle qui appelle Claude ». Dans cet article, « loop » est pris au second sens.

Le terme lui-même n’est pas encore stabilisé. La même synthèse note que le débat n’a pas tranché : le loop engineering est-il une nouvelle discipline, une technique de transition ou une étiquette marketing ? En juillet 2026, un successeur a même été proposé sous le nom de « graph engineering ».

À quoi ressemble un harness dans un outil de revue de code

Le pipeline de review de diffox montre comment ces composants tiennent ensemble. Une pull request passe par quatre étapes avant de devenir des commentaires ; à chacune, une idée du harness apparaît.

Contexte et orientation : c’est ce que le harness donne au modèle avant qu’il se mette au travail. Les agents spécialisés reçoivent quatre choses : le diff, les fichiers avant et après, la description de la pull request et, s’il y en a un, le fichier de règles de votre dépôt (AGENTS.md ou CLAUDE.md). Le fichier de règles est lu depuis la branche dans laquelle la pull request sera fusionnée, pas depuis sa propre branche ; ainsi, une pull request ne peut pas changer les règles de sa propre review. Cette garantie ne tient pas à une phrase de consigne, mais à l’endroit d’où le fichier est lu.

L’analyse spécialisée, c’est le partage du travail. « Y a-t-il un bug ici ? » est une question large. diffox fait donc lire le même changement par des agents spécialisés. L’équipe en compte 17 ; chacun a sa propre consigne et cherche une seule chose : l’un les erreurs de logique, un autre les problèmes de concurrence, un autre le test qui ne vérifie rien.

Le harness fixe aussi la forme de la sortie. Pour être retenu, un constat doit dire trois choses : ce qu’il affirme, ce qui tourne mal et dans quelle situation, et le code sur lequel il s’appuie, cité mot pour mot. Les agents ne donnent pas de numéro de ligne ; diffox trouve la ligne lui-même en cherchant la citation dans le fichier.

Choisir et publier est une étape à part. Chaque constat a une classe : Critique, Avertissement ou Suggestion. La pull request reçoit ce que vous devez corriger, c’est-à-dire les constats critiques et les avertissements. Les suggestions attendent un moment sur la page Constats de la console, et vous pouvez y publier celles que vous voulez. Une review ne bloque jamais un merge.

Une vérification que le modèle ne peut pas convaincre

La troisième étape, la vérification des preuves, est celle où l’idée du harness se voit le plus clairement dans cet exemple. Un modèle de langage peut écrire quelque chose de convaincant et de faux : il cite une ligne qui n’est pas dans le fichier, conteste du code que la pull request n’a pas touché, répète le même problème trois fois en trois phrases différentes. Cette étape rattache chaque constat au fichier lui-même, et non à la parole du modèle.

Ces vérifications sont du simple code, pas un appel à un modèle : la même entrée reçoit chaque fois la même réponse.

• La citation du constat est cherchée dans le fichier. Une citation introuvable n’a aucune ligne à désigner ; si la ligne trouvée n’est pas dans ce que la pull request a changé, le constat est hors périmètre.
• Les constats qui font la même objection au même endroit sont fusionnés en un seul.
• Quand un constat dit que le code contredit un texte, sa seconde citation est elle aussi cherchée mot pour mot.

Le modèle ne peut pas convaincre la vérification de la citation : elle n’évalue aucun argument, elle cherche la citation dans le fichier.

On peut aussi faire contrôler un modèle par un autre modèle, mais le résultat reste le jugement d’un modèle. Anthropic raconte que, lors des premiers essais, son modèle évaluateur trouvait de vrais problèmes, puis se persuadait qu’ils n’avaient pas d’importance et approuvait le travail. Tester par du code ce qui peut l’être est donc un composant à part ; la question qui demande du jugement reste au modèle.

Dans un petit projet, la même idée tient en quelques lignes. L’exemple ci-dessous n’est pas le code de diffox ; il montre le principe.

# EXEMPLE : cherche dans le fichier la citation donnée par le modèle
def quote_exists(finding: dict, files: dict[str, str]) -> bool:
    quote = finding.get("quote", "").strip()
    source = files.get(finding.get("file", ""), "")
    return bool(quote) and quote in source

La boucle qui tourne tout au long d’une pull request

Une review passe par un harness ; une pull request, elle, passe par de nombreuses reviews. Le code est écrit, diffox l’examine, le code change, un nouveau push arrive. Que le code soit écrit par un humain ou par un agent de codage, c’est une boucle, et chacun de ses six composants a son équivalent dans le code de diffox.

La vraie leçon de cette boucle tient en deux choix. Le premier : le vérificateur ne prend pas un changement pour un succès. Quand les lignes d’un constat changent, le commentaire indique seulement, à la fin, le commit qui les a modifiées. Il n’écrit jamais « corrigé », car du code réécrit peut encore contenir le bug. Un article de recherche de juin 2026 pose la même exigence pour la règle d’arrêt : ne jamais prendre une erreur pour un succès.

Le second : c’est vous qui choisissez la condition d’arrêt. Les reviews automatiques s’arrêtent à une limite par pull request, que vous modifiez dans l’onglet Paramètres de la console. Au-delà, vous demandez une nouvelle review en mentionnant diffox dans un commentaire. La décision de merge vous appartient aussi : une review ne bloque jamais un merge. C’est là que la boucle passe la main à un humain.

Comment un harness grandit avec les erreurs

Un harness ne se construit pas une fois pour toutes. Chez Hashimoto, il y a deux voies : une ligne dans le fichier de règles pour les erreurs simples, un outil écrit en code pour le reste. Il écrit que chaque ligne du fichier de règles de son projet vient d’un mauvais comportement d’un agent.

L’article d’OpenAI décrit la même boucle dans une équipe : Codex écrit tout le code du produit, les ingénieurs construisent l’environnement. Quand l’agent peine, ils y voient un signal ; l’outil, le garde-fou ou la documentation qui manque est identifié et ajouté au dépôt. Quand la documentation ne suffit pas, la règle passe dans le code. Le fichier de règles reste court : un AGENTS.md d’environ 100 lignes, une table des matières et non une encyclopédie.

Il y a aussi le sens inverse. Selon Anthropic, chaque composant d’un harness est une hypothèse sur ce que le modèle ne sait pas faire seul, et ces hypothèses peuvent vieillir à mesure que les modèles progressent. Quand un nouveau modèle arrive, on réexamine le harness et on retire les composants qui ne sont plus porteurs.

En développant cet outil, nous avons tiré de cette boucle trois habitudes, dans notre propre dépôt :

• Chaque règle est écrite avec l’erreur qui l’a fait naître. Une règle sans sa raison est effacée par le premier qu’elle dérange.
• On ne fait confiance à un test qu’après l’avoir vu passer au rouge quand on annule la correction. Un test qui ne vérifie rien est vert lui aussi.
• Quand une vérification écrite en code change, l’ancienne et la nouvelle version sont rejouées sur les résultats déjà enregistrés. Pas besoin d’une nouvelle exécution payante ; chaque cas où les deux versions divergent se voit un par un.

Par où commencer dans votre projet

Pour commencer, vous n’avez pas besoin de choisir un framework ni de changer de modèle. Un harness tourne déjà dans l’agent de codage que vous utilisez ; vous y ajoutez les composants propres à votre projet.

Repérez d’abord l’erreur, puis choisissez le remède le moins cher. Pour une erreur simple, le premier remède est une ligne dans le fichier de règles. Si l’erreur se répète malgré la règle, faites passer la règle dans le code : une règle de linter, un test, un script. Le conseil général d’Anthropic vaut ici aussi : trouvez la solution la plus simple, et n’ajoutez de la complexité que lorsque c’est nécessaire.

Pour votre première boucle, l’ordre est le même : vérifiez d’abord qu’une seule exécution est fiable, puis écrivez la condition d’arrêt et la limite. Le conseil d’Anthropic est clair : arrêtez-vous quand l’objectif est atteint ou au nombre maximal de tours ; pour maîtriser la consommation de tokens, les limites de la boucle doivent être nettes.