- Il existe des développeurs qui ont du mal à créer une valeur claire en utilisant des LLM de codage
- Certains utilisateurs ne sont pas satisfaits de la qualité des sorties des LLM
- Sur des exigences précises ou des problèmes complexes, les LLM ont tendance à ne pas être à la hauteur des attentes
- En revanche, ils apportent un certain confort pour des automatisations simples ou des tâches répétitives
- Les développeurs cherchent des moyens d'améliorer leur prompt engineering ou leurs workflows
Discussion sur les difficultés d'utilisation des LLM de codage et les moyens de les améliorer
Valeur limitée des LLM
- Ces derniers temps, de nombreux développeurs expérimentent les LLM de codage comme ChatGPT, GitHub Copilot, Claude, etc., pour divers usages
- Mais une part importante des utilisateurs ne constate pas le gain réel de productivité qu'ils attendaient
- En particulier, pour l'écriture d'algorithmes complexes, la structuration de grands ensembles de code ou la conception de l'architecture d'un projet, le code recommandé par les LLM est souvent fragmentaire ou inefficace
Mécontentement sur la qualité des sorties
- Certains développeurs estiment que le code fourni par les LLM contient des bugs ou produit des résultats inexacts faute de bien comprendre le contexte
- Il arrive fréquemment que les explications ou les analyses soient insuffisantes, ou que le code ne reflète pas correctement la complexité et le contexte du projet
Une aide sur des usages simples
- Pour la génération de courts snippets de code, les tâches répétitives ou la résolution de simples problèmes de syntaxe, on constate clairement une utilité du côté de l'automatisation de base
- Leur usage pour des tâches routinières comme les tests unitaires, le refactoring ou les corrections de style de code est plutôt bien évalué
Tentatives d'amélioration
- Certains développeurs appliquent activement des techniques de prompt engineering pour obtenir de meilleurs résultats
- Ils expérimentent des façons d'utiliser les LLM adaptées à leur propre workflow, ainsi que des combinaisons avec divers outils open source
Conclusion et enseignements
- À ce stade, il est admis que les LLM ne peuvent pas constituer une solution universelle à tous les besoins des développeurs
- La communauté et les développeurs partagent leurs expériences tout en cherchant des stratégies d'utilisation efficaces et des moyens de dépasser ces limites
1 commentaires
Commentaires Hacker News
J’ai l’impression qu’il existe deux catégories de développeurs. D’un côté, ceux qui disent que les LLM sont un superpouvoir absolu pour coder et que leur productivité a été multipliée par 100 ; de l’autre, ceux qui les voient comme des outils assez capricieux, qui demandent beaucoup de travail et d’efforts pour obtenir au final des résultats simplement corrects. Mais si les LLM augmentaient vraiment la productivité de façon révolutionnaire pour le premier groupe, on pourrait se demander si ces gens ne devraient pas déjà dominer tout le marché et balayer la concurrence
Sur du greenfield, j’ai vraiment l’impression que ma productivité peut être multipliée par 100 grâce aux LLM. Par exemple, ils peuvent générer en quelques minutes toute l’ossature de base d’une app React avec plusieurs pages, un store Redux, l’authentification, etc. Si je dis « ajoute maintenant X », j’obtiens en général un bon résultat. En revanche, pour la maintenance de systèmes existants, l’ajout de fonctionnalités complexes ou les cas où la connaissance métier est essentielle, les LLM sont peu utiles. C’est bien pour l’autocomplétion ou pour compléter une fonction, mais dès qu’il faut implémenter une fonctionnalité complète, on atteint vite leurs limites. Dans ces cas-là, le temps passé à piloter le LLM est à peu près équivalent à celui qu’il me faudrait pour coder moi-même. Du coup, je commence souvent par écrire du code squelette dans la structure que je veux, puis je laisse le LLM remplir les blancs. Ceux qui parlent de productivité multipliée par 100 n’ont probablement encore rencontré que les parties faciles, ou n’ont pas encore buté sur les difficultés. En pratique, 90 % du travail est facile, et les 10 % restants sont les vrais durs, et c’est justement là que les LLM n’y arrivent pas
C’est un peu sarcastique, mais ceux qui parlent de productivité x100 sont en fait en train de multiplier un petit chiffre par 100. Les LLM sont incroyablement utiles à l’étape de recherche. Par exemple, j’ai récemment dû écrire explicitement du code d’algèbre linéaire spécialisé pour un certain domaine, sans pouvoir utiliser une bibliothèque comme LAPACK, donc j’ai dû l’implémenter moi-même. Dans ce genre de situation, utiliser un LLM comme ouvrage de référence plutôt qu’un manuel permet d’obtenir d’un coup les informations voulues, et là, le temps de recherche peut vraiment être divisé par 100. Mais quand j’ai laissé le LLM écrire le code, il a introduit des erreurs subtiles qu’un non-expert aurait du mal à repérer. Un junior aurait pu les laisser passer. Comme j’accorde de l’importance à la review de code, je ne pense pas que la vitesse pure d’écriture du code augmente énormément, même si les LLM s’améliorent. En revanche, pour l’exploration et la synthèse qui servent à décider quel code écrire, ils accélèrent énormément les choses. Au final, la vraie valeur dans le monde vient de l’innovation et des idées créatives, et je pense que cela reste du ressort des humains. Les LLM seront des assistants importants, mais je crois que le code à forte valeur ajoutée doit encore être écrit directement par nous
En réalité, il est possible de n’appartenir à aucun de ces deux groupes. Ce n’est pas x100, mais ce n’est pas non plus pénible à utiliser. Je code professionnellement depuis plus de 30 ans, et j’ai toujours dû aller chercher des infos ; j’oublie souvent des langages ou des syntaxes spécifiques. Beaucoup de métiers demandent aussi d’alterner entre plusieurs langages. Avant, il fallait sans cesse fouiller dans des livres de référence, des manuels, voire des ressources encore plus pénibles. Avec l’arrivée de moteurs de recherche comme Google, c’est devenu un peu mieux, puis des plateformes comme Stack Overflow ont encore gagné en efficacité. Aujourd’hui, les LLM représentent simplement une nouvelle étape. Les suggestions d’autocomplétion me donnent parfois exactement l’indice que je cherchais. Bien sûr, j’ignore ce qui ne sert à rien, mais j’aime le fait que l’interface de chat permette de poser des questions de manière bien plus conversationnelle qu’avec Google ou une recherche sur SO
J’étudie les maths avec Math Academy, ChatGPT et YouTube, surtout 3Blue1Brown. Sans cette combinaison, ce serait pénible ; maintenant, c’est agréable. Quand j’avais suivi un cursus similaire à l’University of Amsterdam, c’était bien plus difficile, car ChatGPT n’était pas aussi intelligent qu’aujourd’hui. ChatGPT répond même à des questions auxquelles un professeur aurait du mal à répondre, et cela me convient très bien, car pour apprécier un sujet et résoudre des problèmes de manière créative, j’ai besoin d’en comprendre aussi le contexte culturel. Par exemple, j’ai demandé pourquoi on utilise le m pour les angles, et il m’a expliqué que cela venait historiquement de measure. Du coup, je peux à nouveau me concentrer sur les maths elles-mêmes. Il m’a aussi expliqué simplement la formule rapide de calcul de variance. Ce n’est pas un moyen de dominer le monde, mais cela me permet d’apprendre des connaissances que je n’aurais peut-être jamais acquises autrement. Bien sûr, YouTube et Math Academy jouent aussi un grand rôle
Les LLM donnent un superpouvoir à ceux qui touchent à beaucoup de domaines sans être experts partout. Si l’on ne creuse qu’un seul domaine très en profondeur et qu’on travaille toujours uniquement là-dessus, ils sont moins utiles. Par exemple, écrire un Dockerfile avec un LLM, quand on n’a pas de spécialiste du déploiement parce que ce besoin n’arrive qu’une fois par projet, c’est vraiment excellent. On peut aussi résoudre de petites erreurs de syntaxe ou des problèmes mineurs plus vite qu’avec Google. Faire analyser par un LLM des trade-offs d’architecture, puis prendre soi-même la décision finale, aide aussi à gagner en productivité. En revanche, il faut bien cadrer le périmètre dans le prompt pour éviter qu’il fasse n’importe quoi, et comme il invente souvent des API qui n’existent pas, il faut aussi corriger de manière itérative. Malgré cela, même avec ces allers-retours, il reste un gain de vitesse
Moi aussi, j’utilise les LLM de différentes façons. Ils m’aident pour de petits problèmes de debug, des scripts shell, du code, des questions, etc. Pour un usage personnel, j’essaie différents outils comme Claude, OpenAI, Google ou Perplexity et je choisis celui qui donne le meilleur résultat. Au travail, j’utilise Claude, OpenAI et Google via Copilot dans VSCode ou via une plateforme interne, et j’ai aussi un peu expérimenté Copilot Studio. Je travaille comme ça depuis plus d’un an et demi ; je n’ai pas utilisé tous les outils en continu, mais mon impression générale est la suivante. Oui, les LLM ont clairement amélioré ma productivité. J’ai pu expérimenter dans plusieurs langages et mieux comprendre divers sujets, donc certaines tâches sont nettement plus faciles. Mais quel que soit le modèle ou sa version, dès que le travail devient complexe, sort des sentiers battus ou dépasse la simple combinaison d’éléments, ils échouent tous. Il arrive même que le temps passé à réparer les absurdités produites par un LLM annule complètement le temps gagné au départ. Ma conclusion honnête, pour l’instant, c’est que les LLM sont utiles pour la petite autocomplétion de code, le debug et les explications, mais pas beaucoup plus. Ils ne menacent pas encore nos emplois à court terme
Les LLM m’aident énormément quand j’apprends une nouvelle bibliothèque, API ou un nouveau langage. Par exemple, pour savoir comment faire du rendu de texte avec OpenGL, demander directement à un LLM est bien plus rapide que de se farcir une documentation officielle énorme et mal fichue. Ils sont aussi utiles pour écrire du boilerplate répétitif et ennuyeux lorsqu’il n’existe pas de code de référence dans l’existant. Mais dans la partie vraiment « travail », c’est-à-dire le code spécifique à mon service, je n’utilise pas beaucoup les LLM au sens de « les laisser écrire le code à ma place ». En tant qu’ingénieur senior, je passe presque pas de temps à coder réellement ; ce qui compte, c’est la conception de structure, le refactoring legacy, les problèmes de performance, le debug de bugs rares, etc. Comme les LLM n’accélèrent que l’écriture de code répétitif, leur utilité reste limitée sauf si l’on recommence un nouveau projet depuis zéro chaque semaine. Si vous écrivez encore énormément de boilerplate, il faudrait peut-être réfléchir à d’autres solutions plus fondamentales au lieu de dépendre seulement des LLM
Pour lire de la documentation officielle illisible et l’expliquer, les LLM sont clairement bien meilleurs qu’un programmeur moyen. Sur ce point, ils apportent une valeur réelle. Et il y a aussi des langages qui imposent énormément de boilerplate
Il n’existe pas de silver bullet, et la conceptualisation reste la partie vraiment difficile. The Mythical Man-Month est un texte important, il faut vraiment le lire davantage
Il n’y a pas de silver bullet. C’est fascinant qu’on oublie sans cesse les conseils simples de Fred Brooks. Si on n’exagère pas les attentes et qu’on utilise les LLM en comprenant qu’ils contiennent forcément des bugs, puisque leur jeu d’entraînement contient beaucoup de code bogué, ils deviennent bien plus utiles. Il ne faut pas leur déléguer la conception ; mieux vaut faire soi-même le travail préparatoire, comme découper les fonctions, puis les utiliser pour réduire la corvée dans les tâches ennuyeuses ou les domaines peu familiers. Mais même pour du code généré par LLM, si l’on veut en assumer la responsabilité, il faut impérativement disposer des connaissances et de la validation nécessaires. Même si le code d’un LLM semble parfait, il peut cacher des défauts ; il faut donc continuer à étudier, à progresser, et garder un esprit critique. Il ne faut jamais lui faire une confiance aveugle
Il est clair que quand la taille du problème augmente, les LLM deviennent inutiles. Ils excellent sur les tâches répétitives ou les opérations complexes de find & replace. Pour du code quotidien, clair et routinier, comme remplir des méthodes CRUD pour des ressources API, ils sont très utiles. Récemment, j’ai même demandé à Claude Opus 4 de relire mes patchs ; il détecte parfois des erreurs et me rappelle aussi ce que je devrais faire. Mais une fois un certain seuil de complexité dépassé, leur utilité s’effondre brutalement. Par exemple, s’il faut faire des modifications réparties sur plusieurs fichiers relativement volumineux, on en vient déjà naturellement à raisonner soi-même sur les fichiers à modifier. Malgré tout, les utiliser comme « rubber duck » reste très correct. Si l’IA réussit, tant mieux ; sinon, je reprends tout de suite la main. En pratique, les LLM ne m’aident qu’au démarrage, et l’essentiel des corrections est de toute façon quelque chose que je devais faire moi-même. Leur faire poser l’ossature, puis retoucher selon mes besoins, semble plus simple que de partir totalement de zéro. Quand un LLM montre clairement qu’il galère, je n’insiste pas. Si le problème vient d’une spécification ambiguë et qu’il a mal deviné, je le lui signale ; s’il n’y arrive toujours pas, je termine moi-même
Mon expérience est similaire. J’ai trouvé de la valeur dans les LLM sur les points suivants. Ils produisent très bien des composants ou pages React assez indépendants, surtout avec une bibliothèque UI populaire. Ils génèrent aussi des fonctions pures bien définies avec une fiabilité correcte, et c’est facile à vérifier. Le boilerplate des frameworks connus, ils le font vraiment facilement et correctement. En revanche, autour de moi, les gens se vantent d’expériences end-to-end incroyables, alors que moi, ça ne se passe jamais comme ça, et ça me rend presque fou. Au quotidien, même avec beaucoup d’efforts, les LLM s’effondrent complètement dès qu’on leur confie une fonctionnalité complète. Avec des outils comme aider, ils n’arrivaient même pas à créer une simple fonctionnalité d’e-mail template dans Next.js ; si je découpais la tâche en plus petits morceaux, ça allait un peu mieux, mais le code existant se dégradait de plus en plus. Même quand j’expliquais le problème, plus je promptais, plus ça devenait bizarre. J’ai fini par essayer de corriger à la main, mais le code était devenu totalement chaotique
Des amis vibe coders m’ont déjà dit que « mes critères sont trop élevés ». À mes yeux, les vibe coders ne relisent pas vraiment le code, donc ils n’ont pas de standard de qualité. Si le vibe coding fonctionnait vraiment, des endroits comme Google AI amélioreraient déjà leurs produits à une vitesse écrasante, avec leurs énormes budgets GPU, TPU et les modèles d’IA les plus récents. Si cela arrivait réellement, nous ne le découvririons pas d’abord parce que notre travail deviendrait progressivement plus facile, mais plutôt parce qu’une nouvelle énorme et inattendue ferait la une ; et ce n’est que bien plus tard que nous apprendrions que l’IA en était la cause
Les LLM sont bons pour le code jetable. Ils ne rendent pas nécessairement le développement, la maintenance, le debug ou la correction faciles. Comme la plupart du code est en pratique du code « consommable » plutôt qu’un vrai produit, cela leur convient bien. Même si on veut appliquer des concepts comme la restauration rapide, l’usine d’assemblage ou la production automatisée, il y a une différence énorme. Dans une usine, les objets produits par des machines sont fiables parce qu’ils sont fabriqués correctement à 99,99 % ou plus. Mais avec un LLM, je dois vérifier chaque étape moi-même, et si je ne le fais pas, ça ne fonctionne tout simplement pas. Il est impossible qu’un LLM résolve avec succès un problème de manière entièrement autonome, sans surveillance, 24h/24. C’est pour cela qu’il ne nous prend pas encore nos emplois
Je ne songerais jamais à confier à un LLM l’intégralité d’un problème complexe pour récupérer simplement le résultat final. Ce n’est pas là sa force. Sa vraie valeur, c’est de donner des « indices » pour faire avancer le travail et de permettre de sauter des parties simples mais chronophages. Il y a quelques jours, je devais construire une chaîne de log, et le LLM m’a immédiatement proposé un format de code plus élégant que ce que j’avais en tête ; un travail qui m’aurait pris 15 minutes a été réglé brillamment en 30 secondes. Ce sont ces petits gains qui s’accumulent et créent de la valeur
notepad.exe. Pour un langage comme Lisp, simple mais puissant, le surlignage des parenthèses est indispensable. Quand on repense aux 10 ou 20 dernières années, on voit des évolutions selon les langages. Java, C# et C++ ont beaucoup emprunté aux langages fonctionnels ; sur la JVM, il y a Clojure ; Go s’obstine avec une syntaxe du genreif err != nil. Rust a ajouté?, Zig est similaire. Python devient de plus en plus long et complexe avec les annotations de type, etc. Les auto-formatters sont vraiment pratiques, car on n’a plus à se soucier de l’indentation, même si Python reste imparfait à cause de sa sensibilité aux espaces. Les outils aident les langages verbeux, et les langages expressifs aident à produire du code concis. On passe bien plus de temps à lire du code qu’à en écrire. Les outils déterministes sont forts sur la structure du code, tandis que les outils probabilistes comme les LLM sont meilleurs pour approcher l’intention. Les modèles de langage sont une évolution des outils d’automatisation et, comme l’autocomplétion, ils continueront à s’améliorer, mais ils ne pourront pas « résoudre complètement » le codage. Il n’y a pas de vérité absolue ici, seulement des différences d’opinion