GDD - l’ère du « développement piloté par le gaslighting »

 (tonsky.me)
12 points par GN⁺ 2025-07-21 | 6 commentaires | Partager sur WhatsApp
  • Ces derniers temps, les utilisateurs d’ordinateurs répètent d’innombrables tâches dénuées de sens indépendamment de leur volonté, en se contentant de suivre ce que la machine leur demande.
  • Les LLM influencent désormais la manière dont les développeurs conçoivent les API, au point que ceux-ci adoptent des fonctionnalités proposées par l’IA, et que certains prédisent bientôt un monde où l’IA écrira la majorité du code.
  • Par exemple, Soundslice a réellement ajouté une fonctionnalité que ChatGPT décrivait à tort.
  • Cela tient au fait que les LLM analysent un grand nombre d’API et proposent donc des conceptions intuitives qui sont celles auxquelles un développeur penserait le plus spontanément.
  • Les LLM ne sont pas adaptés à la mise au point d’idées nouvelles ou d’approches originales, mais dans la plupart des cas, suivre la conception la plus évidente peut s’avérer efficace.
  • Nous entrons désormais dans une époque où l’IA ne se contente plus d’utiliser les outils, mais influence aussi leur conception.

Gaslight-driven development

Des tâches absurdes devenues ordinaires

  • Quiconque utilise un ordinateur depuis dix ans répète sans cesse des actions intrinsèquement inutiles comme créer un compte, valider un e-mail, accepter les cookies ou remplir un captcha.
  • Même lorsque ce n’est pas ce qu’il veut, l’utilisateur n’a d’autre choix que de suivre les instructions de l’ordinateur.
  • À force de ces tâches répétitives, nous nous sommes déjà en partie habitués à une vie où l’on obéit à la machine.

Comment les LLM transforment la réalité du développement

Ce que signifie ce phénomène

  • Il est difficile de juger si cette évolution est positive ou négative.
  • D’un côté, comme les LLM ont appris sur d’innombrables API, ils tendent à proposer ce qui paraît le plus intuitif du point de vue du développeur.
  • C’est aussi une nouvelle manière de tester une API depuis la perspective d’un débutant (newbie’s POV).
    • Autrefois, quand un développeur se trompait, il allait consulter la documentation et corrigeait de lui-même ; désormais, les LLM continuent de fournir des exemples d’usage erronés, ce qui permet aussi aux développeurs d’identifier plus vite les problèmes.

Limites et interrogations

  • Cette approche n’est pas adaptée aux travaux véritablement innovants.
    • Les LLM ne comprennent ni les schémas qui leur sont peu familiers, ni les concepts entièrement nouveaux.
  • Au final, dans des domaines comme les API, la solution la plus banale est peut-être la meilleure.
    • Dans la majorité des situations, plutôt que de concevoir quelque chose de complexe, il est préférable d’opter pour une forme que l’IA comme les développeurs peuvent comprendre intuitivement.

Conclusion : le début d’une nouvelle époque

  • L’IA ne se contente plus d’utiliser les outils qu’on lui donne ; elle commence à avoir son mot à dire sur la manière même dont ces outils devraient être conçus.
  • Et cet avis agit souvent comme une forme de gaslighting sur les développeurs et les organisations, comme si « cela avait toujours été ainsi ».
  • À l’avenir, un développement aligné sur les attentes et le sens commun de l’IA a de fortes chances de devenir une norme naturelle.

À lire aussi

6 commentaires

 
ffdd270 2025-07-21

J’ai parfois l’impression qu’un clou puissant appelé dépendance aux LLM est en train d’être enfoncé dans le grand concept de dépendance au chemin. Le glissement de « parce qu’on l’utilise depuis longtemps » vers « parce que les LLM l’aiment bien »… au final, où cela va-t-il nous mener ?
 
kandk 2025-07-21

C’est quelque chose qu’on utilisait déjà depuis longtemps, et le LLM l’a appris..
 
jujumilk3 2025-07-21

« Vous pouvez maintenant éteindre votre ordinateur. »
 
rosen 2025-07-21

Une métaphore parfaite !!
 
GN⁺ 2025-07-21
Avis Hacker News
  • J’ai imaginé que, lorsqu’un LLM recommande un endpoint API qui n’existe pas, on pourrait l’accepter, implémenter exprès cet endpoint, puis lui faire renvoyer volontairement le code de statut 421: Misdirected Request, ou bien utiliser le vrai 501: Not Implemented ; et si la nuance de 501 ne convient pas, je propose un nouveau code de statut : 513: Your Coding Assistant Is Wrong
    Référence wiki des codes de statut HTTP
    • L’idée de 513: Your Coding Assistant Is Wrong m’a beaucoup fait rire, merci pour ce moment ; cela dit, j’aimerais aussi proposer HTTP 407 Hallucination, pour dire que le serveur comprend bien la requête, mais juge qu’elle ne correspond pas à la réalité
    • Cette histoire m’a aussi rappelé un panneau d’avertissement amusant qui indique que le GPS se trompe
      Exemple « GPS is wrong »
    • Je vote pour l’introduction du statut 513 ; on a déjà le code 418, donc je ne vois pas pourquoi on ne pourrait pas avoir 513
    • Si vous voulez faire ce genre de blague, j’aimerais vraiment que vous utilisiez une réponse 418, j’aimerais le voir davantage adopté
  • Voir en temps réel plusieurs utilisateurs consulter la même page est amusant, mais les indicateurs de personnes qui entrent et sortent sans cesse rendaient la lecture vraiment difficile
    • J’ai un bookmarklet dans ma barre de favoris qui supprime d’un coup tous ces éléments fixes ou sticky ; je m’en sers souvent parce qu’il fait disparaître tous les éléments fixes/sticky de la page et rétablit aussi le défilement
      (code JavaScript fourni)
    • Moi aussi ça me gênait, donc j’ai fait clic droit, Inspecter, puis ouvert les outils de développement pour coller le code ci-dessous dans la console ; cela fait disparaître la zone d’affichage de ces utilisateurs 
      document.getElementById("presence")?.remove();
      Si vous vous demandez pourquoi le cerveau réagit si fortement à ce mouvement, cela a un lien avec l’instinct de détection des prédateurs
      Lien vers l’article scientifique, Référence wiki en neurosciences
    • Ça m’a rappelé le jeu Chess Royale, où j’avais eu une expérience similaire avec les avatars et les drapeaux ; c’était vraiment un jeu très réussi, mais Ubisoft, comme il lui arrive souvent, a fini par fermer le service, ce qui est dommage pour un si bon titre
      Capture d’écran de Chess Royale
    • Il me semble que c’était déjà la page qui avait plein de curseurs en arrière-plan ; à ce stade, on dirait un concept de design volontairement distrayant, presque une blague
    • J’ai essayé de supprimer des éléments de la page avec un outil comme uBlock, mais ça s’est transformé en jeu de taupe où il fallait recommencer sans arrêt
  • Dans Instant, la fonction tx.update gère à la fois l’insertion et la mise à jour des entités, mais le LLM continuait d’écrire du code avec tx.create, alors j’ai fini par créer aussi une fonction tx.create ; je me suis demandé si, dans ce genre de cas ambigu, non seulement les LLM mais aussi de vrais développeurs n’avaient pas déjà perdu inutilement beaucoup de temps
    • De toute façon, si tx.create n’existait pas à l’origine, personne n’aurait eu de temps à perdre, non ?
  • Pour une fonction qui prend en charge à la fois l’insertion et la mise à jour, je pense qu’il serait plus juste de l’appeler put plutôt que update, car update peut prêter à confusion
    • Dans ce cas, upsert me paraît plus approprié
    • Le nom put suggère qu’on écrase le contenu existant, tandis que upsert signifie explicitement insertion/mise à jour
  • Rien qu’à l’idée qu’un LLM produise un mauvais texte et que je doive changer une ligne de code pour ça, j’ai l’impression que l’univers atteindra la mort thermique avant que je le fasse ; je trouve à la fois absurde, comique et inacceptable de devoir modifier du code pour une raison aussi ridicule
  • Je ne suis pas d’accord avec la thèse du post ; je remets déjà en cause le point de départ qui consiste à se demander si nous devons vraiment nous plier à ce que veut l’ordinateur
    À mon avis, si les utilisateurs font une vérification par e-mail ou s’inscrivent, ce n’est pas parce que l’ordinateur l’a exigé, mais parce qu’un humain a fait ce choix de design
    • Je trouve déjà généreux d’appeler cela une « thèse » ; en voyant ce passage, j’ai immédiatement fermé la page
  • J’ai récemment eu une conversation amusante avec mon équipe sur les principes de codage du futur
    Au lieu de se concentrer sur la lisibilité du code, les principes SOLID ou la complexité, il semble qu’il devienne plus important de savoir à quel point l’agentic IDE que j’utilise peut bien indexer le contexte du code, et à quel point le modèle peut bien générer à partir de ce code
    Comme la vitesse de modification du code augmente énormément, la maintenabilité du code pourrait au contraire devenir l’indicateur clé, et nous allons peut-être vers un monde où l’alignement entre prompt et code, ainsi que l’utilisabilité d’un code qui tombe « par hasard » juste, attireront davantage l’attention
  • Si quelqu’un diffusait de manière constante, avec assurance, de nouveaux conseils de développement sur mon produit — faux, en réalité — je me demande si une entreprise ajouterait vraiment simplement ces fonctionnalités imaginaires avant d’écrire un billet de blog outré
    • Je me demande si, en me comportant carrément comme un LLM et en faisant des erreurs absurdes tout en les défendant avec assurance, les autres me comprendraient quand même
    • En y repensant, M. Martin, l’auteur de « Clean Code », n’est-il pas un peu dans ce style ?
    • Si cette personne influençait 90 % de mes clients, alors j’introduirais probablement vraiment ces fonctionnalités imaginaires
    • La plupart des entreprises affirmeraient probablement avec assurance que cette fonctionnalité inutile est absolument indispensable
  • On dirait presque le début d’une belle amitié avec les LLM ; ce qui me frustre le plus comme fractional CTO, c’est que de petits détails comme les conventions de nommage des environnements varient complètement d’un client à l’autre
    Par exemple, dans l’univers AWS on a dev et prod, alors que dans Expo on a test et production, si bien qu’en passant d’un projet à l’autre il faut réfléchir plus qu’on ne le pense
    J’imagine que les LLM rencontrent le même problème, mais à une échelle bien plus grande
    Si l’on pouvait consacrer à des choses réellement utiles les synapses du cerveau gaspillées à cause de cette confusion inutile autour du nommage et du comportement des API, ce serait l’idéal
    • Il y a une blague en informatique selon laquelle il n’existe que trois problèmes difficiles : l’invalidation de cache, le choix des noms et les erreurs off-by-one
      Même si un LLM devient très habile pour nommer les choses, le problème demeure puisqu’il repose sur un incoherent stochastic process
      Et j’aimerais demander si l’on s’est déjà sérieusement interrogé sur la raison pour laquelle les noms d’environnement ne sont pas harmonisés
      En tant qu’ancien CTO, j’y vois un signal qu’il faut améliorer la communication au sein de l’organisation et le manque de standards
      Comme ce sont des points simples à corriger et qu’ils permettent réellement d’améliorer la culture et la conscience collective, j’aimerais dire qu’au lieu de laisser cela au LLM, il faudrait s’en occuper plus directement
  • Lien connexe
    Voir la discussion Hacker News précédente
 
dkmin 2025-07-21

Le succès viral de Soundslice