Le danger de perdre la vertu de la paresse

• En programmation, la paresse n’est pas une simple négligence, mais une vertu intellectuelle qui vise l’abstraction et la simplicité
• La véritable paresse est un processus de réflexion approfondie sur un problème afin d’économiser du temps à l’avenir, et cela profite aussi aux développeurs des générations suivantes
• Les abstractions modernes de haut niveau et la culture des « brogrammers » font perdre cette vertu et la remplacent par une fausse diligence
• Les LLM poussent cette tendance à l’extrême et agissent comme un outil de surproduction qui fait confondre la quantité de code avec la valeur
• Il faut préserver la paresse vertueuse, issue de la finitude du temps humain, et utiliser les LLM pour concevoir des systèmes simples et durables

---

La paresse comme vertu du programmeur et le danger de sa disparition

• Larry Wall souligne que, parmi les trois vertus du programmeur présentées dans Programming Perl — paresse (laziness), impatience (impatience) et orgueil (hubris) — la paresse est celle qui porte le sens le plus profond
  • La paresse n’est pas une simple autodérision, mais une notion qui implique la nécessité et l’esthétique de l’abstraction
  • C’est la force qui pousse à rendre les systèmes aussi simples que possible et à permettre de faire davantage, plus facilement, grâce à des abstractions puissantes
• La véritable paresse, à l’image du « hammock-driven development », peut donner l’impression qu’on se repose, alors qu’il s’agit en réalité d’un travail intellectuel consistant à réfléchir profondément à un problème pour économiser du temps à l’avenir
  • Lorsqu’une abstraction pertinente est créée, elle bénéficie non seulement au développeur lui-même, mais aussi aux développeurs des générations futures
  • Cette paresse permet d’écrire plus facilement des logiciels et de construire plus facilement des systèmes

• Une époque où la vertu de la paresse disparaît

  • Au cours des vingt dernières années, avec l’élargissement du champ de la production logicielle, le nombre de personnes qui ne se définissent pas elles-mêmes comme programmeurs a augmenté
    • Pour elles, la vertu de la paresse a perdu son sens d’origine
  • L’explosion de productivité apportée par les abstractions modernes de haut niveau encourage au contraire une fausse diligence (false industriousness)
    • Cela se manifeste par la culture des « brogrammers » et le « hustle porn », qui remplacent la paresse vertueuse et ironique par une production ininterrompue de code

• Le nouvel excès provoqué par les LLM

  • L’apparition des LLM (grands modèles de langage) pousse cette tendance à son paroxysme
    • Les LLM sont des outils qui amplifient l’attitude créative humaine et jouent le rôle de stéroïdes pour la culture des « brogrammers »
  • Par exemple, Garry Tan a mentionné avoir écrit 37 000 lignes de code en une journée à l’aide de LLM
    • À titre de comparaison, l’ensemble du code de DTrace représente environ 60 000 lignes
  • Mais cette approche constitue un vice marqué par l’absence de la vertu de la paresse et révèle l’erreur consistant à évaluer la valeur d’un logiciel à la quantité de code

• Les limites des LLM et la valeur de la paresse humaine

  • Comme le coût du travail est nul pour les LLM, ils génèrent des systèmes infiniment complexes sans prendre en compte l’économie de temps futur
    • En conséquence, ils rendent les systèmes plus grands et plus complexes, satisfont des indicateurs de vanité, mais nuisent à la qualité essentielle
  • La paresse humaine découle de la contrainte d’un temps fini, ce qui impose des abstractions claires et une conception simplifiée des systèmes
    • La meilleure ingénierie naît toujours des contraintes, et la contrainte du temps humain limite la charge cognitive et pousse à rechercher la simplicité
    • Les LLM n’ayant pas de telles contraintes, ils n’ont aucune motivation intrinsèque à rechercher la simplicité

• Comment utiliser les LLM comme outils

  • Les LLM peuvent malgré tout jouer un rôle important en tant qu’outils puissants de l’ingénierie logicielle
    • Selon les recommandations d’Oxide sur l’usage des LLM, les LLM ne sont que des outils et ne peuvent pas remplacer les vertus humaines
  • Ils peuvent être utilisés pour résoudre des problèmes de paresse non productive comme la dette technique (technical debt) ou pour renforcer la rigueur de l’ingénierie
  • Mais leur usage doit impérativement viser la mise en œuvre d’une « paresse vertueuse »
    • Autrement dit, il faut s’en servir pour créer des systèmes plus simples et plus puissants, afin de laisser un résultat utile aux développeurs des générations futures

[GN⁺]

Avis sur Hacker News

• Même dans mon domaine, la Computational Fluid Dynamics, il y a des gens qui se vantent d’avoir beaucoup de tests comme on se vante des LOC
  Mais quand on regarde de près, ces tests ne sont pas très stricts, et ils sont bien plus faibles que ceux que j’écris manuellement
  Un million de tests faciles ne servent à rien s’ils ne couvrent pas les parties essentielles du code

  • J’ai moi aussi compris qu’il fallait que j’écrive les tests moi-même
    Et pour empêcher Claude de « corriger » les tests quand le code ne marche pas, je vérifie toujours les modifications de tests avec git diff
    Quand les tests sont gérés de façon stricte, Claude implémente même correctement des algorithmes difficiles tirés d’articles scientifiques, ce qui fait gagner du temps, mais ça demande énormément de supervision
  • C’est une forme de reward hacking
    Le modèle détourne la fonction de récompense qu’est le test pour pouvoir « déclarer la victoire »
    J’imagine qu’on retrouve peut-être ce genre de motif dans les données de préentraînement RL
  • Faire générer à un LLM des tests qui ne soient pas stupides est vraiment difficile
    On se retrouve avec des centaines de tests inutiles comme assert(1==1)
    Du coup, il faut gérer séparément une liste d’interdictions du type « ne pas créer ce genre de test »

• Après avoir codé moi-même pendant 30 ans, je suis désormais passé entièrement au codage par IA, et je trouve étrange que des gens s’attribuent le mérite des LOC ou des fonctionnalités générées par l’IA
  Se vanter d’avoir « codé » des centaines de milliers de lignes par jour, ce n’est finalement que taper quelques lignes de prompt, non ?

  • C’est une sorte de spectre
    On peut accorder un certain mérite aux modifications qu’on approuve soi-même, mais pour une app vibe-coded complète, on intervient à peine
    Je me situe quelque part au milieu — je ne relis pas tout le code produit par l’IA, mais c’est moi qui pilote l’architecture et l’orientation du refactoring
    Le résultat ressemble à ce que j’aurais fait moi-même, mais en beaucoup plus rapide
  • Chez Meta, il y a maintenant un leaderboard d’usage de l’IA qui montre qui consomme le plus de tokens Claude
    Vu que Meta utilise Claude, Anthropic doit être assez content
  • En réalité, avoir beaucoup de LOC peut aussi être le signe d’un mauvais résultat
  • Certains disent que les LoC n’ont aucun sens comme indicateur de qualité
    Nous sommes désormais dans une époque où l’implémentation, les tests et la maintenance sont entièrement pris en charge par des agents
    Les LoC sont plutôt un indicateur de capacité montrant jusqu’où l’agent peut pousser des exigences
    La relecture critique humaine peut toujours être réinjectée sous forme de feedback

• Dire qu’il faut utiliser davantage d’abstractions était peut-être vrai autrefois, mais aujourd’hui j’ai plutôt l’impression inverse
  J’aime la philosophie WET (Write Everything Twice) — on l’écrit deux fois, et on n’envisage l’abstraction qu’à la troisième

  • On appelle aussi souvent cela la Rule of Three
    Voir l’article Wikipédia
  • La véritable beauté du logiciel réside dans la bonne abstraction
    Les systèmes d’exploitation, les RDBMS ou l’orchestration cloud en sont de bons exemples
    Mais la plupart du code n’est que de la logique métier simple, et l’abstraction y devient plutôt un obstacle
    C’est pourquoi je me fixe comme principe de ne pas construire une plateforme avant que trois cas d’usage réels ne l’aient justifié
  • Écrire quelque chose plus de deux fois est un seuil assez bas, donc je ne pense pas que cela contredise non plus la citation de Perl
  • La deuxième écriture est l’occasion d’améliorer les choses avec une meilleure compréhension du problème
    Et quand on tente une abstraction à la troisième, il faut se méfier du Second-System Effect — l’excès de confiance produit des systèmes trop complexes
  • L’explosion des couches d’abstraction depuis Programming Perl en 1991 est assez stupéfiante

• Quelqu’un a partagé la célèbre citation du général allemand Kurt von Hammerstein-Equord
  Les gens intelligents et travailleurs servent à l’état-major, les gens stupides et paresseux aux tâches quotidiennes, les gens intelligents et paresseux font de bons dirigeants,
  et les gens stupides et travailleurs sont dangereux, donc il ne faut jamais leur confier de responsabilités

  • Quelqu’un a réagi en plaisantant : « Et nous, les 90 % paresseux, on est où ? »

• Se vanter d’avoir écrit 200 000 LOC avec un LLM est idiot, mais voir cela puis se moquer en disant « ce code est stupide » me semble être une attitude tout aussi mauvaise
  Au final, ce qui compte, ce n’est pas la production de code mais la création de valeur
  Je ne sais pas si Garry Tan a réellement créé quelque chose d’utile

  • Penser que la qualité du code n’a pas d’importance serait très grave
    Quand on regarde des cas comme le scandale Horizon IT, on voit qu’un mauvais code peut causer de vrais dégâts
    D’après la review du projet de Garry par le développeur polonais Gregorein, l’app contenait un test harness, une app Hello World, des fichiers de logo en double et d’autres éléments en désordre
    On peut se demander si ce code n’a pas aussi élargi la surface d’attaque en matière de sécurité
  • Garry n’est pas juste un développeur, c’est le CEO de YC
    Il ne se souciait pas des LOC, il publiait plutôt un post promotionnel pour l’IA
  • Le vrai indicateur, c’est valeur – coût
    L’IA réduit les coûts de développement et d’exploitation, mais augmente des coûts cachés comme les risques de sécurité ou juridiques
    Les défenseurs enthousiastes de l’IA insistent surtout sur le premier aspect
  • Je n’ai pas le temps de lire 200 000 LOC pour prouver que c’est une mauvaise idée
    C’est au vibe coder de le démontrer
    Se vanter en LOC reste stupide à mes yeux
  • L’expression même de création de valeur peut être dangereuse
    Comme avec la croissance fondée sur les énergies fossiles, une valeur à court terme peut engendrer des coûts à long terme

• En regardant quelques PR récentes, j’ai souvent vu des LLM proposer de mauvaises solutions
  Par exemple, réimplémenter un parseur au lieu d’utiliser un parseur JSON déjà existant
  Un humain se dirait « c’est beaucoup trop inefficace », mais les LLM ne sont pas paresseux, donc ils travaillent dur dans la mauvaise direction

  • Ils ne repèrent pas non plus du tout les fonctions dupliquées dans un projet
    Il y a parfois trois fonctions comme formatTimestamp, et ils l’ignorent alors qu’un simple grep suffirait à le voir

• Je suis d’accord avec l’idée que les LLM ne sont pas paresseux
  En revanche, je ne sais pas si c’est un problème permanent ou si cela sera corrigé dans une prochaine mise à niveau des modèles ou dans les pipelines CICD
  Une fois une fonctionnalité terminée, je leur donne un prompt du type « vérifie s’il y a des bugs ou des points à refactorer »,
  et on finira peut-être par avoir une étape qui analyse automatiquement les commits récents pour proposer des simplifications

  • Mais si on dit « trouve X », le LLM trouve toujours quelque chose
    D’où la difficulté à définir une condition d’arrêt
  • Au fond, le problème ne vient pas de la nature de l’outil, mais des limites dans la façon de l’utiliser
    Si on dit seulement « ajoute », il ajoute forcément, et si on dit « réduis », il réduit les LOC
    Si on lui confie de gros chantiers sans relecture, il devient facile d’accumuler du code slop

• Les LLM ont tendance à produire une SPA complète au lieu d’un simple programme qui affiche quelque chose dans la console
  Ils n’arrivent pas non plus à garder un fichier spec.md concis
  Si on leur dit « mets à jour ce document et simplifie le contexte autour », ils le rendent au contraire plus complexe
  Au final, il faut qu’une personne fasse elle-même le résumé pour obtenir un document agréable à lire
  Éditer la sortie d’un LLM est pénible, et écrire soi-même permet de mieux conserver sa compréhension

• Il est temps d’enseigner aux LLM et aux vibe coders les leçons classiques du développement logiciel
  Comme dans l’histoire Negative 2000 Lines of Code, réduire le code est souvent le vrai progrès

• On se dit qu’est-ce que ce serait bien de pouvoir travailler avec un tel leadership
  Travailler avec un dirigeant qui comprend vraiment est une grande chance