Tech • IA • Robotique • Jeu
N'utilisez surtout pas ces deux outils (voici quoi utiliser à la place)
6/10INTRO
SuperPower et BMAD suscitent de vives critiques de la part d’utilisateurs avancés de Claude Code, qui estiment que ces frameworks ajoutent un énorme surcoût de prompt, des coûts en tokens plus élevés et des workflows plus lents, sans produire un code réellement meilleur.
POINTS CLÉS
Pourquoi le rejet s’intensifie
SuperPower et BMAD sont présentés comme des accélérateurs de productivité pour le codage avec l’IA, avec des promesses de livraison plus rapide et d’une meilleure structure. Pourtant, leurs détracteurs soutiennent l’inverse: ces outils imposent souvent des workflows rigides en plusieurs étapes à des tâches que les modèles modernes peuvent déjà accomplir directement. Le reproche central est qu’ils donnent une apparence de professionnalisme tout en rendant le travail courant plus lent et plus coûteux.
Forte adoption, réputation mitigée
SuperPower est associé à environ 300,000 GitHub stars et près de 1 million d’installations dans l’écosystème Claude Code, tandis que BMAD affiche environ 54,000 stars. Ces chiffres témoignent d’un fort engouement et d’une grande visibilité, mais ils ne tranchent pas la question de savoir si ces méthodes améliorent réellement les résultats. Selon les critiques, cette popularité relève davantage de la preuve sociale et du branding que de gains mesurés en efficacité développeur.
Ce que sont réellement ces outils
La critique porte sur le fait que ces deux produits sont essentiellement de vastes collections d’instructions Markdown, de règles et de fichiers de workflow, plutôt que de nouvelles capacités de modèle. BMAD comprendrait plus de 31 skills, 274 fichiers Markdown et plus de 12,000 lignes de texte, pour un total d’environ 1.7 million de caractères, soit près de 350 pages. SuperPower est décrit de façon similaire, avec plus de 15 skills et de nombreux fichiers de processus obligatoires.
Des workflows lourds pour des changements simples
Selon leurs opposants, BMAD peut exiger un brief, un document d’exigences produit, un fichier UX, un document d’architecture, des epics, des stories, des builds et des revues avant même de commencer à coder. SuperPower est critiqué pour des étapes comparables, comme le brainstorming, la mise en place du workflow, les tests et la revue de code, même pour des fonctionnalités ordinaires. Le résultat, disent-ils, est un framework qui traite de petites tâches comme s’il s’agissait de programmes de livraison à l’échelle d’une grande entreprise.
Injection de prompt et gonflement du contexte
Un reproche technique majeur est que ces frameworks injectent de grandes quantités de texte d’instructions au démarrage de la session via des hooks et le chargement de skills. Les critiques disent que le modèle doit ainsi lire des pages de règles avant de traiter la demande réelle, et qu’il peut être forcé d’invoquer certains skills dès qu’il existe la moindre chance qu’ils s’appliquent. En pratique, cela peut consommer très vite la fenêtre de contexte et laisser moins de place au vrai problème de code.
Des recherches citées contre les prompts longs
Les critiques invoquent des constats plus larges sur le comportement des LLM: la fiabilité tend à baisser à mesure que la longueur des entrées augmente, et les modèles peinent souvent avec les informations enfouies au milieu de longs contextes. Cela rejoint l’effet bien connu de lost in the middle, où les tokens du début et de la fin reçoivent plus d’attention que les blocs d’instructions denses au centre. L’argument est que des workflows gonflés ne coûtent pas seulement plus de tokens; ils peuvent aussi rendre le modèle moins précis.
Plus d’agents, plus de coûts
Une autre objection vise l’usage de multiples sous-agents, de nouveaux chats et de boucles de revue répétées pour un travail qu’un seul modèle pourrait souvent accomplir en une fois. BMAD ouvrirait un nouveau chat pour chaque étape du workflow afin d’éviter le débordement de contexte, mais les critiques rétorquent que cela ne fait que multiplier l’usage de tokens d’une étape à l’autre. L’effet global est décrit comme le fait de payer plusieurs fois pour accomplir la même tâche.
L’argument en faveur de skills plus simples
À l’inverse, des approches de prompting plus légères sont présentées comme de meilleures alternatives. De petits skills fondés sur des questions de clarification et une planification légère sont préférés aux frameworks complets. Un exemple souvent cité est le style de prompting compact de Matt Pocock, avec certains skills de seulement 6, 25 ou 40 lignes, contre des fichiers de framework qui s’étendent sur des centaines, voire des milliers de lignes.
La plupart des changements logiciels sont petits
Les critiques soutiennent aussi que la tâche moyenne de codage ne justifie tout simplement pas un processus aussi lourd. Ils citent des tendances internes en ingénierie montrant que beaucoup de modifications de code sont minuscules: le changement médian chez Google serait d’environ 24 lignes, et près de 10% n’affecteraient qu’une seule ligne. Si la majorité du travail réel est petite, imposer à chaque changement une longue machine de spécification et de revue est, selon eux, inefficace par conception.
Une alternative en trois étapes
Le remplacement proposé est simple: définir clairement le besoin, aligner le prompt sur le résultat visé, puis laisser le modèle exécuter. Au lieu d’inventer des équipes d’agents fictifs ou de générer plusieurs documents de planification, on pose au modèle des questions directes sur la fonctionnalité, son public, son apparence attendue et la façon de vérifier qu’elle est terminée. L’idée de fond est que les modèles plus puissants gèrent désormais naturellement la plupart des tâches de codage, rendant de nombreux anciens frameworks de prompt obsolètes.
CONCLUSION
Le débat autour de SuperPower et BMAD reflète un changement plus large dans le codage avec l’IA: à mesure que les modèles progressent, les développeurs remettent de plus en plus en question la valeur réelle des frameworks de prompt élaborés face au surcoût qu’ils imposent. Pour de nombreux utilisateurs avancés, la règle émergente est simple: moins d’instructions, moins de cérémonial et plus de prompting direct.
Poser une question