Article

Know Your Medium

The should-designers-code debate is dead. What matters now is knowing your medium.

Feb 2026666 words

For years, design discourse revolved around the question "should designers code?"

It was a consistent conference talk, and an argument for either side made for perfect rage-bait. It generated so much heat because it was always the wrong question, maybe even a deflection. It assumed that coding was a secondary skill. A nice to have.

While we were arguing about it, the tools moved. Design tools started thinking in systems, logic, and architecture. People lamented design systems from stripping creativity from design, while everybody in surrounding professions celebrated at having design guidelines to lean on. Then AI tools started shipping functional interfaces from a sentence. And the question stopped making sense.

Designers must understand their medium the way a ceramicist understands clay. The ones who ship things that hold together understand the substrate. They know the line between expensive and cheap. They know that border radius wasn't a hill to die on but the interaction model of a flow absolutely was. They have taste about where to spend complexity. That knowledge can only come from proximity to the material, not youtube tutorials.

At the same time, the old separation of designer draws picture, engineer makes picture interactive, was always a broken handoff process. Every layer of abstraction between intent and implementation introduced drift. The highest-impact-and-quality teams I've been a part of were the ones where there was no space for drift, where a designer could look at a component and know without asking what it would cost to change. Where an engineer could look at a flow and rapidly implement changes by understanding user impact.

Now that thought leaders have arrived late and ready to preach the hot topic of the time, the narrative is that everybody is a builder. The walls between disciplines are coming down and the future belongs to the "full stack product manager" or whatever other title gets the most impressions. And again, we're back in the ragebait era of product methodology and skillsets.

What is actually happening is role collapse. The boundaries between product management, engineering, and design are collapsing because the tools no longer enforce them. A designer who can prompt their way to a working prototype is making engineering decisions whether they like it or not. A designer or engineer who understands the user and the business is making product decisions whether anyone gave them that title or not. And this was always the trajectory for anybody who took product design seriously.

Every good product designer I know eventually drifted into the liminal space between design, engineering, and product strategy. Not because they wanted to, but because good work demands understanding the substrate. You can't design a system without understanding how it works. You can't make meaningful decisions without understanding business priorities. You can't ship anything good without having opinions on implementation.

I spent years sitting in that space, learning languages, frameworks, methodologies. The knowledge was hard-won, and often hard to communicate to people who think design is pixel-work. But it's what made me useful in a room of engineers. Now that a designer with Cursor and well-formed opinions can produce something that would've taken significant effort five years ago, the time to build intuition is compressing into a year.

The dissonance isn't really about this compression, it's more about watching wave of thought leadership describe a revolution, when for many of us it's just an acceleration of what we were already doing. We were already working in the medium.

While tools make it easy to produce anything, producing the right thing is still as hard as it ever was. Good judgement doesn't come from a prompt. Understanding the constraints and possibilities of your medium is still the work. The question isn't whether designers should code, or whether PMs should be builders. The question is whether you understand the material well enough to make good decisions.

Indie hackers always existed, exist now, and will always exist. The ceramicist doesn't ask whether they should understand the kiln. They just understand it, because the alternative is broken pots and wasted time.

Writing