Le chagrin et la fracture des développeurs révélés par le coding avec l’IA

• La diffusion des outils de coding avec l’IA fait remonter à la surface des différences de motivation qui existaient depuis toujours entre développeurs, mais restaient invisibles
• Le chagrin lié à la perte de la satisfaction artisanale d’écrire du code et celui lié aux changements de l’écosystème et de l’environnement de carrière autour du code relèvent de deux formes de perte différentes
• Vu par un développeur qui programme depuis les années 1980, le coding avec l’IA est le prolongement naturel d’un niveau d’abstraction supplémentaire, de la transition du C64 BASIC vers l’assembleur jusqu’au passage des fonctions à la conception de systèmes
• L’expérience accumulée à lire et relire du code pendant des décennies reste pleinement valable comme sensibilité et jugement pour évaluer la qualité du code généré par l’IA
• Le point essentiel est de reconnaître le type de chagrin que l’on ressent : la perte artisanale et la perte contextuelle exigent des réponses différentes

---

Le début du deuil

• James Randall, développeur qui a commencé à programmer à 7 ans dans les années 1980, décrit comme « compressée » l’expérience de découverte et de persévérance qui consistait à comprendre quelque chose par soi-même
  • Cela n’a pas complètement disparu, mais quelque chose se perd dans cette compression
• Nolan Lawson exprime plus directement ce sentiment de perte dans son texte "We Mourn Our Craft"
  • Il nous manquera la sensation de façonner le code à la main, les nuits à 2 heures du matin passées à traquer un bug avec le débogueur, la fierté de se dire « c’est moi qui l’ai fait »
• Ces émotions sont bien réelles et renvoient à une perte effective, mais à la lecture, l’impression persistait que chacun faisait le deuil de quelque chose de différent

La nature de la fracture

• Le coding avec l’IA révèle une fracture moins visible qui existait depuis longtemps parmi les développeurs
• Avant l’IA, les deux camps travaillaient de la même manière : mêmes éditeurs, mêmes langages, même workflow de pull request
  • Les développeurs orientés artisanat et les développeurs orientés résultat étaient assis côte à côte, livraient le même produit, et il était impossible de les distinguer
  • La motivation derrière le travail restait invisible, parce que le processus était identique
• Désormais, une bifurcation apparaît : confier le code à la machine et piloter ce qu’il faut construire, ou bien continuer à écrire le code soi-même
  • C’est à ce moment de choix que la raison pour laquelle on a commencé à programmer devient enfin visible
• La même fracture existait déjà dans les cours de mathématiques et d’informatique à l’université : certains aimaient les preuves et les théorèmes pour eux-mêmes, d’autres ne s’y intéressaient que lorsqu’ils pouvaient être appliqués

Mon chagrin était différent

• Au cours des 18 à 24 derniers mois, il y a bien eu une période de chagrin et d’adaptation
• J’avais peur de ne pas pouvoir comprendre ces nouveaux outils, mais en réalité j’ai pu les comprendre
• Je craignais de perdre ma capacité à juger la qualité du code produit par l’IA, mais des décennies passées à lire et à relire du code ne se sont pas évaporées
  • Je continue à voir quand quelque chose ne va pas, et ce discernement est toujours là
• J’avais peur que la résolution d’énigmes soit terminée, mais en réalité je suis simplement monté d’un niveau
  • Du placement d’octets sur un C64 à l’écriture de fonctions, puis à la conception de systèmes : le même schéma que dans toutes les transitions de ma carrière
  • Désormais, l’énigme s’est déplacée vers l’architecture, la configuration et la direction d’assistants
• La plupart de ces peurs n’ont pas résisté à la réalité, mais une part de chagrin demeure

Le chagrin qui demeure

• Ce n’est pas de ne plus écrire du HTML à la main, mais un chagrin lié à l’écosystème du web ouvert lui-même
  • L’entraînement des IA sur les biens communs et la concentration accrue de ceux qui façonnent l’expérience des internautes constituent une perte bien réelle
  • C’est un problème qui ne disparaît pas, indépendamment des gains de productivité personnels
• Il y a aussi un chagrin face au changement du paysage des carrières
  • Le développement web, pratiqué depuis plus de 30 ans, n’est plus un domaine aussi brûlant qu’avant
  • Les applications mobiles en ont capté une partie, et l’ingénierie IA occupe désormais la position dominante
  • J’ai le sentiment de réussir ma transition, mais l’anxiété est réelle et elle n’est pas encore retombée
• Le cœur de ce chagrin est le suivant : il ne s’agit pas de regretter l’acte même d’écrire du code
  • C’est le chagrin de voir changer le monde autour du code
  • Le chagrin de Randall et Lawson porte sur l’artisanat lui-même, alors que celui de ce texte porte sur le contexte et les raisons

Aucun des deux camps n’a tort

• Dans un texte en réponse à Lawson, Kevin Lawver défend l’idée qu’au lieu de s’accrocher au passé, il faut rediriger l’artisanat et la passion
• Au-delà d’un cadrage simpliste nostalgie contre pragmatisme, il est concrètement utile de reconnaître le type de chagrin que l’on ressent
• Si l’on fait le deuil d’une perte artisanale, entendre « adapte-toi, c’est tout » ne résout rien
  • Il faut peut-être retrouver cette satisfaction ailleurs, ou accepter que la sensation procurée par le travail change
  • Le fait même d’avoir pu tirer sa subsistance de cet artisanat jusqu’ici relevait déjà de la chance
• Si l’on fait le deuil d’une perte contextuelle, des réponses plus concrètes sont possibles
  • On peut apprendre de nouveaux outils, continuer à défendre le web que l’on veut — même s’il s’agit d’un petit web — et à la fois s’adapter tout en restant triste
• Citation de Nolan Lawson : "Je ne célèbre pas ce nouveau monde, et je ne lui résiste pas non plus. Le soleil se lève et se couche, et moi je tourne impuissant sur mon orbite, incapable par mes protestations de l’arrêter."
  • Mais reconnaître qu’il existe aussi un peu d’excitation au milieu du chagrin et de la peur est un aveu honnête

Faire travailler l’ordinateur

• Depuis que j’ai commencé à programmer dans les années 1980, tous les langages que j’ai appris ont été des moyens au service d’une fin
  • Une nouvelle manière d’amener l’ordinateur à faire ce que je voulais
• Le coding avec l’IA est la dernière étape de cette continuité, non pas une rupture mais le barreau suivant de l’échelle
• Sauf que cette échelle elle-même est en train de changer, et que le bâtiment contre lequel elle est appuyée change lui aussi, si bien qu’on ne sait pas exactement où elle mène
• Une chose reste certaine : la satisfaction ressentie au moment où quelque chose de pensé et construit fonctionne réellement n’a pas changé depuis plus de 40 ans
  • Le chemin emprunté par le code pour y parvenir a changé, mais ce moment où ça fonctionne reste le même

[github88]

On en fait beaucoup trop.

[ahwjdekf]

Je pense que c’est une très bonne chose que l’IA s’occupe de trucs comme la programmation web.

[brilliant08]

Il paraît donc que les autres formes de programmation ont une sorte de valeur sacrée.

[onetoday]

J’ai parfois l’impression que la moyenne d’âge sur HN est assez élevée et que ce sont un peu des gens en train de décrocher.
Du coup, j’ai tendance à passer mon chemin sans lire ce genre de billets négatifs (et pas simplement critiques).

Cela dit, il m’arrive encore parfois de me rappeler le plaisir de coder moi-même,
comme je suis plutôt côté web, je me dis que c’est peut-être un peu plus faisable,
mais ça fait maintenant plus de trois mois que je n’ai pas tapé une ligne de code.

Surtout, développer comme ça est tellement amusant que je me retrouve à faire beaucoup d’heures sup de mon plein gré, comme quand j’étais plus jeune.

[snisper]

Si l’IA vous préoccupe autant, il suffit peut-être de ne pas l’utiliser.

[savvykang]

Je me demande comment les gens avaient réagi à l’époque où les outils RAD sont apparus.

[GN⁺]

Réactions sur Hacker News

• Je pense que l’article passe complètement à côté du sujet. Même les développeurs « artisanaux » (craft) visent le résultat, mais un résultat durable et extensible
  Le but d’un bon programmeur est de se rendre inutile. Il fut un temps où l’on comptait les cycles en assembleur et où l’on empaquetait les bits à la main, puis l’usage des compilateurs est devenu évident. Il y a eu une époque où l’on écrivait soi-même des applis CRUD, mais aujourd’hui les frameworks s’en chargent. La gestion mémoire, les systèmes de types, les langages de haut niveau, les systèmes no-code/low-code font tous partie du progrès. Au fond, le but de la programmation est de faire en sorte que l’ordinateur accomplisse ce que nous n’avons plus besoin de faire nous-mêmes
  La vraie fracture, à mon avis, est une différence d’état d’esprit entre ceux qui voient le logiciel comme quelque chose qu’on peut améliorer et comprendre, et ceux qui le voient comme un obstacle incompréhensible fabriqué par d’autres
  • J’aime bien cette perspective. Quand on travaille longtemps sur un système, tous les détails finissent par paraître significatifs. On développe une intuition de l’impact qu’un changement aura sur l’ensemble. Mais j’ai peur qu’avec le logiciel à l’ère de l’IA, ce type de compréhension devienne impossible. Trop de code sera généré automatiquement, au point qu’il sera difficile d’embrasser l’ensemble. Au final, si modifier devient trop compliqué, il sera peut-être plus rationnel de tout refaire avec l’IA. C’est pourquoi la modularité (modularity) va sans doute devenir encore plus importante
  • Je suis d’accord avec presque tout, sauf la dernière phrase. Ce n’est pas tant une question d’intelligence ; en pratique, les gens de la deuxième catégorie sont souvent simplement moins bons
  • Je me demande si cette distinction ressemble à celle de Pirsig entre le « classique » et le « romantique ». Les premiers cherchent à comprendre la structure et les principes, les seconds privilégient l’apparence, la sensation et l’utilité
  • On entendait souvent autrefois que « les bons programmeurs se rendent inutiles », mais on dirait que cette idée a presque disparu aujourd’hui
• La vraie fracture oppose ceux qui croient que le progrès technologique est intrinsèquement bénéfique et ceux qui savent qu’historiquement, les gains de productivité n’ont pas conduit à une réduction du temps de travail
  La journée de 8 heures n’a pas été obtenue par la technologie, mais par la lutte politique
  • La vraie fracture est entre les détenteurs du capital et les travailleurs. Les capitalistes vivent en mangeant une partie de ce que produisent les travailleurs, grâce à des bouts de papier hérités
  • C’est intéressant de voir ce type de discussion apparaître plus souvent sur Hacker News. Si l’IA remplace les développeurs, des gens intelligents et motivés pourraient bien se politiser. Historiquement, quand les entreprises deviennent trop grandes, on finit par les traiter comme des États
  • Il y a trop d’affirmations extrêmes. Au fond, la vraie fracture est entre les partisans de la science et de la technologie et ceux qui les détestent
• Ce n’est plus simplement une histoire de gens qui aiment taper sur des claviers mécaniques. La vraie différence oppose ceux qui aiment comprendre les systèmes et en créer de nouveaux, et ceux qui préfèrent déléguer cela à d’autres et ne récolter que le résultat
  Cela dit, si l’« autre » est un humain, on peut partager le mérite via le mentorat ou la mise en place d’un bon environnement
  • C’est drôle comme la « vraie fracture » finit toujours par opposer « moi, intellectuellement ou moralement supérieur » à « eux, les inférieurs »
  • J’aime comprendre les systèmes et en créer de nouveaux, tout en appréciant de déléguer les tâches répétitives à l’IA. Donc je ne devrais pas exister ? Je ne suis pas d’accord
  • Il y a deux types de développeurs. Le type A est méticuleux sur la sécurité, les tests, la CI, mais peut frustrer les utilisateurs. Le type B est moins bon sur les tests ou le déploiement, mais se soucie davantage de l’expérience utilisateur. On a besoin des deux. Cela dit, l’IA remplacera sans doute d’abord le domaine du type A
  • C’est un peu une sensation de « Claude, soulève ce poids pour moi »
  • Chacun trouve son plaisir à des endroits différents. Moi, j’aime le processus de résolution de puzzle. Improviser une solution m’amuse plus que suivre un plan
• Avant l’IA, les deux groupes faisaient le même travail — le même éditeur, les mêmes langages, le même workflow de PR. La différence, c’était la motivation. C’est pourquoi certains aiment que l’IA écrive le code à leur place, alors que d’autres regrettent la disparition de la partie qu’ils aimaient
  Le texte de Kellan, « Code has always been the easy part », va dans le même sens. Notre génération s’est lancée dans la tech parce qu’elle était devenue accro au sentiment d’agency que procurait le web
  • La vraie différence, c’est le niveau d’exigence en matière de qualité. Certains passent des heures sur un seul nom de variable, d’autres pensent que « si ça tourne, c’est bon ». Les deux ont de la valeur. Mais vu la vitesse d’évolution des modèles, il ne faut pas juger selon les standards de l’an dernier. La sortie par défaut est moyenne, mais bien utilisés, ils peuvent produire une qualité bien supérieure
  • Programmer en Perl n’avait rien de plaisant esthétiquement ? Moi, j’étais fier de maîtriser Perl. Il y avait un vrai plaisir à manier librement un langage difficile à lire
  • Perl avait clairement son charme. Une syntaxe comme unless permettait d’exprimer le flux de manière naturelle. Mais comme son évolution s’est arrêtée, chacun l’a étendu à sa façon, ce qui a créé des bases de code fragiles
  • Je n’aime pas coder en soi, mais la satisfaction d’avoir résolu un problème est énorme. J’ai l’impression que ce type de réflexion aide à garder le cerveau souple
  • Ce n’est pas une dichotomie. Je suis un mélange des deux. L’IA prend en charge le code au travail, ce qui me laisse l’énergie de profiter d’un codage plus traditionnel chez moi
• Je suis orienté résultats. J’accorde de l’importance à la qualité du résultat. Je suis plus obsédé par la finition du produit final que par le processus de codage. Pourtant, les applis d’aujourd’hui sont plus lentes et plus buggées qu’il y a 15 ans. Même l’app Claude affiche parfois des boutons sur lesquels on ne peut pas cliquer
  Le codage avec l’IA n’apporte qu’environ 10 % de productivité en plus. Le vrai goulot d’étranglement, c’est comprendre quoi construire et convaincre les autres. Le code n’est qu’un moyen de formaliser cette compréhension
  • Moi aussi, j’utilise plus souvent l’IA pour collecter et vérifier des informations que pour écrire du code. Je fais relire par plusieurs LLM qui se critiquent mutuellement. C’est très utile pour traiter une logique métier complexe. L’IA est aussi pratique pour explorer les edge cases
  • Je suis d’accord pour dire que le codage n’est pas le goulot d’étranglement. Dire que l’IA apporte une productivité multipliée par 10 n’a aucun sens. À la base, je code déjà vite, donc l’IA ne m’aide pas tant que ça. Au contraire, on se retrouve dans une situation où la vitesse est imposée au détriment de la qualité. Mes coéquipiers crachent des milliers de lignes avec l’IA, et la qualité du code s’effondre
  • J’ai l’impression qu’on confond qualité du code et finition du produit. La plupart des problèmes viennent de décisions business
  • Si seul le résultat compte, on peut aussi demander : « pourquoi ne pas externaliser directement au lieu de le faire soi-même ? »
• Le « web où l’on écrivait le HTML à la main » me manque. C’est triste de voir l’écosystème web DIY créé directement par des individus être remplacé par des outils d’IA appartenant à des entreprises. Nous sommes encore dans une phase intermédiaire, mais le déclin du web ouvert s’accélère déjà
• L’IA générative peut aussi s’inscrire dans une forme d’artisanat. On peut charger du code open source et demander « pourquoi ça fonctionne comme ça ? », pour faire un développement fondé sur la compréhension
  • Le plaisir de résoudre des puzzles n’a pas disparu ; il s’est déplacé d’un niveau vers le haut. Désormais, le domaine de l’artisanat, c’est la conception de la structure globale du système et des raisons qui la sous-tendent
  • Bien sûr, il faut ensuite contribuer en amont (upstream)
  • En réalité, on pouvait déjà faire ce genre de chose avec un moteur de recherche
• Les trois scénarios sont mauvais. ① une IA faible → Grande Dépression 2.0, ② une IA au niveau attendu → monopole d’une poignée d’ultra-riches, ③ une IA surpuissante → extinction de l’humanité. La quantité idéale d’IA est de 0
  Cela dit, il faut quand même essayer de résister
  • Je pensais comme ça avant, moi aussi, mais en voyant ces temps-ci les limites concrètes après le boom de l’IA, j’ai l’impression que le marché va bientôt se corriger. On est plus proche de l’époque d’AOL
  • Une véritable intelligence ne consiste pas simplement à transformer du texte en appels d’outils ; elle doit aussi inclure la planification, la critique et la résolution créative de problèmes
  • En réalité, les scénarios 1 et 2 profitent aux mêmes personnes. Le scénario 3 est un fantasme destiné à détourner l’attention du public
• Après de longues années en startup, j’ai abandonné l’idée d’« artisanat ». En revanche, j’ai développé une intuition très nette du danger que représentent l’absence de revue de code IA ou des PR trop volumineuses. Ce n’est pas une question d’artisanat, mais de précision et de gestion de la dette technique
  • Le problème, ce ne sont pas les « gens orientés résultats », mais ceux qui s’attribuent le mérite tout en évitant le travail. Même si leur code casse tout, ils sont déjà passés à un autre projet
  • D’après mon expérience, la vraie question n’est pas tant « artisanat vs résultats » que le sens de la construction de l’ensemble du bâtiment. Que l’IA prenne en charge une partie comme un sous-traitant, très bien, mais en ce moment, on est au niveau de l’externalisation de l’ensemble, et le résultat est catastrophique
• Il y a deux types de développeurs : ceux qui aiment trop coder pour ne pas devenir managers, et ceux qui deviennent managers dès qu’ils en ont l’occasion. Ce sont les seconds qui profitent le plus de l’IA
  • Les gens doués avec les humains devraient devenir managers. Et il existe une troisième catégorie — ceux qui aiment concevoir des systèmes et délèguent l’implémentation aux autres