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

• Plus on produit vite 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 capacités à long terme s’affaiblissent
• Elle aide beaucoup dans les schémas familiers, mais face à des problèmes inconnus, des conditions ambiguës, des informations incomplètes et des contraintes contradictoires, la simple imitation superficielle s’effondre facilement et le niveau réel apparaît
• Les bons ingénieurs confient 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 directement la responsabilité de la définition du problème, de la relecture, des choix et des abandons
• La vraie valeur élevée de l’ingénierie logicielle réside davantage dans le jugement que dans la production de code ; voir les contraintes cachées, repérer un faux problème et transformer des débats flous en arbitrages devient encore plus important
• Surtout en début de carrière et dans le fonctionnement 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 renforce la valeur humaine

---

Les modes d’échec quand on externalise sa réflexion

• A.I. traite rapidement des tâches comme la génération de code, les résumés de réunion, l’explication de concepts, les brouillons d’architecture ou les mises à jour d’état, mais elle peut aussi installer facilement l’habitude de produire des résultats plausibles sans compréhension
• Si l’on répète la réponse produite par 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 propre compréhension par des résultats générés, plus on saute les exercices qui développent le jugement, en échangeant les capacités à long terme contre une apparence à court terme
• Dans des situations qui ne se traitent pas par template — problèmes inconnus, conditions ambiguës, informations incomplètes, contraintes contradictoires — l’imitation superficielle s’écroule vite

• L’analogie de la copie d’une copie d’examen

  • On peut garder de bonnes notes en recopiant une réponse, mais dès qu’on entre dans une situation où une vraie compréhension est nécessaire, le vide du socle apparaît
  • Sans l’intuition qui se construit en faisant le travail soi-même, il devient difficile de raisonner sur un problème inhabituel ou de réagir à un changement de conditions
  • Réutiliser encore et encore les réponses données par l’IA ne fait qu’emprunter 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 intuition des ordres de grandeur, on ne peut plus vérifier si le résultat a du sens
  • Un ingénieur qui a de bonnes bases peut relire la sortie de l’IA, filtrer les erreurs, puis la corriger ou la jeter
  • Un ingénieur sans bases n’utilise pas l’IA : il se laisse entraîner par l’IA, ce qui est encore plus dangereux dans les rôles où l’exactitude et la responsabilité du résultat comptent

• L’analogie de la voiture autonome

  • La conduite autonome réduit la fatigue et gère les situations du quotidien, mais si l’on en dépend avant de comprendre la conduite, on devient presque un passager qui possède juste les commandes
  • C’est dans les situations non standard — mauvaise visibilité, route complexe, autres véhicules imprévisibles, panne du système, danger soudain — que le niveau réel se révèle
  • L’IA aussi est forte sur les schémas généraux et les structures familières, mais l’ingénierie déborde en permanence de ce cadre : changements de besoins, bugs subtils, propriété floue, objectifs d’architecture concurrents, données partielles, frictions organisationnelles et arbitrages sans réponse parfaite

La manière dont les excellents ingénieurs utilisent l’IA

• Les excellents ingénieurs n’utilisent pas moins l’IA ; ils l’utilisent plus activement, sans lui céder pour autant l’acte de penser lui-même
• Ils lui confient volontiers les tâches mécaniques comme écrire du boilerplate, résumer de la documentation, générer du scaffolding de tests, proposer des refactorings, explorer les points de défaillance, accélérer la recherche ou compresser les tâches répétitives
• En revanche, ils formulent des questions plus précises, définissent le vrai problème plutôt que de répondre à la demande immédiate, et privilégient la clarté et la concision à une formulation lisse mais vide
• Ils ne se contentent pas de recombiner le savoir déjà présent dans le système : ils produisent une nouvelle connaissance à forte valeur
• Et ils réinvestissent ainsi le temps gagné dans un niveau supérieur de réflexion et de jugement

La vraie source de valeur

• Depuis longtemps, on assimile l’ingénierie logicielle à la production de code, mais ce n’est pas là que se trouve la valeur la plus élevée
• Si l’essentiel consistait seulement à écrire du code syntaxiquement correct, l’IA serait déjà en train de remplacer directement une grande partie du métier ; en réalité, le cœur du travail, c’est le jugement
• Les ingénieurs de valeur voient les contraintes cachées avant qu’elles ne provoquent un incident, remarquent que l’équipe résout le mauvais problème, transforment des débats flous en arbitrages clairs, identifient l’abstraction manquante et déboguent non pas le code, mais la réalité
• L’IA peut aider sur ces tâches, mais elle ne peut pas les prendre entièrement à sa charge
• À l’avenir, les ingénieurs qui créeront le plus de valeur seront plus proches de 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’IA plus utile
• Dans cet environnement, au lieu d’être remplacé par l’IA, l’ingénieur gagne davantage de levier en travaillant au-dessus du niveau 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 celles où se forment les compétences fondamentales : sens du debug, intuition des systèmes, précision, goût, relecture critique, capacité à décomposer un problème et à expliquer pourquoi quelque chose fonctionne
• Ces compétences se construisent dans le frottement, les essais-erreurs, la correction des échecs, la traque des causes racines et l’expérience du réel qui résiste et casse les hypothèses
• Si l’IA supprime toutes les difficultés du processus d’apprentissage, on gagne peut-être en efficacité à court terme, mais on saute l’étape où les capacités se trempent
• On peut sembler efficace pendant un ou deux trimestres, tout en laissant discrètement échapper les capacités qui soutiendront l’avenir
• Les systèmes d’assistance peuvent donner l’impression que les choses fonctionnent, mais ils ne créent pas à votre place la capacité réelle

Il n’existe pas de raccourci vers le jugement

• Le simple fait de lire une explication générée ne permet pas de transférer la maîtrise dans la tête sans faire soi-même le travail
• Il n’existe aucun chemin où l’on externalise longtemps le raisonnement tout en finissant malgré tout par acquérir une forte capacité de raisonnement
• Il est possible et souhaitable d’externaliser les tâches mécaniques, d’accélérer la recherche et de compresser les tâches répétitives
• Mais on ne peut pas sauter le processus même de formation de la compétence et se retrouver malgré tout en possession de cette compétence
• L’erreur centrale des usages les plus naïfs de l’IA consiste à croire qu’on gagne du temps alors qu’en réalité on ne fait que repousser la facture : jugement faible, compréhension superficielle, faible adaptabilité

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

• Si l’IA aide à construire plus vite la compréhension, à penser plus profondément et à travailler à un niveau plus élevé, alors la valeur humaine augmente
• Si l’IA aide à éviter la compréhension, à éviter la difficulté et à éviter de prendre possession du raisonnement, alors la valeur humaine diminue
• Une trajectoire s’accumule comme des intérêts composés ; l’autre vide l’intérieur et pousse vers un état où l’on devient facilement interchangeable
• L’avenir favorise moins les ingénieurs qui utilisent simplement l’IA que ceux qui savent distinguer avec précision ce qu’il faut déléguer et ce qu’il faut garder en propre, et qui transforment le temps économisé en meilleure réflexion

Pourquoi l’effet est encore plus fort sur la santé des organisations

• Le management de l’ingénierie se retrouve lui aussi sur cette même frontière entre usage qui accélère la compréhension et usage qui imite la compréhension
• Un leadership solide doit savoir distinguer les résultats bien présentés du jugement réel ; si l’on ne récompense que la vitesse, l’aisance et la qualité de présentation, on passe à côté des signaux de profondeur technique
• Quand un travail à faible compréhension mais à forte fluidité se répand, ce n’est pas seulement la qualité des livrables individuels qui baisse : c’est tout l’environnement de connaissance de l’organisation qui s’affaiblit
  • les reviews deviennent plus faibles
  • les discussions de design deviennent plus superficielles
  • la documentation devient plus lisse, mais moins utile
  • avec le temps, l’organisation perd sa capacité à produire la clarté et le jugement technique dont elle dépend
• C’est pourquoi l’essentiel n’est pas tant l’adoption d’outils d’IA en soi que la préservation des conditions dans lesquelles survivent la vraie réflexion, l’apprentissage et le métier
• Dès l’embauche, il faut des moyens de distinguer non pas l’aisance apparente, mais la compréhension réelle
  • les entretiens doivent tester le processus de raisonnement plus que les polished answers
  • l’évaluation doit récompenser non pas le volume de sortie, mais la clarté, la profondeur, le jugement sain et les contributions techniques durables
• Cela a aussi un impact majeur sur la conception des équipes et la culture
  • il ne faut pas que les bons ingénieurs passent trop de temps à nettoyer des travaux plausibles mais superficiels produits par des personnes qui ont externalisé leur réflexion
  • si l’on n’empêche pas cela, les hauts performeurs finissent consumés comme amplificateurs pour tout le monde sauf eux-mêmes, ce qui mène facilement à la frustration, à la baisse des standards et aux départs
• En définitive, dans l’ère de l’IA, la qualité d’une organisation dépendra surtout de la capacité du leadership à distinguer en permanence l’effet de levier et la dépendance, l’accélération et l’imitation, la compétence réelle et la sortie 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