La spécification, c’est le produit

Le coût de construction vient de chuter d’un ordre de grandeur. Tout le monde en parle. Presque personne ne parle de ce que cela exige réellement de nous.

Ceci est le premier texte d’une série sur les compétences qui comptent maintenant. Pas des compétences de développeur. Des compétences humaines. Celles qui déterminent si l’IA nous rend plus capables ou simplement plus productifs à construire la mauvaise chose.

Nous commençons par la plus importante : la spécification. La capacité de décrire ce que vous voulez assez clairement pour qu’une chose incapable de lire vos pensées le construise correctement. Tout le reste en dépend.

La confusion la plus coûteuse

Une analyse de CodeRabbit portant sur 470 pull requests GitHub a révélé que le code généré par l’IA produit 1,7 fois plus d’erreurs de logique que le code écrit par des humains. Pas des erreurs de syntaxe. Pas des problèmes de formatage. Le code fait la mauvaise chose correctement. Il construit exactement ce qui a été demandé, et ce qui a été demandé est erroné.

Ce n’est pas un problème d’IA. C’est un problème de spécification. Et c’est la confusion la plus coûteuse de l’industrie en ce moment, parce que le coût de construction est tombé à presque rien tandis que le coût de construire la mauvaise chose est resté exactement où il était.

Quand l’exécution coûtait cher, les mauvaises specs étaient survivables. Le processus lent et itératif de développement logiciel créait des points de contrôle naturels. Vous décriviez quelque chose vaguement, un développeur l’interprétait, en construisait un morceau, vous le montrait, et vous disiez « non, pas comme ça, comme ceci ». Le coût de ces allers-retours était caché dans le coût de l’exécution. Personne ne le remarquait parce que personne ne le mesurait séparément.

L’IA a supprimé les allers-retours. Elle prend la spec et fonce. Elle ne s’arrête pas pour demander si c’est vraiment ce que vous vouliez dire. Elle ne remarque pas que votre spec se contredit au troisième paragraphe. Elle construit, avec assurance et rapidité, exactement ce que vous avez décrit. Et si ce que vous avez décrit était erroné, vous voilà avec un monument magnifiquement conçu à la gloire de votre propre ambiguïté.

Il existe un plafond dur qui rend cela concret. La recherche suggère que les modèles de langage de pointe suivent de manière fiable environ 150 à 200 instructions avant que l’adhérence ne se dégrade. Ce n’est pas beaucoup. Un brief de projet typique, combiné au contexte système et aux configurations d’outils, peut facilement dépasser ce budget. Quand c’est le cas, le modèle commence à sauter les étapes qui comptent le plus : les étapes collaboratives, les questions de clarification, les parties qui auraient détecté le désalignement tôt. La spécification ne doit pas seulement être claire. Elle doit être assez concise pour tenir dans le budget d’attention du système qui l’exécute.

Le piège du savoir tacite

Voici pourquoi c’est si difficile. La plupart d’entre nous ne savons pas vraiment ce que nous voulons avant de voir ce que nous ne voulons pas.

Pendant des décennies, les organisations ont fonctionné sur le savoir tacite : cette compréhension non écrite de ce à quoi ressemble le « bon », qui vit dans la tête des personnes d’expérience. La gestionnaire de produit sénior qui regarde une spec et dit « ça ne marchera pas » sans pouvoir pleinement articuler pourquoi. Le responsable d’ingénierie qui rejette une architecture parce qu’elle « ne sonne pas juste ». La designer qui sait que la mise en page cloche avant même de pouvoir nommer le principe qu’elle viole.

Ce savoir est réel. Il a de la valeur. Et il est complètement invisible pour l’IA.

L’IA force le savoir tacite à devenir des standards explicites. C’est ça, le basculement, et il est franchement douloureux, parce que la plupart des organisations n’ont jamais eu à articuler ce qu’elles entendent vraiment par « bon ». Elles comptaient sur les personnes d’expérience pour porter cette compréhension implicitement. Maintenant, ces personnes doivent l’externaliser, transformer l’instinct en langage, transformer « je le reconnais quand je le vois » en quelque chose d’assez concret pour être spécifié, testé et vérifié.

Ce n’est pas un défi technique. C’est un défi de pensée. Et il concerne tout le monde, pas seulement les développeurs.

Ce n’est pas une compétence de développeur

Une gestionnaire de produit qui décrit une fonctionnalité à un agent d’IA a besoin de la même compétence qu’un développeur qui rédige un fichier de spécification. Un directeur marketing qui briefe un outil de contenu IA en a besoin. Une fondatrice qui explique sa vision à une équipe de bâtisseurs assistés par l’IA en a besoin. Un responsable des opérations qui définit un flux de travail pour un système automatisé en a besoin.

La compétence est la même partout : pouvez-vous décrire le résultat que vous voulez assez clairement, assez complètement et assez précisément pour qu’une chose incapable de lire vos pensées le produise?

La plupart d’entre nous sommes moins bons à cet exercice que nous le pensons. Nous avons passé nos carrières dans des environnements où les humains autour de nous comblaient les vides. Un collègue qui comprenait le contexte. Une équipe qui partageait des hypothèses tacites. Une culture qui portait des standards non dits. L’IA n’a rien de tout cela. Elle a exactement ce que vous lui avez donné, et elle exécutera exactement cela, ni plus ni moins.

Microsoft a suivi 300 000 employés utilisant des outils d’IA. L’enthousiasme a culminé dans les trois premières semaines. Puis la plupart des gens ont discrètement cessé de les utiliser. Les survivants n’étaient pas les plus techniques. C’étaient ceux qui avaient appris à articuler ce qu’ils voulaient avec assez de précision pour que l’outil puisse réellement le livrer.

Les 80 % qui ont abandonné ne manquaient pas d’intelligence. Il leur manquait une compétence que personne ne leur avait jamais demandé de développer : convertir la chose dans leur tête en une spécification assez claire pour une machine qui prend tout au pied de la lettre.

La bonne nouvelle

La spécification est une compétence qui s’apprend, et elle progresse plus vite que la plupart des gens ne s’y attendent. La meilleure spécification, il s’avère, n’est pas la plus détaillée. C’est celle qui ne laisse aucune place à la mauvaise interprétation.

Cinq choses à retenir :

1. Décrivez d’abord le terminé. Trois phrases. Pas le processus. Le résultat. Si vous ne pouvez pas décrire le terminé, vous n’êtes pas prêt à commencer.
2. Nommez vos contraintes. Chaque hypothèse non formulée est un vide que la machine comblera avec son propre jugement. Souvent plausible, et erroné.
3. Spécifiez ce que vous ne voulez pas. « Ne réorganise pas le code existant » fait gagner plus de temps que la plupart des instructions positives. Les humains infèrent les limites. L’IA, non.
4. Testez d’abord sur un humain. Si quelqu’un sans contexte ne peut pas comprendre votre spec sans poser de questions, elle n’est pas prête pour l’IA.
5. Corrigez la spec, pas le résultat. Chaque résultat raté est un miroir qui vous montre ce qui manquait à votre spécification.

Mais le changement profond n’est pas une technique. C’est une habitude d’esprit : apprendre à remarquer l’écart entre ce que vous vouliez dire et ce que vous avez dit. Une équipe chez HumanLayer a développé ce qu’elle appelle un artefact de « discussion de conception » : un document de 200 lignes où l’IA externalise tout ce qu’elle pense que vous voulez, pose des questions sur ce qu’elle ne sait pas et expose ses hypothèses avant d’écrire une seule ligne de code. C’est, en somme, une chirurgie du cerveau sur la compréhension de l’agent avant de le laisser continuer. Le document n’est pas du code. C’est de l’alignement. Et il attrape les mauvaises décisions sur un document de 200 lignes au lieu de les découvrir après 1 000 lignes d’implémentation.

Cet écart entre ce que nous voulions dire et ce que nous avons dit a toujours existé. Il n’a simplement jamais compté autant, parce que des humains le comblaient pour nous.

L’économie de la spécification

Voici le motif plus large. Dans l’ancienne économie, l’exécution était le goulot d’étranglement et la spécification était gratuite. N’importe qui pouvait avoir une idée. Le difficile, c’était de la construire. Dans la nouvelle économie, l’exécution approche de la gratuité et la spécification est le goulot d’étranglement. N’importe qui peut construire. Le difficile, c’est de savoir quoi construire, et de le décrire assez précisément pour que la construction produise ce que vous vouliez vraiment.

C’est pourquoi le marché de l’emploi se scinde en forme de K. Les rôles qui montent sont ceux qui reposent sur le fait de savoir quoi construire : pensée produit, jugement architectural, cadrage de problème, standards de qualité. Les rôles sous la plus forte pression sont ceux définis entièrement par l’exécution de la spécification de quelqu’un d’autre. Non pas que les gens dans ces rôles manquent de talent, mais parce que l’économie de l’exécution a changé sous leurs pieds.

La compétence qui fait le pont, c’est la spécification. Ce n’est pas glamour. Ça ne fera jamais tendance sur LinkedIn. Mais c’est la capacité au plus fort levier qu’une personne puisse développer en ce moment, parce que c’est la couche de traduction entre l’intention humaine et l’exécution machine. Réussissez-la et l’IA multiplie tout ce que vous savez. Ratez-la et l’IA devient un moyen très rapide d’arriver à la mauvaise destination.

Les outils sont prêts. La question est de savoir si nous pouvons décrire, avec assez de clarté et de précision, ce que nous voulons vraiment qu’ils construisent.

Ceci est le premier texte du « Guide du voyageur galactique de l’économie en K », une série sur les compétences humaines qui comptent le plus à l’ère de l’IA. À venir : « L’écart du goût », sur le jugement, l’évaluation et l’art de savoir si le résultat est vraiment bon.