I keep hearing the same question at dinners, in DMs, on Twitter threads that go nowhere productive. It comes in different flavors but it’s always the same:
“Why can’t Cursor just add a visual canvas? You’d never need Figma again.”
“Figma Make is getting good. Once it exports real code, game over for these AI code editors.”
“v0 already generates better UI than most junior designers. Why are we still paying for Figma seats?”
It’s a reasonable question. Design tools are learning to generate code. Code editors are learning to generate design. They’re converging. So can’t one side just finish the job? Can’t Cursor ship a design mode and kill Figma? Can’t Figma ship code generation and kill Cursor?
I’ve been sitting with this question for a while. My short answer is no. Neither can. And the reason they can’t is more interesting than the question itself. But to get there, I have to unpack what these tools are actually doing, why the convergence is harder than it seems, and what it reveals about where the real bottleneck lives.
Let me start with a moment that triggered all of this.
The moment I skipped the design phase and didn’t miss it, but noticed something was missing
Last week I needed a landing page for a side project. I opened Figma out of habit. New file, frame, auto-layout, the usual ritual. Then I stopped. Closed the tab. Opened Cursor instead. Typed a prompt describing what I wanted. Ten minutes later I had a working page: responsive, styled, deployed, live. I never went back to Figma.
The output wasn’t great, honestly. The spacing was slightly off. The typography hierarchy was flat. The CTA button had that unmistakable “AI generated this” energy. But for the first time, I’d skipped the design phase entirely and didn’t feel like I’d missed a step. I felt like I’d missed taste. Hold that thought. I’ll come back to it.
That experience is why the question keeps coming up. If a code editor can get you to a live, working page in ten minutes without ever touching a design tool, it’s natural to ask why the design tool exists. And if Figma can generate layouts from a prompt, it’s natural to ask why the code editor needs to generate UI at all.
Both questions make sense. Both are wrong. Here’s why.
First, some context: the handoff that built a $20B industry
To understand why “just add design to Cursor” or “just add code to Figma” sounds simple but isn’t, you have to understand the workflow these tools exist within.
For the last decade, product development has run on an assembly line:
Designer creates mockups in Figma → Developer inspects specs, rebuilds it in code → QA catches mismatches → back and forth until it “matches the design”
This workflow is called the handoff. The entire design tools industry, the roughly $20B one that includes Figma at about $600M ARR and the one Adobe tried to buy for $20B, has been organized around making one side of this handoff better.
Figma made collaboration real-time. Design systems standardized tokens so designers and developers at least shared a vocabulary. Dev-mode tools like Zeplin and Figma Dev Mode made the translation thinner. Design-to-code tools like Anima and Locofy tried to automate the translation entirely, with middling results.
Every single tool was optimizing the same flow: design artifact in, code artifact out, shrink the gap. Nobody was asking whether the gap should exist at all. That’s the context in which AI generation tools arrive.
The handoff has three structural problems that AI doesn’t automatically fix
Problem #1: It’s inherently lossy.
A Figma frame is a picture of intent. One state. One breakpoint. One data set. Code is the actual product. It handles empty states, error states, loading spinners, 37-character usernames, and viewport widths nobody tested. No amount of annotation fully bridges this.
Problem #2: The mediums are fundamentally different.
Designers think in visual hierarchy, whitespace, and rhythm. Developers think in DOM trees, component boundaries, and state management. A designer says “this feels too heavy.” A developer says “this re-renders on every keystroke.” Both are right. They’re talking past each other.
Problem #3: Speed is gated by translation steps.
Idea → wireframe → mockup → review → handoff → code → code review → QA → staging → production. Each arrow is a translation. Each translation is a potential “that’s not what I meant.” The bottleneck isn’t talent. It’s the number of conversions between intent and output.
These three problems are why everyone got excited when AI generation tools showed up. They promised to collapse translation steps. The question was who collapses them, and from which direction.
Three camps formed, and they’re betting on very different outcomes
Camp 1: “Make designers faster”
Figma Make, Framer AI, Canva Magic Design.
The incumbents. They’re adding AI generation into the existing canvas. Figma Make generates layouts and components from prompts, but the output is still a Figma file. A design artifact. You still hand it off.
What works: for the 80 percent of design work that’s layout and iteration, it’s genuinely useful. Generating a dashboard layout from a prompt in seconds instead of an hour is real value.
What doesn’t: the output is still a picture. It still needs to become code. The handoff survives. AI here speeds up the design phase but doesn’t eliminate the translation phase.
Usable today, clear value for designers. Doesn’t change the fundamental workflow.
Camp 2: “Democratize design”
Galileo AI, Uizard, Musho.
New entrants. Text-to-UI for people who can’t use Figma. PMs, founders, marketers generating screens from prompts.
What works: for MVPs, pitch decks, and “I need something that looks credible in 30 seconds,” these deliver. A non-designer getting a professional-looking app screen without hiring a freelancer is real.
What doesn’t: the output is generic. It works for landing pages. It falls apart for complex product design: multi-step flows, conditional UI, dense data tables, accessible form patterns. And there’s a subtler issue. It looks designed but isn’t thought through. Aesthetically passable, structurally shallow.
Good for prototyping. Not a replacement for product design.
Camp 3: “Design is a prompt, not a phase”
Cursor, Windsurf, v0, Bolt, Lovable.
This is where the energy is. These tools generate working production code, not mockups. The output isn’t a picture of a UI. It is the UI. Running in a browser. Interactive. Deployable.
v0 generates React components from prompts that are surprisingly good. Cursor and Windsurf scaffold entire pages, wire up state, connect APIs. Bolt and Lovable build full apps from a conversation.
What works: the output is real. You skip the handoff entirely. The thing the designer would have drawn, the developer builds directly.
What doesn’t: there’s a sameness to it. The spacing is uniform but not rhythmic. The hierarchy is present but not felt. The components are correct but not considered. Without explicit design system constraints, the output drifts toward a median aesthetic. Technically functional, spiritually anonymous.
Interaction design is especially weak. Describing delightful micro-interactions in text rarely produces delight.
Genuinely usable for real products. Visual quality ceiling is real. Interaction design still needs human craft.
So why can’t one side just finish the job?
Can Cursor add a design mode? In theory, yes. In practice, design is about exploration. Trying five variations. Squinting. Adjusting by feel. A code editor is optimized for precision and execution, not visual exploration. Adding a true design canvas would mean rebuilding Figma inside Cursor. That’s not a feature. That’s a product.
Can Figma ship production code generation? In theory, yes. In practice, generating a working app requires state management, routing, APIs, responsive behavior, build systems, and deployment. That’s not a plugin. That’s rebuilding a code editor and platform inside Figma.
Here’s the tell. Each tool would have to become the other to fully close the gap. When two products need to become each other to solve a problem, the answer is usually neither. It’s something new.
Even if someone solved this tomorrow, it wouldn’t be enough
Even with a perfect tool that generates flawless UI and production-ready code, you’d still need someone who can look at the output and say:
“No. The visual weight is wrong. The primary action doesn’t draw the eye. The spacing creates false grouping. The loading state feels jarring. Fix it.”
You’d still need someone who knows what good looks like.
The tools are converging. The gap between design tools and code editors is shrinking. But the gap between technically correct and feels right is not closing. It’s becoming the only gap that matters.
The rise of the taste engineer
When design and code generation converge, the winning skill isn’t pushing pixels or writing functions. It’s the ability to prompt, evaluate, curate, and iterate across both domains simultaneously.
This person exists today. Senior designers who learned enough code. Senior engineers who developed real design taste. It’s not a coincidence that products like Linear or Raycast feel different despite small teams.
Taste scales when it’s embedded in people, not process. And no tool generates taste.
You can see the gap when taste is missing
Everything works. Nothing feels.
That’s what code generation without taste produces. The AI optimized for the prompt. The founder got what they described. The user just leaves.
They can’t explain why. They just choose the product that feels considered.
The real question
The tools will converge. That debate will resolve itself.
The more interesting question is what becomes valuable when the mechanical work of design and development is commoditized.
The answer is judgment. The ability to look at something and know whether it’s good.
That distance between correct and good is where taste lives.
And I don’t see a model closing that gap anytime soon.