L’article explique pourquoi les IA comme Claude génèrent du code standard, souvent éloigné des conventions spécifiques d’une équipe, et propose une solution via les rules. Sans instructions précises, l’IA se base sur des pratiques moyennes en ligne, ce qui peut entraîner des incohérences dans une base de code. Les rules permettent d’intégrer les bonnes pratiques internes sous forme d’instructions claires, comme des conventions de nommage ou des principes architecturaux, afin d’harmoniser le code produit.

Les rules sont des directives écrites au format DO/DON’T, intégrées à la session de l’IA pour guider ses choix. Elles couvrent des aspects variés, des unités de mesure aux bonnes pratiques comme le debounce pour optimiser les performances. Ces règles, une fois formalisées, réduisent les corrections répétitives en revues de code et facilitent la transmission des savoir-faire techniques au sein de l’équipe.

L’ajout excessif de contexte dans les instructions ou spécifications pour les agents de codage peut nuire à leur performance plutôt que de l’améliorer. Au-delà d’un certain seuil, ces agents deviennent confus, mélangent des détails de différents documents et génèrent des réponses erronées, notamment lorsque les spécifications deviennent trop détaillées ou obsolètes. Par exemple, des fichiers de spécifications trop techniques ou volumineux, initialement conçus pour décrire des comportements, finissent par inclure des détails d’implémentation qui induisent en erreur l’agent.

La question centrale soulevée est celle de la source de vérité dans le développement logiciel assisté par IA. Ni les tests, ni le code, ni les spécifications ne suffisent à eux seuls à garantir une compréhension fiable, car chacun reflète une réalité différente : les tests valident le comportement actuel, le code représente l’implémentation réelle (y compris ses défauts), et les spécifications, si elles ne sont pas maintenues, deviennent rapidement obsolètes. Sans une source de vérité claire et à jour, les équipes et les agents se retrouvent à deviner les intentions initiales, ce qui conduit à des incohérences.

Pour résoudre ce problème, une distinction utile consiste à séparer deux types de vérité : d’une part, la vérité exécutable (le code et les tests), qui reflète l’état actuel du logiciel, et d’autre part, la vérité intentionnelle (les objectifs, les contraintes architecturales et les attentes fonctionnelles), qui guide les évolutions futures. Cette séparation permet d’éviter que les agents ne s’appuient sur des informations contradictoires ou obsolètes, et clarifie le rôle de chaque élément dans le processus de développement.