L’époque où je réfléchissais en profondeur me manque
(jernesto.com)- Avec l’arrivée des outils de codage par IA, l’expérience de la réflexion approfondie a brutalement diminué, au point de donner l’impression que ma progression en tant qu’ingénieur stagne
- Parmi les deux facettes en moi, le « Builder » et le « Thinker », le Builder est satisfait grâce à l’IA, tandis que le Thinker est affamé
- Le « vibe coding » permet de passer rapidement d’une idée à sa concrétisation, mais les occasions de résoudre des problèmes de façon créative ont fortement diminué
- Quand l’IA fournit une solution « suffisamment correcte » à 70 %, il est difficile, par tempérament pragmatique, de la rejeter
- J’ai essayé de retrouver la satisfaction de la réflexion profonde en dehors du code, sans succès, et il reste incertain de savoir si ces deux besoins pourront être satisfaits en même temps
Le problème d’un manque de réflexion
- Avant de lire ce texte, demandez-vous : « À quand remonte la dernière fois où vous avez vraiment réfléchi ? »
- Ce texte n’apporte ni solution ni conseil ; c’est simplement l’expression d’une frustration récente
Deux dispositions : Builder et Thinker
- Builder : la tendance à construire, livrer et produire des résultats concrets
- Motivé par la vitesse et l’utilité
- Dopamine d’un déploiement réussi, satisfaction de créer un système qui résout un vrai problème, plaisir de savoir que quelqu’un utilise son outil
- Thinker : la disposition qui exige une lutte mentale profonde et prolongée
- À l’université, quand j’étudiais la physique, on nous donnait des problèmes bien au-delà de la difficulté moyenne
- Même en comprenant les concepts, certains problèmes restaient difficiles rien que pour imaginer une méthode d’approche
Trois types d’étudiants face à un problème difficile
- Type 1 (la majorité) : essaie quelques fois, puis abandonne et demande de l’aide au professeur ou à l’assistant
- Type 2 (profil chercheur) : va à la bibliothèque chercher des problèmes similaires ou des indices jusqu’à rendre le problème abordable, et finit généralement par le résoudre
- Type 3 (profil Thinker) : n’aborde le problème que par la pensée
- Pendant plusieurs jours ou plusieurs semaines, consacre presque tout son temps cérébral en mode non-I/O à la possibilité de résoudre le problème
- La réflexion continue même pendant le sommeil
- Cette méthode n’a jamais échoué, et j’en suis venu à considérer que la pensée profonde et durable est ma force
- Je ne suis ni dans le top 1 % en rapidité ni doté d’un talent inné, mais j’ai la conviction qu’avec assez de temps, je peux résoudre n’importe quel problème
Le conflit avec l’IA
- Si l’ingénierie logicielle était au départ si satisfaisante, c’est précisément grâce à cette double satisfaction
- Elle nourrissait à la fois le Builder (le sentiment d’être productif et concret en créant quelque chose d’utile) et le Thinker (résoudre de vrais problèmes difficiles)
- Les projets où j’ai le plus grandi comme ingénieur contenaient toujours de nombreux problèmes difficiles exigeant des solutions créatives
- Mais récemment, les moments où je m’accroche plusieurs heures à un seul problème pour y réfléchir sérieusement ont fortement diminué
- Je pense que tout cela est la faute de l’IA
- J’écris plus de logiciel que jamais, et des logiciels plus complexes, mais j’ai l’impression de ne plus progresser du tout comme ingénieur
- En remontant à la source de ce sentiment de stagnation, j’ai compris que je suis en train d’affamer le Thinker
- Le « vibe coding » satisfait clairement le Builder
- Il y a un plaisir immédiat dans le fait de voir une idée se matérialiser presque instantanément
- En revanche, les moments où je dois moi-même inventer une solution créative à un problème technique se font beaucoup plus rares
- Pour les personnes purement orientées Builder, c’est l’époque idéale
- Mais pour moi, il manque clairement quelque chose
Le piège du pragmatisme
- J’anticipe l’objection suivante : « Si le vibe coding suffit à résoudre le problème, alors ce n’était pas un problème difficile au départ. »
- Mais cet argument passe à côté de l’essentiel
- L’IA n’est pas particulièrement brillante sur les problèmes difficiles, pas plus qu’elle ne produit toujours de bonnes solutions sur les problèmes faciles
- Si je réécrivais moi-même le même module pour la troisième fois, je suis convaincu que le résultat serait meilleur que n’importe quelle sortie générée par l’IA
- Mais en même temps, je suis pragmatique
- Si je peux obtenir une solution « suffisamment proche » en investissant une infime fraction du temps et de l’effort, ne pas choisir l’IA finit par paraître irrationnel
- Le vrai problème, c’est qu’il m’est impossible de désactiver consciemment ce pragmatisme
- Au fond, je suis un Builder, et j’aime l’acte même de construire. Si je peux construire plus vite, cela me paraît toujours préférable
- Même si j’essaie de rejeter l’IA pour revenir à une époque où les besoins du Thinker étaient naturellement satisfaits par le code, le Builder supporte mal cette inefficacité
- L’IA ne propose presque jamais une solution satisfaisante à 100 %, mais les solutions à 70 % qu’elle atteint répondent le plus souvent au critère du « suffisamment bon »
Que faire maintenant ?
- Honnêtement, je n’ai toujours pas trouvé de réponse, et je continue d’y réfléchir
- Je ne suis plus certain que ces deux dispositions puissent encore être satisfaites simultanément dans un seul et même domaine, celui du code
- Une option consiste à viser des projets plus difficiles et à chercher délibérément des problèmes sur lesquels l’IA échoue complètement
- J’en rencontre parfois, mais j’ai l’impression que les problèmes exigeant des solutions profondément créatives diminuent rapidement
- J’essaie aussi de retrouver, en dehors du code, cette sensation de croissance intellectuelle
- J’ai même rouvert de vieux manuels pour me reconnecter à la physique
- Mais cela ne m’a pas apporté de satisfaction réelle
- Lorsqu’il est possible de construire quelque chose, j’ai du mal à justifier auprès de moi-même le fait de dépenser du temps et de l’énergie mentale sur des problèmes de physique ni directement pertinents ni vraiment actuels
- Le tempérament Builder ne me laisse tout simplement pas m’asseoir pour méditer longuement sur des problèmes non résolus
- Le tempérament Thinker, lui, reste affamé tant que le vibe coding se poursuit
- Je ne sais pas si viendra de nouveau un moment où ces deux besoins pourront être satisfaits simultanément
« Nous avons désormais le droit de donner à cet être ce nom familier qui a toujours désigné ce qu’aucune puissance de l’imagination, aucun bond de la fantaisie la plus audacieuse, aucune foi la plus fervente, aucune pensée abstraite si profonde soit-elle, pas même l’esprit dans l’extase, n’avaient jamais pu atteindre : Dieu. Mais cette unité fondamentale appartient au passé ; elle n’existe plus. Dans le processus de transformation de son être, elle s’est entièrement, radicalement brisée en mille morceaux. Dieu est mort, et sa mort fut la vie du monde. »
— Philipp Mainländer
9 commentaires
Les types 1 et 2, c’était foutu d’avance,
ce sont des programmeurs sans les qualités requises,
et ça ne provoque un sentiment de crise
que chez ceux qui en restent au simple professionnalisme... Au fond, ce sont des gens
pour qui réfléchir est une corvée...
Pour les types 3, c’est plutôt un cadeau bienvenu.
Les types 3 l’utilisent déjà très bien, non ?
Quand un nouvel outil sort, ils ne sont pas les premiers à l’adopter avec enthousiasme ?
Moi, au début, j’ai essayé du code win32.
Mais comme prévu... c’était au niveau d’une Automation Interface
seulement.
Avec un truc pareil, je me suis dit d’emblée qu’on ne ferait jamais de la conception logicielle de grande qualité.
J’ai donc réfléchi à la meilleure façon d’en tirer parti au maximum.
Et pourtant, même à ce niveau, il y a beaucoup de choses à en faire.
Là aussi, si on réfléchit et qu’on se creuse la tête, c’est comme si on se donnait des bras et des jambes en plus... À mes yeux, le vrai problème, c’est de ne même pas chercher à penser comme ça.
Tu te fais juste des illusions. Pouvoir expérimenter vite, tester ce qui peut l’être et accumuler des données, c’est ça qui est rentable ; en quoi est-ce différent de dire « ah~ je m’en fiche, moi je suis du camp de la théorie~ » lol
J’ai surtout l’impression de voir quelqu’un hurler parce que la situation a fini par prouver que sa théorie, qui n’avait pas pu être vérifiée jusqu’ici faute de pouvoir être concrétisée, ne servait absolument à rien.
Si c’était un vrai penseur, il serait encore en train de réfléchir à quel problème résoudre dans cette situation, de l’identifier grâce à l’IA et de chercher une meilleure solution.
Je ne pense pas que ce soit un commentaire formulé dans le respect.
Sur mes 5 jours de travail, je passe une journée à ne pas utiliser de LLM pendant mes heures de travail, et le dimanche je n’utilise pas du tout de LLM ; c’est tout à fait faisable.
Ne pourrait-on pas simplement améliorer davantage le code généré par l’IA en ajoutant en plus des étapes de build et de réflexion en parallèle ?
Dans les énormes systèmes de niveau enterprise, choisir le bon modèle de traitement et définir une approche en pipeline reste un domaine où l’IA montre encore ses limites en matière de maturité, donc autant se tourner vers l’architecture.
Bien sûr, on peut se demander combien de temps ça durera...
À défaut, on assouvit son envie en résolvant des problèmes d’algorithmes difficiles, et on aborde le business de façon pragmatique — il n’y a pas vraiment d’autre solution.
Comme le tricot existe encore à l’époque où les machines fabriquent des vêtements, je me dis qu’on pourrait peut-être encore coder comme loisir.
À titre tout à fait personnel,
je me dis qu’on peut peut-être faire du cherry-picking du plaisir de construire et de celui de réfléchir.
On peut désormais créer quelque chose qui fonctionne à un coût vraiment faible (et en peu de temps),
et conserver le plaisir de voir les utilisateurs s’en servir, ainsi que celui d’avoir résolu un problème concret du quotidien.
Et si l’on consacre le temps ainsi gagné à des problèmes qui demandent une réflexion approfondie (c’est d’ailleurs ce que je fais en pratique),
alors cela a aussi son sens, et sans doute son propre plaisir.
Avis sur Hacker News
En mars 2025, le billet d’Aral Balkan m’a marqué
Coder, c’est comme façonner une motte d’argile pour lui donner la forme voulue. Ce processus permet d’apprendre les limites et les propriétés du matériau.
Avant de créer, c’est justement le moment où l’on sait le moins ce que l’on veut créer. Le design ne consiste pas seulement à résoudre un problème, mais à découvrir le bon problème.
Si l’on saute le processus créatif, on perd la dimension humaine de l’apprentissage et de la découverte. Une œuvre façonnée de ses propres mains, on la comprend dans les moindres détails ; un résultat sorti d’un distributeur n’est qu’une imitation qui en a l’apparence
Plus l’idée est nouvelle, plus l’outil cherche à la « normaliser », et il faut faire l’effort de résister à cette tendance.
Dans ce processus, on finit par définir clairement ce que son idée est, et ce qu’elle n’est pas. Dès qu’on cesse de pousser, le LLM recouvre l’originalité du projet
Mon travail consiste à combiner des outils déjà existants pour fabriquer quelque chose de nouveau.
Sauter le processus de fabrication ne diminue pas forcément la valeur de l’œuvre.
Par exemple, le fait que Zelda utilise le moteur physique Havok, ou qu’un jeu soit fait avec Unreal, ne l’empêche pas d’être excellent
Je suis fier du résultat produit ces trois dernières semaines en combinant Codex, Claude et des sessions de test.
Avant, l’objectif était de concrétiser une idée ; aujourd’hui, c’est de satisfaire le client et de respecter les délais et le budget
Cela permet de construire des systèmes complexes composés de milliers de pièces.
Autrefois, ce rôle était tenu par l’organisation de l’entreprise : les niveaux supérieurs rédigeaient les spécifications, les niveaux inférieurs fabriquaient les pièces
Avant, on reconnaissait très vite un site fait avec Ruby on Rails.
Si l’on confie le travail à une personne ou à un agent sans comprendre les caractéristiques du médium, c’est là qu’apparaît la différence entre du code propre et du code impossible à maintenir
Au final, la responsabilité revient à celui qui donne les consignes. Sans expérience du médium, on n’est pas prêt à évaluer le résultat
J’ai simplement moins de texte à taper, mais je réfléchis toujours autant
Les outils se sont améliorés, c’est tout ; programmer reste programmer.
Qu’on traverse le désert à dos de chameau ou en hélicoptère, un voyage reste un voyage.
Le fond n’a pas changé simplement parce que les outils ont évolué
On dirait que beaucoup ont oublié que des vécus différents peuvent coexister.
Le commentaire « je ne veux pas réfléchir » m’a particulièrement marqué
C’est très bien de passer au niveau d’abstraction supérieur, mais il faut aussi reconnaître ce qu’on y perd
Les LLM ne sont qu’une évolution des outils, mais la disparition de ce processus de pensée minutieux laisse un goût de regret
C’est plutôt donner du travail à quelqu’un d’autre et en faire la revue.
Ceux qui n’aimaient pas programmer s’en réjouiront, mais on ne peut pas appeler cela du « développement »
Quand j’écris moi-même le code, les structures de données se dessinent dans ma tête ; quand l’agent le fait à ma place, cette sensation disparaît.
Committer du code sans le comprendre n’a aucune valeur à mes yeux
Assimiler le coding basé sur les LLM aux abstractions existantes est une mauvaise analogie
Les compilateurs ou les frameworks visent des abstractions étanches, alors que les LLM sont intrinsèquement poreux
Au final, trouver et corriger les bugs reste toujours le travail des humains.
Les LLM réintroduisent ainsi l’incertitude et le risque que nous cherchions justement à éviter
Si tous les paramètres ne sont pas explicités dans le prompt, on obtient un résultat moyen.
On peut se demander si le langage naturel est vraiment adapté pour contenir ce type d’informations
Ce n’est pas une abstraction, c’est de la génération de code non déterministe
En ce sens, les LLM agissent aussi différemment sur notre manière de penser
Je suis plutôt un thinker, donc le coding avec l’IA ne m’intéresse pas beaucoup
J’aime construire moi-même un noyau d’OS ou un moteur graphique.
Plus que le résultat, c’est le processus de résolution du problème qui constitue mon hobby et ma satisfaction
À l’inverse, les builders s’enthousiasment pour l’IA parce qu’elle leur permet de créer plus vite
Tous les ingénieurs réfléchissent ; seuls les objectifs des outils diffèrent
Après des décennies à coder, les outils d’IA m’apportent une vraie liberté
Je peux expérimenter rapidement des idées que je n’aurais même pas essayé auparavant.
Grâce à cela, je peux faire avancer des projets perso dans de courts créneaux de temps
Grâce à l’IA, on peut enfin se concentrer sur la vraie réflexion.
J’ai désormais l’impression que la singularité approche
En cas d’échec, on apprend ; en cas de réussite, on peut se concentrer sur la validation de la qualité
Il existe plusieurs formes de réflexion
Il y a la pensée concentrée, en immersion totale, et celle qui mûrit lentement en arrière-plan.
Ces deux formes relèvent d’une immersion profonde, et ce sont justement des choses qu’il est facile de perdre à l’ère de l’IA
Résolution de problèmes mathématiques, réflexion philosophique, contraintes complexes du travail concret : chacune apporte une forme différente de tension intellectuelle
Au fond, ce qui compte, c’est l’expérience d’une immersion profonde, quelle qu’en soit la forme
Parmi les ingénieurs seniors autour de moi, je vois deux catégories
Certains ont obtenu un léger gain de productivité, mais chez d’autres, la profondeur de réflexion a diminué
Ils copient-collent souvent telle quelle la réponse proposée par le LLM.
Le vrai problème, c’est l’absence de capacité à poser les bonnes questions
Dans les systèmes matures, cela représente souvent plus de 90 % du travail
Je regrette que des collègues ingénieurs, fascinés par l’IA, aient bradé l’essence même de leur métier
Nous possédions les moyens de production, et nous y avons renoncé de nous-mêmes
Si l’IA rend le développement moins cher et plus rapide, le marché pourrait au contraire s’élargir
Le progrès technologique désavantage toujours certaines professions, mais il apporte aussi un progrès pour la société dans son ensemble
De la même manière que nous avons jadis réduit les emplois d’autres industries par l’automatisation, c’est maintenant notre tour
Il n’en résulte que du vide. Mais c’était peut-être précisément leur but
La logique du « on peut le faire, donc on le fait » finit par faire perdre notre humanité
L’IA ne supprime pas la pensée. Le problème, ce sont les entreprises médiocres et les manières de penser médiocres
Il faut aller là où les entreprises accordent une vraie valeur à la réflexion
Moi aussi, je code avec des LLM, mais je réfléchis toujours en profondeur
Je pense à l’architecture, aux risques, aux contraintes, à la dette technique, aux alternatives, etc.
Cela ressemble davantage à une pensée de gestion, qui navigue et coordonne plusieurs contextes à la fois,
qu’à la pensée d’un scientifique absorbé pendant plusieurs jours par un seul problème
Les PR des juniors qui utilisent l’IA sont devenues plus longues et plus complexes,
et désormais, l’essentiel de mon travail est centré sur la revue
Ils sont utiles pour le prototypage rapide, les fonctions utilitaires, l’autocomplétion de code, l’exploration de bibliothèques, etc.
Au contraire, comme les tâches simples diminuent, je réfléchis davantage
Avant, écrire le code amenait à reconsidérer la réflexion de plus haut niveau sur la conception ;
aujourd’hui, ce processus s’est réduit, ce qui conduit à penser « moins en profondeur »