What a Design Engineer Is in Tokyo, and Why There Are So Few

A design engineer in Tokyo in 2026 is one person who decides what a product should be, designs it, writes the production code, and ships it under their own name. I am Carlos Lastres, an AI product designer and design engineer in Tokyo, and that sentence is my job description. This article is about where the role came from, why so few people in this city hold it, and what it looks like on an ordinary Tuesday.

Japan named the role first

The title is older than most people think, and it is Japanese. Shunji Yamanaka left Nissan's design studio, went freelance in 1987, and founded Leading Edge Design in Tokyo in 1994. The Japanese Design Archive Survey credits him with establishing a new profession called design engineer: someone who draws the object and also understands the mechanism inside it. His Tagtype keyboard, built with Kinya Tagawa, who later founded Takram, was selected for the permanent collection of MoMA in 2009. Takram still lists its people as design engineers, from an office in Jingumae.

That lineage matters because it tells you what the word meant here. A Japanese デザインエンジニア was a hardware person. The product had a shell and a mechanism, and the rare individual who could reason about both was worth more than a designer and an engineer sitting in separate rooms.

The mechanism became software

The product I work on most days has no shell. It is an app, a website, a voice in a menu bar, or a model answering a question out loud. The mechanism is code and the behavior of a language model, and the design is how a person experiences that behavior. The two cannot be separated, because the interesting decisions only show up once the thing is running.

Here is the version of this I keep coming back to. When I built Glimpse, an iPhone app that looks through the camera and answers out loud, the design question was not the layout. It was what happens in the half second between the question and the answer. On a mockup that gap is invisible. In the running app it is the whole product. I only found the right answer because the same person who drew the screen could also change the streaming code, try it outside with real noise, and change it again before lunch.

So the 2026 version of the role is Yamanaka's idea with the mechanism swapped. One person carries the product from the first decision about what it should be, through the interface, into production code, onto the store, and through whatever happens after launch. In my case that includes the business side too: pricing, the paywall, the checkout, the support email. I have written about why the handoff stopped being the point, and this is the practical consequence. There is nobody to hand it to.

Why Tokyo has so few

Search for デザインエンジニア in Tokyo today and most of what comes back is mechanical design jobs and a handful of studio profiles. The software version of the role barely exists as a title in Japanese companies, and I think there are three reasons.

The first is where design sits. When METI and the Japan Patent Office asked 25,000 Japanese manufacturers what made them successful, 0.8% credited design for the domestic market and nobody credited it for the American market. Seven years after the government's own Design Management Declaration, design in most Japanese companies is a department that receives decisions. A role that makes product decisions and writes code at the same time does not fit in that org chart, so the org chart does not produce it.

The second is the talent pipeline. IPA's 2025 survey of digital transformation found that 3.8% of Japanese companies consider the quality of their digital talent adequate, against 52.9% in the United States. The people who could grow into design engineers are mostly on an engineering track that never touches a user, or on a design track that never touches a repository. I wrote about the productivity number behind the engineer shortage, and the short version is that the shortage is partly a shortage of people allowed to decide.

The third is language, and this one is personal. Most of the AI tooling, the documentation and the conversation about this kind of work happens in English. The products ship to Japanese users. A design engineer in Tokyo has to live in both, and in my case also in Spanish and Chinese, because the clients and the users do. That filter alone removes most candidates.

None of this is a complaint about Japan. It is the reason the role is valuable here. A city with world class hardware design engineering, a government that has been asking companies to take design seriously since 2018, and a very small number of people who can design and build software products is a city with an enormous gap between what is possible and what gets shipped.

What the job looks like on a Tuesday

People imagine the role as a designer who learned to code, or an engineer with taste. In practice it is a sequence of decisions, and the sequence is the point.

A Tuesday for me starts with whatever broke overnight. Say a review for AnimaEcho reports that the voice cut out on an older iPhone. I open the project and reproduce it, and in a voice app that kind of bug is usually a design decision in disguise: the app was waiting for a silence that never came, so the real fix is a visible way to interrupt her. I design that and build it in the same hour, and by mid morning it is in TestFlight.

Then client work. A Japanese company wants an AI feature in their product, and the request arrives as a screen. My job is to turn it back into a question about what the model can actually do, what the user needs to understand, and what happens when the model is wrong. I prototype the answer in working code because a Figma file cannot show you a model being wrong. I use Claude Code for most of that, and I hold Anthropic's Claude Partner credential for it, which mostly means I have shipped enough with it to know where it fails.

The afternoon is the part that never appears in a portfolio: the subscription that did not restore, the Japanese copy that read like a translation, the shipping form for AnimaNext that has to work for an address in Tokyo and one in Texas. Each of those is a design problem, an engineering problem and a business problem at once, and each of them is why one person holding all three is faster than a meeting between three.

How to tell whether someone is one

Because the title is rare, it gets claimed loosely. Three things separate a design engineer from a designer with a GitHub account.

There is a product with their name on the store listing. Not a contribution, not a team credit. Their name as the seller, which means they handled everything from the privacy declaration to the screenshots.

There is code they wrote that is running for strangers right now. A repo, a package, a live app. Something that can break and that they would have to fix.

And there is a design decision they reversed after seeing it running. That is the real test, because it proves that the designing and the building happened in the same head.

I keep a dated list of what I have shipped so that anyone can apply those tests to me, and I wrote a separate piece on how to hire a design engineer in Tokyo for people who need one and do not know what to check. The role Yamanaka established from this city thirty years ago is still the most useful one in product work. It just builds different things now.