Crise de l’identité du programmeur

• L’identité du programmeur est aujourd’hui menacée par l’arrivée de l’IA et des outils LLM
• La culture de la programmation trouve ses origines dans l’éthique hacker du MIT des années 1950, où l’écriture du code en elle-même était considérée comme un savoir-faire profond (craft), avec pour valeurs centrales la logique précise et l’immersion dans la résolution de problèmes
• Mais l’industrie de l’IA et les outils LLM actuels cherchent à transformer les développeurs en simples rédacteurs de spécifications ou opérateurs, en imposant une approche de « vibe-coding » où l’on donne des instructions en langage naturel au lieu d’écrire directement le code
• Le code généré par les LLM est non déterministe et imprécis, et il supprime la compréhension profonde et l’immersion que les développeurs acquièrent en lisant et en écrivant eux-mêmes le code, rompant ainsi leur lien avec la codebase
• Les entreprises, au nom de la productivité, imposent l’usage de ces outils, et remplacent la collaboration et la culture du mentorat dans les équipes par l’interaction avec l’IA, ce qui affaiblit les liens humains entre développeurs
• La valeur essentielle de la programmation, comprise non comme un simple livrable mais comme un processus de réflexion et de compréhension, est en train de se perdre, et les développeurs doivent résister à cette évolution pour préserver leur savoir-faire, leur plaisir et leur identité professionnelle

---

L’essence et la tradition du programmeur

• Écrire du code n’est pas une simple tâche : c’est l’identité même du développeur, et l’éditeur est à la fois un atelier et un sanctuaire, un lieu où l’on affine sa technique et entre dans un état de flow

  • Grâce à des outils comme Vim, on travaille sans barrière entre la pensée et le code, en créant un monde immatériel qui agit pourtant sur le réel
  • Le processus de résolution du puzzle compte davantage que l’image achevée, et dans ce flux de technique qui va des doigts au buffer, le temps disparaît

• À la fin des années 1950, une nouvelle culture de la programmation est née au MIT, où des hackers expérimentaux et anticonformistes poursuivaient le programme parfait à l’aide du Flexowriter et de l’ordinateur TX-0

  • Autour du concept de « The Right Thing », ils visaient un code élégant et concis
  • Les membres du Tech Model Railroad Club se sont plongés dans le langage machine, y ont appris une forme de magie numérique, et ont instauré une culture de partage des découvertes avec les autres étudiants

• C’est dans le creuset informatique du Building 26 que les compétences de codage se sont forgées, et cette culture établie il y a environ 70 ans perdure encore aujourd’hui dans l’esprit des développeurs comme dans les machines

  • L’héritage des hackers d’autrefois subsiste comme une technique profonde et presque motrice, sur laquelle s’est bâtie toute une industrie passionnée
  • Les développeurs sont toujours animés par le même émerveillement, le même sentiment d’accomplissement et la même élégance dans la résolution de puzzles

• Pourtant, ces valeurs fondamentales qui constituent l’identité du programmeur sont menacées, et l’avenir de la programmation, autrefois clair et lumineux, est désormais obscurci par la noirceur, l’arnaque et l’incertitude

L’IA impose une nouvelle identité

• L’industrie de l’IA, qui pèse des milliards, la communauté Hacker News et les défenseurs des LLM sur LinkedIn affirment que l’avenir du développement logiciel ne ressemble presque plus à la programmation, et ce qui semblait être un mème il y a un an — le « vibe-coding » — devient courant

  • Les développeurs devraient désormais écrire des spécifications en Markdown au lieu du code, tandis que disparaissent l’immersion profonde, l’exploration minutieuse de la codebase, la résolution de puzzles et la découverte de ses secrets
  • À la place, il faudrait accepter une cognition fragmentée et les changements de contexte pendant que des agents pensent à la place du développeur ; la résolution créative de problèmes est déléguée à la machine, et le développeur devient simple opérateur

• Certains développeurs accueillent favorablement cette évolution et cette nouvelle identité de « Specification Engineering », enthousiastes à l’idée de devenir des opérateurs qui « dirigent l’orchestre » à la manière de Steve Jobs

  • On peut alors se demander pourquoi ils sont devenus programmeurs s’ils semblent ne pas aimer coder ; peut-être confondent-ils Woz et Jobs
  • Prompt, Context, Specification « Engineering » ne semble pas promettre aux programmeurs une carrière radieuse et prospère

• Cela signifie une dévalorisation de la technique, de la compétence et du travail, en déplaçant les capacités d’abstraction propres aux développeurs vers un terrain où elles ne sont plus nécessaires, dans un espace déjà occupé par les product managers et les designers

L’évolution des rapports de pouvoir dans l’entreprise

• À mesure que cette nouvelle identité est imposée en entreprise, les rapports de pouvoir changent, et dans une tentative frénétique d’augmenter la productivité au mauvais endroit, les développeurs sont contraints d’utiliser les LLM de façon de plus en plus précise

  • S’ils ne se conforment pas, ils sont poussés dehors, sommés soit d’utiliser des produits qui annoncent leur propre inutilité, soit de démissionner
  • Par le passé, les dirigeants ont rarement dicté avec autant de précision les outils des développeurs

• Les développeurs ont toujours tiré une grande fierté du fait de sélectionner et perfectionner leurs outils, comme des chefs ou des menuisiers, en personnalisant ceux-ci selon leur façon de penser via le réglage minutieux de l’éditeur, des dotfiles et de l’environnement de développement

  • Ils se sont consacrés à la personnalisation de leur boîte à outils comme partie intégrante de leur technique ; voir des managers, souvent très éloignés du travail quotidien, en dicter l’usage ressemble à une intrusion
  • Pour des programmeurs longtemps favorisés dans l’entreprise, ce récit donne au management un nouveau moyen de faire pencher l’équilibre des forces en sa faveur

La différence fondamentale entre les LLM et les langages de programmation

• Certains comparent l’impact des LLM à la transition des langages bas niveau vers les langages haut niveau (de l’assembleur à Fortran), mais cette analogie est erronée à plusieurs égards

  • Fortran restait enraciné dans la programmation : il ne cherchait pas à supprimer la technique, mais à construire dessus, en étendant la précision et l’expressivité de la programmation au lieu de les retirer
  • Fortran produisait de manière fiable le bon résultat pour une entrée donnée ; dans le monde des LLM, rien de tout cela n’est vrai

• L’informatique et la programmation peuvent être très frustrantes, mais on a toujours pu faire confiance à leur précision : un programme exécute exactement ce qu’on lui demande

  • C’est justement parce que nous sommes habitués à compter sur cette précision des machines qu’il est facile de croire un chatbot lorsqu’il nous persuade qu’il a bien accompli la tâche demandée

• Les LLM et leur manière de travailler sont fondamentalement imprécis, tant par les propriétés mêmes des grands modèles de langage que par l’usage du langage naturel pour leur donner des consignes

  • Il est d’ailleurs frappant que des programmeurs hostiles au non-déterminisme aient adopté une telle approche, eux qui préfèrent la prévisibilité, la composabilité, l’idempotence et des tests d’intégration stables
  • Le code produit par les LLM représente l’inverse : un chaos incohérent

• Dans « On the foolishness of “natural language programming” », Dijkstra soulignait déjà qu’il fallait remettre en cause l’hypothèse selon laquelle le langage naturel simplifierait le travail ; il insistait sur le fait qu’un texte formel a l’avantage de n’avoir à satisfaire que quelques règles simples pour être valide

La perte de compréhension profonde et d’immersion

• Certains tentent de distinguer le développement assisté par IA du vibe-coding en lui opposant davantage de rigueur et de bureaucratie, mais cela ignore le fond du problème

  • On ne lit pas le code généré par un LLM avec la même attention que celui qu’on a écrit soi-même ou relu dans une PR ; il y a dans le codage avec LLM quelque chose d’intrinsèquement anesthésiant pour le regard
  • On parcourt le tout à la va-vite, on se sent dépassé et ennuyé, et dès que la CI passe et que le programme compile, on accepte aveuglément des pièges dangereux
  • On ne vérifie pas si les tests ont bien été configurés pour s’exécuter, s’il a importé une bibliothèque inexistante, ni s’il a réimplémenté à lui seul une bibliothèque entière

• Une critique ou un résumé de livre ne remplace jamais l’expérience de lecture directe, qui exige de parcourir des centaines de pages, phrase après phrase, en méditant les idées

  • De la même manière, survoler le résumé d’un travail effectué par une IA prive de la compréhension profonde du domaine, du problème et des solutions possibles, et coupe le lien avec la codebase
  • Se jeter dans l’abîme de l’ignorance, en faire émerger le sujet et ses implications, apprendre et comprendre, est à la fois satisfaisant et indispensable à un bon logiciel
  • Le sentiment de propriété, l’agentivité et le travail profond et gratifiant sont remplacés par une attention dispersée entre des onglets d’agents

• Joan Didion disait : « J’écris pour découvrir ce que je pense, ce que je regarde, ce que je vois et ce que cela signifie » ; Peter Naur explore une idée similaire dans « Programming as Theory Building »

  • La « Theory » de Naur incarne la compréhension de la codebase : son fonctionnement, son formalisme et sa représentation du monde réel
  • Ce contexte et ces intuitions ne s’acquièrent que par l’immersion ; Naur décrit même cette « Theory » comme le principal résultat de la programmation, davantage que le logiciel lui-même, le véritable produit
  • Ce n’est qu’avec une « Theory » bien développée qu’on peut appliquer efficacement extensions et corrections de bugs à une codebase

• Le bon design naît de l’immersion, du va-et-vient dans un buffer de texte et du travail qui se fait souvent aussi loin du clavier

  • Comme on ne peut pas garder une codebase entière en tête, il faut plonger dans les modules, classes et fonctions pour préciser un modèle mental encore flou
  • Il faut lire et écrire du code pour étendre sa cognition, retrouver sa familiarité et sa compréhension du domaine du problème

• Une partie du contexte se construit, et c’est souvent après de nombreuses tentatives imparfaites qu’une solution finit par apparaître ; il faut aussi ressentir la dissonance d’un mauvais design

  • C’est en écrivant du code répétitif et pénible qu’on comprend qu’il existe une manière meilleure, plus concise, plus élégante, plus composable et plus réutilisable
  • Cela oblige à s’arrêter pour réfléchir profondément au problème, à prendre du recul et à repartir de zéro
  • À l’inverse, le travail avec des agents IA est sans friction ; il évite les solutions alternatives, et l’on ne sait pas si ce qu’on accepte est parfait, banal, affreux, voire nuisible

L’effondrement de la collaboration d’équipe et du lien humain

• La dette cognitive du codage centré sur les LLM va au-delà de l’érosion de la technique : des « slop-jockeys » à la capacité d’attention réduite jettent leurs productions dans les pull requests et les design docs, perturbant la collaboration et désorganisant les équipes

  • Les collègues chargés de la code review prennent douloureusement conscience qu’ils ne sont plus la dernière couche de contrôle qualité, mais la première
  • Ils doivent signaler des fonctions nouvellement ajoutées mais jamais appelées, des bibliothèques hallucinées, ou des erreurs d’exécution ou de compilation évidentes
  • L’auteur, qui n’a manifestement fait que survoler son propre code, n’en assume pas la responsabilité et dit : « Claude l’a écrit comme ça. Stupide IA, haha »

• Des managers intrusifs et des dirigeants soucieux d’économiser de l’argent poussent les équipes à réduire les interactions humaines — probablement sans même en mesurer pleinement les conséquences

  • Dans un état d’isolement et de privation de liens, on se retrouve encouragé à ériger des murs autour de son expérience de travail
  • Lorsqu’on a besoin d’un pair programmer, d’échanger sur une solution, de prototyper, d’esquisser une architecture ou de poser des questions d’expert sur une partie obscure de la codebase, on se tourne vers un LLM plutôt que vers une personne
  • Plus besoin de buddy d’onboarding, de mentor ou de collègue : on peut désormais parler à une machine
  • Il devient si facile d’éviter le contact humain avec les LLM que cela pourrait finir par devenir la norme

Défendre l’identité du programmeur

• Il est sidérant de voir à quel point nous nous conformons au récit de l’hype autour de l’IA, en participant activement à l’effacement programmé de la technique et en abandonnant volontairement nos moyens de penser

  • Nous faisions partie des chanceux qui avaient pu vivre d’un hobby ; même si l’on met en place des processus stricts et méticuleux pour contenir ce slop, on externalise toujours la partie la plus amusante du travail pour la remplacer par une corvée prescriptive

• Les LLM ressemblent à une solution qui largue une bombe nucléaire en orbite sur la complexité du logiciel, en recourant à quelque chose de bien plus complexe et opaque pour traiter les symptômes au lieu de résoudre les vrais problèmes

  • Remplacer sed par Claude, ou demander des réponses sur une bibliothèque ou un framework dont la documentation reste obscure même après des heures de recherche, cela peut se défendre
  • Mais je ne veux pas devenir simplement un opérateur ou un relecteur de code, relégué au second plan des parties amusantes et intéressantes du travail

• Je préfère des outils qui aident dans les tâches répétitives, à comprendre une codebase et à écrire le bon programme, et je ressens un malaise face aux produits conçus pour penser à ma place

  • Je rejette les produits qui retirent mon agentivité dans la compréhension du logiciel que je produis et qui coupent mes liens avec mes collègues
  • Même si les LLM finissent par être à la hauteur du battage médiatique, nous perdrons malgré tout tout cela, ainsi que la technique elle-même
  • Les humains comptent plus que les machines et les entreprises qui les financent, tandis qu’eux engrangent les profits pendant que le reste d’entre nous poursuit le nouveau rêve américain qu’ils vendent
  • En échange, nous offrons notre capacité de pensée critique, notre plaisir, notre technique, notre vie privée — et peut-être même la planète

[command2alt]

Globalement d’accord
Surtout le changement de contexte ? On envoie un prompt, puis l’attente casse la concentration et fait baisser la productivité. Si la vitesse des LLM augmente au point de donner une réponse immédiate, cela pourrait peut-être résoudre le problème.

[serithemage]

On a vraiment l’impression que le texte part d’une conclusion déjà arrêtée et qu’il est écrit de manière orientée. La question de la disparition du sens de l’ownership chez les développeurs me semble se lire, indépendamment des LLM, comme un débat entre l’ère de l’artisanat et l’ère de l’industrialisation.

[GN⁺]

Avis sur Hacker News

• Ce qui m’a le plus marqué, c’est de voir des reviewers de code sombrer mentalement en réalisant qu’ils ne sont plus la dernière étape du contrôle qualité, mais la première ligne de défense. Ils reçoivent une demande de review, mais doivent désormais repérer un à un les nouvelles fonctions jamais appelées, les bibliothèques ajoutées sans raison, les erreurs évidentes de runtime ou de compilation, etc. Et l’auteur du code esquive sa responsabilité avec des phrases du genre : « C’est Claude qui l’a écrit, l’IA s’est trompée, haha. » Depuis l’arrivée des LLM, la loi de Brandolini (réfuter des absurdités demande bien plus d’énergie que d’en produire) se fait encore plus cruellement sentir. Quand des développeurs peu expérimentés ou peu compétents peuvent déverser des milliers de lignes en quelques minutes, la responsabilité réelle de garantir la santé du système est désormais refilée aux reviewers. Quand on regarde le delta de lignes ajoutées/supprimées dans les PR, celles écrites par des LLM ne font presque qu’ajouter, tandis que les ingénieurs seniors expérimentés suppriment souvent autant de code qu’ils en ajoutent

  • À mon avis, ce n’est pas un problème technique, mais un problème humain. Si ça arrive une fois, il faut adresser un avertissement sévère ; si ça se répète une deuxième fois, il faut refuser et faire remonter au manager. Peu importe qui a rédigé la PR, au final c’est votre nom qui est dessus, donc si le code est mauvais, la responsabilité vous incombe aussi

  • Je ne fais plus de code review dans de grosses équipes, mais si je me retrouvais dans une situation pareille, je pourrais tolérer ce genre de défausse une fois ; si ça se répétait, j’essaierais de faire partir la personne. Et si c’était impossible, je partirais moi-même. C’est à ce point un environnement horrible

  • Je pense que le fait que je me sente moins productif en ce moment est lié à ça. Il y a la pression pour produire plus de code plus vite, et le fait qu’en utilisant des agents de ce type, je ne maîtrise plus vraiment tout le contexte du code que je produis. Je ne peux garantir la qualité que dans la mesure où je peux relire attentivement ligne par ligne, et c’est là ma limite. Du coup, en ce moment, j’utilise l’IA plus lentement, plus prudemment, et j’augmente la part de code que j’écris moi-même. Pour répéter une définition de type claire ou une spec sur plusieurs propriétés, l’IA peut aider un peu, mais même dans ces cas-là, le résultat n’est pas toujours fiable

  • Plus un ingénieur senior a d’expérience, plus il a tendance à retirer autant de code qu’il en ajoute. L’article Negative 2,000 Lines Of Code vaut aussi le détour

  • Dès qu’un LLM entre dans la boucle, je pense que la question de savoir à qui nous transférons la responsabilité devient un problème de société plus large. Les gens s’attribuent facilement le mérite quand le résultat est bon, mais accusent tout aussi facilement l’IA quand il est mauvais. À mon avis, il suffira de quelques procès marquants pour que cette culture change fortement

• J’ai depuis longtemps le sentiment que beaucoup de gens qui entrent dans le secteur voient le code moins comme un artisanat que comme un moyen de gagner de l’argent facilement. Depuis que j’ai lu des témoignages de développeurs d’infrastructure open source qui avaient du mal à vivre, puis vu les développeurs qui codent dans des cafés, les bootcamps, les mouvements du type « il suffit d’apprendre à coder », les grinders de Leetcode, les développeurs de San Francisco qui vivent dans leur voiture à cause du prix des loyers, et maintenant le sujet est de s’automatiser soi-même avec l’IA jusqu’à perdre son emploi. Le problème, c’est qu’on ne considère pas les développeurs comme de vrais professionnels. Les standards sont flous, il n’y a ni code d’éthique, ni socle de compétences cohérent, ni représentation. Pire encore, les membres du secteur manquent parfois à ce point d’autonomie qu’ils vont à l’encontre de leurs propres intérêts. Les avocats ont un barreau, les médecins ont leur ordre, mais les développeurs n’ont qu’une angoisse existentielle. Désormais, des supérieurs menacent en mode « on va automatiser ton poste avec l’IA ». Dans les autres professions, on ne voit pas autant d’hostilité envers ses propres intérêts, et je me demande sincèrement pourquoi c’est le cas dans ce secteur

  • Je pense qu’un « codeur » et un ingénieur logiciel, ce n’est pas la même chose. Ce n’est pas parce qu’on a fini un bootcamp et qu’on sait écrire un petit programme en Python qu’on est ingénieur logiciel. Si je dis que j’ai un diplôme, on m’accuse d’élitisme et on me répond que ce qu’on apprend en informatique ne sert pas en pratique. Pourtant, il existe clairement des gens qui sont devenus d’excellents ingénieurs sans diplôme, par leurs propres moyens. Malgré tout, je suis d’accord pour dire qu’il faut des standards, sous une forme ou une autre. On peut simplement féliciter un ancien de bootcamp qui rejoint une startup licorne pleine de buzzwords du moment, mais pour des systèmes sensibles de type Therac-25, il vaut mieux que ce soient des gens formés de manière rigoureuse qui s’en occupent

  • Un patron qui vous dit : « Si tu n’automatises pas, ton poste va disparaître » ? Mais c’est justement notre métier. Automatiser le travail, c’est l’essence même de notre activité, et nous sommes probablement le groupe professionnel qui a le plus d’occasions et de compréhension pour automatiser son propre travail

  • Je pense que l’enseignement ressemble par certains aspects au métier de développeur. Il y a d’excellents profs, de très mauvais profs, et beaucoup entre les deux. Bien connaître une matière ne veut pas dire qu’on sait bien l’enseigner. Peut-être qu’on peut voir les développeurs comme des enseignants qui apprennent aux machines. Certains le font caractère par caractère, idée par idée, d’autres par ambiance générale

• En laissant les LLM de côté un instant, il m’arrive d’écrire du code dont je suis vraiment fier, un code très abouti. De la structure jusqu’à chaque ligne, il n’y a aucune décision sans raison ; sur ce code-là, je suis un expert et je le maîtrise complètement. Mais la plupart du temps, je n’écris pas avec ce niveau d’exigence. Le plus souvent, c’est plutôt « il faut juste que le boulot soit fait », donc je m’autorise moi-même un standard un peu plus bas. Malgré tout, les rares fois où j’arrive à me concentrer pleinement pour produire quelque chose de vraiment bien, c’est extrêmement gratifiant et ce sont parmi mes meilleures expériences de code dans toute ma vie. Avec les LLM, c’est paradoxal : il est devenu à la fois plus facile et plus difficile de coder avec un haut niveau d’exigence. Quand je suis profondément concentré, je peux bien utiliser les LLM pour aller plus vite et viser un niveau encore plus élevé. Je peux écrire un code largement meilleur que celui du LLM, mais je peux aussi écrire un code encore meilleur avec son aide. Le problème, c’est qu’il devient de plus en plus difficile de rester dans cet état de concentration. On finit par survoler le code généré par le LLM, à se dire que l’apparence est correcte et que ça marche, donc on laisse passer. Mais ce code vaguement validé se dégrade peu à peu, devient de plus en plus médiocre, et à force de laisser passer ce genre de choses dans un état d’émoussement, il est déjà trop tard. Au final, on ne devient jamais soi-même l’expert de ce code, et on accumule seulement du code bancal

  • Ces deux derniers mois, en utilisant davantage l’IA, j’ai traversé ce processus :
    1. J’ai commencé par utiliser l’IA pour de petites tâches, et j’ai été impressionné par la qualité du résultat
    2. J’ai progressivement commencé à lui confier des tâches plus importantes en cherchant la meilleure manière de l’utiliser efficacement
    3. À ce stade, l’IA faisait presque tout toute seule comme un agent, et moi je ne faisais plus que relire le code à la fin
    4. J’ai alors compris que « je devais de toute façon tout examiner moi-même en détail, et que l’IA n’était finalement pas le raccourci magique que j’espérais » (par exemple, il est impossible de donner juste la grande ligne et d’obtenir en retour un code final crédible)
    5. Du coup, je suis revenu à un usage de l’IA centré principalement sur de petites tâches L’IA me semble utile pour la recherche, les prototypes, les POC, ou du code jetable du type « ça tourne, mais c’est inutilisable en production ». Pour la conception fondamentale ou l’architecture, je préfère garder la main ; pour l’implémentation de fonctions ou le remplissage de détails logiques, l’IA peut être d’une aide assez précieuse

• Cet essai correspondait tellement à ce que je pense que j’ai pris plaisir à le lire. J’ai essayé d’utiliser l’IA au travail, mais dans la plupart des cas le résultat était médiocre, donc j’ai presque toujours dû tout réécrire moi-même. Je suis convaincu que déléguer inutilement à l’IA mon temps de réflexion ou ma résolution de problèmes serait l’une des pires décisions pour ma carrière. L’IA n’est qu’un générateur de texte de qualité moyenne

  • Ce qui me frustre le plus, c’est que je pourrais en fait être vraiment très bon au développement assisté par LLM. Mes collègues, eux, sont totalement happés par ce nouveau monde, produisent en continu de l’AI slop et mettent un temps fou à travailler. Moi, en comparaison, j’ai un sens de l’architecture logicielle, je sais demander au LLM les corner cases importants, bref je sais mieux « comment donner des instructions à l’IA ». En plus, je gère bien le contexte, et, grâce à mes particularités neurodéveloppementales, je me suis entraîné toute ma vie à communiquer avec des êtres qui ne fonctionnent pas comme moi, ce qui me permet d’avoir une forme d’empathie plus mécanique avec les LLM. Mes collègues, eux, s’énervent davantage parce que les LLM ne lisent pas dans leurs pensées. Mais les LLM s’améliorent, donc mon avantage ne durera pas éternellement. Et à mesure que l’AI slop s’accumule, il faut encore utiliser davantage de LLM pour le gérer, ce qui crée un cercle vicieux. Au final, plus personne ne saura vraiment quel est ce code, et je finirai peut-être par simplement prier le dieu-machine

• À la question « Mais pourquoi ces gens ont-ils décidé de devenir programmeurs, alors qu’ils ne semblent même pas intéressés par le code lui-même ? », j’insiste sur le fait que « le but, c’est de résoudre des problèmes ». Le code est un moyen, pas une fin. « Régler son éditeur, ses dotfiles, bricoler son environnement de développement », ça peut être amusant, mais moi j’y vois une complexité inutile que je déléguerais volontiers

  • Configurer soi-même son éditeur, ses dotfiles et son environnement de développement, c’est au fond se familiariser avec son environnement de travail, développer sa maîtrise des outils et construire un environnement plus productif. Si, dès qu’il faut toucher à un script de build, il faut « appeler quelqu’un », c’est précisément parce que cette maintenance n’a pas été faite. Il y a énormément de gens qui utilisent Git depuis dix ou vingt ans et qui ne comprennent toujours ni les conflits de fusion ni même les usages de base ; au final, toutes les corvées finissent par retomber sur les rares personnes qui maîtrisent vraiment leurs outils

  • Le genre d’argument « ça n’a aucune valeur », si on le pousse jusqu’au bout de sa logique, peut finir par devenir « quelle valeur a le simple fait d’exister ? »

  • Le but de presque tous les métiers dans le monde est de résoudre des problèmes, alors je me demande quand même pourquoi, parmi tous ces métiers, ils ont choisi précisément le logiciel

  • Je suis d’accord à 100 % avec l’idée que « le but est de résoudre des problèmes, et le code n’est qu’un moyen ». Les gens qui sont tristes à l’idée que l’IA code à leur place sont plutôt du genre « artistes du code », davantage attachés à la « forme » de ce qu’ils créent. Moi, je me concentre sur le problème lui-même, donc que l’IA se charge de coder ne me manque pas du tout

  • L’idée que « le code n’est pas une fin mais un moyen », tout comme celle selon laquelle « bricoler son éditeur est amusant mais sans valeur », reste profondément subjective. Certaines personnes aiment le code pour lui-même, même en l’absence de problèmes à résoudre, et s’il n’existait plus aucun problème dans le monde, beaucoup continueraient malgré tout à aimer coder

• J’ai trouvé ce texte vraiment fascinant. Il correspond presque exactement à ce que je ressens vis-à-vis de la programmation avec des LLM. J’étais simplement quelqu’un qui aimait coder, et j’ai aussi pris plaisir à en faire mon métier. Mais aujourd’hui, je regrette de ne plus pouvoir vivre au travail ce hobby que j’aimais. C’est devenu une activité complètement différente

• Je suis un peu âgé. Vers 1995, on programmait dans un environnement totalement différent d’aujourd’hui. À l’époque, les ingénieurs connaissaient les clients visés, la stack technique, les tendances du secteur, et avaient vraiment la main. Leur code était leur terrain de jeu : ils le refondaient comme ils voulaient, choisissaient eux-mêmes l’indentation ou le style des accolades (et réparaient eux-mêmes quand ça cassait). Il n’y avait pas de tests unitaires (au mieux quelques vérifications de paramètres), et presque pas de code review formelle : on discutait simplement entre collègues au bureau autour d’un tableau blanc. Quand il y avait un bug, on le corrigeait immédiatement. Au final, le management a gagné, et j’ai l’impression que cette époque du « cowboy coding » a peu de chances de revenir. On peut être nostalgique de l’Apple des années 90, mais on ne peut plus y retourner. C’était vraiment amusant

  • J’ai commencé à peu près à la même époque, et chez nous, à cause d’ISO 9001, on faisait des code reviews régulières. On imprimait les livrables, puis trois personnes se réunissaient dans une pièce pour vérifier chaque ligne et signer. On appliquait ça à un RTOS de contrôle industriel. La gestion de projet se faisait avec un diagramme de Gantt de 40 pieds imprimé et collé au mur. C’était l’époque du pur waterfall

  • Moi, j’ai commencé à la fin des années 2000, et à l’époque les parcours de carrière et les frontières entre spécialisations étaient bien plus clairs. Les administrateurs système et les développeurs étaient nettement séparés, alors qu’aujourd’hui on attend de moi que j’assume aussi le rôle d’opérateur système, ce qui a élargi mon périmètre de travail. J’ai développé mes compétences système comme un hobby, et dans la pratique, quand on me confiait ce type de travail, la documentation fournisseur et les formations étaient si médiocres que j’avais surtout envie de détourner le regard

  • Je ne pense pas que l’ensemble du secteur revienne au cowboy coding, mais je pense que ce style subsistera encore dans certains environnements. Chez WhatsApp entre 2011 et 2019, c’était encore assez libre. Cela dépend du contexte, mais selon le coût de détection d’une erreur en amont et le coût de correction une fois en production, ce qui est approprié change. Personnellement, je préfère les approches qui réduisent le coût de correction des erreurs. Évidemment, ça ne veut pas dire faire des erreurs honteuses, et je teste tout ce qui est réellement nécessaire

  • Aujourd’hui, il y a trop de profils orientés business, de vibe coders et de script kiddies, et j’ai l’impression que tout s’est dégradé

  • Le problème du cowboy coding, c’est qu’un seul membre peu fiable peut ruiner toute l’équipe. Plus l’organisation grandit, plus le nombre de membres défaillants devient inévitable, et pour éviter l’explosion des problèmes, il faut des garde-fous de plus en plus lourds. Dans une petite équipe d’élite fondée sur la confiance, le cowboy coding est d’une efficacité redoutable, mais comme il est difficile d’évaluer précisément le niveau réel des candidats au recrutement, ce modèle ne convient pas du tout aux grandes organisations. À l’avenir, cette manière de faire ne survivra peut-être que dans de petites entreprises, ou dans de petites équipes au sein de grands groupes

• J’ai du mal à être d’accord avec l’auteur quand il dit que « Le LLM est une solution de dernière instance, une sorte d’arme nucléaire contre la complexité logicielle. Au lieu de résoudre le vrai problème, il tente d’en atténuer les symptômes en apportant une complexité encore plus grande ». L’objectif central de l’adoption de l’IA, c’est de centraliser les « talents créatifs, coûteux et hautement qualifiés » dans un tout petit nombre d’entreprises qui conçoivent l’IA, puis de licencier les travailleurs créatifs dans toutes les autres entreprises pour ne garder qu’une main-d’œuvre plus simple. Autrement dit, le but est de simplifier avec l’IA la complexité propre à chaque entreprise. Pour reprendre Le Magicien d’Oz, personne ne veut regarder derrière le rideau : tout le monde veut juste que son travail devienne plus facile. C’est ce qui se produit quand on ignore entièrement les risques de long terme pour ne chercher que les gains à court terme

  • On a déjà vu ce genre de centralisation dans beaucoup de secteurs. Par exemple, dans la banque, les banquiers locaux prenaient autrefois des décisions en tenant compte des réalités de leur région, alors qu’aujourd’hui le siège central décide de tout. Les banquiers locaux sont repoussés dans le monde « sous l’API », tandis que les élites du siège captent toute la richesse. Les notions de « legibility » et de Seeing Like a State sont utiles pour réfléchir à ça

• J’ai vraiment aimé ce texte. Je suis aussi d’accord avec certains commentaires qui disent que résoudre le problème est plus important que le code. Mais à mon avis, si on commence à confier à l’IA même les problèmes qui demandent une réflexion profonde, cette capacité même de résolution en profondeur risque de s’atrophier avec le temps. Se contenter de demander « fais-moi quelque chose » ne me semble pas relever de la véritable résolution de problème

  • Je pense qu’on peut aimer à la fois la résolution de problèmes et l’artisanat. Logiquement, résoudre le problème est sans doute la valeur la plus importante, mais pour certaines personnes, le plaisir venait davantage du fait de coder, manipuler et fabriquer par elles-mêmes ; il est donc naturel qu’elles regrettent la disparition de cette joie. Comme dans ce texte, les gens qui se définissent comme « programmeurs » aiment en général vraiment résoudre des problèmes, construire, faire eux-mêmes et bricoler