At some point in the early 2010s, the industry decided the answer to every question about the future of design lived in one sentence: “Designers should code.” That sentence spread across conferences, LinkedIn, and bootcamp curricula like an oil slick. Some defended it with apostolic conviction. Others pushed back with equal force. The debate is still running today, and I got tired of it a while ago.
Not because the question is wrong, but because it’s wrong-headed.
Alan Cooper – the man who built some of the first commercial software for personal computers and wrote “The Inmates Are Running the Asylum” – said something about this debate that should have ended it a decade ago: “Performing a task does not automatically teach you the implications of performing it.” The fact that you write code doesn’t mean you understand what your code does to the user, to the team, to the product. And the reverse is equally true – not being able to write code doesn’t mean you don’t understand the system you’re designing.
Cooper named the debate for what it is: a matter of personal taste being presented as universal truth. Like insisting that because you don’t like avocado, avocado is objectively a terrible food.
The real question, the one this debate never actually asked, is different. Not “should designers code?” But: what order do you think in?
A mockup looks like thinking but isn’t
An architect doesn’t lay bricks. But an architect who doesn’t understand how bricks stack designs things that can’t be built, or that cost three times what they should. The difference between “I can lay bricks” and “I understand how bricks work” is the difference between craft and thinking through the material. Nobody argues that architects should become bricklayers. Everyone agrees they need to understand the material they’re designing for.
The design version of this should be obvious by now. It isn’t – and we’ve had twenty years to figure it out.
Karl Koch, a design engineer at DuckDuckGo, described his team’s process: they never open a design file before writing the decision down in words. Not a shorthand note, not a Slack message, not “let’s talk about it on a call” – a literal written document that says: we believe this change will produce this outcome, because of this reason. Only then, Figma.
Why? Because – as Koch puts it – “a mockup is a persuasive object. It looks resolved even when the thinking underneath it is not.” A written sentence can’t hide. You can challenge every word – and that’s the point. You want the argument exposed while the change is still cheap.
I know this from both sides of the table. As a designer, I’ve been in reviews where a wireframe looked great and then it turned out nobody thought through what happens when the user has no data yet, or when the text is twice as long as in the example, or when the connection is slow. As someone evaluating other people’s work – I’ve seen portfolios full of beautiful screens without a single sentence about what those screens were supposed to solve.
A mockup is a tool. The tool doesn’t think for you.
When AI made execution free
For years, the “designers should code” argument had at least one practical justification: designing in the browser, in live code, gets you to the truth of how something actually works faster. Figma is great, but it’s not a browser. A pixel in Figma is not a pixel on an Android phone with system fonts and touch gestures.
That argument is still true – but it stopped being sufficient.
Jakub Krehel, a design engineer at Interfere, describes this precisely through animations. Today anyone can animate an interface. An AI agent will do it in a few seconds. But does the animation make sense? Krehel gives a simple example: a context menu. You can animate it on open and on close. On paper that sounds fine. In practice – if a user opens that menu 200 times a day and the animation runs 300 milliseconds, those animations eat over six hours a year. Per person. Watching a menu appear.
The decision to not animate something requires understanding – not the ability to animate, but the ability to think about why animation exists at all. Krehel says it plainly: “Animating something and animating something well are two very different things.” AI agents are excellent at executing. They don’t yet have the capacity for understanding and judgment.
Figma just announced Figma Motion – animation native to the canvas, with an agent that generates keyframes from a text description. The Lead Motion Designer at Atlassian commented that the tool will “help people develop taste faster.” Access to the tool speeds up exposure. Taste – knowing when movement helps and when it gets in the way – is still something you build yourself. Access to a faster brush doesn’t make you a better painter.
The temptation, when a machine can execute faster than you can think, is to let it. Not out of laziness – out of pressure, out of the reasonable desire to keep up. But execution that outruns thinking doesn’t produce better work. It produces more work that looks finished. And in a world where the output is indistinguishable, the thinking is the only thing left that’s yours.
TJ Pitre put it most sharply: “A prototype that looks finished but uses none of your real components is not progress. It is a liability with good lighting.” A prototype built outside the design system, outside real components, outside the constraints of the actual framework – that’s an illusion of progress, and it costs three months when engineering has to rebuild it from scratch.
The problem isn’t the tool. The problem is reaching for the tool before you know what you want to say.
What it means to understand code without writing it
Code is a material – the same way brick is for an architect, or a lens is for a director. You don’t have to manufacture the brick to understand how load travels through a wall. You don’t have to grind the glass to know what a 35mm frame does to a face. Most directors don’t operate the camera. That’s what the DP is for. What they do instead is understand the camera well enough to know exactly what they’re asking for.
Designers who understand code design differently. They know that “let’s just add a hover animation” is easy in Figma and complicated in CSS on touch devices, where hover doesn’t exist. A component looking like one element in Figma might be eight elements in the DOM, each with its own state – and horizontal scrolling requires separate mobile logic that nobody will think to mention until the prototype is already in engineering. Designers who know this raise those questions before anyone opens a ticket, not after.
None of that knowledge requires writing production code. It comes from talking to engineers enough times that you start hearing the patterns. From reading code without having to ship it. From asking “how does this actually work under the hood” until the answer stops surprising you.
The best example I have isn’t theoretical. A checkout redesign – the kind with serious internal complexity, business validation logic, backend connections checking order integrity and customer credibility at every step. The design system for that project wasn’t built in Figma (well, that’s where it started – until our engineers started asking the right questions about frontend constraints and API communication, and we moved the real work somewhere it could actually answer them). It was built in code, collaboratively, with designers, developers, and business stakeholders in the room together. Frontend work that had been planned for six weeks was done on day one. Engineers had finished components in hand and spent the day assembling views. Nobody built anything from scratch. The thinking had already happened – it was encoded in the system.
The business went into a mild panic. Frontend developers who weren’t building anything felt like a waste of money. That’s the part I still find funny. The work was so well thought through in advance that the execution looked like nothing was happening.
That’s the distinction that code literacy actually gives you. Not the ability to ship a pull request. The ability to feel the resistance of the material while you’re still designing – to know when you’re designing something that can be built with care, and when you’re designing something that will be rebuilt from scratch by someone who has to guess at your intention.
Before you open Figma – do you know what you’re trying to say? Did you read the documentation? Do you have HIG on your resume because it looks fancy, or did you actually read it? Have you talked to the engineer who’ll build this before you made anything that looks like a proposal? Do you know what happens in the error states, the empty states, on a slow connection?
If not, you have a mockup that looks like thinking but isn’t.
Every tool available to you right now is powerful enough to generate something that looks like a finished product – quickly, convincingly, with good lighting. None of them replaces the question you should ask yourself before the first click.
Understand code well enough to think alongside an engineer. Not well enough to replace an engineer – that’s a different job, with its own craft and its own depth. Well enough to know what questions to ask. Well enough to feel the resistance of the material while you’re designing. Well enough that your prototype is evidence of thinking, not a substitute for it.
The debate about whether designers should code has no answer because it asks the wrong question. The right question is whether you think before you build.
Some designers do. That’s why their work ships the way it was designed.