12-21-25
Fig. 1
Last week, Cursor announced AI-powered visual editing and design Twitter erupted.
We've been here before.
This is the "should designers code?" debate wearing a 2025 AI costume. It's shown up over the years to varying degrees and it'll show up again in a few years when the next tool promises to close the gap between canvas and code.
Why does this debate refuse to die?
"Designers should code" keeps coming up because the end product of our interfaces is ultimately code. Many think the faster we get to code, the faster we have a real interface.
And that is true, with a small caveat.
This gap has always existed. It will likely never go away because it reflects two different ways of working with a medium.
Since we're building digital products, there's a big appeal to directly manipulate the end product. And because many don't feel comfortable with code or even this process in general, they will hold on to their sacred objects on a canvas.
I myself have one foot firmly planted in each of these camps. But I believe there is room for both. It's not a binary decision.
I'm a designer who finds a lot of value in moving objects around the canvas, and who can write HTML and CSS from scratch, and really loves building things with AI.
There is something fundamentally different about freeform exploration versus direct end product manipulation. The same way there's a big difference between drawing with a pencil on paper, moving objects around on a screen, or writing words in a journal versus typing words on a screen.
And now we can have AI do some or all of that for us.
But they're all different techniques using different tools. They are all useful. We don't need to limit ourselves to only one.
Both sides of this debate are arguing from different points on a very long design-code continuum.
Designing in code can limit your vision if you're not used to thinking and building simultaneously. The tools you use will absolutely affect the way you think and approach a problem.
Even if I feel comfortable designing in code and building with AI, it shifts my perspective to a narrower point of view. Which is not always a bad thing. But it can mentally constrain me. Even though I feel comfortable working from both ends of the spectrum.
On the other hand, we're not usually talking about world-changing design. We're often talking about text and buttons on a screen. Many of these problems can be solved by directly manipulating the medium.
But there are larger problems that require us to sit back, think, cast a vision, and challenge assumptions before building. Fast does feel productive, but speed can hide the fact that you haven't actually solved anything meaningful.
This debate continues because there hasn't been a shared baseline for where this decision should take place. It's always been either or.
Are we prototyping with throwaway code, or committing critical production code to an app with millions of daily active users? Vastly different contexts. Not worth merging them into a single conversation.
The architecture analogy comes up a lot. Architects still sketch before they build. There's a lot of value in planning, dreaming, sketching, and then building.
However, that's also based on the idea that physical buildings are irreversible. You can't iterate on a foundation or structural things very easily once a building is fully up.
With code, this is different. You can iterate on it once it's up.
Sometimes casting a vision, counting the cost, then moving forward is the best approach. Sometimes building quickly and iterating wins. It's not always either or. It can be both and.
There's also the standardization fear. There's been worry that unified tools and shared primitives will lead to cookie cutter design.
But to use the building metaphor again, 2x4s and 4x8 sheets of material are actually a good thing. Sixteen inch center studs are a good thing.
So I say let cookie cutter primitives happen. Every font uses the exact same alphabet. Every song uses the same 12 notes. Some people will always want to build something unique regardless of those primitives.
Some people like cookie cutter. Subdivisions have their place. Others prefer unique custom homes. They can both exist. And they are largely built with some of the same base pieces of material. The market for each is real.
The idea that everything may become cookie cutter is not an actual problem. It's a theoretical problem. Meanwhile, there are real problems with real impact waiting to be solved.
So let's solve actual problems. Let's ship things that matter. Yes, we can plan for the future. But spending too much energy on potential problems that aren't actual problems is a distraction.
When standardization becomes a real problem for your work, deal with it then. Until then, let's build.
For designers watching this debate, get as much experience as possible.
Learn to get good at design. Learn to work fast with AI. Get good at casting a vision and thinking in abstract. AI is not good at vision and taste. This is where designers can add the most value.
Build your vision-setting skills through whatever means necessary. If that means getting really good at traditional design, do that. If it means going hardcore into AI and manipulating code, do that. Maybe, just maybe, do both.
My word of caution... if you rely too heavily on AI from the very beginning, you may never develop those vision and taste skills. Or they could potentially diminish if you aren't flexing that muscle regularly.
This is a unique opportunity for us humans, to creatively express ourselves through the medium in service to others. Whether this happens on the canvas or in code, there is an end goal. And it's not fully dependent on the process or tool.
The tech world will always move quickly. Tools will change. But what doesn't change is the fundamentals. Understanding a problem before jumping to solutions. Asking why.
Designers who understand fundamentals can pick up any tool. The tool is just a means to get there.
A few years from now, these conversations will have evolved. New tools, new workflows, new attempts to close the gap between canvas and code.
But the debate will return. It always does. Because the fundamental tension isn't about tools. It's about people arguing from different positions on a spectrum without acknowledging it.
We have fantastic tools available to us. Let's use them all.
But before you jump into the next debate, know where you're standing. And where the opposing opinion is standing. That's what's actually missing from these conversations.
Not better arguments. A shared baseline.
Practical design wisdom delivered weekly.