In Figma’s not a design tool—it’s a Rube Goldberg machine for avoiding code, Michael Buckley revives the perennial debate on whether designers should learn to code with this blaring call to action:

Somewhere, a designer is meticulously adjusting auto-layout settings in Figma—crafting an intricate set of nested components, master variants, and esoteric constraints—all to simulate the behavior of a simple button …

If you’re going to spend hours creating intricate simulations in Figma, you might as well put that effort directly into code—because in the end, code is where your designs must ultimately function.

Oof.

Yes, it is true that code is the medium of software. And, yes, it is also true that code is where “designs must ultimately function.” But, does it necessarily follow that designers should learn to code? In this day and age? Let’s face it: The days of wiring up “noodles” to create prototypes in Figma and other design tools are dead. But it isn’t because designers are learning how to code. Instead, AI is putting the nail in that coffin.

Here’s what I see happening, both across the industry and where I work: Some designers are coding, but not in the traditional, time-honored, learn-to-code-by-cracking-open-a-book-and-furiously-typing kind of way. Instead, they’re vibe coding. AI-based programming tools like Cursor—tools targeted squarely at the developer market—are disrupting the design process. Designers who previously were only drawing pictures of software in Figma are now wandering into the interdisciplinary space between design and engineering. They are prototyping and making software—not with visual programming tools, but with AI agents and text-based code. And in the process, they are inadvertently picking up basic knowledge of HTML, CSS and JavaScript. Some are even moving beyond the basics, transforming themselves into nascent design engineers.

I find this fascinating, and as someone who has made a career in the UX design engineering space, rather exciting. For myriad reasons—from the burdensome maintenance of LLM-generated code, to the imprecision of LLM-generated edits, to the hallucination of APIs and third-party libraries—it remains to be seen whether this new breed of AI-based programming tools will really lead to a full step-change in productivity for production software engineers any time soon. But, in the context of design and prototyping, the same limitations that make these tools challenging to use for production are irrelevant. Prototypes don’t need to be maintained, and they typically have few security requirements. They also can be scrapped and re-built over and over again. In fact, the entire purpose of design prototyping is to learn as quickly as possible through rapid exploration, testing and iteration. This is a space well-suited to embrace vibe coding.

But what does all this mean for those of us who have made a career out serving as the bridge between disciplines? What does the use of AI tooling by designers mean for the UX engineers, the design engineers, the design technologists, and other design-engineering hybrids?

I think it means opportunity.

For the past few months, I’ve been setting aside time on Fridays for casual conversations with design technologists, UX engineers, design engineers, and a variety of other folks—often students—aspiring to have one of these job titles. We talk about everything from career paths to organizational structure to design collaboration to prototyping strategies. AI is never the first topic of any of these conversations, but I can always sense when it is coming. It is that proverbial elephant in the room who coyly tip-toes from some dark corner to take center stage just before our allotted 30 minutes expires. What do you think about AI? What do you think it means for … us?

I’m not big on gatekeeping. Lowering barriers to entry to programming, and making it easier for more designers jump in and prototype their own ideas is wonderful. We want to make it easier for designers to move beyond drawing mere pictures of software to making working versions of those same pictures. We want them to make prototypes. More prototyping means more testing of designs and, ultimately, better design outcomes and better user experiences.

More prototyping also means better communication with engineering. If a designer is able to move higher up the fidelity spectrum on their own, then it’s less likely that things will be lost in translation as engineers implement the design vision in production. Engineers will no longer have to reference only Figma files, where it is sometimes difficult to impossible to convey all the details around application behavior or animation. Instead, they can just play with the working prototype and try it out for themselves, possibly even borrowing the AI-generated code from the prototype to get started.

The lines between disciplines will get increasingly blurry. I understand that this may feel unnerving for any generalist makers who have already carved out a niche for themselves in this interdisciplinary space, but here’s my take on it: Experienced design engineers will be free to focus on different, more challenging problems, in tighter partnership with their design and engineering colleagues. They can radically uplevel their impact.

Designers without much programming knowledge can do a lot with AI, but they will still always find themselves hitting a wall in what they can build. Despite the hype around so-called “one-shot” vibe-coding, to be truly facile with AI-based tools you still have to “speak the language” of software engineering and guide the AI agent through a series of steps and decisions. You have to tell it what programming language and frameworks you want to use. You often have to guide it in making decisions around things like API choices, state management, or data persistence technologies. And, most critically, AI often gets things completely wrong, breaks previously working code, or hallucinates non-existing APIs, functions or 3rd-party dependencies. It can be maddening, and solving any of this typically requires code literacy and significant debugging experience.

Furthermore—as I’ve written before—left to their own devices, generative models threaten to homogenize design. The achilles heal of all generative models is that they have been trained on solved problems. This makes them well-suited for quickly scaffolding common UI patterns, creating CRUD interfaces, or generating simple backends that can allow prototypes to work with real data. They are very good at creating facsimiles of pre-existing interfaces and experiences. But this also makes them ill-suited for prototyping many of the aspects of a user experience that will allow your product to truly stand out from the crowd.

And this is where design engineers come in.

User experience has always mattered, but as software rapidly proliferates—as more people are empowered through AI to rapidly create software—user experience will be the ultimate differentiator. Empowered by the same AI tools that their design colleagues are using to scaffold the basics of an experience or try out a simple design with real data, design engineers can both collaborate more deeply with their designer colleagues and spend more time focusing on higher-impact user experience problems. And they can spend more time with production engineering colleagues polishing and elevating the experiences that ship. Whether this means inventing delightful new interaction patterns, creating rich prototypes of new product concepts, nailing a subtle transition or animation, or digging into UI responsiveness optimizations, LLM-based tools mean design engineers can spend less time on scaffolding and plumbing and be more ambitious and in what they explore and build. That, to me, is exciting.

In Future Proofing Your Software Engineering Career, Addy Osmani writes:

The best engineers have always been more than just coders. They’ve been problem solvers who understand both technical constraints and human needs. As AI tools reduce the friction of implementation, this holistic understanding becomes even more valuable.

I know of no group of more product-minded, and human-attuned engineers than those people who call themselves “UX engineers” or “design engineers.” I’d be excited to have more of them. If AI tools make it a little easier for more designers to get comfortable with code, to build things with code, and maybe, just maybe, to actually learn the medium of code, that’s a win.