Critique de la théorie de l'inutilité de l'ingénierie des harnais chez les grandes tech et des boucles générations futures sans discernement

Après la publication d'un article connexe d'AI Times abordant la théorie de l'inutilité de l'ingénierie des harnais chez les grandes tech, plusieurs leaders technologiques ont échangé leurs opinions à ce sujet. Il a été rapporté que, après Google, OpenAI avait également déclaré que les modèles de prochaine génération pourraient absorber une partie importante des fonctionnalités actuelles des harnais.

Ce texte vient ajouter à cette discussion. Pour conclure d'emblée, je suis d'accord avec la perspective selon laquelle la majorité des harnais disparaîtront. J'ai moi-même écrit dans mon article Harness Engineering Expliqué Complètement — Origines, Concepts, Écarts, Avenir Tout en Un que les harnais complexes créés pour corriger les faiblesses des modèles seront rapidement remplacés à mesure que les modèles s'améliorent.

Cependant, extrapoler cela pour affirmer que tous les harnais deviendront bientôt inutiles serait une erreur qui oublierait l'essence des harnais. La question de l'absorption des fonctionnalités par le modèle est différente de celle de la gestion des responsabilités lorsque les humains et les organisations confient du travail à l'IA.

Commençons d'abord par examiner la manière dont les mots-clés circulent

Cependant, les mots-clés technologiques ont souvent été consommés de manière différente et avec des significations distinctes en Corée par rapport à l'étranger. J'ai donc d'abord procédé à une vérification de ce point. Cette fois aussi, nous devons distinguer les déclarations originales, les discussions techniques réelles et le cadre créé en Corée.

Voici une comparaison de la consommation du mot-clé ingénierie des harnais entre le monde et la Corée, tirée de mon article Harness Engineering Expliqué Complètement — Origines, Concepts, Écarts, Avenir Tout en Un.

Cette fois-ci également, il faut être prudent face à l'interprétation généralisée : il n'existe pas de preuve claire que "harness is dead" ou "harness is useless" soit devenu un slogan largement accepté dans les pays anglophones. Il est plus exact de parler de discussions sur l'amélioration de la capacité d'utilisation d'outils des modèles, de l'absorption de certains éléments d'échafaudage dans les modèles ou les plateformes, et sur le raccourcissement potentiel de la durée de vie des couches d'ajustement complexes construites manuellement. Les déclarations du vice-président Noam Brown ne m'ont pas été confirmées directement jusqu'à la source originale ; je n'en ai eu connaissance que par les reportages nationaux et internationaux. Par conséquent, je vais examiner le cadre de « théorie de l'inutilité des harnais » qui s'est rapidement cristallisé en Corée.

Les harnais qui disparaîtront et ceux qui doivent persister sont différents

Il est clair que certains harnais disparaîtront. Les approches qui exigeaient de fragmenter les invites sur plusieurs étapes, les règles temporaires contournant les défauts de certains modèles, les flux de travail peu profonds dont l'ordre d'appel d'outils était fixé de force par l'humain — tout cela peut être absorbé à mesure que les modèles s'améliorent. Ces harnais ont tout intérêt à disparaître.

Cependant, comme l'a synthétisé le directeur général de A2Sys, Dongsoo Lee, extrapoler cela à tous les harnais serait dangereux. Pour résumer :

• Les harnais de prompts et de flux de travail peuvent être absorbés par le modèle. Nous sommes d'accord.
• Les harnais d'exécution d'outils traitent des permissions, des approbations et de la récupération après défaillance. Est-ce vraiment un harnais destiné à disparaître ?
• Les harnais de runtime, de mémoire et d'infrastructure traitent du contexte, du cache, du routage des modèles, des coûts, de la latence et des pistes d'audit. Il est difficile de considérer cela aussi comme un harnais destiné à disparaître.

L'essence des harnais que j'ai décrite aux chapitres 7 à 11 de « Ingénierie des Harnais : Re:Commencer à zéro — Génie logiciel IA » réside ici. Les contrats définissent les limites autorisées, la structure et l'isolation réduisent la portée des modifications, tandis que la traçabilité et la validation relient l'intention originale au résultat réel. La mesure et l'exploitation gèrent les coûts, les permissions, les pannes et la récupération. L'ingénierie des harnais dans cette portée n'est pas quelque chose qui sera résolu simplement parce que les modèles s'améliorent.

D'un autre côté, l'argument selon lequel les harnais, les boucles et l'ingénierie des prompts sont des heuristiques humaines est également valide. Toute méthodologie commence par des heuristiques. Les types, les tests, l'intégration continue, les révisions de code et la séparation des responsabilités sont tous des méthodes créées par les humains pour gérer des systèmes complexes. Mais ce qui est plus important ici, c'est : peut-on confier à un modèle navire amiral seul la transparence et la responsabilité ? Si une tâche est assignée, l'IA seule ne peut pas vérifier qu'elle s'exécute correctement selon l'intention, ni qu'elle ne commet pas d'erreurs sans surveillance. Il pourrait certes exister une IA qui surveille et corrige, mais ce serait alors un harnais.

Dans un commentaire sur un message du professeur Han Sang-gi, j'ai formulé cette position comme suit :

L'ingénierie des harnais dépendra de la portée considérée. Tant qu'il existe une intention organisationnelle et celle du développeur, il sera difficile pour elle de disparaître.

Plus les modèles s'améliorent, plus grande est la possibilité que l'IA accomplisse quelque chose de complètement inattendu de manière plus sophistiquée. C'est pourquoi les harnais ne sont pas des dispositifs de correction des faiblesses des modèles, mais plutôt des dispositifs d'exploitation qui fixent la direction et la responsabilité.

En pratique, les frontières des responsabilités viennent avant les capacités du modèle

Nextain collabore avec les clients demandeurs de développement via Discord. Aujourd'hui, j'y ai introduit un agent Claude Code résolvant un problème spécifique. L'agent Nextain participant au canal (en réalité Claude Code fonctionnant sur un serveur) lit le canal Discord et répond.

L'opérateur non-développeur présent sur le canal a fourni les résultats des tests, les lacunes et les exigences. Face à cela, alors qu'il traitait ce qui était possible de traiter, lorsqu'il devait modifier un déploiement important ou une ressource à ne pas toucher, il demandait mon approbation.

De plus, au début du déploiement, il commençait à travailler dès qu'il entendait les exigences, ce qui frustrait les demandeurs. J'ai donc donné des instructions sur le processus de travail. Voici les instructions : écoutez les exigences et confirmez la réception, effectuez l'analyse, établissez un plan, signalez le plan à nouveau sur le canal Discord, puis commencez le travail. À la fin, une fois le travail terminé, faites un rapport final, et si des problèmes survenaient en cours de route, appelez-moi (le leader en développement) pour m'informer via Discord sur ce qui nécessite une décision.

Le cœur de ce harnais est le processus de développement de Nextain et les responsabilités de chaque membre. Serait-ce que si c'était un modèle navire amiral, il agirait de lui-même de la meilleure façon possible ? Y a-t-il vraiment une seule meilleure façon ? La cohérence du processus organisationnel et du travail est ultimement un harnais. Cette frontière des responsabilités est indépendante de la capacité du modèle. Plus un modèle peut accomplir de tâches, plus strictement nous devons distinguer ce qui est autorisé et où il faut s'arrêter.

Le problème réel dans les opérations est la dérive et les coûts

Le problème auquel sont confrontés les développeurs utilisant Codex et Claude en pratique reste la dérive. Même en réduisant les objectifs, cela s'échappe sur d'autres chemins, effectue des modifications qui ne devraient pas être effectuées, modifie les tests pour réussir et ignore les frontières des responsabilités d'exploitation. Plus le modèle devient sophistiqué, plus ce problème peut être habilement dissimulé.

Dans ce contexte, « il suffit d'en exécuter plus » fonctionne pour les grandes tech. Augmentez le temps d'inférence, créez plus de candidats, abandonnez les chemins échoués, ajoutez une validation externe. Cependant, pour les développeurs en pratique et les petites startups qui doivent économiser chaque centime, c'est impossible. La situation des entreprises nationales est identique.

Le « rendement en termes de coûts totaux de jetons » mentionné par Ha Jeong-woo, ancien Secrétaire en chef adjoint à la planification de l'avenir IA, dans les commentaires avec le professeur Han Sang-gi cités ci-dessus, est exactement ce critère. Les harnais ne sont pas des dispositifs pour rejeter les modèles navires amiraux. Ce sont des dispositifs de contrôle des coûts pour utiliser les modèles onéreux uniquement sur les jugements vraiment nécessaires, et pour séparer le travail répétable en modèles plus petits, outils locaux, scripts et validateurs déterministes.

Les récentes réalisations mathématiques d'OpenAI doivent aussi être divisées en deux moments. J'évalue haut la première réussite liée au contre-exemple du problème des distances unitaires du plan d'Erdős, car elle montre la possibilité qu'une IA découvre de nouvelles connexions mathématiques différentes des approches existantes. C'est un cas qui démontre la possibilité d'une découverte nouvelle que seule l'IA pourrait faire.

En revanche, le calcul au moment des tests, qui a été davantage mis en avant par la suite, représente une direction où davantage de calcul et de recherche de candidats, de validation et d'itération sont investis au moment de l'inférence. C'est aussi une technologie importante. Cependant, si on en parle uniquement comme une amélioration de l'intelligence pure d'un seul modèle, la structure des coûts disparaît. C'est une technologie de quantité, mais particulièrement avantageuse pour les grandes tech.

Les harnais sont des lignes de défense contre les coûts et les données

L'affirmation « les modèles vont dévorer les harnais » est accrocheuse. Cependant, qui utilise ce modèle et combien il coûte est une question distincte. À mesure que les modèles absorbent plus de fonctionnalités, le code utilisateur peut devenir plus simple. Simultanément, on pourrait devenir dépendant d'appels de modèles plus lourds et plus onéreux. La complexité ne disparaît pas ; elle se déplace du lieu de travail de l'utilisateur vers la couche de facturation du fournisseur du modèle.

Il en va de même pour les données. Pour que les agents deviennent vraiment utiles, ils doivent voir les documents, le code, les calendriers, les e-mails, les journaux opérationnels, l'historique des pannes, les flux d'approbation et les données client. Au moment où l'agent devient le lieu de travail, l'intégralité du travail de l'utilisateur devient une entrée.

Un bon harnais n'envoie que le contexte nécessaire aux modèles externes et laisse le reste dans le lieu de travail de l'utilisateur. Il route les modèles, réutilise les caches, divise les permissions et ajoute une validation reproductible. C'est pourquoi les harnais constituent à la fois une ligne de défense contre les coûts et une ligne de défense contre les données.

De ce point de vue, il est possible que les entreprises mondiales de modèles souhaitent éviter un robuste harnais côté utilisateur. Si l'utilisateur traite d'abord avec des modèles plus petits et des outils locaux, puis n'appelle le navire amiral que quand c'est nécessaire, le nombre d'appels et le contexte transmis diminuent. Ce n'est pas une affirmation définitive, mais plutôt une considération qui doit naturellement être examinée dans une structure industrielle où les coûts de développement, d'inférence, de GPU et d'électricité des modèles de frontière augmentent.

OpenAI et Anthropic sont à la ligne de front de la compétition des harnais via Codex et Claude Code. Google, en revanche, est à la fois une entreprise de modèles et un acteur du cloud. On ne peut pas dire que chaque entreprise a exactement les mêmes intérêts, mais la raison pour laquelle il est difficile d'écouter cette controverse comme une simple prédiction technologique est clairement définie. Un bon harnais réduit à la fois « le désir des grandes tech de déplacer le lieu de travail vers le modèle pour collecter des données » et « la dépendance à l'utilisation du navire amiral ».

Les boucles ne sont pas la valeur par défaut de la prochaine génération

Il en va de même pour les boucles. Je les utilise moi-même, mais je pense qu'il est généralement approprié de ne pas utiliser de boucles pour la plupart des missions. Si c'est le type de travail qui peut produire un résultat adéquat même en le confiant à un développeur ordinaire, utiliser correctement un bon modèle une fois sera probablement moins cher et plus rapide. Étonnamment, les cas où les boucles sont efficaces sont étroits.

Premièrement, il y a la recherche et développement. C'est le travail où il n'y a pas de réponse correcte, où l'hypothèse change en fonction des résultats expérimentaux, et où l'expérience suivante doit changer de manière active basée sur les résultats précédents. C'est le cas pour notre recherche interne sur la voix et le chant. Dans ce cas, plusieurs IA examinent les résultats expérimentaux et l'ensemble des données, jugent la continuité avec les expériences existantes, si la dérive est présente, et la nécessité du prochain cycle. Le critère d'achèvement n'est pas un résultat plausible, mais le jugement selon lequel l'indice ne s'améliore plus. Comme l'objectif est la convergence de l'exploration, les boucles conviennent.

Deuxièmement, il y a l'utilisation de petits modèles dans un environnement limité. Un petit LLM a tendance à réduire l'objectif et à arrêter en disant « c'est assez ». Cependant, dans ce cas, ce qui est nécessaire est moins une longue boucle qu'un dispositif qui ferme l'objectif et la condition de fin. C'est plus proche de la fonctionnalité « goal » de Claude Code qu'une boucle. Un harnais qui fixe l'objectif et la responsabilité. Si vous abusez des boucles dans les tâches quotidiennes d'un utilisateur ordinaire, c'est un gaspillage de coûts. Les boucles sont utilisées pour la convergence de l'exploration, les harnais pour fixer l'objectif et la responsabilité. Les deux ne sont pas interchangeables.

Naia cherche à préserver le lieu de travail du côté de l'utilisateur

Naia ne rejette pas les modèles navires amiraux. Nous prévoyons d'utiliser le modèle phare cloud pleinement dans le développement. Les bons modèles doivent être utilisés.

Cependant, nous n'avons pas l'intention de transmettre tous les lieux de travail et données aux plateformes des grandes tech. Ce que Naia vise est une structure qui combine local, P2P, open-weight, petits modèles, validateurs déterministes et harnais d'autorisation explicite. Utilisez les navires amiraux onéreux pour les décisions nécessaires, mais préservez le lieu de travail de base dans les mains de l'utilisateur.

De ce point de vue, le développement de modèles open-weight comme DeepSeek, Qwen, Kimi et GLM est important. Il devient possible de combiner des modèles selon les objectifs, de protéger les données localement, et d'appeler le navire amiral fermé uniquement lorsque c'est nécessaire. En Corée, la stratégie de modèles indépendants de Upstage et Naver a aussi du sens dans ce contexte. Plutôt que de suivre simplement le navire amiral des grandes tech mondiales, une approche combinant open-weight, modèles indépendants, harnais spécialisés et contexte de travail domestique peut être plus pragmatique.

Les modèles peuvent être loués. Mais il n'est pas nécessaire de louer le lieu de travail et les données aussi.

Conclusion : Ce qui est nécessaire au-delà de la théorie de l'inutilité, ce sont les discussions sur les niveaux technologiques

Les harnais destinés à disparaître disparaîtront. Les fonctionnalités absorbées par les modèles augmenteront. Il n'y a aucune raison de nier cela. Cependant, je ne pense pas que les fonctionnalités absorbées par les modèles, le système d'exécution qui fixe l'intention et la responsabilité de l'organisation, et le système d'exploitation qui protège les frontières des coûts et des données disparaîtront. Si le sujet qui délègue le travail à l'IA est humain et si le sujet responsable des résultats est aussi humain, alors les contrats, la structure, la traçabilité, la validation et l'exploitation ne disparaîtront pas.

J'espère que nous cesserons d'avoir ces débats de mots-clés sur le fait que les harnais sont morts ou vivants. Je voudrais que les discussions vraiment centrées sur la technologie progressent en avant : ce qu'il faut mettre à l'intérieur du modèle, ce qui doit rester sous le contrôle de l'utilisateur et de l'organisation, comment valider et annuler la dérive, qui supportera le coût des jetons et l'exposition des données.

Références et sources

Mes articles et livres

• « Ingénierie des Harnais : Re:Commencer à zéro — Génie logiciel IA »
• « Harness Engineering Expliqué Complètement — Origines, Concepts, Écarts, Avenir Tout en Un »
• « Annonce de la publication d'Ingénierie des Harnais »

Déclencheurs directs de cette discussion

• AI Times, "Après Google, OpenAI aussi affirme que les modèles absorberont les fonctionnalités des harnais"
• AI Times, "[25 juin] 'Les modèles vont dévorer les harnais'..."
• Message Facebook du professeur Han Sang-gi et discussions dans les commentaires
• Dongsoo Lee, CEO d'A2Sys, "Théorie de l'inutilité des harnais ? Moitié vrai, moitié faux"

Documents techniques et sources originales

• OpenAI, "Learning to Reason with LLMs"
• OpenAI, "An OpenAI model has disproved a central conjecture in discrete geometry"
• OpenAI, "Introducing Codex"
• OpenAI, "Introducing OpenAI o3 and o4-mini"
• Google, "Gemini 2.0: our new AI model for the agentic era"
• "The Interplay of Harness Design and Post-Training in LLM Agents"
• "More Is Not Always Better: Cross-Component Interference in LLM Agent Scaffolding"
• "AutoHarness"