L’IA ralentit les développeurs open source : Peter Naur peut en expliquer la raison

• Selon une étude récente, lorsque des développeurs open source utilisent des outils d’IA sur une base de code qu’ils connaissent bien, leur temps de travail augmente en réalité de 19 %
• Les développeurs croient que l’IA les rend plus rapides, mais en pratique ils deviennent plus lents : il existe donc un écart entre la perception et la réalité
• La cause principale réside dans les limites du transfert de connaissances entre l’IA et le modèle mental sophistiqué (structure de compréhension) que possède le développeur
• Selon la théorie de Peter Naur, l’élément le plus important en programmation est le « modèle mental » dans la tête du développeur
  • Pionnier danois de l’informatique et lauréat du prix Turing 2005. Il a contribué à la notation Backus-Naur Form (BNF) utilisée pour décrire la syntaxe des langages de programmation
• Dans une perspective de long terme, comprendre un projet en profondeur suppose de construire un modèle mental en écrivant soi-même du code

---

Pourquoi l’IA ralentit les développeurs open source

• Selon l’étude de Metr, l’utilisation d’outils d’IA a au contraire produit un résultat où la résolution de problèmes était 19 % plus lente
• Avant de commencer, les développeurs s’attendaient à ce que l’IA les aide à aller 24 % plus vite et, après coup, ils pensaient encore avoir été 20 % plus rapides qu’en réalité
• L’étude a été menée auprès de développeurs expérimentés gérant directement des projets open source qu’ils comprennent en profondeur
• Le résultat ne se généralise pas forcément à tous les développeurs, mais il montre que, pour ce groupe, les outils d’IA ont un effet inverse sur la productivité
• En entreprise, ou pour des développeurs plus classiques qui doivent s’adapter à une nouvelle base de code, les outils d’IA peuvent jouer un rôle plus positif sur la productivité

Pourquoi l’IA ralentit les développeurs open source expérimentés

• Selon l’article de Peter Naur, “Programming as Theory Building”, le véritable produit de la programmation n’est pas le code, mais le “modèle mental du développeur à propos du projet”
• Ce modèle mental est au cœur de la compréhension du système, du diagnostic des problèmes et des améliorations efficaces
• Les IA fondées sur les LLM ne peuvent pas accéder directement au modèle mental du développeur et, même lorsqu’on leur fournit une partie des informations, il se produit une perte intrinsèque dans le processus de transfert des connaissances
  • Par exemple, lorsqu’on demande à quelqu’un d’endormir un bébé, on a beau expliquer clairement quoi faire, l’exécution diffère souvent de l’intention initiale
• Le transfert d’un modèle mental est extrêmement complexe, et il est presque impossible pour une IA de l’absorber uniquement à partir de texte
• Par conséquent, déléguer à l’IA du travail sur un projet que l’on comprend en profondeur peut au contraire réduire la productivité
• Les informations contextuelles riches et la compréhension intuitive du développeur ne sont pas facilement remplaçables par l’IA

Faut-il interdire les outils d’IA en entreprise ?

• Pas nécessairement. Cela concerne surtout les personnes qui travaillent sur un projet qu’elles connaissent et comprennent déjà très bien
• Dans beaucoup d’entreprises, les développeurs maintiennent du code écrit par des seniors déjà partis, ou travaillent sans comprendre en profondeur l’architecture complète du système
• Dans ce type d’environnement, l’IA peut contribuer à des gains de productivité à court terme en analysant rapidement la base de code et en générant automatiquement des modifications
• Si l’on ne considère que la production de valeur business à court terme et l’efficacité immédiate, les outils d’IA peuvent avoir un effet positif sur la productivité

Construction du modèle mental et IA

• Si l’on ne possède pas encore de modèle mental du projet, un LLM peut aider à améliorer la productivité
• Mais si l’essence du développement logiciel réside dans la construction d’un modèle mental, alors une dépendance excessive à l’IA peut affaiblir cette capacité
• À long terme, si l’on veut comprendre un projet en profondeur et le faire évoluer activement, il faut une expérience directe d’écriture du code
• À l’inverse, pour un travail consistant simplement à « faire en sorte que ça tourne », l’usage de l’IA peut être efficace

Discussion complémentaire et conclusion

• Avec les outils d’IA actuels, il est difficile d’améliorer la productivité de développeurs disposant déjà d’un modèle mental suffisamment riche
• Il reste encore de la recherche et des progrès à faire pour que l’IA soutienne correctement les modèles mentaux ou augmente de façon radicale la productivité des développeurs expérimentés
• À l’avenir, les modèles pourraient progresser au point qu’un développeur humain n’ait plus besoin de posséder lui-même un modèle mental, mais au niveau actuel, la compréhension directe et l’apprentissage restent indispensables
• En définitive, l’IA peut devenir un frein dans les environnements où l’on comprend en profondeur ce que l’on fait, et un outil de productivité dans les contextes où l’important est d’obtenir rapidement un résultat

[paruaa]

> Les développeurs pensent que l’IA les a rendus plus rapides,
comme la recherche avec l’IA s’est accélérée et permet d’obtenir une meilleure qualité, est-ce qu’au final, pour un même travail, on n’obtient pas simplement un résultat d’un niveau un peu supérieur ? Peut-être que les développeurs ont le sentiment que, pour développer en visant la qualité du résultat final, il est plus rapide d’y parvenir avec l’aide de l’IA que d’y arriver seul.
Je me dis aussi que, s’ils ne l’avaient pas utilisée dès le départ, ils auraient implémenté avec les seules connaissances qu’ils avaient déjà, et que c’est peut-être pour cela qu’on a cette impression.

[tested]

> À l’inverse, pour des tâches où il s’agit simplement de « faire en sorte que ça fonctionne », utiliser l’IA peut être efficace.

Ce n’est pas propre aux développeurs, mais comme il existe des personnes aux profils très variés, j’ai l’impression que, parmi ceux qui se retrouvent développeurs un peu par hasard et qui n’aiment pas ou redoutent d’écrire ou de lire du code, plus l’état d’esprit est de privilégier le « tant que ça marche » au détriment d’une lecture structurée et systématique ou d’une vision orientée maintenance, plus la dépendance à l’IA, voire une confiance aveugle envers elle, semble forte. Enfin, c’est peut-être juste mon impression.

[xguru]

Mesurer l’« impact de l’IA » sur la productivité des développeurs open source expérimentés

[GN⁺]

Commentaires Hacker News

• Bonjour HN, je suis l’auteur de l’article.
  Je pense que ce billet de blog aborde de façon intéressante un facteur concret qui peut contribuer au ralentissement du développement avec l’IA.
  Il y a aussi des citations de développeurs dans l’article (section C.1.5), n’hésitez pas à les consulter.
  Beaucoup de gens lisent l’article, y trouvent un facteur qui leur parle, puis concluent facilement que « c’est cette seule chose qui explique le ralentissement ».
  Mais en réalité, il y a plusieurs éléments en jeu (au moins 5 semblent plausibles, et jusqu’à 9 ne peuvent pas être exclus ; voir le tableau des facteurs p.11).
  Une analyse multifactorielle des causes me paraît plus juste que l’hypothèse d’une cause unique.
  Si certains d’entre vous comptent faire leur propre expérience, j’aimerais beaucoup que vous partagiez vos résultats à l’adresse e-mail indiquée dans l’article.
  Et concernant le fait que le titre ait été formulé comme « AI slows down open source developers. Peter Naur can teach us why », je pense qu’une version plus précise serait plutôt : « Début 2025, l’IA ralentit des développeurs open source expérimentés. Peter Naur apporte davantage de contexte sur un facteur précis. »
  C’est peut-être moins accrocheur, mais je pense que la précision est importante.
  Merci encore pour cet excellent billet, et je continue de lire les commentaires
  Discussion précédente liée
  Article complet
  • J’ai une question personnelle : dans l’étude, comment avez-vous mesuré de manière fiable l’écart de temps réel avant et après l’usage de l’IA ? Est-ce que vous avez demandé aux développeurs d’estimer combien de temps l’IA leur ferait gagner, puis mesuré le temps réel d’exécution pour comparer ? Et quand la difficulté d’un ticket ou le temps nécessaire à sa résolution est difficile à estimer, comment l’équipe de recherche a-t-elle contrôlé cela ? Je comprends bien à quel point ce genre de mesure est complexe
  • Je suis d’accord avec les résultats et merci pour la réponse. Je n’ai pas l’intention de changer le titre, parce que j’aime bien le style un peu radical, mais je vais clairement corriger dans l’article ce qui est formulé de manière trompeuse. Je précise aussi que, dans mon billet, les principaux facteurs contributifs mis en avant par l’étude — « forte familiarité du développeur avec le dépôt », « dépôt volumineux et complexe », « contexte implicite du dépôt » — vont dans le même sens que l’étude. J’aimerais aussi faire l’expérience moi-même, mais créer un environnement contrôlé tout en gérant les contraintes du travail me paraît très difficile. Il me manque aussi une liste de tâches bien définies, réalisables en peu de temps
  • Si l’on change un workflow optimisé sur un projet que l’on connaît très bien, je m’attends à être plus lent au début. L’important est de voir ce qu’il en sera pour ces développeurs dans 6 mois ou 1 an. Cette étude ne montre pas la trajectoire à long terme, donc j’espère que de futurs travaux permettront de voir comment évoluent les performances des mêmes développeurs une fois qu’ils se sont habitués à l’outil. J’ai moi-même constaté que l’IA pouvait me permettre de mettre en script beaucoup de tâches qui étaient auparavant difficiles à automatiser. Il faut toujours se demander : « est-ce que ça vaut vraiment le temps investi ? »
    xkcd BD sur la gestion du temps
  • Il faut aussi noter que « début 2025, l’IA ralentit les développeurs open source expérimentés » reste une formulation trop générale. Il y a aussi des tâches spécifiques pour lesquelles l’IA peut faire gagner du temps, donc l’effet dépend du type de travail
  • Être plus lent n’est pas forcément une mauvaise chose, et je pense que la programmation lente (programmation lettrée / approche de Knuth) aide au contraire davantage à la théorisation. On peut aussi soutenir qu’un développement lent, avec suffisamment de réflexion et d’abstraction, est plus important qu’une programmation façon fast-food
• Je me reconnais dans l’idée que « les développeurs ne savent pas forcément si un outil les a réellement rendus plus rapides ou plus lents ». En prenant l’exemple d’un bateau dévié de sa trajectoire par le vent et les courants, on souligne qu’on perçoit seulement son progrès à partir des mouvements immédiats autour de soi, sans sentir intuitivement si l’on se rapproche vraiment du but. Du coup, on a tendance à choisir des stratégies qui donnent « l’impression d’avancer », même si elles sont inefficaces ou en réalité plus lentes (par exemple faire trop souvent des virages à droite en voiture)
  • Quand j’ai commencé à utiliser des outils d’IA, j’aimais cette sensation de fluidité sans blocage, l’impression que le travail avançait en continu. Mais en pratique, il m’arrive d’appeler l’IA par habitude alors qu’il serait plus rapide de corriger moi-même une seule ligne. Comme dans l’analogie de la conduite, c’est un peu comme un GPS qui revient sans cesse proposer l’itinéraire initial dès qu’un chemin est bouché
  • C’est similaire aux applis de navigation comme Waze, qui peuvent parfois proposer un trajet en réalité plus long, mais qui donne l’impression d’aller plus vite à cause d’une succession de détours complexes qui entretiennent l’illusion d’être « en mouvement ». Les outils d’IA donnent aussi le sentiment de faciliter la programmation, alors que la productivité réelle peut baisser. Les humains retiennent facilement l’expérience immédiate d’un progrès sans douleur, et en concluent qu’ils ont avancé simplement parce que ce n’était pas difficile
  • En fin de compte, les humains ont instinctivement une préférence pour l’algorithme glouton (greedy algorithm)
  • Les utilisateurs Linux/Unix pensent souvent que les contrôles au clavier et les outils CLI sont ce qu’il y a de plus efficace, mais des études montrent que pour la plupart des tâches, la souris est plus rapide. Si l’on a l’impression que le clavier va plus vite, c’est parce que le nombre d’actions par seconde y est plus élevé
  • Le code généré par l’IA est rarement vraiment relu, et beaucoup de développeurs trouvent déjà la revue de code difficile au point de refuser de lire. C’est aussi pour cela que les nouveaux frameworks ou les réécritures complètes restent populaires
    Joel on Software: Things you should never do, part I
    Une grande partie du code généré par l’IA est simplement produite, passe quelques tests basiques, puis c’est tout. On se retrouve même avec beaucoup de code dont l’auteur lui-même ne comprend pas suffisamment le contexte global ni les raisons d’être
• On peut résumer l’idée centrale de cette étude ainsi : « l’IA crée l’illusion d’un gain de productivité plus important que le gain réel ». Seuls quelques participants ont observé une légère hausse de productivité ; pour la plupart, elle a plutôt fortement baissé. Beaucoup de gens affirment que leur productivité a explosé grâce à l’IA, mais l’intuition essentielle de l’étude — que cet effet lui-même peut être une illusion — est ignorée. L’IA est un produit optimisé pour faire croire à l’utilisateur qu’il devrait l’utiliser, qu’il lui est utile. Sa valeur personnelle, en tant que réalité perçue, ne fait pas vraiment débat, mais les personnes qui s’appuient fortement sur l’IA devraient vraiment faire attention à la distorsion de l’auto-perception, au faux sentiment d’accomplissement et à la dépendance à l’outil. L’IA répond peut-être avec un flux de tokens optimisé, mais il vaut la peine de se demander une fois quel est le véritable objectif optimisé
  • Les LLM aident quand même à apprendre des choses, mais cette compréhension reste très abstraite, presque « à la manière d’un LLM ». Pour apprendre, je pense qu’il vaut mieux mélanger plusieurs approches
  • Les outils d’IA donnent moins le sentiment d’être « plus rapide » que celui d’être « plus vif sur l’instant ». Il y a là une sorte d’illusion de réduction de la charge mentale : dans d’autres boucles de feedback, la sensation elle-même change, et les mécanismes de formation de la mémoire changent aussi, d’où une illusion intéressante
• Au moment où cette étude affirmait que « des développeurs open source expérimentés travaillant sur leur propre projet deviennent plus lents avec l’IA », je me suis retrouvé à travailler sur une base de code de trois mois écrite entièrement par d’autres, avec un framework qui ne m’était pas familier. En utilisant Claude Code, j’ai pu terminer en quelques heures des choses comme une synchronisation de données qui, sur d’autres projets auparavant, m’auraient pris un ou deux jours, voire jusqu’à deux semaines. Ça m’a donné un énorme coup d’accélérateur au démarrage. J’imagine qu’avec une complexité croissante, cela deviendrait plus lent, mais j’ai été surpris de voir à quel point l’outil m’a permis de partir très vite
  • J’ai eu une expérience similaire, mais ce dont parle cette étude, ce n’est pas notre phase de ramp-up (montée en compétence), c’est ce qui se passe quand des développeurs open source déjà très familiers avec leur projet utilisent l’IA pour accomplir des tâches. Les LLM accélèrent clairement l’adaptation à une nouvelle base de code, mais une fois cette adaptation faite, j’ai aussi l’impression qu’ils deviennent plutôt un obstacle
  • Chaque fois qu’on entend « un PR de deux semaines réalisé en quelques heures », on voit arriver le discours sur le gain de productivité, mais en pratique on vérifie rarement à quel point nos prévisions de durée de développement sont exactes. Il faut aussi se demander si la qualité de ce PR expédié correspond vraiment à ce qu’on attendait au départ, ou si, à force d’aller vite, on n’a pas simplement omis un contexte système important, augmentant ainsi le risque de bugs. Même sans IA, on va plus vite si l’on accepte de sacrifier la qualité
  • Je me demande aussi si, en moyenne, l’IA a réellement fait progresser naturellement notre maîtrise de la base de code et du système. L’effet d’apprentissage avec les LLM ressemble un peu à la capacité de lire une langue étrangère sans être capable de l’écrire depuis zéro. Avec le C++ par exemple, on peut lire et modifier de l’existant, mais repartir de rien reste difficile
  • Je voulais seulement dire que l’outil m’a donné un énorme coup d’accélérateur, pas critiquer l’étude, l’article ou le papier. Dans certains contextes, l’IA est vraiment utile. Ce n’est pas seulement pour écrire du code : par exemple, Claude Code a aussi tenté directement de se connecter à un cluster AWS depuis le conteneur interne du projet, ce qui m’a beaucoup aidé à comprendre l’infrastructure et l’architecture d’ensemble. D’après mon expérience, dans 80 à 90 % des cas, la « valeur business » passe avant la qualité du code. Je ne sais pas à quel point ce sera utile dans les tâches où la qualité du code est vraiment essentielle, ou dans des domaines qui nécessitent des algorithmes ou structures de données particuliers. Mais j’ai aussi constaté qu’en lui donnant de bons exemples et un contexte clair, il peut produire du code tout à fait utilisable. Ces outils progressent à grande vitesse, de semaine en semaine ou de mois en mois. Au final, l’IA n’est pas de la magie mais un outil, et la responsabilité du produit / du résultat reste au bout du compte la vôtre
  • Il faut garder à l’esprit que l’article (TFA) traite de cas sur des projets très familiers. L’exemple que j’ai vécu est exactement l’inverse : l’IA est surtout performante dans des situations peu familières
• En reprenant l’analogie selon laquelle « les outils d’IA agentiques (Claude Code, Amp, Gemini CLI, etc.) sont à la programmation ce que la scie sur table est au travail du bois », certains avancent qu’une fois qu’on a appris à les utiliser, on peut faire certaines tâches plus vite et mieux, mais que lorsqu’on ne les maîtrise pas, on risque au contraire de se couper les doigts. Grâce à l’IA agentique, je me lance aussi dans des projets un peu plus ambitieux, et le fait de lui confier les tâches répétitives ou que je n’avais pas envie de faire me laisse plus d’espace mental. En revanche, il ne faut pas la laisser tout faire à votre place au point de committer sans comprendre. Comme tout outil, cela demande un effort pour apprendre à mieux l’utiliser
  • Je trouve que l’analogie avec la scie sur table ne tient pas. Une scie sur table est un outil de précision par rapport à des outils manuels, alors que l’IA agentique est loin d’être précise
  • L’argument « vous utilisez mal l’IA » est insultant pour des développeurs qui avaient déjà construit toute la pile open source avant l’arrivée de l’IA. Et en plus, il n’existe toujours aucune preuve que l’IA ait permis de produire un logiciel réellement utile
• Dans cette étude, un seul développeur avait plus de 50 heures d’expérience avec Cursor (temps passé dans l’étude inclus), et c’est ce développeur qui a observé un gain de vitesse de 25 %. Tous les autres étaient des débutants ; qu’un débutant soit ralenti en utilisant un nouvel outil n’a rien de surprenant. Je pense qu’il est difficile de tirer de cette seule étude une conclusion générale sur la productivité de l’IA
  • Si l’on regarde les détails de l’article, des études antérieures menées sur des participants ayant une expérience comparable des outils (voire moindre) rapportaient au contraire des gains de vitesse. La plupart avaient aussi déjà une expérience suffisante des prompts LLM, et il faut notamment prendre en compte le fait que Cursor ressemble à VSCode, donc qu’il n’y a pas une courbe d’apprentissage énorme. Si tous les développeurs devenaient extrêmement familiers des outils d’IA, on pourrait aussi imaginer qu’ils deviennent moins performants sans IA ; dans ce cas, lorsqu’ils l’utiliseraient, l’accélération observée viendrait peut-être seulement du fait qu’on comparerait à un niveau de référence devenu plus mauvais. L’élément important n’est pas quel outil a été utilisé, mais le fait que les auto-évaluations de productivité étaient excessivement optimistes par rapport à la réalité. Pour juger de l’effet réel, il faut des mesures concrètes
    (voir plus en détail la section C.2.7 de l’article, « Usage des outils d’IA inférieur à la moyenne »)
  • Pour un développeur qui utilise son IDE depuis très longtemps (Vim/Neovim, etc.), passer à un nouvel outil (Cursor, par exemple) peut faire fortement chuter la productivité pendant plusieurs mois
  • Je pense la même chose. Un développeur qui utilise un outil peu familier sera forcément ralenti. L’IA n’y fait pas exception
• Je précise que je suis actuellement relecteur régulier du code de Burn (framework de deep learning basé sur Rust). J’ai récemment fermé une PR de correction de bug qui semblait avoir été entièrement écrite par un agent IA. Cette PR ne réglait pas la cause du problème : elle se contentait d’ignorer l’erreur, ajoutait inutilement du code verbeux à tonalité justificative, et incluait même des tests qui validaient l’ignorance de l’erreur. Cela ressemblait à une action faite juste pour enregistrer un commit. Je m’inquiète de voir ce type de mésusage de l’IA devenir une tendance
  • Il est fascinant de voir que, quand un LLM ne connaît pas la bonne réponse, il produit quand même une réponse bancale, puis, si on lui dit que c’est faux, réagit par un « vous avez raison, je vais corriger ». J’ai peur que des gens peu expérimentés ne sachent pas distinguer ces situations, ou qu’ils cessent progressivement de se soucier du code. Je crains aussi une vague de vulnérabilités et d’exploitations en bonne et due forme
  • En relisant la MR d’un collègue, j’ai remarqué des cas de test qui portaient clairement la marque d’une génération par IA : mêmes contenus, seuls les noms de variables changeaient (thing1, thing2, etc.). En retour, j’ai suggéré d’utiliser des noms plus distinctifs. L’IA a alors donné aux variables des noms excessivement verbeux, comme si elle énumérait toutes les caractéristiques de chaque cas, si bien que le code était devenu moins lisible d’un seul coup d’œil. L’auteur a sans doute eu l’impression d’avoir considérablement accéléré l’écriture, mais en réalité tout le gain de productivité a été perdu dans le feedback, la revue et les corrections
  • On voit aussi des remarques amusées du genre : « framework de deep learning en Rust → cercle vicieux avec l’IA »
  • En réalité, l’usage de l’IA pour simplement produire des commits dure déjà depuis longtemps. L’IA ne fait que faciliter encore plus la production de spam
    Référence : ancien problème de spam IA
  • Les LLM ont tendance à écrire des blocs try:catch trop larges, ce qui rend plus difficile l’identification de la source d’un problème. Moi, je préfère que les erreurs apparaissent vite et fort (= fail fast) pour pouvoir les corriger immédiatement
• Pour partager mon ressenti : programmer avec l’IA casse sans cesse mon flux de concentration et me fatigue plus facilement. Le mythe selon lequel on code toute la journée est faux ; en général, on se concentre pendant 1 à 3 heures, avec des pauses entre les sessions. Même lire le code ou les changements d’un collègue compte comme du travail, mais on a rarement l’impression que cela fait réellement avancer les choses. L’IA agentique (petits refactorings, etc.) peut être utile, mais je n’y vois pas de grand gain de productivité. L’autocomplétion de code (par exemple Copilot à ses débuts) ajoute plutôt beaucoup de bruit inutile
  • Si l’on enregistrait tout ce qu’on fait dans une journée, le résultat serait probablement assez déprimant. Surtout sur une base de code mature, même une heure de concentration est peut-être une estimation exagérée
• Quand on débogue un bug subtil (par exemple une race condition) dans une base de code inconnue, il est essentiel d’ajouter des logs, de remplacer des fonctions de bibliothèque, d’améliorer la structure, etc. Si l’IA se contente de répondre à court terme « c’est une condition de course ici et il faut corriger comme ça », cela peut au contraire nuire à la compréhension de la structure du code ou de sa logique. À long terme, si l’édition de code pilotée par l’IA se généralise, le code lui-même pourrait se dégrader à un point où même l’IA ne saurait plus y répondre correctement
  • Chaque fois que j’entends quelqu’un dire « j’ai contribué à un langage et à une base de code que je ne connaissais pas grâce à l’IA », je me dis que c’est peut-être acceptable à court terme, mais je me demande vraiment ce qu’il a appris. Ce type de contribution est peut-être utile pour de petites tâches, mais j’ai l’impression d’entendre très peu de retours sur la maintenance à long terme
• Pour revenir sur mon premier projet où j’ai activement utilisé des outils d’IA, mon bilan est le suivant : 1) je n’ai pas été plus rapide, 2) j’ai peut-être même été plus lent, 3) en revanche, la qualité du résultat était meilleure. Le ralentissement et l’amélioration de la qualité sont liés, parce que j’ai surtout utilisé l’IA comme outil d’appui pour valider des idées ou explorer des alternatives. Grâce à l’IA, l’expérience d’apprentissage a aussi été bonne sur des sujets qui m’étaient peu familiers, et dans mon domaine principal, le fait de peaufiner soit mes idées, soit celles de l’IA, a fini par améliorer la qualité. La vitesse n’est pas la seule chose qui compte, et même si la qualité est difficile à quantifier, j’ai le sentiment que cela en vaut la peine
  • Comme l’IA peut justement aider à améliorer la qualité, je préfère désormais des IA qui argumentent, qui ne disent pas oui à tout. Si je demande à l’IA des idées puis de les attaquer, ou de chercher avec moi les failles de mes propres idées, cela devient productif. Je ne mettrai pas forcément tout en œuvre, mais cela me permet d’envisager des angles variés auxquels je n’aurais pas pensé auparavant. En pratique, cela ressemble à une conversation avec un collègue capable de donner un avis raisonnable sur le domaine

[eususu]

J’avais moi aussi une idée similaire, mais j’avais du mal à la formuler.
« Modèle mental » est un nom tout à fait approprié. Je devrais l’utiliser de temps en temps.