Règles · repris de LinkedIn

Trois règles entre un composant bien posé et une hallucination

Des dizaines d'interfaces Figma générées avec Claude via MCP : les trois règles d'écriture qui font la différence.

Article · le fil se lit aussi sur LinkedIn

J'ai généré des dizaines d'interfaces Figma avec Claude via MCP. À force, un motif se dégage : la différence entre un composant bien posé et une hallucination ne tient presque jamais au modèle. Elle tient à trois règles d'écriture du design system.

1. Chaque composant a une règle d'usage contextuelle

Pas juste ses props : une phrase qui dit dans quel contexte il s'utilise, et dans quel contexte il ne s'utilise jamais.

Exemple : chez nous, une erreur bloquante utilise le composant Banner, jamais un Toast. L'agent, lui, choisit le Toast par défaut. Parce que c'est le plus courant partout ailleurs, sauf chez toi.

2. Les combinaisons de composants ont leurs propres règles

Quand deux composants apparaissent ensemble, il y a des règles que ton équipe connaît par cœur mais que personne n'a jamais écrites. Un bouton primaire et un bouton secondaire dans une même barre d'action : le primaire est toujours à droite. Un champ de recherche n'est jamais suivi d'un bouton « Filtrer » sans séparateur.

Ton équipe applique ça sans y penser. L'agent, lui, ne connaît pas ces règles tant que tu ne les as pas écrites quelque part. Je les documente en YAML : une machine lit du YAML, elle ne browse pas une doc Notion.

3. Des bulles de contexte, pas tout le DS d'un coup

Selon la tâche (formulaire, tableau, navigation), l'agent reçoit uniquement le contexte pertinent. Moins de contexte, moins d'hallucinations.

Tu as déjà ce genre de règles dans ton design system, même informellement ? C'est exactement la matière qu'il faut écrire : le jour où une IA lit ton système, ce sont elles qui font la différence.

La discussion continue sur LinkedIn