Les LLM grignotent ma carrière d’ingénieur logiciel, et je ne sais pas quoi faire

• Les outils de développement basés sur les LLM interviennent désormais dans la rédaction des documents de conception, la planification de l’implémentation, l’écriture du code et le débogage, ce qui affaiblit la différenciation apportée par 10 ans d’expertise backend en paiement et finance
• Dans la finance et les paiements, la connaissance métier constituait un avantage compétitif fondé sur l’expérience de la conformité PCI, des grands livres en partie double, de l’escrow, du rapprochement, du cycle de vie des paiements et de l’idempotence des virements bancaires, mais le premier choc est venu lorsque les modèles ont commencé à saisir les liens structurants des systèmes
• Avec Claude Code, Codex, MCP, DataDog MCP, etc., l’automatisation du débogage s’étend : certains bugs sont résolus à partir d’une simple stack trace et du contexte Sentry, puis 90 % des bugs en systèmes distribués finissent traités en un seul essai
• Les deux derniers bastions, la qualité du code et l’architecture, se retrouvent eux aussi réduits à une affaire de « taste », et l’on s’oriente vers un monde où l’on accepte des codebases notées C ou D, manipulées par des LLM, plutôt que des codebases notées A ou B, agréables à lire pour des humains
• Pour préserver son employabilité à long terme, il faudrait déplacer son expertise vers des domaines où les LLM n’excellent pas facilement, mais une reconversion vers la recherche est contrainte par le pays de résidence, la concurrence sur les candidatures, la situation familiale et le risque de RSI

---

Parcours professionnel

• Ingénieur logiciel avec 10 ans d’expérience professionnelle, j’ai commencé côté front-end web parce que le débogage y était plus simple, avant de basculer vers le backend
• Par hasard, j’ai occupé un rôle de développement logiciel dans la finance, la tenue comptable (bookkeeping) et le traitement des paiements, avec une forte autonomie dans une relation proche et franche avec les Product Managers et les parties prenantes
• J’ai accumulé de la connaissance métier sur la conformité PCI, les grands livres en partie double (double-entry ledgers), l’escrow, le rapprochement (reconciliation), le cycle de vie des paiements (payment lifecycles) et l’idempotence des virements bancaires (bank transfer idempotency)
• Faire carrière en devenant expert métier était un choix clair de différenciation dans un domaine où la demande de spécialistes montrait des signes de hausse

Le premier pilier à s’effondrer : la connaissance métier

• L’an dernier, j’ai rejoint une entreprise du secteur financier ; mes sociétés précédentes avaient une forte composante paiements et finance, sans être centrées uniquement sur la finance
• Cette nouvelle entreprise a adopté l’IA à fond, fournissant dès le premier jour des comptes ChatGPT et Claude Enterprise, et encourageant son usage pour la recherche, l’exploration et le code
  • À une condition : chaque ligne de code envoyée en production doit être relue et assumée personnellement
• Mon premier projet consistait à reprendre un ancien système de paiement en ligne chaotique, une tâche qui m’a été confiée en raison de mon expérience passée dans ce type de construction
• Les Design Docs rédigés avant de coder devaient pouvoir être lus à la fois par les ingénieurs et les Product Managers ; il fallait donc des documents plus orientés architecture que plongée technique détaillée
• J’ai rédigé mes premiers Design Docs avec une aide minimale de l’IA ; à l’époque, j’appelais encore les LLM des « stochastic parrots », une position que je ne défends plus aujourd’hui
• Le retour de mon manager était que je livrais du bon code à bon rythme, mais que je passais trop de temps sur les Design Docs et devais davantage utiliser l’IA
• Les modèles n’étaient pas aussi bons qu’aujourd’hui, mais ils étaient déjà suffisamment efficaces pour accélérer l’écriture et la prise de décision
• C’est à ce moment-là que la valeur de mes années d’expérience sur les compromis d’implémentation, le fonctionnement de l’acquiring et la structuration de l’idempotence pour éviter la double facturation a commencé à diminuer
  • Le modèle nécessitait encore du pilotage, mais il pouvait déjà saisir les liens de structuration d’un système, soit précisément la partie la plus difficile, celle qui ne se forme dans l’esprit qu’après des années de pratique
• Comme le web regorge de billets explicatifs, de documentation technique et d’articles de blog sur l’application d’outils techniques à ce domaine, il était logique que les modèles aient absorbé cela dans leurs données d’entraînement
• Je pensais qu’il nous resterait au moins le débogage pour continuer à nous distinguer, et que mon expérience des race conditions en production et du débogage de systèmes distribués garantirait mon employabilité à long terme

Le deuxième pilier à s’effondrer : le débogage et les systèmes distribués

• Une fois les LLM devenus bons pour rédiger des documents et aider à planifier les implémentations, ils sont aussi devenus bons pour écrire du code, et la tendance s’est amplifiée avec l’engouement autour de Claude Code au second semestre 2025 et l’arrivée de Codex
• Avant cela déjà, j’utilisais les LLM tous les jours pour écrire des tests unitaires, sans leur faire suffisamment confiance pour leur déléguer une implémentation complète
• Introduire davantage d’IA dans l’écriture du code était l’étape suivante naturelle, et comme j’aimais autant les mises en production et la satisfaction utilisateur que le simple fait de coder, l’échange me paraissait acceptable
• Les LLM sont devenus compétents pour écrire du code, mais ils ne savaient pas encore déboguer le chaos laissé par les modèles ou par les humains, ce qui me laissait un rôle plus important que celui de simple chef d’orchestre des robots
• Puis l’arrivée de MCP, des workflows agentiques et de Claude 4.5 a commencé à fissurer aussi ce pilier du débogage
• Claude 4.5 résolvait environ 60 % des bugs à partir d’une simple stack trace et d’un peu de contexte ; dans la plupart des cas, un lien Sentry avec Sentry MCP activé suffisait
  • Il produisait parfois des solutions plausibles mais totalement fausses
• À partir de là, j’ai cessé de me méfier de la machine, après l’avoir vue résoudre d’un seul coup avec Claude Code des bugs qui m’auraient autrefois occupé toute une journée
• Puis sont arrivés 4.6, 4.7, GPT 5.5, Opus 4.8 et DataDog MCP, et la CLI s’est mise à résoudre d’un seul essai des bugs de systèmes distribués
  • Y compris des bugs que je n’aurais pas su résoudre auparavant, des bugs qui auraient exigé deux jours entiers de débogage à plein temps, ou des bugs de systèmes distribués avec une observabilité insuffisante
  • Race conditions bizarres, corner cases imprévus, problèmes d’intégration avec des tiers, cas limites d’API non documentés : 90 % de ces bugs se résolvent désormais en un seul essai
• Il faut toujours quelqu’un pour relire le code et piloter les robots, donc je reste employé, mais je suis devenu un ingénieur standardisé
• Mon expertise finance-paiement, mon intuition de débogage et mes connaissances en systèmes distribués se sont transformées en savoir « promptable » qu’un autre ingénieur senior peut obtenir en pilotant un LLM
• Contrairement à ce que l’on enseignait, à savoir qu’il y a de la place pour les généralistes comme pour les spécialistes, le marché semble désormais vouloir transformer tout le monde en généraliste
  • Et si tout le monde devient généraliste sans que la demande suive, le prix des généralistes baisse ; or la demande, elle, est en recul

Le troisième pilier, pas encore tombé : la qualité du code et l’architecture

• Le pilier qui reste encore est celui de la qualité du code et de l’architecture logicielle, aujourd’hui déjà réduit au mot « taste »
• Tout au long de ma carrière, j’ai aimé le refactoring, j’ai accordé de l’importance au bon code et j’ai toujours su négocier du temps dans les sprints pour cela
• J’ai aimé discuter des compromis et de la structure des codebases autour de sujets comme DDD, l’architecture hexagonale ou la Clean Architecture
• Les agents sont des outils très faibles pour maintenir une codebase propre
  • Sans pilotage, les dépendances circulaires apparaissent très vite
  • Ils ajoutent du code dupliqué, insèrent des commentaires inutiles, mélangent fonctions pures et effets de bord, et ignorent les principes SOLID
• Cette capacité devrait être l’un des derniers remparts de l’employabilité humaine, mais l’industrie la réduit à du « taste » et se dirige vers un monde où l’importance de l’organisation du code diminue
• Les humains gardent encore un rôle de pilotage des agents pour éviter les codebases spaghetti truffées de graphes de dépendances circulaires
• Personne ne veut d’une codebase notée F, où toucher à quoi que ce soit casse le reste, mais du C ou du D est désormais considéré comme acceptable
• Si l’on n’a plus besoin de codebases notées A ou B, c’est parce qu’elles sont maintenant conçues moins pour être lues par des humains que pour être manipulées par des LLM
• Et si le code source est désormais écrit pour être lu par des machines plutôt que par des humains, alors on peut aussi choisir de se tourner vers la machine
• La connaissance de la qualité du code et de l’architecture perd elle aussi de sa valeur ; le temps consacré à lire des livres, à pratiquer concrètement, à débattre avec d’autres ingénieurs et à rédiger des ADR devient inutile

Alors, que faire maintenant ?

• À court terme, je pense rester employé — du moins dans mon entreprise actuelle — mais les perspectives à long terme sont incertaines
• Sur le long terme, la valeur de ce dans quoi j’ai investi 10 ans, voire davantage si l’on compte l’expérience non spécialisée, continue de diminuer
• Le dernier pilier d’expertise lui aussi a été réduit à une affaire de “taste”
• Il y a environ 8 mois, mon entreprise a procédé à des licenciements (présentés comme sans rapport avec l’IA), et d’excellents anciens collègues licenciés sont toujours à la recherche d’un emploi
  • Beaucoup d’entre eux se heurtent au même problème : l’expertise métier seule ne permet plus de se différencier
• L’entreprise recrute à nouveau pour certains postes, mais la familiarité avec le domaine n’est plus un facteur de différenciation fort
  • Avant, les offres étaient publiées sous la forme « Software Engineer - Area » ; désormais, elles portent simplement le titre « Software Engineer », l’affectation à une équipe se faisant après acceptation de l’offre
• C’est une évolution qui ouvre de meilleures opportunités aux excellents ingénieurs qui n’avaient pas eu l’occasion d’accumuler une expérience métier approfondie
• Mais c’est aussi une évolution qui place sur la même ligne de départ d’excellents ingénieurs ayant consacré toute leur vie à accumuler de la connaissance métier
• Le seul moyen de préserver son employabilité à long terme semble être de déplacer son expertise vers des domaines où les LLM n’excellent pas facilement
• Je réfléchis aussi à l’option de retourner à l’université pour étudier les mathématiques, les statistiques et le Machine Learning avancé, puis postuler à des postes de recherche dans des frontier labs
  • Il n’existe pas de frontier lab dans le pays où je vis, et les rares instituts qui existent sont submergés de candidatures
  • Ma situation familiale rend un déménagement vers un autre pays difficile
  • Et même si cela devenait possible, il existe aussi la possibilité que le RSI (amélioration récursive de soi) rende les chercheurs inutiles d’ici là
• J’en suis au point d’envisager de transformer mon hobby du travail du bois en métier, tant je me sens dans l’impasse

[GN⁺]

Commentaires Hacker News

• Quoi ? Je pilote des LLM toute la journée, mais je n’accepterais absolument jamais d’être responsable d’un produit financier
  Le premier pilier tient toujours. L’auteur ne se rend peut-être pas compte de sa propre influence, mais à voir les PR annulées, je sais que dès que je sors d’un domaine que je connais en profondeur, je ne peux plus déterminer si l’agent raconte n’importe quoi. Même notre meilleur agent, qui a accès aux systèmes distribués comme l’a mentionné l’auteur, se trompe souvent, a une vision étroite et fait constamment des choses stupides. Au final, c’est encore l’expertise des ingénieurs de l’équipe qui remet les choses sur les rails

  • J’écris avec un compte temporaire pour éviter de révéler mon identité. Je travaille dans une FinTech qui construit des produits réglementés et j’ai accès à Mythos
    Mythos a affirmé avec assurance qu’une partie de notre base de code violait une réglementation précise et que, exploitée de cette manière, elle représentait un risque grave. Mais c’était faux : il avait halluciné les exigences réglementaires. Je le savais parce que ce code avait déjà été examiné par un conseiller juridique humain. Et on nous dit que c’est le meilleur modèle disponible à l’heure actuelle. J’utilise beaucoup l’IA générative pour aider à écrire du code, mais même à moyen terme, on ne peut pas réellement s’appuyer sur ce type d’outil pour construire des produits financiers conformes à la réglementation. Ce serait complètement fou. Oui, beaucoup d’entreprises FinTech utilisent des agents pour gagner en vitesse, mais s’en servir pour lancer un produit sans qu’un humain l’ait réellement examiné en profondeur, c’est assumer un risque énorme
  • On dit que « l’expertise des ingénieurs de l’équipe remet les choses sur les rails », mais comment être sûr que mes collègues sont plus experts que moi ?
    Avant les LLM, dans la plupart des entreprises, il y avait de la place pour que d’excellents ingénieurs et des ingénieurs moyens travaillent ensemble. Après les LLM, seuls les ingénieurs « d’élite » pourront survivre, parce qu’on n’aura plus besoin des ingénieurs moyens. Étant donné la nature de HN, la plupart des ingénieurs qui lisent ce texte pensent probablement faire partie des 10 à 5 % supérieurs de leur entreprise, de leur ville ou de leur pays, et donc ne pas être ces ingénieurs « moyens » qui subiront l’impact de l’adoption des LLM. Statistiquement, il y a de fortes chances que ce soit faux. Au fond, c’est une question d’ego. Il est probable que vous ne soyez pas une rockstar, et les LLM pourraient finir par prendre votre travail. Comme toujours, les gagnants ne seront que les entreprises et les dirigeants, et comme la plupart d’entre nous sommes tout au bout de la chaîne, c’est nous qui en subirons les conséquences
  • Sur les PR avec des exigences complexes, j’observe que le temps jusqu’à la PR initiale est devenu très court, mais qu’ensuite commence un ping-pong entre le relecteur et le développeur
    Dans ce que je vois, le développeur a fait une partie du travail en vibe coding, et comme il n’a pas de compréhension approfondie ni des exigences ni de son propre code, il faut plusieurs itérations pour corriger. On peut dire que c’est un problème humain, mais l’effet net que j’observe est le suivant : dans les cas complexes, on est passé de « temps de rédaction de PR assez long + temps de revue assez long » à « temps de rédaction de PR très court + temps de revue plus long ». Je ne sais pas s’il y a un vrai gain dans ces cas-là. Parfois, même quand le code est fonctionnellement correct, il devient verbeux à cause d’un trop grand nombre de fonctions intermédiaires, et cela risque d’avoir un impact sur les revues futures
  • Malheureusement, l’ensemble du secteur logiciel adopte les LLM / la génération de code. Banques, FinTech, assurances, tout le monde y passe
    J’ai les mêmes inquiétudes, mais on les balaie souvent ou on les noie dans des réponses du genre : « ne vous inquiétez pas, le gain en vitesse de livraison et le ROI en valent la peine »
  • Je ne sais pas combien de temps encore cette phrase — « je pilote des LLM toute la journée, mais je n’accepterais pas d’être responsable d’un produit financier » — pourra tenir dans un employeur donné
    Personnellement, toutes les FinTech avec lesquelles j’ai été en contact avaient depuis l’an dernier une sorte de compte IA pour les développeurs. Même dans des boîtes comme Jane Street, des employés publient des billets de blog pour dire qu’ils passent l’essentiel de leur temps à piloter des agents. Combien de temps pensez-vous encore que votre entreprise pourra résister ?

• Je vois souvent des commentaires du type « notre métier est à l’abri parce que l’IA n’arrive pas à faire X avec une précision de 80 à 100 % »
  Je ne veux pas paraître excessivement pessimiste, mais les modèles progressent vite. Si, il y a environ trois ans, on avait décrit la situation actuelle en disant qu’« avec un seul prompt, un modèle crée une application MVP complète en environ 30 minutes », cela aurait semblé relever de la science-fiction. Les obstacles actuels des modèles — réduction du taux d’hallucination, garantie de conformité aux règles, maintien d’une base de code propre — ne paraissent pas si lointains à surmonter. Même la récupération d’informations spécifiques est déjà partiellement possible via plusieurs serveurs MCP/RAG. L’avenir des ingénieurs logiciels m’inquiète. Une fois ces défauts résolus, où se situera encore le métier ? Dans un rôle consistant à déléguer des tâches aux modèles d’IA ? Malheureusement, cela n’exige pas des années d’expertise, ce qui en fait une arme à double tranchant. Vérifier les sorties de l’IA ? Il suffit de lui demander d’expliquer chaque ligne qu’on ne comprend pas. De la même manière que les calculateurs humains ont été remplacés par les ordinateurs numériques, j’ai l’impression que nous verrons encore une vague de licenciements plus importante. Faire de tête des calculs mathématiques complexes peut être un défi amusant, mais c’est bien plus lent et plus sujet aux erreurs qu’un ordinateur. De la même façon, écrire du code à la main finira sans doute par apparaître comme un « défi » amusant, et l’IA comme la calculatrice moderne

  • Je recommande vraiment de regarder ce court extrait
    https://youtu.be/5eqRuVp65eY?si=3fLT6S5q2OIUcu6r
  • Il est tout à fait exact de dire que les modèles s’améliorent rapidement, et qu’il y a trois ans, leur état actuel aurait semblé relever de la science-fiction
    Beaucoup de choses vont continuer à beaucoup s’améliorer. Cela dit, quand on regarde l’histoire récente des bouleversements brutaux provoqués par la technologie, on voit un schéma récurrent. Comme une avalanche ou une crue soudaine, ces changements rapides commencent souvent par une ou plusieurs percées majeures dans une technologie donnée. Au début, le rythme du changement est rapide et chaotique, puis il ralentit progressivement à mesure que l’on récolte les fruits les plus accessibles et qu’on rencontre de nouvelles barrières et frictions dans des territoires inexplorés. Au début de ces périodes, extrapoler directement dans le futur le rythme exceptionnel des changements récents donne de faibles capacités de prédiction. Les explosions soudaines et extrêmes ont tendance à revenir vers une ligne de tendance de long terme. On peut considérer que le bouleversement actuel des LLM vient de l’accumulation de recherches depuis 2010, puis de leur cristallisation avec l’article sur les Transformers en 2017, qui a rapidement déclenché de nombreuses recherches connexes. Si c’est le cas, nous sommes peut-être déjà au milieu ou dans la seconde moitié de la phase d’explosion rapide des LLM. Le rythme des percées fondamentales et larges qui tirent vers le haut toutes les applications des LLM a clairement ralenti, et une grande partie des découvertes récentes à fort impact relèvent de l’extension vers des domaines spécifiques, de l’optimisation, du tuning et de la mise en produit. Cela ne veut pas dire qu’il n’y aura pas demain une nouvelle percée du niveau des Transformers, mais historiquement, les cygnes noirs se déplacent rarement en troupeau
  • Pourquoi penser que cela s’arrêterait aux licenciements de développeurs ? Si les entreprises logicielles deviennent dépendantes des fournisseurs de LLM pour faire tourner leur activité, je pense qu’on pourrait voir un effondrement massif de ces entreprises à l’échelle mondiale, des produits on-premise jusqu’au SaaS
    Les clients n’achèteront plus d’outils logiciels comme aujourd’hui ; ils pourront soit créer en interne tous les logiciels dont ils ont besoin, soit les faire produire par des consultants en prompt engineering. Ce pourrait être un monde très différent
  • Quelle est votre théorie sur le moment où l’IA atteindra les 100 % ? Est-ce que les PM et les business analysts vont créer tous les logiciels ?
    Ou bien il n’y aura plus qu’environ 700 entreprises unipersonnelles dans le monde et tous les autres ne pourront plus travailler ? La Matrice ?
  • Si vous pensez que les modèles deviennent vraiment aussi bons, c’est presque délirant
    Ma productivité n’a pas tant augmenté que ça depuis la sortie de Claude 3.5. J’ai un accès illimité à tous les LLM, mais la plupart sont nuls, et je passe plus de temps à corriger qu’à produire. Les seules personnes qui tirent vraiment profit de cet outil sont celles qui sortent rapidement des résultats de faible qualité. Si vous n’êtes pas d’accord, c’est que vous en faites partie

• Mon parcours de carrière est étonnamment similaire à celui de l’auteur. Curieusement, ce que l’auteur considère comme le premier pilier qui s’est effondré me paraît aujourd’hui être celui qui tient le mieux.
  Les LLM échouent de façon répétée sur les spécificités de notre activité : fiscalité locale, détails des procédures comptables, particularités de notre implémentation du grand livre. Ils sont excellents pour le refactoring, la conversion entre langages et le suivi des bugs dans du code existant, mais dès qu’il s’agit d’itérer et d’étendre notre domaine, il y a toujours beaucoup de points subtilement erronés. C’est peut-être parce que les entreprises où j’ai travaillé traitaient volontairement des domaines complexes afin de construire un moat. Des entreprises qui restent viables parce qu’il n’existe aucun livre permettant d’en faire une copie, et parce que le savoir-faire reste en interne. Et si, dans une FinTech, un manager recommande de produire rapidement des documents de conception avec de l’IA, cela me semble trop imprudent pour une activité qui manipule de l’argent. Surtout quand il y a un grand volume de petites transactions, où il est bien trop facile de mal répartir des montants à l’échelle de plusieurs millions. Ces bugs sont vraiment difficiles à traiter. Corriger la logique n’est que la première étape ; ensuite, il faut corriger des données mal calculées dans une base de données immuable, gérer les procédures réglementaires et la communication avec les clients. Les correctifs deviennent alors des pièges dont les nouvelles fonctionnalités et l’observabilité doivent tenir compte. Du genre : « souvenez-vous que l’anomalie dans les données du 2 février vient de l’incident X »

  • Quand on construit quelque chose qui n’a réellement jamais existé auparavant, on ne peut pas confier les décisions d’architecture à un LLM.
    Je développe plusieurs produits basés sur des simulations physiques, entièrement fondés sur des principes premiers. Or, si on lui confie cela sans recherche active, réflexion ni validation, il produit du code de calcul cent fois plus lent, avec des chemins alternatifs absurdes et des raccourcis qui finissent par rendre le calcul inutile. Cela arrive dans environ 95 % des cas. La supervision est cruciale, et la réflexion architecturale ne peut pas encore être externalisée. Seule l’exécution peut l’être.
  • Les spécificités de la fiscalité locale, des procédures comptables et de l’implémentation du grand livre relèvent de l’expertise métier, et ne nécessitent pas forcément un ingénieur logiciel.
    Bien sûr, il arrive souvent qu’un ingénieur logiciel senior en soit aussi spécialiste, mais ce n’est pas indispensable. Traditionnellement, il était utile pour une production sans friction qu’un ingénieur puisse traiter environ 90 % du travail sans avoir à consulter un expert métier ; mais c’est précisément cette « tradition » dont le texte original dit qu’elle est terminée. Dans le nouveau monde, le rôle d’un ingénieur senior n’est pas de posséder lui-même cette expertise métier, mais de faire en sorte que l’agent la possède ou puisse l’acquérir, et de garantir que ce qu’il produit est vérifiable et correct. Les ingénieurs seniors qui s’accrochent à l’idée qu’une expertise métier poussée les mettra à l’abri se retrouveront bientôt dans une impasse, tout autant que les juniors qui n’ont pas pris ce virage.
  • Je n’arrive même pas à faire produire à Claude ou GPT-5 des organigrammes de cas d’usage courants de manière cohérente, sans parler du contenu spécifique au domaine.
    Ils disposent d’un vocabulaire profond, ce qui leur donne l’air d’en savoir plus qu’en réalité. Ils sont très bons pour écrire du code et déboguer des erreurs visibles, mais cela tient pour moitié au fait que cela sert de dispositif de test.
  • Une technique qui peut aider consiste à aligner, avec le LLM, une compréhension commune des fonctionnalités produit et des règles qu’elles doivent refléter.
    L’idée centrale est de fournir la documentation au LLM, puis de le laisser poser beaucoup de questions afin de lever les ambiguïtés et les risques de malentendu. Je recommande de jeter un œil à Skills. C’est vraiment utile. https://www.youtube.com/watch?v=6BB6exR8Zd8
  • Notre entreprise aussi traite beaucoup de réglementations complexes et d’implémentations de systèmes très spécifiques au domaine, et auparavant l’IA y avait du mal.
    Nous avons pu résoudre ce problème avec des fichiers claude.md/agents.md bien structurés. Nous y avons aussi intégré supermemory.ai, afin que les décisions nouvellement prises soient toujours rappelées à l’agent IA à chaque démarrage d’une nouvelle session.

• Je repense toujours à la phrase tristement célèbre de Steve Jobs : « les idées ne valent pas grand-chose »
  Tout est dans l’exécution, et si les LLM de pointe résolvent l’exécution, alors les idées deviennent désormais la porte d’entrée vers l’abondance. Mais l’abondance en elle-même ne garantit pas une « force de rétention ». Ce qu’on oublie souvent, c’est la volonté humaine de rester sur quelque chose, et le fait de vraiment s’en soucier. Beaucoup de gens ne se soucient pas assez d’une chose, ou n’en ont pas assez envie, pour la créer, la maintenir et se l’approprier. On pourra peut-être lancer une V1 plus vite, mais pourra-t-on continuer à l’alimenter sur la durée ? On en voit un bon exemple avec l’outil de musique IA Suno. Il produit maintenant des résultats plutôt bons. Beaucoup de gens s’amusent un temps dans leur petit univers à eux, puis se lassent vite et s’en vont ; seuls quelques créateurs très prolifiques restent et transforment cela en un environnement qui « ressemble à un travail ». L’échelle et l’économie de la délégation et de l’exécution ont peut-être changé, mais il reste encore beaucoup d’éléments à prendre en compte

  • J’ai un peu utilisé Suno, et je ne suis pas d’accord avec l’idée qu’il « produit de très bons résultats »
    Même avec une culture musicale limitée, c’est mon impression ; les musiciens seront probablement encore plus critiques. Les premières fois, c’est impressionnant, et les mélodies sont accrocheuses. Avant, il y avait des choses qui sonnaient bizarrement en arrière-plan, mais la plupart ont été corrigées. Sauf qu’au bout de quelques dizaines de morceaux, tout commence toujours à sonner pareil. Tout est générique, les chansons ne racontent rien, et ça donne l’impression d’une musique faite pour passer dans une pub d’entreprise. Même en écrivant des prompts plus précis, ça n’a pas vraiment aidé, et la plupart des détails qui pourraient rendre un morceau intéressant sont ignorés. Les résultats les plus intéressants venaient plutôt du moment où je le faisais dérailler, presque comme par bug. Quand je lui demandais de mélanger deux genres très différents, il produisait un résultat troublant, avec une sensation que je n’avais pas le souvenir d’avoir déjà entendue. Mais dès qu’on veut aller plus loin, ça devient toujours difficile, ça essaie sans cesse de revenir à quelque chose de générique, et ça ignore les consignes détaillées. Suno sait faire du remix. C’est similaire au code. Les LLM sont déjà très bons pour le portage d’une chose qui fonctionne déjà, afin de la faire fonctionner dans un autre langage. Mais si on n’a qu’une idée, ils échouent sur la partie originale. Pour faire implémenter correctement une idée par un LLM, il faut lui donner tellement d’instructions qu’on finit par lutter contre l’ambiguïté du langage naturel, ce qui revient pratiquement à écrire le code soi-même
  • Les LLM de pointe ne « résolvent » pas l’exécution
    Avec assez d’insistance, et en mettant en place un système capable d’obtenir du code réellement fonctionnel, on peut résoudre l’exécution. Mais c’est précisément ça, l’ingénierie. Aujourd’hui, dans leur état par défaut, on est encore très loin d’un remplacement de l’ingénierie. Peut-être que ce sera possible dans 3 ans. Ça évolue vite. Mais aujourd’hui, on ne peut pas simplement dire « crée-moi un meilleur compilateur Rust », s’adosser à son siège et attendre le résultat
  • Suno est un bon exemple. J’ai écrit les paroles de nombreux morceaux et je les ai « produits » avec Suno, mais il faut des dizaines à des centaines de retouches ou de modifications via remix / cover / extension, ou beaucoup de temps dans l’éditeur, avant d’obtenir le son que je veux
    J’aime les morceaux, au point de pouvoir les écouter dans ma playlist, mais ils n’ont pas suscité de grande réaction dans l’algorithme de Suno. Je ne les ai pas non plus beaucoup promus ailleurs, et quand j’ai essayé de les publier, je n’ai récolté que quelques likes. Je ne suis pas déçu. J’ai fait cette musique pour moi-même, et le fait de la partager n’était qu’un effet secondaire. La conclusion que j’en ai tirée, c’est qu’il faut énormément de travail pour que les gens s’intéressent à ce que j’ai créé et l’apprécient. Il faut faire du marketing, l’amener devant les gens, leur faire y prêter attention. Je suis aussi convaincu qu’il faut le relier à une vidéo, une histoire, un persona, une certaine ambiance, quelque chose qui leur donne une raison d’aimer ça. Pour que ça « prenne », il faut répéter tout cela auprès du même public et leur laisser le temps de s’y habituer. Donc il faut de la constance, et il faut vraiment se soucier de ce qu’on essaie de vendre. Il faut d’abord que moi, je reste accroché, avant que les autres ne s’y attachent
  • https://x.com/chamath/status/2033385903520129161
    https://en.wikipedia.org/wiki/Sturgeon%27s_law
    La loi de Sturgeon dit que « 90 % de tout est de la camelote ». Cette maxime a été formulée par l’écrivain et critique américain de science-fiction Theodore Sturgeon pour défendre la valeur du genre. Sturgeon estimait que, dans n’importe quel domaine, la majorité des œuvres sont de faible qualité, et que la science-fiction n’est donc pas particulièrement inférieure aux autres
  • Tu peux en dire plus sur les outils de musique IA ?
    J’ai l’impression qu’ils sont utilisés comme des outils de génération en une seule fois. Je ne connais pas bien la musique, mais j’imagine qu’un artiste a besoin de nombreuses étapes intermédiaires, de séparation des pistes, de personnalisation des instruments, et d’autres éléments qui m’échappent. Sans cela, j’ai du mal à voir comment ça pourrait servir à un travail professionnel

• Je ne suis pas totalement d’accord avec ce texte. Un vibe coder ne peut pas concevoir, développer et implémenter un système de complexité intermédiaire sans tout faire exploser
  Une grande partie du fait de bien utiliser des applications comme Claude repose sur une compréhension conceptuelle et sur l’expérience des notions d’informatique. Ce sont précisément des choses qu’un vibe coder n’aura jamais. S’il les avait, ce ne serait pas un vibe coder

• « Je ne sais pas quoi faire » : il suffit de surfer sur la vague
  Je l’ai fait quand la vague, c’étaient les sites web et les webapps. Je suis entré dans l’industrie logicielle avant Internet, et j’ai continué à changer de monture. Il n’est jamais trop tard pour apprendre une nouvelle technologie. Une nouvelle vague crée de nouveaux types de travail et de travailleurs. Il suffit de devenir l’un d’eux. Montez la bête, maîtrisez l’outil. C’est simplement le même jeu qui revient

  • D’accord
    S’il existe une compétence dont la demande reste constante, c’est la capacité à structurer les choses dans sa tête, qu’il s’agisse d’un nouveau métier, d’un nouveau processus, de nouvelles personnes, ou de n’importe quoi d’autre. J’ai affûté et développé cette capacité en travaillant comme mécanicien prototypiste. Pour ceux qui ne connaissent pas, un mécanicien prototypiste est quelqu’un qui accomplit ce qu’il faut pour fabriquer des pièces complexes chaque semaine, dans des délais courts. Métal, plastique, peu importe. On devient très bon pour se familiariser rapidement avec les processus, les machines-outils et les matériaux. Après un certain temps, on absorbe de nouvelles informations très vite, et on peut comprendre le travail bien plus rapidement et précisément que beaucoup d’autres. Tout le monde peut commencer. Il suffit d’être curieux et de fabriquer quelque chose. Puis d’en fabriquer davantage. Partagez ce que vous créez, et fabriquez ce que les autres veulent
  • Globalement, on a l’impression que la société est plus agitée, mais au fond c’est encore la même chanson et la même danse qui se répètent
    Dans les années 90 et 2000, il y a eu la vague du « la programmation orientée objet va tout changer ». On faisait alors en orienté objet des choses qu’on faisait déjà avec succès depuis des centaines de fois. Vous écrivez du code lié aux avions ? À l’université, j’ai réellement entendu dire qu’il suffisait d’acheter un objet avion omnipotent qui s’occupe de tout ce qui concerne l’avion. Ah bon, l’orienté objet n’était pas une solution miracle ? Alors essayez la génération de code, ou Ruby on Rails. Vous créez un site web en deux secondes. Il y avait de la génération de code partout. Puis ça est parti dans des directions étranges, et TDD est arrivé. J’ai déjà vu de vraies discussions disant qu’un ingénieur qui ne fait pas de TDD mérite quasiment la prison. Non, en fait, pas TDD : BDD était la solution. Lean, non Agile, non agile en minuscules, mais au début c’était ça, non Scrum, non XML, attendez, ça c’était la décennie précédente, JSON, et finalement SAFe. Et maintenant, c’est « t’as vu ce chatbot ? ». À chaque cycle, si on y prête attention, il en sort de bonnes choses. Mais il apporte aussi beaucoup de battage et d’angoisse. Il suffit d’expérimenter et d’apprendre. Une chose qui n’a pas changé pour moi, c’est que presque tout le monde préférerait mourir plutôt que de réfléchir sérieusement aux conséquences de la réalisation de ses propres rêves. Tant que cela restera vrai, les gens continueront à payer quelqu’un pour chevaucher à leur place le dragon des modes surhypées
  • On dit « maîtrisez l’outil », mais la proposition de valeur de ces outils, justement, c’est qu’il n’y a aucune compétence à accumuler ni aucune maîtrise à acquérir
    Tout le flux d’usine à résultats médiocres — pardon, le flux « AI native » — ressemble à ça : « Waouh, j’ai amadoué le chatbot pour qu’il fabrique quelque chose que je ne comprends pas du tout. Qu’est-ce que je travaille bien ! » C’est comme une médaille de participation appliquée au fait de fabriquer des choses. Quelque chose d’autre produit le résultat, et moi je récupère le mérite sans vraiment comprendre. Mon effort ne produit aucun rendement composé. Aucune leçon apprise. Aucune compréhension accumulée. Aucun éclairage menant à l’innovation future. Aucune différenciation. Juste hurler dans le vide jusqu’à l’anesthésie mentale, jusqu’à ce que la machine à sous recrache un mélange médiocre qui « a l’air assez correct », puis recommencer le lendemain. Si c’est ça, le jeu, alors je passe mon tour. Tant mieux si d’autres y prennent plaisir, mais croire qu’il y a la moindre maîtrise là-dedans relève du délire. La seule condition pour « réussir » avec cet outil, c’est de cesser de s’en soucier et de capituler

• Je l’ai déjà posté avant, mais ça vaut la peine de le republier
  Je fais du DevOps dans une entreprise très agressive dans son usage des LLM. Les étapes ont été grosso modo les suivantes : demander « beaucoup de choses » au LLM, lui en demander encore plus, lancer plusieurs agents, revenir à un agent unique mais lui faire construire des outils, puis passer à des outils déterministes que les humains comme les LLM peuvent utiliser. La raison est simple. En déploiement comme en test, les outils déterministes donnent des réponses binaires et sont reproductibles. En cas d’incident, on peut toujours revenir à un outil qu’un humain peut exécuter. C’est plus rapide. Un script simple s’exécute en moins de 30 secondes, alors que les « conneries plausibles » semblaient toujours prendre 2 à 3 minutes. Au final, on revient à cet article : https://spawn-queue.acm.org/doi/10.1145/3194653.3197520. En gros : « faites une liste de tâches, écrivez le script de chaque tâche, combinez les scripts en fonctions, et les fonctions deviennent le système ». À cela j’ajouterais que, si on laisse faire le LLM, il est tout à fait disposé à produire du code. On peut ajouter des tests pour vérifier que les tests fonctionnent. On faisait déjà ça autrefois avec du code écrit par des humains. On peut aussi lire le code. Et quand on lit le code, on voit qu’il lui arrive de produire du code fonctionnel tout en faisant des choses complètement folles. Les humains font ça aussi, mais c’est un autre sujet. Au bout du compte, il faut toujours vérifier que le système produit a du sens. Pour le dire plus simplement, le code est peut-être mort, mais l’ingénierie logicielle est bien vivante et en pleine forme

  • C’est la bonne approche
    On peut demander absolument tout à un grand LLM. C’est possible, et ça se fait réellement. Mais ça coûte énormément d’argent et ça prend du temps. À la place, si on utilise l’IA pour créer des outils afin de traiter de manière déterministe autant d’étapes du processus que possible, puis qu’on fait utiliser ces outils par l’IA, cela tourne bien plus vite et pour bien moins cher. Bonus : à terme, on peut même abandonner l’IA cloud coûteuse et faire tourner le tout sur des modèles locaux petits ou moyens

• Si la projection de l’auteur sur l’avenir est juste, les bons ingénieurs logiciel sont en sécurité
  Les connaissances métier peuvent s’apprendre bien plus vite que la manière d’appliquer de bons principes d’ingénierie. Un ingénieur dont le principal avantage compétitif est la connaissance métier n’est probablement pas si excellent que ça en ingénierie elle-même. Cela dit, il peut toujours trouver du travail dans d’autres secteurs de l’industrie où les connaissances métier qu’il a accumulées sont nécessaires

  • Dans le fil complet d’il y a une semaine, on disait que l’expertise métier avait toujours été le vrai fossé défensif : https://news.ycombinator.com/item?id=48340411
  • Je ne sais pas si l’idée que les connaissances métier s’apprennent bien plus vite que de bons principes d’ingénierie est universellement vraie
    Beaucoup de bons ingénieurs logiciel, avec l’arrogance de croire que les connaissances métier se récupèrent facilement, ont ruiné un grand nombre de systèmes ERP. Une énorme partie de l’IT consiste littéralement à injecter des règles métier dans des systèmes
  • Je ne suis pas partiellement d’accord. Les grandes lignes des connaissances métier peuvent s’apprendre vite, mais les affiner en une compréhension nuancée qui tient compte de la complexité peut prendre des années, voire des décennies, surtout dans des organisations spécifiques qui ne sont pas souvent considérées comme des « entreprises de développement logiciel »
    Et pourtant, je continue de voir et de relire du code de développeurs logiciel « spécialisés » qui ne suivent pas de bonnes pratiques d’ingénierie logicielle. Dire qu’un ingénieur dont l’atout principal est la connaissance métier peut ne pas être très bon en ingénierie s’applique tout autant aux ingénieurs sans connaissance métier. En tout cas, c’est mon expérience. Peut-être avons-nous juste eu de la malchance
  • Développer et acquérir une connaissance métier de valeur est un processus difficile, risqué, coûteux et lent
    Parce qu’une connaissance métier de valeur n’est pas celle d’hier, mais celle d’aujourd’hui et de demain. Dans les domaines où la connaissance métier compte, elle est profondément imbriquée avec l’ingénierie. On ne demanderait pas à Jeff Dean de développer Unreal Engine from scratch. Cela dit, il existe aussi de nombreux principes d’ingénierie logicielle que les experts métier n’ont pas complètement internalisés ou n’appliquent pas suffisamment. Tant que la connaissance métier aura de la valeur, cet état de fait perdurera. Parce que l’ingénierie logicielle est elle aussi un autre domaine
  • Peut-on apprendre les connaissances métier plus vite ? Je pense que non
    La méthodologie peut être améliorée bien plus vite que l’acquisition d’une expertise. La première relève de l’approche, donc on peut l’imposer et l’élever rapidement. La seconde dépend de la disposition de la personne à apprendre, de ses capacités et du temps disponible à ce moment-là, et on ne peut pas la forcer au-delà d’un accompagnement raisonnable. Elle a aussi un effet cumulatif, donc la courbe d’apprentissage initiale est bien plus abrupte

• J’utilise Claude Code et Opus 4.7, et ce n’est pas tant que le code généré est faux, c’est plutôt qu’il a tendance à en écrire trop
  Réfléchir à une fonctionnalité précise et à la meilleure manière de l’intégrer au code reste précieux. Claude choisit souvent une couche de la stack, par exemple la couche de présentation, et y pousse la logique. Quelques semaines plus tard, si les mêmes données sont nécessaires ailleurs, Claude n’arrive pas à réutiliser le code de la couche service et fait une sorte de « greffe ». Si un humain n’y prête pas attention, le volume de code double et la logique se retrouve dupliquée. Je ne pense pas que des outils IA comme Claude vont beaucoup s’améliorer là-dessus à court terme. Là où je travaille, on nous pousse déjà à réduire l’usage d’Opus 4.7 pour économiser de l’argent. Quelqu’un a dit qu’on devrait utiliser un plus petit modèle pour les « corrections de bugs simples ». Parfois, peut-être, mais en pratique, à quelle fréquence peut-on vraiment savoir à l’avance qu’il s’agit d’une correction simple ? Si les coûts augmentent, j’ai l’impression que l’intérêt à utiliser cet outil pour écrire « tout le code » va diminuer. Si les gens migrent vers des modèles moins chers et moins efficaces, la pression pour ne pas relire ce code disparaîtra probablement aussi. On verra bien où cela mène, mais ce ne sera peut-être pas aussi radicalement différent que ce que craint l’auteur

  • Je suis d’accord avec la critique selon laquelle l’IA écrit trop de code
    Rien que le fait de demander à l’IA de réduire de moitié le nombre de lignes de code en production et de vérifier s’il existe d’autres bibliothèques réutilisables est étonnamment efficace. On pourrait probablement aussi créer un bot de refactoring qui repère les doublons et les extrait. Ce n’est pas fourni par défaut aujourd’hui, mais il n’est clairement pas certain que ce soit impossible
  • Moi aussi, j’ai constaté ce problème de code trop volumineux
    La vraie question ouverte est plutôt de savoir si trop de code est réellement un problème. Ces outils font désormais partie de la vie. S’ils permettent de résoudre des problèmes ou de déboguer plus vite, et que le logiciel a moins de bugs, alors ce n’est peut-être pas trop de code, mais simplement le bon nombre de lignes
  • Il y a quelque temps, j’ai eu dans une codebase deux fonctions, fooBar() et fooBarExtended()
    La seconde avait les paramètres et fonctionnalités supplémentaires nécessaires au problème actuel. Pourtant, au lieu d’appeler cette fonction, Claude continuait d’essayer d’ajouter les mêmes paramètres d’extension à la première. Même après que je lui ai dit de ne pas le faire, il a refait la même proposition plus tard, et parfois c’est vraiment agaçant

• Quelle que soit votre vision de l’avenir du secteur, je pense qu’il est difficile de trouver un plus grand succès professionnel dans l’ébénisterie artisanale que dans le logiciel artisanal

  • Le marché du meuble / des placards sur mesure est déjà assez difficile, et le travail du bois est un hobby bien trop courant chez les programmeurs ; si beaucoup d’entre nous s’y mettent, le marché sera vite en surcapacité massive
    On m’a déjà dit d’essayer de vendre les meubles que je fabrique, et ma réponse est toujours la même. J’ai déjà fait une fois l’erreur de transformer un hobby en métier, et je n’ai pas l’intention de la refaire. Au moins, le logiciel paie encore plutôt bien
  • Cela dépend de ce que tu entends par travail du bois
    Quelqu’un avec qui je travaille fabrique des terrasses, des jardins, des caravanes, des abris et des clôtures, et gagne vraiment très bien sa vie. Cela dit, pour être juste, cette personne est aussi incroyablement douée
  • J’ai une maison historique avec une porte de forme unique, sculptée à la main
    Le cadre de porte a pourri, et j’ai payé 4 000 dollars à un menuisier pour fabriquer une pièce de remplacement. Remplacer la porte elle-même coûterait facilement 25 000 dollars. Si vous déménagez dans un grand quartier historique rempli de portes sculptées à la main, vous pouvez gagner correctement votre vie
  • Une toute petite fraction du marché, probablement même pas 1 %, est encore prête à payer pour du fait main. Bonus si c’est complètement moderne tout en ayant une esthétique rétro. Par exemple, des claviers steampunk
    Mais la part du marché prête à payer pour du logiciel fait main est exactement de 0 %
  • Va voir layoffs.fyi. Tu as de fortes chances d’être licencié bientôt. Si ce n’est pas demain, alors donne juste encore quelques années au temps que l’IA s’améliore. C’est une voie à sens unique vers le bas
    Ce n’est pas l’ébénisterie, c’est l’agriculture. Il faut obtenir un terrain et cultiver soi-même de quoi manger. Ne plus participer du tout à l’économie est le seul moyen de survivre