Design to code, on your real codebase.

Design to code is the work of turning a design, such as a Figma frame, a screenshot, a written description or a change made on a canvas, into code a team can review and merge. The four common routes are a Figma file read by a coding agent or plugin, a screenshot, a prompt, and designing directly in code on a canvas. They differ mainly in how much of the target codebase they can see.

Not on its own. The Figma MCP server gives a coding agent such as Claude Code or Cursor design context from a selection, and Figma's docs say it is not designed to return production-ready code. The agent writes the code, and Code Connect or a rules file is what maps Figma components to the components in your repository.

Yes, Claude Code, Cursor, v0 and Anima all accept an image and produce markup that matches its layout and colors. The result is a starting point, because the model sees pixels and cannot know which of your components, tokens or states the picture shows. Point it at the target component and tokens in your repo before you ask for the code.

Designing in code means changing the running product on a canvas with design controls, so the code is the output of the design work rather than a translation of it. The designer does not write the code, and engineers still review the resulting pull request. Onlook, Cursor Design Mode and Modeinspect are tools built around this route.

It works when the route can see the codebase: the existing components, the design tokens, the file and styling conventions, and the pull request review that gates every change. Prompt-first tools build a fresh project, Figma and screenshot routes need a mapping or rules file, and design in code tools work on the connected repository directly.