Claude Design meets coding agents (a workflow that actually ships)

For most of my career, the gap between "I have an idea for a screen" and "the screen exists in production" was measured in days. Sometimes weeks. There was a Figma round, a developer round, a back-and-forth round, an "actually that doesn't work in dark mode" round. Each round had a handoff, and each handoff lost a little bit of intent.

In the last six months, I've collapsed that loop. The screen you're reading right now — including the typography, the dark-mode reading variant, the marginalia in the gutter — went from "vague idea" to "deployed" in about an hour. Not because I got faster at design or faster at coding, but because I stopped doing them as separate jobs.

The setup is small. Claude Design for the design pass, a coding agent (Cursor, Claude Code, take your pick) for the implementation pass. The trick is in how they hand off to each other.

What Claude Design actually is

Claude Design isn't Figma. It doesn't produce vector files or component libraries. What it produces is a working HTML/CSS/JS prototype — a real, browser-renderable file with real fonts, real animations, real hover states. You describe the screen in plain language, iterate on it conversationally, and at the end you have an .html file that already looks like what you wanted.

That distinction matters more than it sounds. A Figma file is a picture of a UI. An HTML file is a UI. Every layout decision is already encoded as CSS. Every interaction is already JavaScript. There's nothing to "translate" — there's only a question of which framework you want to translate it into.

The handoff isn't a screenshot. It's the implementation, written in the wrong framework.

The handoff format

Claude Design exports its output as a tiny project bundle: a README.md and a project/ folder with the HTML, the assets, and any helper components. The README is written for the next agent in the loop — it contains a paragraph that says, roughly: "the user opened this file last, here's what they probably want."

That paragraph is the entire interface between the two halves of the workflow. You don't write it. You don't read it. You just attach the bundle to your coding agent and say "implement this." The agent reads the README, opens the HTML, and figures out what to do.

This sounds trivial. It is not. The reason it works is that Claude Design and the coding agent have the same model behind them, which means they share a vocabulary, share an aesthetic sense, and read code the same way. There's no impedance mismatch.

What the coding agent actually does

When I drop a Claude Design bundle into Cursor, the agent does roughly this:

1. Reads the prototype top to bottom. Not skims — reads. Every CSS rule, every animation, every breakpoint.
2. Maps it onto the existing codebase. "This is a Next.js project, App Router, no Tailwind. The prototype uses CSS variables. Existing variables live in globals.css. New rules should append, not replace."
3. Asks one or two clarifying questions if the design has implications it can't infer (e.g. "this needs MDX — do you want .mdx or pure markdown?").
4. Writes the plan, not the code, first. A short list of files to create and files to modify.
5. Implements. Components, routes, CSS, content, dependencies — all in one pass.

The whole thing is one conversation. I don't switch tools, I don't open a Jira ticket, I don't open Figma. The design lives next to the code lives next to the deploy.

Why this works

There are three things going on that make this loop fast.

The first is shared context. When I'm in Cursor with a .html prototype open and a Next.js project open in the workspace, the agent sees both. It can read the prototype's CSS variables and check if my project already defines --accent or --ink. If it does, the agent reuses them. If it doesn't, the agent extends them. There's no manual translation step.

The second is granularity. Both halves operate at the level of "the whole feature." Claude Design doesn't give you a button library — it gives you a screen. The coding agent doesn't give you a stub — it gives you the route, the component split, the styles, and the wiring. The unit of work is "a thing that's done."

The third is tight coupling between sense and code. A traditional design tool produces an artifact you have to interpret. The interpretation is where most of the cost is — figuring out what the designer meant by "this should feel premium." Claude Design produces an artifact where the meaning is already encoded as code, which means the next agent doesn't have to interpret. It has to translate, which is a much cheaper operation.

What it's not good at (yet)

Honest accounting:

• Complex state. A multi-step form with validation rules, optimistic updates, and error states is still a place where you want a human in the loop. The prototype shows the visual flow; the agent needs guidance on the state machine.
• Accessibility nuance. Both tools handle the basics — semantic tags, focus rings, aria-labels. The harder cases (focus traps, live regions, screen-reader announcements) need explicit prompts.
• Cross-route consistency. Each Claude Design export is a single screen. If you want a navigation bar that's consistent across /, /blog, and /projects, you need to wire that up yourself or feed all the screens at once.
• Performance budgets. Neither tool will tell you that a particular animation is jank on mid-tier Android. That's still your job.

None of these are dealbreakers. They're places where the loop hands back to a human, the same way a senior engineer hands back to a junior on a tricky bug.

The actual time savings

Numbers from the last few projects I've shipped this way:

• Idea to clickable design: 20-40 minutes in Claude Design (vs. 2-4 hours in Figma).
• Design to deployed: 1-3 hours in a coding agent (vs. 1-3 days in a normal handoff).
• Iteration on a deployed design: 5-15 minutes per round (vs. an hour or more, because the design and code now live in the same conversation).

Most of the savings aren't in any one step. They're in not switching contexts. The cost of "now I have to open Figma, find the right frame, screenshot it, paste it into Slack, write a JIRA ticket" is enormous. When the design and the code share a conversation, that cost goes to zero.

The thing this actually is

I keep wanting to call this "AI-assisted design-to-code" and that's not quite right. It's not assistance — it's a new shape of the same job. The role I used to play, where I'd open Figma, sketch a layout, then open VS Code and reimplement it from memory, was always a stupid round-trip. I was the bottleneck and the translation layer. Two agents doing the same job, badly, in series.

What this loop actually does is collapse that. One pass to figure out what the screen should be. One pass to make it real. I'm still in the loop — I'm steering, I'm reviewing, I'm catching the things the agents miss. But I'm not the translation layer anymore, and that's the part of the job I never enjoyed anyway.

If you're a designer-developer hybrid, or a solo founder, or a team that's tired of the Figma-to-code round-trip, this loop is worth trying. Start small: pick one screen on an existing site, take it to Claude Design, hand the export to your coding agent, and see how close you get on the first pass.

I think you'll be surprised. I was.