Design to Code in 2026

For most of the last decade, going from design to code meant a developer opening a Figma file, reading off pixel values, and rebuilding the layout in CSS. Auto layout and design tokens narrowed the gap, but a manual translation step remained. In early 2026, three updates converged that finally make the workflow feel structurally different rather than just slightly faster.

What actually changed

The first is Figma's expanded Draw Mode, which now absorbs the auto-layout logic into a single, consistent positioning model. The same node tree that designers manipulate visually is the one a code generator can walk reliably – no more inferring intent from absolute positions that happen to align by accident.

The second is the maturation of LLM-driven component matching. Tools like Figma Code Connect plus capable agents can now look at a node in a design file and pick the right component from a project's actual codebase – using component metadata, prop types, and even prior mappings as hints – rather than emitting a fresh, unstyled approximation.

The third is honest, two-way CSS variable round-tripping. The same tokens that drive Figma variables now serialise cleanly to CSS custom properties, with light, dark and high-contrast modes coming along as first-class siblings rather than separate component variants that drift.

Where it still breaks

Three categories of friction remain. They are the ones we run into on almost every project that ships to a real codebase.

Animation

The handoff for "the card should slide in from the right when scrolled into view" is still essentially a written description and a screen recording. No tool we know of round-trips motion specs in a production-ready way. We expect this to be the next big seam to close.

State ownership

Visual states are easy – the design system covers hover, active, disabled, focus. But who owns the truth about which state the component is in at any given moment is still a manual conversation between designer and engineer.

Naming

Two designers will name the same component three different ways before lunch. The agent picking up that component to map to code has to make a guess. Sometimes it is right. Sometimes you get <Card variant="featured"> when the codebase already has <HighlightedCard>.

The artefacts designers and engineers swap become smaller, more typed, and more honest.

How we work today

In the studio, we have shifted our defaults. The design system is the source of truth – not the screen mockups. We invest more time up front in tokens, variables and component metadata than we used to, and less in pixel-perfect specs of one-off screens. The trade-off pays back in code that needs less translation later.

Concretely, our standard project setup now includes:

• Token plan in week one, before any screen design.
• Code Connect mappings on every component that touches a real codebase.
• Light, dark and high-contrast modes scoped at the token level, not the component level.
• Documented naming conventions shared between Figma and the repo.

A minimal Code Connect mapping looks roughly like this:

// figma.config.json (excerpt)
{
  "componentMappings": {
    "ds/Button/Primary": "src/ui/Button.tsx",
    "ds/Card/Default":   "src/ui/Card.tsx",
    "ds/Card/Featured":  "src/ui/HighlightedCard.tsx"
  }
}

What we expect next

We expect the next year to bring serious motion handoff – meaning a designer can express the timing curve and trigger of a transition inside Figma, and the result lands in code in a form that survives more than one developer reading it. We also expect design system as source of truth to stop being an opinion and start being the default workflow inside the tool itself, with screen-level mockups becoming a downstream artefact rather than the canonical one.

If those land, the manual translation step finally disappears for most flows, and the design-to-code conversation is replaced by a design-system-to-product conversation. Which is a much better problem to be having.

---

None of this means designers and engineers stop needing each other. It means the artefacts they swap become smaller, more typed, and more honest. The translation gets cheaper, so the conversation can be about the actual product.