What Is a Design Engineer, a Developer's Perspective, and How to Grow Into One
What a design engineer is, what it's like for developers when designers start shipping code, and a checklist to grow into the role.
Ask a designer and a developer where their jobs end, and until recently you’d get a clean answer: the designer handed over specs and the developer built them.
That separation is disappearing.
I invited Stefania Barabas, a Senior Frontend Engineer, to talk about what this means and her experience working with designers who use AI.
The Rise of the Design Engineer
For years the split was simple. Designers designed, developers built, and a handoff sat in between. AI coding tools changed what a designer can hand over. With Claude Code, Cursor, and Figma Make, a designer can now turn an idea into a working, functional product or feature.
So teams started moving the designer closer to the code. More teams embed designers directly in the development team, where they produce functional components that engineers then take over, review, and harden for production.
This isn't theoretical. Intercom has designers shipping their own pull requests, catching and fixing UI issues themselves instead of waiting on an engineer. And when I asked four designers how their work is changing, every one of them described building functional things, prototypes, tooling, shipped components, that they couldn't have built two years ago.
What is a Design Engineer?
A design engineer is a designer who also codes: someone who prototypes directly in the codebase with AI tools and hands over something functional instead of a static spec. The skill set blends design with front-end or vibecoding, AI-assisted building, prototyping, and prompting.
There's another side to this. When a designer starts committing functional code, what changes for the developer who reviews it, and what does that collaboration actually look like?
So I asked one.
Meet Stefania 👋🏽
Stefania Barabas is a Senior Frontend Engineer with 8+ years building scalable web applications. She’s the author of Stef’s Dev Notes, where she writes about engineering judgment in an industry obsessed with speed.
Let's Ask Stefania 💬
1. Tell us about your role and the team you worked in.
I’ll describe my last role at Relex Solutions. The company operates in retail, wholesale, and consumer goods manufacturing, and I worked within the retail pricing team. The team started small but grew quickly, which eventually led to a split into two smaller teams. My team included a team lead, product owner, designer, a fullstack developer focused on AI, a backend developer, and two frontend developers.
My role was focused mainly on frontend development, but it also gave me space to collaborate closely with design to improve features and build them end-to-end, as well as with backend.
2. Since AI became part of your workflow, what has changed the most?
One of the things that changed the most is the time spent on validation and prototyping. With the help of AI tools and close collaboration between frontend and design, speed increased quite a lot, giving us enough room to work on the solution properly.
Another change was that designers could make trivial changes themselves directly, which saved time and gave them space to learn new skills like creating a PR, running the project locally, responding to code reviews, and even merging a solution to production.
This also brought a bit of pressure on the dev side, since reviews had to be more focused to understand the impact of the solution on the existing codebase. Working with AI also gave me the opportunity to explore design solutions and propose improvements to the design team.
Claude Code was used by both developers and designers, while Cursor was used mainly by developers.
3. Did design and engineering collaboration change? How?
A typical project would start with a product request, followed by prototyping and validation, refinement within the team, splitting the work into tasks, and then working on it in iterations and sprints until the final solution shipped.
Before designers had access to the code and AI tools, they would ideate, prototype, and explore various solutions, refine them within the team, and hand over specs and designs for implementation. Now, ideation, exploration, and prototyping can happen directly in the codebase. After refinement, they either finalize the design and hand it over for implementation, or make the changes themselves, depending on complexity.
Personally, I like the idea of designers touching code and understanding the impact of their solutions on the codebase. As mentioned before, designers now have access to make trivial changes themselves, which saves developers’ time, but I think the most important part is that their solutions can sometimes bring new perspectives that developers might overlook.
Compared to before AI tools and codebase access, the collaboration itself hasn’t disappeared: there are still meetings and discussions to get to the right solution, and iteration is still a core part of the development process.
This also means code review has gained even more importance, since it’s now the main checkpoint for catching the impact of changes made outside the usual dev workflow.
4. What’s your advice for design and dev teams working with AI workflows?
The best advice I can give is to keep communication tight and human judgment aligned. Even though things can be built very easily now with the help of AI tools, understanding the “why” behind each solution is essential. Both designers and developers should align on why a solution should be implemented, and what the impact would be, both on user experience and on the codebase.
In practice, this means having 1-on-1 collaboration sessions, refinements, and review sessions, with reviews covering both UI testing and going through code review together.
This Role Isn't a Maybe Anymore
What stayed with me from Stefania’s answers is how much it works both ways. Designers can make small changes themselves now, which saves developers time, and they bring in ideas a developer might not have reached for. But it runs the other direction too. Being in the codebase gives Stefania room to spot things and propose solutions back to the design team. Nobody loses a skill here. Both sides just get more to work with.
And the more that becomes possible, the more the human parts seem to matter. Code review carries more weight than it used to, and collaboration matters even more. Underneath all of it, it still comes down to communication and good judgment.
How to Prep for the Design Engineer Role
If you're a designer moving toward this role, here's a checklist Stefania and I put together to help you get started:
The smallest step: prototype something with AI!
Learn the front-end fundamentals: HTML, CSS, and layout with Flexbox and Grid.
Learn how the browser turns your design into pixels, and why some choices are slowing down performance.
Learn Git and GitHub, and how teams collaborate through them: version control, pull requests, and reviews.
Level up on design systems. AI raises the bar: tokens and components that live in code and stay in sync, so what the AI builds matches what you designed.
Take one component past the happy path. Handle the loading, error, and empty states, and make it accessible.
Learn to estimate engineering effort, not just design effort: ask developers why something takes three days instead of three hours.
Pair with an engineer on a real ticket. Watching someone debug live teaches more than any course!
Get deep into one framework. React, or whatever your team uses, enough to build and debug a component from scratch.
Good code comes from good briefs: give the agent context, learn how to structure your project well, work in small steps, and read every change it makes before you accept it.
Stefania's Pick for Designers!
Something practical for designers stepping into the codebase:
Vercel’s react-best-practices skill. An open-source set of 40+ React and Next.js performance rules that your coding agent applies as it writes.
Bakes performance patterns into the components your agent generates, so you skip a later refactor pass.
The rules flag which choices are expensive to build and which are cheap, before you commit to them.
It won’t touch styling, layout, color, or typography. Pair it with a design-specific skill, don’t swap one for the other.
Works with Claude Code, Cursor, Codex, or OpenCode.
Transitioning to this role? I'd love to hear your story.
Thanks for reading! 🫶
More UX + AI Reads 👇🏽
Get the full library of AI skills, prompts, and frameworks! 💎
For designers and product people who want to thrive in the AI era:
The AI UX Risk Skill | The Idea Studio Skill | 100 Principles for Designing AI Products | Control Evaluation Prompt | Framework for Discovering Problems
+more!
New resources keep coming 👌
I’m Ileana Marcut, founder of Creative Glue Lab, a design + development studio focused on digital products, AI-native tools, and systems. I write UX+AI, where I share practical insights at the intersection of UX, AI, and product strategy.
Got something in mind? Email: ileana@creativegluelab.com
 | A guest post by
|
I really like the direction of this article, especially the idea that designers should better understand code, and developers should better understand design.
But I’m curious about another side of this evolution.
Historically, these two roles have looked at the product through different lenses. Developers naturally evaluate whether something can be built, scaled, and maintained. Designers evaluate whether users will understand it, whether they’ll get confused, and whether they’ll be able to accomplish their goals.
Today, we’re talking a lot about the convergence of skills. But do we risk losing the diversity of perspectives at the same time?
It seems to me that one of the reasons great products emerge is because these two roles challenge the same problem from different angles.
I’d love to hear your thoughts on this. As skills converge, do you think these perspectives should converge as well? Or is preserving those different lenses actually what helps teams build better products?