Harness a explosé — mais les gens n'ont pas compris qui il veut vraiment dévorer

Palo Alto ce matin, le café vient d’être servi, Alan Walker baisse les yeux et tombe sur l’article d’Anthropic sur harness, lève la tête et dit simplement :

“Beaucoup de gens pensent que c’est un petit progrès du modèle. Faux, c’est le processus qui commence à trahir l’homme.”

Cet article parle en surface de conception d’ingénierie, parle de planner, generator, evaluator, parle de comment faire fonctionner Claude pendant plusieurs heures, pour créer des produits plus complexes.

La plupart des gens s’arrêtent ici. Ils pensent :

Oh, donc c’est juste que l’agent est devenu plus complexe, le prompt est plus long, le workflow est plus détaillé.

Mais Alan dit que ce qui mérite vraiment d’être regardé n’est jamais la fonctionnalité de surface, mais où le pouvoir se déplace.

Pour qu’une tâche complexe soit réalisée dans le passé, il fallait quelqu’un pour décomposer les besoins, quelqu’un pour exécuter, quelqu’un pour vérifier, quelqu’un pour retravailler, quelqu’un pour garantir.

Maintenant, ce qu’Anthropic fait, ce n’est pas de rendre le modèle plus semblable à un employé intelligent, mais de laisser tout le système commencer à prendre en charge le niveau d’organisation, de supervision et d’acceptation qui appartenait auparavant aux humains.

Harness n’est pas un plug-in. Harness est la machine qui commence à développer une “couche de gestion”.

C’est ce qui est vraiment effrayant.

01 Ce n’est pas un outil, c’est “la couche qui gère les outils”

Beaucoup de gens voient harness, et leur première réaction est : n’est-ce pas juste un autre cadre d’agent ?

Cette compréhension est trop superficielle.

L’essence d’un outil ordinaire est d’exécuter des ordres. Vous cliquez, il fait. Vous ne dites rien, il ne bouge pas.

Mais harness n’opère plus selon cette logique. Ce qu’il fait réellement, c’est de rationaliser la structure de répartition du travail qui était auparavant cachée dans les équipes humaines :

Qui comprend les besoins, qui les décompose en étapes, qui exécute, qui vérifie, qui a le droit de renvoyer pour retravailler une fois qu’un problème est découvert.

En d’autres termes, Anthropic ne s’efforce pas d’accumuler plus de fonctionnalités, mais d’intégrer “comment organiser le travail” dans le système lui-même.

Pourquoi cette étape est-elle importante ? Parce que ce qui était le plus difficile à reproduire dans le passé n’était jamais une capacité unique, mais une capacité organisationnelle.

Il y a beaucoup de gens qui savent écrire du code.

Mais peu de gens savent organiser une douzaine de personnes, plusieurs étapes et plusieurs cycles de retravail pour finalement livrer de manière stable.

Et ce que harness touche, c’est précisément cette couche de valeur la plus élevée.

Les outils améliorent l’efficacité, l’organisation détermine la production.

Un modèle individuel n’est qu’une force de travail, Harness commence à toucher à la structure de l’entreprise.

Quand l’IA ne se contente pas de travailler, mais commence à se diviser, à transférer des tâches, à rendre des comptes, elle n’est plus un simple “upgrade d’outil”.

02 Ce n’est pas plus intelligent, c’est plus difficile à échouer

L’aspect le plus déroutant d’un modèle est qu’il semble toujours très intelligent dans des tâches courtes.

Posez-lui une question, il répond avec clarté ; demandez-lui d’écrire un code, il le fait souvent de manière convaincante. Ainsi, beaucoup de gens se trompent en pensant : puisque les tâches courtes peuvent être réalisées, les tâches longues ne consistent qu’à faire fonctionner plus longtemps ?

Pas du tout.

La véritable difficulté des tâches longues n’est jamais qu’une étape ne peut être réalisée, mais de rester cohérent et contrôlé sans se déformer après des dizaines d’étapes.

Les humains rencontrent les mêmes difficultés dans les projets. Ce qui est le plus redouté, ce n’est pas l’incapacité, mais le fait que les choses deviennent chaotiques à mesure que l’on avance :

Les besoins ne sont plus clairs,

Les objectifs commencent à dériver,

La logique devient incohérente,

Et finalement, ce qui est le plus maîtrisé n’est pas d’achever le travail, mais de rédiger un résumé qui semble terminé.

Le problème central mentionné dans l’article d’Anthropic est essentiellement celui-ci :

Les modèles perdent progressivement leur âme dans les tâches à long terme. Plus le contexte est long, plus l’état devient chaotique, plus il est facile d’entrer dans une illusion psychologique de “ça ira”.

La valeur de Harness n’est pas de le rendre plus agile, mais de le rendre moins dispersé, moins illusoire, moins susceptible de passer inaperçu.

Décomposer les étapes, faire des transferts, établir des contrats, évaluer de manière indépendante, revenir en arrière en cas d’échec, ces détails de processus semblent être des détails, mais ils résolvent en réalité le même problème fondamental :

L’intelligence peut être instable, mais la livraison ne peut pas dépendre de la chance.

Donc, si vous voulez vraiment comprendre harness, vous devez d’abord comprendre une chose :

Ce qui sera réellement précieux à l’avenir, ce n’est pas celui qui peut occasionnellement produire une démo impressionnante.

Mais celui qui peut faire avancer le système pendant quelques heures, quelques jours, voire plus longtemps, sans échouer.

Savoir écrire n’est pas exceptionnel.

Écrire jusqu’à la fin sans s’effondrer, cela l’est.

Une étincelle d’inspiration n’a pas de valeur, une livraison stable en a.

Alan dit que la phrase la plus froide dans cet article d’Anthropic n’est pas planner, ni generator, mais evaluator.

Pourquoi ?

Parce que les grands modèles ont un défaut très similaire à celui des humains : ils pensent toujours que ce qu’ils font est acceptable.

Tant qu’il n’y a pas de contraintes externes, il est très facile de donner une évaluation de “plutôt bon”, “essentiellement terminé”, “les fonctionnalités essentielles sont présentes”.

Le problème est que cette évaluation est souvent non pas un mensonge, mais une forme de complaisance systémique.

Pourquoi tant de projets échouent-ils dans les entreprises humaines ?

Parce que ceux qui exécutent sont souvent les meilleurs pour se trouver des excuses.

Ceux qui réalisent disent que c’est presque fait,

Ceux qui vérifient n’ont pas envie de plonger en profondeur,

Et donc quelque chose de “presque” est finalement validé et explose entre les mains des utilisateurs.

Ce qui est particulièrement impitoyable chez Anthropic, c’est qu’ils décomposent cette tâche :

Celui qui travaille est un rôle,

Celui qui corrige est un autre rôle.

Le premier est responsable de la progression, le second de la suspicion.

La logique sous-jacente est très profonde :

Une fois que les droits de production et d’évaluation sont séparés, le système commence à former un véritable cycle fermé.

Et ce qui est encore plus inquiétant, c’est qu’Anthropic ne laisse pas simplement l’evaluator dire “je pense que ça ne va pas ici”. Ils essaient de structurer la “correction des erreurs” :

Les fonctionnalités doivent être testées, les pages doivent être cliquées, les interfaces doivent être vérifiées, l’état de la base de données doit être observé, la qualité du design est aussi décomposée en dimensions évaluables.

Que signifie cela ?

Cela signifie que de nombreux jugements qui étaient auparavant mystifiés par les humains commencent à être décomposés en processus, normes et seuils.

Ce qui est le plus souvent automatisé n’est pas la force physique, mais la correction des erreurs.

Une fois que “ce truc fonctionne-t-il ou non” devient systématisé, les protections basées sur l’expérience de nombreuses personnes commenceront à fuir.

De nombreux postes dans le passé étaient précieux non pas parce qu’ils produisaient, mais parce qu’ils avaient le pouvoir de dire “ce truc est-il acceptable ?”.

Maintenant, ce pouvoir commence à se desserrer des mains des gens.

03 Le coup le plus impitoyable, c’est de ne pas se permettre de se vanter

Alan dit que la phrase la plus froide dans cet article d’Anthropic n’est pas planner, ni generator, mais evaluator.

Pourquoi ?

Parce que les grands modèles ont un défaut très similaire à celui des humains : ils pensent toujours que ce qu’ils font est acceptable.

Tant qu’il n’y a pas de contraintes externes, il est très facile de donner une évaluation de “plutôt bon”, “essentiellement terminé”, “les fonctionnalités essentielles sont présentes”.

Le problème est que cette évaluation est souvent non pas un mensonge, mais une forme de complaisance systémique.

Pourquoi tant de projets échouent-ils dans les entreprises humaines ?

Parce que ceux qui exécutent sont souvent les meilleurs pour se trouver des excuses.

Ceux qui réalisent disent que c’est presque fait,

Ceux qui vérifient n’ont pas envie de plonger en profondeur,

Et donc quelque chose de “presque” est finalement validé et explose entre les mains des utilisateurs.

Ce qui est particulièrement impitoyable chez Anthropic, c’est qu’ils décomposent cette tâche :

Celui qui travaille est un rôle,

Celui qui corrige est un autre rôle.

Le premier est responsable de la progression, le second de la suspicion.

La logique sous-jacente est très profonde :

Une fois que les droits de production et d’évaluation sont séparés, le système commence à former un véritable cycle fermé.

Et ce qui est encore plus inquiétant, c’est qu’Anthropic ne laisse pas simplement l’evaluator dire “je pense que ça ne va pas ici”. Ils essaient de structurer la “correction des erreurs” :

Les fonctionnalités doivent être testées, les pages doivent être cliquées, les interfaces doivent être vérifiées, l’état de la base de données doit être observé, la qualité du design est aussi décomposée en dimensions évaluables.

Que signifie cela ?

Cela signifie que de nombreux jugements qui étaient auparavant mystifiés par les humains commencent à être décomposés en processus, normes et seuils.

Ce qui est le plus souvent automatisé n’est pas la force physique, mais la correction des erreurs.

Une fois que “ce truc fonctionne-t-il ou non” devient systématisé, les protections basées sur l’expérience de nombreuses personnes commenceront à fuir.

De nombreux postes dans le passé étaient précieux non pas parce qu’ils produisaient, mais parce qu’ils avaient le pouvoir de dire “ce truc est-il acceptable ?”.

Maintenant, ce pouvoir commence à se desserrer des mains des gens.

04 Ce qui sera mangé en premier, ce ne sont pas les programmeurs, mais “presque bon”

Dès qu’ils voient ce genre d’article, beaucoup de gens réagissent immédiatement en disant : les programmeurs vont-ils disparaître ?

Alan dit que cette question est trop superficielle et paresseuse.

La première vague qui sera absorbée par Harness n’est pas un intitulé de profession.

Ce qui sera d’abord mangé, c’est une manière de vivre qui existe depuis longtemps et est très courante dans presque tous les travaux intellectuels :

Les exigences ne sont pas claires, on commence à travailler ;

On dévie en cours de route, on rectifie plus tard ;

Le résultat est moyen, mais ça fonctionne ;

La documentation n’est pas claire, mais tout le monde dans l’équipe comprend ;

On met en ligne d’abord, on corrige les problèmes ensuite.

En d’autres termes, c’est un ensemble complet de méthodes de travail basées sur l’ambiguïté et la flexibilité humaine.

De nombreux projets continuent d’avancer non pas parce que le processus est réellement clair, mais parce que quelqu’un, au milieu, comble les lacunes grâce à l’expérience, les remplacements ou des jugements temporaires.

Ce que Harness est en train de faire est tout le contraire.

Il compresse l’espace d’ambiguïté.

Il compresse l’espace des excuses.

Il compresse l’espace de survie basé sur “je pensais”, “presque”, “ça devrait aller”.

D’abord définir ce que signifie “terminé” à ce stade, puis permettre de commencer ;

Si ce n’est pas satisfaisant, renvoyez-le ;

Si la vérification échoue, continuez ;

Ne vous fiez pas à vos sentiments, exigez des preuves.

Une fois que cette logique commence à avancer, le plus dangereux n’est jamais la personne qui sait le mieux coder, mais celle qui dépend le plus des zones grises pour survivre.

Harness n’absorbe pas les programmeurs, il absorbe d’abord l’ambiguïté.

Tout le monde ne sera pas remplacé, mais chaque poste qui vit de l’ambiguïté sera dévalué en premier.

De nombreux postes dans le passé ont prospéré grâce à un fossé d’information, mais à l’avenir, beaucoup de postes périront à cause de l’écart standard.

05 Pourquoi cela a-t-il explosé maintenant

Beaucoup de gens se demandent pourquoi ce genre de flux de travail a déjà été fait auparavant, pourquoi cette fois-ci, les gens prennent-ils cela au sérieux ?

Parce qu’auparavant, le modèle de base n’était pas assez fort.

Pour être plus franc :

Auparavant, de nombreux cadres de ce type semblaient très beaux, mais fonctionnaient lourdement, et le résultat n’était pas assez solide.

Vous avez empilé une multitude de processus, de rôles et de règles, mais au final, vous n’avez fait que transformer un modèle peu fiable en un système plus complexe mais tout aussi peu fiable.

C’est pourquoi beaucoup de gens ont perdu patience avec les agents, les workflows, les échafaudages.

Ce n’est pas que la direction était mauvaise, mais que le châssis n’était pas à ce stade.

Maintenant, c’est différent.

Une fois qu’un modèle franchit un certain seuil, de nombreux processus qui semblaient auparavant décoratifs commencent à libérer une valeur réelle pour la première fois.

Parce qu’une fois que le modèle de base est suffisamment fort, le processus ne soutient plus un incapable, mais amplifie un système qui peut déjà fonctionner de manière continue.

C’est pourquoi harness semble soudain “un peu réel” maintenant.

Ce n’est pas que son idée est apparue aujourd’hui, mais que le modèle est enfin suffisamment fort pour tirer parti des bénéfices du processus.

Alan a très bien dit :

La capacité du modèle est le moteur, Harness est la transmission.

S’il n’y avait pas de bon moteur, même la meilleure transmission serait inutile.

Mais lorsque le moteur est déjà assez puissant, la transmission commence à décider qui peut aller sur l’autoroute, et qui reste sur place à faire vrombir le moteur.

Donc, ce n’est pas simplement une tendance technique, mais l’industrie envoie un signal plus profond :

La compétition future n’est pas seulement de savoir qui a le modèle le plus fort, mais qui intègre le modèle dans le système de production en premier.

06 “L’humain est supposé être au centre”

Enfin, Alan repose sa tasse et dit la phrase la plus froide de ce jour :

“Avant, les humains surveillaient le logiciel, maintenant c’est le logiciel qui surveille le logiciel.”

Pourquoi cette phrase est-elle si percutante ?

Parce qu’elle révèle que ce que harness réécrit réellement, ce n’est pas un poste, mais une prémisse plus fondamentale, que presque personne n’a remise en question dans le passé :

Dans le travail numérique, il est supposé qu’il y a une personne au centre.

C’est elle qui décompose les tâches,

qui surveille les progrès,

qui juge la qualité,

qui coordonne les retours,

qui garantit la dernière couche.

Cette “personne supposée être au centre”, peut être un programmeur, un PM, un TL, un responsable de design, un QA, ou un chef de projet.

Le nom n’est pas important.

Ce qui est important, c’est que tout le système de production numérique précédent ne peut pas se passer d’un tel centre humain.

Ce que harness touche réellement, c’est cette position centrale.

Il ne dit pas que les humains doivent être immédiatement évincés, mais prouve progressivement que :

Certaines décompositions peuvent être effectuées par le système,

Certaines supervisons peuvent être effectuées par le système,

Certaines validations peuvent être effectuées par le système,

Certaines rétroactions et réessais peuvent également être gérés sans que les humains aient à les découvrir et les traiter d’abord.

Lorsque ces choses sont prouvées de plus en plus, la position des humains ne disparaîtra pas immédiatement, mais commencera à s’enfoncer.

De centre par défaut, elle deviendra une intervention exceptionnelle ;

De surveillance continue, elle deviendra une gestion des problèmes périphériques ;

De maître du processus, elle deviendra observateur du processus.

C’est ce que harness a réellement absorbé.

Ce ne sont pas les programmeurs.

Ce ne sont pas les chefs de produit.

Ce ne sont pas les QA.

Mais l’hypothèse plus profonde derrière ces rôles :

L’humain est supposé être au centre du processus.

Et une fois que cette prémisse commence à s’affaiblir, l’histoire qui s’ensuit sera totalement différente.

À l’ère des outils, la compétition se fait sur qui utilise mieux les outils.

À l’ère de Harness, la compétition se fait sur qui accepte le plus tôt :

qu’il n’est plus naturellement au centre du système.