It’s mid-October, and the app I open first thing in the morning to start a new design exploration is not Figma. It’s not a sketchpad. It’s not v0. It’s Cursor. The thing that markets itself as “the AI code editor.”

I open it, point it at a branch of our repo, and describe the screen I want. Fifteen minutes later I’m clicking through a real running interface in my browser, typing into real form fields, watching the actual validation fire.

I’m a designer. I have been for eight years. I have never written production code outside of CSS tweaks and a few brittle React components. And honestly, this tool, built explicitly for engineers, has somehow become the place I start design problems.

I don’t think I’m alone. I also don’t think this is being talked about enough.

A quick primer for designers who don’t live in a terminal

If you haven’t looked, Cursor is a fork of VS Code with AI features welded into it. You can ask it to write code, edit files, or run commands. You can point it at your whole repository and ask questions in plain English about how a thing works. It’ll chain together a dozen edits across a dozen files to ship a feature. The model under the hood has been swappable, but since roughly midyear it’s usually Claude Sonnet 4.5 or one of the GPT-5 family, depending on the task. Closest cousins are Cline, Continue, and Anthropic’s own Claude Code, but Cursor has the friendliest path in if you’re not used to a terminal.

The sales pitch is “write software faster.” The quiet secondary effect is the part I actually care about. The cost of running a real prototype against your actual codebase basically collapsed. That’s the bit that matters to design.

What changed for me

In 2024, if I wanted to explore a new onboarding flow against a real product, my options were tight. I could draw it in Figma or Sketch, spec it out in Notion, mock the interactions in ProtoPie or Origami Studio, or beg an engineer to spend a few hours pairing.

Each option had the same shape. Make a representation of the work, hand it off, wait, look at what came back, make another representation. The whole apparatus assumes the work itself is too expensive to do twice.

In 2025, my default is different. I clone a branch. I open Cursor. I type a long paragraph describing the flow I want, what state the user is in when they arrive, what the failure modes are, what microcopy I’m after. Cursor takes the existing components from our codebase, the real ones that ship to real users, and wires a new screen together. I run it locally. I click through it. Something feels wrong. I type another paragraph. It adjusts.

An hour in, I have a prototype that’s indistinguishable from production, because it’s built from production parts. At no point did I draw a rectangle.

This is not replacing engineering. I cannot read most of what Cursor writes, and I certainly can’t review it for performance or edge cases or security. When I hand the branch back to my engineering partners, they rewrite large chunks of it, and they catch things I’d never have caught. That handoff is real work and it requires real engineers.

What changed is the direction of the handoff. The designer no longer ships a comp to an engineer who then builds it. The designer ships a working prototype to an engineer who then hardens it. The artifact moved from a file that represents the intended work to code that performs the intended work.

The designer this favors

I want to be specific about who wins, because the people saying “AI will flatten design” are being too glib.

The designer who does well in Cursor is the one who can write a tight, constraint-rich brief. This is genuinely a different muscle than pushing pixels. It needs you to know what you want with a level of precision that designers could previously smuggle past themselves by iterating visually. If you can only figure out what you want by dragging things around on a canvas, the Cursor workflow will feel awful. You’ll produce garbage and you’ll blame the tool.

The designer who does well in Cursor also tends to be a systems thinker. When I say “add a sort control to this table,” the useful version of that brief specifies which component should provide the control, which states it has, what happens when the data is empty, what the keyboard behavior is, how it composes with the existing filter chips above the table. A designer who thinks in components and states has a real edge here. A designer who thinks in screens doesn’t.

And the designer who does well has strong taste, because the model will confidently produce things that work but look terrible, and you have to be willing to say so and iterate. If you can’t articulate why something is wrong, you are stuck with what the model gives you, and what the model gives you is almost never ship-quality on the first pass.

The designer this is harder on

So who has a tougher time? We should be honest about it.

If your value to a team has been “I am fast in Figma and I make things pretty,” the Cursor workflow won’t make you more valuable. It’ll probably commoditize you, because the specific thing you’re good at is now cheap for people who were never good at it. I’ve watched engineers on my team produce a design mock in Cursor in twenty minutes that was 80 percent of what a fast Figma designer could produce in a day. It’s not a better mock. It’s worse, in real ways. But it’s good enough to unblock a sprint, and the marginal 20 percent of polish is sometimes not worth the two-day wait.

This is the part of the conversation people don’t really want to have out loud. A lot of design hiring in the last decade has been for execution speed in Figma. That skill is losing value in real time, and the designers whose careers were built on it are going to feel the floor tilt.

I think the move is to face it now and start building a different set of muscles, while you have the runway. The designers I know who are doing this best aren’t panicking. They’re learning to brief tightly, to evaluate quickly, and to spend more time on the parts of the job a model can’t fake.

The engineer is not obsolete

A point I want to be careful about, because it gets mangled every time the “designers can code now” discourse comes around.

Designers using Cursor are not replacing engineers. The output of a designer-in-Cursor is almost never shippable as-is. The code is usually inefficient, the accessibility is usually wrong, the state management is usually naive, the tests usually don’t exist, and the integration with the rest of the codebase is usually brittle. Handing that to production without an engineer’s review is how you ship a regression that takes a week to untangle.

What Cursor does is reshape the handoff. The engineer’s job becomes more about reviewing, hardening, and integrating than about translating a comp into a first pass of code. That’s a more interesting job, for what it’s worth. Most engineers I know would rather review and strengthen a working prototype than read a 40-artboard Figma file and guess at the corners.

The comp was always a workaround for the fact that running the real thing was expensive. When running the real thing gets cheap, the comp stops earning its keep.

Honestly.

A workflow that actually works

A concrete version of what I do now, in case it’s useful.

I still start in Figma or on paper, depending on how fuzzy the problem is. For a new flow I don’t understand yet, I sketch. For a variation on something we’ve shipped, I open the existing Figma file and block in the new piece.

Then I open Cursor. I tell it where the flow lives in our codebase. I paste the sketch or a screenshot of the Figma block. I describe what’s different, what the behavior should be, what edge cases I care about.

Cursor produces a branch. I run it locally. I click through it. I usually write another paragraph saying what feels off. Then another. After three or four passes, I have something I want to put in front of a PM or a research participant.

When I’m happy, I open a pull request and tag the engineer who owns that surface. They look at the diff, clean up whatever needs cleaning, push a polished version. That becomes the real work.

Figma ends up as the record of the decisions, not the place the decisions were made. It’s where I go to annotate, to write up the rationale, to keep a snapshot of the visual state so the team has something to reference six months later when they’ve forgotten why the empty state is laid out a certain way. Figma is the library. Cursor is the workshop.

The honest caveat

I don’t think every designer should adopt this. If you work somewhere with a rigid design-engineering split, or on a team where designers don’t have repo access, or in a domain where the UI layer is less about invention and more about tight adherence to a pattern library, Cursor will cost you more than it saves.

And I’ll admit something. I’m lucky to be on a team where this workflow is accepted. The engineers I work with are generous about cleaning up my messes. Not every team is set up that way. I might be projecting a workflow that’s specific to my situation onto a wider audience that can’t replicate it. If that’s you, and the workflow I’m describing isn’t possible where you sit, I’d love to hear what’s actually working for you instead. Please let me know.

But if you’re on a product where a designer-in-the-code workflow is even possible, and you haven’t tried it yet, I’d really spend a week on it. The skill it asks you to develop, the ability to brief tightly and evaluate quickly, is going to be valuable regardless of whether Cursor specifically wins the tool wars. The posture is what matters. The posture is: I don’t hand my work off, I ship it and let the experts harden it.

I’ll see you in two weeks.

Jameson