- Cela fait environ deux ans que les outils d’assistance au code basés sur les LLM ont été lancés
- Certains développeurs rapportent une hausse de productivité pouvant aller jusqu’à 5x à 10x
- Cependant, il n’existe aucune preuve claire que la productivité de l’ensemble de l’industrie logicielle ait augmenté de 5 à 10 fois
- En pratique, au-delà de l’ajout de simples fonctionnalités standard dans une base de code, les outils LLM se montrent délicats à utiliser
- La plupart des programmeurs ne savent pas comment utiliser efficacement les outils LLM, ou ne s’y intéressent pas
Pourquoi les gains de productivité semblent concentrés sur certains utilisateurs
- Si la productivité a réellement été multipliée par 5 à 10, il est probable que cela soit limité à une minorité d’utilisateurs avancés ou de développeurs expérimentés particulièrement à l’aise avec les LLM
- Rien n’indique que l’ensemble de l’industrie logicielle fournisse soudainement beaucoup plus de fonctionnalités utiles, ni que la qualité se soit visiblement améliorée
- L’auteur dit n’avoir presque pas ressenti l’impact des LLM au cours des 1 à 2 dernières années
Quels projets les LLM ont-ils réellement rendus possibles ?
- Il n’est pas clairement établi quels projets ont été rendus possibles grâce aux performances des LLM
- Les travaux de recherche offrent eux aussi très peu d’exemples concrets (la refactorisation de COBOL étant à peu près le seul cas cité)
- Même les produits fondés sur les LLM dans les laboratoires AGI ne montrent pas de résultats particulièrement impressionnants
- Ils se limitent à offrir des fonctions basiques comme l’envoi de PDF dans une boîte de dialogue
- Ils manquent de capacités permettant au LLM d’interagir de manière fluide avec différents logiciels et types de données
Question : existe-t-il réellement des domaines où la productivité a augmenté ?
- Il n’existe pas de preuve claire montrant quels projets ont été lancés plus vite grâce aux LLM
- On ne voit aucune trace d’un domaine particulier de l’écosystème logiciel ayant connu une croissance par 10
Ce que l’on veut, ce sont des preuves concrètes et tangibles
- Les types d’informations suivants sont inutiles
- Les affirmations vagues sur une productivité multipliée par 10
- Les références à des indicateurs économiques abstraits ou à une hausse de la quantité de code produite
- Les simples exemples de génération d’outils ou de fonctionnalités basés sur des LLM
- Les petits exemples du type « créer un clone de Snake avec ChatGPT »
Théorie provocatrice : il est possible que les LLM n’augmentent pas réellement la productivité
- Corriger le code généré par les LLM et résoudre les problèmes qu’il crée peut au contraire faire perdre du temps
- Quand une base de code importante générée par LLM dépasse un certain niveau de complexité, elle peut devenir impossible à corriger, au point qu’il faille finalement tout réécrire depuis le début
- Même lorsque les LLM produisent de nouveaux logiciels, il est probable qu’il s’agisse surtout d’outils à usage unique ou de code de démonstration jamais utilisé
- Même dans des logiciels réellement utiles, une augmentation du volume de code peut accroître le risque de fonctionnalités inutiles ou de bloatware
- Il est possible que les programmeurs soient séduits par une expérience quasi « magique » consistant à obtenir des résultats immédiats grâce aux LLM
Une fourchette réaliste de gains de productivité
- D’après l’expérience de l’auteur, les LLM ne sont utiles que dans certains cas précis
- Écrire des fonctionnalités mineures
- Aider à apprendre une bibliothèque ou une base de code spécifique
- Effectuer de petits travaux de refactorisation
- Le gain de productivité se situe probablement plutôt autour de 10 à 30 %
- Une maximisation de la productivité semble difficile avant l’arrivée de l’AGI (intelligence artificielle générale)
[Commentaire de Richard Horvath]
Cas où les LLM peuvent offrir un gain de vitesse de 10x dans certaines situations
- Écriture de petits scripts autonomes
- Ils donnent d’excellents résultats pour des tâches simples (par exemple des scripts bash de manipulation de fichiers, ou du code Excel VBA)
- Une simple description suffit souvent à les produire, et leur validation est facile
- Ils peuvent être écrits sans connaissance approfondie du langage
- Il n’est pas nécessaire de se soucier de maintenance, de modularisation ou de tests unitaires
- Ils sont particulièrement efficaces pour les tâches liées aux expressions régulières (regex)
- Accélération de l’apprentissage lorsqu’on travaille sur une stack peu familière
- Ils permettent de repérer rapidement les classes et méthodes d’une nouvelle bibliothèque
- Même si le code généré ne fonctionne pas entièrement, ils suggèrent une approche de résolution du problème
- Ils réduisent fortement le temps autrefois consacré à chercher dans la documentation ou les tutoriels
- En revanche, le code généré doit être corrigé et refactorisé manuellement
Les personnes qui rapportent une hausse de productivité par 10 relèvent probablement de l’un des cas suivants
- Faible niveau de connaissances en développement
- Lorsqu’on manque de bases en programmation, le code produit avec l’aide d’un LLM peut sembler bien meilleur qu’auparavant
- Mais dans ce cas, il est très probable que ce code ait des effets négatifs à long terme
- Besoin d’écrire beaucoup de solutions petites et indépendantes
- Les automatisations Excel ou l’écriture de scripts shell en DevOps sont des cas où les LLM sont particulièrement utiles
- Besoin d’expérimenter fréquemment avec différentes stacks et bibliothèques
- Cela concerne davantage des activités d’exploration que du travail durable sur une stack précise
- Effet d’ancrage (Anchoring Effect)
- Quand un LLM produit un résultat immédiat sur une tâche donnée, on risque de surestimer cela et d’y voir un gain de productivité durable
[Commentaire de Davidmanheim]
- Du point de vue des développeurs et des dirigeants dans une entreprise classique, les gains de productivité liés aux LLM ne peuvent en réalité rester que limités
- Cela s’explique par la théorie des contraintes (Theory of Constraints) :
- Supposons qu’auparavant une tâche soit accomplie via le processus suivant :
- Business Analyst → 1 jour
- testeur QA → 1 jour
- programmeur → 1 jour
- Même si la productivité du programmeur est multipliée par 2 ou par 5, la durée totale du travail ne diminue pas
- Les autres étapes (analyse métier et QA) deviennent le goulot d’étranglement, si bien que la vitesse globale du processus reste inchangée
- Une reconfiguration des processus d’entreprise est nécessaire
- Pour tirer pleinement parti des gains de productivité permis par les LLM, il faut repenser l’ensemble des processus de l’entreprise
- Or cette reconfiguration n’a commencé que dans certaines entreprises à l’heure actuelle
[Commentaire de faul_sname]
- Avec les LLM, il dit avoir obtenu notamment les résultats suivants dans la génération de maquettes UI :
- Auparavant, la création de maquettes UI représentait environ 10 % du temps total de travail
- Grâce aux LLM, cette création est devenue environ 5 fois plus rapide
- Mais le temps de travail total n’a pas diminué pour autant
- En revanche, le niveau de détail et l’interactivité des maquettes UI se sont fortement améliorés
- Cela a permis davantage d’itérations, et donc une amélioration finale de la qualité du produit
- Le « code qui sera jeté » n’est pas forcément inutile
- Même un prototype ou du code de démonstration peut contribuer à créer un meilleur produit final
- Les LLM fournissent aussi des réponses sur des erreurs précises difficiles à trouver via un moteur de recherche
- Exemple : « comment résoudre une erreur survenant dans une tâche exécutée sur telle stack xyz »
- Ils aident au débogage dans des contextes précis de stack et de configuration Kubernetes
- Il estime la hausse globale de productivité à environ 10 à 30 %
- Mais cette hausse n’est pas homogène sur l’ensemble des tâches
- Des accélérations spectaculaires sur certaines tâches (par exemple les maquettes UI, le débogage, etc.)
- Peu ou pas de résultats sur les travaux complexes ou sur du code legacy
- Les gains sont surtout visibles au début des projets, puis diminuent dans les phases de maintenance complexes
- Selon lui, la limite ici n’est pas un manque d’agency, mais un problème de gestion du contexte (context management)
[Commentaire de Noosphere89]
- En citant le point de vue d’Ajeya Cotra, il mentionne les points suivants sur l’effet des LLM sur la productivité des programmeurs :
- La productivité de l’IA en programmation est plus élevée que prévu
- L’IA obtient des résultats significatifs dans les tâches de codage
- Mais ses performances chutent nettement dès qu’il s’agit de tâches hors du code
- L’impact industriel global de l’IA reste donc pour l’instant limité
- Liens vers les publications d’Ajeya Cotra
- À propos de l’affirmation selon laquelle « il faut l’AGI pour obtenir des résultats durables »
- La trajectoire actuelle de développement de l’IA montre moins de généralité que prévu
- Les performances de l’IA peuvent fortement progresser sur certaines tâches, tout en révélant des faiblesses nettes dans certains domaines
- En raison de ce déséquilibre des performances, le concept d’AGI (intelligence artificielle générale) pourrait être moins utile qu’on ne l’imaginait
[Commentaire de yo-cuddles]
- Exemple d’une personne dans son bureau qui fait de la robotic process automation (RPA)
- Elle affirme avec force être beaucoup plus productive
- Mais en réalité, son travail est inefficace et peu fiable, ce qui fait perdre du temps aux autres qui doivent corriger ses productions
- Ses collègues essaient de l’écarter du workflow
- Les gens mesurent mal leur propre productivité et perçoivent surtout certains gains ou pertes spécifiques :
- Focalisation sur les gains visibles
- Lorsqu’une tâche est rapidement accomplie par une méthode automatisée, le sentiment d’accomplissement est immédiat
- Comme ces résultats rapides sont tout de suite visibles, ils sont perçus comme un effet positif
- Les coûts à long terme sont difficiles à percevoir
- Le temps perdu après coup est difficile à retracer
- En particulier lorsque quelqu’un d’autre corrige les problèmes, ce coût devient invisible
- Même si des erreurs issues d’un travail automatisé sont ensuite corrigées, il reste difficile de ressentir le temps perdu qu’elles ont entraîné
- Les problèmes causés par du code généré par LLM sont difficiles à identifier pour les raisons suivantes :
- En cas de bug, il est difficile de retracer précisément que la cause vient du code généré par le LLM
- D’autres personnes peuvent perdre du temps supplémentaire dans le processus de correction
- On peut ne pas percevoir la cause profonde du problème, ni réaliser qu’elle vient de l’usage de l’outil d’automatisation
- Le sentiment de « j’ai terminé rapidement grâce à l’automatisation » est fort, mais le « temps perdu à cause de l’automatisation » est difficile à ressentir
- Malgré la généralisation de l’usage des LLM, aucune hausse nette de productivité n’apparaît clairement à l’échelle de l’industrie
- Les gens affirment être « deux fois plus productifs », mais il est très possible qu’en réalité leur productivité ait baissé à cause de problèmes cachés
- Autrement dit, le temps et les ressources consommés à résoudre ces problèmes restent invisibles, ce qui conduit à une perception exagérée des résultats
6 commentaires
Cela correspond assez à mon expérience aussi.
Dans ce genre de cas, j’ai gagné pas mal de temps. Avec la combinaison Google + Stack Overflow, on ne trouve souvent pas grand-chose de pertinent, et surtout sur Stack Overflow, même quand il y a une réponse, il y a toujours beaucoup d’objections en commentaires, ou bien il s’agit d’une manière de faire d’une ancienne version qu’il ne faut plus utiliser, ce qui était souvent vraiment agaçant...
On dirait que le gain de productivité x10 apparaît surtout au moment du prototypage.
Je suis plutôt ravi.
> La plupart des programmeurs ne savent pas comment utiliser efficacement les outils LLM, ou ne s’y intéressent pas.
Étonnamment, beaucoup de développeurs autour de moi ne s’intéressent pas vraiment à la technologie. Ils passent la majeure partie de leur temps à consommer mécaniquement des YouTube Shorts nouveaux ou répétitifs.
Avis sur Hacker News
Je travaille dans une entreprise tech populaire à Seattle, où l’usage de l’IA est imposé. La direction suit de près à quel point les développeurs utilisent l’IA, et on m’a même demandé personnellement pourquoi je ne l’utilisais pas davantage. Je pense qu’il est important d’utiliser le bon outil pour la bonne tâche, et l’IA n’est pas toujours adaptée.
Il existe un vieil adage selon lequel les 10 % finaux d’un projet logiciel prennent 90 % du temps. L’IA est utile sur les 90 % initiaux, mais elle n’aide pas sur les 10 % restants.
Chez une FAANG, nous utilisons des LLM intégrés à l’IDE, avec un effet légèrement positif.
Comme exemple de développeur ayant réellement connu une amélioration par 10, il y a le cas de Pieter Levels, qui a codé un simulateur de vol multijoueur en 3D en quelques jours.
J’ai essayé d’utiliser des LLM pour générer du code, mais au début ma productivité a baissé.
Je fais partie de l’équipe qui développe Copilot Autofix chez GitHub, qui propose des correctifs à partir des alertes CodeQL.
La qualité des réponses des assistants de code basés sur des LLM dépend fortement de la capacité de communication du programmeur.
L’hypothèse selon laquelle la productivité logicielle n’aurait pas été multipliée par 5 à 10 est peut-être fausse.
Il semble que le dernier point de la traduction du résumé des avis sur Hacker News, « il pourrait être erroné de supposer que la productivité du logiciel n’a pas été multipliée par 5 à 10 », soit une mauvaise traduction. À la lecture du texte original, un résumé plus raisonnable serait plutôt quelque chose comme : « affirmer que la productivité du logiciel a été multipliée par 5 à 10 repose sur des hypothèses erronées concernant le gain de productivité ».