Robin Spielmann takes a stab at defining “design engineer”:

The role [of a design engineer] is: there is a specific set of tasks that has to be done in every digital product, and on most teams nobody is responsible for them.

A design engineer understands there’s a ton beneath the surface of a static mock:

A [static screen] shows a product at its best. One screen width, plausible data that someone made up, and the path where everything goes right. Shipping that same screen means answering a much longer list of questions. What happens with a name that’s sixty characters long? Does the layout jump around when the data finally loads? What if there is no data at all, and is that an empty state or does it look like something broke? What about a slow connection, a narrow phone, someone who never touches a mouse?

Making decisions around those questions is the job of a design engineer:

[a great product is] the sum of a few hundred small decisions, none of which would survive being written down as a requirement.

There’s the reality right there! There’s just too much to write down and convey as requirements (plus trade-offs have to be made). You need someone who 1) understands these concerns exists, and 2) takes them on with care.

I kinda like this working definition of a “design engineer”:

A design engineer is the person who owns whether a product still agrees with itself.