For years, product designers kept asking "Should designers code?"

It was a reliable conference talk and perfect rage-bait. Pick a side, explain why the other side did not understand design, collect applause. The argument treated code as a secondary skill. A nice-to-have.

While we argued, the tools changed. Design tools added components, variables, constraints, and prototyping logic. People complained that design systems stripped creativity from design. Engineers mostly seemed relieved to have some rules. Then AI tools started shipping functional interfaces from a sentence. At that point, the question stopped making sense.

Designers need to understand the substrate in the way a ceramicist understands clay. They need to know which changes take five minutes and which take two days. Border radius isn't usually a hill to die on. The interaction model of a flow absolutely can be. You learn the difference by opening the product, changing it, and seeing what breaks. YouTube can help. It cannot do the breaking for you.

The old model—designer draws picture, engineer makes picture interactive—made drift inevitable. Every handoff left room for the decision to get lost. The best teams I've worked in left little room for that. A designer could look at a component and know what it would cost to change. An engineer could look at a flow, understand its effect on the user, and change it quickly.

Now the thought leaders have arrived, late as usual, to announce that everybody is a builder. The future belongs to the "full-stack product manager" or whatever title gets the most impressions this week.

Underneath the rebrand, the jobs are changing because the tools no longer enforce their old boundaries. A designer who prompts a working prototype into existence is making engineering decisions, whether they like it or not. An engineer who changes a flow after talking to a customer is making a product decision. The title does not matter much.

Every good product designer I know eventually learned enough about engineering constraints and product priorities to argue with both. Good work demands it. You cannot design a system without knowing how it works, and you will not ship anything good for long without opinions about its implementation.

I spent years learning languages, frameworks, and methodologies because I got tired of losing decisions in the handoff. That knowledge was hard-won and difficult to explain to people who thought design was pixel work. But it made me useful in a room of engineers. Now a designer with Cursor and well-formed opinions can produce something that would have taken significant effort five years ago. Cursor compresses some of that learning into months. The awkward edge cases still turn up when you try to ship.

The should-designers-code argument can stay dead. A ceramicist does not debate whether the kiln counts as part of the job. They learn how it works because the alternative is broken pots and wasted time.