1 points par GN⁺ 2 시간 전 | 1 commentaires | Partager sur WhatsApp
  • En reprenant le concept central de Quality (qualité) du best-seller de 1974 "ZAMM", l’article examine si le « bon code » et l’éthique de l’artisan (craftsman ethos) restent pertinents à l’époque de la généralisation des outils de codage IA
  • À mesure que l’IA produit du code en masse, l’auteur nomme the Maw (le gouffre du néant) la crainte qu’il ne reste plus que du « code qui fonctionne et du code qui ne fonctionne pas », et que disparaisse toute distinction entre un code beau, excellent ou véritablement valable
  • L’entretien d’une moto et la maintenance logicielle sont fondamentalement la même activité, dont le cœur est fait d’observation minutieuse et de pensée précise
  • Le concept de Quality chez Pirsig unifie la compréhension romantique (romantic) et classique (classical), et implique que même les fondements de la science et des mathématiques contiennent des jugements esthétiques et de qualité
  • Déléguer le codage à des agents IA fait perdre le caring (l’identification à son travail) et le « sens de la qualité du travail » ; il est donc important de viser l’excellence humaine (human excellence) dans ce que l’on fait

Le livre ZAMM

  • Cet article porte presque entièrement sur le best-seller de 1974 "Zen and the Art of Motorcycle Maintenance (ZAMM)", tout en parlant aussi d’IA
  • ZAMM est souvent considéré comme un livre prétentieux (pretentious), avec une note GoodReads de 3.78, mais aussi de nombreuses critiques très négatives
    • « Zora » lui donne 1 étoile, le qualifiant de pseudo-ouvrage philosophique déguisé en roman, qui ne mérite pas trois minutes de lecture et constitue une arnaque plus grande que la Bible
    • « Lala BooksandLala » lui donne 1 étoile avec ce seul commentaire : « absolutely not »
  • L’auteur reconnaît franchement qu’un billet de blog sur ZAMM et l’IA ne sonne pas forcément comme la lecture la plus joyeuse du monde

the Maw — le gouffre du néant qui s’est ouvert dans la tech

  • the Maw est un gouffre de nihilisme ouvert au cœur de l’industrie tech ; c’est le sujet d’environ 63 % des billets de blog de type agrégateur de liens comme Hacker News
  • Parmi les textes récents sur le sujet, on trouve “Do I Belong in Tech Anymore?”, la série en 10 parties “The Future of Everything is Lies, I Guess.”, ou encore “I Think I’m Done Thinking About Gen AI for Now,”
  • Les ingénieurs logiciels n’ont en général pas peur des nouvelles technologies, et pourtant ils cherchent des raisons de rejeter les derniers outils de codage agentiques, gênés par l’idée que l’algèbre linéaire écrive désormais des logiciels
  • Le débat Commenter A vs Commenter B

    • Le commentateur A se plaint que Claude Code ait choisi un nom de fonction subtilement trompeur
    • Le commentateur B, adepte du Maw, répond que l’IA lit le corps entier de la fonction pour en comprendre le sens, donc que le nom n’a plus d’importance et que bientôt les humains ne liront plus le code
    • La thèse du commentateur B revient presque à dire que toute la discipline du génie logiciel — bonnes pratiques, architecture, maintenabilité — devient inutile
  • Ce que the Maw a de plus effrayant, c’est sa tentative d’abolir à jamais la distinction entre le bon et le mauvais, pour ne laisser qu’un monde où il n’existe que du code qui marche et du code qui ne marche pas, sans code beau, excellent ou ingénieux
  • Les questions centrales sont donc : existe-t-il encore de bons programmeurs et du bon code ?, pourquoi le “bon” est-il important ?, et à quoi ressemble un bon programmeur qui utilise des outils d’IA ?

ZAMM est en réalité un livre sur la programmation

  • ZAMM pourrait pratiquement s’intituler "Zen and the Art of Software Maintenance", tant l’entretien d’une moto et la maintenance logicielle sont, au fond, la même activité
  • L’essence de la maintenance n’est pas le travail physique, mais l’observation minutieuse et la pensée précise ; le mécanicien se concentre sur des images mentales et des hiérarchies (chapitre 9 de ZAMM)
  • Qu’il s’agisse d’une panne moteur ou d’un service web bloqué sur un deadlock, le processus de débogage est le même ; comme dans le mème « wired in » de The Social Network (2010), le mécanicien bâtit lui aussi des tours d’abstractions dans sa tête
  • Les conseils physiques directs de ZAMM sont au nombre de deux seulement (placer des chaises de chaque côté du vélo pour ménager son dos, manipuler délicatement les pièces de précision) ; tout le reste concerne l’état d’esprit du mécanicien
  • Le Gumption Trap (piège de la motivation)

    • Gumption désigne la réserve de volonté mobilisée pour l’activité intellectuelle qu’est la maintenance, comparée à une « psychic gasoline »
    • Un gumption trap est un événement qui vide d’un coup cette motivation pendant la maintenance
      • intermittent failure setback : le problème disparaît dès qu’on essaie de le réparer, l’équivalent en logiciel d’un could-not-reproduce / Heisenbug
      • impatience trap : on sous-estime le temps nécessaire, on se retrouve pressé par le planning, on prend des raccourcis, puis on accumule un gros retard à cause d’une erreur plus grave
  • Pirsig était un passionné d’informatique

    • Le Smithsonian expose une Apple II avec 7 cartes d’extension, aux côtés de sa Honda Super Hawk de 1966
    • L’Apple II est sortie en 1977, donc Pirsig l’a achetée après la publication de ZAMM, mais il avait déjà travaillé auparavant comme technical writer chez Honeywell
    • ZAMM contient plusieurs analogies avec les circuits et les manuels d’ordinateurs numériques ; si le livre avait été écrit 10 à 20 ans plus tard, il aurait probablement porté sur l’informatique

Quality (avec un Q majuscule) — l’idée centrale de ZAMM

  • Si ZAMM parle de maintenance, c’est en réalité pour mener à son idée maîtresse : Quality (la qualité)
  • ZAMM est construit presque comme un roman policier intellectuel
  • Le point de départ se trouve au chapitre 1, quand Pirsig remarque que son rapport à la moto diffère profondément de celui de son compagnon de route John
  • Le contraste entre John et Pirsig

    • John achète la BMW allemande la plus fiable possible pour éviter le tracas laid et pénible de faire lui-même la maintenance
    • Pirsig, lui, voit de la beauté dans le fonctionnement interne de la moto et juge peu pratique le refus de le comprendre
    • Le mystère de ZAMM consiste à savoir s’il existe une idée capable de relier ces deux visions
    • L’attitude de John relève d’une compréhension romantique (romantic) — émotions et impressions immédiates — tandis que celle de Pirsig relève d’une compréhension classique (classical) — formes fondamentales et abstractions logiques
    • Pirsig estime que, dans les années 1960-70, beaucoup voyaient la technologie comme quelque chose d’hostile, de contrôlant, de « square », et que la société comme la technique étaient devenues trop dominées par la compréhension classique, provoquant la séparation entre ces deux modes de compréhension
    • Puisque ces deux compréhensions se sont dissociées et que la société est dominée par la compréhension classique, il faut une fulcrum idea (idée-pivot) pour les réconcilier
  • L’intuition née des cours de rhétorique

    • Pirsig se souvient de l’époque où il enseignait la rhétorique à l’université et s’interrogeait sur ce qu’il devait réellement enseigner à ses étudiants
    • Sa mission était d’apprendre à ses étudiants à bien écrire
    • On enseignait la bonne écriture à travers des procédés comme la metaphor (métaphore), le parallelism (parallélisme) ou l’anaphora (anaphore), mais un texte peut être mauvais tout en contenant tous ces procédés, et bon sans aucun d’eux
    • Les étudiants savaient distinguer un bon texte d’un mauvais même sans connaître ces procédés, ce qui supposait une compréhension romantique difficile à enseigner à l’université, bastion de la compréhension classique
    • Ce que Pirsig essayait en réalité d’enseigner, c’était Quality
      quelque chose que tout le monde reconnaît mais qu’on ne peut pas définir formellement, et le concept qui relie la compréhension romantique et la compréhension classique
  • La métaphysique de Quality et l’excellence de sa dénomination

    • On ne peut pas mesurer si un texte, une moto ou une expérience possède une Quality élevée ou faible ; ce n’est donc pas objectif, mais comme Pirsig pense que Quality produit le sujet, ce n’est pas simplement subjectif non plus
    • Quality n’est pas objective parce qu’elle est immesurable, ni subjective parce qu’elle existe avant le sujet ; elle est un crible (sieve) qui s’applique avant la séparation sujet-objet
    • L’excellence du nom « Quality » vient du fait qu’il mêle l’idée de « haute valeur » et celle de « propriété/attribut », suggérant, comme le Good débattu depuis Platon, que le bien est perçu immédiatement avant la logique et la raison
    • Pirsig considère que la science et les mathématiques sont cohérentes et logiques à l’intérieur de leurs domaines, mais qu’à leurs fondements comme à leurs marges subsistent des jugements de Quality
    • En géométrie, une fois les axiomes posés, on peut déduire avec certitude ; mais si l’on choisit d’autres axiomes, on obtient une autre géométrie, et décider quels axiomes sont les plus « justes » relève davantage du goût et de l’adéquation à un but
    • En science, une fois l’hypothèse formulée, la méthode scientifique dit quoi faire ensuite ; mais parmi les innombrables hypothèses possibles, choisir laquelle mérite d’être poursuivie relève presque d’un art, sans méthode déterminée
    • Henri Poincaré expliquait que le mathématicien ou le scientifique à la frontière du savoir doit choisir parmi de nombreuses possibilités découlant des lois existantes, et que la règle guidant ce choix est si subtile qu’elle se dit difficilement : elle doit être ressentie plus que formalisée
    • Le rasoir d’Occam aussi recommande de choisir la théorie la plus simple, mais jusqu’au bout, le jugement consistant à éliminer les explications inutiles reste un jugement esthétique et un jugement de Quality
    • Il faut abandonner la maxime selon laquelle « la science et son enfant, la technologie, sont neutres en valeur, donc exemptes de quality » ; l’impression de Quality joue le rôle de locomotive qui indique où le train du savoir doit aller

Critique de l’IA et réponse de ZAMM

  • Une grande partie des critiques adressées à l’IA se concentre sur le fait de savoir si les outils agentiques fonctionnent vraiment comme la publicité le promet (dégradation de la base de code, hallucinations de fonctions inexistantes)
  • Même en admettant que les outils d’IA actuels se trompent souvent, le débat sur leur efficacité risque de manquer l’essentiel
  • Beaucoup d’ingénieurs pourraient ne pas vouloir utiliser d’outils agentiques même si ceux-ci fonctionnaient exactement comme annoncé
  • Dans l’article "I Think I'm Done Thinking about Gen AI"

    • On ne peut pas réfuter par des données les arguments pratiques de l’autre camp ; l’auteur a eu une très mauvaise expérience du genAI, mais cela reste anecdotique, et les données scientifiques sont encore presque inexistantes
    • La source de son biais négatif est que les propriétés esthétiques du genAI lui sont profondément déplaisantes ; il en conclut qu’il ne l’utiliserait même pas si c’était gratuit
  • ZAMM m’a aidé de deux façons
    • Première aide — j’étais prisonnier d’une pensée trop classique

      • Le rôle le plus important de Quality est d’élargir la raison, en assimilant des éléments irrationnels auparavant exclus
      • Le défaut d’assimilation de ces éléments irrationnels produit l’« esprit moderne confus et fragmenté » ; parce que la pensée classique domine, j’ai eu tendance à écarter (discount) mon rejet instinctif de l’IA
      • Puisque les opinions de chacun sont également subjectives, cela redonne une légitimité à demander, même face à des études du type « les agents de codage augmentent de 50 % le volume de code », « pourquoi ce code supplémentaire est-il nécessaire, et quel jugement de Quality contribue réellement à l’épanouissement humain ? »
    • Deuxième aide — comprendre la nature de mon rejet

      • La technologie moderne est dominée par une vision de séparation sujet-objet (subject-object), et les manuels produits supposent un utilisateur extérieur, indifférent, qui ne fait que « manipuler » le produit
      • Une société où des gens indifférents fabriquent de la technologie pour la vendre à d’autres gens indifférents
      • La solution consiste à ce que le technicien s’identifie à son travail ; quand la séparation sujet-objet disparaît, le caring (souci, engagement) apparaît, et Quality se révèle en arrière-plan (chapitre 25 de ZAMM)
      • À chaque instant du travail, il existe des milliers de bifurcations toutes classiquement défendables, et seul un rasoir d’Occam centré sur Quality — un sens de ce qui est bon — permet d’avancer (chapitre 24 de ZAMM)
      • Si l’on confie le codage à un agent, on perd ce « sens de la qualité du travail » ; les LLM sont utiles pour la recherche ou comme rubber duck, mais leur randomness est constitutive, ils produisent du code à un rythme difficile à suivre, ajoutent de la friction entre soi et son travail, et rendent le caring plus difficile

Conclusion — être un exemple dans son propre travail

  • L’auteur espère un monde où les gens s’identifient à leur travail et recherchent l’excellence ; ce qu’il est possible de faire, c’est montrer l’exemple dans son propre travail

« La première étape pour rendre le monde meilleur commence juste ici, dans votre propre cœur, votre propre esprit et vos propres mains, puis elle se propage vers l’extérieur. D’autres peuvent parler de la manière d’élargir l’avenir de l’humanité, mais moi, je veux simplement parler de la façon de réparer une moto. Je pense que ce que j’ai à dire aura une valeur plus durable. » - ZAMM, chapitre 25

1 commentaires

 
GN⁺ 2 시간 전
Avis sur Lobste.rs
  • J’ai peur que le développement logiciel devienne un métier de spécification sur pattes. Non pas parce que les agents seraient réellement capables d’accomplir les parties les plus difficiles et délicates du métier, mais parce que la majeure partie des logiciels dans le monde a toujours été un bric-à-brac douteux qui doit juste à peine fonctionner
    En y ajoutant un marché des lemons typique, la plupart des SaaS deviendraient un bric-à-brac plein de bugs, et les acheteurs perdraient la capacité de distinguer les bons produits des mauvais. Les prix et la demande baisseraient alors. Des gens continueront d’utiliser des logiciels, mais les effectifs globaux diminueront, et l’essentiel du travail risque de devenir de la gestion de bric-à-brac. Les exceptions seraient une petite minorité chanceuse travaillant sur des endroits comme des « systèmes d’enregistrement », qui doivent absolument fonctionner correctement
    À moyen terme, oui, mais le véritable objectif des labos d’IA est de créer quelque chose qui remplacera tout le travail intellectuel et physique humain à moindre coût. Ils ne savent pas encore comment, mais ils essaieront en y brûlant jusqu’au dernier dollar de la planète. Ce dont rêvent les investisseurs ressemble en réalité à un successeur évolutif de l’humanité
    Ma politique personnelle vis-à-vis de l’IA est la suivante. Quand l’artisanat compte, j’essaie d’utiliser les agents de code comme des assistants d’artiste, comme ceux qui peignaient les arrière-plans des grands maîtres. Opus 4.8 est déjà trop intelligent et, de ce fait, plutôt inadapté : en une ou deux heures d’audace irréfléchie, il peut faire perdre le fil d’une codebase. En ce moment, j’aime bien Qwen3.6 27B, qui est assez intelligent pour traquer des bugs, refactoriser ou implémenter une fonctionnalité bien spécifiée dans du code que je comprends. Mais dès que je perds ma compréhension du code, le modèle se met lui aussi à patauger, et j’en paie immédiatement le prix
    En matière de politique publique, je pense qu’il est insensé de fabriquer son propre successeur évolutif sans garantie de coexistence possible. C’est pourquoi je m’oppose fermement à la création d’une véritable intelligence de niveau humain. Mais cette opposition devrait être au niveau d’un traité international. Pas un faux traité : un traité dont la violation pousserait les États-Unis et la Chine à de graves tensions et à la détermination d’arrêter les runs d’entraînement. Interdire les data centers régionaux, c’est bien, mais si quelqu’un construit SkyNet en Iceland ou au Middle East, il faudra quand même affronter SkyNet au bout du compte. Arrêter l’IA est fondamentalement une question d’État, et harceler des mainteneurs open source parce qu’il existe un fichier AGENTS.md n’est pas une action sérieuse
    Donc, dans l’ensemble, je suis d’accord avec le texte d’origine. Le développement logiciel peut être un véritable artisanat, et cela fait 30 ans que je vis de ce que j’aime en étant bien payé. Mais si les modèles deviennent bien meilleurs, on risque d’entrer dans un monde où le nombre de gens qui aiment sincèrement l’artisanat logiciel dépassera la demande réelle. La matière noire des apps internes d’entreprise sera globalement satisfaite par un bric-à-brac un peu meilleur qu’aujourd’hui, et c’est là que se trouvent en réalité la plupart des emplois du métier
    Je pleure le métier que j’ai choisi, mais je pleure encore davantage le monde et l’humanité. Il n’est pas nécessaire d’investir toute notre richesse pour tenter de créer quelque chose de plus intelligent que l’humain, moins cher, et duplicable avec la commande cp. Mais nous allons quand même essayer, en y brûlant toutes ces ressources

    • J’ai commencé à apprendre la programmation vers 10 ou 11 ans, et j’ai continué parce que cela me fascinait. Quand j’ai obtenu mon premier emploi, j’ai compris que je devrais faire du développement web, et pendant la majeure partie de ma carrière j’ai gardé une séparation stricte entre la programmation pour le plaisir et le travail pour le salaire, comme deux artisanats distincts
      En vieillissant, j’ai vu de plus en plus de jeunes apprendre la programmation parce que c’était un métier rentable, et j’avais du mal à comprendre qu’ils ne ressentaient pas la fascination que j’y trouve. Donc je ne suis pas si endeuillé que ça. Si la population des développeurs logiciels chutait de 80 %, ce serait peut-être au contraire un meilleur métier dans lequel évoluer
      Je suis aussi d’accord sur l’usage de l’IA comme assistant d’artiste. Même les modèles les plus récents, je sais qu’on ne peut pas les laisser tourner longtemps sans surveillance, parce qu’ils finiront par faire n’importe quoi. Cela dit, je préfère avoir Opus comme assistant, parce qu’il n’est pas nécessaire de tout lui expliquer en détail. Mais ce serait encore mieux s’il y avait un vrai développeur junior à l’autre bout, qui pourrait apprendre l’artisanat. Comme le faisaient les véritables assistants d’artiste
  • Ce qui m’effraie le plus dans « The Maw », c’est cette idée qu’il cherche à avaler pour toujours la distinction entre ce qui est bon et ce qui est mauvais. La phrase disant qu’on aboutirait à un monde où le code beau, excellent, vertueux ou amusant disparaît, et où il ne reste plus que du code qui fonctionne et du code qui ne fonctionne pas, me parle exactement

    • À mon avis, « The Maw » n’a pas grand-chose à voir avec l’IA, et ce sentiment avait déjà commencé avant que les LLM ne deviennent aussi compétents qu’aujourd’hui. C’est simplement du capitalisme myope
      Quand on écrit du code dans un cadre professionnel, il faut satisfaire les exigences, et ça s’arrête là. L’objectif d’une entreprise est de gagner de l’argent, et tout le reste passe au second plan. Avec la hausse des taux, l’argent s’est raréfié, et la pression pour simplement livrer du code qui fait juste ce qu’il faut pour gagner de l’argent n’a jamais été aussi forte
      Rechercher la beauté et l’élégance est un luxe dont jouit l’artiste, pas la part du travailleur à la chaîne auquel la programmation ressemble de plus en plus. Bien sûr, dans un tel environnement, l’apprentissage, la créativité et l’innovation passent au second plan, mais leurs effets ne se feront sentir que dans quelques années, voire plusieurs décennies. C’est un jeu myope, mais suffisamment long à l’échelle du mandat moyen d’un CEO ou jusqu’à une IPO pour qu’on se retrouve dans la situation actuelle
  • Cet article parle d’un livre qui a, à lui seul, changé ma vie, donc je suis sans doute biaisé, mais dans l’ensemble je l’ai trouvé excellent. Cela dit, commencer par les postures pseudo-intellectuelles plausibles de Goodreads ne me semble pas une bonne idée
    Le gumption trap est très lié à la programmation, et je pense qu’on finit inévitablement par rencontrer chacun de ceux que Pirsig énumère à un moment ou un autre de sa carrière. J’ai moi-même écrit à ce sujet avant l’adoption généralisée des LLM
    Les conseils de Z&AMM s’appliquent tellement bien à la programmation que, si vous vous êtes demandé si Pirsig avait déjà programmé, la réponse est évidemment oui. Dans la suite de Z&AMM, Lila, il mentionne même directement COBOL
    Je pense que la meilleure façon d’expliquer la qualité est comme une couche située au-dessus du subjectif et de l’objectif. L’explication la plus concise se trouve dans Lila. Une personne assise sur un poêle brûlant peut constater, sans argument philosophique, qu’elle se trouve dans une situation de faible qualité, porteuse d’une valeur négative, et que cette valeur n’est ni un jugement ni une description de l’expérience, mais l’expérience elle-même. Autrement dit, la valeur se situe entre le sujet et l’objet, elle est perçue plus directement et plus réellement que le « moi » ou l’« objet » auxquels elle sera attribuée ensuite
    Si cela vous intéresse, j’ai aussi des notes complémentaires à ce sujet. Dans Lila, Pirsig tente d’élaborer un système métaphysique complet, en divisant les schémas de qualité statique entre l’inorganique, l’organique, le social et l’intellectuel, puis en plaçant au-dessus la qualité dynamique indéfinissable qui était le point central de Z&AMM
    Je pense qu’il faut se demander si l’adoption de l’IA est en soi un événement de faible qualité, ou s’il est possible d’intégrer les modèles de langage au travail des programmeurs d’une manière de haute qualité. J’ai l’impression que la façon dont les gens entrent en relation avec l’IA relève d’une faible qualité, mais qu’ils peinent à l’exprimer faute de mots et de cadre de pensée permettant de l’aborder à un niveau autre que celui du dualisme sujet-objet, et qu’ils choisissent donc de la rejeter en bloc
    À un certain niveau, l’IA rend possible une approche romantique de la programmation. Si l’on se contente de traiter les productions de l’IA au niveau de la surface, sans intention d’aller plus loin, cela peut convenir sur le moment. Mais dès qu’on regarde réellement à l’intérieur du code, on découvre qu’il n’y a pas de structure classique à mettre au jour. Le modèle a fait semblant de travailler ainsi, mais ce n’était pas le cas en réalité. C’est sans doute pour cela que les dirigeants, product designers, investisseurs et solo founders, qui ne considèrent la technologie que comme un moyen d’atteindre d’autres objectifs, comprennent mal la frustration des développeurs face au code généré par l’IA
    L’idée que les modes d’emploi de produits grand public présupposent la relation entre le produit et l’utilisateur uniquement comme une affaire de « manipulation », tout en tenant pour acquise la question de ce qu’est une bonne cuisson, une bonne tonte de pelouse ou un bon usage de l’informatique, s’applique encore aujourd’hui presque telle quelle à la documentation des bibliothèques logicielles et des outils. J’ai lu récemment la documentation de Pi agent, et j’ai trouvé frustrant qu’elle parte du principe qu’on sait déjà ce qu’est un bon usage et qu’on cherche seulement comment l’ajuster à ses préférences. Quand j’ai demandé à des collègues « alors, comment est-ce qu’on s’en sert bien ? », ils m’ont regardé d’un air perplexe
    Cela me fait aussi penser à Vim. Si l’on ne lit que le manuel de Vim, on se sent vite déconcerté. Il a fallu des décennies d’articles accumulés sur « comment bien utiliser Vim ». Et plus tard, on en est même arrivé à la conclusion que la meilleure plateforme pour un bon usage de Vim n’était peut-être pas Vim lui-même, d’où l’apparition de Kakoune ou Helix
    En tant que père d’une fille de deux ans, je vous félicite pour l’arrivée de votre première fille. Le plus beau voyage de votre vie vous attend. Si vous cherchez des œuvres dans le même esprit que Z&AMM, je recommande Surfaces and Essences de Hofstadter et Sander, la suite Lila, ainsi que les travaux de Sevilla King et de John Vervaeke

  • J’ai lu l’article jusqu’au bout. Je ne sais pas si c’est parce que le texte était bon ou grâce à ma capacité à rester accroché à un long format, mais je penche pour la première hypothèse
    Une chose que Robert dit au sujet de la qualité, c’est que si les gens la ressentent différemment, ce n’est pas parce que la qualité elle-même diffère, mais parce que leurs expériences diffèrent
    Donc, avant de parler de qualité à mon équipe, je me demande d’abord si nous avons la même expérience. Si ce n’est pas le cas, dire « améliorez la qualité » ne fonctionne pas. Il faut dire précisément ce qu’il faut améliorer
    En étendant cela au code généré par l’IA, je me demande si la « qualité » varie elle aussi selon l’expérience

  • Très beau texte. Même si je n’avais rien tiré d’autre de l’apocalypse IA, elle m’a au moins amené à réfléchir beaucoup plus profondément à la relation entre les ingénieurs logiciel et le code qu’ils écrivent

  • Grand soulagement de constater que d’autres ont aussi prêté attention à Pirsig. Dans Previously, on Lobsters, il y avait presque exactement le même débat que celui que Phaedrus avait avec les classicistes au sujet de la qualité d’un essai, à ceci près qu’ici la question était de savoir si l’essai avait été écrit par un chatbot ou par un étudiant humain
    Utiliser un LLM comme outil de recherche ou comme canard en plastique particulièrement puissant est très utile, mais faire écrire du code par un LLM dont l’argument de vente est précisément d’inclure intrinsèquement de l’aléatoire et de produire plus de code que je ne peux en suivre, cela me semble ajouter une couche de friction entre moi et ce que je fabrique
    Dans le cadre de Pirsig, quand un sujet humain regarde un objet physique, la qualité de cette interaction — autrement dit la source du jugement de valeur porté sur l’objet — n’est déterminée ni subjectivement par l’humain ni objectivement par les propriétés physiques de l’objet, mais émerge de l’interaction elle-même. On peut dire que le jugement est contextuel ou participatif. Tous les objets ne participent pas de la même manière. Quand un humain observe un photon, le théorème de Kochen-Conway implique que le photon possède une liberté intrinsèque quant à la manière dont il réagira, tandis qu’un arbre, occupé à maintenir son homéostasie, ne réagit guère au regard. Entre les deux, M. pudica et D. muscipula réagissent au contact et au bruit, mais pas au regard ; ce n’est donc même pas un spectre unidimensionnel
    Alors, comment un dispositif d’exécution de LLM ou un chatbot réagit-il à l’observation ? En réalité, il ne réagit pas. Ce n’est qu’un objet mathématique fini et relativement petit. Toutes ses propriétés sont objectives, et il n’y a ni choix ni variation dans la sortie. On peut lui adjoindre un générateur pseudo-aléatoire pour le faire errer au hasard entre des tokens plus ou moins plausibles, et on peut piloter cette marche en lui imposant les tokens que nous choisissons, mais cela s’arrête là. Si le LLM paraît profond, c’est parce qu’il possède une topologie hyperbolique et que l’exploration d’un espace hyperbolique donne l’impression d’un zoom dont les détails se déploient à l’infini
    Avec le raisonnement de Pirsig, il n’y a au fond que deux positions possibles sur les LLM. La première consiste à voir le LLM comme un système contextuel qui traite l’entrée humaine comme le contexte d’une réponse statistiquement plausible ; la seconde, comme un système objectif qui traite l’entrée humaine comme le segment initial d’un énoncé statistiquement plausible. Dans les deux cas, le LLM est plus proche d’un miroir qui renvoie l’utilisateur à lui-même, l’utilisateur ne choisissant que l’angle d’approche. L’entrée choisie est le principal moyen de contrôle cybernétique pour atteindre l’information ou l’état désiré, et le modèle ne fait qu’offrir un ensemble préconfiguré de possibilités assez vaste pour écraser l’humain. Si les chatbots produisent un effet ELIZA qui débouche facilement sur la psychose, c’est peut-être parce qu’ils sont des miroirs haute fidélité conçus pour déformer l’image de l’utilisateur par la flatterie et le love bombing, afin de le rendre dépendant de leur usage
    Utiliser des LLM pour écrire du code me donne l’impression d’une barrière entre l’ordinateur et moi. Les vibe coders le reconnaissent, tout en affirmant que cette barrière fournit abstraction et isolation, comme une autre API. Mais si l’on reprend la métaphore du miroir, le miroir n’est pas entre l’ordinateur et moi, il est à côté. Au lieu d’utiliser directement l’ordinateur, on vise le miroir, on zoome soigneusement sur la bonne zone, et, une fois la précision suffisante, on peut donner des instructions simplement parce qu’il devient possible de voir l’ordinateur sous un certain angle. Mais ce n’est pas une abstraction, et l’isolation est encore plus faible. On ne fait qu’ajouter du travail pour trouver un point de vue qui n’existe peut-être même pas
    Si les vibe coders procèdent ainsi, c’est peut-être parce qu’ils ne savent pas observer l’ordinateur. Le HCI est participatif, et les humains doivent disposer d’un contexte de programmation avant d’écrire du code, c’est-à-dire de la théorie de Naur évoquée dans previously, on Lobsters. Ou alors c’est peut-être de la vanité : ils préfèrent regarder le miroir parce qu’il leur renvoie leur propre image. Mais à mes yeux, ce sont vraiment les deux seules voies qui puissent avoir un sens. Il existe déjà bien assez de problems between the keyboard and chair, inutile d’en ajouter un de plus qui n’améliore pas la puissance expressive / d’abstraction

  • Personnellement, j’ai l’impression que, s’il y a une « ligne juste », je me situe de part et d’autre
    D’un côté, j’aspire au lien et à la relation avec le code que j’aurais écrit moi-même sans IA, et je sens que ce lien disparaît quand j’utilise l’IA. C’est réel
    D’un autre côté, je pense que l’usage de l’IA me pousse vers un niveau d’abstraction plus élevé, où j’ai l’occasion d’exercer mon discernement et d’y projeter ma propre vision de la qualité. Si je laisse l’IA exécuter le code à ma place sans rester suffisamment impliqué, le lien au niveau du code lui-même disparaît ou s’affaiblit. Mais au niveau d’abstraction où je ne demande pas à l’IA de contribuer, ce lien ne disparaît pas
    Dans mes projets personnels, ce niveau correspond à l’architecture et à la définition des interfaces. En ce moment, je construis un harnais et une pipeline qui appellent plusieurs fournisseurs de LLM, et je réfléchis avec beaucoup de soin aux flux d’entrée, de sortie et de contrôle de ces appels, ainsi qu’à la manière de les composer en un flux permettant d’atteindre un objectif plus large. J’ai le sentiment que si j’investis du temps et de l’attention dans ce processus, même si je perds le lien avec le code lui-même, je ne perds pas le lien avec mon intention ni avec l’architecture. Autrement dit, pour moi, la qualité et l’artisanat ne se limitent pas à la seule partie où l’on utilise l’IA
    C’est une comparaison un peu datée maintenant, mais cela ressemble au fait de devenir manager ou de diriger sa propre entreprise. On dit souvent que le passage le plus difficile dans le parcours d’un CEO est d’abandonner le contrôle, c’est-à-dire d’accepter de ne plus contrôler exactement la manière dont sa vision est réalisée. Il est impossible pour le CEO d’une entreprise suffisamment grande de connaître tous les détails de la mise en œuvre de sa vision. Un CTO, dans une moindre mesure, vit quelque chose de similaire, puisqu’il doit continuer à se soucier d’une partie des détails techniques
    Le deuil que j’ai fini par accepter, c’est qu’il existe, pour toute tâche donnée, un trade-off entre le temps investi, la compréhension et le résultat produit. Si l’on en optimise deux, l’attention se détourne du troisième. Malgré cela, quelle que soit la combinaison que l’on choisit d’optimiser, il reste largement assez d’occasions d’exercer son discernement et de conférer de la qualité

  • Le commenter B de cet article, c’est moi, et j’ai lu le texte attentivement. Je n’ai pas lu ZAMM, mais j’ai un peu lu Zen.
    Cette remarque est tout à fait pertinente. La plupart des gens, dès qu’on leur donne du libre arbitre supplémentaire — autrement dit de l’argent tombé du ciel ou un gain de productivité soudain — le gaspillent immédiatement et en font les déchets les plus gros et les plus agaçants qui soient. Il y a là une anxiété évidente.
    Les personnes qui utilisent des ordinateurs ont tendance à mal mesurer combien de savoir-faire artisanal et d’efforts il a fallu pour produire des livres. Cela vaut aussi si l’on remonte à la machine à écrire, à l’imprimerie typographique, à l’écriture manuscrite, à la mémoire humaine, et même à la seule beauté des mots et à la capacité de convaincre les autres de les répéter.
    Le fait d’avoir des ordinateurs n’empêche pas les gens d’investir beaucoup dans la qualité de leurs productions et de créer de grandes choses. C’est juste qu’il y a aussi énormément de déchets dans le monde.

  • Une réflexion à propos de ZAMM : la vision « romantique » de John sur les productions techniques peut se défendre de manière pragmatique, au cas par cas.
    Par exemple, supposons qu’un projet dépende d’une infrastructure open source. Si l’on doit creuser un bug obscur du noyau ou du compilateur, qu’on peut contourner facilement et documenter, puis annuler ce contournement si quelqu’un le corrige plus tard, qu’est-ce que cela apporte réellement au projet ? La conclusion, c’est qu’il faut choisir avec sagesse les batailles qu’on veut mener.

    • J’ai effectivement fait ce genre de chose, et une ligne a été ajoutée au projet Linux Kernel manpages. Je ne considère pas cela comme une perte de temps, parce que cette expérience a fait de moi un meilleur programmeur.