What the design-to-code loop unlocks

As the boundary between code and canvas dissolves, designers and developers are finding new ways to build together. Alex Kern and Gui Seiz are shaping what that looks like at Figma—Alex as a software engineer focused on AI-powered creation, Gui as design director of AI. Here, they talk about how AI is collapsing the distance between design and engineering

, and what a more continuous way of working makes possible.

How is AI changing the relationship between design and code?

From a design perspective, workflows have changed drastically. Code used to be expensive—complex, laborious, and hard to revise. Design exploration felt cheap by comparison. You could go wide, move quickly, and converge over time. AI has inverted that dynamic.

Instead of mocking up 50 static frames, I can build something as a functional wireframe and start iterating on behavior, not just layout. Going from code to canvas helps break you out of that locked-in feeling. You can step back, reconsider the direction, and explore in a way that still feels fluid.

Historically, bringing code into the design process was tedious—keeping Figma in sync with the codebase, maintaining consistent structure across both, and aligning decisions between design and engineering. AI changes that. Models can now reliably work with code as a creative medium.

The shift is not just about generating code faster. It’s about making the translation between canvas and code more semantic and less mechanical.

What does this new relationship unlock for collaboration?

Code is well suited to single-player environments, where you keep moving in one direction. But if you want to explore a very different direction, the model will often be biased toward what already exists in the codebase. That can be limiting. The ability to think bidirectionally on the Figma canvas helps teams break out of that.

The old debate was: Should designers code? Now AI codes, so the more interesting question is: Should designers ask AI to code? And, why wouldn’t you?

AI changes who can participate. If someone doesn’t have access to the internal design system, they can still pull the live product into Figma as editable frames and start working from there. Sometimes that’s the real shift: not philosophy, just access. The barrier to entry is much lower now.

How does AI change the learning curve for designers and developers?

In the past, there was a big learning curve. AI makes it feel more like a ramp. Your baseline is way higher and you’re out of the gates more capable. If you want to go deeper, it’s no longer a huge investment. You can learn on the job and upskill over time—becoming a strong specialist in your problem space or a deep expert in your product’s specific engineering components. It’s all much more contextual now.

I did so many code bootcamps and it didn’t click. Back then it was all abstract. Now, inspiration catches you at work, and you can ask AI: “Explain this to me in the context of the thing I’m actually building.” I understand routes and React now because I have concrete work to ground it on. My ideas used to stop at the limit of my technical knowledge. Now I’m poking at shaders, working in 3D, and building my own tools. Before, I wouldn’t have even considered it.

What’s the real differentiator when everyone has access to the same tools?

Curiosity, as much as taste, is going to be the real differentiator. AI enables designers to code in a different way and acts as a very patient tutor. Getting set up used to feel intense, from new tools and frameworks to environments and syntax—all of it. Now it’s a prompt box. To stay relevant in the age of AI, you have to evolve your craft, and it’s never been easier. The curious designers will be the winners here.

It will become more important for software to distinguish itself through design—not by carbon copying what came before, but by experimenting with what it even means to deliver software. Interfaces that blend engineering and design to build things that only software can do: visualizations of data, real-time understanding of intent, generative UI, ephemeral tools, and on-demand compute from anywhere. The technology to do this exists today, but it still takes a creative individual with a point of view to define what comes next.

How does this roundtrip workflow actually hold up in practice?

Starting in the Figma canvas and going to code used to be expensive for engineers. That’s because it’s not just about getting working code in the abstract; it’s about generating ergonomic code that can endure. Code has a lifespan of years and decades, so messy code becomes a long-term problem. In the past, the design translation step has been really mechanical, tedious, and error-prone. AI has enabled a more semantic understanding of that translation.

Code to canvas, canvas to code

—a true roundtrip workflow exists. Your designer can take code to canvas, and your developer can take canvas to code, or vice versa. It allows teammates to be more self-serve, since a lot of design and copy changes in code can now be done by designers.

Figma used to be where you aligned. Code was the source of truth. The bridge between them was screenshots: someone would capture their app, bring the images into Figma, mark up changes, and say, “This is what I’m thinking.” Then someone else had to go rebuild it.

Now you can import your Storybook, blog posts, graphics, tables, and get real data into Figma really quickly. In the past it was hard to get that level of fidelity. Now there’s a lot more overlap. You can keep the two in sync and get close to 100% coverage.

What happens to timelines when models don't experience time?

For engineers, time has always been a key constraint. Now with agents, engineers are taking on projects that would have been an irrational way to spend their time before—rewriting huge open source projects in different languages and frameworks, building browsers from scratch, combing through backlogs at an unprecedented rate, taking on massive undertakings with tiny teams, sometimes even solo. These agents can move really fast, but models don’t have a sense of time. It’s funny, Claude Code will give me an estimate that something will take three months. And I’m like, “No, you’re going to do this in five minutes.”

It’s funny because it's true—nobody's estimating anymore. You just try it. So it shifts the question from, “How long will this take?” to “What do we want to build?”