The Title Is Splitting

The question

I'm finishing a UX degree, and lately I've been wondering whether the job the degree names will still exist in that shape when I get there. Not because the work is disappearing. Because it's splitting into two versions of itself, and only one of them is the one I actually do.

What a UX designer is

A UX designer, as the field traditionally means it, figures out what should be built and proves it on paper. They interview users, map the journey, build the flows and screens in Figma, test the click-through, and hand it off. The deliverable is a decision, rendered beautifully. Somebody else turns it into software.

What a design engineer is

A design engineer works the same problem from the other end. The research and layout thinking are still there, but the deliverable isn't a picture of the thing. It's the thing, or the closest working version of it. The prototype runs on real logic, real data, real edge cases. There's no handoff, because there's nobody to hand off to. The design decisions and the build decisions happen in the same head, in the same hour. Design questions are decided in functional code now, and the software that comes out the other side is more beautiful, and more capable, than a mockup could ever convey.

What changed

For a long time that second person was considered a unicorn, mostly because implementation was expensive. Doing both jobs meant being slow at each. What's changed isn't people's talent. It's the price of building. AI collapsed the cost of a first draft, of a screen and of the code behind it. When a working version costs about what a polished mockup used to, the mockup stops being the obvious place to stop.

The team is agents

I don't just build faster myself. I direct a team that isn't people. I work out the concept of a design, the system it has to be, and then I run a team of agents that does the work a developer team would have done: the implementation, the iteration, the deliverable taking shape piece by piece. My hours go to the design questions of the system: what it should do, how it should behave, where it breaks for a real user. The production happens under my direction.

That's not a faster pair of hands. It's a different job shape. The scarce resource stops being labor and becomes direction: how clearly you can conceive the thing, and how honestly you judge what comes back.

What the postings say

You can watch the shift in the job postings. Anthropic asks its product designers to prototype in front-end code. Cursor's design engineer listing wants someone equally comfortable in Figma and a code editor. Designer Fund's 2026 survey found half of designers have already shipped AI-generated code to production. Figma itself has become the floor, not the differentiator, assumed in nearly every posting, the way typing is assumed. Nobody wins a job for knowing the canvas anymore. They win it for what they can do past the canvas.

Don't draw what already exists

There's a harder version of this. Most interfaces aren't invented anymore. They're assembled. The buttons, fields, modals, and tables already exist in the library, decided and built, and the layout patterns are a known grammar. Hours spent dragging those components around an unstructured canvas isn't design; it's transcription, a screenshot of decisions somebody already made, which an engineer then has to translate back into structure anyway.

The canvas made sense when it was a cheap simulator for an expensive build. Building got cheap. What's left for it is real but narrower: wild early exploration, and rooms full of people who can't run code. That's alignment and sketching. It isn't where the design decisions live anymore.

Where I land

I should be clear that this isn't tool snobbery. I use Figma. It's the team's shared surface, and refusing it would make me a bottleneck with opinions. But Figma answers layout questions. Code answers behavior questions. And the products I care about, AI products especially, are behavior all the way down: state, latency, the weird thing the model does on the fourth prompt. A static flow will lie to you about all of that, politely, in high fidelity.

The honest version is simpler than the market analysis. I'm not strictly a designer. I like code. And I don't want to be prototype support for somebody else's design team, building careful copies of decisions I didn't make. I want the decisions to be mine, and I want to answer for them in working software.

And this is not abstract for me. I'm a software developer and a UX designer. The stack of capabilities this whole question is about is the one I already work with: the research, the design, and the code, all in the same person.

Building the thing is how I find out what the design actually is. Half my design opinions don't survive contact with a running prototype, and I'd rather learn that myself in an afternoon than hand a team a beautiful fiction to discover over a sprint. The research still matters. It's what keeps the building pointed at a real person's problem instead of my own amusement. But it's my differentiator, not my whole job.

It's mine

So the two titles aren't rivals. They're the same role on either side of implementation getting cheap. The UX designer asks what should exist. The design engineer asks that too, and then has to answer for it in working software.

I can have one agent, or two, or fifteen. My influence is no longer decided in team meetings. It's decided in a prompt. The real questions are taste, and defining goals that meet user needs. It is a system. It is beautiful. It is well researched.

It's mine. I'm a design engineer.