Claude Code, the Figma Replacement

Around this time last year, I wrote a lightweight explainer breaking down the differences between Replit and Figma. It’s one of my most viewed posts of all time, and in the year since, much has changed in the tools landscape.

Today, there’s suddenly a lot of chatter about Claude Code, the new Figma. Or the new Figma Make. This will follow a similar layout to the Replit comparison (though I hope to not start a long series of Figma replacement guides).

What is Claude Code?

The earliest days of LLM assisted coding meant copying and pasting lines of codes from an IDE into the LLM’s app, then going back to paste the response. It was slow and tedious. Then, tools started to pop up allowing developers to use LLMs in their coding tools directly, reducing the number of steps needed to apply code suggestions provided by LLMs.

Claude Code is a first-party command line tool optimized for planning and executing code changes. It has access to the entire codebase, and with some prompting and guidance, it can get to work coding complex features with minimal input. When Claude takes the wheel and is allowed to run code changes, you’ve arrived at Vibe Coding.

Features and Design in Claude Code

Let’s say you’re building an admin dashboard with stats about how your site is doing. You begin with a prompt: “Create an admin dashboard that shows key health metrics over the last 30 days.”

I’m going to vastly simplify what happens next. In most instances, Claude Code will try to load everything it needs to fulfill the request. It’s going to try to determine what the health metrics are, how your database works, what kind of access control is in place, and maybe even what components or patterns to use to build it.

Then, it’s going to get to work building the dashboard. You’ll eventually land at a prototype in code. From there, you’ll need to be familiar with your app’s build and deployment processes to be able to share the prototype with others.

Replacing Figma with Claude Code

Conversations about replacing Figma with [tool of the day] almost always refer to Figma’s role in making prototypes. Claude Code certainly makes prototyping faster. In fact, I’d argue for common interactions like signup forms or other common user flows, it makes more sense to prototype in code.

Designers and design teams having access to Claude Code will be the biggest challenge with adopting it at scale. It’s simply faster to prop up designs and prototypes in a team context with a purpose-built tool like Figma, where you won’t have to work through code quality processes like Git or CI/CD.

There’s also a fundamental difference in how these tools operate: Figma is a sandbox. You can experiment freely, create throwaway explorations, and nothing you do affects the product until an engineer translates it into code. Claude Code isn’t a sandbox—it’s the real thing. It operates directly in your codebase, making changes to the same files engineers ship. This is powerful for reducing the design-to-development gap, but it also means designers need to understand (or at least respect) how the codebase is structured, what patterns exist, and what the consequences of changes might be.

Because LLM outputs can vary so much from prompt to prompt, keeping a designer in the loop remains critical—ensuring the interface follows conventions, but also catching when Claude goes off-script in ways that could introduce inconsistency or technical debt.

What Figma does that Claude Code can’t

• Lofi. FigJam is an excellent design research tool, and before we can articulate good prompts, we have to understand what we’re building. FigJam can conduct pre-prototype activities like card sorts, journeymaps, walking the store, and more.
• Collaboration: Designers and stakeholders can collaborate quickly with tools made specificially for providing feedback; coded prototypes won’t have this built-in.
• Quality: Figma can house design system documentation that helps maintain quality and consistency across your app. Critique and feedback tools are native to Figma. Claude Code outputs can vary significantly between prompts, and without a designer reviewing outputs against established conventions, consistency erodes fast.

New Discovery and Delivery Workflow

1. Use FigJam for discovery and structure

   • Run workshops to understand user needs
   • Journey map the workflow you’re designing for
   • Sketch rough layouts and interaction models collaboratively

2. Prototype in Claude Code

   • Start with a prompt that references your existing components: “Using our design system, create a settings page for notification preferences. Include toggles for email and push, with a save confirmation.”
   • Claude Code will pull from your actual codebase, using existing components, patterns, data structures
   • Iterate by refining: “Add a preview of what the notification will look like” or “Make the save action optimistic”

3. Validate with real context

   • Because the prototype is real code, you can test with actual data and auth states
   • Share a deployed preview with stakeholders
   • Refine based on feedback in near real-time

How should I prepare?

• Get familiar with LLMs and how they approach design. Claude’s desktop app has had artifacts for some time, and it’s a great tool for experimenting with code prototypes. Experiment with different prompts and context to see how it shapes results. Learn what makes a good prompt—being specific about layout, interactions, and edge cases will dramatically improve output quality.

• Document, document, document. The more specific you can be with your guidelines, the more predictable the outputs will be. PRDs, design system code examples, and usage patterns all shape outputs. Structure your documents for machine readability: consistent headings, explicit component names, and clear examples of do’s and don’ts.

• Understand your codebase. Unlike browser-based tools, Claude Code operates in your actual project. Knowing how your components are organized, what patterns exist, and where the boundaries are will help you prompt effectively—and catch when Claude goes off-script.

• Invest in design system documentation. Document not just visual properties but usage patterns. If your system has a Modal component, document when to use it versus a Drawer, what content patterns work inside it, and how it handles mobile. This context helps Claude Code (or any LLM, for that matter) make better decisions.

Advanced design and prompting with Claude Code

I’ve experimented with UI design and Claude Code to mixed results. Here are a few things I’ve found helpful:

• Never ever trust a generated UI. There’s a tension between the least expensive route to generating a UI and the context needed to deliver the right UI. All of these tools can go off the rails fast, and you’ll need to be able to inspect, diagnose, fix, and test any UI-generated code.

• DESIGN_GUIDELINES.md - Create a list of design guidelines for your project that the LLM can use when building a UI or UX, and make sure it’s being referenced when building. Or you will get Emojis all over your interface.

• Skills/Sub-agents - Create an Agent (or skill) that’s responsible for critiquing any introduced UI against your DESIGN_GUIDELINES. This will catch some issues and steer towards more consistent designs.

• Playwright for computer vision. Claude can’t actually see what it’s generating, so using playwright to generate screenshots can help automate some of the revision process.

Verdict: It most likely won’t replace Figma

Prototype cycles will continue to speed up with innovations in code generation, whether it’s Claude Code, Replit, or any other tool. But prototyping remains a small part of the overall product creation process. Discovery, collaboration, critique, and system documentation are still well-served by Figma. For now, medium to large teams would create a lot of problems (and potentially expensive ones) by porting their design processes to Claude Code.

Very small teams and those contracting out design work may find Claude Code a viable shortcut for getting interfaces built quickly. And for some products, that might be fine. Teams taking this path should be honest about the tradeoff: you’re optimizing for speed, not for the kind of intentional, user-informed work that compounds over time. If design was never a priority, Claude Code won’t change that. If it was, Claude Code alone doesn’t quite get you there.

And “expensive” cuts both ways. Beyond the organizational cost of changing workflows, there’s the literal cost: larger context windows mean more tokens, and more tokens means more overhead. Token pricing is effectively subsidized right now, and if prices climb, end-to-end design work in LLMs won’t make sense.

None of this means designers should ignore these tools. For those willing to learn them, you’ll have more time on the work that actually requires human judgment: understanding users, navigating tradeoffs, and creating coherence across complex systems. The designers who thrive will be using taste and craft to deliver better designed products.