Débat sur les harnesses d’OpenAI et Anthropic : des modèles plus puissants, des paris d’ingénierie opposés

Les ingénieurs d’OpenAI ont relancé un différend majeur avec Anthropic : des modèles d’IA plus puissants devraient nécessiter des harnesses plus légers, alors que les tâches exigeantes continuent de bénéficier d’une supervision renforcée.

Ce débat sur les harnesses d’OpenAI et Anthropic ne porte pas seulement sur les prompts ou les préférences d’interface. Il concerne les logiciels qui entourent un modèle, notamment les outils, la mémoire, les autorisations, la planification, l’évaluation et l’approbation humaine.

OpenAI affirme qu’un échafaudage excessif peut intégrer des limites que le prochain modèle n’aura plus. Les expériences récentes d’Anthropic aboutissent à une conclusion plus nuancée. De meilleurs modèles ont éliminé une partie de l’orchestration, mais les planificateurs et évaluateurs indépendants sont restés utiles lorsque les tâches approchaient des limites du modèle.

Le désaccord dépasse Codex et Claude Code. Les entreprises transforment des modèles généralistes en agents capables de modifier des dépôts, d’utiliser des navigateurs, d’analyser des documents et de coordonner des projets de longue durée. Chaque contrôle supplémentaire peut améliorer la fiabilité, mais il ajoute aussi de la latence, de la complexité et une hypothèse de plus susceptible de devenir obsolète.

La question centrale n’est donc pas de savoir si les harnesses comptent. Les travaux d’ingénierie des deux entreprises montrent qu’ils comptent. La question est de savoir si les progrès déplacent la valeur vers le modèle, vers le harness, ou de manière répétée entre ces deux couches.

Ce qu’OpenAI et Anthropic ont réellement changé

Les deux entreprises considèrent désormais le harness d’agent comme une couche déterminante du produit, mais elles divergent sur la quantité d’intelligence que cette couche doit contenir.

Un harness d’agent est l’environnement d’exécution qui relie un modèle à des outils, du contexte, de la mémoire, des boucles de rétroaction et des contrôles utilisateur. Le modèle génère les décisions. Le harness détermine les informations qu’il voit, les actions qu’il peut entreprendre et la manière dont les erreurs sont détectées.

La position d’OpenAI est apparue clairement dans des reportages d’août consacrés à ses efforts pour étendre les agents au-delà du développement logiciel. Ses ingénieurs y décrivaient une bonne ingénierie de harness comme le fait de donner à un modèle les outils et informations précis dont il a besoin, sans l’entourer de règles inutiles.

L’ingénieur Nick Gershenson a déclaré à TechCrunch que des ensembles élaborés de logique conditionnelle et d’outils peuvent produire des gains à court terme. Il a toutefois soutenu qu’un nouveau modèle peut rendre ces ajouts obsolètes en quelques mois. Sa direction privilégiée est une interface sobre qui permet à un modèle compétent de résoudre lui-même une plus grande part du problème.

Ce principe fait écho à la bitter lesson, l’argument influent de Rich Sutton selon lequel le calcul généralisé surpasse les systèmes construits autour d’un vaste savoir humain. Appliquée aux agents, cette leçon privilégie des modèles largement capables plutôt que des flux de travail conçus manuellement pour chaque défaillance anticipée.

OpenAI n’a pas abandonné l’ingénierie de harness. Son propre compte rendu sur l’ingénierie de Codex décrit les dépôts, la documentation, les tests, les boucles de rétroaction et les plans lisibles par machine comme une infrastructure essentielle. L’entreprise a fait état d’une moyenne de 3,5 pull requests par ingénieur et par jour sur un projet interne.

La différence tient à l’endroit où OpenAI souhaite concentrer la complexité. Ses ingénieurs privilégient des environnements lisibles et des retours clairs plutôt que des ramifications toujours plus élaborées dictant la manière dont le modèle doit raisonner.

Les recherches d’Anthropic du 24 mars ont présenté un test de résistance différent. Le chercheur Prithvi Rajasekaran a utilisé un planificateur, un générateur et un évaluateur pour construire des applications complètes au fil de longues sessions autonomes.

Le planificateur transformait une demande courte en spécification structurée. Le générateur mettait ce plan en œuvre. L’évaluateur utilisait l’application, vérifiait les critères convenus et renvoyait les défauts à corriger.

La comparaison initiale d’Anthropic a révélé qu’une exécution avec un seul agent produisait une application dont la fonctionnalité centrale de gameplay ne fonctionnait pas. Le harness multi-agent a livré un résultat plus étendu et fonctionnel, malgré des défauts persistants.

Cela ne prouvait pas qu’un système plus lourd l’emporte systématiquement. Anthropic a ensuite supprimé la décomposition au niveau des sprints lorsque Claude Opus 4.6 a géré les travaux plus longs de façon plus cohérente. Pourtant, le planificateur et l’évaluateur continuaient de détecter des fonctionnalités manquantes ou superficielles.

L’événement constitue donc à la fois un rapprochement et un désaccord. OpenAI comme Anthropic simplifient les harnesses lorsque les modèles absorbent d’anciennes responsabilités. Elles divergent sur la rapidité avec laquelle les développeurs devraient faire confiance à ce transfert.

Pourquoi le débat sur les harnesses d’OpenAI et Anthropic compte aujourd’hui

La pression vient du fait que les agents dépassent les tâches de programmation circonscrites pour s’attaquer à des travaux dont la réussite est plus difficile à définir et l’échec plus difficile à inverser.

La programmation a offert le premier environnement favorable aux agents. Les dépôts contiennent des fichiers structurés, les compilateurs exposent les erreurs et les tests produisent souvent des signaux clairs de réussite ou d’échec. Un harness peut transformer ces signaux en une nouvelle tentative du modèle.

Le travail intellectuel général offre moins de vérifications fiables. Une note stratégique peut paraître cohérente tout en reposant sur des hypothèses fragiles. Une feuille de calcul peut effectuer des calculs corrects tout en répondant à la mauvaise question métier. Un agent peut terminer une présentation soignée sans remarquer que ses sources sont obsolètes.

OpenAI étend son approche des agents à ces environnements moins structurés. Ce mouvement pousse l’entreprise à préserver la simplicité associée à des modèles plus puissants tout en ajoutant les contrôles exigés par les utilisateurs ordinaires.

Anthropic subit la pression inverse. Claude Code a bâti une grande partie de son attrait sur des progrès visibles, des interactions fréquentes et l’implication de l’utilisateur. Cette approche peut sembler plus sûre, mais les questions et validations répétées accroissent la charge de travail de l’opérateur.

Cette rivalité reflète deux instincts produits. OpenAI a souvent cherché à offrir l’expérience consistant à confier un objectif et à recevoir un résultat fini. Anthropic a généralement exposé davantage le processus de raisonnement intermédiaire, par le biais de plans, d’alternatives et de demandes d’autorisation.

Aucun de ces instincts n’est universellement supérieur. L’autonomie devient attrayante lorsque l’objectif est clair et la vérification peu coûteuse. La collaboration gagne en valeur lorsque les préférences ne sont pas exprimées ou que les conséquences sont difficiles à mesurer.

Cela explique pourquoi une interface peut modifier la qualité apparente d’un modèle identique. Un harness contrôle la sélection du contexte, les descriptions d’outils, le comportement de reprise, l’accès aux fichiers et le moment de l’intervention utilisateur. Ces décisions façonnent chacune des actions du modèle.

Des créateurs de frameworks indépendants ont observé la même dépendance. LangChain a indiqué que des profils de harness spécifiques aux modèles produisaient des améliorations de 10 à 20 points sur un sous-ensemble de tau2-bench par rapport à sa configuration par défaut. Ses profils de harness ajustent les prompts, les outils et les middlewares selon les comportements des différents modèles.

Ce résultat remet en cause une version simpliste de la thèse d’OpenAI. Si le harness n’était qu’une béquille temporaire, sa modification ne devrait pas créer de grands écarts de performance alors que le modèle sous-jacent reste identique.

Il étaye toutefois aussi la critique d’OpenAI concernant l’abstraction inutile. LangChain n’a pas identifié une architecture unique, toujours plus complexe, qui améliore chaque modèle. L’entreprise a constaté que différents modèles répondaient à différentes configurations.

La pression pratique se reporte sur les équipes produit. Elles doivent décider si elles optimisent étroitement pour un fournisseur ou si elles maintiennent une couche portable entre plusieurs modèles.

Une optimisation poussée peut offrir de meilleurs résultats immédiats. Elle peut aussi créer une dépendance à des outils, prompts et comportements de contexte propres à un fournisseur. La portabilité limite cette dépendance, mais un harness générique peut laisser inutilisée une partie des capacités du modèle.

Ces choix deviennent plus déterminants à mesure que les agents reçoivent des autorisations plus étendues. Un assistant de programmation qui suggère un correctif joue un rôle circonscrit. Un agent qui lit des communications, modifie des documents partagés et déclenche des systèmes métiers franchit plusieurs frontières de confiance.

Les équipes qui évaluent ces produits devraient donc regarder au-delà des benchmarks de modèles. Elles ont besoin d’éléments sur la combinaison complète modèle-harness dans des conditions réalistes d’autorisations, de données et de défaillances.

OpenAI veut que le modèle prenne les commandes

L’argument d’OpenAI en faveur de harnesses plus légers veut que les développeurs exposent clairement l’environnement, puis laissent le modèle fournir l’essentiel du comportement adaptatif.

Cette position ne signifie pas supprimer les tests, les autorisations ou la gestion du contexte. Elle signifie résister aux procédures de raisonnement construites à la main qui compensent des limites supposées disparaître.

L’expérience d’OpenAI avec la première application web Codex aide à comprendre cette conviction. L’entreprise avait initialement parié sur un modèle capable d’accomplir des tâches avec une implication minimale de l’utilisateur. L’approche plus interactive de Claude Code d’Anthropic s’est révélée mieux adaptée à ce que les modèles pouvaient alors accomplir de façon fiable.

OpenAI a ensuite ajouté davantage d’occasions pour les utilisateurs de guider Codex. Un ingénieur a reconnu que le produit initial avait devancé ce que son modèle et son harness pouvaient prendre en charge.

Cette histoire compte parce qu’elle montre le danger des deux côtés. Un harness peut contenir trop de logique rigide. Il peut aussi présumer d’une compétence du modèle supérieure à celle que les utilisateurs reçoivent réellement.

L’approche actuelle d’OpenAI cherche à éviter un nouveau décalage grâce à des environnements plus clairs et des retours plus solides. Son compte rendu d’ingénierie interne met l’accent sur une documentation structurée, des règles de dépôt, des plans et des vérifications automatisées.

Ces éléments sont plus légers qu’un flux de travail qui prescrit chaque étape du raisonnement. Ils représentent néanmoins une ingénierie importante. Le harness délègue le jugement tout en facilitant l’inspection de la réussite.

Cette approche correspond aussi aux ambitions produit d’OpenAI. Un agent généraliste de travail ne peut pas s’appuyer sur des concepteurs qui prédisent chaque séquence qu’un utilisateur pourrait demander. L’espace des tâches possibles est trop vaste.

Un système guidé par le modèle peut choisir des outils et réviser des plans à mesure que les conditions changent. Cette flexibilité est attrayante lorsque les utilisateurs passent de la recherche aux feuilles de calcul, aux messages, au code et aux présentations au sein d’une même mission.

Cependant, un harness minimal transfère davantage de responsabilité vers le modèle. Le modèle doit repérer les ambiguïtés, demander les informations manquantes et reconnaître quand une action mérite confirmation.

Ces comportements ne sont pas garantis par la seule capacité générale. Un modèle peut mieux exécuter des instructions sans devenir tout aussi performant pour détecter un objectif défaillant.

L’expérience utilisateur renforce ce risque. Ethan Mollick, professeur à Wharton qui étudie l’IA au travail, a opposé les systèmes qui tentent de terminer immédiatement le travail à ceux qui présentent des comparaisons et demandent un retour.

La conception plus autonome réduit les frictions lorsque l’agent interprète correctement l’objectif. Dans le cas contraire, les utilisateurs peuvent ne découvrir l’erreur qu’après une longue chaîne de travail cohérent mais mal orienté.

Cela fait de la qualité du contexte un élément central. Un harness léger fonctionne au mieux lorsqu’il fournit des informations concises, pertinentes et à jour. Un contexte vaste et non filtré peut enfouir les priorités, même lorsque le modèle prend en charge une longue fenêtre de contexte.

Pour les travailleurs du savoir, l’organisation de ces éléments demeure un problème d’ingénierie distinct. Une base de connaissances consultable peut réduire le bruit de récupération avant qu’un agent ne commence à agir.

La thèse d’OpenAI est la plus forte pour les tâches disposant d’un retour machine dense. Les compilateurs, suites de tests, linters et vérifications dans le navigateur permettent à un agent d’évaluer ses progrès sans jugement humain constant.

Il devient moins efficace lorsque l’achèvement dépend de goûts, de l’historique organisationnel ou d’attentes non consignées. Un modèle ne peut pas inférer des éléments qui ne figurent jamais dans son contexte.

OpenAI fait donc un pari calculé. À mesure que les modèles progressent, ils prendront en charge davantage de planification et de récupération en interne. Les concepteurs de harnesses devraient préserver leur généralité plutôt que de figer les limites des modèles d’hier dans les produits de demain.

Anthropic affirme que les tâches plus difficiles nécessitent toujours davantage de structure

Les données d’Anthropic sur des harnesses plus lourds montrent que des modèles plus performants n’éliminent pas l’orchestration ; ils en repoussent la frontière utile vers des tâches plus complexes.

Le harness de longue durée d’Anthropic est parti de deux faiblesses récurrentes. Les modèles perdaient en cohérence durant les travaux prolongés, et ils évaluaient leurs propres résultats avec trop de bienveillance.

Le premier problème concernait le contexte. Les tâches longues accumulent des décisions, des résultats d’outils, des erreurs et des implémentations partielles. Même lorsqu’une fenêtre de contexte peut contenir ces éléments, leur organisation influence ce que le modèle remarque.

Anthropic a utilisé des réinitialisations de contexte avec des fichiers de transmission structurés. Une réinitialisation offrait à une nouvelle session d’agent un état de travail propre tout en préservant les progrès essentiels et les prochaines étapes.

Le second problème était l’auto-évaluation. Le même modèle qui produisait une application acceptait souvent des résultats insuffisants, surtout lorsque la qualité dépendait d’un jugement de conception.

Anthropic a séparé la création de la revue. Son évaluateur utilisait des critères explicites et l’automatisation du navigateur pour tester les fonctionnalités. Le générateur recevait des constats concrets et tentait d’effectuer les corrections.

Le premier harness complet a transformé une demande de jeu d’une phrase en 16 fonctionnalités réparties sur dix sprints. Son évaluateur appliquait des contrats détaillés à chaque sprint, dont 27 critères pour une étape de l’éditeur de niveaux.

Anthropic a indiqué que le résultat multi-agent offrait des fonctionnalités de base opérationnelles absentes de l’essai mono-agent. Il exigeait toutefois beaucoup plus de temps d’exécution, d’orchestration et d’utilisation du modèle.

Ce compromis rend l’expérience plus utile qu’une simple victoire dans un benchmark. Il montre ce que peut apporter une structure supplémentaire, tout en révélant pourquoi les équipes ne peuvent pas ajouter des évaluateurs sans discernement.

Anthropic a ensuite répété le processus avec un modèle plus performant. Opus 4.6 a maintenu la construction principale pendant plus de deux heures sans la décomposition précédente en sprints.

Cela confirmait l’observation centrale d’OpenAI. Une capacité autrefois fournie par le harness avait été intégrée au modèle, rendant une partie de l’échafaudage inutile.

L’évaluateur a néanmoins relevé des lacunes importantes. Il a identifié des fonctionnalités audio centrales qui n’existaient que sous forme d’éléments d’interface superficiels ou de placeholders. Le générateur a ensuite traité plusieurs de ces omissions.

La conclusion d’Anthropic n’était pas que chaque tâche requiert trois agents. L’évaluateur apportait le plus de valeur lorsque le travail se situait près de la limite de ce que le générateur pouvait achever de manière fiable.

Cette limite est dynamique. Une nouvelle version de modèle la repousse. Une tâche plus exigeante la ramène de nouveau vers l’intérieur.

Cela produit une interprétation différente de l’amer enseignement. Les modèles généralistes remplacent les solutions conçues sur mesure pour les problèmes d’hier, mais ils rendent également accessibles des objectifs auparavant impraticables.

Une fois que les équipes tentent d’atteindre ces objectifs, de nouveaux modes de défaillance apparaissent. Le harness ne disparaît pas. Il suit la frontière des capacités.

La position d’Anthropic reconnaît également que l’évaluation fait partie du produit. Un système qui génère davantage de résultats n’est pas automatiquement plus utile. Une personne ou un système doit déterminer si ce résultat répond au besoin réel.

Pour les développeurs, les suites de tests peuvent fournir une grande partie de ce jugement. Pour le design, la recherche et le travail de gestion, les critères doivent souvent être énoncés avant que l’agent agisse.

Une architecture planificateur-évaluateur rend ces attentes explicites. Elle peut aussi amplifier de mauvais critères. Un évaluateur appliquera l’indicateur mesurable qui lui est fourni, même si cet indicateur ne reflète pas ce que les utilisateurs valorisent.

Les harnesses plus lourds créent donc leur propre problème de gouvernance. Davantage de composants impliquent davantage de prompts, d’autorisations, de journaux, de transmissions et de chemins de défaillance à maintenir.

Les données d’Anthropic soutiennent une structure sélective, pas une complexité permanente. Retirez ce qu’un modèle plus performant peut désormais gérer, puis réinvestissez les efforts d’ingénierie là où la vérification produit encore un gain significatif.

Le test modèle contre harness reste indécis

Aucun des deux camps n’a démontré que son architecture privilégiée l’emporte sur l’ensemble des modèles, tâches, budgets et niveaux de risque.

Le débat entre les harnesses d’OpenAI et d’Anthropic repose largement sur des expériences internes et des observations de produit. Ces sources révèlent des choix d’ingénierie, mais elles ne fournissent pas de comparaison contrôlée entre Codex et Claude Code.

Le récit d’OpenAI reflète ses propres modèles, dépôts et pratiques d’équipe. Les exemples d’Anthropic utilisent des modèles Claude sur une sélection de tâches de création d’applications. Chaque entreprise a choisi l’environnement et les critères de réussite.

Même la comparaison détaillée d’Anthropic modifiait plusieurs variables à la fois. Le système complet ajoutait planification, évaluation, décomposition, exécution plus longue et davantage d’appels au modèle. Le résultat ne permet pas d’isoler quel composant a créé chaque amélioration.

L’entreprise a ensuite utilisé le retrait de composants pour examiner cette question. Ses conclusions reposaient toutefois encore sur un petit ensemble de démonstrations plutôt que sur une réplication indépendante à grande échelle.

Les benchmarks tiers aident, mais ils introduisent des complications supplémentaires. Un harness peut être performant parce que le benchmark ressemble à son flux de travail privilégié. Une autre configuration peut plutôt optimiser l’usage des tokens, le taux de réussite, la latence ou la capacité de récupération.

Un même score peut aussi masquer des risques opérationnels différents. Un agent peut échouer visiblement et s’arrêter. Un autre peut produire un résultat plausible mais incorrect qui passe les vérifications automatisées.

Les recherches sur les systèmes de codage en production traitent de plus en plus le modèle et le harness comme une unité combinée. Une récente étude sur le code source a examiné 11 harnesses de codage, dont Claude Code, Codex CLI, Gemini CLI, Pi, OpenCode et OpenHands.

Cette diversité affaiblit l’idée d’un harness optimal unique. Ces systèmes diffèrent dans leur gestion du contexte, leurs points d’extension, leur planification, leur isolation et l’exécution des outils, car leurs concepteurs visent des utilisateurs différents.

La portabilité constitue une autre question non résolue. Des reportages ont cité une comparaison dans laquelle le harness open source Pi surpassait Codex tout en utilisant le même modèle OpenAI.

Un tel résultat suggère que le fournisseur du modèle ne construit pas automatiquement le meilleur environnement pour chaque tâche. Il n’établit pas que Pi l’emporte largement, puisque la configuration du benchmark et les réglages restent déterminants.

Les harnesses ouverts peuvent exposer des traces, l’utilisation des tokens et des détails de configuration que les produits propriétaires dissimulent. Cette transparence aide les équipes à diagnostiquer les échecs et à changer de fournisseur.

Les harnesses contrôlés par les fournisseurs accèdent plus tôt aux capacités spécifiques aux modèles. Leurs développeurs peuvent s’adapter à des comportements non documentés et déployer des mises à jour coordonnées.

Les incitations commerciales comptent. OpenAI et Anthropic bénéficient tous deux de l’utilisation de leurs modèles par les clients via leurs propres interfaces. Posséder le harness renforce la distribution et peut accroître les coûts de changement grâce au contexte stocké, aux intégrations et aux flux de travail appris.

Cela ne rend pas leurs affirmations d’ingénierie fausses. Cela signifie que les clients doivent distinguer les preuves techniques de la stratégie de plateforme.

Le coût constitue une autre incertitude, même sans comparer les prix publics. La planification et l’évaluation multi-agents consomment davantage de tokens et de temps. Un taux d’achèvement supérieur peut justifier ce surcoût lorsque l’échec est coûteux.

L’inverse s’applique au travail routinier et réversible. Exécuter un évaluateur pour chaque modification mineure peut consommer plus de ressources que la correction d’une erreur occasionnelle.

La sécurité complique encore la thèse du harness léger. De meilleurs modèles peuvent exécuter des séquences d’actions plus longues et utiliser les outils plus efficacement. Ces améliorations augmentent les conséquences d’instructions mal comprises.

Les limites d’autorisation, les journaux d’audit, le sandboxing et les confirmations sont des fonctions du harness. Une capacité renforcée peut accroître leur importance tout en réduisant le besoin d’échafaudages de planification.

Les équipes devraient donc rejeter les tests unidimensionnels. Une évaluation utile doit mesurer l’achèvement des tâches, les défauts cachés, le temps de revue humaine, la consommation de ressources et la récupération après un échec.

Elle devrait également comparer les configurations avec le même modèle. Sinon, une équipe peut acheter un modèle plus capable alors qu’un changement de contexte ou d’outil aurait résolu le problème.

Les données actuelles soutiennent une règle conditionnelle. Utilisez le harness le plus léger qui atteint un seuil de fiabilité défini, puis ajoutez de la structure lorsque les échecs observés le justifient.

Cette règle ressemble à un compromis, mais elle crée un travail opérationnel exigeant. Les équipes ont besoin d’évaluations reproductibles, d’inspection des traces et de configurations versionnées pour savoir quand un composant reste utile.

Sans ces preuves, « plus léger » devient une foi dans le prochain modèle. « Plus lourd » devient un folklore accumulé, encodé sous forme de prompts et de branches de flux de travail.

Trois signaux détermineront quelle approche l’emporte

La prochaine phase sera décidée par des preuves comparatives, et non par la description privilégiée de son architecture par l’une ou l’autre entreprise.

Le premier signal sera la performance lors de l’échange des harnesses. Les chercheurs et les créateurs de frameworks ont besoin de tests contrôlés qui maintiennent constants le modèle, la tâche, l’accès aux outils et les limites de ressources.

Si des harnesses tiers surpassent régulièrement les interfaces des fournisseurs avec le même modèle, la valeur se déplace vers l’orchestration. Ce résultat affaiblirait l’idée que les progrès des modèles absorbent naturellement l’essentiel de la différenciation produit.

Si les écarts de performance se réduisent entre des harnesses bien conçus, la thèse d’OpenAI gagne en crédibilité. Cela suggérerait que des modèles plus performants nécessitent moins d’interventions spécialisées et peuvent fonctionner dans des environnements plus simples et standardisés.

Le deuxième signal sera la manière dont Anthropic et OpenAI simplifient leurs propres systèmes après chaque nouvelle version de modèle. Anthropic a déjà montré une version de ce test en retirant la décomposition en sprints des flux de travail d’Opus 4.6.

Observez quels composants disparaissent ensuite. La planification, les réinitialisations de contexte, l’évaluation indépendante et les approbations fréquentes représentent chacune une hypothèse différente sur les limites des modèles.

Retirer un composant sans réduire la qualité de la tâche renforce l’argument du harness léger. Déplacer ce composant vers une classe de travail plus difficile soutient l’interprétation d’Anthropic fondée sur une frontière mobile.

Le troisième signal sera l’adoption hors de l’ingénierie logicielle. Les agents de codage bénéficient de dépôts, de tests et de retours numérisés. Le travail intellectuel contient des signaux plus faibles et davantage de préférences implicites.

Un agent piloté par le modèle paraîtra convaincant si les personnes acceptent le travail achevé sans corrections importantes. Un harness collaboratif paraîtra plus solide si les utilisateurs ont systématiquement besoin d’aperçus, de comparaisons et d’étapes d’approbation.

L’indicateur d’adoption le plus utile ne sera pas le nombre de tâches commencées. Ce sera la part achevée correctement après prise en compte de la revue humaine et des retouches.

Les développeurs devraient également suivre la gravité des échecs. Un harness qui accomplit moins de tâches mais s’arrête en sécurité peut être préférable à un autre qui en termine davantage tout en commettant des erreurs difficiles à détecter.

Les acheteurs d’entreprise devraient exiger des évaluations utilisant leurs documents, autorisations et flux de travail. Les classements publics ne peuvent pas représenter les définitions de l’exactitude propres à chaque organisation.

Les travailleurs du savoir peuvent mener une version plus simple de ce processus. Commencez par une tâche familière et réversible, puis comparez le résultat de l’agent à une référence humaine établie.

Consignez les situations où le modèle manquait de contexte, a choisi le mauvais outil ou a nécessité une orientation subjective. Ces observations révèlent si la prochaine intervention doit porter sur les instructions, la récupération d’informations, les règles d’approbation ou une revue indépendante.

Le débat sur les harnesses d’OpenAI et d’Anthropic ne s’achèvera pas parce qu’une entreprise choisira une couche légère et l’autre une couche plus épaisse. Toutes deux ajoutent et retirent déjà des composants à mesure que les modèles et les tâches évoluent.

L’avantage durable reviendra aux équipes capables de mesurer rapidement ces évolutions. Elles sauront quelles contraintes empêchent encore les défaillances et lesquelles ne font que préserver des hypothèses héritées d’un ancien modèle.

Pour toute personne déployant des agents, l’action immédiate est simple : tester ensemble le modèle et le harness, examiner les traces réelles et définir le succès avant d’accorder une autonomie plus large. Des modèles plus puissants déplacent la frontière de l’ingénierie, mais n’éliminent pas la nécessité de l’identifier.