Coder avec des LLM (été 2025)
(antirez.com)- Mise à jour du retour d’expérience du développeur de Redis, antirez sur l’usage des LLM
- Des LLM de pointe comme Gemini 2.5 PRO et Claude Opus 4 renforcent les capacités des développeurs
- Les LLM peuvent améliorer l’efficacité du travail de multiples façons : suppression de bugs, test d’idées, élargissement des connaissances
- Ils permettent aussi de prendre facilement en main des domaines non spécialisés ou de nouvelles technologies avec l’aide d’un LLM
- Cependant, pour la qualité globale du code et sa maintenabilité, la collaboration « humain + LLM » reste essentielle
- Pour tirer le meilleur parti des LLM, il est crucial de fournir un contexte suffisant et une communication claire
Évolution du développement avec les LLM et points clés
Les LLM de pointe (Gemini 2.5 PRO, Claude Opus 4, etc.) jouent un rôle d’extension des capacités des programmeurs grâce à leur vaste compréhension et à leur aptitude à traiter de grandes quantités de code
- Si l’on sait décrire clairement un problème et communiquer de manière itérative
- il devient possible d’éliminer des bugs avant la mise en production (par exemple, dans le cas de l’implémentation de Vector Sets dans Redis, des bugs ont été immédiatement supprimés via la revue de code de Gemini/Claude)
- on peut tester rapidement si une idée fonctionne, écrire du code expérimental et en évaluer les performances
- un pair-design fondé sur l’expérience et l’intuition devient possible, en combinant la richesse des connaissances spécialisées du LLM et l’intuition humaine
- en donnant des consignes claires au LLM, certaines parties de l’implémentation peuvent être réalisées rapidement
- il devient possible de s’adapter vite à des domaines peu familiers (par exemple du code assembleur 68000 pour Amiga)
Dans l’ancien article « LLMs et la programmation début 2024 », l’utilité des LLM était déjà mentionnée, mais au cours des 18 derniers mois, les LLM ont progressé de façon spectaculaire
Pour en tirer le meilleur, humains et LLM doivent chacun disposer de certaines compétences et habitudes, d’où l’importance de principes clairs
Limites du vibe coding et principes de collaboration humain + LLM
Aujourd’hui, les LLM sont excellents comme amplificateurs des capacités des développeurs, mais ils ne sont pas encore au niveau où ils pourraient gérer seuls, de façon autonome, l’ensemble du travail
- Pour des projets ponctuels et de petite taille, comme des tests ou de petits utilitaires, un design produit uniquement par un LLM peut fonctionner
- En revanche, pour des projets d’envergure ou atypiques, l’usage d’un LLM seul risque fortement d’entraîner complexité, code inutile et fragilités structurelles
- La collaboration entre LLM et humain apporte le plus fort gain de productivité, à condition d’avoir une communication efficace et de l’expérience dans la gestion des LLM
- Il ne faut pas confier les tâches complexes au seul LLM : une intervention humaine active tout au long du processus reste nécessaire
L’importance de fournir un contexte suffisant au LLM
Pour qu’un LLM comprenne correctement la direction du développement ou de la résolution d’un problème, il est indispensable de lui fournir des informations de contexte étendues
- Il est préférable de fournir des articles scientifiques, la base de code concernée (si possible dans sa totalité), ainsi que l’intention du travail
- Cela inclut des informations essentielles comme l’objectif de l’implémentation, les approches inutiles ou fragiles, les idées centrales réalisables, les buts, les invariants et le style de code
- Par exemple, lorsqu’un LLM traite une technologie nouvelle qu’il ne connaît pas (comme les Redis vector sets), inclure le README dans le contexte permet d’obtenir immédiatement des réponses de niveau expert
Choix du LLM et méthode d’utilisation
Le LLM le plus connu ne produit pas nécessairement les meilleurs résultats en pratique
- Pour le code, Gemini 2.5 PRO et Claude Opus 4 sont particulièrement efficaces
- Gemini 2.5 PRO excelle dans la détection de bugs complexes et la résolution de problèmes
- Claude Opus 4 est très bon pour écrire du nouveau code et offre une excellente expérience utilisateur
- Alterner entre les deux modèles améliore la compréhension lors de conceptions complexes
- S’il ne fallait en choisir qu’un, la recommandation va à Gemini 2.5 PRO
- Conditions à respecter lors de l’usage d’un LLM
- il vaut mieux éviter les agents de code ou les agents intégrés dans les IDE
- il faut permettre au LLM de voir directement l’ensemble du contexte (code, documentation, etc.) afin d’obtenir les meilleures réponses
- l’usage de fonctions qui ne montrent qu’une partie du contexte, comme RAG (génération augmentée par récupération), entraîne une baisse de performance
- à chaque étape, l’humain doit copier/coller le code manuellement et suivre lui-même le déroulement
Conclusion – garder le contrôle reste essentiel
L’arrivée d’agents capables d’écrire seuls du code n’est probablement plus très loin, mais à l’heure actuelle, c’est encore une collaboration dirigée par l’humain avec le LLM qui produit le code le plus affûté
- Le rôle de l’humain, qui décide toujours de « quoi » faire et « comment » le faire, reste central
- L’usage des LLM permet de dépasser les limites de ses connaissances actuelles et de progresser en apprenant de nouvelles technologies ou de nouveaux concepts
- En gardant un contrôle direct sur le code, on peut préserver la cohérence de la conception et de l’implémentation, tout en minimisant l’incertitude liée aux erreurs du LLM
- Vérifier régulièrement les progrès des performances des agents est aussi une stratégie avisée
- À ce stade, éviter l’usage des LLM peut faire prendre du retard sur les changements en cours ; il est donc crucial d’adopter une approche équilibrée
1 commentaires
Commentaires sur Hacker News
Je trouve regrettable que des modèles LLM propriétaires comme Gemini 2.5 PRO ou Claude Opus 4 soient en train de devenir la norme ; je vois très positivement les progrès des LLM et leur puissance en tant qu’outils, mais j’ai du mal à comprendre pourquoi les développeurs, célèbres ou non, continuent de considérer comme acceptable de dépendre d’un service payant tiers pour programmer ; auparavant, on pouvait coder uniquement avec de l’open source et des outils gratuits ; j’ai peur que, d’ici quelques années, dépendre d’un LLM payant devienne aussi inconfortable à éviter qu’écrire du code aujourd’hui sans IDE ni vim ; les discours du genre « $200 par mois, ce n’est pas grand-chose » ne règlent pas le problème de fond
Les modèles ouverts qu’on peut faire tourner localement aujourd’hui sont encore insuffisants en qualité et, surtout, coûtent bien plus cher à exploiter ; le jour où il sera économiquement possible de faire tourner chez soi un modèle du niveau de Claude 4, beaucoup de gens essaieront ; pour l’instant, un modèle comme Kimi K2 tourne sur deux Mac Studio de 512GB, mais rien que le matériel coûte environ $20,000
Le modèle par abonnement donne d’abord l’impression d’offrir un rapport qualité-prix exceptionnel, mais peu à peu les prix montent et la qualité baisse, et on finit enfermé dans le service, un peu comme dans l’épisode « Common People » de Black Mirror
Personnellement, je pense qu’un futur où tous les développeurs seraient automatiquement soumis aux LLM payants a peu de chances de se produire ; à long terme, les gens finiront par comprendre que produire énormément de code est en soi un problème ; le code est une dette, et cette dette augmente à mesure que s’accumulent du code instable ou lent ; l’IA ne va pas disparaître, mais quand l’enthousiasme retombera un peu, on comprendra mieux où et comment l’utiliser ; je me demande aussi ce qui se passera quand les financements se tariront ; OpenAI et Anthropic ne sont pas rentables et ont besoin d’un flux continu de capitaux pour maintenir leur état actuel ; si l’évolution des LLM est déjà arrivée à peu près à son plafond, les investisseurs pourraient se retirer, et alors le coût d’usage pourrait grimper, voire le service disparaître complètement
En pratique, je ne pense pas que ce soit un gros problème ; s’il n’y a pas de vrai gain de productivité, il n’y a aucune raison de rester dépendant d’un service cher et peu agréable à utiliser ; les modèles ouverts progressent eux aussi régulièrement, donc si l’écart avec eux n’est pas grand, il n’y aura aucune raison de continuer ; si, au contraire, les LLM poursuivent une progression rapide, alors nous ne serons de toute façon plus compétitifs avec les méthodes actuelles et il faudra se reconvertir vers d’autres domaines ; en conclusion, je ne pense pas qu’il faille trop s’inquiéter ; j’ai aussi le sentiment que la valorisation des grandes entreprises de modèles est très largement surestimée
À propos de l’idée qu’on peut coder avec de l’open source et des outils gratuits : j’aimerais ajouter que JetBrains est une entreprise plus ancienne que beaucoup de mes collègues, et que les Visual Basic/C++/Studio de MS ont facilité le développement Windows, mais tout cela était payant
Je ne suis pas d’accord avec l’expression « PhD-level knowledge » ; un doctorat n’a pas pour but principal d’acquérir des connaissances existantes, mais d’apprendre à faire de la recherche ; c’est un point souvent mal compris dans les discussions sur l’IA, et parler de « connaissances de niveau doctorat » finit par devenir assez flou
Au-delà du fait qu’un PhD soit un apprentissage de la recherche, l’essentiel est aussi de savoir poser des questions ; un LLM ressemble davantage à un « travailleur paresseux doté d’un vaste savoir » : il n’explore pas des hypothèses en se posant lui-même des questions ; exemple concret : j’ai demandé à Claude Code (Max Pro) de commenter le nombre d’assertions d’un test, et cela a créé un bug fondé sur une hypothèse erronée du plan initial ; il a fallu que je lui ordonne de réécrire lui-même le plan pour qu’il trouve la cause et la corrige ; par exemple, si l’objet ORM avait une valeur
null, c’était parce qu’il n’y avait pas eu de refresh après le commit, et parce qu’un objet chargé dans une autre session DB était resté tel quel après la fin de cette sessionD’accord, il a des connaissances de niveau expert, mais il ne sait pas faire aussi bien que les humains ce dans quoi les humains excellent ; par exemple, un LLM peut écrire d’un coup un programme brillant du début à la fin, mais a plus de mal à l’améliorer de façon itérative
Même si l’on comprend qu’un PhD représente plus que des connaissances, le simple fait d’avoir un accès facile à ces connaissances a une valeur immense ; dans mon ancienne entreprise, sur des questions difficiles auxquelles seul un doctorant pouvait normalement répondre — pour simplifier, quelque chose comme « que se passe-t-il si l’on applique une tension dans une direction donnée à la frontière entre deux matériaux ? » — un LLM pouvait fournir une réponse assez utile
Une fois le doctorat obtenu, on ne se soucie pas davantage de la matière elle-même ; au final, l’important, c’est d’avoir appris à mener une recherche
Je pense que toute discussion sur le coding avec des LLM devrait obligatoirement préciser le domaine traité et le langage de programmation utilisé ; ces deux variables ont bien plus d’impact que la manière d’utiliser le LLM ; si quelqu’un aime ou déteste coder avec un LLM, il faut d’abord lui demander quel type de problème il a traité, puis essayer soi-même de résoudre ce problème avec l’IA pour bien comprendre sa position ; sinon, on retombe toujours dans des échanges stériles du type « c’est parce que tu l’utilises mal » ou « moi j’ai essayé, ce n’était pas terrible »
D’après mon expérience de plusieurs mois de travail très concentré sur l’agentic coding, je suis d’accord avec tout ce que dit le billet ; les LLM de pointe restent de loin les plus faciles à utiliser, mais j’espère que les modèles ouverts vont bientôt les rattraper ; on peut demander à un LLM de suggérer de nouvelles méthodes ou de proposer des approches qu’on connaît déjà ; parfois, il a tendance à compliquer les choses, donc il faut le détecter tôt ou lui demander de refactorer ; la situation changera encore à mesure que différents modèles sortiront ; tous les travaux n’ont pas forcément besoin d’un modèle de pointe ; pour des petites fonctionnalités ou des corrections de bugs simples, Copilot est déjà un point de départ assez correct ; j’aimerais que tout le monde profite de cette période de changement pour expérimenter et apprendre
J’ai utilisé la GitHub action de Claude sur une dizaine ou une vingtaine d’issues pour l’implémentation et la review de PR, et c’est littéralement du hit-or-miss ; je suis donc d’accord pour dire qu’il vaut mieux l’utiliser comme outil d’augmentation que comme automatisation aveugle ; sur de petites fonctionnalités ou de petits refactorings avec de bons tests, ça marche presque automatiquement ; lancé via une action, cela me permet de faire autre chose pendant ce temps, ce qui est un avantage (et c’est encore plus pratique si Claude rédige aussi l’issue) ; mais dès qu’on passe à une taille moyenne ou plus, on obtient souvent un code qui a l’air plausible mais qui, en réalité, ne fonctionne pas ; c’est peut-être ma faute parce que la couverture de tests est insuffisante, mais le problème revient clairement souvent ; même en rédigeant des issues plus détaillées ou en variant les prompts, les résultats restent décevants ; pour les gros chantiers, c’est évidemment encore plus difficile ; la review de PR est utile sur des tâches petites ou moyennes, mais produit aussi beaucoup de vérifications inutiles ; en conclusion, je pense que les LLM sont encore loin de coder seuls ; pour les petites tâches, le plus efficace reste de leur faire écrire l’issue et d’attendre la PR ; sur la plupart des tâches de taille moyenne, il me suffit en général de donner la direction à Claude et je n’ai presque plus à coder, donc la productivité augmente clairement ; j’ai aussi essayé Gemini, mais si on le laisse faire, le code part dans des directions imprévisibles ; on utilise aussi Copilot en interne pour la review de PR, mais l’effet est faible ; sur de grosses codebases, Gemini pourrait peut-être être plus utile
Contrairement à l’OP, après un mois d’exploration intensive du sujet, j’ai trouvé que Gemini 2.5 PRO et Opus 4 donnent de meilleurs résultats dans les discussions abstraites, comme l’architecture ; ensuite, il était plus efficace de confier l’implémentation du code à Sonnet ; 2.5 PRO et Opus tournent souvent autour de la bonne réponse et se corrigent eux-mêmes en boucle, tandis que Sonnet va plus directement au but, au prix d’instructions suffisamment détaillées
C’est tout à fait plausible ; en pratique, Sonnet/Opus 4 peuvent être plus puissants sur les meilleurs résultats, mais sont aussi, sur certains points, moins cohérents ou moins bien alignés que Sonnet 3.5v2 (qu’on appelle aussi 3.6), voire 3.7 ; en outre, un modèle est un objet complexe, et selon le domaine, un modèle qui « semble plus faible » peut mieux fonctionner ; l’environnement conversationnel (interactive) et l’environnement orienté agent reposent aussi sur des méthodes de reinforcement learning différentes, donc les performances du modèle varient selon la façon dont on l’utilise
Les statistiques internes montrent également qu’Opus et Gemini 2.5 pro performent moins bien que Sonnet 4 en environnement réel lien vers les statistiques
J’ai eu une expérience similaire ; j’utilise Gemini 2.5 Pro dans AI Studio pour valider ou affiner de grandes idées de conception, puis j’apporte les exigences dans Claude Code, qui code généralement cela proprement ; j’ai aussi essayé récemment Gemini CLI, mais son niveau en coding est très en dessous de Claude Code ; il y a beaucoup d’erreurs de syntaxe, il n’arrive pas à sortir des boucles, et les résultats sont verbeux au point d’être difficiles à suivre malgré leur rapidité ; à l’inverse, Claude Code est excellent en débogage ; pour les problèmes de « big picture », DeepSeek R1 vaut aussi le détour : c’est très lent, mais le taux de bonnes réponses est élevé
Voici un exemple concret du fait que l’IA/les LLM écrivent parfois un code extrêmement inefficace lien vers le blog correspondant
J’ai constaté que si je demande d’abord au LLM de simplement expliquer la tâche voulue, puis que je lui donne du feedback au fil de quelques itérations, la qualité du code produit ensuite est bien meilleure ; le fait de faire valider un plan détaillé avant d’avancer est efficace
D’après mon expérience, sur le front-end, on peut confier en vibe coding des tâches répétitives, simples et faciles à valider, mais le reste du temps j’utilise surtout les LLM comme partenaires de sparring pour relire mon code et évaluer diverses alternatives ; même quand leurs recommandations sont absurdes ou logiquement bancales, ils m’aident à ne pas passer à côté d’évidences, ce qui me satisfait ; ils m’aident aussi à corriger ma tendance à vouloir trop en faire face à des problèmes inutilement emmêlés
Je ne comprends pas exactement ce que l’OP veut dire ; est-ce qu’il suggère vraiment de coller à la main des fichiers C de redis dans la fenêtre de chat web de Gemini Pro ?