IA : l’incompétence accélérée

 (slater.dev)
5 points par GN⁺ 2025-05-29 | 1 commentaires | Partager sur WhatsApp
  • En ingénierie logicielle, une dépendance excessive aux LLM accélère rapidement l’incompétence
  • Les LLM ont des limites et ne peuvent pas remplacer la pensée critique ni les capacités de résolution de problèmes
  • L’usage des LLM s’accompagne de nombreux risques : sorties erronées, erreurs d’entrée, baisse de la qualité du code, affaiblissement des compétences des développeurs, perte du plaisir de créer
  • Les LLM ne peuvent pas fournir des compétences de développement essentielles comme la théorie des programmes et l’entropie des programmes
  • À long terme, la maîtrise technique et la capacité de réflexion approfondie comptent plus que jamais

Introduction

Depuis l’arrivée de l’IA et des LLM qui ont capté l’attention du grand public fin 2022, les discussions se multiplient
En tant qu’ingénieur logiciel expérimenté, l’auteur présente deux problèmes majeurs observés avec les LLM

Le point de vue « Les LLM sont mes amis »

Les ingénieurs qui considèrent les LLM comme l’outil suprême finissent par faire de la vitesse leur valeur prioritaire
Les LLM permettent de générer rapidement beaucoup de code, mais cela comporte des risques à long terme

Les risques liés à l’usage des LLM

  • Risque de sorties erronées : les LLM produisent du code manifestement incorrect (impossible à compiler) ainsi que du code plus subtilement défectueux (bugs logiques, etc.)
    • Lorsqu’une personne sans capacité d’évaluation demande du code source, la probabilité d’obtenir une réponse inadaptée est élevée
  • Risque d’entrées erronées : les LLM ne critiquent pas les hypothèses fausses ni les prompts dépourvus de contexte
    • Ils ne distinguent pas les bonnes questions et ne comprennent pas non plus le problème XY (échec à identifier la cause profonde)
  • Ralentissement futur du développement : l’adoption des LLM fait croître rapidement la dette technique et transforme la base de code en un ensemble confus et difficile à maintenir
  • Risque d’infantilisation des utilisateurs : à mesure que disparaissent les occasions de développer la résolution de problèmes et la pensée, la dégradation des compétences des talents du développement s’accélère
    • Les développeurs seniors n’acquièrent plus d’expérience de résolution de problèmes plus profonde, tandis que les juniors n’ont même plus l’occasion de construire leurs compétences
  • Perte de la joie de créer : écrire du code avec les LLM fait perdre l’état de flow et le plaisir de la création, et lire puis modifier du code généré par l’IA est souvent pénible

L’inquiétude : « Vais-je perdre mon emploi à cause de l’IA ? »

Cette possibilité est très faible
Il existe deux capacités de développement que les LLM ne peuvent pas remplacer : la théorie des programmes et l’entropie des programmes

Théorie des programmes

  • Comme l’affirmait Peter Naur, « programmer consiste à construire une théorie du design »
    • Le code source n’est pas le véritable livrable, et la compréhension collective (la théorie) est plus importante
    • Si l’on donne le même problème à deux équipes de niveau équivalent et qu’on ne leur transmet ensuite que le code, l’équipe qui l’a développé elle-même pourra ajouter des fonctionnalités bien plus efficacement
    • Dans une base de code peu familière, la productivité est faible, puis augmente progressivement à mesure que l’on comprend la théorie interne de conception

Les LLM et la théorie des programmes

  • Les LLM ne disposent que d’une mémoire en contexte ; ils ne peuvent donc pas internaliser une véritable théorie des programmes ni une conception en profondeur
    • En pratique, l’essence réelle du développement (la conception et la construction d’une théorie) n’est acquise que par les humains

Entropie des programmes

  • Fred Brooks a qualifié la complexité (entropie) de difficulté fondamentale de la programmation
    • La maintenance des programmes augmente la complexité, et même les meilleures exécutions conduisent les systèmes à un vieillissement irréversible

Les LLM et l’entropie des programmes

  • Les LLM se limitent à une prédiction de tokens au niveau du texte et sont incapables d’une réflexion sémantique au niveau des idées, des plans de conception ou des exigences
    • Plus ils traitent de longues conversations ou de gros blocs de code, plus ils répètent des changements inutiles ou étranges, ce qui ne fait qu’alourdir la complexité
    • Réduire la complexité ou lui résister est une tâche que seuls les humains peuvent accomplir

Conclusion

À partir des intuitions de deux pionniers, l’auteur réaffirme la nature essentielle de la conception logicielle et de la complexité
Si l’on espère que l’IA améliorera sa carrière de développeur, il faut faire attention : elle peut au contraire accélérer l’incompétence
Forts d’une expérience riche et de compétences solides, nous devons reconnaître que les LLM ne peuvent pas remplacer les ingénieurs humains
L’attrait économique de l’adoption de l’IA réside dans la réduction des coûts, mais en réalité elle introduit de nouveaux risques, et un usage excessif accumule à long terme des coûts supplémentaires et des risques organisationnels
L’importance de la maîtrise technique et de la capacité de réflexion approfondie ne changera pas à long terme ; il faut utiliser l’IA comme un outil et continuer à investir dans les compétences essentielles qui comptaient déjà en 2019

Annonce du prochain article

Un prochain billet abordera des solutions concrètes pour chacun de ces risques

Références

À lire aussi

1 commentaires

 
GN⁺ 2025-05-29
Avis Hacker News
  • Partage d’une impression récurrente : les discussions sur le codage avec l’IA reflètent parfois la différence entre les ingénieurs logiciel et les data scientists / ingénieurs machine learning
    Les ingénieurs logiciel sont toujours censés produire un logiciel prévisible qui passe les tests, et l’outillage y est bien plus avancé
    À l’inverse, pour les ingénieurs ML, travailler avec des modèles probabilistes fait naturellement partie du quotidien, et les tests portent souvent davantage sur des métriques que sur une sortie précise
    Ils sont donc plus habitués au fait que l’IA n’est pas toujours fiable
    Ils abordent aussi les assistants de code avec l’idée que si 80 % de la réponse est correcte, il leur suffit de repérer les 20 % restants
  • D’après mon expérience, environ la moitié me semble aussi avoir vécu quelque chose de similaire
    Quand je travaillais chez Amazon, les solutions fondées sur le ML étaient très utiles pour des problèmes sans approche classique
    Mais dans une startup, certains s’obstinaient sur une approche par apprentissage sans même comprendre le filtrage ou le mapping de base, ce qui produisait à répétition des résultats absurdes pour l’estimation d’attitude d’un avion à l’arrêt
    Ce fossé entre ML et ingénierie logicielle est bien réel, et j’aimerais qu’on trouve de meilleurs moyens de le faire apparaître dans les processus de recrutement
  • Dans l’ambiance actuelle, on a l’impression que l’état d’esprit MLE est appliqué de force à d’autres groupes
    Dans une entreprise qui vend des produits où la précision et la justesse sont essentielles, l’équipe ML soutenait que 80 à 90 % suffisaient, au grand agacement de l’architecte
    Cela rappelle que même un petit pourcentage peut avoir un impact énorme, comme on l’a vu pendant la pandémie avec les discussions autour d’un taux de mortalité de 1 %
  • Mention de la différence entre comportement déterministe et comportement probabiliste
    Cet article s’intéresse à une question méta sur l’IA et l’ingénierie logicielle, à savoir la gestion de l’entropie des programmes
    La gestion de l’entropie représente une part énorme de la construction de produits logiciels, et l’IA pourra peut-être un jour la faciliter, mais aujourd’hui elle l’aggrave souvent
  • Actuellement en master d’IA (surtout ML), je développe en tant que SWE de nouveaux réflexes
    Je vois le MLE dans une perspective plus large de SWE, avec la nécessité de comprendre l’ensemble : construction de pipelines robustes, intégration des modèles, déploiement, etc.
    Mais la plupart des profils purement MLE manquent de point de vue SWE et comprennent souvent le ML sans véritable intuition informatique
    Pour être réellement full-stack, il faut comprendre à la fois les systèmes bas niveau, l’architecture, le déploiement, et le MLE
    Pourtant, le marché recrute surtout soit des SWE, soit des docteurs MLE ; qu’on me propose donc une rémunération à la hauteur si je sais faire tout cela
  • Les ingénieurs logiciel appliquent eux aussi très souvent une pensée probabiliste
    Par exemple en repensant les race conditions, en estimant le p99 des appels DB, ou avec les tests A/B
  • Globalement d’accord avec l’argument de l’article, mais j’ai aussi observé des effets positifs en utilisant des LLM
    En tant que développeur senior avec 30 ans d’expérience, devoir lire du code généré par l’IA signifie que le développement bascule vers un flux centré sur la revue de code
    Cela aide même les développeurs individuels à adopter un sens des responsabilités propre au travail en équipe et à apprendre en lisant davantage de code
    Bien utiliser un LLM exige aussi une compréhension de la structure hiérarchique du problème
    Concevoir en détail section par section aide naturellement à définir les interfaces et les frontières
    Les LLM sont un catalyseur qui accélère la progression des juniors vers un niveau senior, en leur permettant d’entrevoir l’apprentissage des développeurs expérimentés
    L’IA ne remplacera pas les développeurs ; elle finira par s’intégrer comme un outil
    • Je pense qu’on devrait toujours lire plus de code qu’on n’en écrit
      Le code généré par les LLM peut être monotone, mais cela reste une occasion d’apprentissage
      J’ai découvert beaucoup de nouveaux idiomes et appels de bibliothèques en lisant du code généré par des LLM
      Plus on est senior, mieux on peut formuler les prompts, et plus le LLM devient un catalyseur puissant
    • L’IA est excellente pour produire un premier prototype qu’on peut copier-coller, mais pas pour valider ni commit
    • Du point de vue des entreprises, l’IA ne servira pas à aider les juniors, mais à supprimer leur recrutement tout en exigeant des seniors une productivité multipliée par 10 grâce à l’IA
      Les réductions d’effectifs se poursuivent, de la big tech à la mid-tech et à la small tech
  • Le débat sur l’IA est comparé à l’ancienne idée selon laquelle l’impression 3D allait remplacer toute la fabrication
    L’IA serait plus proche de ce type de changement concret que d’une singularité
    • L’impression 3D est une technologie formidable et innovante, mais le moulage par injection existe toujours
    • L’impression 3D n’a pas provoqué de singularité, mais dans l’enseignement supérieur et d’autres formes de travail du savoir, l’IA a déjà un impact majeur
      Avec l’arrivée des LLM, des méthodes de cours et de devoirs autrefois considérées comme évidentes changent rapidement partout dans le monde
    • L’impression 3D a apporté des transformations et des innovations immenses dans plusieurs secteurs, comme l’aéronautique et le spatial
      Sans SpaceX, bien des choses auraient été réellement impossibles
    • C’est aussi comparable à l’idée que le bitcoin allait remplacer les banques
      Au final, les banques ont surtout fini par vendre des produits financiers fondés sur le bitcoin
    • L’impression 3D et l’IA ont des courbes de croissance totalement différentes
      L’impression 3D n’est pas perçue comme un remplacement de la fabrication existante et reste surtout cantonnée au prototypage, aux maquettes et aux PoC
  • Les LLM excellent pour écrire du code, mais ne peuvent pas porter la « responsabilité »
    Accepter du code qu’on ne comprend pas se paie cher plus tard en maintenance, sous forme de dette technique
    C’est comme une illusion de vitesse gratuite ; en réalité, on accumule de la dette technique à un taux équivalent à 40 % d’intérêt annuel
    L’IA peut automatiser la saisie, mais la réflexion doit rester humaine
    • Comme le LLM ne « comprend » pas réellement, la vraie compréhension n’existe que lorsque l’humain comprend le contexte de la codebase et le système
    • Proposition de réduire ce taux d’intérêt via les tests et une structuration en sous-systèmes isolés (tdd, microservices, etc.)
      Certains estiment que des pratiques comme tdd ou les microservices, pas toujours nécessaires dans le développement traditionnel, gagnent en valeur à l’ère des LLM
    • Selon la tâche, l’IA peut aussi être très mauvaise, y compris pour écrire du code
  • Le plus gros point de douleur, dans mon expérience, était le risque d’entrée (input risk)
    La moindre ambiguïté dans le prompt peut complètement fausser le résultat, et lorsqu’on s’en rend compte, il est souvent trop tard pour réparer proprement
    C’est précisément à cause de l’ambiguïté du langage humain que les langages formels sont apparus
    Personnellement, en utilisant les outils IA, j’ai parfois l’impression que mon niveau se dégrade rapidement, et j’ai eu des cas où j’y ai perdu encore plus de temps et d’énergie
    L’IA est utile, mais on dirait qu’il y a d’un côté ceux qui voient s’accumuler les petites erreurs sur des problèmes complexes, et de l’autre des managers ou non-techniciens qui ne regardent que le résultat pour parler de « remplacement de rôle »
    [Expérience détaillée : commentaire précédent]
    • Je recommande d’utiliser l’IA comme assistante, avec une responsabilité humaine directe sur la qualité et la maintenance
      Comme les calculatrices ont fait baisser les capacités de calcul mental, l’IA peut aussi dégrader l’écriture, la communication et la résolution de problèmes
    • Partage d’une expérience où l’entrée d’un mot ambigu produisait des résultats non logiques du LLM
      D’où l’usage réservé des LLM à de petites tâches claires, du type de celles qu’on chercherait sur StackOverflow
      Je ne traite jamais leurs réponses comme des vérités absolues, mais comme des guides
    • L’IA permet de résoudre certains problèmes plus vite, mais elle ne résout pas les problèmes qu’elle rend inutilement plus complexes
      La capacité humaine à comprendre le plan d’ensemble reste essentielle pour résister à l’entropie
    • Une méthode que j’utilise souvent : demander d’abord au LLM de « poser 5 questions claires pendant 3 tours »
      Cela aide à clarifier bien davantage le sujet et le contexte
      J’espère que cette astuce servira aussi à d’autres
    • J’ai le pressentiment qu’après cette époque de hype, l’importance du contrôle qualité sera redécouverte
      Exemple : l’ancienne guerre Coke vs Pepsi
  • Difficile d’être d’accord avec l’idée que les LLM ne traitent pas conceptuellement les idées, diagrammes et spécifications
    Si on interroge un LLM sur l’intention de conception, par exemple en demandant « donne-moi un code simplifié », on peut obtenir un très bon second avis
    Si on ne pose pas la question, il n’y a simplement pas de réponse ; et les réglages par défaut sont aussi notre choix, donc cela n’a pas grand-chose à voir avec la nature profonde de la technologie sous-jacente
    • Il existe déjà de nombreuses démonstrations empiriques du travail conceptuel des LLM
      En pratique, personne ne peut embrasser entièrement un programme gigantesque dans sa tête ; les outils et les langages ont surtout progressé sur la base d’une compréhension partielle
      Les LLM partagent cette même limite, donc humains et LLM se ressemblent en ce sens
    • En revue de code junior, j’ai souvent l’impression que le problème principal n’est pas tant la qualité du code que l’orientation choisie
      Ce qui manque aux LLM, c’est la capacité à demander « pourquoi fais-tu cela de cette façon ? »
    • Je me demande si vous utilisez un outil d’automatisation pour passer du code au diagramme, ou si vous le faites vous-même
  • Évocation d’une analogie avec l’idée que les logiciels de cartographie comme Google/Apple Maps atrophient le sens de l’orientation
    Il y a une part de vrai, mais la plupart des gens n’étaient déjà pas bons pour se repérer, et les technologies de cartographie ont plutôt amélioré en moyenne la capacité à aller de A à B
    Même pour la minorité de personnes très habiles, la technologie joue davantage un rôle d’assistance que de remplacement
    L’IA entraînera sans doute une évolution similaire à plus grande échelle : certaines capacités diminueront ou se perdront, mais il y aura aussi beaucoup à gagner
    • Les cartes sont incomparables aux LLM en termes de fiabilité
      Une carte donne presque toujours la valeur attendue, alors qu’un LLM varie même avec le même prompt, ce qui le rend difficile à juger fiable
      De la même façon que certaines personnes finissent dans un lac à cause du GPS, une confiance aveugle dans les LLM peut provoquer des problèmes encore plus graves
    • Personnellement, l’usage des logiciels de cartographie m’aide plutôt à mieux mémoriser l’espace
      On peut errer librement puis retrouver un itinéraire quand nécessaire, ce qui enrichit au contraire l’expérience
    • Google Maps est plus précis à plus de 90 % qu’un chauffeur de taxi
      L’IA, elle, est parfois inférieure à quelqu’un qui n’a pratiqué le domaine que quelques jours
    • Je me demande s’il existe des preuves à l’appui de l’idée d’une « amélioration du niveau moyen »
  • Pas d’accord avec l’affirmation de l’auteur selon laquelle « [l’IA] ne peut pas travailler au niveau conceptuel »
    Les LLM récents peuvent clairement travailler à un niveau conceptuel, par exemple pour traduire ou appliquer un concept
    Ils peuvent même comprendre des concepts qu’un humain n’a pas personnellement expérimentés
    • Les LLM modélisent les concepts à travers des clusters de tokens
      Par exemple, autour de dog, on retrouve des mots associés
      En revanche, ils ne modélisent pas bien la composition, l’intention ou le raisonnement contrefactuel
      Ils sont performants pour les questions proches des données d’entraînement
      Dans des domaines bien structurés conceptuellement, comme l’ingénierie logicielle, ils peuvent être utiles
    • Exemple complémentaire : les humains aussi peuvent comprendre des concepts sans les avoir expérimentés directement
  • En réalité, 70 % des employés font déjà leur travail à moitié, et l’IA est parfois meilleure
    Au final, ceux qui travaillent sans conviction ne changeront pas avec l’IA, et seuls ceux qui apprennent vraiment progresseront avec elle
    • Critique de la limite d’un récit autocentré où l’on s’imagine appartenir aux 30 %
    • Ceux qui utilisent l’IA pour bâcler leur travail ne font qu’augmenter leur risque de licenciement
      Si l’IA fait mieux le travail, cela crée justement un argument pour remplacer la personne
    • Dans les grandes entreprises, cette thèse semble la plus réaliste
      Même le FSD (conduite autonome) est bien meilleur qu’un conducteur moyen non expert
  • Partage d’un sentiment récent : la nécessité de reconstruire 90s.dev comme une communauté non-IA, dédiée à l’artisanat logiciel
    Réflexions en cours autour d’un format forum, mailing list ou multi-blog
    Liste de diffusion temporaire
    • Plutôt qu’une structure ouverte à tous, un système sur invitation avec un arbre de confiance par parrainage semblerait plus adapté à une communauté durable
      Il existe déjà des exemples réussis de ce modèle dans certaines communautés
    • Utiliser un ancien logiciel de forum avec un design rétro pourrait aussi être une bonne idée