Trying to define Design Engineering today, and why the confusion around it turned out to matter.

Have you ever read a job title and felt like it was made for you, only to lose your smile reading the actual responsibilities? As a designer with a frontend development background, it happened to me more than once. I love UX, doing research, solving user and business problems; but I also love to build and bring solutions to life. Yet hybrid roles were quite rare on the French market, at least in online job postings.

So imagine my joy each time I spotted a listing titled “UX/UI Builder”, “Product Builder” or the rising “Design Engineer”, that carried in themselves the hybrid nature of my professional experience! But under those titles, the job descriptions varied wildly. Sometimes they were 70% design and 30% development, sometimes the other way around, and sometimes they were something else entirely, requiring a lot of strategic thinking and resembling the role of an augmented product manager.

Each of these roles is legitimate on its own. But the inconsistency left me with a question: What actually is a Design Engineer? What’s its DNA? And more broadly, what does this confusion reveal about where the market is heading?

Working at the intersection of design and front-end

As I dove into the subject, I realised that I wasn’t the only one feeling lost. During an online event about Design Salaries in 2026, organized by The Product Crew, Design Engineering was mentioned, and the participants comments were revealing.

Despite the title proliferation, there is a shared DNA. Design Engineering lives at the intersection of visual design and front-end development. Not simply being “good at both,” but a distinct discipline focused on the space where design decisions meet technical implementation.

A Design Engineer can take a concept from initial idea to shipped product, fluent enough in both languages to translate between them without losing fidelity (Gonzalez, 2024). What makes the role distinct is less about the toolset and more about a particular mindset: end-to-end ownership. As Yann-Edern Guillet puts it, the design engineer is a live translator, “when designing, thinking about constraints and implementation; when coding, thinking about intent and aesthetics”.

AI as an accelerator, not the origin

The Design Engineer isn’t a product of AI. But AI has dramatically accelerated both the visibility and the accessibility of the role, by doing something more fundamental: blurring the boundaries between what designers and developers can each do.

Prompt-to-code tools now allow designers to generate functional code directly from mockups or prompts. Designers are shifting from makers of static visuals to active builders. Louis-Auguste Bacot, a design engineer at Alan, the French digital health insurer, gave me his thoughts on the role. He believes that “the role of a designer is bound to change completely,” and that anyone who can’t code, understand code or engage directly with the product will find themselves sidelined within two years. It’s a view shaped by his context: a no-silo culture, an acceleration phase, a role that blurs design, code and strategy by design. My own research suggested a more uneven picture, where AI has accelerated individual work without necessarily transforming collaboration or eliminating roles that don’t touch code. Both things can be true at once.

Conversely, AI is also giving developers the ability to materialise visual concepts quickly, without necessarily mastering tools like Figma. The boundary is becoming porous on both sides.

This is what AI has reshuffled. Not the existence of the role, but its accessibility and its frontiers. And in doing so, it has pushed Design Engineering beyond a bridging role into something harder to pin down; a title that defines new usage.

But the concept has since spilled beyond the individual.

Design Engineering as an AI-augmented workflow

At some companies, Design Engineering has become a deliberate restructuring of how product teams collaborate and ship. Not only a role anymore, but a discipline embedded in the workflow itself.

I first read about UX-dev new AI workflows experiments in mid-2025, through Lital Poria article “From Pixel-Perfect to AI-First: How Jit Revolutionized Our UX-Dev Workflow”, where she explained how she went from Figma to Cursor.

Since then, more organisations are experimenting with new design-dev workflows, sometimes under a clearer “Design Engineering” brand. It was UXDX that brought the sharpest focus to that label, with their free online event in February 2026, “Establishing Design Engineering” where product designer Ella Moran and software engineer Anna Spyker, at Tracksuit, a brand tracking platform, shared how they had built the practice from scratch.

They started from a practical constraint: a tight deadline, engineers at capacity, and visual details slipping through the cracks. Anna set Ella up with an AI coding agent scoped to frontend changes only, connected to the staging backend. By the end of their first session, Ella had worked through an entire list of UI fixes independently.

“I was literally just like sitting there on my phone scrolling on Instagram reels, while Ella did my whole day’s work for me,” Anna summed up.

The scope expanded from there: individual features shipped solo, then the whole product design team onboarded. Their pull requests went through the exact same review process as any engineer’s. Later, the product manager joined a parallel experiment in wild prototyping, in a duplicated repository kept separate from the production workflow.

By the end of the experiment, Ella had started skipping Figma altogether, going straight to Claude Code. Not as a statement, just as the faster path. It’s the kind of small shift that says more about the pace of change than any prediction would.

A similar experiment ran at a larger scale at Alan, presented during a live organised by The Product Crew. Laure Boutmy, product designer, and Tim Petricola, software engineer, built their “Everyone Can Build” initiative around a core observation: developer dependency was a genuine brake on product velocity. Their solution repositioned code as a shared interface between all roles. Designers and some product managers now contribute directly to the codebase via Cursor and Figma MCP, each paired with a dedicated engineering reference who has the final responsibility for merging to production. Tim mentioned that in Q4, they had “over 350 pull requests merged so far. The vast majority of designers have been onboarded; they’re active, so they’re really using Cursor and submitting pull requests.”

Both teams learned hard lessons worth sharing, not as a how-to guide, but as an honest account of what this transition looks like in practice.

• The technical setup remains fragile: a single infrastructure bug was enough to bring things to a halt at Alan, and agent constraints had to be continuously recalibrated at Tracksuit as Ella kept outgrowing them.
• Knowing how to test a change, not just make one, turned out to be half the work.
• Review fatigue is real. And access to the codebase by non-engineers introduces security considerations that need to be addressed early, not retroactively.

And across both experiments, a few lessons stood out to increase the chance of a successful process:

• Find an engineering ally before you start.
• Start small and make it visible.
• Invest in shared education early.
• And acknowledge friction openly: trust with engineers is not granted, it’s built, Laure noted.

What this reveals about product roles more broadly

These experiments reflect that something is evolving in how organisations think about product roles altogether.

Across product roles, expectations are expanding. Designers are anxious about the future evolution of their role, with an ever-growing list of things they’re expected to master (code, strategy, research…). The boundaries between UX research, product design, engineering, and product management are becoming more negotiable.

And companies themselves seem just as uncertain: the inconsistent job descriptions explored at the beginning of this article are not just a naming problem, they reflect organisations trying to scope roles in real time, in a landscape that keeps shifting under their feet. On The Product Crew live about design salaries, the idea was pushed even further: titles are becoming secondary. What matters now is the scope you’re willing to own, and whether you can deliver tangible work within it. Louis-Auguste Bacot himself captures this tension well:

“I’m not a big fan of having a precise role title, because for me that’s not what matters. What matters is what you do.”

That said, this shift is neither universal nor without friction. Larger organisations, regulated industries, and teams with established structures probably still need roles that fit defined boxes. The move toward scope-based hiring is most visible in early-stage companies and teams actively restructuring around AI workflows. For everyone else, the change is slower and more uneven. It’s also wise to take a step back from the AI hype.

So what is a Design Engineer, exactly?

Apart from a shared DNA bridging design and dev, I don’t have a clean, universal answer for what Design Engineering is expected to handle today. And I’m not sure there’s a precise scope yet. What I do have is an observation: the confusion in job descriptions isn’t a failure of HR. It’s a reflection of organisations figuring out what they need in real time, in a landscape AI is reshaping faster than job titles can follow.

What I’ve come to believe, after all this research, is that Design Engineering is less a role to fill than a stance to take: the willingness to own the full arc from idea to shipped product and to move fluidly between design intent and technical execution. Whether you call it Design Engineer, Product Builder, or something else entirely, that stance is what the market is actually asking for. The title will settle eventually.

Special thanks to Louis-Auguste Bacot for his perspective and to UXDX for the guidance.

The design engineer symptom: what a rising job title reveals was originally published in UX Collective on Medium, where people are continuing the conversation by highlighting and responding to this story.