If you hang out on Twitter, you’ll realize that every designer, PM, and their dog are now engineers.
LLMs have dramatically reduced the barrier to building something and designers who’ve never been able to go beyond a spaghetti Figma prototype suddenly feel like Superman.
But was the designers ability to write code the bottleneck to building better software?
The commentary below is through the lens of a startup, big orgs may have different experiences with more granular role definitions.
How Design Used to Work
The traditional separation between design and development wasn’t just organizational, it was cognitive. Each discipline had distinct mental models:
- Designers wrestled with what the solution should be
- Engineers focused on how the final solution should be implemented
This separation created productive constraints. When designers couldn’t easily build the thing, they were forced to:
- Sketch widely and expansively
- Create multiple concurrent prototypes
- Use cheap, throwaway materials
- Embrace waste in the prototyping phase (where waste is cheap)
The constraint of not being able to write code was, perhaps, a blessing.
I’ve written before about the value of staying low fidelity. Before LLMs unlocked code for designers, the fidelity trap was present with high fidelity Figma mockups.
The Displacement Trap
HCI researcher and tools for thought advocate, Andy Matuschak discusses displacement behaviors. Rather than sitting with a problem and the discomfort it brings, we switch to an activity with short-term payoff. Coding a prototype can become exactly this kind of displacement activity.
The dopamine hit of shipping something functional is real, anyone who has done it will agree.
It feels like progress that an idea you had is now “working” software. But this satisfaction can mask whether you’ve actually solved the right problem.
The Fidelity Problem
When building physical artifacts, we don’t morph early prototypes into the real thing. Car designers move from sketches, to 3d models, to clay etc. The medium is different, we use cheap materials specifically designed to be discarded. Yet with code, there’s a psychological pull to build on what you’ve already created.
For inexperienced engineers, untangling semi-working code isn’t a trivial task and eats time that should be spent elsewhere.
The closer you are to the final form, the less likely you are to rip it up and start over. But ripping everything up is exactly what good design requires.
The Right Tool for the Right Problem
For every design challenge, we should ask:
What medium allows me to:
- Validate this idea for the least cost in the shortest time?
- Create as many possibilities as possible without premature constraints?
- Communicate the right amount of detail to the intended audience?
Sometimes that’s code. Often it’s not.
The designer’s skill is proportional to their ability to select the right tool for the right problem, not their ability to create passable react code.
As an aside, I believe the ability to create coded prototypes, especially for usability testing is a seismic breakthrough. Gone are the days of faking a text input field in Figma.
Questions to Consider
Before reaching for the code editor, ask yourself:
- Which stage of the design process am I at right now?
- What question am I trying to answer, and what’s the simplest prototype that can answer it?
- What form factor can I create to move forward with sufficient confidence?
- Does this coded prototype represent one potential idea, or have I explored the entire solution space?
- Am I able to create multiple, concurrent prototypes with different approaches?
The Real Value of Design
The value of design work is in uncovering, stumbling upon, and arriving at more optimal solutions through exploration. It’s about creating choices, then making choices.
Is “vibe coding” doing that? Or is it just building the first thing that comes to mind because we finally can?
Conclusion
LLMs are an incredible unlock.
Non-technical people can create real websites and apps for side projects and rapid experimentation. Aside from the artifact, the designer can start to build up a mental model of how code runs, how a project is structured, and how to write clean code. Especially if the designer moves beyond Lovable/ v0 and into an IDE.
If you’re a designer working in a team, the question isn’t whether you can code your prototypes, it’s whether you should.
The best designers know that their job isn’t always to build things. It’s to find the right things to build, in the right way. And sometimes, the best way to do that is to keep your hands off the keyboard and pick up a pen instead.
- This simplistic diagram assumes user needs or requirements come from ‘somewhere’ and a final design solution is delivered ‘somewhere’. ↩︎