Le culte du vibe coding est insensé

• 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é