Deux problèmes dans le modèle mental par défaut de Claude.
Premier problème :
Son processus fonctionne comme ça :
1. Mock
2. Implémentation
3. Affinage
Ça marche super, mais tout ça est chamboulé à chaque opération de compaction.
Comme Claude ne se rappelle plus que les mocks sont là, il les valide comme si vous les aviez conçus.
Ma solution pour contourner ça, c’est de créer des epics et de demander à la machine d’y inscrire l’analyse et l’état d’avancement détaillés au fur et à mesure.
Second problème : les bugs vus comme des erreurs :
Les bugs ne sont pas des erreurs. Aucun développeur chevronné ne vous dira jamais qu’un bug est une erreur. Vous ne devriez jamais considérer les bugs comme des erreurs, parce que ce n’est pas ce qu’ils sont. C’est offensant de voir les bugs comme des erreurs ou des échecs. Je ne lâcherai pas sur ce point.
Au contraire, les bugs sont la preuve que la structure de votre app ne fonctionne pas comme vous l’espériez. Rien de plus, rien de moins.
Chaque bug est une donnée précieuse dont vous avez réellement besoin pour affiner et livrer votre produit.
Vous n’aimez peut-être pas voir des bugs. Certes.
Mais une bonne QA n’est pas faite pour les cœurs fragiles.
Claude ne comprend pas ce principe par défaut.