This guide breaks down the full design-to-code workflow using AI tools. We'll cover what the new workflow looks like, why it matters now, and then walk through the exact steps — from setting up your environment to pushing a redesigned product to GitHub. Everything here comes from a live workshop, troubleshooting and all.
Table of contents:
- What is the design-to-code workflow?
- Why designers need to learn this now
- The workflow in action: redesigning a live product
- How to go from zero to shipping code
- Tools and resources
What is the design-to-code workflow?
Design to code with AI is the practice of using AI-powered tools to translate design decisions directly into production front-end code, bypassing the traditional handoff to engineering. Instead of annotating a Figma file and hoping a developer interprets your intent correctly, you're writing the code yourself with AI doing the heavy lifting.
In practice, this looks like:
- Opening a codebase in Cursor, prompting Claude Code to redesign a UI component, and seeing the changes live in your browser
- Taking a Figma selection, pasting the link into Claude Code, and watching it apply your design changes to the actual code
- Pushing your own pull request to a shared GitHub repo, ready for review
This isn't about designers becoming engineers. It's about eliminating the gap between what you design and what gets built.
Design to code vs. design-to-dev handoff
The traditional handoff is a relay race. You finish your leg, pass the baton, and hope the next runner doesn't drop it. Design to code collapses that into a single sprint. You design, you implement, you ship. The feedback loop goes from days to minutes.
Design to code vs. no-code tools
No-code platforms like Webflow or Framer give you visual builders, but they lock you into their ecosystem. Design to code with AI works on any codebase, your company's actual production repo with its existing component library, design tokens, and architecture. That's the difference. You're not building in a sandbox. You're building in the real thing.
Design to code vs. vibe coding
Andrej Karpathy coined "vibe coding" to describe the experience of prompting AI and seeing what happens. Design to code is adjacent but more intentional. You're bringing design expertise to the prompting process. You know what good UI looks like, you're just using a different tool to get there.
Why designers need to learn this now
The roles are merging. PMs are already prototyping with AI. Engineers are using AI to generate UI. If designers don't step into the code, someone else will make those design decisions for them and they won't have the same eye for it.
This isn't a silver bullet. There's real troubleshooting involved, things break constantly, and you'll spend time debugging that you used to spend pixel-pushing. But the tradeoff is worth it, especially for designers at startups where speed matters more than process purity.
When you can code your own designs, three things change immediately:
- You control the final output. No more reviewing a dev build and finding your spacing is off, your animations are missing, or your component states don't match the Figma. You built it. It matches.
- You ship faster. The back-and-forth between design and engineering disappears. We've seen what used to take a sprint cycle collapse into a single working session.
- You become more valuable. A designer who can hand off working code to a product team is operating at a fundamentally different level. You're not just proposing solutions, you're implementing them.
The workflow in action: redesigning a live product
The best way to understand this workflow is to see it applied to a real project. We used Andrej Karpathy's LLM Council — an open-source tool where you ask a question, multiple AI models answer it, and then they grade each other's responses. Brilliant concept, but the UI needed serious help. (Karpathy is a genius, but he's clearly not a designer.)
Taking an open-source project from ugly to usable
The starting point: LLM Council had functional code and a clever concept, but the front end was bare-bones. No visual hierarchy, no polish, no design system.
What we did: We cloned the repo into Cursor, ran Claude Code, and prompted it to redesign the entire page. The prompt was simple; "You are a world-class product designer. I want to redesign this page to look like [reference]. Make sure you plan this out for me first." Claude Code analyzed the codebase, proposed a plan, and then rewrote the front-end components.
The result: A fully redesigned interface in a single session. The design adhered to the reference we provided, Claude Code even added hover states we didn't ask for, and the whole thing ran locally without breaking the back end. We committed the changes and pushed to a forked repo on GitHub — something any engineer on the team could review and merge.
Bidirectional Figma flow: code to Figma and back
The problem: Sometimes you want to tweak something visually before committing it to code. Maybe the spacing feels off, or you want to explore a color variation. Doing that through prompts alone is slow.
The solution: Figma MCP creates a two-way bridge. We took the redesigned code and pushed it directly into Figma using a single prompt — "turn this screen into a Figma." From there, we made visual adjustments (changed a button to white, removed an element), copied the Figma selection link, pasted it back into Claude Code with "apply this new design," and watched the code update to match.
Why this matters: You're no longer choosing between designing in Figma or designing in code. You can move between both. Use code for structural changes and rapid iteration. Use Figma when you need to get into the pixels. The bridge between them is now a single prompt away.
How to go from zero to shipping code
You don't need a computer science degree to start doing this. You need a few tools installed, a basic understanding of what's happening under the hood, and the willingness to troubleshoot when things break (they will break). Here's the exact playbook.
1. Set up your environment
You need three things: Cursor (or any code editor), a Claude Code subscription, and a GitHub account. If you're working with Figma designs, add the Figma MCP integration to Claude Code.
Cursor is a great starting point for designers because it shows you the file structure visually. You can see folders, click into files, and understand the codebase without using the command line. Think of it as training wheels. Once you're comfortable, you might graduate to a pure terminal setup like Ghostty — but there's no rush.
2. Clone the repo and get oriented
Before you change anything, you need the code on your machine. In Cursor, go to New Window, click Clone Repo, and paste the GitHub URL. Create a folder called something like coding to keep your projects organized.
Once cloned, your first Claude Code prompt should be: "Read the README file and download dependencies." This tells Claude Code to understand the project's rules and install everything the code needs to run. Think of the README as the project's instruction manual, and dependencies as the tools it relies on.
If the project needs API keys or secrets, you'll create a .env file in the root directory. This is just a text file that stores passwords the code needs to function.
3. Run the servers and see the product
Type "start servers in background" into Claude Code. This launches the product locally on your machine so you can see and interact with the front end in your browser.
This is the moment it becomes real — you're looking at a functioning product that you're about to redesign. Take a minute to click around and understand what you're working with.
4. Prompt Claude Code with plan mode
This is the part that changed everything for me. When you prompt Claude Code to make design changes, end your prompt with: "Make sure you plan this out for me first."
Plan mode tells Claude Code to stop and think before it touches anything. It will analyze the codebase, propose which files it wants to modify, outline the components it'll create, and sometimes ask clarifying questions. I've had Claude Code surface design considerations I hadn't even thought of.
Don't just accept the plan blindly. Read through it. This is your opportunity to catch misunderstandings before they become 45 minutes of debugging. Since I started using plan mode consistently, the back-and-forth has dropped dramatically.
A prompt like this works well: "You are a world-class product designer. I want to redesign this page to look like [paste reference image or URL]. Adhere to the colors, shapes, and layout. Plan this out for me first."
5. Commit early, commit often
Once Claude Code makes changes you're happy with, commit them. Committing is just saving a snapshot of your project at that point in time — like a save point in a video game.
Tell Claude Code: "Commit this code." It'll stage and save everything. I learned this the hard way — I used to forget to commit, make a bunch more changes, break something, and then wish I could go back to when it was working. Commit every time you reach a good state.
6. Move between code and Figma
If you have Figma MCP set up, you can push your code into Figma with "turn this screen into a Figma." From there, make your design tweaks — adjust spacing, swap colors, refine components.
To bring changes back, copy the Figma selection link (right-click the element, Copy Link to Selection), go back to Claude Code, and prompt: "Here's my Figma selection for [element name]. Apply this new design." Paste the link. Claude Code reads the Figma data through MCP and updates the code.
One caveat: the Figma import doesn't always generate clean tokens and components. It's better for exploration and visual tweaking than for creating a production-ready design system. For complex component work, you'll still want to build that intentionally.
7. Push to GitHub
When you're ready to share your work, tell Claude Code: "Commit and push." This takes your local changes and uploads them to your GitHub repository where your team can see them.
If you're working on an open-source project (like we did with LLM Council), you'll push to your own fork rather than the original repo. From there, you can open a pull request — essentially a proposal that says "here are my changes, want to merge them?" This is how you contribute to any open-source project, and it's how design changes get reviewed in professional codebases.
Tools and resources
The ecosystem is moving fast, but here's what's working for us right now:
- Cursor — Code editor with built-in AI. Best entry point for designers. Visual file explorer makes the codebase approachable.
- Claude Code — AI coding agent that works within your editor or terminal. Handles everything from redesigns to git operations. Plan mode is the killer feature.
- Figma MCP — Connects Figma to Claude Code for bidirectional design-to-code flow.
- GitHub — Where code lives. You'll use it to clone projects, commit changes, and collaborate with your team.
- Ghostty — A fast, clean terminal if you want to graduate from Cursor and work purely in the command line.
If your team is shipping product and your design-to-dev handoff still involves annotated Figma files and Jira tickets, we should talk. At TDP, we've been building this exact workflow into how we serve our clients going from Figma to production code, eliminating the handoff entirely.
Start shipping
The gap between "designer" and "person who ships product" has never been smaller. The tools exist. The workflow works. The only thing left is to open a terminal and start breaking things.
Every designer should be learning these tools right now. Not because coding is suddenly your job — but because the ability to implement your own designs is going to make or break how product teams function in the next few years. It's all going cross-functional. The designers who figure that out first will have a serious edge.
Want help building out your component library? We have openings for teams looking to formalize their design systems. Reach out and let's talk about your design challenges.
