What do engineers and design engineers have in common?
They ship.
That is the whole answer, and it is also the whole problem. We have talked to hundreds of designers this year, across startups, scale-ups and enterprises, and the pattern is brutal. Roughly 95% of designers do not ship. Not because they lack taste, craft or ideas. Their work dies in the design handoff.
The other 5% are doing something different. They design in code. They open pull requests. Their work gets merged. We call them design engineers, and in this article we want to explain why they are winning, why the design ladder has quietly been rewritten, and why the climb is a lot shorter than most designers think.
The three rungs of the new design ladder
When we mapped the designers we spoke to, three distinct profiles kept showing up. Think of them as rungs on a ladder. Everyone wants to be on the top rung. Only one rung actually reaches production.
01. Entry level: lives in Figma
The entry level designer lives in Figma. Their day is frames, auto layout, components and prototypes. They have a basic interest in AI tooling, which mostly means using ChatGPT to "brainstorm" copy or ideas. Prototyping is the ceiling of what they produce and, in many cases, the main goal.
There is nothing wrong with this. Most of the industry works this way, and it has worked for a decade. But the output is a picture of a product, not the product. Somebody else has to turn it into working software, and that is where the loss begins.
02. AI-native: prototypes with vibe coding tools
The AI-native designer has moved past static mockups. They have tried Lovable, v0, Bolt, Claude Design or Cursor (we looked at where Cursor fits for designers separately). They can spin up a working prototype in an afternoon. Their Figma files are increasingly a starting point rather than a final deliverable.
And yet, they ship nothing.
The reason is not effort or ambition. It is that vibe coding tools produce something that looks like the feature but is not the feature. The prototype lives outside the real codebase. It does not use the team's actual components, design tokens or data. It cannot be reviewed or merged. So the AI-native designer ends up doing a more sophisticated version of the same handoff: here is a working demo, now please rebuild it properly.
The AI-native designer has the eagerness. What they lack are the technical concepts to steer an agent toward high-fidelity, production-ready output inside a real repository. They can describe what they want. They cannot yet reference their codebase the way an engineer would.
03. Design engineer: designs in code
The design engineer designs in code. Their prototypes are branches. Their reviews are pull requests. Around 90% of what they produce is production-grade and gets merged without a rebuild.
Most design engineers we spoke to are 20 to 35, self-taught or upskilled in-house, working at Series A to mid-market tech companies. Almost none have a computer science degree. They do not understand git internals or DevOps in depth, and they do not need to. What they have is a working mental model of their product's codebase: where the components live, how the design system is wired, what a good PR looks like, and how to prompt an AI agent using that vocabulary.
That last part matters more than anything else. A design engineer prompts like an engineer. Instead of "make a nice settings page," they say "build a settings page using our SettingsLayout, FormField and PrimaryButton components, following the spacing tokens in theme.ts." Same designer, same taste. Completely different output.
Why the design handoff is where design work dies
The design handoff is the most expensive ritual in product development, and almost nobody measures it.
A designer spends days or weeks getting a flow right. They annotate it. They present it. Then an engineer, working from a different tool with different constraints, rebuilds it from scratch. Spacing drifts. States get dropped. Edge cases get improvised. By the time it reaches production, the design has been translated twice: once from intent to Figma, once from Figma to code. Something is lost in every translation.
Then the roles reverse. The designer files "design QA" tickets. The engineer, who has moved on, deprioritizes them. The polish never ships. Six months later the product looks nothing like the Figma file, and everybody quietly accepts it.
This is what we mean when we say 95% of design work dies in a handoff. It is not that the work is bad. It is that the work is never the thing that ships. Only code ships.
Design engineering removes the translation step. When the designer works in the codebase, the design and the implementation are the same artifact. There is nothing to hand off.
Design engineering is not a new idea. It is a comeback
Before software, the best designers made things. James Dyson described his realization at the Royal College of Art as inventing and making being one activity, not two. Dieter Rams did not draw pictures of radios for someone else to build. Design engineering was the default, because you could not design a physical product without understanding the material it would be made from.
Software separated the two. Design became pictures. Engineering became material. The handoff was invented to bridge them, and for years it was the best we could do.
AI has closed that gap. The material of software, code, is now something a designer can work with directly, without a decade of engineering experience. Design in code is not designers becoming engineers. It is designers getting their material back.
What it actually takes to become a design engineer
Here is the part most designers get wrong. They assume the top rung requires a CS degree, a bootcamp, or years of learning to program. It does not.
Every design engineer we talked to got there the same way: by being curious enough to learn the basic concepts of their own codebase, and eager enough to try shipping. Not to become a full-stack engineer. Just to understand enough to reference and prompt like one.
Concretely, that means learning:
- How your codebase is organized. Where the pages, components and styles live. What the folder structure means.
- What your components are called. Real component names, not Figma layer names.
Button,Card,DataTable, and the props they accept. - How your design system is implemented. Tokens, themes, spacing scales and typography as they exist in code, not as they exist in a Figma library.
- What a pull request is. A change, proposed for review, with a diff. That is the whole concept.
- How to prompt an agent with all of the above. The difference between a vibe-coded demo and a mergeable PR is almost entirely the quality of the references in the prompt.
Notice what is not on the list. Algorithms. Data structures. Build pipelines. Deployment. Even git, in the traditional sense of memorizing commands, is no longer necessary. Modern tools abstract it away entirely. You can create a branch, make changes and open a pull request without ever typing git rebase.
The barrier to design engineering is no longer technical. It is a barrier of mindset and tooling.
Why teams are moving fast on this
We are seeing companies restructure around design engineering faster than most designers realize.
The math is simple for a product team. A designer who ships production-grade PRs removes an entire loop from the delivery cycle. Features that took a design sprint plus an engineering sprint plus a QA sprint now take one person and one review. Engineers stop rebuilding UI and start solving harder problems. The design system stops drifting, because the people who care most about it are the ones writing it.
For design leaders, it is also the strongest answer to the "is design dead" discourse. Design is not dead. Design that ends in a Figma file might be. The designers who learn to manipulate code and ship production-quality features are going to be the ones companies fight over in the coming years. The ones who do not will find that a working prototype from an AI-native competitor, or an engineer with decent taste and an agent, is good enough.
The tooling gap between AI-native and design engineer
If the mindset shift is small, why are so many designers still stuck on the second rung?
Because the tools have been built for the wrong side of the handoff. Vibe coding tools optimize for a fast, impressive demo. They start from a blank project because a blank project is easiest to generate into. But designers on real teams do not work in blank projects. They work in codebases with thousands of components, strict design systems and opinionated engineers who review every PR.
What an AI-native designer needs to become a design engineer is not a better demo generator. It is a design tool that lives inside the real codebase: something that lets them work on a visual canvas the way they are used to, while every element they touch is an actual component from the actual repository, and every change becomes an actual diff.
This is the gap we built Modeinspect to close. It is a design to code tool for design engineers: a Figma-like canvas connected directly to your codebase, so designers can design in code using real components and design tokens, then open production-grade pull requests without the rebuild. It exists because the handoff should not exist.
But the tool is the smaller part of the story. The bigger part is the ladder.
Where are you on the ladder?
Take an honest look at the last five things you designed.
- If they are all still in Figma, you are on rung one. That is fine, but it is also the most crowded and the most at risk.
- If some of them became prototypes in Lovable or v0 that an engineer later rebuilt, you are on rung two. You already have the eagerness. You are missing the concepts.
- If any of them shipped as a PR you opened, you are a design engineer, whether or not that is your title yet.
Only one of these three actually ships. The good news is that the distance between rung two and rung three is measured in weeks of curiosity, not years of study.
Frequently asked questions about design engineering
What is a design engineer? A design engineer is a product designer who designs in code and ships their work directly to production, typically through pull requests, instead of handing off mockups to engineers. They combine design craft with enough technical understanding of their codebase to build real, mergeable features.
Do you need to know how to code to be a design engineer? Not in the traditional sense. Design engineers understand the higher-level concepts of their codebase, such as components, tokens and pull requests, and use AI agents to write the actual code. A CS degree or programming courses are not required.
What is the difference between a design engineer and a front-end engineer? A front-end engineer starts from the engineering side and owns the whole implementation, including logic, performance and infrastructure. A design engineer starts from the design side and owns the UI layer, ensuring what ships matches the intended design and design system. In practice the two collaborate closely, and the design engineer removes the rebuild step from the workflow.
What does "design in code" mean? Design in code means creating and iterating on UI directly inside the product's real codebase, using the actual components and design tokens, rather than in a separate design tool whose output must be translated by an engineer.
Is the design handoff going away? For teams adopting design engineering, yes. When the designer's output is a pull request rather than a Figma file, there is nothing to hand off. The review process replaces the handoff.
How do I start moving from AI-native to design engineer? Learn how your team's codebase is structured, learn the real names of your components and tokens, understand what a pull request is, and start prompting agents with those references. Then ship one small change end to end. The first merged PR changes everything.
Modeinspect is a design to code tool for design engineers. Design on a canvas, connected to your real codebase, and ship production-grade PRs.