One Person, One Motion
Design engineering isn't a designer who codes or an engineer with taste. It's the refusal of the handoff — and the handoff was always where intent went to die.
Fifteen years ago I animated frame by frame. The thing I learned wasn't motion. It was that intent degrades every time work changes hands.
You feel it first in a cut. A director imagines a moment; an editor approximates the imagining; a note-giver approximates the edit; and three passes later the thing on screen is a photocopy of a photocopy of an idea nobody can quite locate anymore. Every translation loses information, and the loss compounds. I spent years getting good at reducing the number of hands — doing the concept and the edit and the color, so the idea traveled a shorter distance to the screen.
Then I moved into product, and found the same disease with a different name. It's called the handoff.
The Handoff Was Always the Bug
Here is the standard pipeline, and here is where it leaks. A designer imagines an interaction. They produce a mockup — already an approximation, because a static frame can't hold timing, and timing is half of how an interface feels. An engineer implements the mockup — a second approximation, because the spec never answered what happens when the data is empty, or slow, or wrong. Then everyone gathers in a "design QA" meeting to reconcile the implementation with the intent, which is a polite way of saying: to recover the information the pipeline just destroyed.
I don't think the handoff is inefficient. I think it's lossy, which is worse. Inefficiency costs you time. Lossiness costs you the product — the specific texture of the thing you meant to make, sanded off one approximation at a time until what ships is merely fine.
Motion taught me this in miniature: a transition either builds trust or breaks it, and the difference lives in fifty milliseconds of easing that no mockup can specify and no spec can carry. If the person who felt the interaction isn't the person who tunes the curve, the curve is a guess.
Not a Designer Who Codes
"Design engineer" gets read as a hyphenate — a designer with a coding hobby, or an engineer with taste. Both miss it. The role isn't two skills stapled together. It's the deletion of the seam between them: a single custody chain from "what should this feel like" to "what shipped," with no translation step in the middle because there's no second person to translate to.
That's why the artifacts are different. A designer's deliverable is a file that describes the product. A design engineer's deliverable is the product — the running thing, with its empty states and its focus rings and its 60fps and its accessible markup, because those aren't a later engineering concern, they're where the design actually lives. When I built a dispatcher dashboard, the design wasn't the mockup of the card; it was the custom component that made a busy person scan a hundred rows ten times faster. The design was the code. It usually is.
AI Raises the Stakes, Not Lowers Them
The obvious read on AI is that it commoditizes the building, so the building matters less. I read it the opposite way.
When scaffolding is nearly free — when a model can stand up a state machine or a RAG pipeline in an hour — execution stops being the bottleneck. And when execution stops being the bottleneck, the bottleneck becomes judgment: what to build, whether this is that, where the model's plausible output is subtly wrong. Taste doesn't get cheaper as generation gets cheaper. It gets more valuable, because it's the scarce input now.
This is why I use AI daily and verify everything by hand. The model drafts; I check every ARIA role against the spec, every edge case, every money path. Not because I distrust the tool — because the tool moved the job. Writing the code was never the point. Deciding what code should exist, and whether this code is that code, is the whole thing now, and that decision is not delegatable.
The design engineer is the person the AI era was waiting for: someone who holds the full custody chain in one head, moves at the speed generation now allows, and has the taste to know when the fast, plausible answer is the wrong one.
The Refusal
So the role isn't a job title to me. It's a refusal — of the handoff, of the lossy pipeline, of the idea that "who imagines it" and "who builds it" have to be different people passing approximations across a wall.
The throughline hasn't changed since my motion days: make complex systems feel simple, and never lie to the user. You can't do either from across a handoff. You do it by holding the whole thing — the intent and the implementation, the feeling and the frame budget — in one pair of hands, and refusing to let it out of them until it ships.
Design is how it works. That was always an engineering claim.
This is the argument; the work is the evidence. If you're building something where one person owning the whole surface would matter — I'd like to hear about it.