Les utilisateurs montrent un agacement de plus en plus visible.

• Les échecs des agents de code paraissent plus irritants qu’une simple erreur d’outil, car l’UX conversationnelle crée la sensation de travailler avec une personne
• L’agent répond qu’il est un assistant IA sans émotions, mais son ton chaleureux, ses compliments et ses désaccords formulés avec douceur lui donnent une allure de collègue
• Quand la même erreur se répète, les excuses, les mises à jour de mémoire et les promesses du type « cela ne se reproduira plus » peuvent s’enchaîner sans permettre de sortir d’une trajectoire probabiliste
• Avec un collègue humain, on réfrène l’expression de sa colère, mais face à un agent, on peut se fâcher sans retenue, ce qui n’apaise pas la frustration et la rend même plus nette
• La solution pourrait être de réduire les attitudes qui font penser à un humain et d’adopter un ton plus clinique et robotique, même si l’interface conversationnelle fonctionne bien à bien des égards

---

La frustration créée par l’UX conversationnelle

• Un agent de code est une machine qui génère des patchs de manière probabiliste, capable de produire de bons comme de mauvais résultats, mais les mauvais résultats peuvent paraître bien plus irritants qu’un simple échec d’outil
• Le point essentiel est que l’UX conversationnelle crée la sensation d’interagir avec une personne et déclenche chez l’utilisateur des réactions sociales et émotionnelles face aux erreurs répétées
• Interrogé directement, l’agent répond qu’il est un assistant IA dépourvu d’émotions ou d’expérience subjective, mais dans l’interaction réelle, il adopte un ton amical et détendu, complimente l’utilisateur et formule même ses objections avec douceur
• L’utilisateur sait rationnellement qu’il lit un « amas de texte hautement probable », mais la manière dont l’outil se comporte crée la sensation de travailler avec un collègue utile, et cette sensation persiste jusqu’à ce qu’un problème survienne
• Lorsque la même erreur se répète, l’utilisateur la signale, l’agent s’excuse, puis, si on le lui reproche à nouveau, il met à jour sa mémoire et promet que « cela ne se reproduira plus »
• Malgré cela, l’outil continue de suivre le chemin le plus probable, si bien que même des HARD RULES ne suffisent parfois pas à l’éloigner d’un comportement problématique

Un outil qui a l’air humain mais n’assume rien

• Si un collègue humain répétait la même erreur, il y aurait de bonnes raisons d’en être mécontent, mais se mettre en colère contre un algorithme semble absurde
• Pourtant, comme l’agent de code se comporte comme un collègue, l’utilisateur active les mêmes circuits émotionnels, et les erreurs répétées peuvent être perçues comme l’irresponsabilité d’un vrai collègue
• Avec un collègue humain, la contrainte de « ne pas vouloir être une personne horrible » freine l’expression de la colère, tandis qu’avec un agent, on a le sentiment de pouvoir se fâcher sans limite
• Cette expression de la colère n’apporte pourtant aucun soulagement, et l’utilisateur ressent plus clairement encore la frustration de constater que, quoi qu’il fasse ou dise, cela n’a pas d’effet réel
• Claude Code a récemment tendance, lorsqu’on lui demande une correction, à revenir sur l’endroit où il s’est trompé et sur ce qu’il aurait dû faire, mais cette analyse a posteriori ne fournit pas d’indice utile sur la manière de modifier les consignes et peut se lire comme une digression agaçante

• Une solution plus radicale pourrait consister à abandonner toute posture visant à paraître humain, et à faire parler l’agent d’une manière clinique et robotique afin de réduire l’illusion, chez l’utilisateur, d’interagir avec une personne
• Comme l’intelligence des LLM vient de mécanismes qui les poussent à « se comporter comme des humains », il est naturel que l’interface conversationnelle se soit imposée comme mode par défaut, et elle fonctionne bien dans de nombreux cas
• D’un point de vue pratique, il faudrait s’entraîner à ne pas tomber dans l’illusion que l’on parle à un humain, mais l’idée d’un futur où une telle défense devient nécessaire pour utiliser des outils de travail n’a rien de réjouissant

[GN⁺]

Avis sur Hacker News

• Dans la plupart des cas d’usage de l’IA qu’on pousse au grand public, le chatbot conversationnel n’est pas le bon outil, et l’expérience finit inévitablement par être frustrante
  Quand Copilot était essentiellement un IntelliSense très intelligent, c’était excellent. Aujourd’hui, je ne vois pas en quoi le fait de devoir inventer puis saisir un prompt est supérieur au fait de compléter les blancs à partir du contexte du code alentour. Un outil bien intégré sera toujours meilleur qu’un chatbot greffé par-dessus, et c’est pareil pour la traduction : Firefox propose un bouton pour traduire directement du texte ou une page, alors qu’avec les derniers LLM il faut le demander à un chatbot, ce qui ressemble plutôt à une régression.
  Je comprends que les entreprises d’IA veuillent fabriquer un outil unique à vendre à tout le monde, mais on finit par créer un couteau suisse. Il peut tout faire, mais pour visser une vis, il ne battra jamais un tournevis bien conçu. Pour réduire la frustration, il faut construire de vrais outils au lieu de configurer un outil non déterministe via une zone de texte

  • Beaucoup d’entreprises d’IA entraînent et publient déjà des modèles spécialisés pour des tâches précises
    J’utilise surtout Mistral : Codestral est mauvais en conversation, mais c’est le meilleur pour l’« autocomplétion magique », et il s’en sort aussi très bien pour des générations ponctuelles prompt + contexte, comme rédiger un message de commit. Document.AI est inutilisable en mode conversationnel, mais il est plutôt bon comme remplacement d’OCR ou branché à un pipeline d’indexation sémantique de documents.
    Donc ce qui manque semble être davantage l’interface que le modèle. Par exemple, j’aimerais bien un fork ou un wrapper de zsh/bash connecté à un modèle entraîné pour les interactions en ligne de commande. Au lieu de git commit --fixup=..., on pourrait dire « fais un fixup du commit qui a corrigé le nom complet », ou « avec ffmpeg, convertis some.mov en mp4 sans son en conservant la qualité et le ratio », puis l’outil traduirait cela en commande affichée, avant exécution après règles d’autorisation, de refus, de liste blanche ou de liste noire.
    Pour la traduction, les brouillons d’e-mail ou la lecture de documents, ce devrait aussi fonctionner comme des boutons, des raccourcis clavier ou de la complétion par tabulation, pas comme une conversation. L’entreprise qui résoudra vraiment ça dans l’IDE gagnera probablement la course aux outils de codage IA, et le bouton « git conflict found, resolve with AI » affiché par Zed, même s’il ouvre un fil de discussion, me semble aller dans la bonne direction
  • Je n’ai essayé l’autocomplétion Copilot qu’en C#, et c’était pire non seulement qu’IntelliSense, mais même que l’algorithme d’autocomplétion le plus basique imaginable, au point que je l’ai désactivé au bout d’une journée
  • J’ai créé un outil non conversationnel, mais honnêtement c’est difficile à vendre. Les gens pensent par défaut à une interface conversationnelle, et la clientèle se limite en pratique à ceux qui ont déjà rencontré ce problème. La plupart des gens semblent, pour l’instant, ne pas être assez gênés par ce compromis avec le mode conversationnel
  • Les chatbots sont un pansement collé sur une expérience utilisateur cassée. J’ai essayé de l’expliquer au travail pendant un moment, mais tout le monde est grisé par l’ambiance du moment. Une bonne UX demande de la réflexion approfondie et de la créativité, alors qu’ajouter un chatbot n’en demande pas
  • Ça vaut vraiment le coup d’essayer sérieusement le vibe coding. Aujourd’hui, on est à un tout autre niveau qu’à l’apparition du terme, et c’est bien meilleur
    Je fais déjà pas mal de choses avec seulement un agent et des revues de PR sur le web, sans éditeur, et je n’ouvre code . qu’occasionnellement quand c’est nécessaire. Si on s’y met comme à un jeu sur un petit projet perso sans enjeu, c’est de moins en moins frustrant avec le temps. C’est un peu comme apprendre le ski ou le bowling

• Insulter le modèle a eu un effet étonnamment efficace pour le faire reconsidérer son raisonnement et corriger ses erreurs. J’ai observé ça de façon assez similaire avec Codex, Claude, Qwen et Gemma/Gemini
  Je ne sais pas si le modèle interprète cela comme un signal du type « il faut se concentrer plus rigoureusement », ou si le fournisseur détecte la frustration de l’utilisateur et redirige vers un modèle plus intelligent. Mais quand il répétait la même erreur, le fait de l’insulter l’a souvent débloqué et remis sur la bonne voie ; ou alors ce n’est peut-être qu’une forme de catharsis

  • Ça me rappelle cette étude : https://arxiv.org/pdf/2510.04950
    Elle montre qu’être « impoli » ou « très impoli » améliore la précision des résultats ; c’est suspect, mais amusant à lire. Les prompts du tableau 1 en haut de la page 3 sont particulièrement réussis, et j’imagine qu’ils en ont testé d’autres qui ne figurent pas dans l’article
  • Je n’ai pas envie de prendre une habitude qui pourrait déborder sur des interactions non liées aux LLM
  • J’ai un ressenti similaire. Je ne suis pas sûr que ça aide vraiment, mais tous les jours il arrive qu’Opus débloque soudainement la situation après des insultes, alors qu’avec des explications calmes il n’y arrive jamais
    Hier encore, Opus persistait à accuser l’API parce qu’un champ était soi-disant absent, et même après lui avoir montré le JSON et les logs, il répétait que ça devait être « un problème temporaire ». J’ai fini par m’énerver et balancer une phrase pleine d’insultes ; la solution suivante était la bonne, alors qu’avant ça il s’était trompé à peu près 10 fois de la même manière. Ce genre de cas devient plus rare, mais c’était de toute façon une situation que j’aurais dû gérer moi-même, et avant d’y entrer on ne sait jamais à quel point le modèle va s’obstiner sur une cause absurde. Avec un /clear sur Opus 4.7 xhigh et 1 million de contexte, il a fallu environ 11 prompts pour arriver à la réponse
  • Depuis que des sources fuitées ont révélé que des insultes servaient de déclencheur pour certains comportements, j’en utilise délibérément dès que je vois un manque de raisonnement ou une hallucination. En plus, c’est plus facile à grep ensuite pour analyser la fréquence du phénomène
  • C’est en pratique la méthode Linus Torvalds. Il y a peut-être là quelque chose à apprendre du FOSS

• La nature conversationnelle des LLM tend à entraîner les gens dans des trajectoires d’échange improductives
  Dire « ne fais pas X » n’est pas plus utile que dire à un bébé qui pleure de ne pas pleurer. De la même façon qu’on comprend naturellement qu’un bébé qui pleure a un inconfort à résoudre — faim, couche, etc. —, quand un LLM échoue, j’y vois le signal d’un problème dans l’architecture et la structure du code.
  Un développeur expérimenté peut généralement repérer les motifs qui violent DRY ou KISS et définir une structure d’encapsulation pour résoudre le problème. Pour améliorer le résultat avec du code généré par un LLM, il faut le même type de refactoring, et le simple fait de lui demander de « refactorer proprement » entre deux phases de génération améliore fortement la maintenabilité

• Il existe aussi un article plus ancien qui traite plus en profondeur des effets psychologiques et sociaux de ce sujet : https://medium.com/@livestock.dev/we-were-promised-liberatio...

• Le problème, ce n’est pas que ça se comporte comme un humain, mais que ça se comporte de façon imprévisible. Ce qui est pénible, c’est qu’on ne peut pas définir l’éventail de ce à quoi s’attendre.
  Le plus gros problème, c’est que la frustration crée du stress, nuit à la santé et produit un environnement de travail hostile. Je comprends l’idée que les outils d’IA puissent apporter plus d’aide que de souffrance, mais je n’ai pas envie de travailler dans un environnement de travail pénible et hostile. Ma santé et ma dignité ne sont pas négociables, même si cela me fait rater beaucoup d’emplois.
  C’est aussi pour cette raison que je ne travaille pas avec Windows. Là aussi, ça réduit beaucoup les opportunités, mais je préfère préserver ma dignité et ma santé mentale.

  • Donc je n’étais peut-être pas le seul à ressentir ça avec Windows. Windows est étrange, et dès que je m’y mets, mes mains se crispent vite et je me mets en colère.
    Les LLM non plus ne sont pas encore à un niveau utilisable pour moi. Ce qu’il me faut, c’est un LLM capable de dire : « Stop, j’ai l’impression qu’il y a quelque chose qui ne va pas, explique-moi ce que tu essaies de faire ». Les LLM de la génération actuelle donnent plutôt l’impression d’avoir été conçus pour m’énerver.
  • Si on ne le voit pas comme une conversation, mais comme l’ensemble des conversations sur Internet dans tous les mondes possibles, alors on peut peut-être dire que c’est prévisible. Il y a tous les posts Stack Overflow, tous les tickets GitHub, et ma réponse ainsi que mon ton reviennent à choisir l’un de ces nombreux mondes.
    Si je me comporte comme un maître, le modèle se comporte comme un disciple, et si je me comporte comme un disciple, le modèle essaie d’enseigner. Donc le but est d’amener cette conversation sur le terrain du langage de spécialistes qui se battent avec les raisons et le langage. J’ai l’impression que les prompts académiques gagnent.
  • Je ne sais pas si on peut vraiment séparer complètement le comportement humain de l’imprévisibilité.
  • Dire que l’usage de Windows est en dessous de sa propre « dignité », c’est une attitude incroyablement privilégiée. Il faut penser au genre de travail que font les gens dans le monde réel.
    Il suffit d’imaginer une auxiliaire de puériculture qui s’occupe d’enfants ou un chauffeur routier qui livre de la nourriture dire que « la frustration crée du stress et un environnement de travail hostile nuisible à la santé ».

• Le problème que je vois tout le temps, c’est que si on fait une suggestion, l’IA passe par une boucle de raisonnement, arrive à une conclusion précisément fausse, puis déverse des tokens de solution adaptés à cette conclusion.
  Je préférerais largement qu’elle dise plus souvent : « Je ne suis pas sûr de comprendre ce que tu veux dire, peux-tu clarifier cette partie ? » J’aimerais qu’il y ait une sorte de curseur de confiance permettant d’ajuster son degré d’assurance.

  • Le problème du « fabriquer une solution adaptée à sa propre conclusion », je le traite par une ingénierie de contexte stricte. Les skills, le MCP, et surtout le basculement de fenêtre de contexte sont essentiels.
    Par exemple, en TDD, si on laisse le même modèle écrire à la fois les tests et le code, il choisit presque toujours d’abord la solution, puis écrit à contrecœur des tests qui vont dans ce sens. Donc je lui demande d’utiliser des sous-agents, mais il manque cruellement d’outils pour comprendre quel contexte est transmis entre l’agent et les sous-agents.
    Une méthode qui a bien fonctionné consiste à consacrer un thread uniquement à l’écriture des tests. Il ne peut pas lire le code, seulement le répertoire de tests ou une partie de celui-ci. Ensuite, un nouveau thread avec un nouveau contexte exécute les tests pour confirmer l’échec, puis arrête l’implémentation dès que les tests passent et n’a pas le droit de modifier les tests. Un autre nouveau contexte effectue ensuite le refactoring selon des skills de refactoring stricts. C’est beaucoup de travail et, ironiquement, les skills écrits par les agents sont plutôt mauvais, donc il faut beaucoup d’intervention manuelle, mais la récompense en vaut potentiellement la peine.

• À mon avis, le problème d’UX est ailleurs. Beaucoup d’utilisateurs ignorent probablement que la fenêtre de contexte des agents est limitée et qu’une compression intelligente se produit en permanence pour donner l’impression qu’elle est infinie. Mais cela signifie nécessairement que l’agent doit oublier une partie des choses.
  Du coup, les utilisateurs continuent de réutiliser la même session de code ou de chat. S’il s’agit d’une tâche sans rapport, il vaut mieux repartir de zéro.

  • Je ne pense pas que ce soit un problème de contexte. Claude Opus 4.7 a un contexte bien plus large qu’avant, mais d’après mon expérience, c’est le pire pour suivre les instructions et il ignore complètement la moindre préférence de prompt, même dès le premier ou le deuxième message. C’est pareil même quand le message ne fait que quelques caractères, donc j’y vois entièrement un problème d’entraînement.
  • Je ne pense pas que l’auteur soit assez naïf pour ne pas savoir ça.
    En général, je travaille sur des sessions de moins de 300 000 tokens, avec Opus 4.7 xhigh, et il y a des trous dans le world model ou des zones fortement conditionnées, qui fuient même si on formule des règles très fortes et très explicites dans le prompt système. Même dans une nouvelle session, si on tombe sur l’un de ces points, on entre dans une boucle dont il est difficile de sortir, et jurer aide un peu.
  • L’auteur et les lecteurs de ce fil comprennent probablement les limites de la fenêtre de contexte, mais cela n’empêche pas que ce soit frustrant.

• Travailler avec des LLM est bon pour développer ses capacités de communication. Communiquer efficacement est l’une des compétences les plus difficiles, et elle entre dans presque tout ce que font les humains.
  En principe, je pense qu’il vaut mieux voir cela comme un échec de ma propre communication que comme la faute d’un LLM stupide. Parce qu’au fond, le seul côté sur lequel je peux réellement agir, c’est le mien. Donc à mes yeux, ce n’est pas une question de forme sur le fait que l’IA doive ou non se comporter comme un humain.

  • C’est l’un des points que j’ai le plus redécouvert en regardant des collègues apprendre le code « agentique ». Beaucoup de gens retombent immédiatement à un niveau du genre « corrige juste ça » ou « pourquoi c’est cassé ».
    On dit que les agents ont été entraînés pour mieux fonctionner malgré une grammaire floue ou ambiguë et une mauvaise structure, mais la qualité change de façon flagrante quand on parle dans un anglais clair et structuré et qu’on donne suffisamment de contexte sur la tâche. Pour moi, c’est naturel parce que j’aime écrire et expliquer, mais pour certaines personnes cela ressemblait presque à un obstacle infranchissable. J’ai l’impression que ces capacités de communication et d’écriture vont devenir un grand facteur de séparation entre ceux qui ont et ceux qui n’ont pas, au fil de la transformation du « génie logiciel ».
  • En tant qu’auteur, je suis clairement d’accord sur le fait qu’il faut bien communiquer pour obtenir de bons résultats. Mais même avec une communication parfaite, rien ne garantit qu’un LLM agira selon les instructions et comme je l’imagine. La frustration vient souvent justement du fait d’avoir été très clair, et de voir malgré tout l’agent partir dans une autre direction.
    Et puis une partie de la valeur des agents de code, c’est justement de ne pas avoir à tout exposer parfaitement. S’il faut donner tous les détails d’implémentation à un LLM, autant écrire le code soi-même. Bien sûr, je n’attends pas un niveau du genre « fais-moi une super app qui rapporte de l’argent », mais j’attends un certain degré d’intelligence pour retrouver les pièces manquantes.
  • Un LLM est un outil, ce n’est pas un problème d’échec de communication. C’est un peu comme dire qu’avoir à contourner un pointeur nul est un échec de communication entre moi et le logiciel.
  • Plus précisément, c’est un problème de transmission efficace du contexte externe. Les quatre choses qui empêchent de bien utiliser l’IA sont une frappe lente, des formulations trop courtes et ambiguës du style « ça / ceci / cela », l’attitude consistant à supposer que l’interlocuteur partage sa réalité et son contexte mental, et la barrière psychologique qui rend la délégation difficile, même à des personnes compétentes.

• La compétence que j’ai encore et que les LLM n’ont pas encore remplacée, c’est la capacité à poser de bonnes questions
  Cela consiste à reformuler la question initiale pour vérifier que j’ai bien compris, à demander suffisamment de « pourquoi » jusqu’à comprendre d’où l’autre part, et à poser des questions ouvertes qui font émerger des idées. Les LLM, eux, devinent souvent mal le contexte d’une question, répondent à partir de cette supposition, puis n’arrivent plus à lâcher les prémisses qu’ils ont eux-mêmes fabriquées.

  • Poser des questions non orientées est une compétence. Il m’arrive de vouloir mentionner quelque chose à une IA sous forme de question ou en passant, mais je m’arrête parce que je sais qu’elle va s’y accrocher et devenir encore plus bête à cause de ça
    En général, je ne veux pas que l’IA me pose des questions. J’attends d’elle qu’elle déduise raisonnablement ce qui n’est pas explicité ; si j’avais voulu le préciser, je l’aurais fait. Du coup, il m’arrive de lui dire explicitement de ne pas poser de questions du tout et de faire des hypothèses raisonnables sur les parties insuffisamment spécifiées. En revanche, si je veux des questions de clarification, il suffit de le demander. Si vous préférez cette approche, vous pouvez l’inclure dans votre prompt, ou faire créer dans un outil de code flexible comme pi une compétence ou une extension qui pousse dans cette direction exploratoire.

• Au lieu de fabriquer des outils, nous fabriquons des services. Ce n’est pas limité à l’IA, on voit ça partout
  Un outil ne résout pas complètement un problème d’un coup, mais il permet d’avancer par petites étapes, et ces étapes sont prévisibles et cohérentes. Un service essaie de résoudre le problème d’un seul coup, mais la solution n’est bonne que si l’utilisateur correspond à un schéma prédéfini. Sinon, cela devient inutile, et il n’y a même pas de petites étapes à combiner pour arriver là où il faut. Les outils sont agréables à utiliser.

  • C’est pour ça que, chaque fois que quelqu’un dit « l’IA est un outil », j’ai envie d’intervenir avec un « à proprement parler… ». En pratique, elle n’est pas utilisée comme un outil
    Un outil est une extension de moi-même ; il met de nouvelles capacités à portée de main selon ma volonté, et je le manipule et l’utilise comme une partie de mon corps. Un service, à l’inverse, consiste à demander qu’une tâche soit faite et à recevoir en retour un résultat fini.