Je pense que de nombreuses entreprises sombrent actuellement dans une psychose collective autour de l’IA
(twitter.com/mitchellh)- Mitchell Hashimoto : « De nombreuses entreprises sont actuellement plongées dans une grave psychose collective autour de l’IA, et il est impossible d’avoir avec elles une conversation rationnelle »
- Le débat MTBF vs MTTR de l’ère de l’automatisation de l’infrastructure cloud s’étend désormais à l’ensemble de l’industrie du développement logiciel, et la foi aveugle dans les agents IA engendre une nouvelle forme de folie collective
- Le dogme du MTTR comme solution universelle se répand, avec l’idée que « l’agent corrigera rapidement les bugs, donc ce n’est pas grave de livrer avec des bugs », une façon de penser dont l’échec a déjà été démontré à l’époque de l’infrastructure
- Un système peut sembler sain sur des métriques locales tout en se transformant globalement en quelque chose d’incompréhensible, et la baisse des bug reports comme la hausse de la couverture de tests ne garantissent pas une sécurité réelle
- Quand on soulève directement le problème, la conversation est bloquée par des contre-arguments immédiats du type « on a 100 % de couverture de tests » ou « les bug reports diminuent », sans vision d’ensemble
- Le rythme du changement est si rapide que personne ne perçoit l’érosion de l’architecture sous-jacente, tandis qu’on construit une « machine à désastres résiliente » automatisée
Argument central : la psychose collective autour de l’IA (AI Psychosis)
- De nombreuses entreprises se trouvent aujourd’hui dans un état grave de psychose collective autour de l’IA, au point qu’une conversation rationnelle avec elles est impossible
- Il ne peut pas citer de noms, notamment parce que cela inclut des amis qu’il respecte profondément à titre personnel
- Il exprime une vive inquiétude quant à la manière dont cette situation pourrait évoluer
La leçon de l’ère de l’infrastructure : MTBF vs MTTR
- Le débat MTBF (temps moyen entre pannes) vs MTTR (temps moyen de rétablissement), déjà vécu pendant la transition vers le cloud et l’automatisation du cloud, refait surface
- À l’époque, il restait cantonné à l’infrastructure ; aujourd’hui, il s’étend à toute l’industrie du développement logiciel (voire au monde entier)
- Les partisans les plus fervents de l’IA raisonnent presque de manière absolue selon l’idée que « le MTTR suffit »
- Selon cette logique, « puisque les agents corrigeront les bugs à une vitesse et à une échelle impossibles pour les humains, on peut se permettre de livrer avec des bugs »
- Leçon apprise à l’époque de l’infrastructure : le MTTR est excellent, mais on ne peut pas abandonner complètement la conception de systèmes résilients
Blocage du dialogue et schémas de réponse
- Lorsqu’il soulève ce sujet auprès de personnes qu’il connaît personnellement, il se heurte à un rejet immédiat
- Avec des réponses comme « non, la couverture de tests est totale » ou « les bug reports diminuent »
- Or ces objections ne montrent pas l’ensemble du tableau
- Il a déjà exprimé directement ses inquiétudes en privé, sans être entendu, et juge important de les partager plus largement
La machine à désastres automatisée
- Une leçon déjà apprise dans l’infrastructure : l’automatisation peut permettre de construire une « machine à désastres très résiliente »
- On voit apparaître des systèmes qui semblent sains sur des métriques locales tout en devenant globalement incompréhensibles
- Les bug reports diminuent, mais les risques potentiels explosent
- La couverture de tests augmente, mais la compréhension sémantique recule
- Les changements vont si vite que personne ne remarque l’érosion de l’architecture sous-jacente
Points soulevés dans les principales réponses
- @adamhjk : « Ce que le vibe coding pur détruit en premier, c’est l’architecture elle-même » ; encore faut-il qu’il y ait une architecture pour pouvoir détecter son érosion
- Précision supplémentaire de Mitchell Hashimoto : dans l’infrastructure, on peut mettre à jour un système en ligne et appliquer le MTTR à tous les utilisateurs dans un délai raisonnable, mais cette logique ne fonctionne pas pour des logiciels que d’autres intègrent ou exécutent directement, comme les bibliothèques, logiciels desktop et applications mobiles
- @tinygrad : nous sommes entrés dans une époque où il faut 20 minutes plutôt que 10 secondes pour déterminer si ce qu’a dit une IA est totalement faux, et les organisations doivent conserver un ancrage dans la réalité
- @beyang : l’UX actuelle des agents fait de « LGTM (Looks Good To Me) » le chemin de moindre résistance, et la vitesse à laquelle les agents produisent du code apparemment plausible transforme le problème de vérification en code review en menace immédiate
- @beh_zod : la fonction de récompense du shipping est courte, tandis que le temps nécessaire pour prendre conscience de la dette accumulée dépasse la plupart des capacités d’attention
- @shipwithjay : c’est un symptôme lorsque le leadership engineering reste silencieux et ne sait pas répondre à des questions contrefactuelles (« qu’est-ce qui devrait être vrai pour que nous arrêtions cela ? »)
- @chadfowler : il écrit un livre sur ce sujet ; l’idée centrale est de repositionner la rigueur (rigor) dans l’architecture et les systèmes d’évaluation, et le moment est venu de mettre en œuvre des bonnes pratiques longtemps repoussées faute de temps et de budget
Réponses de Mitchell Hashimoto aux questions et avis des gens
- Q : « Que faut-il faire à la place ? »
- R : « Réfléchissez (utilisez l’IA, mais réfléchissez) »
- Q : il estime qu’il est encore plus probable que l’idée selon laquelle « l’IA est surestimée » soit elle-même un symptôme plus psychotique encore
- R : toutes les tendances séculières sont surestimées, mais cela ne justifie pas de les rejeter en bloc
- Q : « S’il faut choisir entre protéger ce que l’on a maintenant et sauter dans le risque, je choisirai la seconde option »
- R : ce n’est pas un interrupteur binaire
1 commentaires
Commentaires sur Hacker News
Le conseil en architecture IA va probablement devenir une forme majeure de conseil à forte valeur ajoutée, un peu comme la réponse aux incidents de sécurité ou les experts en récupération de données
Les systèmes écrits uniquement par l’IA peuvent croître jusqu’à un niveau de complexité que les humains ne comprennent plus, le taux de correction des défauts diminue tandis que le nombre de tokens consommés par défaut augmente, et au final les modifications faites par l’IA peuvent créer plus de défauts qu’elles n’en corrigent, rendant l’ensemble instable
Il faudra alors sans doute une procédure spécialisée pour remettre ce chaos au propre comme dans une clean room, en extraire les principes de conception fondamentaux, puis probablement tout reconstruire en utilisant encore l’IA
L’ingénierie logicielle du futur se concentrera sans doute sur les principes permettant d’éviter cela dès le départ, mais comme l’ingénierie logicielle classique a elle aussi mis plus de temps que prévu à parvenir à des principes de conception stables, il faudra probablement 20 ans pour apprendre cela
L’hôpital lui a même donné l’accès aux serveurs du service IT, mais comme il ne pouvait pas connecter Claude, il ne savait pas comment déployer et m’a contacté complètement perdu ; l’application semble aussi avoir des problèmes intéressants liés aux données et à l’état
Cela me fait penser à quelqu’un qui recevrait chez lui un nombre illimité d’objets Amazon gratuitement : en théorie une vie d’abondance, mais en pratique on finit enseveli sous quelque chose qui n’a rien à voir avec la prospérité
Tout le monde sait comment ça s’est terminé
Ils avaient à moitié réimplémenté Kubernetes dans des milliers de lignes de Github Actions, et c’était impossible à comprendre
Je n’aime pas le marketing autour de l’IA, mais je trouve que c’est utile comme outil pour permettre à des gens expérimentés d’aller plus vite
En revanche, quand on n’est pas expert, l’IA semble produire des solutions compliquées pour tout ce qu’on veut faire
Il semble parler moins de l’usage de l’IA en soi que du fait que les entreprises et les gens externalisent leur prise de décision et leur réflexion à l’IA
Écrire du code avec l’IA n’est ni une psychose IA ni quelque chose de mauvais, mais si on se contente de taper un prompt et de croire ce que dit l’IA, là on s’en approche
Je vois souvent sur Twitter des gens de la finance et des VC remplacer leur réflexion et leur raisonnement par des captures d’écran de ChatGPT, alors qu’il suffirait qu’ils pensent un tout petit peu par eux-mêmes
Ces outils sont mauvais pour les idées, la réflexion et le conseil ; ils ne font que produire ce qui ressemble à un motif par appariement de motifs, donc quand on leur parle d’idées ils sortent en général les banalités les plus génériques
En revanche, ils sont assez utiles pour des tâches comme l’écriture de code, où l’appariement de motifs aide réellement, mais il ne faut pas leur confier la réflexion ni la prise de décision
En gros, les sommets sont plus hauts et les creux plus bas, et la description ci-dessus est très juste
J’ai écrit à ce sujet ici : https://mitchellh.com/writing/my-ai-adoption-journey, https://mitchellh.com/writing/building-block-economy, https://mitchellh.com/writing/simdutf-no-libcxx
Le dernier article décrit une modification complexe réalisée grâce à l’IA, et montre aussi comment je l’aborde de manière raisonnable
Elle produit presque toujours un texte qui semble logique, mais ce texte peut contenir des hypothèses implicites erronées et des décisions qui ne conviennent pas au cas d’usage
Pour construire une solution vraiment correcte, il faut que la définition du problème soit bonne, et c’est parfois plus difficile que de produire la solution elle-même
Ou même à des consultants pris au hasard
Est-ce que « l’IA a dit que c’était une bonne idée » est vraiment pire que « on a suivi la tendance du secteur » ?
Quand cela arrive à titre individuel, les amis et la famille peuvent plus ou moins freiner les choses en signalant des comportements ou des propos étranges
Mais quand un employeur commence à faire ça au niveau du leadership, il est difficile d’imaginer à quel point cela peut devenir mauvais
On subit la pression de suivre le mouvement ou on craint d’être licencié, et les seuls susceptibles de réguler la pensée sont les collègues opposés à cela, lesquels risquent de partir ou d’être renvoyés
Pour garder son poste, il faut se conformer
Comme l’agent prend les décisions à votre place, le travail avance à la vitesse de l’agent, et il prend souvent des décisions sans rien dire avant de ne livrer qu’une sortie finale du type « voici le plan »
Pour le relire correctement, il faut comprendre le problème en profondeur, donc on retombe à la vitesse humaine et on finit par survoler et approuver
L’essentiel, c’est de décider de manière consciente et prudente quelles décisions externaliser
Pour cela il faut ralentir ; les gains fantasmés de vibe coding à 10x diminuent, mais en échange on reste plus impliqué et on accumule moins de dette cognitive
Les décisions ennuyeuses, comme la façon de parcourir un tableau ou d’aligner la sortie d’un appel sur l’entrée d’un autre, peuvent être laissées à l’agent
Les vraies décisions doivent être prises à l’avance et inscrites dans la spec : il faut définir les frontières, les API, les structures de données fondamentales, les systèmes et les responsabilités, la gestion des erreurs, ainsi que les fortes contraintes de sécurité et de confidentialité
S’il y a ambiguïté, il faut demander à l’agent de s’arrêter, et un bon ingénieur peut obtenir un gain de vitesse de 2 à 3x sans effets secondaires
Peut-être que cela va enfin transformer le génie logiciel en véritable discipline d’ingénierie
En ce moment, des prompt engineers montent l’infrastructure entière de leurs entreprises
Je connais personnellement quelqu’un qui a migré la base de données de son entreprise vers une version plus récente de Postgres ; il a fini par réussir, mais l’écouter raconter le processus me faisait grincer des dents
Ça donnait l’impression de : « J’ai versé de l’essence sur le serveur et allumé une cigarette, mais t’inquiète, j’ai trouvé un extincteur au sous-sol. La jauge dit qu’il est vide, mais quand on le secoue on entend encore du liquide »
Quand il partira de l’entreprise, il faudra un prompt engineer encore plus sûr de lui pour maintenir cette infrastructure DB
Ce billet souligne qu’il est impossible de débattre avec les gens qui disent « ce n’est pas grave si on déploie des bugs, les agents pourront les corriger à une vitesse et à une échelle impossibles pour les humains »
Et pourtant la réponse la mieux classée ici est justement un exemple de « oui, mais les agents sont incroyablement rapides »
C’est peut-être l’hypothèse que le gain d’un codebase et de fonctionnalités doublés dépasse le coût de bugs doublés
En tout cas, pour la newsletter aux investisseurs de ce trimestre, ça aura meilleure allure
On peut très bien continuer à déployer toujours plus de déchets, et la boucle de feedback, ce sont les clients ?
La réponse a été : « C’est la théorie des jeux. Quelqu’un le fera, donc tu es obligé de le faire aussi. Ça ne peut pas être si mauvais. »
La logique a son utilité, mais ignorer les risques, c’est autre chose
Supposer qu’en allant extrêmement vite et en cassant tout on obtiendra au final un bon résultat est dangereux
Cette dynamique autour de l’IA ne se passe pas bien et elle ne me plaît pas
Je ne pense pas forcément que le camp psychotique soit « le nôtre »
Je travaille dans une très grande entreprise, et chez nous la modernisation et l’adoption de nouvelles technologies ont toujours avancé à une vitesse glaciaire
Mais bizarrement, cela pourrait maintenant devenir un avantage concurrentiel
La vie imite l’art
Avant, on plaisantait sur le fait qu’il y avait encore des fax, mais je ne pensais pas être un jour aussi soulagé de travailler dans une culture qui n’est pas prise dans ce genre de fièvre
Lire HN donne l’impression d’entrer dans l’Alice au pays des merveilles des maximalistes du token et des psychotiques de l’IA
Ici, je ne connais littéralement personne à qui l’on impose de travailler comme ça
Si c’est votre humeur, vous aimerez peut-être le nouvel outil CLI Burn, Baby, Burn (those tokens) : https://github.com/dtnewman/burn-baby-burn/tree/main
Le Show HN est ici : https://news.ycombinator.com/item?id=48151287
Cela me rappelle Simple Made Easy de Rich Hickey et son approche lors de la création de Clojure
Avant même que les LLM ne génèrent des programmes entiers, les frameworks complexes permettaient déjà aux développeurs de produire très vite une première version d’un programme, au prix d’une compréhension plus difficile, donc d’un débogage et de modifications plus compliqués
Certains parient que même si l’IA écrit des programmes extrêmement enchevêtrés et complexes, elle sera toujours assez intelligente pour les déboguer, les maintenir et les modifier
Je n’en suis pas convaincu
La psychose IA n’est pas une position hostile à l’usage de l’IA
J’utilise des outils de codage IA tous les jours, mais les outils IA n’ont aucune notion du futur
Nous avons longtemps compté sur la pensée égoïste de l’ingénieur qui se dit : « Si ça casse en production, je ne pourrai pas le réparer, et on me réveillera à 3 h du matin » pour construire des systèmes stables
Il y avait aussi la paresse ordinaire qui consiste à chercher la bibliothèque parfaite sur CPAN pour éviter de faire le travail soi-même, et parfois on passait plus de temps à ne pas trouver la bibliothèque qu’à écrire la solution
J’ai écrit des milliers de lignes de code avec des outils IA et les ai mises en production, ce qui m’a semblé assez naturel, parce que depuis 2017 je dis aux gens de ne pas taper leur code entièrement à la main, mais de l’écrire en installant dans leurs tests des pièges capables d’attraper le mauvais code
Mais il y a une chose que l’IA ne fait pas, c’est écrire moins de code : https://xcancel.com/t3rmin4t0r/status/2019277780517781522/
Les signalements de bugs diminuent aussi quand les gens perdent confiance dans le fait qu’ils seront corrigés
Signaler un bug demande souvent un investissement en temps assez important
Cela arrive assez souvent quand la confiance dans un groupe ou une entreprise s’effondre
Ils risquent donc davantage d’être incorrectement signalés, et certains éléments peuvent être faux
C’est une attaque sur plusieurs fronts
On n’a même pas encore abordé les tactiques adversariales
Si l’on n’a pas de scrupules, quoi de mieux qu’utiliser des agents pour inonder un concurrent de faux signalements de bugs ?
Problème résolu
Une grande partie, voire peut-être la totalité, de ce que Mitchell observe pourrait très bien se produire même sans IA
J’ai vraiment l’impression d’être dans une position étrange
Je déteste tellement les changements que l’IA apporte à l’expérience et à la pratique de l’écriture de code que j’aurais presque envie de faire n’importe quoi sauf utiliser des ordinateurs, tout en pensant en même temps que ces outils sont très puissants et continuent de s’améliorer
Le point de Mitchell est valide. Ce genre d’outil peut introduire des fondations pourries qui ne seront découvertes qu’une fois toute la structure effondrée
Je ne veux pas me retrouver dans un rôle où je devrai en répondre sans comprendre le codebase aussi profondément qu’avant
Mais les humains introduisent eux aussi depuis longtemps des bugs subtils mais fatals dans le code
Donc, dans une large mesure, cela ressemble encore à une question empirique ouverte
Va-t-on voir beaucoup de systèmes s’effondrer de façons terribles qu’on ne voyait pas auparavant ? Peut-être pour certains
En même temps, est-ce qu’on ne va pas apprendre qu’il faut aller davantage vers la spécification et la vérification ? Je ne sais pas
Quoi qu’il en soit, cette manière de construire des systèmes semble inévitable, même s’il y aura des collisions en chemin
J’ai aussi l’impression qu’il existe une forme de psychose réactionnaire dans le camp anti-IA
Je n’ai pas envie d’avoir affaire à l’IA, mais je ne peux pas non plus nier mon expérience de ces outils
J’aimerais qu’il y ait plus d’espaces pour avoir ce type de discussion réaliste mais négative sur l’IA
C’est aussi pour cela que Mitchell est un bon développeur