The button already exists. Even so, an AI agent creates a new one with its own colour, different spacing and an extra variant. In the screenshot, the replica looks similar. In the project, however, a second component has appeared that would have to be maintained separately from now on. The problem is not merely image understanding but missing component identity.
Figma Code Connect links design components with their counterparts in code and makes these relationships usable for Dev Mode and MCP. The current documentation thus describes a specific route for context. It does not demonstrate any blanket improvement in quality or cost. Our question is: what information does an agent need in order to actually reuse the existing button?
The variant is a contract
Our own example component is called QuietButton. It has a primary and a secondary appearance as well as a disabled state. The instruction is not “Build something similar” but “Use this component in a permitted configuration”. That sounds obvious, but it requires a precise relationship between design and code.
Design: understated action button
Code: QuietButton
Allowed variant: secondary
Label: View details
State: enabledThis card is a mapping schema of our own, not a Code Connect configuration file. It makes visible where an agent would otherwise have to guess. A similar-sounding value such as “quiet” is not automatically a valid parameter if the actual component expects “secondary”.
The same applies to content and state. A button that is dimmed for decoration may be implemented differently from a control that is actually disabled. The visual impression alone is therefore not enough for the technical mapping.
One small real example is better than a long style description
Alongside the mapping, give the agent an existing usage. For a simple HTML component, it could look like this:
<button class="action action--secondary" type="button">
View details
</button>The classes belong to our example. Which CSS rules they carry has to be determined by your own project. The added value is that the agent is not expected to invent a new structure first. It gets a concrete starting point with limited changes.
A useful addition names what should be preserved: the same component, valid variants, existing keyboard operation and the actual purpose of the action. An extensive collection of material with contradictory examples could help less than a short, current excerpt.
Outdated mappings can look very convincing
Suppose the project renames a property. The old mapping remains understandable and neatly formatted. For the agent it is plausible context, but technically wrong. The connection to the current code therefore has to be maintained as well.
For a practical review of what you already have, choose three frequently used components. Note one real usage of each and its permitted variants. Compare these details with the current code before you publish a new mapping. This suggested exercise does not claim that a repository review has already been carried out or that an AI run has passed.
A counter-case sharpens the mapping: what should happen if the design calls for a variant that the component does not have at all? Instead of quietly inventing a new button, the implementation should name this gap. Missing context then becomes a deliberate design decision that can be made in the actual project.
Brand values complement the component but do not replace it
If you reuse a page component of your own in KENJTEC, the brand sheet from KENJTEC BrandStudio ai can provide specific colours, fonts and shapes. Apply these values deliberately to the existing HTML/CSS example instead of having the component reinvented from an image alone.
Your own HTML, CSS and JavaScript can then be prepared manually in the developer mode of KENJTEC WebSiteBuilder ai, viewed separately in the preview and published as custom code. This does not mean an automatic Code Connect import or React app hosting. The mapping stays in your external development workflow.
The technical lesson is transferable: a design system does not consist only of similar shapes. It needs verifiable relationships between visible variants and actual components. The more concrete these relationships are, the less an agent has to guess and the easier it is to judge its result against the existing project.
Sources and status
Research and documentation as of 25 October 2026. Code Connect: Introduction.
