9 designers open up about AI-assisted coding

AI has lowered the bar for non-engineers to write code, and some companies are using that to push designers past prototyping and into shipping real code to customer-facing products.

I interviewed nine designers about it, from big tech like Shopify and Meta down to early startups. I expected a conversation about tools and workflows, and found a bigger topic: one around what designers believe the core of their job is, what they think AI is doing to their identity, and how it is reshaping their relationship to the teams around them.

Some see it as an invigorating return to what brought them to the discipline in the first place, from the joy of creating to finally being able to sweat the details that separate a mediocre product from a great one. Others worry it drags design toward operational execution, burning time wrangling code that would be better spent on what they do best: discovering nascent user needs and thinking through what to build and how it should work. It also forces a harder question about the engineers on the other side of the table, who are armed with the same AI tools and may need less help with half-baked code and more help deciding what is worth building at all.

Four designers spoke about how building working products, not just mockups, brings them back to what drew them to design in the first place.

“I love that pushing code allows designers to tap back into the excitement and promise of simply...making stuff. It’s the part of the job many of us fell in love with first, but it’s also the part of the job that, for many good and valid reasons, is often most constrained. I love seeing that the entire product development process is compressing, which hopefully lets designers lean into whatever their strengths are. Some might even decide that product management is their thing, but I have a hope that it lets designers spend more time making stuff with their hands.” - Roland Tiango (Headway, Faire, Shopify)

I feel this personally. I tell my teams I have never been more energized to be in product development, for precisely this reason. Designers have been stuck in proposal mode for too many years, relying on others just to see their ideas take form outside of a canvas-based design tool. Many are thrilled to have the chains come off.

Being a more senior designer has always meant finding your own work rather than being handed it. When you can build in the time it used to take to mock up, you no longer need permission or resources to go chase a potentially groundbreaking solution.

You just go build it.

“PRs being a normal function of design work allow designers to ‘complain by making things’, as James Murphy would say. The further design work gets from being hypothetical, the better. I see designers becoming more and more responsible for finding the work rather than being told what to do. Access to data tooling allows everyone to validate their ideas. Access to real code allows everyone to build real things. Design tools are now another way to express an idea, not the only way.” - Jeffrey Kalmikoff (Motive, Meta, Uber)

Designers who code is not a new thing. I studied six programming languages and used to design and build even in my early career. Coding was a hard requirement for a lot of early tech jobs. Some of the people I spoke to, like Jessica and Michael, have deep technical backgrounds and carry an owner’s mentality, hunting for broken windows in the experience and enjoying the fix without a pile of overcommunication, reviews, and bureaucracy.

“I’ve pushed code as part of my role as a product designer at all but one of my jobs, so basically for the majority of the last 15 years. The difference now is that AI is helping lower the barrier to entry, which I think is a great thing. Having access to our developer tools also shortens the loop between when I spot an issue in production and when a fix actually goes out. I’m constantly combing the parts of Shopify that I’m responsible for and fixing little details that would have otherwise sat in a backlog.” - Jessica Harllee (Shopify, Faire, Etsy)

For these designers, the smallest details that push a product from a rough, minimum viable product to a consumer-grade product are an obvious win.

“Small simple polish changes to code, like a color update, padding fix, font change. This can cut out wasted communication costs and get stuff fixed faster in a team environment that actually allows teams to push fixes without additional reviews.” - Michael Hintze (Google, Meta, Apple)

There is a second thing happening underneath all of this, and it is a silver lining to some and a source of anxiety to others: the job description itself is dissolving. After years of designers specializing into narrower and narrower lanes, the pendulum is swinging back toward doing whatever you are good at and rolling up your sleeves to get it done, now with an infinite army of agents at your disposal.

“The last 15 years, people had clearly defined industry and skill-specific roles and knew their swim lane, where and how to collaborate, and how to get promoted. That's all changed. Now we are back to the dotcom boom era. No job descriptions, no role definition. It's all about experimentation and comfort with ambiguity. What matters now is design fundamentals, curiosity, systems thinking, a discerning point of view, and the creativity to imagine what doesn't exist yet.” - Kim Lenox (Adobe, Zendesk, LinkedIn)

For another group, code is the most commoditized step in the whole workflow. Not a core part of a designer’s identity, just a means to an end. For Andrew, coding was never the hard part.

“I feel that code is the last 5% of my job. I’m much more interested in using AI to better understand the problem space, use it to get side by side with users to ensure the system is being designed to reduce adoption friction, and that products and features are prioritized to bring value to customers and the business. Way too many people associate UX design with pushing code to production. That’s the easiest part of the whole workflow.” - Andrew Milmoe (Blue Origin, GE)

The anxiety here is not that designers cannot code. It is that designers will mistake execution for the job and pour their newly freed time into velocity instead of building the right thing in the first place. Michael, who started as a CS and math grad before pivoting to design, put it plainly. Engineers do not need more help writing code. They need more help figuring out what deserves to exist.

“If I wanted to be an engineer I would have been one. I choose intentionally to focus my time on the less executional aspects of the work. What problem should we focus on? Why is it most important? Why should we solve it? Do we actually have a novel solution? Does it fit in with everything else? Engineers don’t need help pushing more code. They need help deciding what to build, why, and getting support with the org and leads to actually do it, making sure good ideas don’t die.” - Michael Hintze

The line is not between people who code and people who do not. It runs through each designer, drawn between where AI-assisted coding creates real leverage and where it is just flexing. Michael is the clearest example: bullish on shipping the small fixes, adamant about stopping before he trades his most valuable skills for playing pseudo-engineer.

Kim Lenox, leading teams through this, is honest that not every designer is cut the same, and that it would be shortsighted to hold each of them to identical expectations.

“Some people are comfortable in the abstract, writing code, seeing their results, and knowing where to tweak to get what they want. Others simply are not. Either they don’t have the coding skills or the patience to get the results they want. For some there’s lots of frustration and time wasted hunting for ways to wrangle the code into submission. And others feel empowered, but pressure to put more energy into things they don’t enjoy as much. Visual people like working with visual UX affordances.” - Kim Lenox

And then there is the part you can only understand by doing it. Building real software with an LLM is a lot of back and forth, waiting, compiling, and negotiating with an agent that is sometimes plainly inept, and the output often leaves a lot to be desired. The downtime is real, and it breaks the deep-focus flow designers are used to.

“Shipping is 100% faster, but quality has definitely been downgraded a bit, at least on first release.” - anonymous

“A core skill that is emerging is rational multitasking. In other words, taking on multiple projects at one time without burning out.” - Jeffrey Kalmikoff

“This is actually the most frustrating part to me. I’m so used to spending hours in Figma doing deep work with little to no downtime. Now the back and forth with LLMs has completely shifted this paradigm. For the most part I have to multitask to pick up that downtime.” - anonymous

The designers I spoke to were candid about how their engineering peers feel. The common thread was that knowing your limits and sizing the problem correctly is what decides whether a designer’s PR is a gift or a headache, and that the size and stage of the company matters just as much.

“It’s nice to be able to make things get built to your standard and sweat the details. At the same time, the gap is in the connective tissue. Engineers know best how systems work and where things break. So ultimately it depends on the scale of the product. Shipping UI at a small startup isn’t the same as doing so at a global megacorp.” - Oscar von Hauske Valtierra (Meta, Google)

As Michael points out, just because a designer can code does not mean they should. A real engineer will often do it faster, more responsibly, and with less room for error.

“Anything more complex than simple changes is often a waste of a designer’s time, since an engineer would be 100x more efficient at the task than we would. Vibe coding isn’t the same as creating production code you want to ship, and it can create tons of issues for the team.” - Michael Hintze

Much of the conversation among designers is how it affects them and their workflows. Hang Xu, a former designer/recruiter with a deep pulse on the design community, was the one who turned around and asked about everyone else in the room.

“I spoke with a few engineers at one of those AI-forward companies, and their private feedback was that it’s been a frustrating experience for them. While it feels like it’s empowering designers, it’s creating a lot of extraneous work for the developers supporting these initiatives. AI mandates are causing many of us to be shitty coworkers in the pursuit of tokenmaxxing and trying to prove to everyone that we’re AI-native.” - Hang Xu

That reframes the question from “is this good for me” to “is this good for the team.”

Designers spend a lot of energy complaining about adjacent functions dumping half-formed work onto them. Yet there’s the risk here of becoming the function doing exactly that, in the name of looking AI-native.

Which brings it back to quality and who guards it. One thing I have watched my whole career, and Kim echoes it precisely, is that engineers do not always have the eye or passion for aesthetics. In a world where the expectation is that everything ships 10x faster, quality is the first thing out the door without real care and guardrails.

“Some people are better at aesthetics than others, even if they are not designers. Tons of mistakes go live and need to be found and unpacked. The cultural push for speed and experimentation over quality is the culprit, not the humans behind the code.” - Kim Lenox

“It’s still important that each function has a POC responsible for quality, regardless of who is executing the work.” - Jeffrey Kalmikoff

Jessica, among the most bullish of the group about designers as coders, is also the most disciplined about the risk. Sharing a common material with your engineers is a real gift for collaboration. Getting consumed by it is the trap.

“In my experience, designers pushing code to production has been a great thing for engineers, especially for collaboration. My relationships with engineers have been stronger because I can meet them where they are, use the tools they use, and collaborate directly on the things we’re building. The big things to watch out for are knowing your limits, both in your technical abilities and in your interests. When a PR starts to get a little too large or complicated, that’s usually a smell that an actual engineer should implement the fix. I have neither the interest nor the skills to be an engineer, so I’m regularly assessing whether my time is being spent the way I want it to.” - Jessica Harllee

Nearly everyone I spoke to is building inside a company, with engineers, review processes, and someone else’s codebase to break. Every caution here, the extraneous work for developers, the guardrails, the POC responsible for quality, exists because there is a team absorbing the cost of a designer’s mistakes.

When you are building your own product with no engineers, a thin budget, and no one to hand things off to, pushing code stops being a question of whether you should and becomes the only way the thing gets made. Today’s LLMs let a designer ship consumer-grade products relatively quickly and somewhat painlessly, given patience and experience. And the designer-founder is now the greatest owner and protector of quality, because there is no one else.

Two things happen in that mindset. Building at a high bar gets far cheaper and faster, so it becomes easy to aim higher than you would have. And designers who build tend to be sharper about which quality touchpoints actually matter to the customer, and where good enough is genuinely good enough so you can get back to growing the business. I build this way myself, on MTCHMKR and a handful of other DIY products coming soon under the guise of Formative Labs.

There is a lot of hype around AI, and I am bullish, but with every caveat these conversations surfaced. AI is not a one-shot fix for productivity or quality. Used carelessly, it creates more work and wastes more time, for designers and engineers both. And leaning on it to solve the hard parts can mean delegating away the most important parts of the job.

Used well, it is the opposite. It lets designers cultivate a position as strategic drivers who build, not just people who make slideware and pray for impact. It lets them contribute directly to the actual material of the product and smooth the edges that move something from good to great. And it gives back time and attention for the thing that got most of us into this in the first place.

The tool is neutral. The discipline is knowing which moment calls for which approach, and when the leverage is in the code and when it is in the thinking and creativity.