Que se passe-t-il en ce moment ?

• Dans l’industrie du logiciel, le burnout des ingénieurs s’aggrave, et en particulier les ingénieurs juniors provoquent des problèmes de qualité du code et de collaboration par usage abusif des outils d’IA
• Les retours des ingénieurs seniors ne sont plus utilisés comme des occasions d’apprentissage, mais comme de nouveaux prompts à envoyer à l’IA, et le « code écrit par l’IA » épuise les revues de toute l’équipe
• Dans certaines organisations, du code incomplet généré par l’IA est présenté comme une « réussite », ce qui crée une atmosphère qui encourage la dépendance à l’IA
• L’auteur explique avoir ressenti un malaise et une sensation d’étrangeté en recevant lui-même des réponses de code produites par l’IA, et critique le fait que l’IA détériore au contraire la culture de l’apprentissage et du mentorat
• Il souligne aussi que l’écosystème des startups IA est au final insoutenable à cause de sa non-rentabilité, de sa consommation électrique et de ses problèmes environnementaux, et que la situation actuelle ne diffère guère d’une imposture où « l’empereur est nu »

---

Introduction : un environnement d’ingénierie inquiétant

• Ces derniers temps, le burnout s’intensifie parmi les ingénieurs
• Dans les organisations, on attend des ingénieurs seniors qu’ils examinent et contribuent à des « fonctionnalités fondées sur l’ambiance (mème) » qui ne fonctionnent pas réellement
• D’après mon expérience, les meilleurs ingénieurs ont toujours à cœur d’aider les nouveaux membres de l’équipe à progresser

• Mais au lieu d’utiliser ces retours comme une occasion de grandir, des développeurs débutants s’en servent simplement comme du prochain prompt à envoyer à une IA générative
• J’ai personnellement vu de nombreux ingénieurs juniors utiliser des outils de LLM (grands modèles de langage) à un niveau proche de l’abus

Cas concrets dans l’organisation : les dégâts de l’abus d’IA

• Lors d’un récent town hall dans l’entreprise, j’ai vu des ingénieurs juniors faire une démonstration de nouveaux livrables
• Ils semblaient ne même pas bien comprendre l’objectif ni le fonctionnement de la fonctionnalité
• Pourtant, dans les grandes organisations, l’accent est mis sur la mise en scène du « succès », indépendamment des résultats réels
• Lorsqu’un senior manager a présenté leurs usages de l’IA, il a expliqué fièrement : « voici 4 000 lignes de code écrites par Claude », et cela a été accueilli par des applaudissements

• Moi aussi, en examinant du code à la suite d’une demande de petite amélioration sur une fonctionnalité existante, j’ai demandé du contexte à l’ingénieur junior qui l’avait récemment modifiée
• Je lui ai envoyé l’URL du commit Github avec ma question, mais il semble qu’il ait saisi le contenu dans un LLM puis m’ait simplement recopié la réponse renvoyée
• Ce processus m’a laissé une curieuse impression d’étrangeté et d’inconfort

La pente IA et les limites de la revue de code

• À travers le cas d’un ami, j’ai confirmé qu’on voyait réellement des ingénieurs perdre du temps pendant un mois à examiner et tenter de fusionner du code généré automatiquement par un LLM (des PR vibe-codées)
• Un autre ami a raconté son épuisement à devoir relire à répétition du « code bâclé » produit par l’IA
• Grâce à l’IA, ni la qualité du code ni l’apprentissage ne progressent ; seul le travail répétitif augmente

La vraie valeur de la culture de développement et de la progression humaine

• Tous les ingénieurs progressent étape par étape grâce à leurs collègues et à leurs mentors
• Enseigner directement et faire grandir les autres est l’essence de la culture de l’ingénierie logicielle
• Mais il devient difficile de croire à la valeur de cet investissement quand le résultat est aussitôt copié comme données d’entraînement pour le « dernier modèle »
• Cela conduit à une question fondamentale : ne vaudrait-il pas mieux entraîner directement le modèle plutôt que les ingénieurs juniors ?

• Un tel monde représente une vision profondément sombre.

Une expérience sans IA et conclusion

• L’auteur propose très concrètement de faire l’expérience suivante : « essayez d’arrêter d’utiliser l’IA »
• Lui-même a récemment réinitialisé son ordinateur et a mis fin à son abonnement à Claude Pro
• Faire quelques recherches, lire Stack Overflow et la documentation officielle lui a au contraire permis d’aboutir à des conclusions bien plus fiables
• Il en vient à penser que son propre jugement est supérieur aux résultats fournis par les LLM en matière de précision et de fiabilité.

La valeur économique des outils d’IA générative, et leurs limites intrinsèques

• Il pose la question suivante : « l’IA est-elle vraiment utile ? »
• Objectivement, sa valeur suscite de sérieux doutes
• Le parcours typique d’une startup IA est le suivant :
  • de « l’IA » est appliquée à un domaine existant, et une jeune entreprise apparaît au nom de l’efficacité
  • la startup IA parvient à lever des fonds auprès du capital-risque
  • elle paie des frais d’utilisation à un fournisseur de services IA (OpenAI, etc.)
  • la startup IA elle-même ne parvient pas à générer de bénéfices
• Pris isolément, ce processus ne diffère pas beaucoup de l’écosystème VC traditionnel, mais la différence clé est que même les fournisseurs de services (OpenAI, etc.) ne sont toujours pas rentables
• La technologie elle-même est fondamentalement inefficace et mal adaptée à une expansion de masse
• Sa consommation d’électricité excessive et ses effets négatifs sur l’environnement constituent aussi un problème grave

Conclusion : la nécessité de voir la réalité en face

• On peut toujours espérer que la loi de Moore revienne, ou que tout le monde devienne riche avant la mort thermique de l’univers
• Mais si l’on regarde la réalité en face, le business de l’IA générative relève d’une forme de fantasme, un phénomène d’« empereur nu »

[ahwjdekf]

La crainte qu’après une guerre mondiale nucléaire, à la pointe ultime de la technologie, l’humanité retourne à une époque primitive est en train de devenir une réalité, en ce moment même, dans le domaine du développement logiciel.

[dicebattle]

Il suffirait probablement d’arrêter l’excès de vibe coding. Avec un assistant et pour écrire certains algorithmes simples mais détaillés, difficile de trouver mieux.

[GN⁺]

Avis Hacker News

• Souligne que l’introduction de l’IA dans une organisation n’est pas seulement un problème technique, mais aussi un problème de conduite du changement. Pour obtenir de vrais résultats, il faut une équipe compétente, fondée sur la confiance et la transparence, capable de construire des processus qui combinent de façon équilibrée l’expertise humaine et les points forts des LLM. On voit aussi apparaître des cas où de petites équipes obtiennent de grands résultats grâce à l’IA. Mais dans la plupart des organisations, surtout les grandes entreprises, la culture interne n’est pas saine, et l’IA tend au contraire à amplifier cette toxicité. Certains dirigeants comprennent même mal les « Story Points », qu’ils prennent simplement pour une unité de temps, et ne voient l’IA que comme un outil censé tout réduire de moitié. Fondamentalement, ils sont déconnectés du processus même de création d’un logiciel maintenable et perçoivent l’IA comme un simple canal pour augmenter vaguement les profits. Une étude récente indiquant que 95 % des projets pilotes IA n’ont pas atteint leur ROI montre aussi l’incompétence des dirigeants modernes

  • Fait remarquer que l’IA est peut-être simplement surévaluée. S’interroge sur les équipes concrètes auxquelles renvoie l’affirmation selon laquelle de « petites équipes obtiennent de grands résultats grâce à l’IA »
  • Exprime sa lassitude face à l’attitude qui consiste à absoudre l’IA en disant simplement que « ce ne sont que des problèmes qui existaient déjà ». Estime que la dégradation de la santé mentale ou les problèmes de culture d’entreprise liés à l’IA relèvent aussi de la responsabilité de l’outil lui-même. Contrairement à l’idée que les outils et les systèmes seraient irresponsables, pense qu’ils ont eux aussi un impact réel
  • Trouve regrettable d’entendre seulement des récits de réussite sur l’idée que « de petites équipes font de grandes choses », sans exemples concrets
  • Estime qu’introduire l’IA dans une organisation managériale déjà dysfonctionnelle revient à mettre des fusils automatiques dans les mains d’une bande de Vikings. Cela ne fait qu’accélérer la chute de l’organisation. Souligne que le cœur du problème n’est pas tant la technologie que l’échec social et éthique d’une grande partie des membres, ou d’un petit nombre de cadres clés
  • Mentionne que beaucoup de dirigeants confondent les « Story Points » avec du temps, et dit avoir vu cette erreur dans tous les rôles rencontrés jusqu’ici, du développement au QA, au PM et aux dirigeants

• Parle de l’apparition des « Prompstitudes » (des salariés qui ne s’appuient que sur les prompts). Un collègue lui a déjà simplement renvoyé une réponse de ChatGPT censée deviner son avis, et cela lui a donné, comme le dit l’article, une impression de « violation ». Il les juge moins incompétents que trop dépendants des LLM, un peu comme des personnes âgées dans un casino qui continueraient simplement à tirer sur une machine à sous

• Partage une expérience récente où une conversation avec un collègue lui a laissé un malaise, sans doute parce qu’il était évident qu’une réponse de ChatGPT lui revenait en retour. Il pense qu’il aurait encore préféré être ignoré. Le problème était aggravé par le fait que le LLM défendait avec assurance des choses fausses. De petits détails, par exemple un nom légèrement différent entre la configuration et l’implémentation, peuvent complètement désorienter un LLM. Contrairement à un humain, un LLM n’apprend pas de ses erreurs et n’en prend pas conscience, ce qui l’amène à persister dans la mauvaise direction. Psychologiquement, il trouve presque plus supportable de se battre avec du mauvais code humain

  • A déjà travaillé avec un PM qui écrivait des PRD avec l’IA. Quand on lui posait des questions sur le contenu, il répondait « je ne sais pas, c’est l’IA qui l’a écrit ». Au final, le PM avait renoncé à transmettre réellement ses idées et se contentait d’une performance de rédaction documentaire. Toute la compréhension et l’interprétation des exigences reposaient alors sur lui, ce qui l’a poussé à quitter l’équipe
  • Dit se reconnaître dans l’idée que « le LLM se trompait avec assurance ». Comme certains collègues charismatiques qui parlent avec aplomb, les LLM disent souvent des choses fausses de façon très crédible
  • Raconte une expérience très étrange cette semaine. Il a demandé à Claude de relire une proposition interne liée à une spécification spécialisée qu’il maîtrisait lui-même mal, et Claude a signalé beaucoup d’erreurs. Il a ensuite transmis cela au responsable interne de cette spécification en précisant « c’est le LLM qui a suggéré ça, ça peut donc être n’importe quoi », et cette personne a à son tour donné son message à un LLM, récupéré la réponse et la lui a renvoyée. Au final, il a eu l’impression que nous étions tous devenus les assistants de l’IA. Si c’est cela l’avenir du développement logiciel, cela ne l’enthousiasme pas
  • Pense que du mauvais code humain vaut largement mieux que du mauvais code LLM. Avec du code humain, on peut au moins inférer le contexte et ce que l’auteur essayait de faire. En revanche, le code généré par un LLM peut être cassé du début à la fin, ou inventer sans cesse des fonctions et des concepts qui n’existent pas. En général, les humains ne produisent pas un code aussi déconnecté du réel. Comprendre du code LLM peut exiger de réapprendre toute la codebase
  • À propos de la formule selon laquelle le LLM « croit qu’il ne se trompe pas », fait remarquer qu’un LLM ne croit, ne pense et ne ressent rien. Il ne fait qu’enchaîner les tokens statistiquement les plus plausibles, avec une petite part d’aléatoire pour imiter la créativité

• À la question « les outils IA sont-ils vraiment utiles ? », explique qu’il les utilise d’une manière différente de la plupart des gens et qu’il y trouve de l’aide. Il développe depuis 1983 et est aujourd’hui retraité, travaillant souvent seul. Il a essayé plusieurs outils, mais n’utilise plus que ChatGPT et Perplexity. Il ne leur fait pas écrire directement le code : il se sert du code proposé par le LLM comme point de départ. Il lui arrive parfois de le reprendre tel quel, mais la plupart du temps il le modifie et le réécrit. Quand le LLM commence à produire des résultats de plus en plus mauvais, il coupe simplement et tente une autre approche. Dans ce contexte, imaginer un ingénieur débutant recopier seulement du code LLM lui fait peur. Pour lui, la plus grande valeur est celle d’un « StackOverflow qui répond instantanément ». Il peut poser n’importe quelle question idiote sans honte et obtenir rapidement une réponse correcte. Récemment, en apprenant à implémenter des Passkeys sur iOS, il est parti d’un exemple de code ChatGPT et l’a étudié ligne par ligne. Le code initial et la version finale achevée sont totalement différents, et ce processus a approfondi sa compréhension technique

  • Dit utiliser l’IA exactement de la même manière. Il est presque au bout d’un projet personnel sur un domaine qu’il ne connaissait pas du tout au départ, et il comprend maintenant suffisamment bien la codebase
  • Dit aussi l’utiliser de façon similaire pour de petites tâches ou des projets personnels. Le LLM écrit d’abord un « code jetable », et l’exploration de ses limites permet de mieux comprendre le domaine du problème. Au final, cela donne assez de confiance pour implémenter soi-même plus solidement

• Trouve que les LLM excellent pour répondre à des questions techniques ou proposer de nouvelles approches. Même un débutant peut poser librement des questions sans être jugé comme sur StackOverflow ni se heurter à un mur. Copilot est excellent pour l’autocomplétion et accélère l’écriture du code, ainsi que la complétion des commentaires de documentation ou des lignes de code. Ces petites aides sont faciles à relire. En revanche, confier d’un bloc du code complexe à un LLM crée du chaos et conduit plutôt à passer son temps à déboguer. Pense qu’un débutant qui dépend trop fortement des LLM aura du mal à développer de vraies compétences en développement

• Personnellement, il utilise Zed pour coder sur ses projets hobby parce que l’IA n’y fait pas semblant d’être trop intelligente. Il peut appeler ses fonctions IA de façon discrète seulement quand il en a besoin, et le reste du temps il code simplement lui-même. Au travail, l’IA de VSCode le dérange beaucoup trop. Le problème se pose à deux niveaux : d’abord, l’interaction est trop fragile, avec des popups à cliquer ou l’insertion accidentelle d’énormes autocomplétions ; ensuite, cela casse le flux. L’autocomplétion IA est parfois utile, environ un tiers du temps, mais le reste du temps elle brise son fil de pensée et disperse son attention parce qu’il doit vérifier les résultats de l’IA. Il n’a pas ce problème avec Zed et a l’impression d’y avoir retrouvé le plaisir de programmer. Au fond, le problème vient moins de la fonction IA elle-même que de la manière dont elle est implémentée

  • Dit être totalement en phase avec cela à propos de Zed. Il bricolait auparavant dans JupyterLab ou Kate, puis a changé après avoir utilisé Zed. Avec Zed, l’IDE ou l’éditeur reste central, et les fonctions annexes comme l’IA ou le kernel Jupyter n’interviennent discrètement qu’en cas de besoin. Ces fonctions supplémentaires ne perturbent pas le travail principal d’édition de texte ou de code. Estime que l’équipe de Zed a trouvé un bon équilibre

• Trouve que l’IA est très utile pour créer des prototypes UX. En peu de temps, on peut obtenir un résultat cliquable, itérer plusieurs fois pour définir une direction, puis jeter ce code et redévelopper ensuite proprement. Cette méthode évite de perdre trop tôt beaucoup de temps dans une mauvaise direction. En revanche, pense qu’on est encore loin du moment où l’IA pourra produire d’un bloc une application complète et réellement significative

  • Reçoit beaucoup d’aide de l’IA dans des domaines qu’il pratique moins souvent, par exemple les scripts PowerShell. Lorsqu’il a eu besoin d’un script de rapport sur des paramètres du registre, Claude lui en a écrit un parfait, lui faisant gagner une heure
  • Dit ressentir la même chose : l’IA est excellente pour expliquer des erreurs. Elle aide beaucoup à trouver la bonne solution ou à faire émerger de nouvelles idées
  • Souligne qu’il est important de « jeter le prototype et redévelopper », mais fait remarquer que, dans la réalité, les PM oublient souvent cette partie et que le prototype finit fréquemment en production. Cela dit, si quelqu’un a trouvé une manière de bien l’utiliser, c’est déjà une bonne chose
  • Demande plus de détails sur ce cas d’usage, le processus et les outils, car cela pourrait aider concrètement lui-même et son équipe

• Considère que l’IA n’est pour lui qu’un outil parmi d’autres. Il ne se voit pas comme un développeur de haut niveau, mais sur ses projets personnels, lorsqu’il bloque, il demande à l’IA des idées et du feedback. Le point important, c’est qu’il ne lui confie pas l’écriture du code, sauf éventuellement un peu de boilerplate très simple. S’il code lui-même, c’est pour le plaisir de résoudre des problèmes, de créer et d’apprendre

  • Son projet récent n’aurait pas pu aboutir sans que l’IA écrive directement du code. Du setup complet du dépôt jusqu’au PoC, même imparfait, cela l’a rendu possible. Sans expérience en Django, en JS ni en développement web, il a pu grâce à l’IA obtenir d’abord quelque chose qui fonctionne sans être vraiment propre, puis l’améliorer progressivement tout en renforçant sa compréhension

• Raconte un épisode déconcertant lors d’une revue de code récente. Il est tombé sur une fonction complexe nommée « prepareData » qui mélangeait et filtrait des tableaux multidimensionnels. Lorsqu’il a demandé à son collègue quel était le rôle de cette fonction, celui-ci lui a répondu de demander au LLM pour gagner du temps. Il a été déçu de voir qu’on refusait même de répondre à la question la plus élémentaire dans le cadre d’une review

  • Propose avec un peu d’humour de demander au LLM, de renvoyer simplement la réponse au collègue, puis, après 20 allers-retours de feedback, s’il ne comprend toujours pas, de lui dire à son tour de demander au LLM

• S’inquiète de voir, d’ici dix ans, de jeunes développeurs vouloir devenir seniors sans avoir jamais vraiment écrit de code eux-mêmes

  • Fait remarquer que ce phénomène avait en réalité commencé avant l’IA. Il était déjà difficile d’être embauché sans plus de dix ans d’expérience, et le secteur a échoué à faire monter en compétences les jeunes générations. Même quand une entreprise essaie de former régulièrement des juniors, à chaque crise elle commence par les licencier, puis repart recruter en urgence uniquement des seniors, dans un cercle vicieux qui se répète
  • Plaisante en disant qu’aujourd’hui, trois ans suffisent peut-être pour être senior, et qu’on devient presque staff engineer bien plus vite qu’en dix ans
  • Mentionne que le concept de « vibe coding » est apparu il y a neuf mois et prévoit que, dans moins de deux ans, les gens n’écriront ni n’entretiendront plus eux-mêmes leur code
  • Pense malgré tout qu’il y aura toujours des logiciels écrits par des développeurs ayant une véritable expertise, et que tant que le code LLM ne sera pas parfait, la demande pour du code de haute qualité restera forte
  • Estime qu’il y a trop de développeurs juniors et pas assez de vrais problèmes leur permettant d’acquérir de l’expérience. Autrefois, on pouvait au moins leur confier à moindre coût des PoC ou des scripts ; aujourd’hui, comme l’IA remplit à peu près ce rôle, les occasions diminuent. Ajoute qu’à l’époque déjà, il y avait beaucoup de juniors et peu de places

[happyiminjay]

Aux premiers stades du développement, pour la mise en place de l’environnement et le développement de modules à l’échelle de petites function, l’IA est très efficace. En revanche, en dehors de cela, le vibe coding qui consiste à balancer du code et des prompts est une catastrophe du point de vue de la maintenance. Les premières fois, cela peut sembler fonctionner, mais au final, chaque fois qu’un problème survient, il faut essayer N fois jusqu’à ce que l’IA résolve son propre problème, avec en permanence la crainte de ne pas savoir quels autres bugs cette solution pourrait provoquer.

[ulsoft]

Selon les compétences du développeur
si la personne a de bonnes bases, elle peut utiliser l'IA pour produire un développement de haute qualité
si elle n'a pas de bases solides, tout part dans la mauvaise direction
comme la différence entre un cuisinier qui a les bases et un autre qui ne les a pas