Je suis plus heureux quand j’écris du code à la main

• Après avoir utilisé à plusieurs reprises des outils de génération de code basés sur les LLM, l’auteur a redécouvert le sentiment de flow et de plaisir ressenti lorsqu’il écrit lui-même son code
• Écrire du code n’est pas un simple acte de production, mais un processus de compréhension de l’espace du problème et d’affinement de la pensée, que la génération automatique vient perturber
• Il est difficile de vérifier l’exactitude d’un code qu’on n’a pas écrit soi-même, et seul le fait d’écrire directement permet d’intérioriser le contexte
• En utilisant les LLM de manière limitée, pour fournir manuellement le contexte et ne les employer que pour de petites modifications de code ou la génération de tests, on conserve la maîtrise de son raisonnement
• L’auteur insiste sur le fait qu’il faut privilégier la profondeur de la réflexion et le sentiment de bonheur plutôt que la seule productivité, et se méfier des outils qui entravent la pensée

---

Expérience d’utilisation de la génération de code par LLM et remise en question

• Il a utilisé claude-code à plusieurs reprises, mais a ressenti à chaque fois un sentiment de déprime et d’apathie, jusqu’à finir par le supprimer
  • Le code généré automatiquement « paraît plausible », mais lui fait perdre le sens de ce qu’il est en train de faire
  • Chaque fois qu’il cesse d’utiliser l’outil, il retrouve le plaisir de coder
• Coder n’est pas seulement implémenter, c’est aussi explorer l’espace du problème et apprendre par l’échec
  • Pour vraiment comprendre une API, il faut l’utiliser soi-même ; lire la documentation ne suffit pas
  • L’acte même d’écrire du code est un moyen de rendre la pensée concrète

Le lien entre pensée et exactitude

« Si vous ne faites que penser sans écrire, vous vous contentez de croire que vous pensez. » - Leslie Lamport

• Il est bien plus difficile de vérifier l’exactitude d’un code qu’on n’a pas écrit soi-même
• Le processus d’écriture directe permet d’intérioriser le contexte du problème, ce qui est essentiel pour comprendre la qualité du code
• Dépendre des LLM conduit à sauter cette étape et affaiblit la compréhension du domaine du problème

Le caractère addictif du « vibe coding » et ses effets secondaires

• La génération de code par LLM a un caractère addictif, car elle procure une récompense dopaminergique immédiate
  • Elle nourrit l’illusion que « si je modifie encore un peu le prompt, ça finira par marcher »
• Cette manière de faire renforce l’inertie de la pensée, rend le cerveau passif et pousse à dépendre du LLM même pour des tâches simples
  • Par exemple, confier au LLM un simple find-and-replace a même fini par faire perdre plus de temps
• Même si beaucoup de code est généré, la responsabilité de la relecture et de la compréhension reste finalement humaine, ce qui crée au contraire un goulot d’étranglement

La façon dont les outils façonnent la pensée

• Dans la perspective selon laquelle « les outils ne sont pas neutres », un outil qui entrave la pensée est un mauvais outil
  • La compétence clé des travailleurs du savoir est la capacité à penser en profondeur, et il faut se méfier des technologies qui l’entravent
• Cela dit, l’auteur n’exclut pas totalement les LLM et les utilise de manière intentionnelle et limitée
  • Il copie uniquement les fichiers nécessaires pour fournir le contexte, et ne les utilise que pour de petites modifications de code ou l’écriture de tests
  • De cette façon, l’ampleur des changements générés reste réduite et il peut comprendre lui-même la structure globale de la codebase
  • On passe ainsi d’une génération passive à une « génération réfléchie », ce qui permet de maintenir l’activité du cerveau et l’état de flow

L’équilibre entre bonheur et productivité

• La vie est courte, et il faut faire passer le bonheur en premier
  • Générer automatiquement une fonctionnalité entière peut certes améliorer la productivité, mais si cela provoque une anxiété existentielle et un sentiment dépressif, cela devient contre-productif à long terme
• L’auteur reconnaît qu’on peut ou non se retrouver dans ce ressenti, mais conclut :
  « N’ayez pas peur de choisir autrement »

[nimgnos]

Il y a bien des gens qui aiment faire leurs calculs à la main, ou de tête, même s’il existe des calculatrices.

[su79eu7k]

Je pense avec prudence que le fait d’écrire soi-même à la main les parties très complexes et essentielles à la logique métier, d’y réfléchir, puis d’inculquer cela aux ingénieurs IA pourrait peut-être aider la productivité. Les mathématiciens aussi utilisent des outils comme la calculatrice, mais lorsqu’ils réfléchissent à une idée centrale, ils prennent souvent beaucoup de notes, non ?

[naruchingu]

Même dans un monde où l’on peut prendre une photo en un instant avec un téléphone, certains choisissent encore de passer des heures à dessiner. Ce n’est qu’une différence de processus et de direction, pas une question de bien ou de mal.

[wkdehf555]

J’ai surtout l’impression qu’il s’agit d’une déclaration d’intention qui va frontalement à l’encontre de la direction que poursuivent les entreprises…

[dolsangodkimchi]

Je respecte l’idéal de bonheur et d’épanouissement personnel de chacun, mais du point de vue d’un métier où l’on fournit du travail contre rémunération, cela me semble être un état d’esprit inapproprié.

[foriequal0]

Si quelqu’un ignore des métriques de long terme pour ne courir qu’après des métriques de court terme, même une personne totalement étrangère au sujet pourrait avoir envie de passer en lançant : « Ce n’est pas comme ça qu’on fait, pff. »
Alors, si c’est un programmeur qui pense partager le destin de l’entreprise, y apporter une contribution majeure et y jouer un rôle important, à quel point ce sentiment doit-il être encore plus fort ?

[geeksk553]

En réalité, les développeurs vraiment compétents, ceux qui savent très bien développer, aiment le vibe coding...

Ce n’est pas de moi que je parle (comme Linus Torvalds ou Robert Martin).

[dieafterwork]

Je ne l’utilisais que pour des scripts Python. Je ne dirais pas vraiment que j’y prenais du plaisir.

[cocofather]

D’après ce que j’ai trouvé dans les articles sur Linus Torvalds, il semble qu’il l’utilise comme hobby et qu’il ne s’en serve pas encore pour le développement de Linux.

[GN⁺]

Avis sur Hacker News

• Le codage est comparé au travail du bois. Même si des machines peuvent fabriquer des meubles, certaines personnes continuent de les faire à la main. Le codage manuel peut de la même façon rester un plaisir, mais il deviendra difficile d’en vivre professionnellement à l’avenir

  • Cette analogie semble mal fonctionner. Une scie électrique est une technologie centaure dirigée par l’humain, alors que la GenAI est au contraire une technologie centaure inversée où l’humain assiste. Une scie électrique ne remplace pas la personne, mais l’IA peut réduire une équipe de moitié
  • Le travail du bois produit le même objet en série, mais le code ne se répète pas. Dans la plupart des projets, le goulet d’étranglement est la collecte des besoins ou la conception, donc l’écart de productivité entre codage manuel et codage avec IA reste limité
  • Quelqu’un demande si la transition langage naturel → code ressemble au passage des langages de haut niveau vers l’assembleur. La « complexité essentielle » de Brooks disparaît, et grâce à des motifs standardisés, l’époque arrive où l’IA transforme des intentions ambiguës en code exécutable. Au final, la valeur des experts augmente, mais la demande pour les ingénieurs standard diminue
  • La question posée est : « Si nous ne pouvons plus faire de codage manuel comme métier, pour quoi sommes-nous payés ? » Certains se demandent si l’on finit réduit à faire du support client ou à devenir rédacteur de prompts LLM
  • Ce serait triste si le codage manuel n’était plus jugé précieux. Cela reste agréable, mais la perte de valeur fait mal

• Je choisis, sur le long terme, la méthode qui donne les résultats les plus rapides et les meilleurs. Pour l’instant, c’est neovim et le codage manuel. Taper directement et comprendre le projet en profondeur permet de livrer plus vite sur la durée. Je confie au LLM ce qui n’aide pas à apprendre, donc je l’utilise souvent car ce type de tâches est fréquent

  • L’idée que « la compréhension profonde accélère sur le long terme » est marquante
  • Je travaille de la même manière. Je conseille à mon équipe d’optimiser non pas pour dans 6 mois, mais dans 2 ans
  • Je ne fais moi-même que ce qui apporte un apprentissage, et j’essaie d’automatiser au maximum le reste
  • Utiliser plusieurs agents provoque beaucoup de changements de contexte, et donne au contraire l’impression de perdre le contexte global

• Le problème du vibecoding, c’est que le fait de « se sentir bien » brouille les résultats réels

  • Cela ne fait du bien qu’à certaines personnes ; moi, je prends du plaisir dans une compréhension profonde du problème et du code
  • Lire une vibe doc, pourquoi pas, mais le vibe coding produit du code verbeux, avec trop d’abstractions, difficile à comprendre, et que j’hésite à signer de mon nom
  • Même avec un plan, on finit souvent par devoir tout recommencer depuis le début, ce qui est frustrant
  • Il est difficile de distinguer une vraie hausse de productivité d’une simple impression
  • J’ai essayé avec Windows Copilot, mais c’était lent et de faible qualité, donc sans aucun plaisir

• Quelqu’un pose avec cynisme la question : « Être heureux multiplie-t-il vraiment par 200 la quantité de code produite ? »

• L’IA a clairement de la valeur. Par exemple, pour convertir une table DB de 300 colonnes en struct Rust, un prompt de 15 mots a généré 900 lignes de code. Pour ce genre de travail répétitif, l’IA est parfaite. Mais je ne veux pas tout lui confier. Je l’utilise seulement à un niveau d’usage qui reste agréable

  • Cette approche peut empêcher d’améliorer un mauvais schéma ou une mauvaise conception
  • J’ai l’impression qu’écrire un script de génération de code en Python est préférable. L’IA a des problèmes de fiabilité, comme modifier subtilement les noms de champs
  • Le coût énergétique d’un humain qui code en buvant du café est bien plus élevé que celui de l’IA
  • L’usage de l’IA donne une impression de dépendance à la dopamine

• La vraie question, c’est : « Que fais-je pendant que le LLM écrit le code à ma place ? » On ne peut pas lui tout déléguer, c’est plutôt comme s’en occuper à côté. Un développeur junior progresse, mais un LLM n’apprend pas. Du coup, on a l’impression de perdre la gratification du mentorat

  • Moi, je fais tourner plusieurs agents en parallèle pour développer des fonctionnalités, corriger des bugs et mettre à jour la documentation. Il reste toujours beaucoup à faire, ce n’est pas du doomscrolling

• Certains se demandent comment le recrutement des développeurs a changé récemment. L’usage des LLM est-il autorisé, ou demande-t-on encore du codage manuel ?

  • Les grandes entreprises évoluent encore lentement. Elles hésitent à utiliser du code généré par IA à cause des questions de propriété juridique
  • À l’avenir, on demandera sans doute à la fois du codage manuel et du codage avec IA. Le recrutement ajoute simplement un filtre de plus, comme toujours
  • Les entreprises de taille intermédiaire ont gelé les embauches ou ne recrutent plus que des développeurs qui utilisent l’IA. Les grandes entreprises continuent à demander Leetcode et de la conception de systèmes
  • La plupart des entreprises ne mesurent pas encore l’ampleur de la triche au LLM

• Avant même les LLM, je développais déjà à une vitesse proche du vibecoding avec le développement piloté par les modèles (MDD). Le modèle de données est l’application, et le LLM ne fait qu’écrire un peu plus vite les procédures au-dessus. C’est toujours moi qui décide de l’orientation du modèle de données

• Le codage avec IA se divise en trois catégories

  1. Recherche de code déjà présent en ligne
  2. Code totalement nouveau, où l’IA n’est qu’une aide à la saisie
  3. Génération de code répétitif et rempli de boilerplate — et cela, c’est l’échec des frameworks
  • Ce que l’IA fait bien est peut-être justement ce qu’il ne faudrait pas faire. Le vrai défi est de trouver un langage qui exprime élégamment ce que nous voulons
  • Les frameworks n’ont pas su progresser, et les LLM sont devenus un outil qui voit tous les problèmes comme un marteau

• La société moderne se transforme en système où l’on obtient de la dopamine en cliquant sur des boutons. C’est pour cela que tout semble partir en vrille

  • Une remarque ironique souligne que les machines à sous sont devenues l’UX ultime

[redline2151]

Ces derniers temps, il y a sans arrêt des posts de développeurs dépassés qui se rassurent comme ils peuvent. De toute façon, on ne pourra pas arrêter le sens de l’époque.

[cjm01115]

Là, on dépasse vraiment les bornes.

[geeksk553]

Je suis aussi d’accord avec cet avis : même si l’on s’obstine à coder entièrement à la main, à moins de travailler seul, on finira forcément par être remplacé, et j’ai l’impression que certaines personnes ne s’en rendent pas compte.

[hmmhmmhm]

Oh là, c’est un peu dur comme remarque, ouin