L’IA ne doit pas remplacer la réflexion, mais l’élever

• Plus on produit rapidement des résultats plausibles, plus il devient facile de répéter sans comprendre, et si l’on saute l’entraînement qui développe le jugement, les compétences à long terme s’affaiblissent
• L’aide est précieuse dans les schémas familiers, mais face à des problèmes nouveaux, des conditions ambiguës, des informations incomplètes ou des contraintes contradictoires, la simple imitation superficielle s’effondre facilement et le niveau réel apparaît
• Les ingénieurs solides délèguent volontiers les tâches mécaniques comme le boilerplate, les résumés, le scaffolding de tests ou l’accélération de la recherche, mais gardent en propre la définition du problème, la revue, les choix et l’abandon
• La plus grande valeur de l’ingénierie logicielle ne réside pas dans la production de code mais dans le jugement ; la capacité à voir les contraintes cachées, à repérer le mauvais problème et à transformer des débats flous en compromis devient encore plus importante
• Surtout en début de carrière et dans la gestion des organisations, les critères qui protègent la compréhension réelle comptent davantage ; plus on distingue clairement ce qu’il faut déléguer et ce qu’il faut prendre en charge soi-même, plus l’IA devient un outil qui augmente la valeur humaine

---

Les modes d’échec quand on sous-traite sa réflexion

• L’I.A. traite rapidement des tâches comme la génération de code, le résumé de réunions, l’explication de concepts, la rédaction d’ébauches de conception ou de mises à jour d’état, mais elle peut aussi facilement installer l’habitude de produire des résultats plausibles sans compréhension
• Quand on répète la réponse de la machine comme si c’était sa propre compréhension, on finit par imiter l’apparence de la compétence sans avoir réellement construit ses capacités
• Plus on remplace sa compréhension par des résultats générés, plus on saute l’entraînement qui forge le jugement, en échangeant des compétences à long terme contre une apparence à court terme
• Dans les situations qui ne se traitent pas par modèle — problèmes inconnus, conditions ambiguës, informations incomplètes, contraintes contradictoires — l’imitation superficielle s’effondre vite

• L’analogie de la copie à un examen

  • On peut conserver de bonnes notes en recopiant les réponses, mais dès qu’on se retrouve dans une situation où la compréhension est réellement nécessaire, on voit que les bases sont vides
  • Sans l’intuition qui se construit en faisant soi-même, il devient difficile de raisonner sur des problèmes non familiers ou de réagir à des changements de conditions
  • Réutiliser sans cesse les réponses fournies par l’I.A. revient à n’emprunter que l’apparence de la maîtrise, sans accumuler la maîtrise réelle

• L’analogie de la calculatrice

  • Une calculatrice est un excellent outil pour gagner du temps, mais si l’on en dépend sans sens des ordres de grandeur, on perd la capacité de vérifier si le résultat est plausible
  • Un ingénieur qui a des bases peut relire la sortie de l’I.A., filtrer les erreurs, la corriger ou l’écarter
  • Un ingénieur sans bases n’utilise pas l’I.A. : il est plutôt entraîné par elle, ce qui devient encore plus risqué dans les rôles où l’exactitude et la responsabilité du résultat sont essentielles

• L’analogie de la voiture autonome

  • La conduite autonome réduit la fatigue et gère les situations courantes, mais si l’on en dépend avant de comprendre la conduite, on devient proche d’un passager qui possède seulement les commandes
  • C’est dans les situations non standard — mauvaise visibilité, routes complexes, autres véhicules imprévisibles, défaillance du système, danger soudain — que le niveau réel apparaît
  • L’I.A. est elle aussi forte sur les schémas généraux et les structures familières, mais l’ingénierie déborde sans cesse de ce cadre : changements d’exigences, bugs subtils, propriété floue, objectifs d’architecture concurrents, données partielles, friction organisationnelle, compromis sans réponse parfaite

Comment les excellents ingénieurs utilisent l’I.A.

• Les excellents ingénieurs n’utilisent pas moins l’I.A. ; ils l’utilisent plus activement, sans pour autant lui céder leur réflexion
• Ils lui confient volontiers les tâches mécaniques comme l’écriture de boilerplate, le résumé de documentation, la génération de scaffolding de tests, les suggestions de refactoring, l’exploration des modes d’échec, l’accélération de la recherche et la compression des tâches répétitives
• En revanche, ils formulent des questions plus précises, définissent le vrai problème plutôt que la demande immédiate, et privilégient la clarté et la concision plutôt que des phrases lisses sans substance
• Ils ne se contentent pas de recombiner des connaissances existantes dans le système ; ils produisent de nouvelles connaissances à forte valeur
• Le temps ainsi gagné est réinvesti dans un niveau supérieur de réflexion et de jugement

La véritable source de valeur

• Pendant longtemps, on a assimilé l’ingénierie logicielle à la production de code, mais ce n’est pas là que se trouve la plus grande valeur
• Si le cœur du métier consistait seulement à produire du code syntaxiquement correct, l’I.A. suivrait naturellement une trajectoire de remplacement direct d’une grande partie du travail ; en réalité, le cœur du métier réside dans le jugement
• Un ingénieur de valeur voit les contraintes cachées avant qu’elles ne provoquent une panne, remarque que l’équipe résout le mauvais problème, transforme des débats ambigus en compromis nets, identifie les abstractions manquantes et débogue non pas le code, mais la réalité
• L’I.A. peut soutenir ce travail, mais elle ne peut pas en prendre la responsabilité à la place de l’humain
• Les ingénieurs qui créeront le plus de valeur à l’avenir seront davantage ceux qui élaborent les principes de conception, la compréhension du domaine, les patterns, le contexte et les cadres de décision qui rendent l’I.A. plus utile
• Dans cet environnement, au lieu d’être remplacé par l’I.A., l’ingénieur gagne plus de levier en travaillant à l’étage au-dessus de la sortie brute

Un risque encore plus grand pour les ingénieurs en début de carrière

• Ce problème est particulièrement important en début de carrière
• Les premières années sont le moment où se forment les capacités fondamentales : sens du debugging, intuition système, précision, goût, regard critique, décomposition des problèmes, capacité à expliquer pourquoi quelque chose fonctionne
• Ces capacités se construisent par la friction, les essais-erreurs, la correction des échecs, la recherche de la cause racine et l’expérience du réel qui vous résiste
• Si l’I.A. supprime toutes les difficultés du processus d’apprentissage, on gagne peut-être en efficacité à court terme, mais on saute l’étape où les compétences se forgent
• On peut paraître efficace pendant un ou deux trimestres, tout en laissant discrètement de côté les capacités qui soutiendront l’avenir
• Un système d’assistance peut donner l’impression que l’on fonctionne, mais il ne peut pas produire à votre place une capacité réelle

Il n’existe pas de raccourci vers le jugement

• Le simple fait de lire des explications générées ne permet pas, sans faire le travail soi-même, que la maîtrise se transfère magiquement dans la tête
• Il n’existe pas de chemin qui consiste à externaliser longtemps le raisonnement tout en finissant malgré tout avec une forte capacité de raisonnement
• Externaliser les tâches mécaniques, accélérer la recherche et compresser le travail répétitif est possible et souhaitable
• Mais on ne peut pas sauter le processus même de formation d’une compétence tout en espérant posséder ensuite cette compétence
• L’erreur la plus naïve dans l’usage de l’I.A. consiste à croire que l’on gagne du temps alors qu’en réalité on reporte la facture sous forme de jugement faible, compréhension superficielle et faible adaptabilité

La ligne de séparation et ses implications à l’échelle de l’organisation

• Si l’I.A. aide à construire plus vite la compréhension, à penser plus profondément et à travailler à un niveau plus élevé, la valeur humaine augmente
• Si l’I.A. aide à éviter la compréhension, à éviter la difficulté et à éviter d’assumer la propriété du raisonnement, la valeur humaine diminue
• Une trajectoire s’accumule comme des intérêts composés ; l’autre vide progressivement l’intérieur et pousse vers un état où l’on devient facilement remplaçable
• L’avenir favorisera moins les ingénieurs qui utilisent simplement l’I.A. que ceux qui distinguent précisément ce qu’il faut déléguer et ce qu’il faut garder en propre, puis transforment le temps gagné en meilleure réflexion

Pourquoi l’impact est encore plus grand sur la santé de l’organisation

• Le management de l’ingénierie se retrouve lui aussi sur cette même frontière, entre un usage qui accélère la compréhension et un usage qui imite la compréhension
• Un leadership fort doit savoir distinguer les résultats lisses du jugement réel ; si l’on récompense uniquement la vitesse, l’aisance verbale et la qualité de présentation, on risque de manquer les signaux de profondeur technique
• Si des travaux à faible compréhension mais à forte fluidité se répandent, ce n’est pas seulement la qualité de la production individuelle qui baisse, c’est l’environnement de connaissance de l’organisation lui-même qui s’affaiblit
  • Les reviews deviennent plus faibles
  • Les discussions de conception deviennent plus superficielles
  • Les documents paraissent plus soignés, mais sont moins utiles
  • Avec le temps, l’organisation perd sa capacité à produire la clarté et le jugement technique dont elle dépend
• Voilà pourquoi l’essentiel n’est pas seulement l’adoption d’outils d’I.A., mais la préservation des conditions dans lesquelles la vraie réflexion, l’apprentissage et le savoir-faire survivent
• Dès l’étape du recrutement, il faut des moyens de distinguer la fluidité de façade de la compréhension réelle
  • Les entretiens doivent tester le processus de raisonnement plutôt que des réponses polished
  • L’évaluation doit récompenser la clarté, la profondeur, le jugement sain et les contributions techniques durables plutôt que le simple volume de sortie
• Cela a aussi un fort impact sur la conception des équipes et la culture
  • Il faut éviter que les ingénieurs les plus solides passent leur temps à nettoyer de façon excessive un travail plausible mais superficiel produit par des personnes qui ont externalisé leur réflexion
  • Sinon, les plus performants finissent par servir d’amplificateur pour tout le monde sauf eux-mêmes, ce qui mène facilement à la frustration, à la baisse des standards et au départ
• Dans l’ère de l’I.A., la qualité d’une organisation dépendra finalement encore davantage de la capacité du leadership à distinguer en permanence levier et dépendance, accélération et imitation, capacité réelle et production convaincante

[GN⁺]

Commentaires sur Hacker News

• Plus je relis cette thèse, plus je trouve que la formulation est raffinée, mais j’ai quand même l’impression qu’on n’est pas encore au niveau de la maxime
  Pour arriver à une phrase qui percute immédiatement chez beaucoup de gens en quelques mots, comme « the medium is the message », « you ship your org chart » ou « 9 mothers can't make a baby in a month », il faut souvent des années, voire des décennies, à tailler le sens jusqu’à l’essentiel
  Et comme nous ne savons même pas traiter la formation du sens avec du RL, l’IA ne peut pas le faire à notre place

  • "can't make 9 babies in a month"

    À l’origine, c’est bien « 9 women can't make a baby in one month »

  • On apprend en faisant soi-même. Cette formule me paraît plus proche de la maxime

  • Intelligence amplification, not artificial intelligence me semble pas mal
    En l’abrégeant, ça donne IA, not AI, et en espagnol ça devient « AI, no IA », ce qui est encore plus amusant

  • L’IA ne peut pas produire à votre place le goût ni le jugement

  • the medium is the message

    Si on demandait à 100 Américains ce que signifie cette maxime, j’imagine que très peu sauraient en donner le sens original chez McLuhan

• À mon avis, on peut globalement utiliser l’IA de deux façons
  La première, c’est comme assistance pour écrire du code que je possède et que je comprends ; la seconde, c’est d’utiliser l’IA comme couche d’abstraction à qui l’on confie l’écriture et la maintenance du code
  La seconde approche convient pour des prototypes, des exemples, des références, bref là où la durée de vie est courte et où la qualité du code ou mon niveau de compréhension importent peu
  Le problème apparaît en réalité quand on utilise la 2e approche là où c’est la 1re qu’il faudrait, en se trompant soi-même et en trompant les autres
  Même si cela semble rapide et facile, on finit en pratique par hypothéquer sa base de code, et c’est aussi à partir de là que commence, à mon sens, l’atrophie des compétences

  • Beaucoup d’ingénieurs croient vaguement qu’à un moment dans un futur proche, l’IA saura aussi parfaitement gérer la 1re approche, donc l’idée d’investir dans une infrastructure qui utilise la 2e pour rendre la 1re plus facile est plus difficile à vendre
  • Le problème, c’est qu’on n’a même pas l’impression de mettre quoi que ce soit en gage
    Les fonctionnalités continuent d’arriver et tout a l’air de tenir debout en surface, puis, le jour où quelque chose casse, on se rend compte qu’on ne sait même plus déboguer son propre code sans redemander au modèle

• Beaucoup d’ingénieurs ne pourraient déjà pas travailler sans un IDE moderne, un langage avec gestion mémoire, ou les bibliothèques de GitHub et des gestionnaires de paquets
  Du coup, la dépendance à l’IA ne me paraît pas fondamentalement si différente
  Le sens du mot Engineer peut lui aussi évoluer, et d’ailleurs il existe déjà des « web developers » qui ne font que du Webflow ou du WordPress

  • Le terme Engineer a déjà énormément changé
    Si on s’en tient à une définition stricte, il y a très peu de véritables ingénieurs certifiés parmi les gens du Software Engineering, et dans certains pays cela s’accompagne même d’un statut et d’un titre protégés
  • Il faut distinguer le fait de vraiment ne pas pouvoir faire quelque chose, et celui de ne pas le faire
    En début de carrière, avec suffisamment de temps, on aurait probablement pu faire à peu près n’importe quoi ; aujourd’hui, il y a une longue liste de choses que je pourrais faire, mais que je ne fais pas simplement parce que ça ne m’amuse plus
  • La grande différence, c’est qu’on ne connaît pas encore le coût final
    On ignore si l’IA coûtera l’équivalent d’un abonnement Slack, d’un membre supplémentaire dans l’équipe, ou si le service disparaîtra et qu’il faudra embaucher quelqu’un juste pour conserver un accès à l’IA
  • Au moins pour l’instant, l’exécution en local n’est pas réaliste pour la plupart des gens
    Donc dépendre de l’IA, ce n’est pas du tout la même chose que dépendre d’un IDE qui, lui, peut être local ou open source
  • La phrase « mais enfin, quel genre d’ingénieur es-tu ? » me revient avec l’image des lunettes de soleil rouge vif de Jesse Plemons

• Quelqu’un avec 10 ans d’expérience comprend les flux et la logique du code, donc peut utiliser l’IA tout en produisant du code et en améliorant sa propre manière de faire
  À l’inverse, un débutant risque davantage de se contenter de copier-coller sans comprendre le flux ni la logique, donc je ne pense pas que l’IA lui donne vraiment plus d’espace pour réfléchir

• La manière actuelle d’utiliser l’IA me paraît plus fatigante que les 20 dernières années de programmation
  Le plus épuisant, c’est de soumettre le problème, d’évaluer les propositions, de choisir la bonne direction, d’écarter les suggestions bizarres, puis de retravailler le tout jusqu’à obtenir quelque chose de presque correct
  Ensuite, on laisse tourner le codage pendant 1 à 5 heures, et cela peut produire un résultat qui m’aurait pris au moins 2 à 3 semaines si je l’avais fait moi-même
  Mais après environ 5 heures de ce travail centré sur la planification, je suis complètement vidé, et ce n’est pas la même fatigue que lors d’une session de programmation pure
  J’ai l’impression d’apprendre quelque chose, mais honnêtement cela ressemble davantage à un travail de manager

  • J’ai une impression similaire
    Pour définir lentement un problème avec un LLM et trouver une solution plausible, il faut rester en concentration soutenue en permanence, donc le flow d’autrefois apparaît beaucoup moins facilement
    Il faut traiter sans cesse des montagnes de sortie, en extraire à répétition ce qui compte vraiment, et même quand c’est globalement bon, il y a presque toujours quelque chose d’un peu à côté, ce qui devient assez irritant
    Il faut aussi maintenir un haut niveau de vigilance à cause des erreurs étranges et des défauts de raisonnement propres aux LLM, et le simple fait d’interpréter ce style de communication non humain finit aussi par épuiser
  • L’un des avantages de l’IA, c’est qu’elle vous met en mouvement et continue de pousser
    Mais je me demande aussi si le pacing ou la procrastination ne jouent pas, chez l’humain, le rôle d’une sorte de soupape de décompression

• Il y a déjà beaucoup d’ingénieurs qui ne réfléchissent pas très bien à la base, et l’IA ne change pas ce fait fondamental

  • Le vrai point central, c’est l’incapacité à penser correctement
    C’est l’une des raisons pour lesquelles le domaine du Software Engineering est déjà si abîmé, et l’IA ne peut pas le réparer ; elle ne fait peut-être que repousser temporairement un désordre encore plus grand
  • Je suis d’accord en partie, mais il me semble évident que l’IA a pour effet de rendre plus difficile, pour le leadership, de percer à jour les bobards et le baratin des gens
  • Je me demande comment il est possible de décrocher un diplôme d’ingénieur sans savoir réfléchir
    Même quelqu’un qui a tenu à l’université grâce à la triche devait malgré tout faire preuve d’esprit critique pour ne pas se faire prendre
    Certains n’aimeront pas l’entendre, mais être bon en triche demande déjà une certaine capacité de réflexion

• À mon avis, les gens qui confient leur réflexion à l’IA, quel qu’en soit le degré, n’y accordaient déjà pas tant de valeur que ça au départ
  Comme le dit l’expression « use it or lose it », et même si les études allant dans ce sens s’accumulent, on continue de voir des textes expliquant qu’utiliser les LLM en développement logiciel n’est pas un problème et que notre vraie valeur réside dans notre capacité à penser

  • Cela a peut-être un lien avec le TDAH ou une tendance anxieuse, et c’est peut-être assez fréquent chez les personnes qui travaillent sur ordinateur, mais moi, je pense presque tout le temps
    L’un des beaux aspects de ce métier, c’est justement ce moment où une solution surgit soudainement alors qu’on était absorbé par tout autre chose
    Désormais, l’IA permet de transformer rapidement cette pensée en action
    Avant, il m’arrivait de perdre le fil avant même d’avoir pu saisir le début d’une piste ; aujourd’hui, en quelques minutes sur mon téléphone, je peux matérialiser au moins partiellement une idée, puis revenir à ce que je faisais
    Le fait de ne plus avoir à craindre qu’une simple diversion du regard me fasse perdre l’idée est particulièrement important

• Je suis justement en train de refaire numba, et j’ai du mal à imaginer faire ça uniquement à la main
  Quand j’avais essayé il y a quelques années, c’était extrêmement pénible, lent et sale
  Il y avait une accumulation sans fin de petites choses posées sur des couches d’abstraction construites au fil des années
  Cette fois, je le refais avec un LLM, et ce qui aurait pris plusieurs semaines se boucle parfois en une seule nuit
  Malgré tout, je relis moi-même le code, je regarde aussi la sortie C générée, et je garde la main sur l’architecture pour qu’elle reste facile à manipuler à l’avenir, pour moi comme pour le LLM
  Je ne sais pas vraiment si cela remplace ma réflexion
  Si j’avais passé des mois à tout écrire et corriger manuellement, j’aurais sans doute davantage appris sur les compilateurs ou les transpileurs, mais je serais resté bloqué là-dessus
  À la place, il me reste aussi du temps pour écrire un support de serveur NFS pour un système de fichiers personnalisé en Golang

  • Moi aussi, je m’inquiète de voir quelles parties de mon processus de pensée l’IA est en train de remplacer
    J’ai maintenant mis en place des systèmes où des agents identifient les changements nécessaires pour une fonctionnalité complète, les détaillent très finement dès l’étape de planification, puis réalisent l’implémentation presque correctement du premier coup
    Depuis un an, je lis de moins en moins le code moi-même, et je me demande souvent si le confort que je ressens vis-à-vis du système n’est pas excessif
    J’ai vu tant de fois des niveaux élevés de précision et de réussite que mon réflexe naturel n’est plus vraiment de douter
    Je continue d’attendre le moment où je vais me brûler sérieusement, mais, étrangement, il n’arrive pas vraiment
    Bien sûr, il y a eu de petits oublis et des retours en arrière, mais il y en avait déjà avant
    La différence, c’est qu’autrefois j’avais un rapport beaucoup plus personnel au code, parce que c’était moi qui l’avais écrit à la sueur de mon front
    Maintenant, quand un problème survient, au lieu d’en vouloir au code, je creuse plutôt pour comprendre pourquoi le système n’a pas trouvé tout seul la bonne réponse, ou pourquoi il n’a pas fait apparaître l’ensemble du problème dans le plan avant l’implémentation

• Le plus grand avantage de l’IA en logiciel, c’est qu’elle permet de produire du code plus vite
  Son plus grand inconvénient, c’est qu’elle donne énormément envie d’aller encore plus vite

• C’est pour cela que je n’utilise pas l’IA sur mes projets personnels
  Je veux garder l’esprit affûté
  Il peut y avoir des exceptions pour des projets qui incluent de l’IA, mais je n’utilise pas l’IA pour écrire ce code-là
  En revanche, pour le travail en entreprise, cela m’est égal
  Si mon manager veut faire du vibe coding intégral avec Claude, qu’il en soit ainsi, puisque ce n’est pas moi qui paie le coût de la dette technique qui en résultera