L’IA n’a pas simplifié l’ingénierie logicielle : elle a seulement rendu la mauvaise ingénierie plus facile

• Les LLM ont accéléré l’écriture de code, mais n’ont pas réduit la complexité intrinsèque de l’ingénierie logicielle
• À mesure que la génération de code devient plus facile, l’illusion se répand que l’expertise n’est plus nécessaire, et certaines organisations s’en servent déjà pour réduire leurs effectifs d’ingénieurs
• En réalité, la difficulté n’est pas l’écriture du code, mais la conception du système, la spécification, la validation et le maintien de la cohérence ; l’IA accélère même plutôt la charge dans ces domaines
• Le décalage entre spécification, tests et implémentation (spec drift) s’aggrave rapidement, augmentant le risque d’effondrement de la fiabilité des systèmes
• C’est un schéma observé à répétition en plus de 40 ans de carrière : à l’époque de Visual Basic dans les années 1990, on a déjà vu réapparaître la même idée selon laquelle l’expertise n’était plus nécessaire, avant que la nécessité d’une discipline d’ingénierie ne soit finalement réaffirmée
• Les LLM sont d’excellents outils pour explorer des conceptions et accélérer les premières implémentations, mais ils doivent être utilisés pour renforcer la discipline d’ingénierie, non pour la remplacer

---

Une dangereuse illusion dans l’industrie

• Depuis que les LLM savent générer du code, une ambiance s’installe dans l’industrie logicielle selon laquelle l’ingénierie logicielle elle-même ne serait plus nécessaire
• Des disciplines comme l’architecture, la spécification ou la validation rigoureuse sont traitées comme des reliques d’un autre âge
• Dans certaines organisations, cette idée est déjà traduite en politique, avec des cas de licenciements massifs d’ingénieurs justifiés par les progrès de l’IA
• L’IA n’est que le dernier prétexte pour esquiver de mauvaises décisions business ou les pressions du marché
• Le fait de saisir des prompts dans une IA est de plus en plus présenté comme un substitut aux disciplines qui définissaient l’ingénierie logicielle

Un schéma historique qui se répète

• En plus de 40 ans de carrière, le même schéma a été observé à plusieurs reprises : apparition d’un nouvel outil → proclamation que les problèmes difficiles sont résolus → explosion de la productivité et démonstrations impressionnantes → réduction des effectifs → hausse de la complexité des systèmes → au final, des résultats très éloignés des attentes
• Les outils et les discours changent, mais le schéma lui-même ne change presque pas

L’analogie avec la maintenance aéronautique

• Le domaine de la maintenance aéronautique a beaucoup progressé grâce à l’amélioration des outils, au diagnostic informatique, aux manuels numériques et à l’interprétation par IA de la télémétrie, mais le besoin de techniciens expérimentés reste intact
• Un avion commercial est un système d’une complexité extrême, composé de millions de pièces et de milliers de sous-systèmes interconnectés
• Diagnostiquer un problème ne consiste pas seulement à utiliser le bon outil ou à suivre une checklist ; cela demande de l’expérience et du jugement sur la façon dont le système fonctionne dans des conditions d’exploitation réelles
• Aucune compagnie aérienne ne proposerait de supprimer les techniciens formés sous prétexte que les outils se sont améliorés, puis de confier les réparations à des agents de porte d’embarquement
• Pourtant, l’industrie logicielle est en train de tenir sur elle-même un discours très proche de celui-là

DIY vs systèmes professionnels

• Les projets hobby, les petites applications personnelles ou l’expérimentation de nouvelles idées ne posent aucun problème, et certaines des idées les plus passionnantes de l’histoire de l’informatique sont nées de ces expérimentations
• Mais le développement logiciel professionnel relève d’une tout autre catégorie : traitement des paiements, stockage d’informations sensibles, gestion d’infrastructures, exploitation de systèmes dont les gens dépendent chaque jour
• Les clients s’attendent naturellement à ce qu’un système fonctionne correctement, continue de fonctionner correctement en évoluant, et que les personnes qui le construisent comprennent comment il marche
• Ces attentes sont les conditions de base de l’ingénierie professionnelle, là où discipline et expertise deviennent inévitables

Le code n’a jamais été la partie difficile

• L’idée selon laquelle la difficulté du développement logiciel réside dans l’écriture du code est une vieille méprise
• Taper de la syntaxe a toujours été la partie la moins intéressante de la construction d’un système ; le vrai travail difficile consiste à décider du comportement du système, à concevoir les interactions entre composants et à préserver son intelligibilité à mesure que la complexité augmente
• Ce n’est pas un problème de codage, mais un problème d’ingénierie
• Réduire l’effort nécessaire pour produire du code n’élimine pas ces problèmes ; cela permet seulement de construire plus vite des systèmes plus grands et plus complexes
• Croire qu’il s’agit d’un gain de productivité est une illusion : la charge s’est simplement déplacée ailleurs
  • La charge cognitive nécessaire à la revue du code et au traitement du code généré devient un frein à la productivité plus important que l’écriture elle-même
  • Si la vitesse augmente alors que le comportement sous-jacent n’est pas suffisamment compris, cela ne fait qu’accélérer le moment où la complexité devient ingérable, avec en plus un résultat erroné

Un schéma déjà vu : l’époque Visual Basic

• Dans les années 1990, Visual Basic s’accompagnait déjà de promesses similaires : la programmation aurait été démocratisée, et l’expertise serait devenue inutile
• En pratique, Visual Basic a effectivement permis de créer de nombreuses applications qui n’auraient sans doute jamais vu le jour autrement
• Mais à mesure que les systèmes grossissaient et s’interconnectaient, on a redécouvert que produire des artefacts logiciels et concevoir des systèmes fiables, ce n’est pas la même chose
• Aujourd’hui, nous vivons une version amplifiée du même schéma : ce n’est plus seulement la barrière à l’entrée de la création d’applications qui baisse, mais celle de la production de code elle-même
• De là naît la tentation de croire que l’expertise n’est plus nécessaire

Le problème d’alignement

• Un logiciel fiable dépend d’un alignement dont on parle rarement en dehors de l’ingénierie
• Un système commence par une idée de son comportement → est documenté dans une spécification → puis des ingénieurs traduisent cette spécification en tests et en code de production
• Pour garantir la fiabilité d’un système sur le long terme, spécification, tests et implémentation doivent rester alignés en permanence
• Dès que ces trois éléments commencent à diverger, le système perd progressivement son intégrité
  • La spécification décrit un comportement qui n’est plus implémenté
  • Les tests ne valident qu’une partie du comportement et laissent le reste de côté
  • Les ingénieurs arrivés plus tard devinent le comportement du système en lisant un code qui reflète, ou non, la conception d’origine
• Avec le temps, les suppositions s’accumulent, jusqu’à produire un système que plus personne ne comprend vraiment
• Ce phénomène est appelé spec drift : l’écart progressif entre la description du système et le système lui-même
  • Le code a changé, mais la spécification est restée identique
  • La spécification a évolué, mais les tests sont restés figés
  • Le comportement a changé peu à peu, au point que plus personne ne sait vraiment quelle était l’intention initiale
• Quand l’alignement est rompu, la fiabilité ne tient pas longtemps

L’IA accélère la dérive

• Les LLM accélèrent de façon spectaculaire la production de code, et c’est à la fois leur plus grande force et le point où le danger apparaît
• Quand le code est produit plus vite que les disciplines d’ingénierie qui l’entourent, les forces qui créent le spec drift s’accélèrent elles aussi
• Des changements qui exigeaient autrefois une réflexion attentive et une implémentation manuelle sont désormais possibles en quelques secondes
• Des sections entières d’un système peuvent être réécrites avant même que quiconque ne vérifie si leur comportement reste conforme à la spécification
• Le code peut sembler raisonnable, compiler, être lisible, et même réussir les tests existants, alors que l’alignement qui gouvernait le système a peut-être déjà disparu
• Ce qui ressemble à de la productivité n’est en réalité que la capacité à aller plus vite vers le désalignement qu’auparavant

Là où l’IA aide réellement

• Les LLM ne sont pas une erreur, et utilisés avec discernement, ils peuvent améliorer de façon spectaculaire la manière dont les ingénieurs explorent et conçoivent les systèmes
• Ils excellent notamment dans le raisonnement sur un problème, l’exploration d’alternatives de conception, la synthèse de systèmes complexes et la production de brouillons qui accélèrent les premières étapes de l’implémentation
• Ils sont moins à l’aise dans les domaines qui exigent rigueur et cohérence dans la durée
• Maintenir l’alignement entre spécification, tests et implémentation reste une responsabilité d’ingénierie, et aucun outil ne peut s’y substituer, même s’il peut y contribuer
• La véritable opportunité consiste à utiliser les LLM non pas pour remplacer discrètement le processus d’ingénierie, mais pour le renforcer

L’ingénierie logicielle conversationnelle

• L’une des possibilités intéressantes ouvertes par les LLM est qu’une partie de l’ingénierie logicielle pourrait devenir plus conversationnelle
• Pendant des décennies, les outils de conception de systèmes sont restés rigides : les spécifications étaient des documents, l’architecture des diagrammes, et le raisonnement qui y menait se perdait dans les réunions et les discussions de couloir
• Avec les LLM, les ingénieurs peuvent explorer des idées de manière interactive, tester des hypothèses et travailler sur la conception d’une façon plus proche d’une conversation naturelle
• Mais la conversation n’est pas l’ingénierie : la conversation sert à explorer des idées ; l’ingénierie commence lorsque ces idées sont capturées sous une forme vérifiable, testable et maintenable
• Le défi des outils d’ingénierie de nouvelle génération sera d’apprendre à relier ces deux mondes sans perdre la discipline exigée par les systèmes complexes

L’expertise reste essentielle

• Les logiciels professionnels ont toujours besoin d’ingénieurs qui comprennent réellement comment fonctionnent les systèmes qu’ils construisent
• Les outils peuvent accélérer le développement, mais ils ne peuvent pas supprimer l’expertise nécessaire pour concevoir, raisonner sur et maintenir des systèmes complexes
• L’industrie est dangereusement proche d’oublier cette réalité
• Les LLM peuvent rendre des ingénieurs expérimentés bien plus productifs, mais ils ne remplacent pas la discipline d’ingénierie nécessaire à la construction de systèmes fiables
• Il faut utiliser ces outils efficacement, sans les idolâtrer

[GN⁺]

Commentaires Hacker News

• Je ne suis pas d’accord avec la prémisse de l’article. Je pense que l’ingénierie dans son ensemble est devenue plus facile, en bien comme en mal. Avant déjà, je voyais beaucoup de gens empiler des vérifications de null plutôt que de comprendre réellement. Aujourd’hui, c’est simplement passé à l’échelle. À l’inverse, l’excellente ingénierie est encore plus amplifiée, au point que certaines fonctionnalités qui prenaient autrefois des semaines se font maintenant en quelques jours

  • Je trouve l’article un peu exagéré. Une bonne ingénierie peut aussi bénéficier de l’aide d’agents basés sur des LLM, mais la validation du résultat reste à la charge des humains. La mauvaise ingénierie saute cette étape, donc du point de vue de la loi d’Amdahl, les LLM accélèrent bien davantage la mauvaise ingénierie
  • La mauvaise ingénierie est devenue beaucoup plus facile, et la bonne ingénierie un peu plus facile. Résultat, des gens qui faisaient auparavant de la bonne ingénierie produisent maintenant trois fois plus de mauvaise ingénierie
  • Dans le développement d’applications d’entreprise, j’ai vu des tests mock qui vérifient seulement qu’une valeur attendue est renvoyée. Je me demande bien à quoi ça sert
  • Il est facile d’oublier que les LLM ne sont pas un oracle magique. La qualité du résultat dépend de la façon dont on traite leur sortie. Parfois, on peut l’utiliser telle quelle, mais la plupart du temps, il faut la modifier. Il est facile de tomber dans le piège du « si le LLM l’a dit, c’est sûrement vrai », ce qui rend la mauvaise ingénierie plus facile
  • Même si on est d’accord avec l’article d’origine, il existe en pratique beaucoup de domaines applicatifs où la qualité logicielle, bonne ou mauvaise, importe peu. Souvent, il suffit que ça fonctionne

• Il y a des cas où même cent tests unitaires ne suffisent pas à prouver la correction d’un code. La plupart des développeurs ne savent pas ce qui est suffisant. Ceux qui font beaucoup de vibe coding confient même les tests à la machine. Dès qu’on passe à la conception de système, il faut une architecture capable de garantir la sûreté globale et les invariants temporels. Mais la plupart des gens se contentent de dessiner des boîtes et des flèches en invoquant les « best practices ». Comme avec l’effet Sussman, selon lequel le logiciel se rapproche davantage des sciences naturelles, on finit par passer plus de temps à observer. Utiliser la GenAI comme outil peut être utile, mais arrêter de réfléchir pour dépendre de l’outil est dangereux

  • Je ne sais même pas ce qu’est un test unitaire, mais grâce à l’IA je peux créer des programmes qui m’aident énormément dans mon vrai travail. Les programmeurs d’élite, eux, ne répondraient même pas à un e-mail, même si on les payait

• Tous les quelques années, à chaque nouvel outil, on entend que « la partie difficile de l’ingénierie logicielle est résolue ». La productivité explose, les démos impressionnent, et l’industrie s’auto-congratule. Puis viennent rapidement les réductions d’effectifs. Ce serait formidable s’il y avait une vraie percée, mais si le résultat, c’est des licenciements, ça n’a aucun sens. Au fond, la question reste la même — si l’objectif est de réduire le nombre d’emplois, quelle est la vision des entreprises quand les gens ne peuvent plus gagner leur vie ?

  • L’objectif n’est pas l’emploi individuel. Le but ultime, c’est de construire l’AGI, et dans ce processus, les salaires et l’emploi des développeurs ont probablement déjà dépassé leur pic. Quelques super-développeurs IA font exception
  • Je pense qu’il est impossible d’éliminer la complexité. La réalité et les humains sont complexes par nature. L’idée que le logiciel puisse être simple est irréaliste. En prenant un peu de recul, on dirait que l’objectif final, c’est la disparition de la classe moyenne
  • S’il n’y a pas de demande, il faut faire autre chose. Si on refuse, on meurt de faim
  • Le capitalisme dépend de l’existence d’une classe inférieure. Elle sert de pression sur les autres travailleurs pour qu’ils acceptent des salaires plus bas et de moins bonnes conditions. Les programmeurs n’ont été que temporairement protégés de cette réalité. Cette structure est aussi liée au travail immigré : les entreprises peuvent imposer des tâches dangereuses et expulser ceux qui désobéissent. En fin de compte, tout cela n’est qu’un système destiné à réduire le coût du travail

• Je suis d’accord avec l’idée que « coder n’a jamais été la partie difficile ». Les experts savaient déjà quoi construire ; seule la répétition était pénible

  • La maintenance du code reste avant tout une question d’humains et d’expérience. Savoir « quel code il ne faut pas écrire » est devenu encore plus important. Aujourd’hui, comme générer du code est trop facile, on vit à une époque où il est très simple de produire du code spaghetti en masse
  • Le cœur du débat sur les LLM est là. Certains veulent seulement un résultat, d’autres veulent de la maintenabilité et de la stabilité. Les deux approches sont nécessaires, et les rôles de prototype et de production vont naturellement se séparer
  • Les gens vraiment doués veulent toujours faire les choses eux-mêmes. Ce n’est pas à cause des LLM, ça a toujours été comme ça. Au contraire, ce sont surtout ceux qui disaient que « taper de la syntaxe n’a rien d’amusant » qui en profitent le plus. Pour moi, le fait de taper est la seule partie intéressante

• Les développeurs juniors qui dépendent trop de l’IA paieront plus tard le prix de leurs lacunes fondamentales. Au final, seule l’expérience apportera une vraie sécurité de l’emploi

• J’ai du mal à être d’accord avec l’idée que « écrire du code n’a jamais été la partie difficile ». Bien sûr, ce n’est pas toujours difficile, mais avec des contraintes de temps, l’écriture du code devient un goulot d’étranglement. L’IA permet de tenter des choses qui étaient autrefois impossibles, et libère davantage de temps d’ingénierie

  • Il y a une contradiction à dire que c’est « difficile à prendre au sérieux » tout en étant au fond d’accord. Le texte original porte une nuance bien plus fine
  • Écrire du code était la tâche la plus chronophage, et l’IA le met en évidence. Tout le monde peut taper, mais la vraie compétence, c’est la capacité à lire du code. Comme un bûcheron qui troque sa hache contre une tronçonneuse électrique : l’efficacité augmente, mais les dégâts possibles aussi

• L’IA a aussi facilité la bonne ingénierie. Au final, c’est un amplificateur de comportements

  • Les bons ingénieurs peuvent devenir encore meilleurs, mais la plupart des gens ne savent même pas ce qu’est le property testing. On peut donc se demander à quel point l’IA leur sera utile
  • Internet a relié le savoir du monde entier, mais les humains ont fini par se perdre dans le bavardage et les contenus futiles. Vu la nature humaine, l’IA suivra probablement une trajectoire similaire
  • Les problèmes créatifs se résolvent souvent pendant l’écriture directe du code. Avec l’IA, ce circuit mental s’active moins
  • Des données comme le rapport DORA vont aussi dans ce sens
  • La phrase « l’IA est un amplificateur des comportements existants » est vraiment parfaite. Je vais la réutiliser telle quelle

• Je suis un sceptique de l’IA, mais je ne pense pas qu’elle prenne le travail de mes collègues. En revanche, elle me fait gagner du temps. Je m’en sers comme d’un outil de recherche meilleur que Google, et c’est utile pour explorer une codebase, générer des fonctions utilitaires et relire des erreurs

  • Je suis d’accord aussi. Je pense que cette façon de faire est finalement le point d’arrivée de l’usage de l’IA

• En ce moment, la distinction entre ingénierie logicielle et recherche devient plus nette. L’IA est un outil extraordinaire pour la recherche exploratoire. Lorsqu’une piste paraît prometteuse, je repasse alors en mode SWE pour comprendre le code, le modifier et l’affiner avec mon expérience. Le rôle de l’IA est limité, mais reste utile

  • Les LLM peuvent explorer instantanément une étendue de connaissances bien plus vaste que les humains. Mais le jugement final dépend du goût et du sens de la qualité humains

• Combien de nouvelles générations de modèles faudra-t-il encore avant que ces gens-là (les pessimistes) abandonnent ? Deux ? Trois ?