Being design engineers shouldn't make us less like designers. The work isn't to flatten ourselves into everything, but to know our altitude, point our compass, and walk.

The age-old question: should designers code?

Code generation is easier than ever, and more of us can make something real enough to click, test, and share. So the question's evolved: should designers ship production code?

Roles aren't dissolving so much as getting clearer. The pressure to be everything mistakes access for care, and access is what AI is making cheap.

So do all designers need to become design engineers? I'm arguing no. Some designers create more leverage by staying close to brand, research, taste, narrative, systems, or direction. But more designers need to understand what kind of material they are holding: clay for learning, or bricks for load-bearing software.

The Map isn't the Territory

Alfred Korzybski wrote this line in 1931. The usual reading is simple enough: be humble about our models. The world is bigger than our representation of it.

The map isn't the territory — but the map is useful because it isn't.

A map strips out what we don't need so we can see the path. The territory has too much in it; the map is an artifact small enough to hold.

AI floods that layer. Agents give us access to something close to infinite maps. They can read our codebase, summarize our meetings, simulate our users, draft our specs, and generate twenty design directions before lunch. We're not short on maps anymore.

The bottlenecks have moved to the questions maps can't answer. A map still needs someone to read it; otherwise it's just markings on a page.

Navigation can leverage maps.

Altitude determines what we see

A map is flat, but the territory has dimension. You can fly over it at thirty thousand feet or crawl through the underbrush, and both views are useful for different things.

At high altitude, we see the system: the user's whole journey, the brand vision, the architecture, the way pieces relate. At ground level, we see the constraints: the kerning, the snap of a microinteraction, the cost of a re-render, the exact way state flows.

Neither view is more real than the other. They reveal different things.

Design isn't only high; engineering isn't only low. Designers operate at every altitude, from brand strategy to easing curves. Engineers do too, from system architecture to memory layout. The discipline doesn't pick the altitude. The work does.

A design engineer's job isn't to "do both." It's to traverse: to move between altitudes deliberately, holding context as we go, so the high-level intent survives the descent into implementation and the low-level constraints inform the next ascent. The skill isn't living everywhere at once. It's knowing where we are and how to move.

Specialization is a magnifying glass. It concentrates effort into a focused beam. Breadth without intention is closer to a dimmer switch, spreading our attention across a wider area at a lower brightness everywhere.

We don't have to flatten into generalists to be useful. We have to know our altitude.

Prototypes: an altitude for learning

A prototype is a deliberately chosen abstraction, a map of a possible product. It keeps what we need to learn, like the interaction, the flow, and the feel, and leaves production code, architecture, and the deploy pipeline out of frame.

A prototype shows us the journey before we have to build the road.

That's why prototypes are often more useful than production code for design work. A prototype optimizes for learning. Production code optimizes for shipping and scaling. They are different jobs at different altitudes.

A designer who builds high-fidelity, interactive prototypes isn't necessarily stepping into engineering territory. They may simply be staying in design and using a sharper tool to do design work.

AI maps need human compasses

A map without a compass is a trap. We can see every possible path and still have no idea which one is ours.

Our compass is care, but not in the tidy sense of always knowing what matters most. Care is what makes us keep touching the material. It is the itch to move a line three pixels, rewrite the empty state, throw away the generated option that is almost right but not alive yet.

AI doesn't have that part.

Agents can hold more maps than we can read. They can do enormous amounts of work and can be prompted to apply standards, weigh tradeoffs, and optimize. They can even tell us which direction is "good" if we give them the criteria. But that judgment is only as useful as our understanding of it. If we do not understand the standard ourselves, we are not choosing; we are borrowing a preference and hoping it holds.

We cannot outsource that kind of care. AI can give us clay. Agent harnesses are like pottery wheels: they help us shape more material, faster. But the same underlying stuff can become a brick. Clay is for finding a form. Bricks are for bearing load. They afford different work.

Leverage direction, not AI output

There's a concept worth knowing called capability overhang: models can do more than we can verify. They ship work faster than we can review it. If we treat our job as "check the AI's work," we've already lost. They're faster than us, and there are more of them.

Our job isn't to stand at the end with a red pen. It's to stay in authorship of the work: choose what we are making, set the constraints, shape the material, and decide when the result is worth shipping. AI can work on our behalf. It cannot decide what the work is for.

Our leverage with AI isn't output, because output is cheap. Our leverage is direction.

Attention is the new bottleneck

The asymmetry has another side. Agents and humans both have finite context windows. Theirs grows by engineering: new models, more tokens, every year. Ours grows by experience, slowly, through practice.

Our context window grows too, just not at the same rate.

We have finite time and attention. Every meeting, Slack channel, dashboard, codebase, and PR is now summarizable, queryable, and scannable. The friction that used to limit us is gone.

Gathering context used to be expensive. Now it's cheap, but consuming it is still expensive. That's the bottleneck we live inside.

Time is the only resource that doesn't scale. Where do we point it?

The map metaphor goes one layer deeper. We don't just choose what goes on the map. We choose which maps to read, for ourselves and for the agents we direct.

Traversal is the actual work

A map and a compass aren't enough. Someone has to take the journey. That's the work.

The everything-at-once pressure forgets this. We talk a lot about who's a designer and who's an engineer and where the line is. Meanwhile, the actual making of the thing is still in front of all of us.

Traversal is not an identity exercise; it is the work itself. The prototype gets built, the screen gets shipped, the user says the thing we did not expect, the bug shows up at 11pm. Maps and compasses tell us where to walk. The walking is still the job.

Walk where we create leverage

On any given project, not every stretch of the traversal is ours to walk.

The argument so far might sound like "specialists beat generalists." It's more specific than that. Generalists win when the seams between specialties matter more than the depth within them: when synthesis has to happen in one head, when the picture is changing too fast for sequential handoffs, when the coordination cost of four specialists outweighs their depth advantage. Specialists win when depth has to happen in parallel, when stakes are high, when the work is mature enough to be cleanly differentiated.

A design engineer isn't a generalist. A design engineer is a specialist in traversal. Moving between altitudes is a specific skill, not "okay at everything." The two get collapsed all the time.

Inside a team, the question isn't who is most capable at this task? It's whose attention is most useful here?

A senior designer might technically be the best person to fix a layout bug. But if their time is more valuable on the next prototype, the bug isn't theirs. Delegation isn't giving away the parts we don't want. It's flying at the altitude where we're most needed and trusting the team to walk the stretches that aren't ours.

Index on our strengths, but relative to the team. Our strengths aren't just personal; they're a question of where we create the most leverage for the people walking with us.

Expand craft, don't dilute it

Being design engineers shouldn't make us less like designers. And it shouldn't make us less like engineers.

The everything-at-once narrative treats roles like a checklist: add code to design, add design to code, add product sense, add research, keep stacking. But people aren't stacks. We have finite attention and finite craft. Every skill we graft onto the surface costs depth somewhere else unless we're deliberate about it.

Design engineering should be additive, not subtractive. We take what we're already great at and extend it with enough adjacent fluency to traverse altitudes. We don't trade our care for our tooling. We don't trade our engineering rigor for our visual sense. The point of traversal is that the parts strengthen each other: our design work gets sharper because we understand the material, and our engineering work gets sharper because we can see the user.

The gift of design engineering isn't a new identity. It's the context. Holding altitude across design and engineering is what makes us better at the thing we already are.

If the trade is going the other way, that's not growth. If we've added code but lost care, or added research but lost rigor, we've polluted the role, not grown into it.

Even within design engineering, there are archetypes. The design engineers I look up to most — Rauno Freiberg, Andy Zhang, Bradley Ziffer, Maxime Heckel, and others — each have a spike. Some start as designers and learn to ship their ideas into production. Some start as engineers and learn to care deeply about the user's experience. Some are fluent in both, but still have a center of gravity that shapes how they make decisions.

AI has democratized the creation of code, but not software engineering. Those are different things. Development is not always engineering. Code can be clay: fast, disposable, useful because it lets us feel an idea sooner. Code can also be brick: reviewed, tested, secure, maintained by a team after the initial thrill is gone.

That distinction matters more as AI gets better. Addy Osmani's framing of vibe coding and agentic engineering is useful here: vibe coding has a real place in exploration, prototypes, one-off tools, the messy early pass where we are trying to find the shape of the thing. But vibe coding is not the same as agentic engineering. In agentic engineering, the agent may write the code, but the human still owns the plan, the architecture, the tests, the review, and the decision to ship.

So the question for design engineers is not whether we should be vibe coders or agentic engineers. We need both modes. The danger is mixing them up: treating prototype code like production code, or dragging production rigor into a moment that only needed a sketch.

We are not the role. We are people doing the role. The role tells us the shape of the work: traverse, hold context, choose the altitude. The people we are — our strengths, our care, our compass — are what we bring to that shape.

We don't have to be unicorns. We have to be unmistakably ourselves, at the altitude where we operate best.