Le culte du vibe coding est insensé
(bramcohen.com)- La fuite du code source de Claude a mis en lumière les dégâts que peut causer, sur la qualité réelle d’un projet, la foi aveugle dans le « vibe coding »
- Le vibe coding pose comme principe de ne jamais regarder l’intérieur du code, mais cela relève du pur mythe ; en pratique, une structuration humaine via des fichiers de planification, des skills, des règles, etc., est indispensable
- L’IA est réellement très performante pour des tâches comme la déduplication du code et la résorption de la dette technique, mais pour en tirer parti, un humain doit examiner le code, identifier les problèmes et les expliquer à l’IA
- Il est rare que l’IA reconnaisse d’elle-même qu’« il y a du code spaghetti ici, il faut le nettoyer » ; des résultats de haute qualité apparaissent quand l’humain fournit d’abord la direction et le contexte
- Comme le dit la formule « un mauvais logiciel est un choix du développeur », la baisse de qualité n’est pas le fait de l’IA, mais le résultat d’une prise de décision
- Autrement dit, la dégradation de la qualité logicielle n’est pas la faute de l’IA ; elle relève des choix que font les développeurs eux-mêmes
La fuite du code source de Claude et le problème du vibe coding
- Le code source de Claude a fuité, et beaucoup s’en sont moqués en raison de sa faible qualité
- Parmi les causes avancées figure l’excès de dogfooding, c’est-à-dire une culture d’usage trop aveugle de son propre produit
- Le dogfooding en soi est une bonne idée, mais il peut se transformer en pratique quasi cultuelle dépassant toute limite raisonnable
La réalité du vibe coding
- Le vibe coding est une approche qui pose comme principe de ne contribuer en rien au code, et même de ne pas le regarder
- Pourtant, le vrai vibe coding “pur” est un mythe — en pratique, il existe toujours un framework conçu par des humains, fait de fichiers de planification (listes de tâches), de skills, de règles, etc., et sans cette structure l’IA fonctionne très mal
- Le code étant écrit en anglais et donc lisible par tous, certains développeurs refusent malgré tout de le consulter au nom de l’idée que « regarder l’intérieur, c’est tricher »
- En réalité, le simple examen du code par une seule personne a permis de découvrir une duplication massive entre les agents et les tools ; c’était un problème qu’on aurait facilement repéré si quelqu’un avait pris un instant pour regarder
IA et nettoyage de la dette technique
- Les projets logiciels démarrent souvent avec de la dette technique, et autrefois son traitement pouvait à lui seul prendre un an
- Avec l’IA, ce travail de remise en ordre peut être terminé en quelques semaines, ou résorbé progressivement en parallèle du développement de nouvelles fonctionnalités
- L’IA excelle dans le nettoyage du code, mais elle reste mauvaise pour détecter seule les problèmes — elle donne de bons résultats quand un humain lui dit « il y a du code spaghetti ici » et lui fournit des indications
La bonne manière d’utiliser l’IA — une approche fondée sur le dialogue
- Pour résoudre correctement les problèmes de duplication, les étapes suivantes sont proposées :
- dresser la liste des éléments présents à la fois côté agent et côté tool
- examiner des exemples puis déterminer si chaque élément relève d’un agent ou d’un tool
- discuter des critères d’ensemble et établir des lignes directrices générales
- auditer tous les éléments puis corriger ceux qui ont été mal classés
- pour les éléments présents des deux côtés, examiner les deux versions puis les fusionner en une seule
- Le mode Ask est fait pour ce processus : le cœur de la méthode consiste à examiner les exemples ensemble et à corriger l’IA lorsqu’elle cherche à acquiescer de manière excessive
- Après suffisamment d’échanges, on peut avoir l’impression que l’IA a produit un résultat “one-shot”, mais il s’agit en réalité d’un résultat qui repose sur de nombreuses interactions humaines préalables
- L’équipe de Claude applique le dogfooding de manière extrême sans passer par ce processus, au point de refuser le minimum d’effort consistant à regarder brièvement l’intérieur du code et à expliquer le problème
Cas d’usage concret
- Exemple de workflow de l’auteur : il lance la conversation en disant « auditons le code inatteignable dans cette base de code » ou « cette fonction fait mal aux yeux »
- Il poursuit la discussion jusqu’à obtenir une direction exploitable, explique ce qu’il faut faire, puis continue à débattre jusqu’à ce que l’IA arrête de dire des bêtises
- Ensuite, il établit un plan et lance le build ; c’est sa manière de travailler au quotidien
La qualité logicielle est une question de choix
- Utiliser l’IA n’implique pas qu’il faille accepter un logiciel de mauvaise qualité
- Même des bibliothèques créées sans aide de l’IA par des développeurs excessivement bien payés peuvent être de mauvaise qualité
- Un mauvais logiciel est le résultat d’une décision personnelle ; il faut en assumer la responsabilité et viser une meilleure qualité
9 commentaires
Avec les agents IA en full automation pour générer, merger, relire et valider le code de façon totalement autonome, on en est arrivé à une ambiance où, tant que le code se structure tout seul et qu’on n’a quasiment plus à s’en occuper sauf quand les agents s’emmêlent entre eux ou qu’un développeur doit intervenir de temps en temps, tout serait réglé — et les développeurs qui n’y arrivent pas sont traités comme des anormaux incapables de suivre la tendance… Puis quand on voit des gens qui, au quotidien, balançaient à la pelle du code ultra boilerplate et des suites de patterns simplistes tout en touchant de très gros salaires, et qui maintenant fanfaronnent en disant qu’avec l’IA on n’a même plus besoin de coder, c’est franchement pathétique.
Il faut microgérer jusqu’aux moindres détails pour produire un code d’une qualité à peu près correcte. À mon avis, l’automatisation totalement autonome n’a aucun sens, sauf pour produire en masse du véritable code boilerplate. Ceux qui parlent d’autonomie totale sont de deux choses l’une : soit ils n’y connaissent pas grand-chose, soit ce sont des escrocs.
Des projets à moitié finis prolifèrent…
Et ceux qui ne comprennent la programmation qu’à moitié s’enthousiasment…
Il vaudrait mieux considérer le dogfooding non pas comme une exclusivité, mais comme du « dog pudding ».
dog食...
Le titre et le contenu sont différents… ?
On dirait plutôt une critique qui conclut d’emblée que le vibe coding revient à ne pas faire de revue de code, puis plaque des justifications derrière.
En plus, y mêler Claude Code n’a pas de sens. Si on parle d’un niveau d’exigence sur la qualité, disons des principes d’ingénierie comparables à ceux de la maintenance du noyau Linux, alors on n’aborde pas les problèmes de qualité du code de manière aussi fragmentaire. Dans la grande majorité des cas, c’est une approche propagandiste, du genre « il paraît que c’est comme ça », et non quelque chose qui a été réellement testé directement.
C’est un peu comme dire que le design des bâtiments de Samsung n’est pas terrible et qu’ils sont encore loin d’avoir rattrapé Sony.
Quand j’ai essayé Claude Code pour la première fois, j’ai dit à des amis étrangers : « J’ai testé le vibe coding pour la première fois ! » Après avoir écouté ce que je racontais, ils m’ont répondu : « Non, ça ce n’est pas du vibe coding ; le vrai vibe coding, c’est justement le fait de ne même pas regarder le code. » J’ai l’impression que le « vibe coding » dont on parle souvent en Corée est défini de manière bien plus large que dans le monde occidental. Sur Hacker News, le vibe coding est effectivement défini comme le fait de ne pas faire de revue de code.
Réactions sur Hacker News
C’est étrange de voir des gens prendre la qualité du code source divulgué de Claude Code comme preuve que le « vibe coding » a échoué
Pour moi, c’est plutôt l’inverse. C’est la preuve qu’on peut enfreindre les règles traditionnelles du « bon code » tout en créant un produit populaire et à succès
À cause des délais, du code bricolé à la va-vite reste souvent en production tel quel
Même dans les projets perso, les premiers commits sont désordonnés, puis on crée plus tard une branche de nettoyage pour remettre de l’ordre
Mais en entreprise, on a rarement le temps de faire une deuxième ou une troisième version, donc c’est finalement le premier jet qui part en prod
Honnêtement, je m’inquiète parfois à l’idée qu’un jour du code signé de mon nom fuite. Mais c’est la réalité
Quand on modifie du code et qu’on se dit « ça a l’air un peu forcé », le corriger tout de suite est au final le meilleur moyen de gagner du temps
Je n’ai pas encore assez de recul sur les LLM pour être affirmatif
Claude Code est essentiellement un produit simple, dont la vraie valeur réside dans le modèle lui-même
Autrement dit, c’est un produit à faible risque où une faible qualité du code ne pose pas de gros problème, ce qui a rendu ce cas possible
Cela ne viole pas non plus le concept de « vibe coding ». On donne des idées abstraites de haut niveau, et c’est l’IA qui écrit le code concret
Claude Code correspond au niveau AI Level 7 (humain pour la spec, bot pour le code), et l’auteur dit préférer le niveau 6
Le niveau idéal varie selon les personnes. Certains estiment que la limite est au niveau 5 ou moins, d’autres considèrent que le niveau 2 ou plus est déjà risqué
Le bon niveau dépend de la complexité et de la nouveauté du domaine
Par exemple, dans l’app que je développe, la partie algorithmique est au niveau 0, l’UI au niveau 7, et le middleware quelque part entre les deux
Le vrai savoir-faire consiste à trouver le niveau adapté à chaque zone du code
Dans les langages dynamiques, aller plus loin me met mal à l’aise. Si je devais monter au niveau 7 ou plus, je pense qu’il vaudrait mieux passer entièrement à un langage à typage statique
Le codage ne subsistera plus qu’en partie, comme la forge artisanale, et le reste sera automatisé
Mais cela permettra à une seule personne d’accomplir ce qu’une équipe entière faisait auparavant
La tentation est grande d’accepter une fonctionnalité sans comprendre complètement comment elle marche
L’auteur de ce texte est le créateur de BitTorrent. Ce n’est pas un simple blogueur
L’usage que je préfère avec Claude Code, c’est l’amélioration de la qualité du code
Des tâches qui sembleraient être une perte de temps pour un humain deviennent acceptables si une IA peut les faire presque gratuitement
Rationaliser des motifs de test répétitifs, garder une cohérence dans la sérialisation JSON, supprimer le code dupliqué, etc.
Au final, la base de code devient plus petite et plus facile à maintenir. C’est une sorte de linting à grande échelle
Je croise les résultats produits par chaque modèle, puis à la fin Opus établit la liste finale et applique les corrections
Il y a beaucoup de changements inutiles, mais les problèmes détectés sont réellement utiles
L’angle du « dogfooding » est intéressant
Le vrai sujet n’est pas la qualité du code, mais la capacité des utilisateurs à évaluer de manière critique les résultats de l’IA
Il y a une différence totale entre un ingénieur expérimenté qui garde son jugement en utilisant l’IA, et quelqu’un qui délègue ce jugement à l’IA
Le problème, c’est que les outils ne font pas la différence entre les deux, et que le marketing vise plutôt la seconde catégorie
Les défenseurs du « vibe coding » affirment que la qualité du code importe peu, parce que les LLM peuvent itérer bien plus vite que les humains
Pour un humain, chaque étape (écriture–vérification–correction) coûte cher, alors qu’un LLM peut itérer rapidement pour un simple coût en tokens
Mais je reste sceptique face à cette approche. J’ai vu trop de cas où ça casse en pratique
Cela dit, si les LLM continuent de progresser, ils auront peut-être raison
Sur le spectre du « vibe coding », il y a deux grandes catégories
D’un côté, les gens sans bagage technique qui trouvent ça fascinant ; de l’autre, les détracteurs de l’IA
Entre les deux existe une couche intermédiaire discrète mais très productive. Ces gens sont optimistes tout en étant expérimentés
J’ai moi-même dépensé environ 2 500 $ de crédits Claude Code sur les six derniers mois, et même si la plupart des résultats n’ont jamais été déployés, j’en ai tiré une valeur énorme
Je ne suis pas d’accord avec l’idée que « Claude Code ne sert à rien »
La plupart des webapps ne sont que des CRUD simples. 99 % des entreprises n’ont même pas 50 000 utilisateurs
Dans une entreprise où j’ai travaillé, à cause d’un code inefficace, il fallait faire tourner le programme 22 heures par jour
Ce phénomène fait penser à la théorie de l’innovation de Clayton Christensen
Les entreprises en place, satisfaites de leurs produits actuels très rentables, ignorent les nouvelles technologies de moindre qualité ; puis ces technologies finissent par suffisamment progresser pour renverser le marché
Claude Code est déjà à un niveau « suffisamment bon », et si l’IA continue de progresser, elle finira par dépasser le code écrit à la main
Autour du « vibe coding », on peut distinguer plusieurs profils
① les personnes ayant un intérêt financier, ② les développeurs fatigués du code, ③ les débutants qui construisent quelque chose pour la première fois
Les ② n’ont pas envie d’apprendre du neuf, et les ③ découvrent sincèrement la joie de créer
Le codage avec l’IA peut être pour eux une bonne porte d’entrée
J’en fais partie. Cela fait 30 ans que j’aime coder, mais le temps nécessaire pour concrétiser ce que j’imaginais était toujours trop long
Maintenant, cet écart disparaît, et cela me donne un sentiment de libération. Mon objectif est d’apprendre à aller plus vite sans sacrifier la qualité
À force de copier les problèmes des grandes entreprises, on a perdu en productivité et gagné en fatigue
Aujourd’hui, grâce à l’IA, on peut ignorer cette complexité et obtenir directement des résultats
Même si un nouveau framework ou une nouvelle méthode de déploiement apparaît, il n’est plus nécessaire de s’en soucier. L’IA s’en charge
Ce type de conflit se répète à chaque transition générationnelle dans la tech