L’illusion des promesses sur le code assisté par l’IA : pourquoi l’explosion du « shovelware » n’a pas lieu

• Les affirmations récentes sur les gains de productivité des outils de codage par IA ont été vérifiées à partir des données, et en réalité ni la vitesse ni les livrables n’augmentent de manière visible
• Selon une étude de METR, les développeurs pensaient que les outils de codage par IA amélioraient leur productivité de 20 %, mais en pratique elle a baissé de 19 %
• Les nombreux slogans promotionnels ainsi que les affirmations exagérées d’une productivité multipliée par 10 par les entreprises et les développeurs ne se reflètent ni dans la réalité du marché ni dans les nouvelles sorties logicielles
• Aucun phénomène comparable à une explosion du Shovelware (applications produites en masse, logiciels de faible qualité) n’est observé, donc aucun changement visible n’apparaît
• Les exagérations sur la productivité de la part d’entreprises comme GitHub, Copilot, Cursor, Google et OpenAI, ainsi que de certains développeurs, sont utilisées à mauvais escient dans les investissements, les restructurations et la fixation des salaires
• Conclusion principale : « Tant qu’il ne sort pas réellement davantage de logiciels, l’affirmation selon laquelle le codage par IA rend les développeurs 10 fois plus efficaces est fictive » ; les développeurs ne doivent donc pas céder à la pression et doivent répondre avec des données

---

Introduction : des développeurs logiciels en colère contre le codage par IA

• Après de longues années comme développeur logiciel, l’auteur dit avoir construit sa fierté et son identité autour de la programmation
• Au début de l’adoption des outils de codage basés sur l’IA, il était enthousiaste, mais une étude récente (METR) l’a rendu sceptique
  • Il pensait personnellement que le codage par IA le rendait environ 25 % plus rapide, alors que l’étude METR conclut au contraire à 19 % de ralentissement
• L’étude montre que la perception qu’ont les développeurs de l’efficacité des outils d’IA est à l’opposé des données mesurées
• Ses propres expérimentations lui ont aussi fait sentir que l’usage de l’IA n’avait pas d’effet positif sur le temps réel de programmation

Vérification directe : expérimentation comparative aléatoire avec et sans IA

• Une méthode expérimentale a été appliquée pour mesurer, par unité de travail, la différence de temps (Delta) entre les cas avec IA et sans IA
• Les données recueillies pendant 6 semaines n’ont révélé aucune différence statistiquement significative
• Malgré un petit échantillon, une tendance montrant que l’usage de l’IA rendait en réalité le travail 21 % plus lent a été observée (le même chiffre que dans l’étude METR)
• S’il y avait vraiment eu un gain de 2x ou 10x, les données l’auraient montré clairement
• Le rêve actuel du codage par IA ne se matérialise pas et, en pratique, rien ne change

Entre attentes et réalité : pourquoi il n’y a pas d’explosion du Shovelware

• Si la révolution de productivité promise par le codage par IA était réelle, on devrait voir exploser toutes sortes d’apps, de services et de jeux
• Les messages marketing des nombreux outils de codage par IA pullulent (« Built to make you extraordinarily productive », etc.)
• Google, OpenAI, GitHub Copilot et d’autres affirment eux aussi que les développeurs sont 25 % plus rapides ou 10 fois plus productifs
• Mais dans les données réelles sur les nouvelles sorties logicielles (GH Archive, BigQuery, etc.), aucune forte croissance ni explosion n’apparaît
• Malgré la diffusion grand public du codage par IA depuis 2022, il n’y a pas de changement majeur dans le volume mondial de nouvelles releases et de nouveaux projets

Impact sur le marché et réalité des développeurs

• Des répercussions sociales apparaissent aussi dans l’industrie : stratégie AI-First, FOMO, licenciements massifs et baisse des salaires des développeurs
• Sur le terrain, les outils d’IA n’apportent pas de révolution de productivité
• Ni la courbe d’apprentissage ni la maîtrise des outils ne permettent d’expliquer un écart absolu de productivité

Conclusion : la nécessité d’un jugement lucide fondé sur les données

• Le point essentiel est de constater à partir des données qu’il n’y a à ce jour aucun changement dans le volume de nouveaux logiciels livrés
• Aucune preuve n’étaye l’affirmation selon laquelle l’IA aurait créé des développeurs 10x
• Les développeurs ne doivent pas céder à la pression et doivent choisir leurs outils en s’appuyant sur les données qu’ils ont eux-mêmes vérifiées

Réponses aux objections les plus fréquentes

1. « Si l’on maîtrise vraiment l’art du prompt, on devient un développeur 10x »

   • Si certains atteignaient réellement une productivité multipliée par 10, la production mondiale de nouveaux logiciels aurait plus que doublé
   • La preuve la plus importante n’est pas le discours, mais les résultats objectifs (apps, projets, etc.)

2. « Nous n’en sommes qu’au début, il faut du temps »

   • Des dizaines de milliards de dollars ont déjà été investis, et l’adoption est déjà en cours dans les équipes
   • Les décisions prises aujourd’hui ont un impact direct sur la vie réelle des gens

3. « Si on ne l’adopte pas maintenant, on sera distancé »

   • Même dans les données de GitHub Copilot, l’augmentation réelle de productivité liée à la montée en compétence reste extrêmement faible (taux d’acceptation de 29 % à 34 %)

4. « La qualité s’est améliorée, seule la quantité n’a pas bougé »

   • La qualité globale du secteur serait au contraire en régression, et les tests diminuent aussi
   • Si c’était vraiment un outil de développeur 10x, on devrait voir une déferlante de Shovelware

5. « Tout tourne autour des sites web, et aujourd’hui plus personne ne se soucie des noms de domaine. Les sous-domaines de plateformes comme Vercel suffisent »

   • Beaucoup d’utilisateurs continuent malgré tout de préférer des domaines individuels

6. « L’explosion des domaines en .ai (47 % cette année) = une augmentation réelle »

   • La hausse des nouveaux domaines s’explique seulement par le pivot des startups IA, pas par une explosion du nombre total de nouveaux domaines
   • Le volume total des domaines ne montre pas cela

7. « L’essentiel du développement se joue en dehors du code »

   • Dans les environnements de développeurs individuels ou de petites équipes, plutôt que dans les grandes entreprises, le code reste effectivement central
   • On ne voit toujours pas apparaître une hausse notable des nouveaux projets répondant à de petits besoins de codage du quotidien

Mot de la fin

• Les développeurs ne publient pas réellement davantage
• L’affirmation selon laquelle le codage par IA offrirait une productivité multipliée par 10 peut être réfutée par les données
• Il ne faut pas se laisser emporter par le FOMO et les récits marketing du secteur, mais évaluer à partir des résultats concrets
• Message de l’auteur : « Si vous ressentez la pression, montrez les données et les graphiques. Pour toute affirmation de productivité multipliée par 10, exigez les justificatifs. »

[ahwjdekf]

Pour les développeurs 10x, avec l’aide de l’IA, ils peuvent sans doute passer à environ 12x.

[overthetop]

L’IA est une illusion. Elle n’est pas fiable et son niveau est faible. Dire qu’on peut développer avec l’IA est un mensonge exagéré. C’est impossible. Et utiliser l’IA est un comportement irresponsable qui revient à abandonner l’éthique des développeurs.

[nemorize]

Je me dis que l’on pourra vraiment dire que l’IA aide fortement à améliorer la productivité de l’écriture de code le jour où l’on pourra lui confier entièrement les tâches répétitives simples et se concentrer totalement sur des tâches plus importantes.

Quand on donne une consigne une fois, il faut attendre plusieurs dizaines de secondes pour obtenir un résultat, mais on ne peut pas vraiment mettre à profit cet intervalle, et on ne peut pas non plus s’attendre à un résultat toujours parfait au bout de ces quelques dizaines de secondes.

Au final, tant que cette tâche simple n’est pas parfaitement terminée, je dois continuer à y prêter attention, et comme je ne peux pas non plus basculer sur une autre tâche... il est difficile d’espérer une amélioration réellement significative.

[nemorize]

Franchement, j’ai l’impression qu’il aurait été plus utile pour gagner en productivité de trouver sur Karrot un petit jobber payé 10 000 wons de l’heure pour faire pendant quelques heures seulement des tâches simples.
Avec une dépense d’environ 100 000 wons par semaine, personnellement j’en étais plutôt très satisfait.

J’ai notamment travaillé avec plusieurs dames qui faisaient de la comptabilité avant d’arrêter pour devenir femmes au foyer à plein temps, et même celles qui ne connaissent absolument rien au code arrivent à faire quelque chose de très propre après seulement quelques retours de feedback, haha.
Elles peuvent aussi produire en un instant du code boilerplate en utilisant Excel, avec le remplissage automatique, des formules, etc.

[zxcv123]

Hum... honnêtement, je pense aussi que l’IA reste avant tout un outil, donc il faut savoir bien l’utiliser.
Quel que soit l’outil, il y a toujours plus de gens qui l’utilisent à la va-vite, ou qui ne savent pas vraiment s’en servir correctement, que de gens qui le maîtrisent bien.
Si on configure l’IA pour qu’elle produise des résultats de qualité, elle peut clairement offrir des performances impressionnantes.
J’ai l’impression que ce sont surtout ceux qui ne savent pas obtenir de bons résultats avec l’IA, et qui se contentent d’empiler des prompts idiots, qui disent ensuite que leur productivité a baissé. Franchement, je ne comprends pas qu’on puisse nier la productivité apportée par l’IA.

[kirrie]

Mais dire cela, j’ai l’impression que ça ne prouve rien, un peu comme l’affirmation selon laquelle « une personne qui comprend vraiment l’informatique en profondeur et a acquis suffisamment d’expérience est plus productive que n’importe quelle IA ».

[ndrgrd]

J’ai vu il y a peu l’étude du METR mentionnée, et j’ai trouvé que ses résultats expliquaient très bien ce que je ressentais et les questions que je me posais.

Même quand on lui confie des « tâches répétitives », comme dans les commentaires sur Hacker News, il faut en réalité le plus souvent vérifier et corriger manuellement.
Ce n’est pas la première ni la deuxième fois qu’en voyant la logique désordonnée d’un résultat « simple » produit par l’IA, je me dis que j’aurais mieux fait de le faire moi-même.

Pour des tâches vraiment simples, au niveau du copier-coller, oui, elle s’en sortira bien.
Mais pour ce genre de choses, le simple copier-coller et les snippets sont tout simplement plus efficaces. Et on n’a pas besoin de se connecter à Internet, d’envoyer ses données sur le serveur de quelqu’un d’autre, ni d’attendre des dizaines de secondes à chaque fois.

[GN⁺]

Avis Hacker News

• Pour moi, l’IA ressemble à une courbe en cloche, et je pense que c’est pareil pour beaucoup de gens. Le critère d’évaluation du résultat me semble essentiel. Ce ne devrait pas être le « nombre de lignes de code », mais le « nombre de lignes de code de bonne qualité, maintenables, extensibles et faciles à faire évoluer ». Avec ce critère, les résultats de requêtes comme « générer tout le repo » ne sont que des déchets sans intérêt, alors que l’autocomplétion par l’IA d’un truc comme getUser(... est un vrai gain de productivité. Je ne peux pas dire avec certitude si ça représente 0,1 %, 1 % ou 10 % d’augmentation

• Le problème le plus grave de mon point de vue, c’est que les problèmes sur lesquels je travaille actuellement dans mon entreprise demandent une planification et une exécution soigneuses, et que l’IA n’aide absolument pas. Pourtant, notre manager a réduit les délais d’un projet à 20 % de l’estimation initiale au motif que « nous sommes une entreprise AI-first ». Ce genre de folie collective se répand énormément chez les SVP et les PM, et je n’ai jamais vu ça auparavant

  • Le manager a dit qu’il avait ramené le délai du projet à 20 % de l’estimation d’origine, et je trouve ça complètement absurde. Quelqu’un décide juste de ce chiffre irréaliste et le transforme en réalité. Et quand ça ne marchera pas, on me fera porter la responsabilité, puis plus haut on demandera des comptes à ce manager. Si l’IA augmente vraiment la productivité, il suffira alors de supprimer les développeurs devenus inutiles, mais ça ne devrait venir qu’une fois que les LLM se seront intégrés avec succès au processus de développement. Je me demande même s’il faut retirer mes investissements du S&P 500 en prévision de la bulle IA
  • Si on peut confier même la réponse aux incidents à un LLM, alors autant laisser le CEO faire comme il veut et assumer aussi les dégâts de réputation qui en découleront. Et si ça échoue, on pourra toujours faire revenir git à l’état d’avant le code écrit par le LLM. Je plaisante à moitié
  • Le niveau actuel de l’IA n’est pas encore suffisant pour remplacer les développeurs, mais je pense qu’elle est déjà assez bonne pour automatiser beaucoup de travail de bureau et même certains rôles de managers qui étaient auparavant difficiles à automatiser. Google a effectivement beaucoup réduit son middle management à cause de l’IA, sans semble-t-il réduire les développeurs dans les mêmes proportions
  • L’IA sert d’excuse aux managers qui manquent de leadership technique pour mettre la pression sur les développeurs

• Plusieurs choses peuvent être vraies en même temps. Les LLM ne multiplient pas par 10 la productivité des développeurs sur des tâches générales choisies au hasard. En revanche, sur certaines catégories de tâches, ils augmentent la productivité de façon spectaculaire. On peut aussi s’en servir pour automatiser des tâches répétitives chronophages : même si cela prend plus de temps réel qu’un humain, ce n’est pas gênant puisque ça tourne en arrière-plan. Les LLM accélèrent énormément l’apprentissage d’une nouvelle API ou d’une nouvelle bibliothèque, et quand il faut écrire un petit morceau de glue code dans un langage inconnu, ils font gagner du temps et évitent un apprentissage inutile, ce qui aide énormément. En revanche, je ne ressens presque aucun gain de productivité sur la maintenance de gros codebases existants. Pour mettre en place le scaffolding d’un nouveau site web, les LLM sont étonnamment bons. Ils écrivent aussi très vite des classes mock et savent utiliser des bibliothèques de mock pour des tâches compliquées que je fais deux fois puis oublie aussitôt. Pour comprendre la structure d’un nouveau codebase, ils me satisfont à environ 70 %. Même dans des projets à l’architecture complexe, pour retrouver l’emplacement de routes HTTP ou de fonctions d’injection de dépendances, c’est pratique de demander un truc du style « hé Claude, elles sont où les fonctions liées à l’auth ? ». Il faut utiliser le bon outil pour la bonne tâche

  • Je suis d’accord avec l’idée que les LLM rendent l’apprentissage de nouvelles API ou bibliothèques beaucoup plus rapide, mais ce qui m’inquiète, c’est qu’en examinant leurs réponses puis en lisant la documentation soi-même, on voit qu’ils ne respectent parfois pas les conventions, bricolent des exemples simplistes, utilisent de mauvaises fonctionnalités, ou choisissent des approches bancales ou inutilement complexes. Ça paraît magique, mais si on leur fait trop confiance, on peut facilement se convaincre à tort qu’on a réellement compris
  • J’aimerais savoir concrètement ce que signifie « le LLM automatise des tâches répétitives chronophages en arrière-plan ». Je pense que les défenseurs de l’IA devraient donner des exemples clairs et précis des tâches où cela fonctionne réellement. Je me fatigue de plus en plus du flou ambiant
  • Pour que l’expression « les LLM aident à apprendre rapidement de nouvelles API et bibliothèques » soit plus juste, il faudrait peut-être la remplacer par « lorsqu’on découvre pour la première fois des bibliothèques ou des API déjà anciennes ». Pour les bibliothèques ou outils vraiment nouveaux, les LLM sont souvent de peu d’aide

• La plupart du temps, il n’y a rien de plus qu’un écran rempli de code qui défile dans une vidéo, accompagné d’un discours du type « les développeurs juniors sont finis ». À mon avis, cela vient d’un climat d’instabilité économique saturé d’exagération et d’angoisse, où l’on espère que l’IA sera le sauveur. Il arrive bien sûr d’obtenir des résultats impressionnants avec l’IA, mais au fond cela n’a de sens que pour quelqu’un qui a déjà un certain niveau. Les débutants à intermédiaires inondent les réseaux sociaux de récits de réussite exagérés. Une ambiance s’est installée où chacun essaie, psychologiquement et concrètement, de préserver son « super-pouvoir IA ». Au final, il ne reste qu’à attendre que le cycle de hype retrouve un point d’équilibre et que quelques dizaines de milliards de dollars soient de nouveau brûlés

  • D’après mon expérience, les outils IA donnent vraiment le meilleur d’eux-mêmes sur un projet entièrement vierge, une blank canvas. Par exemple, pour créer un nouveau projet React, l’outil me fait la mise en place plus vite que moi. Mais dans un vrai repo de travail, c’est presque inutile. C’est pour ça que ces outils font une énorme impression en démo et en promo, puis déçoivent dans la réalité
  • Je me demande s’il faut être « quelqu’un d’assez expérimenté pour pouvoir vraiment le faire soi-même à la main », ou plutôt quelqu’un habitué aux outils IA et à leurs limites, ou bien s’il faut les deux
  • La plupart des discours exagérés sur l’IA ressemblent à des articles de vulgarisation scientifique grand public qui n’ont lu qu’un abstract d’article de recherche sans profondeur et annoncent que tout cela va bientôt devenir réalité

• D’après mon expérience, l’IA a été utile pour certaines petites tâches (par exemple de petits refactorings, l’automatisation de définitions de types, etc.), mais sur des tâches plus complexes, elle oubliait trop de choses et il fallait tout retravailler. Peut-être qu’à l’avenir je reverrai mon jugement, mais récemment j’ai vu de plus en plus d’ingénieurs moins expérimentés accepter sans esprit critique comme du « bon code » ce que l’IA leur produit pour implémenter de grosses fonctionnalités. Or ce code ne respecte ni notre guide de style ni nos patterns, ou bien réimplémente de zéro une logique qui existe déjà dans une bibliothèque, ce qui augmente au final la quantité de code que nous devons maintenir nous-mêmes. Et plus tard, on voit apparaître d’énormes PR qui essaient de tout faire d’un coup

  • Pour du code purement nouveau, je pense souvent qu’il est plus judicieux de l’écrire soi-même plutôt que de tirer une grosse bibliothèque pour à peine 50 lignes de code. Sur ce point, c’est positif
  • La « découverte » de ces codes et bibliothèques reste un devoir à faire, et nous étudions aussi une manière pour que les membres de l’équipe puissent exploiter de façon autonome le code interne en s’appuyant sur la documentation ou la recherche elle-même via un LLM. La concentration du savoir sur les bibliothèques internes est un vrai sujet de préoccupation
  • Au stade initial du développement, c’est différent. Au début d’un projet, quand il n’y a pas encore de style de code ni de standards, ce que produit un LLM n’est pas très différent de ce que proposent les membres de l’équipe. Il y a de la valeur à produire du code ne serait-ce que jusqu’au stade de la démo. Pouvoir amener rapidement plusieurs projets à ce stade représente un vrai boost

• Je suis d’accord avec ce qui est avancé ici. Même avec l’IA, je n’ai pas constaté de bond révolutionnaire de productivité. Je pense que si un ingénieur logiciel ne continue pas à pratiquer régulièrement la résolution de problèmes, le discernement et la mise en code, ses connaissances neuronales peuvent s’affaiblir. La promesse que l’IA serait la technologie qui apportera demain un gain de productivité de x2 ou x10 n’a pas vraiment de substance, et même s’il y a eu une légère hausse de productivité sur des codebases individuels, on n’a pas vu sur le marché une multiplication réelle des meilleurs lancements de produits. En tant que consultant, je vois souvent des fondateurs ou des CTO pousser l’IA au point de ne plus vraiment contrôler leur code et de créer encore plus de désordre. Aujourd’hui, il m’arrive même souvent d’endosser un rôle de conseiller pour aider à mettre en place de bonnes pratiques d’ingénierie

  • Comme pour la plupart des techniques, quand la pratique et l’entraînement s’interrompent, les réflexes s’émoussent. Comme lorsqu’on n’a pas fait de vélo depuis longtemps et que le corps rouille un peu, les capacités de programmation s’affaiblissent aussi en pratique. Je crois que cela vaut également pour l’ingénierie IT. C’est réellement un signal à surveiller

• Des CEO affirment que l’IA multiplie par 10 la productivité des développeurs existants, mais si c’était vrai, on devrait plutôt embaucher bien plus de développeurs, non ? Si, à investissement égal, la productivité est multipliée par 10, il serait logique d’injecter massivement de l’argent dans ce « moteur ». Pourtant, sur le terrain, on a plutôt l’impression que la productivité n’a pas bougé et que seul le coût du travail a été réduit

  • Quand les marges baissent, j’ai l’impression qu’on finit toujours par chercher de la valeur dans les coûts salariaux. L’attrait de l’IA est à 99 % la réduction des coûts de main-d’œuvre, et embaucher va à l’encontre de cela. Je ne suis pas non plus d’accord avec les affirmations sur les gains de productivité de l’IA, mais je voulais souligner cet aspect de motivation
  • On dirait que beaucoup de dirigeants C-level espèrent remplacer aussi le personnel restant par l’IA. Ils suivent le récit selon lequel « l’AGI arrive bientôt ». Je n’y crois pas, mais si on adopte cette position, je comprends aussi la logique qui consiste à ne pas recruter davantage de développeurs
  • Je sens que je vais apprendre aujourd’hui ce qu’est la « loi des rendements décroissants ». Il existe une limite au nombre d’êtres humains et de ressources qu’une organisation peut absorber. Au-delà d’un certain point, ajouter plus ne sert à rien. S’il y a plus de licenciements, c’est parce que l’IA améliore l’efficacité : si l’IA couvre la quantité de travail auparavant assurée par une personne, l’emploi diminue d’autant. Ce n’est pas une logique un humain = une IA, c’est une structure où le volume de travail bascule vers l’IA et réduit le besoin en humains. Le remplacement complet n’est pas encore terminé, mais la question de combien d’humains sont nécessaires deviendra un nouveau critère d’offre et de demande. On aura toujours besoin de davantage de talents créatifs, mais ils manquent. Parmi les ingénieurs logiciels qui veulent des salaires de 100 000 à 200 000 dollars, beaucoup ne savent même pas combien ils peuvent faire économiser à l’entreprise. J’ai aussi l’impression que l’école a tué la créativité. Le problème n’est pas tant un manque de compétences qu’un manque de capacité à se donner soi-même une direction ou à produire des idées

• Cette analyse qui regarde le volume de lancements de nouveaux produits sous un angle original est impressionnante. J’ai eu le sentiment qu’au lieu d’une croissance rapide, il n’y avait pas autant de changement qu’on l’aurait cru. Une autre interprétation possible serait qu’en réalité l’écriture du code n’était pas le goulot d’étranglement du lancement produit, et qu’explorer ce qu’il faut construire puis le mettre réellement sur une plateforme prend déjà énormément de temps et d’efforts. Je suis aussi d’accord sur le fait qu’il est trop facile de mal utiliser les outils IA. Parfois on se dit « ça y est, j’ai enfin compris ! », puis le lendemain on réalise « ah non, je l’utilisais encore mal, mais autrement ». Même après plus de 20 ans de développement, je ne comprends toujours pas clairement pourquoi le développement logiciel est si difficile et pourquoi il est si dur d’accélérer réellement la productivité

  • L’idée que « l’écriture du code n’était pas le goulot d’étranglement » me parle vraiment. La vraie valeur dans le logiciel vient de la résolution des « problèmes difficiles », tandis que les problèmes faciles existent déjà partout sous forme de templates. Les LLM règlent vite les problèmes faciles, mais le vrai goulot d’étranglement reste les problèmes réellement « hard ». Pour des raisons techniques, business ou liées au client, ces problèmes difficiles ne se résolvent pas correctement avec des LLM, alors que c’est précisément là que se situe le vrai gain. En revanche, pour les problèmes faciles qui se prêtent à la templatisation, les LLM augmentent vraiment la productivité
  • Dans la livraison logicielle, le codage lui-même n’a jamais été le goulot d’étranglement. L’IA ne sert qu’à justifier les réductions d’effectifs ou à donner un prétexte pour lever des fonds
  • Dans le développement produit, les processus qui demandent du temps — retours utilisateurs itératifs, correction des cas limites, etc. — restent difficiles à raccourcir, même avec l’IA. Cela rejoint aussi le texte de joelonsoftware.com qui dit qu’un bon logiciel prend dix ans

• Nous sommes en train de construire cet avenir maintenant. En pratique, je n’ai commencé à vraiment prendre de la vitesse qu’à partir d’avril-mai, quand l’agentic AI est devenue suffisamment bonne. Rien qu’aujourd’hui, j’ai créé un outil CLI qui exporte des archives iMessage vers un site web, et quelque chose qui m’aurait pris des semaines auparavant pourrait maintenant sans doute être fait en un ou deux jours, jusqu’à la formula homebrew comprise. Je travaille aussi sur une app iOS qui avance bien plus vite qu’en codage manuel, même si je fais exprès de ralentir. À noter que les données du billet d’origine s’arrêtent en mars-avril, et je pense que c’est justement à partir de ce moment que la generative AI a commencé à être réellement utile pour coder. (J’utilise Copilot depuis novembre 2022)

  • Ce qui me surprend dans ce genre de débat, c’est qu’à chaque fois la réaction revient à « tu n’as juste pas encore essayé la toute dernière IA, cette fois ça marche vraiment »
  • Mon expérience est presque identique. J’ai embarqué tard dans la hype IA, mais l’essai des nouveaux modèles et des nouveaux outils récemment sortis m’a fait changer d’avis. Autour de moi, les grandes entreprises ne commencent qu’à présent à autoriser l’usage de ces outils, donc je m’attends à ce qu’il y ait un décalage assez important dans les données réelles de productivité et que leur effet n’apparaisse que plus tard. J’ai aussi quelques regrets sur l’étude du METR, et j’aimerais voir davantage de méta-études sur cette productivité
  • Je suis d’accord. L’agentic AI est un outil complètement différent de l’IA « traditionnelle ». J’attends avec beaucoup d’intérêt de voir ce que donneront les données et les expériences de l’auteur d’ici un an
  • Le moment où l’on dit « l’IA est enfin devenue rapide », et qu’on parle en fait d’il y a à peine 5 mois. À la vitesse de l’IA, 5 mois donnent l’impression de correspondre à 6 ans de changements

• J’ai été développeur à plein temps, puis en travaillant ensuite comme manager puis CTO, je me suis peu à peu éloigné de la pratique du développement. Quand j’ai voulu me remettre à coder, devoir réapprendre les frameworks, les API, les langages et toutes les petites astuces, qui autrefois m’amusaient, est devenu une corvée. Mais grâce à des outils comme Claude Code et à mon expérience en conception logicielle, il est redevenu possible pour moi de développer à nouveau de gros systèmes. Ma productivité n’a pas augmenté de 20 %, ni été multipliée par 10. Comme cela m’a remis à faire des choses que je n’avais de toute façon pas l’intention de faire, j’ai envie de parler d’une hausse de productivité infinie. Si j’étais un développeur passionné et très compétent, ces outils ne seraient sans doute qu’une gêne, mais pour quelqu’un qui ne développe pas habituellement, c’est exactement l’inverse

  • Waouh, reconstruire de gros systèmes non pas une seule fois mais plusieurs, j’aimerais bien que tu partages des cas concrets en détail
  • Ma grande théorie sur les outils de coding IA, c’est qu’ils ne réduisent pas tant que ça le temps réel, mais diminuent énormément l’irritation. Ils économisent l’agacement inutile lié à la syntaxe, au compilateur et aux tâches répétitives, ce qui permet de concentrer son attention sur ce qui compte vraiment. Du coup, des choses qu’on n’aurait pas faites auparavant parce que c’était trop pénible, on finit maintenant par les faire, et au lieu d’aller se promener avant la fin de la journée, on peut rester quelques heures de plus au bureau