- L’affirmation selon laquelle l’IA multiplierait par 10 à 100 la productivité des ingénieurs n’est pas réaliste
- En utilisant réellement et en profondeur des outils de code basés sur l’IA, on constate que le gain d’efficacité reste limité, et que les explosions temporaires de productivité ne se produisent que sur des tâches répétitives et simples
- Les goulots d’étranglement du développement logiciel (revue de code, collaboration, planification, etc.) ne peuvent pas être levés par l’IA, et une amélioration de 10x sur l’ensemble du travail est impossible
- Le mythe de l’ingénieur 10x naît de motivations diverses : distorsion des chiffres, intérêts des acteurs du secteur, ou encore création d’anxiété au sein des organisations
- Préserver sa propre manière de développer et le plaisir de coder produit de meilleurs résultats à long terme et une culture d’entreprise plus saine
Scepticisme face au mythe de l’ingénieur IA 10x
L’anxiété liée à la productivité et l’expérience concrète des outils d’IA
- Sur LinkedIn, Twitter et ailleurs, le discours selon lequel l’IA multiplierait par 10 à 100 la productivité des ingénieurs se répand, et beaucoup de développeurs ressentent l’angoisse de se faire distancer
- L’auteur a lui aussi testé en conditions réelles divers agents de génération de code par IA (Claude Code, Cursor, Roo Code, Zed, etc.), mais s’ils se sont révélés pratiques sur des tâches simples et répétitives, ils n’ont apporté aucune transformation fondamentale sur des tâches réelles complexes
- En JavaScript (en particulier React), il est possible d’écrire rapidement du code répétitif (boilerplate)
- Mais face aux standards internes d’une base de code ou à des bibliothèques atypiques, l’IA ne suit pas correctement
- Pour des langages comme Terraform, l’IA est moins à l’aise et ses performances baissent
- Le phénomène de hallucination peut même conduire à inventer des bibliothèques inexistantes et introduire des vulnérabilités de sécurité
- La capacité de l’IA à comprendre le contexte reste encore limitée. Plus la base de code est complexe, plus cela entraîne prompts répétés, erreurs et perte de temps
- Au final, l’auteur utilise l’IA pour de petits scripts ou des tâches non critiques, et continue de traiter lui-même les tâches complexes ou importantes
Le problème de la quantification de la productivité en développement logiciel
- L’idée qu’avec l’IA la productivité puisse être multipliée par 10 à 100 est déconnectée de la réalité
- Une productivité 10x ou 100x ne signifie pas simplement plus de lignes de code, mais qu’un travail prenant 3 mois (développement complet, revue de code, QA, etc.) serait terminé en 1,5 semaine
- Le développement logiciel comporte de nombreux goulots d’étranglement : planification, estimation des story points, correction de bugs, revue de code, attente de déploiement, tests, QA
- Pour atteindre cet objectif, chacune de ces étapes devrait aller 10 fois plus vite dans la même proportion
- En pratique, le temps consacré au codage lui-même est faible, et une grande partie du temps est investie dans la compréhension, la conception, la revue et la communication
- En réalité, la revue de code, la collaboration, la communication et la QA ne peuvent pas être raccourcies par l’IA
- Les véritables goulots d’étranglement du travail d’ingénierie se situent du côté des personnes, des processus et de la communication
- Les LLM (grands modèles de langage) réduisent le temps passé à taper au clavier, mais le temps nécessaire pour la qualité du code, les tests et la revue reste le même
- Même si l’IA peut accélérer temporairement l’écriture du code, l’augmentation du taux d’erreur, le non-respect des standards de code ou les re-prompts n’ont pas d’effet décisif sur la productivité globale
- Une productivité 10x est, en pratique, un objectif presque impossible à atteindre
La réalité et les limites de l’ingénieur 10x
- Concernant l’existence de l’« ingénieur 10x », l’auteur estime que cela peut exister de façon temporaire et limitée
- La raison principale est la capacité à éviter du travail inutile (empêcher des développements superflus dès la phase de planification, améliorer l’expérience de développement, documenter, etc.), ce qui s’accumule avec le temps
- Mais tous les ingénieurs ne se retrouvent pas constamment dans ce type de situation
- Les ingénieurs exceptionnels peuvent éviter du travail inutile ou améliorer l’ensemble de l’organisation via des améliorations système, mais il existe en pratique très peu de cas de performance réellement maintenue à 10x
- Les outils de codage IA contribuent peu à la prévention du travail inutile
- Au contraire, les recommandations de l’IA peuvent conduire à sur-implémenter ou à proposer une architecture inadaptée
- Coder vite ne signifie pas toujours être un bon ingénieur
Le contexte et les motivations derrière le mythe du 10x avec l’IA
La plupart des affirmations sur une « productivité multipliée par 10 » proviennent de facteurs comme les suivants
- Des ingénieurs de bonne foi qui commettent des erreurs de mesure
- Avec les outils d’IA, on peut vivre sur un court laps de temps une expérience d’efficacité explosive (ex. : rédaction automatique d’une règle personnalisée ESLint)
- Mais lorsque ce type de tâche se répète, l’écart de productivité finit par se réduire brutalement
- L’émerveillement technique, l’adaptation à un nouvel environnement, etc. peuvent au départ créer une illusion d’efficacité excessive
- Les incitations et les parties prenantes
- Les fondateurs de startups IA, les investisseurs et d’autres acteurs citent souvent des chiffres exagérés pour servir leur réussite commerciale
- Les ingénieurs comme les dirigeants peuvent aussi évoquer une productivité exagérée pour répondre aux attentes dans leur organisation
- Des intentions malveillantes
- Certains dirigeants diffusent des affirmations exagérées dans l’intention de nourrir l’anxiété des ingénieurs afin d’éviter des départs, des demandes d’augmentation, ou des remous internes
- La peur que chacun puisse être facilement remplacé à cause de l’IA revient périodiquement (un peu comme autrefois dans les débats sur les coding bootcamps)
Les résultats de l’IA dans l’open source et les projets réels
- Dans la plupart des cas concrets sur les gains de productivité liés à l’IA, il existe une distance entre l’auteur du récit et l’ingénieur dont la productivité aurait augmenté.
- Les cas d’usage d’outils d’IA démontrés directement par de vrais ingénieurs montrent une réalité plus nuancée et sans exagération
- Dans les projets open source, les résultats de l’usage de l’IA apparaissent souvent comme inférieurs aux attentes, voire comme des échecs
- Dans les démos publiques ou les témoignages d’ingénieurs, l’IA peut parfois sembler magique, mais dans la majorité des cas elle ne diffère pas tant que cela d’un simple « générateur de texte »
Une valeur plus importante que la « productivité » : préserver sa propre manière de développer
- L’IA permet parfois d’écrire du code plus vite, mais l’auteur continue de donner davantage d’importance au plaisir même de coder
- Si vous n’aimez pas le codage avec l’IA ou n’y trouvez pas de plaisir, il est acceptable de renoncer à une part de productivité
- Même au prix d’une certaine inefficacité, travailler d’une manière qui vous convient produit à long terme des résultats plus sains et de meilleure qualité
- Quand on travaille avec plaisir, on développe une meilleure capacité de résolution de problèmes, de conception et de collaboration avec ses collègues
- Le plaisir et l’état de flow comptent davantage pour la productivité à long terme et la qualité du code, et courir après la productivité à tout prix augmente le risque de burn-out
- À l’inverse, si le codage avec l’IA vous amuse vraiment et vous aide, rien n’empêche de l’utiliser activement
Conseils pour une culture d’entreprise saine
- Lors de l’adoption d’outils d’IA, imposer à tous les ingénieurs des attentes irréalistes et provoquer de l’anxiété nuit à la productivité de l’organisation
- L’obsession de la productivité maximale mène à une baisse de qualité, à une dégradation de la base de code et à des pertes à long terme
- Il est préférable de donner aux ingénieurs suffisamment d’autonomie et de confiance, et de laisser chacun choisir la manière d’utiliser l’IA qui lui convient
- Dans une organisation, il est important d’offrir des opportunités d’usage de l’IA tout en garantissant un climat d’autonomie
- Si les LLM et les innovations de codage par IA apportent vraiment une productivité 10x, les développeurs le découvriront naturellement d’eux-mêmes
Conclusion
- La révolution de l’ingénieur 10x grâce à l’IA relève davantage du mythe, et il n’existe pas de recette secrète que l’on manquerait réellement
- Le plus important est d’avoir confiance en ses compétences et en sa manière de travailler
- Les réseaux sociaux (en particulier LinkedIn et Twitter) amplifient les mythes exagérés, on peut donc sans problème les ignorer
10 commentaires
Il y avait vraiment des gens pour interpréter 10x comme un vrai facteur 10 ? Pour moi, c’était évidemment une formule exagérée de marketing / d’autopromotion, donc ça me déroute que certains la prennent au sérieux.
Même si ce n’est pas du 10x, il y a pas mal d’organisations qui ont une conviction sérieuse autour du Nx. Remplacer le coût salarial par des dépenses en IA et en attendre des résultats supérieurs…
Ce n’est pas une illusion sans fondement, parce que lorsqu’un PM veut essayer rapidement un petit POC, ou créer un outil pour des tâches répétitives, ça peut se faire en un rien de temps.
Alors, est-ce qu’il y a des développeurs qui y croient vraiment… ? Je pense que, selon la situation à laquelle chacun est confronté, l’ambiance dans le secteur est suffisamment pesante pour susciter une vraie inquiétude.
Je pense aussi qu’il faut avoir ce type de discussion sérieuse, ne serait-ce que pour pouvoir communiquer avec les fonctions non techniques et les responsables d’organisation.
Bien sûr, je ne nie pas que cela aide à la productivité. (Au niveau actuel de l’IA, à l’heure qu’il est) je pense évidemment que parler de 10x n’a aucun sens, et comme le texte original disait clairement « on n’arrive pas à x10 », c’est ce point qui m’a semblé très étrange, d’où mon commentaire, mais il est vrai que ma formulation n’était peut-être pas très bonne.
Comme vous le dites, la productivité de l’IA est une expression exagérée à des fins de marketing ou d’autopromotion, et je pense que cet article contient lui aussi une certaine part d’exagération.
Dans ce contexte, demander s’il y avait vraiment des gens qui interprétaient 10x comme signifiant littéralement dix fois donne un peu l’impression de chercher la petite bête, ce qui a sans doute provoqué cette réaction négative.
On dirait que vous avez répondu sans lire l’article original ; pourtant, nulle part dans le texte il n’était question de se prendre au sérieux...
L’affirmation selon laquelle DataTube.tv, le service de recherche d’idées virales pour YouTube développé par l’auteur, afficherait une utilisation « plusieurs dizaines de fois » supérieure à celle de Viewtrap relève évidemment aussi d’une exagération marketing / d’autopromotion, n’est-ce pas ?
C’est peut-être parce qu’on est en ligne, ou peut-être êtes-vous simplement comme ça, mais la plupart de vos commentaires étaient rédigés avec un regard très critique. J’aimerais que vous portiez un regard un peu plus ouvert.
Je pense que s’il y a de l’emballement autour de l’IA, il y a aussi l’excès inverse, donc je n’ai pas grand-chose à penser du texte en lui-même...
Ce commentaire fait un peu peur, genre wow ; ça fait peur de voir qu’on va jusqu’à retrouver d’anciens posts pour laisser à nouveau un commentaire, surtout quand on vient juste de s’inscrire aujourd’hui
En voyant votre commentaire et même en regardant mon historique, je n’ai pas l’impression qu’il y ait le moindre commentaire particulièrement honteux. Est-ce que le problème, c’est d’adopter un regard critique ? Faut-il, comme vous, ne laisser aucun commentaire pour bien vivre...
Hein ? Le chiffre de 10 avait même été converti en nombre de mois... Je comprends que l'expression « faire son sérieux » ait pu vous déranger. En revanche, les dizaines de fois de Datatube sont des mesures quantitatives. Bon, de toute façon, ce n'est pas comme si l'exploitation était en cours...
Avis Hacker News
Je ne comprends pas pourquoi seul le génie logiciel s’obsède autant avec le mythe de la productivité « x10 (10x) » ; ce concept n’existe pas en ingénierie mécanique, électrique, civile ou chimique
Un excellent ingénieur, c’est quelqu’un qui sait réduire les risques et concevoir des systèmes dans un ensemble de contraintes variées
Concevoir, c’est comprendre un domaine à travers des modèles, puis cerner le périmètre de validité et les limites de ces modèles
Le « 10x » n’existe pas ; il n’y a que le fait d’assumer la responsabilité de bons systèmes
S’il existe des ingénieurs logiciels « 10x », ce seraient ceux qui empêchent des incidents comme les fuites de données ; j’aimerais plutôt voir ce type d’événement diminué par 10
Moi aussi, je suis d’accord avec une bonne partie de cet article
Je suis un énorme partisan du développement avec des outils IA, mais les affirmations sur une productivité x10 ne m’ont jamais convaincu
Grâce aux LLM, certaines tâches comme taper du code vont 2 à 5 fois plus vite, mais cela ne représente qu’une partie du travail total
En pratique, beaucoup d’ingénieurs pensent que certaines tâches précises peuvent aller 20 à 50 % plus vite, mais je suis d’accord pour dire que cela ne se traduit ni par +20 % de productivité globale, ni par un gain x10
Bien sûr, ceux qui utilisent vraiment très bien l’IA peuvent ressentir un gain supérieur à 0,2x, mais à cause de la complexité intrinsèque du développement logiciel, le x10 reste irréaliste dans la plupart des cas
Quand j’utilise l’IA, j’ai l’impression de devoir la surveiller en permanence, donc je ne trouve pas ça particulièrement efficace
Parfois, les suggestions de Copilot collent parfaitement à ce que j’avais en tête et c’est impressionnant, mais dans l’ensemble, ça ressemble moins à un junior très compétent qu’à un « senior ivre » qui n’écoute pas vraiment
La moitié du code généré ne compile même pas, et même quand ça compile, ça ne fonctionne pas correctement
D’après mon expérience, l’IA n’apporte pas un gain de productivité énorme dans la création pure, mais elle aide beaucoup pour l’exploration, la découverte, l’apprentissage, le déblocage et l’écriture répétitive de code
En revanche, la vraie transformation se produit sur les side projects
Avant, j’étais trop fatigué pour consacrer du temps à des projets persos ; maintenant, même si le code n’est pas parfait, je peux concrétiser des idées rapidement et avec bien moins d’énergie mentale
Je peux aussi expérimenter librement mes compétences d’AI engineering, sans contraintes de délais, de vie privée ou d’outils
Je pense que même les personnes qu’on appelle des « ingénieurs 10x » ne gagneront que très peu en productivité avec l’IA
Les meilleurs développeurs que je connais se distinguent surtout par deux capacités : une mémoire phénoménale avec une connaissance détaillée de chaque langage et bibliothèque, et une créativité / capacité de résolution de problèmes presque miraculeuse
Ce qui m’impressionne, c’est leur faculté à arriver à la solution la plus adaptée, originale et élégante, même sans formules ni théorie
Quand on fait du pair programming avec une IA pour arriver à une solution comparable, elle a besoin d’essais et d’itérations sans fin, et finit plutôt par ralentir le génie humain
Mais comme le spectre des compétences est très large, dans mon cas l’IA peut malgré tout permettre un gain x10
Je ne viens pas du logiciel et j’ai un côté perfectionniste qui me fait développer très lentement ; grâce à l’IA, je peux rapidement sortir une première version médiocre, ce qui m’aide à concrétiser mes idées
Je suis moi aussi favorable au développement d’assistants IA, et je pense que des gains de vitesse de 2x à 10x peuvent exister dans certains cas
Mais le plus souvent, la « productivité 10x » est utilisée de façon exagérée pour dire que l’ensemble du processus de développement, du début à la fin d’une fonctionnalité, a été accéléré d’un facteur 10
En réalité, une grande partie du processus de développement global, surtout en dehors du code, n’accélère pas de x10
Cela dit, dans des environnements vraiment petits ou solo, on saute beaucoup de procédures pénibles, donc il peut y avoir un vrai gain de vitesse substantiel
Dans ce contexte, c’est une époque où les petites équipes et le développement en solo deviennent soudainement plus compétitifs
Merci au commentaire de Simon
C’est ce commentaire qui donne vraiment l’impression d’avoir lu l’article
J’admets que, dans certains rôles spécialisés sur un langage ou un outil, des gains réels de productivité x2 existent
Cela fait des décennies que je rêve d’automatiser le développement logiciel, et j’ai l’impression que les LLM ont réalisé ce rêve d’une manière totalement différente
Les anciens outils CASE, UML, IDE, etc. promettaient de « nous laisser nous concentrer sur la vraie logique », mais les LLM génèrent directement du code exécutable à partir du langage naturel
Beaucoup de développeurs voient les anciens rites de passage s’effondrer et ont peur d’être laissés derrière dans ce nouveau monde, avec un vrai syndrome de l’imposteur
Cela amène à se redemander ce qu’est réellement l’ingénierie logicielle
Les LLM sont la forme ultime des anciens outils CASE, mais tout est allé trop vite, et c’est confus et déstabilisant
Des gens qui ne connaissent pas le « langage sacré » des ingénieurs logiciels se retrouvent maintenant avec du pouvoir, et beaucoup d’ingénieurs en viennent à se demander fondamentalement : « Qu’est-ce que je suis en train de faire, au juste ? »
Je comprends enfin ce qu’ont ressenti les artistes quand ils ont vu stable diffusion
Le code généré par l’IA est souvent faux au final, bourré de bugs, de conventions étranges et de choses inutiles
Corriger tous ces problèmes prend parfois autant de temps que de faire les choses soi-même
On peut essayer différents modèles ou affiner les prompts, mais j’ai toujours l’impression que le code de haute qualité que je veux vraiment reste hors de portée
Comme avec stable diffusion, où ceux qui n’y prêtent pas attention ne voient même pas ce qui cloche, ceux qui ne comprennent pas bien le code IA ne voient pas forcément qu’il y a un problème
Récemment, j’ai regardé le code d’un collègue parce qu’il me semblait étrange ; il était rempli de problèmes et même le débogueur ne marchait pas, et il a fini par avouer qu’il avait « codé au feeling »
Quand je regarde le monde récemment, j’ai l’impression que le capital continue de détruire le travail
Bas salaires, mauvaises conditions de travail, surveillance, pression sur les indicateurs, entreprises contraires à l’éthique, contrats courts : la réalité de la plupart des travailleurs se dégrade de plus en plus
Nous avons été trop protégés jusqu’ici pour le ressentir pleinement, mais nous faisons désormais nous aussi face à un avenir instable
Le « software engineering » va finir par devenir un travail de correction du vibe
Beaucoup de métiers peuvent être remplacés par du logiciel, mais il existait déjà une réalité où les managers hésitaient à embaucher des SWE s’ils ne pouvaient pas démontrer une valeur validée
Avec l’adoption de l’IA, les managers vont produire en masse du code qu’ils ne comprennent pas, puis quand tout se cassera la figure dans trois ans, ils rappelleront les SWE pour réparer
Il est même probable que les emplois difficiles et à forte valeur consistant à corriger ce que « l’IA ne sait pas résoudre » deviennent plus nombreux
Les LLM produisent du code directement, sans modèle formel ni diagramme
Moi, j’aimerais plutôt que l’IA génère ce type de conception formelle ou de diagrammes
Ce genre d’outils aide à comprendre le code et à clarifier la conception
J’aimerais que l’IA prenne aussi en charge cette partie
Le goulot d’étranglement du développement logiciel, ce n’est ni la vitesse de frappe ni la génération, c’est la validation et la compréhension
Même si les LLM fonctionnaient parfaitement sans hallucinations, un développeur consciencieux devrait quand même relire le code ligne par ligne
Comme un humain ne peut pas comprendre du code 10 fois plus vite, on peut en réalité perdre encore plus de temps à retracer le code généré automatiquement et à en décoder les intentions cachées
Le discours sur la « productivité x10 » ne vaut que si l’on transmet la sortie telle quelle sans validation, ou si l’on traite du code extrêmement simple où les erreurs n’ont pas d’importance
Dans les logiciels de production, où la moindre erreur peut être catastrophique, le goulot d’étranglement reste la capacité cognitive humaine ; comme les LLM déplacent la charge de l’écriture vers la relecture, ils deviennent même négatifs pour la productivité globale
Cette discussion donne surtout l’impression que des développeurs moyens révèlent leur propre niveau de productivité
Si l’on comprend la technologie du projet et qu’on sait bien découper le travail, on peut anticiper la complexité du code et confier des unités adaptées à l’IA
L’IA n’est pas magique, elle a une limite supérieure de complexité qu’elle peut gérer
Si l’on comprend bien cette limite et la technologie du projet que l’on construit, on peut découper les composants en dessous de ce seuil et demander à l’IA de s’en charger
Cette méthode fonctionne plutôt bien
C’est presque une tautologie
Si l’on simplifie les consignes pour que l’IA fonctionne bien, alors évidemment elle fonctionne bien
Mais dans la pratique, il faut souvent lui mâcher des instructions beaucoup trop détaillées, et même là le résultat reste peu digne de confiance sans une vérification minutieuse
Le simple fait de tout découper finement et de l’expliquer à l’IA peut être plus pénible que d’écrire directement le code soi-même
Si l’IA trouve la bonne réponse du premier coup par chance, c’est efficace ; mais en réalité, on finit souvent à corriger de façon répétée ou à tout refaire, avec une perte de temps et d’effort
Le code bien structuré et agréable à lire produit par l’IA est souvent faux en pratique, ce qui est dangereux
La partie vraiment difficile et chronophage, c’est la conception des parties complexes
Les morceaux triviaux, il suffit de les saisir, mais résoudre les parties complexes, c’est là que part le vrai temps
On sent derrière ce commentaire une nuance du genre : « Je me considère au-dessus de la moyenne comme développeur ? »
Ce pourrait même être l’inverse
Des développeurs peu compétents soumettent mécaniquement des auto-PR sans valeur et s’extasient devant les résultats produits par l’IA, alors que des développeurs avec des standards élevés ne seront pas impressionnés
En pratique, tant qu’on n’a pas vraiment travaillé avec quelqu’un, il est difficile de distinguer les personnes fiables ; je préfère donc rester neutre
L’IA comme l’humain ont leurs limites
Au final, ce qu’il faut, c’est l’ennuyeuse gestion de projet
Avec des exigences correctes, une bonne conception, et suffisamment d’informations pour découper en petites unités de travail, on peut demander à l’IA « implémente l’issue GitHub #42 » et la regarder faire en regardant la télé
Mais si on lui dit « fais-moi Facebook », évidemment c’est voué à l’échec
Un autre domaine où l’IA m’a énormément aidé, c’est la recherche de bugs
Je travaille surtout sur des simulations numériques, et sur un problème qui me bloquait depuis plusieurs jours — une erreur d’échelle dans une formule due à quelques parenthèses manquantes — j’ai simplement expliqué le symptôme et fourni les fichiers à ChatGPT, et il a trouvé la cause très vite
L’IA joue parfois le rôle de révélateur limpide de ce que j’avais raté
Cela ne crée pas un développeur 10x, mais bien utilisée, l’IA a un effet très positif et tangible
Même chose pour moi
Générer du code avec l’IA, c’est moyen, mais pour le débogage c’est un vrai bond de productivité
C’est une sorte de « rubber duck » extrêmement intelligent
(Point de vue d’un développeur amateur) Grâce aux LLM, développer tard le soir quand je n’ai plus les idées claires est devenu beaucoup plus facile
J’ai moi aussi économisé d’innombrables heures grâce à l’IA
Pour moi, c’est quelque part entre x10 et l’infini
Je ne me considère pas comme un ingénieur 10x
Si je suis plus productif que mes collègues, c’est parce que je fais de la conception système et que je ne prends pas les tickets métier flous tels quels
Si l’IA ne peut pas simplifier mes collègues, c’est parce qu’elle ne change pas leur habitude de créer de la complexité dès le départ
L’IA ne résout pas ce problème non plus
Comme mon salaire n’est pas deux fois supérieur à celui de mes collègues, j’en conclus que non
L’adoption d’outils IA ne changera pas cette réalité
Cet article consiste à fixer un seuil « 10x » beaucoup trop élevé, puis à raconter les tentatives personnelles de l’auteur pour le dépasser
J’ai donc l’impression qu’il répartit les partisans de l’IA en trois catégories : ceux qui se trompent, ceux qui vendent, et les mauvais managers qui exploitent l’anxiété
Personnellement, je considère les plaintes à propos des « hallucinations » un peu comme un « signal »
Je pense qu’il est indispensable de parler des hallucinations
Les discussions sur les LLM deviennent trop extrêmes, entre ceux qui disent que ça ne sert absolument à rien et ceux qui annoncent le remplacement des développeurs
Par exemple, Claude 4 Sonnet a déjà répondu à tort que Godbolt se trompait sur un sujet de compilation clang
Malgré cela, cette session dans son ensemble m’a été d’une grande aide ; il faut simplement garder à l’esprit qu’il faut rester critique vis-à-vis des résultats
Les hallucinations existent réellement, et il faut toujours rester sur ses gardes face aux résultats
Merci d’avoir laissé ce commentaire ; tes articles sur l’IA m’ont aidé à surmonter mon syndrome de l’imposteur
Dans l’article, la classification ne visait que ceux qui affirment avoir enchaîné les réussites « 10x » ; ce n’était pas une attaque globale contre tous les partisans de l’IA
Je me demande si tu as trouvé une méthode pour éliminer complètement les hallucinations
Notamment avec Terraform, les LLM inventent encore des propriétés inexistantes, et en JS aussi, dès qu’on utilise des bibliothèques rares, les erreurs d’invention restent fréquentes
Si se plaindre des « hallucinations » est un signal, alors penser cela en est un aussi…
(brève réfutation)
Ce seuil du 10x relève d’un marketing exagéré partagé par toute l’industrie
Exemple : l’affirmation 10x de Sam Altman
La promotion de productivité de Cursor AI
Le développeur 10x augmenté par l’IA
Supposons qu’une personne qui ne sait pas créer de web app en apprenne les bases pendant 6 semaines à raison de 4 heures par jour (120 heures) pour en construire péniblement une seule
Si, à la place, elle utilise une IA comme Claude Code pour créer la même web app en deux jours de week-end (12 heures), alors sa productivité a été multipliée par 10
C’est très proche de ce qui m’est réellement arrivé
Avant, par manque de motivation ou d’énergie, je n’arrivais pas à faire ce genre de choses ; maintenant, grâce à l’IA, je peux les faire sur un week-end
Mais avec la première méthode, il y a un apprentissage qui peut aider quand il faudra modifier quelque chose ensuite
En réalité, si on demande à une IA comme Claude Code de scaffold une web app autrement qu’en React, le résultat est souvent catastrophique
Quelqu’un sans expérience de développement d’apps ne construira pas facilement une application de qualité en un week-end
Elle peut déjà s’effondrer dès la connexion du premier utilisateur
À long terme, je ne pense pas que ce calcul tienne
Au début, on crée vite une app avec un LLM, mais on perd peu à peu sa capacité de maintenance, et à un moment on n’arrive plus à contenir ni gérer la complexité croissante du système dans une simple « fenêtre de contexte »
Au final, la productivité peut même tendre vers zéro
C’est comme avoir entièrement externalisé son cerveau et son expérience d’apprentissage : l’app existe, mais la progression et l’apprentissage sont presque inexistants
Tu comptes vraiment déployer ça tel quel ?
En réalité, ce n’est pas comparable
Il est déjà difficile de mesurer la production d’un développeur 1x, alors la multiplier n’a encore moins de sens
J’ai l’impression que l’IA augmente énormément la « productivité des quêtes secondaires »
Elle est parfaite pour toutes ces tâches qu’on remettait à plus tard par flemme : faire des maquettes, écrire des tests, extraire des bibliothèques, documenter, etc.
Elle ne réduit peut-être pas le temps de création des fonctionnalités, mais si on inclut ces tâches annexes, le résultat final se rapproche un peu plus de quelque chose de complet
J’espère que ces tâches annexes me feront aussi gagner du temps plus tard au moment de chercher des bugs
(Expérience personnelle)
Cela ne vaut que pour mon cas, mais dans mon entreprise, il est courant que le code de test produit par les LLM soit beaucoup trop étroitement couplé au code d’implémentation
On y abuse énormément de patterns comme les test spies
Résultat : on se retrouve avec beaucoup de tests ambigus qui vérifient surtout des détails d’implémentation internes au lieu du comportement du point de vue utilisateur
Les tests cassent trop souvent au moindre changement d’implémentation, si bien qu’ils deviennent une charge plutôt qu’un gain de productivité
Ce n’est pas seulement un problème des LLM : ce sont des développeurs déjà mauvais en tests qui aggravent encore le problème avec les LLM
Pour des développeurs qui manquent d’expérience en TDD et en code de test bien conçu, les LLM amplifient ce type d’anti-patterns
J’aime bien l’expression « productivité des quêtes secondaires »
L’IA, ce n’est pas « mille petites coupures qui mènent à la mort », c’est plutôt « une nouvelle vie faite de mille pansements »
J’adhère à l’idée des « quêtes secondaires »
En réalité, le grand changement, c’est que grâce à l’IA je peux créer des outils ou des fonctionnalités que je n’aurais tout simplement jamais faites sans elle
Ce n’est pas seulement économiser deux semaines ; c’est faire apparaître un résultat qui n’existait pas auparavant
Les attentes vis-à-vis des LLM sont plus élevées que la réalité, mais ils restent extrêmement utiles dans des contextes très variés
Selon le « niveau de zoom », plus on descend d’un vague « vibe coding » vers des demandes du type « écris-moi cette fonction », meilleurs sont les résultats
Au-delà de la génération de code, ils sont aussi efficaces pour apprendre de nouvelles technologies et pour bien d’autres usages
Si mon rôle implique beaucoup de réunions ou de tâches managériales, l’aide des LLM diminue
À l’avenir, je pense qu’ils pourront aussi servir dans les workflows de PR, le nettoyage des commits, la réorganisation de l’ordre des changements, etc.
Même si on ne l’utilisait que pour répondre aux ingénieurs qui disent trop souvent, sans réfléchir, « ce n’est pas possible » ou « c’est irréalisable », j’ai l’impression qu’on obtiendrait déjà un effet x10.
J’ai souvent été témoin de scènes où l’on traitait les non-développeurs d’ignorants tout en affirmant systématiquement que c’était impossible.