Meilleur code, moins de tokens : les avantages de Code Connect dans MCP

Les agents de codage deviennent bien meilleurs pour transformer des designs en code. Mais sans le bon contexte, ils reconstruisent souvent votre UI à partir de primitives au lieu d'utiliser les composants de code de production que votre équipe maintient déjà. Cela peut donner l'impression que le résultat est correct, alors qu'il est inadapté à votre base de code. Cela peut également amener l'agent à consacrer plus de temps (et de tokens) à chercher, à deviner, à déboguer et à réécrire.

Lorsque les agents utilisent le serveur MCP de Figma, Code Connect peut leur fournir un contexte supplémentaire en connectant les composants Figma à des composants réels de votre base de code. Si Code Connect est configuré, les agents reçoivent des extraits de code pertinents pour la production dans la réponse MCP, au lieu d'une simple représentation React du design visuel.

Nous avons initialement conçu Code Connect afin d'améliorer le processus de passage du design au code pour les développeurs humains. Mais aujourd'hui, une quantité d'équipes et de types de rôles effectuent ce type de travail avec des agents de codage. Nous avons donc cherché à mesurer si, et dans quelle mesure, Code Connect améliore les performances des agents.

Lors de nos évaluations, nous avons constaté que, tout comme avec les développeurs humains, Code Connect aide les agents à adhérer aux design systems d'une entreprise et à produire de meilleurs résultats, plus rapidement. Nous avons testé des tâches de passage du design au code avec des agents utilisant le serveur MCP de Figma, à la fois avec et sans les modèles Code Connect configurés.

Nous avons constaté qu'avec Code Connect :

• La durée médiane des tâches a été réduite de 19,6 %.
• La qualité du code a augmenté d'un point complet sur une échelle de Likert de 1 à 4.
• L'utilisation de tokens pour la tâche médiane a été réduite de 29,5 %.

Cet article explique comment Code Connect fournit un contexte aux agents, comment nous avons mené les évaluations et ce que nous avons appris en cours de route.

Comment Code Connect enrichit la réponse du serveur MCP de Figma

Le serveur MCP de Figma permet aux agents de codage de récupérer un contexte structuré sur un design. L'un des outils clés, get_design_context, fournit à l'agent une description en code en React de ce qui se trouve sur le canvas. Le résultat est visuellement correct, mais comme l'agent ignore comment cela correspond aux composants de votre base de code, trois choses ont tendance à se produire :

• L'agent crée un nouveau composant de A à Z.
• L'agent choisit le mauvais composant de votre design system.
• L'agent trouve finalement le bon composant, mais effectue un travail inutile en cours de route, ce qui utilise des tokens supplémentaires.

Une fois les modèles Code Connect configurés, le serveur MCP de Figma remplace certaines parties du code React généré par des extraits de code fidèles à la production. Au lieu de deviner, l'agent dispose maintenant d'un véritable code à utiliser à partir de votre base de code. On lui indique précisément quel composant importer et quelles valeurs de propriété transmettre.

Voici un exemple de la différence en pratique. Sans Code Connect, le serveur MCP de Figma transmet du code React à l'agent de codage de la manière suivante :

<div role="tablist" className="flex gap-1 rounded-md bg-gray-100">
  <button className="bg-white shadow rounded">Design</button>
  <button className="text-gray-600">Code</button>
</div>

Avec Code Connect, l'agent de codage reçoit un extrait de code précis qui puise dans votre design system existant, et il lui suffit alors de l'utiliser au bon endroit :

<SegmentedControl value="design" options={["Design", "Code"]} />

Comment nous avons mesuré l'impact de Code Connect

Nous avons développé un dispositif d'évaluation qui exécute la même série de tâches de conversion de design en code de deux manières : l'une sans Code Connect et l'autre avec des modèles Code Connect. Pour chacun de nos 27 cas de test, nous avons mesuré la qualité du code, l'utilisation des tokens et la durée.

Nous avons testé deux design systems, tous deux basés sur React : Simple Design System (SDS), le design system de démonstration de Figma, et Figma Pattern Library (FPL), notre design system interne, plus grand et plus complexe. Le SDS est très bien intégré à Code Connect ; en moyenne, les réponses MCP que nous avons testées comprenaient 20 % d'extraits Code Connect. Le FPL est un exemple de design system réaliste présentant une couverture Code Connect plus inégale, où Code Connect représentait environ 6 % des réponses.

Les juges LLM ont comparé le résultat final à des extraits de code que nous savons être corrects, et qui correspondent à ce que nous aimerions que l'agent produise dans l'idéal. Ces éléments ont été évalués selon la grille de critères de qualité du code suivante :

1. Exactitude : la mise en œuvre répond-elle correctement aux exigences de la tâche ? Y a-t-il des bugs, des erreurs de logique ou des fonctionnalités manquantes ?
2. Qualité du Code : le code est-il propre, idiomatique et bien organisé ? Suit-il les conventions du langage/framework utilisé ?
3. Maintenabilité : le code est-il lisible, bien structuré et facile à modifier ? Les noms des variables/fonctions sont-ils explicites ? La complexité est-elle bien gérée ?
4. Exhaustivité : la mise en œuvre couvre-t-elle tous les aspects de la tâche ? Les cas particuliers sont-ils traités de manière appropriée ?
5. Bonnes pratiques : gestion correcte des erreurs, sécurité du typage, considérations de performances, accessibilité et sécurité ? Pas de complexité inutile ou de code mort ?

Le score final reposait sur une échelle de Likert en 4 points (de 1 à 4) :

1. Défectueux : le code présente des erreurs de syntaxe, plante ou ne parvient pas du tout à accomplir la tâche.
2. Médiocre : le code fonctionne partiellement mais présente des problèmes importants – mauvaises pratiques, absence de gestion des erreurs, structure déficiente ou problèmes majeurs de correction.
3. Bon : une mise en œuvre solide avec des problèmes mineurs – légères incohérences de style, quelques cas particuliers manqués ou redondances mineures.
4. Excellent : code propre, idiomatique et bien structuré qui accomplit correctement la tâche et observe les bonnes pratiques.

Certaines de ces exécutions contenaient des designs complexes à mettre en œuvre. De bout en bout, certaines exécutions (y compris le lancement de toutes les variantes plusieurs fois, pour écarter les cas atypiques) ont nécessité plus de 24 heures. Du côté du modèle, nous avons testé à la fois Claude Sonnet 4.5 et Claude Opus 4.7.

Le résultat ?

Par rapport à la référence sans Code Connect, les tâches utilisant des modèles Code Connect ont donné les résultats médians suivants pour l'exécution de bout en bout de l'agent, lors de l'utilisation de get_design_context :

• Qualité du code : +1, de 2 à 3, sur une échelle de Likert de 1 à 4
• Utilisation des tokens : -29,5 %
• Durée : -19,6 %

S'agissant de médianes, ces chiffres masquent certaines des tendances observées entre les différents cas. Le facteur déterminant ayant le plus influencé les chiffres est la couverture Code Connect ; celle-ci combine deux éléments : la proportion de designs de transfert constitués de composants du design system, et le nombre de ces composants qui sont effectivement connectés à Code Connect. Plus ces deux paramètres sont élevés, plus la proportion d'extraits Code Connect par rapport au code React standard est importante dans la réponse de l'outil get_design_context, ce qui se traduit par un meilleur rendu visuel des résultats.

Il convient également de noter que le Simple Design System représente un cas plus simple pour un LLM. Comme il s'agit de notre design system de démonstration, la correspondance entre le design et le code est déjà bonne en ce qui concerne les noms des composants et des propriétés. Cela étant, nous avons constaté des améliorations plus importantes qu'avec notre design system FPL, la couverture Code Connect étant plus élevée dans le SDS. Dans le cas du SDS, nous avons connecté la quasi-totalité des composants à Code Connect.

Lorsque la couverture de Code Connect est élevée, les agents ont tendance à effectuer moins d'appels d'outils exploratoires et à passer moins de temps à rechercher par « grep » des noms de composants et d'icônes. Dans l'exemple FPL ci-dessous, les exécutions sans Code Connect ont inspecté le dossier node_modules, effectué de vastes recherches textuelles via grep pour trouver des noms d'icônes et, dans plusieurs cas, ont conçu manuellement la barre d'onglets à partir de zéro tout en s'acharnant sur du CSS personnalisé. Avec Code Connect, l'agent a accédé directement aux véritables composants Tabs et Button, terminant en environ 77 % du temps et avec environ 62 % des tokens.

Les résultats en termes de qualité du code sont tout aussi intéressants. Sans Code Connect, l'agent de codage a conçu manuellement les onglets et les boutons en tant que code React brut et CSS. Même si l'aspect visuel est proche, ce n'est même pas fonctionnel : les onglets ne sont pas interactifs et sont codés en dur pour reproduire le design, y compris l'état « sélectionné » ! Notez également les légères différences au niveau des icônes et des marges internes – des détails cruciaux pour un produit de haute qualité ; les exécutions réalisées avec Code Connect se sont beaucoup plus rapprochées de l'original.

Voici un exemple d'extrait de code issu du résultat sans Code Connect :

{/* Plain divs for the tabs */}
<div className="lv-tabs">
  <div className="lv-tab lv-tab-inactive"><span className="lv-tab-text-inactive">File</span></div>
  <div className="lv-tab lv-tab-active"><span className="lv-tab-text-active">Assets</span></div>
</div>

…


{/* Raw button element */}
<button className="lv-browse-btn">
  <span className="lv-browse-btn-text">Browse team libraries</span>
</button>

…

/* CSS: ~300 more lines*/
.lv-tab { display: flex; align-items: center; gap: 4px; height: 24px; padding: 0 8px; border-radius: var(--radius-medium, 5px); }
.lv-tab-inactive { background: var(--color-bg, white); }

Avec Code Connect, l'agent de codage a correctement importé et utilisé les composants du design system, produisant un code plus succinct et de meilleure qualité :

{/* Usage of the FPL tab component */}
const [tabPropsMap, tabPanelPropsMap, tabManager] = Tabs.useTabs<'firstTab' | 'secondTab'>(
  { firstTab: true, secondTab: true },
  { defaultActive: 'secondTab' },
)

<Tabs.TabStrip manager={tabManager}>
  <Tabs.Tab {...tabPropsMap.firstTab}>File</Tabs.Tab>
  <Tabs.Tab {...tabPropsMap.secondTab}>Assets</Tabs.Tab>
</Tabs.TabStrip>

…


{/* Usage of the FPL Button component */}
<Button variant="primary" width="fill" onClick={() => {}}>
  Browse team libraries
</Button>

Conclusions pour quiconque concevant avec des LLM

Les agents ne savent pas automatiquement ce que signifie un « bon » code dans votre entreprise – vous devez leur fournir le contexte correct. Livrés à eux-mêmes, ils consacreront du temps et des tokens à rechercher les bons composants dans votre design system, ou ils les reconstruiront volontiers à partir de zéro. Le résultat pourrait sembler visuellement correct, mais le code pourrait ne pas correspondre à ce que vous souhaitez intégrer dans votre base de code. Pour bien faire leur travail, les agents ont besoin d'un contexte plus explicite et structuré – dans ce cas, un véritable extrait de code montrant comment mettre en œuvre le composant dans votre base de code.

Si vous utilisez déjà le serveur MCP de Figma, vous pouvez étendre l'utilisation de Code Connect à une plus grande partie de votre design system pour passer du design au code plus rapidement, à moindre coût et avec une qualité supérieure. Vous pouvez suivre le guide ici.