Design to code

Handing a design to an agent usually means pasting an image and hoping. Studio hands over a structured document instead, and the useful part of it is the parts that point back into your repository.

What the agent receives

• The screen's semantics, not its markup: what each element is, how it is laid out, and how it responds, extracted from the design's own representation rather than scraped from rendered HTML.
• The tokens it uses, matched against the tokens that already exist in your project. Where a design variable corresponds to a code token, the handoff says so, so the agent writes your token name rather than a hex value that will be wrong the first time someone changes the theme.
• Component bindings. Where a design component corresponds to a component in your codebase, the binding carries the source path and how confident the match is. An agent that knows the button on this screen is packages/ui/Button.tsx writes an instance; one that does not writes a new button.
• The node ids, carried into the code. This is small and it pays twice: it makes a later fidelity comparison exact, and it makes an automated tap on that element unambiguous when the flow becomes a test.
• The motion, as the compiled CSS described in Motion.
• The assets the screen actually uses.

Where unmatched components go

A binding that matched is a fact. A binding that did not is also information, and it is reported as such rather than dropped: these are the components this screen needs and your project does not have yet.

That turns a handoff into a work list instead of an argument about whether the implementation is faithful.

The other direction

The same map works backwards. Studio can read the components and tokens that exist in your project, which is what lets a design be authored against what is really there, and what lets a code connect draft be generated for the components that correspond.