L’Occident a oublié comment fabriquer des choses, et il est maintenant en train d’oublier le code

• L’effondrement des capacités de production de défense montre que lorsque des travailleurs qualifiés partent à la retraite et que le savoir-faire de fabrication disparaît, il devient impossible de relancer rapidement la production, même quand la demande explose en temps de guerre
• Les cas du Stinger, des obus de 155 mm et de la reconstitution de Fogbank montrent que l’optimisation des coûts et les points uniques de défaillance ont amélioré l’efficacité en temps de paix, mais ont fortement affaibli les marges de la chaîne d’approvisionnement et la vitesse de rétablissement
• Le logiciel suit lui aussi une trajectoire où l’on s’appuie sur des substituts moins chers, ce qui affaiblit le pipeline de talents, et après l’adoption de l’IA, la baisse du recrutement junior s’accompagne d’un renforcement du review bottleneck
• Les compétences ne se créent pas rapidement à coups d’argent, et dans la défense comme dans le logiciel, l’accumulation de savoirs et de savoir-faire exige des années d’expérience de terrain et de capacité de relecture
• Si les juniors ne passent pas par les erreurs de jeunesse et le débogage, les connaissances tacites ne s’accumulent pas, ce qui accroît le risque d’un manque futur d’ingénieurs senior et de institutional knowledge

---

Le parallèle entre l’effondrement des capacités de production de défense et la réduction des effectifs logiciels

• Pour relancer la production du Stinger, Raytheon a dû faire revenir des ingénieurs septuagénaires et reconstituer le processus à partir d’anciens plans papier et d’équipements de test retrouvés dans des entrepôts
• Après que le Pentagone n’a plus acheté de nouveaux Stinger pendant 20 ans, la guerre en Ukraine a fait exploser la demande, mais les lignes de production étaient fermées, les composants électroniques et les seekers n’étaient plus fabriqués, et les commandes passées en mai 2022 ne doivent être livrées qu’en 2026
• En seulement 10 mois de guerre, la demande a suffi à épuiser 13 années de production de Stinger, faisant de la disparition du savoir-faire industriel et du vide dans les effectifs les principaux goulets d’étranglement
• Le problème n’était pas simplement budgétaire : l’obstacle central venait de la structure même du système, où les travailleurs qualifiés partis à la retraite n’avaient pas été remplacés

Les hausses ratées de production de munitions ont révélé la fragilité de la chaîne d’approvisionnement

• La promesse d’un million d’obus et la capacité réelle de production

  • En mars 2023, l’UE a promis de livrer à l’Ukraine un million d’obus en 12 mois, mais la capacité annuelle de production de l’Europe était d’environ 230 000 unités, tandis que l’Ukraine en consommait 5 000 à 7 000 par jour
  • À l’échéance, l’Europe n’en avait livré qu’environ la moitié, et une enquête menée par 11 médias dans 9 pays a estimé que la capacité réelle de production se situait à environ un tiers des chiffres officiels avancés par l’UE
  • L’objectif du million d’obus a été repoussé à décembre 2024, soit 9 mois plus tard que la promesse initiale

• Une structure où plusieurs goulets d’étranglement se superposent

  • La France a cessé sa production nationale de propergols en 2007, puis l’a laissée interrompue pendant 17 ans
  • Le principal site européen de production de TNT se trouvait uniquement en Pologne, et les stocks de munitions de l’Allemagne ne représentaient que deux jours de réserve
  • L’usine Nammo au Danemark, fermée en 2020, a dû être relancée pratiquement depuis zéro
  • L’industrie de défense européenne était optimisée pour de petits volumes de produits sur mesure à forte valeur, et n’avait pas été conçue pour la production de masse ni pour la réponse à une crise

• Les États-Unis présentent des faiblesses similaires

  • Les États-Unis dépendaient eux aussi d’une seule usine à Scranton, d’une seule installation de chargement d’explosifs dans l’Iowa, et n’avaient plus de production nationale de TNT depuis 1986
  • Même après y avoir injecté des milliards de dollars, la production reste à moins de la moitié de l’objectif

Les points uniques de défaillance créés par l’optimisation des coûts

• En 1993, le Pentagone a adressé aux dirigeants de l’industrie de défense le message suivant : se consolider ou disparaître, après quoi le nombre de grands groupes du secteur est passé de 51 à 5
• Le nombre de fournisseurs de missiles tactiques est tombé de 13 à 3, celui des chantiers navals de 8 à 2, et les effectifs ont reculé de 3,2 millions à 1,1 million de personnes, soit une baisse de 65 %
• Des single points of failure sont apparus partout dans la chaîne d’approvisionnement des munitions, et la fabrication des corps d’obus de 155 mm s’est concentrée chez un seul fournisseur à Coachella, en Californie
• Les charges propulsives dépendaient elles aussi d’une installation unique au Canada, et cette optimisation centrée sur le coût minimum a certes amélioré l’efficacité en temps de paix, mais n’a laissé presque aucune marge en cas de brusque hausse de la demande

Quand la connaissance disparaît, la restauration ralentit aussi

• L’échec de la reconstitution de Fogbank

  • Fogbank est un matériau classifié utilisé dans les ogives nucléaires ; il a été produit de 1975 à 1989 avant la fermeture de l’installation
  • Lorsqu’on a voulu le reproduire en 2000 dans le cadre d’un programme d’extension de durée de vie, la plupart des personnes maîtrisant sa production étaient déjà parties à la retraite, décédées ou avaient quitté l’institution, et il ne restait presque aucune documentation
  • Selon les éléments liés au GAO, il a fallu 69 millions de dollars supplémentaires et plusieurs années de rétro-ingénierie pour obtenir à nouveau un Fogbank réellement produisible

• Les connaissances tacites absentes des documents étaient décisives

  • Le nouveau Fogbank fabriqué était trop pur, et l’on a fini par découvrir qu’une impureté involontaire présente dans le lot d’origine jouait en réalité un rôle essentiel dans son fonctionnement
  • Cette information n’apparaissait dans aucun document ; seuls les opérateurs de la production d’origine la connaissaient, et ils étaient déjà partis à la retraite
  • Si même un matériau conçu en interne n’a pas pu être reproduit, c’est parce que la connaissance ne subsistait plus que chez les personnes

Le logiciel suit lui aussi le même chemin

• Les substituts moins chers et plus rapides affaiblissent le pipeline de talents

  • Le schéma consistant à remplacer des capacités construites pendant des décennies par des substituts moins chers, à affaiblir ensuite le pipeline de talents humains, puis à redécouvrir en temps de crise qu’il faut rétablir les capacités supprimées se retrouve à la fois dans la défense et dans le logiciel
  • Si, dans la défense, ce substitut a été le peace dividend, dans le logiciel, l’IA occupe aujourd’hui cette place
  • L’effondrement du pipeline de talents et la crise de la compréhension étaient déjà visibles, et les exemples de la défense montrent aussi à quel point leur reconstruction est longue

• La reconstruction demande plus de temps que d’argent

  • L’augmentation de production dans la défense a pris 3 à 5 ans pour les systèmes simples, et 5 à 10 ans pour les systèmes complexes
  • Pour le Stinger, il faut au minimum 30 mois entre la commande et la livraison ; pour le Javelin, 4 ans et demi pour augmenter la production de moins du double ; et pour l’obus de 155 mm, malgré 5 milliards de dollars investis, l’objectif n’est toujours pas atteint après 4 ans
  • La France aussi a mis 17 ans à relancer la production de propergols, et la contrainte relevait davantage du savoir et du savoir-faire que du financement
  • Une étude de la RAND estime que 10 % des compétences nécessaires à la conception de sous-marins exigent encore 10 ans d’expérience terrain après le doctorat, tandis que les métiers qualifiés de la défense demandent 2 à 4 ans d’apprentissage et 5 à 8 ans pour les capacités de supervision

• La courbe de progression en logiciel ne se compresse pas non plus

  • Il faut 3 à 5 ans à un développeur junior pour devenir un mid-level fiable, 5 à 8 ans pour atteindre le niveau senior, et plus de 10 ans pour devenir principal ou architecte
  • Ce temps ne diminue pas simplement parce qu’on dépense davantage, et il semble difficilement compressible même avec l’IA

Les goulets d’étranglement et l’affaiblissement des compétences après l’adoption de l’IA

• Le goulet d’étranglement du review grandit plus vite que la vitesse de production

  • Dans un essai randomisé contrôlé de METR, des développeurs expérimentés utilisant des outils de codage IA ont en réalité mis 19 % de temps en plus sur des tâches open source
  • Avant l’expérience, ils s’attendaient à ce que l’IA les rende 24 % plus rapides, mais l’écart avec le résultat réel a atteint 43 points de pourcentage
  • Dans une expérience de suivi, une part non négligeable des développeurs a déclaré qu’elle ne participerait pas si elle devait travailler sans IA, et il semble déjà difficile d’imaginer un retour à un travail sans IA

• Réduction des recrutements et baisse des inscriptions universitaires

  • Salesforce a déclaré qu’elle ne procéderait pas à de nouveaux recrutements d’ingénieurs logiciels en 2025
  • Selon une enquête LeadDev, 54 % des responsables engineering estiment que les AI copilots réduiront à long terme les recrutements de juniors
  • Selon une enquête de la CRA, 62 % des départements universitaires d’informatique signalent une baisse des inscriptions cette année

• Le code review devient la contrainte clé

  • L’IA génère du code rapidement, mais les reviews humaines avancent lentement, ce qui crée un review bottleneck
  • En réponse, au lieu de laisser l’IA relire le code généré par l’IA, on impose désormais dans les modèles de pull request la description des changements, leur raison, leur type et des captures d’écran avant/après
  • On ajoute aussi des reviewers dédiés par projet afin de multiplier les regards humains sur ce que le modèle a pu manquer

Les capacités qui risquent de manquer demain

• Un environnement où la seule expertise technique ne suffit plus

  • Désormais, la seule expertise technique ne suffit plus : il faut aussi de la capacité de jugement et du leadership pour assumer la responsabilité, expliquer les arbitrages et repousser les mauvaises suggestions que la machine formule avec assurance
  • Dans un recrutement récent, sur 2 253 candidats, 2 069 ont été écartés et seulement 4 embauchés, soit un taux de conversion de 0,18 %
  • Cela révèle à quel point il existe peu de profils combinant compétences techniques et discernement pour identifier les erreurs de l’IA

• La documentation seule ne suffit pas à transmettre le savoir

  • La documentation s’étend désormais des Site Books aux SDDs, aux rapports RVS, jusqu’aux modules boilerplate avec une couverture complète
  • Aujourd’hui, cela fonctionne parce que les lecteurs de cette documentation possèdent encore une expertise engineering, mais rien ne garantit que ce sera toujours vrai si cette expertise disparaît
  • Il est impossible de prévoir le niveau des modèles en 2031, et il n’est pas certain non plus que l’IA devienne suffisamment bonne pour créer moins de problèmes

• Les crises arrivent sans prévenir, et on ne fabrique pas instantanément des seniors

  • De la même façon que personne n’avait anticipé une guerre totale en Europe en 2022, les crises ne suivent pas un calendrier
  • Dans 5 à 10 ans, il faudra des ingénieurs senior capables de comprendre l’ensemble du système, de déboguer une panne distribuée à 2 heures du matin, et de porter aussi la institutional knowledge située hors de la codebase
  • Or ces profils ne sont pas en train d’être formés aujourd’hui, et les juniors qui devraient apprendre ne sont pas recrutés, ou accumulent une AI-mediated competence nourrie par des recherches financées par le DoD
  • On peut conserver l’aptitude à écrire des prompts pour l’IA, sans pour autant développer la capacité à repérer les moments où elle se trompe

Le risque de voir apparaître un Fogbank du code

• Si les juniors contournent le débogage et les erreurs formatrices du début de carrière, les connaissances tacites ne s’accumulent pas, et quand la génération actuelle d’ingénieurs partira à la retraite, ce savoir ne sera pas transféré à l’IA
• Le résultat pourrait être une disparition pure et simple de la connaissance, selon une dynamique comparable à celle observée avec Fogbank
• La guerre en Ukraine a été le moment où l’échec des optimisations de l’industrie de défense s’est transformé en coût réel, et Stinger, Javelin, Fogbank ainsi que le million d’obus jamais produits en montrent le prix
• L’ingénierie logicielle fait aujourd’hui le même pari d’optimisation ; si l’IA devient suffisamment bonne, ce pari sera peut-être gagnant, mais sinon, la même facture pourrait revenir

[GN⁺]

Avis Hacker News

• Le vrai problème n’est pas l’IA en elle-même
  Le problème, c’est une manière de gérer qui supprime toute marge de manœuvre aux personnes et aux organisations parce qu’elle ne produit pas de profit immédiat, tout en croyant que ce savoir sera encore là quand on en aura besoin plus tard
  La réduction des coûts à court terme diminue les recrutements de juniors et enlève aussi aux ingénieurs expérimentés le temps nécessaire pour transmettre leur savoir, ce qui coupe la transmission des connaissances tacites
  Au final, il ne reste que la documentation et l’automatisation, mais la documentation ne remplace pas l’expérience du terrain et l’automatisation ne remplace pas le jugement
  Quand les gens qui ont réellement manipulé le système disparaissent, les connaissances tacites disparaissent de l’organisation, et la productivité finit elle aussi par baisser
  Aujourd’hui, l’IA se vend selon le même schéma, et dans beaucoup de domaines, ce qui est recherché ressemble davantage à une réduction des effectifs qu’à un gain de productivité
  On retrouve un état d’esprit similaire à celui de GE, qui a vidé ses capacités de long terme à force d’obsession pour les résultats trimestriels et le rendement des actionnaires
  Les décideurs éloignés de l’ingénierie réelle croient qu’ils peuvent remplacer les connaissances tacites par des outils, des processus et de la documentation, mais ce n’est pas le cas
  Si on supprime les personnes et le pipeline d’apprentissage, ce savoir ne reste pas dans l’organisation, il disparaît

  • Une fois que les bean-counters ont pris le contrôle de l’écosystème, ils n’ont optimisé que la rentabilité immédiate, au point de considérer que chaque partie du système devait tourner à 100 % en permanence
    Il n’y a plus aucune marge pour expérimenter, réparer ou absorber les chocs, et j’ai l’impression que 90 % des systèmes cassés aujourd’hui le sont parce qu’ils n’ont aucun slack pour encaisser un choc de court terme
  • Beaucoup de gens passent à côté d’un point important
    Dans une startup, il faut construire en permanence dès le départ, donc ajouter des fonctionnalités crée directement de la valeur, mais des entreprises comme Visa, Salesforce ou LinkedIn ont souvent déjà suffisamment de produit, de fonctionnalités et de ressources
    Ces entreprises se retrouvent souvent à chercher de force un clou qui corresponde au marteau write more software
    Même si elles semblent avoir beaucoup de wishlists et de systèmes d’A/B testing, s’il existait vraiment des opportunités évidentes de gagner plus d’argent en produisant davantage de logiciel, elles les auraient probablement déjà exploitées
    La vraie croissance et la nouvelle demande viennent plus souvent de l’extérieur de ces structures, et des entreprises qui ne savent pas produire ou acheter du logiciel peuvent au contraire saisir l’opportunité
    Et le point clé, c’est la fungibility
    Le capital humain n’est pas une marchandise qu’on reconditionne facilement, c’est quelque chose de vivant, et le pipeline des talents et des compétences peut simplement disparaître s’il est rompu
    Le danger de l’IA pour le code tient aussi au fait qu’elle exploite le capital humain existant sans en recréer pour l’avenir
  • Je ne suis pas totalement convaincu sur ce point
    Une grande partie de la connaissance des systèmes dont je m’occupe peut être documentée, et en théorie une nouvelle personne pourrait reprendre le sujet à partir de cette documentation seule
    Le problème, c’est la quantité de documentation nécessaire, absolument délirante
    Même pour un petit système, parler de dizaines de milliers de pages A4 me semble réaliste
    Le nouveau responsable devrait pratiquement tout mémoriser pour la comprendre, et l’entreprise ne veut pas payer ni le coût de rédaction d’une telle documentation ni le coût d’apprentissage de nouvelles recrues
    D’après mon expérience, si ça ne marche pas, ce n’est pas parce que c’est impossible en principe, mais parce que c’est impraticable en réalité
  • J’ai l’impression qu’il s’agit d’un changement plus fondamental et plus large
    Nous supprimons petit à petit les raisons que nous avons de parler aux autres
    Chaque fois qu’on pose une question à une IA, c’est une interaction humaine qu’on n’a plus avec un collègue
    Ce n’est pas seulement un problème lié au code, et le fait d’avoir en permanence ChatGPT dans sa poche me fait réfléchir aux interactions sociales que cela remplace
    Les humains sont fondamentalement des êtres sociaux, et nous sommes en train d’optimiser encore et encore la disparition de la socialisation
    Moi aussi, je préfère désormais Doordash à appeler un restaurant comme avant, donc je ne suis pas en dehors de cette tendance
  • J’y vois un signe que les systèmes gouvernementaux occidentaux sont cassés
    Dans un monde idéal, les entreprises optimiseraient le profit à court et moyen terme, les gouvernements l’intérêt à long terme, et les individus l’ensemble de leur vie
    Si les entreprises réduisent leur slack et tournent à flux tendu, l’État devrait préserver par la régulation cette marge et l’arrivée de talents afin de protéger les capacités nationales
    Or en Occident, on a l’impression que les groupes de lobbying et les MBA tiennent les entreprises, et entraînent même les gouvernements vers une logique qui optimise seulement l’argent

• Si je code tous les jours sans assistant de code, c’est parce que je pense qu’il faut faire ainsi pour ne pas perdre le sens du geste, y compris dans les petites choses
  La principale raison pour laquelle je n’utilise pas l’IA, c’est que quand je suis devant l’écran, je préfère autant que possible ne dépendre de rien
  Bien sûr, cela n’inclut pas la documentation, les livres ou Stack Overflow
  Je vois souvent autour de moi des gens s’en remettre à l’IA pour toutes les petites tâches du quotidien, et ça me fait peur, parce que cela signifie une réduction extrême de l’effort de réflexion
  Céder cet effort mental n’a rien d’anodin
  Pour moi, à partir du moment où je l’abandonne, je deviens une sorte de zombie dépendant, et je pense que la connaissance naît presque chaque jour de l’essai-erreur répété
  La technologie a toujours montré qu’elle pouvait pousser les gens et les orienter, et la dépendance à l’IA ressemble à la forme ultime de cette logique, où l’entreprise s’attaque jusqu’à notre capacité la plus fine : penser et être curieux

  • Après avoir beaucoup fait de programmation assistée par IA pendant environ un mois, j’ai essayé de recoder à l’ancienne pendant quelques jours
    J’ai passé la majeure partie de ce temps dans la confusion et la frustration, et après presque 7 heures à lutter avec le problème, j’ai fini le travail
    Mais la difficulté elle-même m’a tellement frappé que je me suis demandé si mon cerveau n’avait pas un peu pourri à force de ne plus m’en servir
    Puis je me suis souvenu qu’à l’origine, résoudre un nouveau problème était toujours aussi difficile
    Affronter un problème inédit, c’est naturellement de cet ordre-là, et c’est seulement moi qui n’étais plus habitué à cette sensation
    Quand on s’habitue à la difficulté, elle finit par sembler normale ; à l’inverse, quand on s’habitue à un état sans difficulté, le retour à cette difficulté paraît soudain écrasant et étrange
    C’est pourquoi je pense que la capacité à supporter l’inconfort et la difficulté est un muscle qu’il faut absolument préserver
  • Même avant l’IA, j’oubliais souvent la syntaxe à cause de l’autocomplétion de l’IDE
    Le seul moment où cela a vraiment posé problème, c’est quand j’ai changé d’emploi et que j’ai dû écrire du code d’entretien sur une plateforme sans vérification syntaxique ni autocomplétion, donc je me suis entraîné à l’avance dans cet environnement
    En pratique, la dépendance à l’autocomplétion syntaxique n’a jamais été un gros problème, et l’essentiel, c’était la compréhension des concepts fondamentaux du langage et du runtime
    Par exemple, il était plus important de comprendre le fonctionnement de l’event loop de Node.js et la manière d’écrire des programmes asynchrones et orientés événements
  • Je suis complètement à l’opposé
    Sur les six derniers mois, je dirais que je n’ai pratiquement pas lu moi-même une seule ligne du code que j’ai mis en production
    Et pourtant, travailler ainsi est bien plus fatigant
    Quand je codais à la main, résoudre le problème ressemblait à un puzzle, et une fois terminé, il y avait une boucle de satisfaction et une récompense dopaminergique
    Aujourd’hui, j’ai surtout l’impression de passer mes journées à faire le QA plutôt qu’à résoudre des puzzles, et c’est extrêmement épuisant
    Même si l’IA résout les problèmes difficiles à ma place, la satisfaction fournie par la machine à sous LLM est bien plus faible que celle que j’éprouvais en les résolvant moi-même
  • Aujourd’hui, j’ai moins de temps et moins de patience qu’avant, donc j’utilise l’IA 3 jours par semaine
    Les deux autres jours, je n’utilise pas d’assistant de code, et je lui demande seulement une revue une fois le travail terminé
    Je trouve que cette méthode est bonne pour préserver ma santé mentale et garder mon niveau technique affûté
  • J’ai toujours eu tendance à perdre plus vite que les autres ma capacité à écrire rapidement et avec aisance dans un langage dès que je m’en éloignais un peu
    Même dans un langage que je maîtrisais bien, la partie mécanique se brouillait vite
    Donc le travail assisté par LLM me donnerait probablement l’impression de verser de l’eau de Javel dans mon cerveau
    Je sens moi-même que plus j’en utiliserais, pire ce serait pour moi
    Ma capacité à structurer ce dont j’ai besoin et à résoudre des problèmes reste bonne, mais les nuts and bolts concrets s’évaporent rapidement

• La phrase l’argent n’était pas la contrainte, la connaissance l’était sonne ironiquement
  Parce que le texte lui-même est tellement écrit comme par une IA qu’il est difficile à lire
  Le flux est artificiel, haché, et rempli de tics typiques des LLM
  L’écriture aussi est une compétence qui finit par s’atrophier
  Je peux comprendre qu’on utilise l’IA pour la fluidité de la langue, mais je trouve la traduction par IA préférable à un texte généré
  Si l’auteur n’a même pas assez d’intérêt pour l’écrire lui-même, je ne vois pas très bien pourquoi je devrais prendre le temps de le lire

  • Je trouve curieux que tout le monde soit assez indulgent avec la génération de code end-to-end ou les dark factories, mais que dès qu’un texte est écrit par un LLM, la réaction devienne soudain très hostile
    Pour moi, code et prose ne sont pas si différents au fond
    Dans les deux cas, il s’agit de mots-clés, de grammaire, de syntaxe et de combinaisons porteuses de sens
    Si les phrases produites par l’IA sont creuses ou difficiles à lire, alors selon la même logique, le code produit par IA devrait lui aussi être difficile à lire et peu fiable
    J’aimerais qu’on arrête un peu ce double standard
  • Je n’ai pas du tout eu l’impression de lire un texte écrit par l’IA
    Au contraire, je l’ai trouvé bien meilleur que la soupe textuelle IA que HN laisse parfois passer comme si de rien n’était
  • Les LLM apprennent à partir de la grammaire et du style réellement écrits par des humains
    Donc certaines caractéristiques que les gens perçoivent comme typiques des LLM sont peut-être en réalité des styles d’écriture déjà humains qui reviennent ensuite sous forme répétée à travers des mains humaines
  • On parle de texte manifestement généré par IA, mais j’aimerais bien savoir comment on fait cette distinction
  • Je ne sais pas si c’est vraiment aussi évident
    Je vois chaque jour plusieurs textes générés par IA en haut des résultats de recherche et je les passe immédiatement, mais celui-ci m’a paru assez différent de cette catégorie

• J’ai du mal à croire que les entreprises sachent réellement évaluer le niveau d’expérience des développeurs
  Les catégories junior, mid, senior, lead ne sont qu’une façade ; en réalité, c’est un continuum sur plusieurs axes, facilement déformé par les technologies à la mode
  À strictement parler, je pense qu’on peut devenir développeur de niveau senior sans être employé par une entreprise
  Au fond, l’essentiel, c’est la volonté d’apprendre et de construire par soi-même, ainsi que le temps qu’on y investit
  Aujourd’hui, ce que les entreprises semblent vraiment chercher, ce n’est pas tant la compétence technique que l’expérience consistant à contourner tant bien que mal une structure organisationnelle cassée, ainsi qu’une communication et un budget mal ficelés
  Je ne sais pas si cela définit un senior, ou si cela signifie simplement être habile politiquement
  Ce schéma devient particulièrement visible lorsque le logiciel échoue et que l’illusion se dissipe

  • Je pense qu’il existe globalement deux types de développeurs
    Il y a ceux qui, face à un problème, apprennent d’eux-mêmes ce qu’il faut, creusent ce qu’ils ne savent pas, produisent de manière répétée des résultats utiles, communiquent avec les bonnes personnes, partagent leur avancement, aident et se font aider dans l’équipe, et comblent eux-mêmes les manques avant qu’on le leur demande
    Et puis il y a tous les autres
    En général, on voit assez vite de quel côté quelqu’un se situe dans les premières années de carrière, et il est presque impossible de faire passer quelqu’un de la seconde catégorie à la première
    Ainsi, on peut avoir un senior avec 30 ans d’expérience qui appartient à la seconde catégorie, ou un tout jeune diplômé qui appartient à la première
    Bien sûr, certaines personnes sont excellentes en politique interne, en relationnel ou en bluff, au point de paraître de la première catégorie aux yeux du management alors qu’elles sont en réalité dans la seconde
    Mais là, on ne parle plus vraiment de la capacité à produire du logiciel
    Et même quelqu’un de la première catégorie peut être sous-estimé ou ne jamais être promu, car la corrélation avec la réussite de carrière réelle n’est pas si forte
  • En dehors des organisations suffisamment grandes, le mot seniority a du mal à avoir un sens concret pour un développeur
    On peut toujours s’attribuer l’étiquette qu’on veut, mais cela reste un peu étrange
    Un freelance est jugé sur son portfolio, un chercheur en informatique sur ses publications, un contributeur OSS sur le volume et l’impact de ses contributions
    Dans tous les cas, cela reste proportionnel à l’effort consacré à apprendre et à construire
    En revanche, indépendamment du statut d’emploi, l’expertise ne se résume pas à ce qu’on peut apprendre dans les livres
    La gestion des parties prenantes ou la présentation de solutions s’apprennent difficilement par la lecture seule ; il faut de la pratique et du feedback
    Un ingénieur senior n’est pas seulement quelqu’un qui écrit bien du code, mais quelqu’un qui peut contribuer de manière autonome sur tout le SDLC et aider aussi les autres, et ces compétences se développent probablement bien plus facilement dans un environnement professionnel que sur des projets amateurs
  • Au bout du compte, dès lors qu’on travaille au sein d’une société, la capacité à avoir de l’influence est liée à la seniorité
    Cela demande généralement des compétences sociales et organisationnelles, et même si cela déplaît, c’est ainsi que le monde fonctionne
  • C’est déprimant, mais ça me semble assez juste
    En même temps, j’aimerais autant que possible ne pas avoir à connaître ce genre de choses
    Je n’ai pas envie de me tordre l’esprit pour me conformer à ce qu’attendent les autres, et travailler dans ce type de problèmes est une souffrance pure
  • Je pense qu’il est en pratique très rare de devenir senior developer sans avoir été employé par une entreprise
    C’est un peu comme demander si un chirurgien non employé peut devenir senior surgeon
    Il est difficile de devenir senior sans plusieurs années d’expérience réelle en tant que métier, et dans ce domaine, l’expérience est presque tout
    On ne peut pas assimiler la compréhension nécessaire à partir des seuls livres, et les humains n’intériorisent pas suffisamment en lisant ou en regardant simplement
    Il faut faire soi-même pour qu’il y ait un véritable apprentissage
    On peut apprendre des faits et des techniques dans les livres, mais lire un ouvrage sur la cuisine gastronomique ne fait pas automatiquement de vous un Michelin Chef

• Les générateurs de code IA ressemblent à des trolls
  Ils produisent avec assurance des choses plausibles mais partiellement fausses, et au final c’est à l’humain de repérer les erreurs
  Ce n’est ni amusant ni propice au flow

  • Mon expérience a été exactement inverse
    J’aime corriger les erreurs faites par les autres, et en particulier cette impression de battre le LLM
    Plus que l’état de flow traditionnel, je pouvais au contraire rester concentré plus longtemps en surveillant obstinément le LLM
  • Je pense que cela devrait ressembler à la dynamique d’une review de PR faite par un humain
  • Tout ce qui est produit par l’IA me donne l’impression d’un troll
    Il n’y a aucune logique derrière, seulement de la répétition de motifs, et je ne comprends pas pourquoi des ingénieurs pourtant intelligents se laissent avoir

• Il y a quelque chose d’ironique dans le fait que ce texte lui-même semble assez clairement avoir reçu une aide de l’IA
  Je ne critique pas l’assistance IA en tant que telle, mais juxtaposée au sujet du texte, cela donne matière à réflexion

  • Les clichés que l’IA glisse dans les textes sautent facilement aux yeux, sont assez irritants et très artificiels
    Les gens semblent les utiliser pour « polir » leur texte, alors qu’en pratique il est souvent plus agréable à lire sans cela
    Ce qui m’agace particulièrement en ce moment, ce sont ces phrases qui abusent du point à la place de la virgule
    My people lived the other side of this equation. Not the factory floor. The receiving end.
    On sent la volonté de donner du poids, mais c’est utilisé même là où cela n’a pas lieu d’être, ce qui donne l’impression de lire une bande-annonce de film d’action
  • Moi aussi, j’ai arrêté après quelques paragraphes
    Ce n’est pas que j’y voie un problème éthique en soi, mais le style LLM était tellement irritant
    En plus, les gens l’utilisent pour ajouter toujours plus de longueur et de filler inutiles aux textes, si bien qu’il faut désormais traverser plusieurs pages de ce genre avant d’arriver à quelque chose
    Et le pire, c’est qu’il n’existe pas de moyen simple de distinguer un texte reposant au moins sur une intuition humaine nouvelle d’un texte entièrement généré par un prompt du genre write me something about X
    À l’heure actuelle, si c’est la seconde option, il n’est pas exagéré de dire que cela n’a presque aucune valeur de lecture
  • Moi non plus, je n’ai rien contre l’assistance IA en soi, mais dans ce cas précis elle affaiblit la thèse centrale du texte
    Cela me fait un peu l’effet d’un prêtre qui condamnait l’homosexualité et qu’on surprend ensuite au lit avec un prostitué masculin
    Qu’il ait pris de la cocaïne ou non est secondaire, mais il en reste quand même un goût amer
  • Je me demande sur quoi vous vous basez pour l’affirmer
    Ce texte ne présente pas vraiment beaucoup des traces d’IA les plus évidentes, et ce qui me paraît le plus proche d’un style LLM, c’est surtout la structure en phrases courtes et affirmatives
    Or c’est aussi une manière d’écrire qui jouit d’un certain prestige en anglais depuis Hemingway

• J’ai l’impression qu’avant l’IA, c’étaient plutôt les équipes distantes de développeurs sous contrat en Europe de l’Est qui étaient vues comme l’alternative moins chère

  • Je ne sais pas pourquoi c’était censé être le plan
    De toute façon, il n’y a déjà pas assez de monde
    Et ici aussi, à l’est du 15e méridien, tout le monde a fini par se faire licencier
    En réalité, le plan ressemblait plutôt à faire globalement moins, tant que cela n’avait rien à voir avec l’IA, et chacun semblait attendre de voir qui commencerait les licenciements en premier
    J’ai travaillé à temps partiel pendant six mois, et les décideurs disaient clairement qu’à long terme c’était préférable
    C’était mieux qu’un licenciement, mais ce n’était pas un mode de vie tenable sur la durée
    Je suis plutôt économe, mais pas à ce point
  • C’était une logique du type : on va volontiers aider, puis finir par remplacer
  • La main-d’œuvre étrangère bon marché reste aujourd’hui extrêmement courante dans toutes les grandes entreprises technologiques
    Elles détestent vraiment dépenser de l’argent, et encore plus quand il s’agit de payer des Américains et leur assurance santé
    Je trouve étrange qu’il y ait si peu de freins alors que les entreprises américaines sont clairement sur une trajectoire rapide consistant à exclure les Américains de l’emploi
  • La plupart du temps, c’était India
  • En réalité, c’étaient surtout les Indiens en H1B et l’outsourcing en Inde
    En tant qu’Européen, j’ai bien sûr vu des développeurs d’Europe de l’Est, mais il n’y en avait pas dans toutes les entreprises où j’ai travaillé
    En revanche, il y avait toujours des équipes indiennes
    Sur la qualité, c’était toujours le même type d’histoire ; je ne vais pas entrer dans les détails, mais ceux qui sont prêts à l’entendre voient probablement déjà ce que je veux dire

• Quand je repense au cours de Formal verification in software que j’ai entendu pour la première fois à la fin des années 80, puis au cours de Programming in Java que je confiais aux nouveaux entrants avant mon départ au début des années 2000, j’ai l’impression d’avoir vu la rigueur académique s’effondrer comme d’une falaise, remplacée par un simple alignement sur l’emploi
  Avant, on enseignait surtout à penser ; plus tard, on enseignait surtout à obtenir un emploi bien payé

  • Exactement
    Parce que les entreprises ne veulent plus former elles-mêmes les nouveaux employés
    Le salaire des trainees coûte de l’argent, tout comme le temps de ceux qui les forment, donc elles ont transféré ce coût vers les universités, les étudiants et l’État sous forme de conditions de diplôme
    Il est étrange qu’on trouve suspect de demander à un salarié de payer directement sa propre formation comme condition d’embauche, tout en acceptant si facilement le système des degree mills

• Les humains ne sont pas parfaits
  Quand je suis allé en Ukraine quelques jours avant l’invasion russe, les voyages et les hôtels à Kyiv étaient très bon marché, et quand je demandais aux habitants si une invasion était possible, tous me répondaient que cela n’arriverait pas
  Leur réaction était que la Russie parle toujours de façon agressive, mais ne passe pas réellement à l’acte
  Les préparatifs n’étaient pas suffisants, et en quelques jours ils ont perdu 20 % de leur territoire
  Une fois rentré en Autriche, je n’ai pas cessé de penser que certaines des personnes que j’y avais rencontrées étaient peut-être mortes
  Plus tard, en tant qu’entrepreneur et ingénieur à Dubai et en Saudi Arabia, j’ai demandé ce qu’ils feraient si des drones attaquaient les infrastructures ; après la guerre en Ukraine et la première attaque de l’Iran, cela semblait pourtant tout à fait prévisible
  Et j’ai de nouveau entendu que cela n’arriverait pas
  Ils ne se sont pas correctement préparés, ont perdu des dizaines de milliards de dollars, alors que quelques centaines de millions par an pendant plusieurs années auraient peut-être suffi à l’éviter
  Au final, le problème n’est pas l’IA, mais les humains

  • L’Ukraine se prépare en réalité depuis 2014
    Sans cette préparation, je pense qu’il y aurait aujourd’hui un porte-parole russe assis à Kyiv
  • Moi aussi, je pense que l’Ukraine était au contraire assez bien préparée
    C’est parce qu’elle a tenu les deux premières semaines que la guerre a pu basculer dans la durée, et la guerre du Donbass durait déjà depuis 8 ans
    Il est difficile de croire que les Ukrainiens vivaient dans l’illusion que leur adversaire n’était pas la Russie
  • À l’inverse, le monde regorge aussi de dirigeants qui veulent dépenser des milliards pour une guerre imaginaire contre un pays inventé de toutes pièces
    Souvent, on découvre qu’ils ont un ami qui doit obtenir le contrat, et ils vendent la peur que, si l’ennemi attaque, leurs familles mourront immédiatement
  • Il est facile de faire le malin après coup
    Vous avez simplement choisi deux exemples où quelqu’un disait cela n’arrivera jamais, et où cela est effectivement arrivé
    Que fait-on des innombrables cas où quelqu’un a dit la même chose et où rien ne s’est passé ?
    Si je dis à des millions de gens qui achètent un ticket de loterie qu’ils ne gagneront pas, je fais une prédiction correcte pour presque tous
    Le fait qu’une seule personne gagne ne rend pas ma prédiction fausse, cela peut simplement relever d’un reporting bias
  • En réalité, ils s’étaient préparés
    Personne n’était certain que Poutine irait jusqu’à être aussi stupide, mais l’armée ukrainienne était très occupée à préparer des lignes de défense, des stocks et des tactiques défensives au cas où

• J’ai de plus en plus l’impression que programming as theory building de Peter Naur devient crucial
  Lien : https://gwern.net/doc/cs/algorithm/1985-naur.pdf

  • C’est aussi le premier texte qui m’est venu à l’esprit
    Lecture vivement recommandée