Design to code takes a design, either a file from a design tool with frames, components and tokens, or a mockup, and turns it into components in a real codebase. Some tools read the design file's structure directly, its component tree, variants and tokens, through a connection from the editor. Others work from an exported image.
It sits on this rung rather than at the base because of where its output lands. A screen generated inside a site builder belongs to the builder. Components generated into your repository belong to you, and somebody will maintain them for as long as the product lives.
What it is for
- Building a designed screen in a codebase that already has components and tokens, faster than translating it by hand.
- Keeping a design system and its implementation in step, where both use names a tool can match.
- A first pass at a new component, which a developer then shapes to fit the system.
Who it suits
Front-end developers and design engineers working from structured design files. Teams with a design system in code, where the tool's job is to use the system rather than recreate it. It is strongest when a design system already exists and weakest when it does not, because the tool will invent one.
How to tell this is your category
- Your input is a design, ideally with named components and tokens, rather than a description.
- The output is components in a repository you own, reviewed like any other change.
- If the input is a picture and the output lives inside a builder, that is screenshot to app, on the base rung.
What it costs you later
The layer page names the headline: with a design system in place this category is strong, and without one you inherit one-off components and values nobody chose. This is how that inheritance shows up.
- Two of everything. If the tool does not know which components your codebase already has, it builds new ones that look the same: a second button, a second card, a second dialog, each slightly different. Every later change to the real button misses the copies. Tell it which components exist and where they live, and reject any change that adds a lookalike.
- Literal values where tokens belong. A design file holds colour and spacing as values. Unless the tool maps them to your tokens, they land in the code as literals, scattered across components. The day the brand colour changes, you find out how many places hold it.
- Behaviour the design never showed. A design shows layout. It rarely shows focus, hover, disabled, loading, error and empty, how a menu behaves from the keyboard, or what happens when the content is twice as long. Each gap gets filled plausibly, and an undesigned state is a state the tool invents. List the states each component needs before it is generated. Designing a feature an AI coding agent cannot improvise has the list.
- Visual structure is not semantics. Layer names in a design file are not accessible names, and a group that looks like a list is not one until the markup says so. Headings, labels, roles and focus order have to be checked in the generated code, with a keyboard and a screen reader, not in the design.
- Two sources of truth. After the first generation, the design and the code start to diverge. A developer fixes an edge case in code, a designer changes the spacing in the file, and generating again from the updated design can overwrite the fix. Decide, per component, which one is the source of truth once it exists in code, and bring the other into line by hand.
Making it work
- Put the design system in the agent's context: the component list, the tokens, and one example of a component written the way your codebase writes them.
- Name design components to match code components, so the mapping is a lookup rather than a guess.
- Generate one component at a time and review it as a change, rather than a whole screen at once.
- Treat the output as a draft that has to fit the system, and fix the fit before merging, not after.