Je peux savoir quand vous faites du « vibe coding »

• Récemment, il devient facile de repérer à l’intérieur d’une équipe le code généré par un LLM
• Ces codes, bien que clairs et bien testés, ne respectent pas les conventions du projet
• Ils ignorent plusieurs patterns ou bibliothèques existants pour implémenter quelque chose de neuf
• L’inquiétude grandit face à la tendance à ne chercher que la vitesse dans le développement logiciel
• En fin de compte, l’essentiel reste la qualité et la cohérence, ainsi que la maintenabilité

---

Les traces du vibe coding

• Certaines parties de code écrites récemment par un membre de l’équipe paraissent claires et fonctionnellement parfaites, mais peuvent être immédiatement identifiées comme générées par un LLM parce qu’elles ne respectent pas les conventions propres au projet
• Par exemple, malgré la présence d’une bibliothèque de récupération de données dans le projet, l’équipe écrit directement une implémentation de requêtes HTTP qui couvre tous les cas d’exception
• Les fonctions utilitaires des modules existants sont recréées à répétition, et malgré l’existence d’un mécanisme de modification de configuration au niveau du module, les réglages globaux sont changés
• Malgré une culture bien implantée de codage fonctionnel, du code basé sur des classes est écrit à nouveau
• Il s’agit d’un style de code qu’un développeur n’aurait, il y a quelques années, jamais écrit

L’importance de la maintenabilité et des principes logiciels

• En développement logiciel, on a toujours investi des efforts pour établir des patterns et standards durables
• En pratique, n’importe qui peut écrire du code qui fonctionne, mais le vrai défi est d’avoir un code facile à maintenir et à modifier sur le long terme
• L’enjeu n’est pas la mise en œuvre de la fonctionnalité elle-même, mais une base de code qui puisse être conservée au fil du temps
• Le « vibe coding » peut faire s’effondrer ce type de philosophie et ces standards

Faire de la vitesse la ligne directrice absolue ?

• Il utilise l’exemple d’un nouveau barista dans un café qui, en se dépêchant, renverse son café, pour souligner que l’obsession de la vitesse n’apporte pas toujours de bons résultats
• Les équipes de développement d’aujourd’hui en sont au même stade, allant trop vite pour construire de nouveaux logiciels et provoquant ainsi une baisse de la qualité
• Ce que les gens attendent au fond, c’est un résultat correct, même s’il faut attendre un peu plus longtemps
• Je pensais que la recherche effrénée de la vitesse était un problème de métiers non techniques, mais j’ai été déçu de voir des collègues développeurs eux aussi abandonner les principes pour ne poursuivre que la vitesse

Ce que nous voulons vraiment

• On ne se soucie pas de la manière dont le code a été injecté dans l’IDE
• L’important est l’attitude d’un développeur qui veille à la qualité
• On reconnaît que les LLM sont une avancée technique remarquable, mais on rappelle que la responsabilité de fabriquer un vrai logiciel repose toujours sur le développeur
• Il préconise d’appliquer des principes existants en sachant rédiger de meilleurs prompts, en spécifiant les bonnes bibliothèques, en fournissant des exemples, en travaillant fichier par petit fichier
• Ne laissez pas la qualité du code et la maintenabilité à la charge des seuls « poids » du modèle

[GN⁺]

Avis Hacker News

• Personne ne réimplémente un système de requêtes HTTP si la bibliothèque de data fetching déjà présente dans le projet couvre tous les cas limites, ne recrée un module de fonctions utilitaires s’il en existe déjà un, ne modifie des réglages globaux depuis des modules individuels alors qu’on peut l’éviter, ni ne crée de nouvelles classes dans une équipe qui privilégie surtout une approche fonctionnelle ; j’aimerais travailler dans une équipe comme ça, mais en pratique beaucoup de développeurs refont souvent ce genre de choses

  • Honnêtement, dans les gros projets, ce genre de chose arrive très facilement quand la documentation est mauvaise ; dans le projet de recherche universitaire où je travaille, la documentation du code se limite à dire que le code est « auto-documenté », avec juste quelques mentions sur la configuration CMake, le build ou la manière de lancer les benchmarks ; les règles internes et les conventions, il faut les découvrir sur le tas ; quand quelqu’un de nouveau arrive, il réimplémente souvent des fonctionnalités existantes ou modifie des paramètres globaux ; au final, le mieux reste d’indexer la codebase et de poser directement la question à un LLM (les personnes clés du projet sont parties ou ne répondent que bien plus tard)

  • Je pense que vous passez à côté du point principal de l’auteur ; si la vitesse est la vertu suprême, alors ce genre de choses continuera à se répéter ; si la vitesse est une valeur absolue, il faut que la production augmente de façon exponentielle pour compenser la dette technique ; si d’autres facteurs comptent aussi, alors il faut gérer cette dette intelligemment et la rembourser ; mais aujourd’hui, on a plutôt l’impression qu’on accumule la dette en espérant que ça passera, et beaucoup de gens sont en réalité mauvais pour la gérer

  • Beaucoup réinventent la roue à chaque occasion, ignorent les conventions attendues ou mélangent les patterns ; l’auteur appelle ça du « vibe coding », mais en réalité ce n’est pas un problème propre aux LLM : ça arrive à n’importe qui quand on est pressé de sortir un résultat ou qu’on manque d’expérience ; l’expression « du code qu’aucune personne de l’équipe n’écrirait ainsi » laisse penser qu’il s’agit peut-être d’un reproche visant quelqu’un en particulier ; il faut être prudent avant d’appliquer cette grille de lecture ailleurs

  • J’ai aussi vu des développeurs ajouter une ORM en plus : la première suffisait, mais ils en ajoutent une deuxième parce que « c’est tendance en ce moment » ; développeurs comme LLM ont leurs biais ; bien connaître les règles et les patterns du projet, et travailler dans ce cadre, est extrêmement important ; construire les choses à sa manière sans tenir compte du contexte est très dangereux ; pour les humains, on peut corriger ça avec une culture de code review et en encourageant la lecture du code ; pour les LLM, il faut expliciter tous les patterns et toutes les règles, sinon ils risquent fortement de produire du code en décalage avec le projet ; l’important, c’est de définir explicitement des valeurs et des critères clairs

  • J’ai déjà travaillé dans une équipe aussi bonne ; il s’agissait souvent de projets petits (2 à 4 personnes) mais à fort enjeu ; dans ce genre d’environnement, il est plus facile de construire une culture de développement et un consensus qui équilibrent qualité et vitesse ; dans une telle équipe, personne — humain ou LLM — n’approuverait jamais une PR contenant ce type de code

• Personnellement, je considère les LLM comme des développeurs très juniors : ils essaient de bien faire et suivent les consignes, mais comprennent mal la codebase et ses patterns ; il faut leur expliquer tout le processus, jusqu’aux erreurs potentielles, leur confier des tâches petites et précises, puis relire le code avec soin ; moi, par exemple, je me représente d’abord le modèle de données mentalement avant d’écrire le code ; des explications concrètes sont essentielles ; une règle implicite que j’applique est de toujours mettre un commentaire de bloc en haut du fichier pour expliquer son contenu ; cela sert de deuxième prompt quand la session redémarre ; cette méthode fonctionne bien sans donner l’impression d’être « magique », mais au milieu il faut tout de même faire environ 30 % de nettoyage, renommage et refactoring pour obtenir quelque chose de propre ; malgré cela, avec les LLM je vais beaucoup plus vite qu’en écrivant tout entièrement à la main

  • Les expressions « développeur junior » ou « copilote » ne reflètent pas toujours correctement à la fois les forces et les faiblesses des LLM ; contrairement à une personne, ils oublient facilement et font parfois des erreurs très élémentaires, mais ils sont aussi meilleurs que moi sur certains points (par exemple les erreurs d’index de type off-by-one sur les tableaux) ; et ils connaissent de manière encyclopédique presque tout ce qu’on trouve sur Internet ; à l’usage, j’en suis venu à penser qu’un LLM ressemble à un chien de chasse : c’est le maître qui dirige la chasse et qui doit la terminer lui-même

  • La différence entre un LLM et un développeur junior, c’est la capacité d’apprentissage ; un junior peut apprendre et progresser petit à petit, mais pas le LLM ; plus on met d’instructions dans le prompt, plus il a de chances d’en oublier et de revenir à des réponses génériques ; à chaque nouveau prompt, il faut tout réexpliquer depuis le début

  • J’ai l’impression qu’utiliser un LLM ne diffère pas tellement du fait de chercher du code sur Internet pour le copier-coller ; au final, le développeur doit quand même vérifier lui-même le code et confirmer qu’il fonctionne correctement ; récemment, à cause de ma santé visuelle, je dois travailler par sessions de 20 minutes avec des pauses, donc l’efficacité est devenue encore plus importante ; les LLM génèrent du code bien plus vite qu’un humain, donc même s’ils ne s’occupent que des parties de base, c’est déjà un gros avantage ; en ce moment, je génère des structs pour SIMD avec Unity C# et LINQ, et rien qu’en disant au LLM les conditions voulues, j’obtiens le code ou les chaînes souhaitées bien plus vite qu’en copiant-collant moi-même ; l’idée d’utiliser l’IA comme un HUD paraît très concrète ; plutôt qu’une IA qui écrit tout le programme, j’ai besoin d’un outil d’assistance au développement très puissant sur de petites unités de travail

  • Pour moi, un LLM est un bien meilleur substitut à StackOverflow ; je peux lui poser immédiatement les questions que j’ai, et il me répond de manière précise ; je m’appuie ensuite sur sa réponse pour réécrire dans mon propre code ou ne générer que des fonctions ; avant de copier quoi que ce soit, j’essaie toujours de comprendre entièrement le code ; il m’est aussi déjà arrivé de me demander si, pour sa carrière, il n’était pas plus rentable de soumettre une PR de 400 000 lignes à un projet open source dans un langage qu’on maîtrise mal, plutôt que de travailler honnêtement avec exigence de qualité ; c’est le reflet d’une réalité où les années d’expérience (Years of Experience) sont souvent plus valorisées que les compétences réelles

  • Pour faire travailler un LLM avec succès, j’ai trouvé préférable de limiter son rôle non pas à la réflexion, mais à l’étape de codage elle-même ; il faut découper les tâches, donner un spec précis, indiquer les fichiers à modifier, l’emplacement d’exemples de référence, et transmettre autant de détails que possible pour maximiser les chances de réussite ; pas besoin d’être excessivement minutieux, mais plus il y a d’indices, plus le taux de succès augmente ; je vérifie aussi chaque bloc généré un par un avec git add -p ; cela demande du temps de préparation et de relecture, mais ça économise clairement du temps et de l’énergie par rapport au fait de tout écrire seul ou de laisser passer du code bancal

• Le plus grand danger du vibe coding, c’est que pour un bon développeur, cela ne fait qu’accélérer légèrement le travail, alors qu’un développeur peu compétent peut produire beaucoup plus vite une grande quantité de mauvais code ; la vraie question est de savoir si ces développeurs peuvent progresser grâce au vibe coding, ou s’ils vont simplement stagner à ce niveau

  • D’après mon expérience, même un développeur médiocre peut devenir très vite un mauvais développeur, à cause d’un excès de confiance mal placé et d’une explosion du volume de code produit ; le code généré par l’IA ne prend presque jamais en compte l’architecture d’ensemble, les flux d’information ou le principe de responsabilité unique ; pour produire du code « sûr », il tend à renvoyer des placeholders au lieu de lever des exceptions ; le code appelant doit alors vérifier à chaque fois si le résultat est un placeholder ou non ; dès que les paramètres d’entrée sont mauvais, l’IA essaie de les « corriger » d’elle-même et ignore une structure du type gather_parameters → call → process_results ; et quand on arrive aux tests, le problème devient bien pire

  • Beaucoup de développeurs vont maintenant redécouvrir le concept de net-negative programmer, c’est-à-dire un développeur dont la simple présence fait baisser la qualité du projet

• À mes yeux, la ressource qui manque le plus ici, c’est l’attention portée au travail ; le vibe coding n’est pas en soi la cause de ce manque d’attention, l’IA n’est qu’un outil ; tous les problèmes évoqués par l’auteur s’appliquent exactement de la même façon à un développeur junior humain, et peuvent être améliorés avec plus de guidage ou une meilleure communication ; je ne pense pas que l’IA fasse baisser l’intérêt pour la qualité (ceux qui s’en fichaient s’en fichaient déjà avant) ; l’objection fréquente est qu’on perd des occasions de former des juniors, mais dans beaucoup de cas on utilise l’IA comme solution provisoire faute de moyens (c’est aussi le cas de ma startup, qui recrute difficilement) ; les outils d’IA peuvent faire évoluer les critères de qualité logicielle, et je pense que ce point a encore beaucoup de marge pour changer à l’avenir

• Les LLM devraient utiliser non seulement l’état actuel du code, mais aussi l’historique des commits comme contexte ; beaucoup de codebases migrent progressivement d’un pattern A vers un pattern B, et plusieurs patterns coexistent ; comme la migration ne peut pas se faire d’un coup, on se retrouve généralement avec un mélange durable d’ancien et de nouveau ; même si le LLM reconnaît les patterns, comme dans l’exemple HTTP, le choix de celui qu’il faut suivre reste souvent une question de chance

  • J’ai déjà travaillé sur une grosse codebase qui a connu plus de vingt ans de fusions, changements de nom et acquisitions ; on y trouve encore de très vieux exemples d’appels API, alors qu’il existe ailleurs du code plus récent, mais beaucoup d’anciens éléments ont été conservés pour certains clients ; il y a aussi énormément d’API similaires sans la moindre documentation, donc il faut fouiller une par une pour savoir laquelle renverra les données souhaitées

  • Une méthode consiste à créer un fichier comme CLAUDE.md pour indiquer clairement « suivez ce pattern, évitez celui-là »

  • Cela dit, il est encore plus efficace d’expliquer de manière très concrète la façon de travailler propre à chaque partie, avec des exemples

  • Le problème, c’est que cette capacité même à percevoir le contexte manque souvent aux personnes qui font du vibe coding ; beaucoup avaient déjà peu d’expérience de programmation avant l’arrivée des LLM

  • Tout cela n’est possible que si les messages de commit sont correctement rédigés ; en pratique, la plupart se résument à « modification de ce fichier » ou « correction de bug »

• Quand on utilise des LLM, les outils automatisés comme les linters, les formatters et les vérifications de types strictes sont d’une très grande aide, surtout quand des contributions arrivent de personnes (ou d’agents LLM) qui ne connaissent pas le style du code ou ses règles implicites ; ces outils permettent de contrôler automatiquement le code et, quand c’est possible, de corriger directement certains problèmes ; même chose pour les tests ; les systèmes de validation automatisée sont très utiles pour maintenir la qualité, qu’il s’agisse d’humains ou d’agents

  • Je ne pense pas que ces outils empêchent en pratique la plupart des cas de vibe coding mentionnés dans l’article

  • Il arrive aussi que ces outils ne fassent que lisser la surface en masquant le problème de fond

• Tous les grands assistants IA intègrent déjà par défaut des moyens d’atténuer ces problèmes : /init dans Claude Code, /Generate Cursor Rules dans Cursor, etc., sous une forme plus automatisée et plus facilement déployable à l’échelle d’une organisation que la simple context engineering ; au final, la manière dont ces outils divisent aussi la communauté de développement est un sujet intéressant

  • En pratique, même quand tout est très clairement défini dans CLAUDE.md, CC (Claude Code) l’ignore souvent ; plus la conversation dure, plus j’ai l’impression qu’il répète les mêmes problèmes, et jusqu’ici je n’ai pas trouvé de solution pleinement satisfaisante ; c’est pourquoi je ne pense pas qu’il faille réduire cet article à une simple posture anti-IA

  • Je suis en train de réévaluer Cursor ; s’il n’atteint pas la vitesse espérée, ce n’est pas seulement à cause de petites erreurs (comme un LM qui remplace : par ,), mais aussi parce que la codebase est trop vaste, trop ancienne et de qualité trop hétérogène ; les LLM finissent par réutiliser plus souvent les patterns les plus fréquents — donc souvent les mauvais ; même quand on leur dit clairement « inspire-toi de cette partie », ils restent influencés par l’ensemble de la codebase ; même avec des rules, cela ne semble pas très différent du fait de les injecter directement dans le prompt ; je me demande s’il existe une vraie solution

  • Le cœur du problème, ce n’est pas l’outil, mais le « codeur » obsédé par le vibe ; il n’a ni exigence ni rigueur dans sa manière d’écrire du code

• D’après mon expérience, presque tous les problèmes viennent d’une fenêtre de contexte limitée et d’une « context engineering » sous-optimale ; quand le LLM reçoit correctement le contexte important, comme les fonctions globales, il s’en sert plutôt bien ; la difficulté est de savoir quel contexte fournir et comment le maintenir sans rupture ; je m’attends à de gros progrès sur ce point avec des formes de sub-agents à l’avenir

  • Vous dites que « si l’agent connaît la description des fonctions globales, il les utilise bien », mais en réalité il n’existe pas d’« agent » ; il ne s’agit que d’une fonction mathématique reliant une entrée à une sortie ; comparer un LLM à un humain est inexact, les humains et les machines sont fondamentalement différents

• Je pense que tout cela est juste ; la meilleure manière d’utiliser les LLM, c’est un peu comme un compilateur fournit un niveau d’abstraction supérieur à l’assembleur : si l’on décrit clairement les exigences et les entrées/sorties, il peut produire du code comme une traduction logique ; c’est justement pour cela qu’il faut minimiser la confusion (l’entropie) dans l’entrée ; un LLM est fondamentalement un moteur de traduction ; on l’utilise plus efficacement pour « traduire » que pour « générer » ; malgré cela, des modèles plus intelligents et plus intuitifs arrivent régulièrement, et les résultats s’améliorent en demandant de moins en moins d’effort ; au bout du compte, il viendra un jour où les LLM produiront de meilleurs résultats que les développeurs humains sur n’importe quelle tâche, comme ce sera aussi le cas pour d’autres rôles humains

  • C’est une mauvaise analogie ; un LLM n’est pas un moteur qui « compile » du langage naturel en code de haut niveau ; les langages de programmation et le langage machine exigent des systèmes de sens clairs et cohérents, alors que le langage naturel relève d’une couche d’abstraction totalement différente ; un même LLM peut produire des résultats différents avec une nouvelle seed ou une nouvelle version, tandis qu’un compilateur doit toujours produire la même sortie pour la même entrée

  • Je ne peux pas accepter l’idée qu’un LLM soit une couche d’abstraction comme un compilateur ; en réalité, un LLM n’est qu’un générateur arbitraire de tokens ; parmi les résultats produits avec des LLM, je n’ai jamais rien vu de réellement exploitable ; le techno-optimisme autour de la singularité ou d’un accès illimité aux données manque de fondements réels ; obtenir des données de haute qualité coûte énormément d’argent ; pour l’instant, les prédictions optimistes n’ont pas beaucoup de sens

• J’ai compris plus tard que l’auteur que « beaucoup de gens préfèrent un café rapide et bon marché à un bon café » ; dans le monde réel, la majorité valorise plus la vitesse et le prix que la qualité

  • Il suffit de voir le succès des machines à café Keurig pour comprendre cette tendance

[dkmin]

Le post HN est plus savoureux que l’article lui-même.