- Le créateur de Redis, antirez, utilise souvent l’IA et les LLM, mais estime qu’à l’heure actuelle, la capacité humaine à résoudre des problèmes reste très largement supérieure à celle des LLM
- Il a directement constaté les limites des LLM lors du processus de correction d’un bug complexe sur les Vector Sets de Redis
- Les algorithmes proposés par les LLM se limitent à des solutions standard ou simples
- L’approche créative d’un développeur humain est mieux placée pour proposer des solutions innovantes auxquelles les LLM ont du mal à parvenir
- Les LLM sont très utiles pour valider des idées ou servir d’interlocuteur, mais la créativité finale reste humaine
Introduction : comparaison entre humains et LLM
- Je n’ai absolument aucune hostilité envers l’IA et les LLM
- J’utilise les LLM au quotidien depuis longtemps, pour tester des idées, faire de la revue de code, explorer des alternatives, etc.
- Le niveau actuel de l’IA est clairement pratique et impressionnant, mais je souligne que l’écart avec l’intelligence humaine reste important
- J’ai ressenti le besoin d’écrire ce texte parce qu’il devient difficile d’avoir récemment une discussion équilibrée sur l’IA
Le cas du bug des Vector Sets de Redis
- Je corrigeais récemment un bug lié aux Vector Sets dans Redis
- En l’absence de collègues de Redis, j’ai introduit une protection supplémentaire contre la corruption des données de fichier (RDB/RESTORE)
- Elle est désactivée par défaut et sert de filet de sécurité additionnel pour empêcher la corruption même si la somme de contrôle passe
- Le problème venait d’une optimisation de la vitesse de sérialisation vers le RDB de la représentation du graphe de la structure HNSW
- Les listes de connexions entre nœuds sont stockées sous forme d’entiers, puis reconstruites en pointeurs lors de la désérialisation
- En raison des caractéristiques de l’implémentation de HNSW elle-même (garantie de connexions réciproques), une corruption du graphe/de la mémoire peut entraîner les problèmes suivants
- A est enregistré comme connecté à B, mais B n’est pas connecté à A (erreur de numérotation, etc.)
- Lors de la suppression du nœud B, la violation de cette réciprocité peut laisser un lien A→B, provoquant ensuite un bug de type use-after-free lors d’un parcours B->A
- Après le chargement des données, il faut vérifier que tous les liens respectent bien la « réciprocité des connexions »
- Avec un algorithme pur, la complexité est en O(N^2). Sur de gros volumes de données (~20 millions de vecteurs), le temps de chargement est passé de 45 à 90 secondes, soit un doublement
Recours aux LLM et leurs limites
- En discutant avec Gemini 2.5 PRO, j’ai demandé une méthode plus efficace et j’ai examiné les propositions du LLM
- Première proposition du LLM : trier la liste des nœuds voisins puis appliquer une recherche binaire (binary search), une méthode déjà très connue
- Comme le gain restait faible, j’ai demandé d’autres idées, sans obtenir de meilleure réponse
- J’ai proposé une autre méthode : utiliser une table de hachage pour enregistrer et supprimer des paires de liens (A:B:X, triées et sans distinction de direction)
- Le LLM a jugé l’idée bonne, tout en signalant comme inconvénients les performances de génération des clés et du hachage
- J’ai ensuite proposé d’améliorer l’efficacité en traitant des clés de longueur fixe avec
memcpy, sans snprintf
Créativité humaine vs limites des LLM
- J’ai proposé une idée sans table de hachage, en appliquant une technique de XOR à un accumulateur
- Les paires de pointeurs (ainsi que les informations de niveau) sont combinées par XOR dans l’accumulateur ; lorsqu’une connexion est réciproque, elles s’annulent (0), et en cas d’absence, un motif subsiste
- J’ai toutefois signalé le risque de collisions et la prévisibilité des pointeurs (ce avec quoi le LLM était d’accord)
- Amélioration supplémentaire : combinaison d’une graine aléatoire et de hachage (
murmur-128 et graine urandom), puis application du XOR sur un accumulateur 128 bits
- À la fin, on détermine si la réciprocité des connexions est respectée en vérifiant si la valeur de l’accumulateur est égale à 0
- Le LLM a estimé que cette méthode était à la fois efficace et robuste face aux erreurs générales comme à d’éventuels attaquants externes
Conclusion
- J’ai terminé l’analyse afin de décider, en fonction de son niveau de fiabilité, s’il fallait l’adopter
- Ce cas a confirmé que l’approche créative et non standard d’un développeur humain était supérieure aux réponses limitées fournies par le LLM
- Les LLM sont extrêmement utiles pour valider des idées et servir d’interlocuteur intellectuel (le rôle du « canard intelligent »)
- Mais pour produire une solution créative finale, la supériorité de l’humain reste nette
7 commentaires
Redis va bientôt se faire distancer.
On a l’impression de regarder une course entre un vélo et quelqu’un qui court.
antirez fait partie du top 1 % des développeurs humains. Je pense que les développeurs humains du top 1 % continueront à être meilleurs que les LLM. Mais pour les 99 % restants, je ne sais pas.
J’ai essayé plusieurs fois de faire du troubleshooting avec l’IA, mais tout a échoué, et j’ai finalement résolu le problème moi-même.
Je pense que si les LLM paraissent sophistiqués et créatifs, c’est parce qu’ils ont été entraînés sur ce type de textes, et aussi parce que d’innombrables chercheurs ont vérifié ces connaissances pour améliorer la qualité des données d’entraînement afin d’en renforcer les résultats.
Mais avec le temps, les tendances changent, ou bien une créativité différente devient nécessaire selon la situation ; au final, n’est-ce pas à l’utilisateur de faire preuve de créativité en fonction de son propre contexte..?
Avis Hacker News
J’ai l’impression que cela correspond exactement à mon expérience. En réalité, la grande valeur qu’un assistant LLM m’apporte, c’est surtout de jouer le rôle d’un « canard en plastique » assez intelligent. Parfois, ce « canard » contredit même mon avis et affine davantage ma réflexion. (Qu’est-ce que le rubber duck debugging ?) Mais la question essentielle que tout le monde semble vouloir éviter, c’est : « Cette valeur existera-t-elle encore dans deux ans ? » Moi non plus, je n’en connais pas la réponse.
Pour moi, un LLM n’est pas un canard en plastique mais plutôt une « machine à mauvaises réponses ». On dit souvent que la meilleure façon d’obtenir une réponse sur Internet, c’est de publier une mauvaise réponse, et pour moi c’est exactement ce rôle-là. Si je lui confie une tâche simple mais pénible, il produit un résultat tellement faux que, par agacement, je finis par la faire moi-même sous l’effet de la colère.
Un canard bien trop sûr de lui, avec un niveau de confiance largement supérieur à ses capacités réelles. J’ai vu beaucoup trop de gens se perdre en discutant avec des LLM.
Pour moi, un LLM ressemble à un développeur junior qui travaille sous ma responsabilité, connaît bien les API mais manque de bon sens en architecture. Je relis la plupart des PR trois ou quatre fois avant même de les envoyer en revue d’équipe, en craignant des erreurs absurdes. En revanche, cela me permet de libérer mon cerveau pour d’autres problèmes, et ça c’est appréciable.
Est-ce que cette valeur sera toujours là dans deux ans ? Pour moi, la vraie question n’est pas tant « est-ce qu’on veut passer à autre chose ? » que « est-ce qu’on arrivera jusque-là dans deux ans ? ». Le monde est tellement instable aujourd’hui qu’il est impossible de prévoir à quoi il ressemblera dans six mois.
Pour moi, un LLM ressemble à un collègue de pair programming. Quelqu’un avec qui je peux discuter d’idées, qui me propose des revues de code et des alternatives. Et je peux aussi apprendre en le voyant utiliser des fonctionnalités que je ne connaissais pas.
En lisant ces commentaires, j’ai un peu l’impression que beaucoup espèrent entendre des choses comme « les humains sont indispensables », « les LLM ne savent pas déboguer » ou « les LLM induisent en erreur ». C’est vrai, bien sûr, mais la génération automatique de code, qui était impossible il y a encore deux ans, a énormément progressé et continue d’avancer à un rythme rapide. On finira peut-être par ralentir selon une sorte de « loi de Pareto », mais cela continuera clairement à progresser. Récemment, sur r/fpga, j’ai parlé de mon expérience réussie avec un LLM pour produire la première version d’un testbench, et j’ai été très surpris de voir des gens qui n’avaient même pas essayé nier jusqu’à la possibilité même.
Cette attitude est extrêmement courante chez les professions spécialisées. Je suis aussi passé sur /r/law et, en entendant les propos de Dario Amodei sur l’IA dans le domaine juridique, j’ai ressenti ce réflexe de rejet immédiat. C’est peut-être un mécanisme d’adaptation ou une forme de confort dans le statu quo, mais je pense que c’est très mauvais pour notre capacité future à faire face aux changements économiques et sociaux.
C’est similaire à l’époque où l’assembleur était la base, quand les programmeurs se moquaient de l’arrivée des langages de programmation en les jugeant inefficaces, rigides et trop simplifiés — sans grand rapport avec la réalité. Ce genre de réaction est naturel, indépendamment de la valeur réelle de la nouvelle technologie.
On a l’impression que les LLM ont connu une croissance explosive pendant un temps, puis que les modèles récents ont même régressé. Ils donnent de bons résultats pour générer des tests, mais dès qu’on les utilise trop en profondeur pour implémenter de nouvelles fonctionnalités, cela devient étrange. Ça marche bien pour des projets neufs ou de petites web apps, mais beaucoup moins pour le refactoring de bases de code volumineuses ou legacy, ou pour l’ajout de fonctionnalités. Par exemple, je vois souvent Claude ou ChatGPT inventer n’importe quoi sur toute l’API D3.
En fin de compte, tu es en train de construire toi-même ton propre remplaçant, tandis que tes collègues avancent avec prudence.
ChatGPT-4o fait preuve d’une compétence impressionnante pour écrire du VHDL. J’en fais encore l’expérience aujourd’hui avec des résultats étonnants pour prototyper des contrôleurs bas niveau.
Le volume de contexte nécessaire pour écrire correctement du vrai logiciel est beaucoup trop grand pour les LLM. Un logiciel, c’est en soi la « mise en code du métier ». Comment un LLM pourrait-il connaître toutes les conditions spéciales promises par l’équipe commerciale aux clients, ou les règles implicites propres à chaque service ? Aujourd’hui, ce que les LLM peuvent résoudre reste général et limité. Dès qu’on dépasse deux classes ou 20 à 30 fichiers, même les meilleurs LLM perdent le fil et leur concentration. Comme ils ne maintiennent pas bien le contexte, ils génèrent inutilement beaucoup de churn dans le code. Pour réellement remplacer un développeur, un LLM devrait absorber bien plus de contexte, le collecter à l’échelle de toute l’organisation et garder une continuité de pensée sur des projets de longue durée. Si ces problèmes commencent réellement à être résolus, c’est à ce moment-là que je commencerai à m’inquiéter pour de bon.
Chaque fois qu’on discute de savoir si les LLM remplaceront les développeurs, tout le monde oublie qu’en pratique, l’ingénierie logicielle comprend énormément de travail au-delà de l’écriture de code. Écrire du code n’en représente qu’une petite partie. Ce qui compte vraiment, ce sont les compétences relationnelles, l’analyse des besoins et la capacité à découvrir ce que le client veut réellement, alors que souvent le client lui-même ne le sait pas bien, et c’est à l’ingénieur de le comprendre. Si c’est déjà difficile pour les humains, il est peu probable qu’un LLM y parvienne.
Au fond, tout cela relève d’une boucle de feedback : un processus d’itérations immédiates où le client essaie réellement le produit puis donne son avis. Une interface de chat est excellente pour cette boucle de retour client, et des agents peuvent produire rapidement de nouvelles versions. Les LLM sont tout à fait capables d’abstraction, de systèmes à composants variés, d’architecture globale et même d’analyse des besoins. La vraie question est la vitesse d’itération. La robustesse et le QI des modèles continuent de s’améliorer. L’ensemble de l’ingénierie logicielle est déjà en train d’entrer dans une phase d’automatisation. Dans cinq ans, l’humain sans assistance risque de devenir un énorme goulet d’étranglement. Sans intégration profonde de l’IA, on ne pourra que prendre du retard.
Les LLM ne font pas de l’ingénierie logicielle en tant que telle. Mais ce n’est pas forcément un problème. En pratique, beaucoup de programmes qui réussissent tournent très bien sans « ingénierie logicielle ». C’est encore plus vrai dans des environnements où personne ne se soucie vraiment de la structure des coûts cloud. Au contraire, je pense qu’à l’avenir, des profils proches des business partners IT, avec une vraie sensibilité technique, construiront des applications entières sans l’aide d’ingénieurs logiciel. Dans l’industrie des énergies vertes, c’est déjà une réalité quotidienne. Le problème surgit seulement quand il faut assurer maintenance, montée en charge et efficacité. C’est là que des choix comme « utiliser une liste ou un générateur en Python » deviennent réellement importants, et que la vraie ingénierie devient nécessaire.
Dans cinq ans, il est possible qu’on ne fasse presque plus de conception de code. Déjà, par rapport à il y a un an, je tape énormément moins de code. Mais cela ne reste qu’une partie du processus, et cela ne signifie pas que les développeurs vont disparaître.
En revanche, le rôle du simple « codeur » est déjà largement remplacé. C’est précisément dans cette zone que les LLM excellent. Il y a beaucoup de codeurs sans vraie réflexion qui se contentent de tickets du type « prends cette API et retourne cette valeur » sans jamais comprendre les besoins clients ni faire d’analyse, et cette partie est en train d’être absorbée rapidement. L’ingénierie logicielle au sens fort est tout autre chose, mais il ne faut pas oublier que la demande pour ce type de codeurs était énorme.
Le point très important, c’est que seuls les humains possèdent la capacité de manier les concepts abstraits d’un programme et de résoudre des problèmes de manière créative. Un programmeur est un architecte de la logique, et l’ordinateur est l’outil qui transforme la pensée humaine en instructions. Les outils peuvent imiter l’humain et bien générer du code pour certaines tâches, mais ils ne remplacent pas la conception abstraite fondamentale ni l’acte de construction. Si les modèles acquièrent non seulement la capacité d’écrire du code, mais aussi de réaliser un projet complet à partir d’un cahier des charges, alors le rôle du développeur changera encore une fois.
Il faut toujours partir du principe que « ce qui est meilleur » dépend de la tâche. Les LLM sont déjà bien meilleurs que moi sur les tâches répétitives et très codifiées, comme respecter une syntaxe CSS ou se rappeler comment appeler une bibliothèque connue. Ces petits « événements parasites » me prenaient autrefois beaucoup de temps ; maintenant, ils sont presque instantanément résolus, et j’en suis très satisfait.
En revanche, dès qu’on touche au styling de fond — au-delà du simple CSS de base — les résultats des LLM sont plutôt médiocres. Quand il est difficile d’expliquer clairement l’effet recherché, ou que le travail devient subtil, ils échouent très souvent à produire le résultat le plus important et restent bloqués sur une seule approche.
Pour ce que je maîtrise mal (SQL), les LLM sont bien meilleurs que moi ; pour ce que je connais bien (CSS), ils sont au contraire moins bons. Le critère apparaît donc assez clairement.
Je suis d’accord à la fois avec l’idée qu’ils sont « meilleurs que la plupart des développeurs » et avec le fait qu’ils paraissent meilleurs surtout parce que beaucoup ne savent pas faire de CSS. En réalité, beaucoup de gens détestent le CSS, ne l’apprennent pas vraiment et l’utilisent à contrecœur, d’où cette confusion. Si une entreprise ne peut pas recruter un vrai expert CSS et cherche une solution moins chère, alors un LLM devient une alternative ; si elle a les moyens d’embaucher quelqu’un de vraiment bon, il n’y a évidemment pas de comparaison possible. Au final, le vrai concurrent des LLM, ce sont les développeurs peu compétents.
Dans les langages principaux ou dans des domaines que je ne maîtrise pas exactement, l’autocomplétion des LLM m’aide beaucoup. Mais si l’on ne développe pas une forme de « mémoire réflexe » et qu’on se repose uniquement sur le LLM, on risque de manquer de capacité pour évaluer ses suggestions et de rester bloqué sur des solutions médiocres.
Je suis heureux de voir autant de gens s’inquiéter du « bon code », mais j’ai peur que cela n’ait plus vraiment de sens dans la pratique. L’industrie du logiciel est depuis longtemps déjà absorbée par le monde des affaires, au point qu’on ne sait même plus bien quand cela a commencé (depuis la lettre ouverte de Bill Gates en 1976, peut-être ?). Le vrai problème, c’est que les actionnaires et les dirigeants se soucient moins du code tant que les profits montent. Sans résistance culturelle de la part des développeurs et des utilisateurs, cette structure risque de perdurer.
À propos de l’idée que sans résistance culturelle des développeurs et des utilisateurs, c’est terminé : je veux quand même rappeler qu’il existe des entreprises qui produisent du bon code, et que tout n’est pas forcément un désastre. Le problème n’est pas seulement la qualité du code, mais une question éthique : accepte-t-on les objectifs business dictés par le capitalisme ? L’équilibre entre un beau logiciel et la réalité est ce qu’il y a de plus important. Moi aussi, en tant que développeur et fondateur, j’aime l’open source et l’ingénierie, mais j’ai aussi envie de vivre suffisamment confortablement.
Le code est le moteur du business. Un mauvais code mène à un mauvais business. Il existe une différence nette entre une équipe d’hébergement (pare-feu physiques, vmware, proxys, etc.) et le cloud public (QEMU, netfilter, matériel banal, etc.). Quant à savoir qui a absorbé qui, personne ne peut prédire l’avenir.
J’ai passé toute la soirée d’hier à me battre avec o3. Je n’avais jamais écrit de Dockerfile de ma vie, donc j’ai préféré donner à o3 un dépôt GitHub pour qu’il règle ça automatiquement, mais j’ai ensuite gaspillé des heures à déboguer le résultat. Il ajoutait des éléments qui n’existaient pas, supprimait ou mélangeait des choses inexistantes, et confondait même des notions de base comme la différence entre
python3etpython. Au final, énervé, j’ai trouvé un document Google et tout s’est vite éclairci. L’IA est un excellent outil, mais ce n’est pas une solution miracle, et quelqu’un doit absolument rester « éveillé ».Les entreprises qui utilisent les LLM et l’IA pour augmenter la productivité de leurs employés prospéreront ; celles qui essaient de remplacer entièrement leurs employés échoueront, selon moi. À court terme, il est possible que des CEO ou dirigeants, satisfaits des résultats immédiats, prennent des décisions qui rongent la croissance future.
C’est exactement ça. Utiliser les LLM comme assistants des programmeurs, oui ; comme remplacement total, non. Adopter la technologie avec mesure, c’est la bonne voie.
L’idée qu’on puisse créer de la valeur à court terme pour l’entreprise en remplaçant des employés est assez intéressante. Autrement dit, cela pourrait nuire à l’entreprise à moyen ou long terme, tout en faisant temporairement monter l’action.
Les assistants de code sont des outils communs devenus indispensables, pas des armes pour remplacer les personnes. À une époque où les concurrents peuvent acheter les mêmes abonnements IA, ils ne permettent pas de remplacer les humains.
Retour d’expérience terrain : ancien développeur, aujourd’hui plutôt manager, mais je code encore. Les assistants LLM sont utiles, mais parfois pénibles. Quand ils déversent soudain des suggestions de code inattendues, ils peuvent faire dériver le travail dans une direction non voulue, et le temps de revue devient coûteux. C’est probablement un problème de configuration, mais j’aimerais que ce soit masqué par défaut et visible seulement quand je l’appelle explicitement en ligne de commande. Une chose est sûre : même si je confie à un LLM l’écriture d’un bloc complet de code ou d’une fonction, je passe toujours systématiquement par ma propre revue.
L’éditeur Zed propose ce type de mode de « suggestions discrètes » (voir plus). J’aimerais que tous les éditeurs offrent un mode comme celui-ci.
En ce moment, comme je fais un peu de tout dans une startup, je n’aime pas beaucoup les UI produites par les LLM. Les éléments de base façon building blocks sont utiles, mais si je confie à Claude un long bloc de code entier, il faut ensuite énormément de reprises pour arriver au résultat que je veux.
https://freederia.com Il s’agira d’entretenir une relation de coexistence, comme sur le site des scientifiques de l’IA.