Nettoyer après les développeurs rockstars de l’IA

• Le problème historique des codebases difficiles à comprendre laissées par les « développeurs rockstars » devient une charge de maintenance pour toute l’équipe avec la généralisation du code généré par les LLM
• Les développeurs rockstars adoptaient vite de nouvelles technologies, de nouveaux paradigmes et de nouvelles architectures, et terminaient rapidement les tâches difficiles, mais s’intéressaient peu à l’écriture de code que d’autres puissent comprendre et sur lequel ils puissent collaborer
• Les agents LLM peuvent produire des dizaines de milliers de lignes de code en peu de temps sans se souvenir du travail précédent, sans se soucier de la cohérence avec l’ensemble du système ni d’une meilleure compréhensibilité
• Plus le volume de code généré augmente, plus la complexité du système peut croître fortement, créant un cycle où l’on dépend à nouveau des LLM pour le comprendre
• Pour construire un logiciel durable, il faut limiter les LLM à la génération de petits fragments de code, laisser les humains piloter la conception et simplifier l’architecture en fonction de la complexité réelle du problème

---

La structure laissée par le développeur rockstar

• Après avoir rejoint l’équipe, le développeur rockstar avance des idées fortes sur de nouvelles technologies, de nouveaux paradigmes et de nouvelles architectures
• Il réécrit l’essentiel de l’architecture cœur de l’entreprise et introduit un nouveau processus de build, de nouveaux outils et de nouveaux langages
• Il rejette de nombreuses pull requests, relève le niveau d’exigence pour les autres membres de l’équipe, et personne n’ose montrer qu’il ne comprend pas son code
• Les tâches les plus difficiles lui sont confiées, et il les termine plus vite que les autres
• Les autres membres de l’équipe avancent plus lentement, occupés à apprendre de nouvelles bibliothèques et à s’adapter à sa manière de faire
• Quelques années plus tard, le développeur rockstar quitte l’équipe, attiré par des projets plus difficiles dans une entreprise plus grande

Gérer les conséquences

• Les membres restants récupèrent les projets du développeur rockstar et se retrouvent submergés par le code
• Les flux de données sont difficiles à suivre, au point de donner l’impression que quelqu’un essaie de dissimuler un meurtre
• Ils commencent par corriger de simples bugs, mais il leur faut déjà une semaine rien que pour lancer le code sur leur laptop
• La moitié du code est écrite dans un langage qu’ils ne comprennent pas, l’autre moitié avec des bibliothèques dont ils n’ont jamais entendu parler
• Ils expliquent à leur manager qu’il faudrait réécrire le code, mais l’argument ne passe pas parce qu’il a été écrit par le développeur rockstar
• En errant dans ce code chaotique, ils s’imaginent partir en regardant des offres d’emploi

Nettoyer après les rockstars

• De nombreuses équipes et agences doivent remettre en ordre des codebases laissées par ce type de développeur rockstar
• Comprendre et sauver une codebase complexe ressemble à démêler une guirlande lumineuse emmêlée pour pouvoir la réutiliser
• Les développeurs rockstars aiment coder, apprendre et adopter de nouveaux paradigmes, en poussant leurs capacités au maximum
• Ils cherchent à écrire le code le plus malin possible et se concentrent sur la vitesse maximale
• Écrire un code sur lequel d’autres peuvent collaborer devient la priorité la plus basse pour eux

L’arrivée de l’intelligence artificielle

• Ces dernières années, de nombreuses équipes se retrouvent débordées par une armée de développeurs rockstars
• Chaque fois que quelqu’un ouvre un nouveau chat, il y a un risque d’ajouter un développeur rockstar de plus à l’équipe
• Les agents ne se souviennent pas de ce qu’ils ont fait la veille et génèrent des dizaines de milliers de lignes de code en quelques minutes
• Ils poursuivent l’achèvement des tâches à une vitesse humainement impossible
• Ils ne se préoccupent ni de la cohérence du code généré avec le reste du système, ni du fait de rendre le système plus facile à comprendre
• L’IA dispose d’une boîte à outils de bonnes pratiques qui peuvent ne pas convenir au contexte
• Même lorsque la complexité dépasse les bénéfices, l’IA insiste sur des garde-fous excessifs façon « ceinture et bretelles »
• Si on lui demande une revue de code, elle produit une longue liste d’améliorations difficile à accepter dans son ensemble
• Beaucoup ont l’impression qu’ils prendront un retard irrattrapable s’ils n’utilisent pas les LLM
• Laisser les LLM écrire tout le code conduit selon l’auteur précisément à prendre du retard à terme

Nettoyer après des centaines de rockstars de l’IA

• Remettre de l’ordre dans des amas de code généré désordonnés n’a rien d’aussi plaisant que de nettoyer après un seul développeur rockstar
• Au moins, le développeur rockstar avait une intention de conception et cherchait à faire de son mieux
• Un amas de code désordonné produit par le vibe coding n’est pas l’œuvre d’un seul développeur artificiel
• La codebase résulte de multiples chats et de multiples contextes, générant une fonctionnalité ou un correctif de bug à la fois
• C’est comparable à une codebase écrite par des centaines de développeurs rockstars différents
• Dans certains cas, la dette technique devient si énorme qu’elle ne pourra jamais être remboursée

Construire un logiciel durable

• Il existe plusieurs façons d’utiliser les LLM sans les laisser agir comme des développeurs rockstars
• Les humains peuvent garder la main sur l’ingénierie et demander aux LLM de ne générer que de petits fragments de code à la fois
• Il faut s’assurer que le logiciel est écrit d’une manière que toute l’équipe peut facilement comprendre et faire évoluer
• Si le LLM s’est égaré sans comprendre ce qu’il fait ni pourquoi, il faut ralentir
• Il est acceptable d’avancer plus lentement pour garantir la qualité du logiciel produit
• Il est acceptable de continuer à simplifier pour éviter la sur-ingénierie jusqu’à ce que l’architecture corresponde à la complexité réelle du problème
• Parfois, il est acceptable de laisser le LLM dans la boîte à outils et d’écrire le code soi-même
• Le savoir-faire reste toujours entre les mains des humains, dans un domaine qu’on ne peut pas externaliser aux machines

[GN⁺]

Commentaires sur Hacker News

• La dernière phrase, selon laquelle le savoir-faire restera toujours entre les mains des humains et ne pourra jamais être sous-traité aux machines, m’inquiète un peu
  Dans d’autres secteurs aussi, le savoir-faire n’a pas disparu, mais il a été supplanté par des alternatives bien moins chères et plus faciles à obtenir. On peut toujours acheter des chaussures en cuir faites main, mais peu de gens veulent payer plus de 1 000 $, et on peut aussi acheter un tableau qui a demandé des semaines de travail, mais la plupart achètent plutôt des décorations murales et des bibelots chez HomeGoods
  La différence essentielle, c’est l’hypothèse du jetable, et malheureusement les logiciels deviennent eux aussi de plus en plus « jetables » comme les autres produits. Une simple appli de compte à rebours peut être jetée, mais un logiciel qui soutient des processus métier de longue durée ne devrait pas être traité ainsi
  Si on met l’accent sur l’artisanat logiciel, le problème peut sembler être « ce dont j’ai besoin pour mon usage » contre « quelque chose de boutique, cher et inutile ». En réalité, cela devrait être « quelque chose de maintenable et fiable » contre « quelque chose qu’on peut jeter »
  Indépendamment de savoir si cette tendance profite aux grands fournisseurs de modèles comme OpenAI ou Anthropic, ce n’est pas vraiment le point ici

  • Le savoir-faire dans les autres industries n’est pas en train de mourir de la manière dont on en parle pour le logiciel
    Mon bureau bon marché livré en carton plat, que j’ai monté moi-même avec un tournevis, a certes été produit en masse en usine, mais sa conception a peut-être demandé bien plus de savoir-faire expert qu’un meuble sur mesure. C’est une structure où l’on supporte un coût initial de conception élevé pour ensuite produire en masse avec un faible coût marginal
    Le logiciel a été en grande partie comme ça dès le départ. Quand je télécharge Firefox, il n’y a pas un artisan qui fabrique un navigateur web juste pour moi ; c’est un serveur CDN dans un datacenter quelque part qui copie des octets depuis son cache
    Ce que l’IA menace, c’est le remplacement d’un savoir-faire fondé sur l’investissement initial qui, dans les autres secteurs, n’a jamais été remplacé à grande échelle. Ce que l’IA a remplacé avec plus de succès, c’est un logiciel « artisanal » à bas coût, un domaine qui jusqu’ici n’existait pratiquement pas parce qu’il n’était pas économiquement viable
  • Les industries physiques et le logiciel sont très différents. Des chaussures en cuir sont fabriquées plusieurs fois, une paire par client, alors que le code est écrit une fois et tous les clients utilisent le même produit
    Cela donne un levier bien plus grand pour investir dans la qualité
    J’ai aussi du mal à accepter que le logiciel soit jetable dans le même sens. S’il s’agit d’un problème temporaire, on peut jeter le code et en écrire un nouveau quand un autre problème apparaît. Mais s’il s’agit d’un problème durable, le code, lui, reste
  • Il y a une perspective intéressante du côté de l’usinage
    Les vis étaient autrefois des objets rares fabriqués sur mesure, et produire une bonne vis demandait énormément de temps et d’efforts. Même ce que nous appelons aujourd’hui une vis mécanique ne pouvait être fabriqué qu’au prix d’un travail extrême par une personne très qualifiée
    Pourtant, les machines peuvent transférer le savoir-faire. Si l’on fabrique une très bonne vis, la machine peut transmettre la qualité de cette vis à d’innombrables nouvelles vis
    Aujourd’hui, les vis de toutes sortes et de toutes qualités sont devenues des consommables presque identiques, et ce qu’on aurait autrefois taillé à la main en plusieurs jours ou semaines se produit désormais par milliards
    Je vois l’IA comme un tour sans vis mère. Au début, il faut fabriquer les vis à la main, puis on peut transférer autant qu’on veut la qualité qu’on est capable de produire vers de nouvelles vis. Si j’arrive à fabriquer de meilleures vis, je peux les mettre sur le tour et produire encore plus de meilleures vis. Mais, fondamentalement, cela reste limité par la qualité des vis que je peux fabriquer moi-même. Si je ne suis capable de faire qu’un truc tordu, bosselé et raté, c’est aussi ce que la machine produira
  • C’est une vision complètement erronée. Dans le logiciel, ce qui correspond au « savoir-faire », ce n’est pas la fabrication des chaussures, mais plutôt la conception des chaussures
    Les développeurs logiciels créent une propriété intellectuelle unique, ils ne fabriquent pas des unités de logiciel. Ils ressemblent davantage à des auteurs ou à des musiciens
    Dans le logiciel, il n’existe rien qui corresponde à une fabrication unitaire. On ne fait que copier et déplacer des bits
    Donc, dans le contexte logiciel, le « savoir-faire » désigne le soin apporté à la conception de quelque chose de bon. Il ne disparaîtra pas à moins d’atteindre un point où la qualité même du logiciel que nous utilisons n’aurait plus d’importance, et rien n’indique aujourd’hui qu’on aille dans cette direction
  • L’analogie avec les chaussures faites main ne semble pas juste, sauf si l’on parle d’un logiciel utilisé par une seule personne
    Une comparaison plus appropriée serait peut-être celle des ingénieurs qui fabriquent et maintiennent les équipements de production d’une usine de chaussures. C’est à un degré de séparation du consommateur, mais il y a clairement aussi du savoir-faire là-dedans

• J’aime bien réparer du code produit par l’IA ou par externalisation. La semaine dernière, j’ai découvert qu’un client avait essayé de créer un outil pour son service en vibe coding, et le résultat était une énorme merde Next.js qui demandait 10 Go de mémoire pour compiler, avec des milliers d’erreurs de lint, et même des logs de développement bruyants commités dans Git
  Maintenant, c’est à nous de réparer ça, donc ce genre de chose revient à du travail gratuit répétitif à 10 000–50 000 euros. C’est très facile si on sait ce qu’on fait, et impossible sinon. Qu’on continue à m’en apporter

  • D’une certaine manière, le client a fourni les spécifications et les maquettes UI à implémenter
  • Je suis d’accord avec ça à 1000 %
    Je travaille dans la réponse à incident pour les PME, et ces dernières années la charge de travail a augmenté au point d’en devenir difficile à gérer, et mon compte bancaire ressemble à un tas d’or de dragon
    Je pense depuis toujours que la sécurité doit être intégrée et planifiée, et je ne veux absolument pas voir se produire des incidents de compromission
    Mais le fait que des gens avec une expertise floue puissent maintenant sortir des applis en une heure a été une aubaine énorme pour des gens comme moi
  • Les agences qui se concentreront sur ce type de travail gagneront beaucoup d’argent. J’ai déjà récupéré plusieurs dossiers comme ça, et tant que les gens penseront pouvoir faire leur produit en vibe coding, il y en aura d’autres. Comme tu l’as dit, c’est de l’argent facile
  • Beaucoup de gens misent énormément d’argent sur l’IA. Certaines de ces mises sont prometteuses, mais toutes ne réussiront pas
    Cet état d’esprit revient à voir les gens comme des machines à sous humaines dans lesquelles on injecte de l’argent
  • Je me demande si tu pourrais en dire plus sur la façon dont cela se passe réellement, sans révéler ton identité ni celle de tes clients
    Je me demande si, quand les clients viennent vous voir, ils cherchaient dès le départ de l’aide pour mettre ça en production, ou si vous êtes plutôt le dernier recours après l’échec complet de l’approche IA
    Je me demande aussi s’il existe des façons typiques dont ces projets s’effondrent, ou si les échecs sont en général plus subtils

• J’ai rencontré dans ma vie quelques personnes qu’on peut vraiment qualifier d’exceptionnelles. Le genre de personnes qui font se dire : « Mais comment peut-on être aussi intelligent ? »
  Il y a deux traits qu’on observe chez les gens vraiment intelligents, et ils sont généralement mutuellement exclusifs. Le premier, c’est ceux qui ne savent pas à quel point ils sont intelligents. Pour eux, c’est simple, ou bien c’est leur sujet, donc ils supposent que toute personne ayant un diplôme d’informatique le sait, s’en souvient et le comprend aussi. En écoutant des amis réciter sans effort des maths liées à la cryptographie, je me suis déjà dit : « J’ai validé ce cours, mais je ne peux pas vraiment dire que je maîtrise le sujet dont tu viens de parler. »
  L’autre catégorie, ce sont ceux qui sont douloureusement conscients en permanence d’être plus intelligents que la plupart des gens autour d’eux. Certains deviennent mesquins, d’autres sont simplement épuisés d’être entourés de gens relativement « stupides ». J’ai un peu d’empathie pour ces derniers. Il suffit d’imaginer une vie où tout paraît clair, évident et facile à traiter, tout en voyant l’humanité répéter sans cesse des choix absurdes alors que les réponses sont connues depuis longtemps

  • Il y a aussi un troisième problème. C’est qu’une nette majorité des gens croient appartenir à cette dernière catégorie
  • Je ne prétends pas avoir lu énormément de livres ni avoir un QI élevé, mais je ressens quelque chose de similaire sur de petites choses qui me semblent relever du bon sens
    Voir les gens tergiverser, ou faire X alors qu’il est évident que cela produira le mauvais résultat -Y, ça me rend dingue. La plupart du temps, j’ai simplement appris à ne pas le dire à voix haute
    C’est particulièrement malsain dans les relations familiales proches. J’en vois tellement que j’ai parfois l’impression de pouvoir tuer à force de rabâcher
  • J’ai connu et rencontré des gens comme ça
    Mais aucun d’entre eux n’était un développeur 10x qui a empilé un chaos monumental que l’équipe et moi avons dû nettoyer pendant des mois
  • Vivre en étant à l’extrémité de la courbe sur une caractéristique fondamentale est une expérience solitaire
    Même en faisant des efforts, il est difficile de créer des liens avec la plupart des gens, et eux ont tout autant de mal à me comprendre. L’écart d’expérience vécue est immense et souvent difficile à franchir
  • Beaucoup de développeurs choisissent simplement d’exécuter les tâches du quotidien ou de suivre le cargo cult
    Tous les développeurs ne peuvent pas produire le même volume, mais n’importe qui peut devenir intelligent à sa façon s’il décide de continuer à réfléchir au-delà de la moyenne culturelle
    La plupart ne réalisent même pas qu’ils pourraient le faire

• Ces deux phrases m’ont parlé
  « Suivre le flux de données était si difficile qu’on aurait dit que quelqu’un essayait de dissimuler un meurtre »
  « Il m’a fallu une semaine rien que pour faire tourner le code sur mon laptop »
  J’ai toujours pensé que j’étais le seul à avoir du mal à comprendre le flux de données ou à mettre en place un environnement de développement correct. Le syndrome de l’imposteur n’aidait pas, pas plus que certains environnements toxiques où l’on pousse parfois la « vitesse » à tout prix
  Ça m’a fait du bien de voir que je n’étais pas le seul

  • Le passage « Il m’a fallu une semaine rien que pour faire tourner le code sur mon laptop » m’a surpris
    Claude Code en CLI a rendu bien plus facile qu’avant le fait de lancer une application et de déboguer des dépendances arbitraires ou des problèmes liés à Docker. Avant, il fallait apprendre l’architecture tout en résolvant en plus ce qui ne fonctionnait pas sur ma machine
  • Tu n’es pas le seul. J’ai ressenti exactement la même chose, et ce genre de connaissance se trouve généralement dans la tête des gens ou dans un thread Slack perdu au hasard
    Avec le code généré par l’IA, c’est encore pire. Parce qu’il s’agissait juste de produire quelque chose qui semblait plausible sur le moment

• J’envie un peu les gens qui doivent nettoyer ce que d’autres ont laissé. Au moins, ça donne l’impression de résoudre un puzzle
  Mon travail actuel est vraiment ennuyeux. C’est assez simple pour qu’un junior puisse le faire, mais on dit malgré tout qu’il faut un développeur mid-level. Je ne dis pas que je vaux mieux que ce travail, ni qu’un mid-level ne devrait pas faire ce genre de tâches. Simplement, je n’arrive pas à me forcer à m’intéresser au code que cette entreprise produit. C’est vieux, poussiéreux, et même les personnes importantes ne l’utilisent pas. Les clients ont acheté cet outil à une époque, et comme c’est un outil sans intérêt, ils ne s’y intéressent pas assez pour le remplacer, donc ils continuent juste à l’utiliser
  On m’a promis qu’un travail plus en phase avec mon expérience arriverait bientôt, mais je ne vois pas comment ce genre de client pourrait arriver dans une entreprise aussi stagnante
  Ce n’est pas étonnant que cette entreprise perde ses clients et ses employés. Mais j’ai un crédit immobilier à rembourser. Aujourd’hui, on m’a dit que mon contrat pourrait ne pas être renouvelé, et c’était en gros une menace pour que j’assume davantage de responsabilités et fasse plus de travail pour le même salaire
  Malheureusement, je dois tenir jusqu’à ce que je trouve un nouveau poste vraiment intéressant. Je n’ai pas besoin de beaucoup d’argent, et les histoires de « croissance » ne m’intéressent absolument pas. J’ai juste besoin de quoi survivre
  Ce commentaire est peut-être très hors sujet, désolé. Je n’ai pas d’autre exutoire où poster ça

  • Tu n’es pas seul. J’ai vécu exactement la même situation chez Microsoft, et j’ai fini par démissionner
    J’étais L63, mais le travail que je faisais aurait pu être fait par un L60 ou un L61, et j’avais souvent l’impression d’occuper l’un des Bullshit Jobs dont parle David Graeber. La rémunération était confortable, mais une fois mes actions de bonus d’embauche épuisées, j’ai vu que je ne restais dans ce poste que pour la stabilité
    J’avais l’impression d’être l’un de ces ingénieurs qui bronzent sur la terrasse des bureaux de Hooli en attendant la prochaine vesting de leurs actions. J’avais 9 ans de carrière et ça ne me semblait pas être ce qu’il y avait de mieux pour moi à ce stade
    Cela dit, j’avais beaucoup moins d’obligations financières, donc la décision a été bien plus facile
  • Au début, j’ai cru que « medior » était une faute de frappe bizarre pour « senior », puis comme le mot revenait deux fois, je suis allé vérifier. Apparemment, dans certaines régions d’Europe, c’est utilisé pour dire intermédiaire
  • Je me reconnais énormément dans « je n’arrive pas à me forcer à m’intéresser au code que cette entreprise produit »
    Des produits de merde faits par des boîtes de merde, qui prospèrent sur la paresse et l’absence de goût de la plupart des gens, et que les marketeux monétisent
    Et maintenant c’est encore pire, parce que tout le secteur est en train de se LLM-iser, ce qui amplifie ça d’un facteur 100. Ça rend le code impossible à maintenir et, pire encore, ça nous rend tous plus stupides
    Je pense sincèrement que j’aurais préféré qu’on ne découvre jamais ça
  • Si tu regardes bien la codebase sur laquelle tu travailles en ce moment, il y a probablement déjà plein d’occasions de nettoyer des choses, qu’elles aient été laissées par d’autres ou par toi-même
  • Le passage sur la « menace pour que j’assume davantage de responsabilités et fasse plus de travail pour le même salaire » m’intrigue un peu
    Je me demande si ça veut simplement dire faire plus d’heures et plus de tâches inutiles, s’il y a en réalité davantage d’occasions de coder, ou si on attend soudain de toi que tu prouves que tu as plus de valeur
    Je ne cherche pas à minimiser ce que tu as vécu. Si c’est la dernière option, je me demande s’il y a concrètement quelque chose à en tirer

• Les premières sections m’ont parlé. J’ai l’impression d’avoir été un développeur rockstar autrefois, et j’ai fini par comprendre que ce n’était pas une bonne chose
  J’étais peut-être capable de finir le travail 10 fois plus vite que mes collègues. Mais à un moment, j’ai compris que ce n’était pas parce que j’étais 10 fois plus productif que la moyenne, mais parce que ma manière de travailler rendait les gens ordinaires autour de moi 10 fois moins productifs
  Depuis, j’ai ralenti, et ça a été un changement positif pour l’ensemble de ma vie. Être un joueur d’équipe n’offre pas le même niveau de mobilité ascendante dans cette industrie folle, mais c’était étonnamment bénéfique pour ma santé mentale

  • Moi aussi, j’ai clairement déjà fini par me tirer une balle dans le pied en implémentant les choses à la façon rockstar
    Dans mon cas, c’était le plus souvent de la sur-abstraction sur des choses inutiles, ou la création de quelque chose pour des cas d’usage qui ne se produisaient jamais réellement. Donc, chaque fois que je sens ma pensée dériver vers trop d’abstraction, j’essaie de me rappeler YAGNI et KISS

• Cet article a trop peu de valeur
  Je ne vois même pas bien ce qu’il essaie de dire, on dirait juste un texte d’auto-congratulation

  • Il existe clairement du mauvais code. Mais cet article semble mélanger le « mauvais code » et le « code complexe, volumineux et qui demande du temps pour s’y habituer »
    Une grande partie de ce qu’on appelle l’énorme quantité de mauvais code laissée par des « développeurs rockstar » est en réalité le résultat d’une complexité qui s’est accumulée lentement et progressivement à mesure que les exigences changeaient
    Et souvent, les gens pensent qu’ils « refactorisent pour la lisibilité », alors qu’en réalité ils sont surtout « en train de réécrire le code et de le comprendre au passage »
  • En résumé, c’est « quand vous utilisez des LLM, ralentissez et réfléchissez à ce que vous faites ». Vous m’avez fait gagner 5 minutes
    J’attendais plus de contenu ou de vrais exemples. 90 % du texte sert à l’auteur à se plaindre et à définir le problème, puis l’avant-dernier paragraphe balance une solution vague et bricolée à la main. Il n’y a quasiment aucune pertinence ni utilité réelle

• C’était vraiment stupide de ma part d’avoir mis une énorme pression sur deux ingénieurs de production pour construire l’infrastructure autour de deux projets rentables que j’avais créés
  J’aurais gagné bien plus d’argent si j’avais tout fait en code spaghetti comme un patron du 10x, puis rejoint Anthropic pour décrocher un package de rémunération à neuf chiffres. Quel idiot j’ai été, profondément idiot
  Au moins, c’est la conclusion que j’en tire ici

• Le code écrit doit généralement être maintenu par quelqu’un d’autre que son auteur. Donc, si vous écrivez du code que personne ne comprend, cela finit par mener à un échec de maintenance
  On peut choisir d’optimiser différentes choses : du code facile à comprendre pour l’équipe, la vitesse, l’excellence technique, etc.
  Mais même si vous optimisez l’excellence technique, si personne d’autre dans l’équipe ne peut comprendre ce code, c’est quand même un échec
  J’ai déjà vu du code surconçu

[GN⁺]

Avis sur Lobste.rs

• Cet article contient très peu de conseils réellement utiles

  • On a l’impression que c’est une plainte personnelle emballée dans deux buzzwords pour lui donner de l’allure
    L’expression « développeur rockstar » a toujours été suspecte, mais il existe bel et bien d’excellents développeurs. Simplement, ces gens ne se comportent pas comme dans l’article : ils travaillent autant que possible dans l’environnement existant, améliorent la base de code, n’introduisent pas des nouveautés non éprouvées comme des jouets, et laissent derrière eux un système plus stable grâce aux tests, aux déploiements scriptés, au linting, etc.
    Ici, on dirait que l’IA a été ajoutée pour dire que ce comportement va empirer. C’est possible, mais ça ne me semble pas encore suffisamment démontré. Après des décennies comme consultant à remettre de l’ordre dans des codebases en mauvais état, j’ai souvent vu des causes liées à des gens allés trop loin, mais encore plus souvent des équipes qui ne connaissaient simplement pas de meilleure méthode. Dans aucun des cas je ne me suis dit : « ça, c’est sûrement l’œuvre d’un développeur rockstar/ninja/à buzzword »

• Donc maintenant, il ne faut plus seulement nettoyer les déchets déversés par les chatbots au-dessus de nos têtes, mais aussi passer derrière ceux qui s’en moquent
  Ça donne juste envie d’attendre que la bulle éclate

  • C’était déjà comme ça avant, et l’IA ne fait qu’amplifier le problème. À l’inverse, on peut aussi voir les choses en disant que le travail de nettoyage est devenu plus facile

• Si je rejoins une entreprise en 2026 et que je découvre qu’elle utilise encore create-react-app, je me demande quel comportement est réellement recommandé. Il faut juste ne rien dire ?

  • Si c’est un nouveau projet, il suffit de dire que c’est désormais deprecated et que ce n’est plus recommandé
    Si c’est un ancien projet, alors vous avez identifié de la dette technique. Tout le monde en a. Le meilleur moyen de convaincre qu’il faut corriger ce genre de chose, c’est de construire un argumentaire compréhensible du point de vue business. Si ça fonctionne, est-ce vraiment un risque ? Quelle est sa priorité par rapport aux autres dettes techniques ? Quels risques implicites assume-t-on si on ne met pas à niveau ? Quel effort la mise à niveau demande-t-elle ?
    Si l’effort est faible et que vos collègues le souhaitent aussi, il est parfois possible de simplement le faire sans demander d’autorisation. Mais ça marche surtout quand les personnes concernées soutiennent le changement et que cela ne gêne pas vos propres livrables. Ce n’est peut-être pas quelque chose à faire pendant votre première semaine
    En général, il vaut toujours mieux demander et comprendre pourquoi les choses sont ainsi plutôt que d’expliquer comment elles « devraient » être. Toute base de code avec un historique est le résultat de milliers de décisions que vous ne connaissez pas encore. Il faut s’armer de connaissances et d’empathie
  • Quand j’arrive, je préfère d’abord observer avant de pointer tout ce qu’il faudrait changer. Il y a un équilibre entre tout bouleverser à l’arrivée d’une nouvelle personne dans l’équipe et se concentrer sur ce qui a un réel impact. Juste après avoir rejoint l’équipe, on ne sait pas encore ce qui produit cet impact
  • Ça dépend des combats que vous choisissez. Personnellement, je ne pense pas que ça en vaille la peine, mais je ne suis pas vous. Le code legacy est partout, et le coût d’une réécriture pour quitter un framework comme create-react-app est bien plus élevé que le coût de continuer avec quelque chose que les gens maîtrisent déjà
  • Je ne suis pas développeur web, donc qu’est-ce que cette question veut dire exactement ? Que create-react-app est dépassé, ou que React est dépassé ?
  • Je voulais juste dire à quel point ça me valide de voir que les gens détestent désormais CRA
    Je détestais déjà ça en 2020, quand ça avait encore l’air cool

• Le fait que « les agents ne se souviennent de rien de ce qu’ils ont fait hier » est un problème solvable. On peut utiliser des approches de mémoire, etc. Ce n’est pas universellement bon, mais ça s’améliore
  Dire que « ce code ne se soucie pas de bien s’intégrer au reste du système » ne correspond pas à mon expérience. En général, le code généré par LLM a tendance à ressembler assez fortement au code similaire dans la zone concernée. Le code lu pour s’orienter s’y reflète presque tel quel
  Dire que « ça ne se soucie pas de savoir si le système devient plus facile à comprendre ou pire » est aussi quelque chose qu’on peut traiter. On peut demander à un LLM de l’évaluer et faire baisser progressivement ce score. Ce qui rend quelque chose plus facile à comprendre est souvent une propriété non déterministe du système ; paradoxalement, un LLM peut donc être plus facile à utiliser pour le mesurer que d’autres outils. Dans une nouvelle session, on peut demander : « pour comprendre ce code nouvellement ajouté, quelle portion du système faut-il comprendre ? » puis optimiser pour réduire cette portée
  La partie « l’IA a une boîte à outils de bonnes pratiques qui ne convient peut-être pas ici » ressemble souvent au fait de former un développeur junior qui arrive sur un nouveau projet avec les mêmes idéaux. À un junior, on l’explique verbalement et on espère qu’il retiendra et appliquera ce savoir ; avec l’IA, il suffit de le documenter dans des fichiers AGENTS.md / CLAUDE.md, et cette connaissance reste là
  Dire que « quand on demande une code review, il en ressort une foule d’améliorations avec lesquelles on n’est pas d’accord » : avec Codex, c’est réglé pour garder la liste courte, concise et à forte valeur. D’autres modèles peuvent se comporter différemment, mais là encore, c’est en fin de compte une question d’instructions. Ce à quoi vous tenez mérite souvent d’être documenté, et l’usage de l’IA rend cela nécessaire

• Avec les rockstars, la moitié du problème est l’ego, mais au moins une rockstar qui laissait du code écrit par un humain y mettait une réflexion et une intention pour l’étayer
  À l’inverse, les « rockstars » qui ne sont qu’une enveloppe humaine posée sur de l’IA ont le même niveau de frime, voire pire, tout en ne comprenant parfois même pas complètement la moitié des problèmes qu’elles prétendent résoudre

• En appliquant autant que possible une approche de programmation fonctionnelle, afin de créer des composants indépendants du contexte que l’on peut assembler de différentes façons, on obtient un levier considérable
  Si l’on sépare les briques élémentaires individuelles qui abstraient les détails d’implémentation des tâches dépendantes d’un contexte précis, on peut facilement réorganiser ces briques quand les exigences changent ou quand on choisit une autre approche. On peut aussi raisonner indépendamment sur chaque morceau sans connaître tout le contexte d’ensemble, et comprendre la logique de plus haut niveau en observant comment ces morceaux s’emboîtent
  Les langages fonctionnels offrent une bonne base pour travailler avec des LLM, car ils poussent naturellement à écrire le code d’une manière qui limite le contexte. Cela réduit l’étendue nécessaire pour comprendre une fonctionnalité donnée du programme, ce qui aide à la fois le modèle et les utilisateurs humains