My journey with AI started early this year, right around the time Figma's MCP server started working with Claude, so Claude could read my Figma files directly.
At work, I started playing around with building product things in AI. I had prior experience with tools like Lovable and Base44, but the execution wasn't what I expected. Things were very basic at the time. Whatever you were trying to build ended up looking the same, even after you gave it your design system, your color library, your components and such.
That all changed once I started using Claude Code. I went with Claude because it was the hot one at the time, but the same works with Codex or Cursor. My perspective on AI changed drastically. What I was able to build was truly a result of how I prompted it. That's where my journey of building with AI began.
Early on, I built experiences that stayed in Figma, just to get the right understanding of what I was building and make it accurate. I would give my Figma designs to Claude through the MCP, and it would build them. It still didn't completely land. It was maybe 70 to 80% done, but it got there.
From there, I understood it couldn't design everything I wanted without full context. So I broke things down into small parts, starting with setting up the entire design system first. (This is where my design system case study comes in.) I gave Claude proper components, buttons, the right tokens, and an understanding of how certain sections should look. I set different rules and precedents, like "this is the only way you will do it."
With that, it got a decent understanding of how the product should look and stopped assuming things on its own, because assumption is the biggest challenge to get past with any AI model. That laid my foundation, and I just began building. Now when I gave it a Figma design, I'd get a decent result that only needed a couple of extra prompts to clean up. That became my workflow.
As the days and weeks went by, I started building directly in code, and my use of Figma dropped. Figma stayed as the place where designs lived as the source of truth, but nothing new was being built there. Everything stayed in code.
Only when the AI couldn't get a certain design right would I send it back to Figma, refine it myself, and have it built again.
The moment it clicked
The moment it clicked was when I realised how much Figma was slowing the whole process down.
If you want to show a Figma design to your team or your stakeholders, you have to share a prototype. That needs an entire process before it, where you connect each button to its state or screen one by one, then add subtle animations to make it feel fluid. At the end of the day, Figma prototypes are just slideshows connected between screens. You're only animating the transition between them. The whole setup was slow, with too much correcting here and there.
Figma prototype
Screens wired together one by one, with a transition between each. A slideshow.
Built in code
One working screen. Its states, copy and use cases change in place.
With AI, you design the entire thing in code, and that gives you a proper version of how the real application will look. I was able to create multiple use cases, update copy, and design various states and state machines.
If I had to change copy in Figma, I'd have to go through each screen individually and make sure it was a component so the change applied everywhere. I never faced that in code.
If a demo was coming up and the example use case needed updating, I would just feed it an MD file with the context of the new use case. The AI would change the example, the numbers and the context while keeping the same UI. That used to be my longest process in Figma. That's when I knew static Figma wouldn't work here.
The great thing about AI is that you can bring it into any part of your workflow. You can keep it as a final checkpoint to audit everything you've designed, or bring it in from the very start for exploration and prototyping. You can even use AI for the whole thing and skip Figma entirely. That's completely fine too. Every designer has their own moment where they bring AI in, and it's up to you how you want it.
How I work now
I begin in code, and I make sure whatever project I'm working on has my design system laid out in it. That way I don't have to go back and forth asking the AI to use a particular button style, header or layout. That groundwork comes first.
For something new from scratch, I give the AI a good set of briefs, then come back to it and start designing the screens. If something takes several rounds of prompting and still doesn't give me what I want, I send it to Figma, do a quick iteration there with some drag and drop, and send it back to be updated. It's updated right in the code.
At Petavue, I work directly with our CEO, and we're always building new experiences: a new problem to solve, and how to solve it. That needs the user experience built out. The first iteration is always done in code, just to get an understanding of the UX.
Once the UX is settled, we aim to polish it, and for me, Figma is the right place to do that. I don't redesign every single screen. I give the AI an understanding of how I want certain screens and layouts to be.
Once the first iteration is reviewed and finalised, I send it to Figma and give it a nice cleanup. Code coming into Figma gives me a version that's already built with auto layout, so the tweaks are easy. Then I send it back to code, finalise it, deploy it, and share it for review.
Sage was built exactly this way. I built the entire prototype in Claude Code, using components I designed in Figma and exported as React. Product and engineering reviewed it before a polished Figma file existed.
Sage's message thread, live on this page: components I designed in Figma, built in code.
This has pretty much become the standard now. At Petavue, no one expects a Figma file or a prototype from me anymore. I build directly in React, and it shows exactly how the thing will look. I can cover a lot of edge cases very quickly in code.
The one thing that remains is a source of truth where you can find everything that's finalised. That's where Figma comes in. Once I'm done with a product experience or feature, I send the individual screens back to Figma, so everything is well documented and laid out.
Beyond product screens
I use AI for pretty much everything now. I design websites and product experiences with it. I've done some brand design exploration and made marketing assets too, though those need more hands-on work in Figma to give them a personal touch.
I've also taken the opportunity to build product documentation. I help maintain Petavue's help docs.
Whenever a new feature comes up, I test it thoroughly and work with AI to reverse engineer how it works, so we cover a lot of edge cases. Then I translate that into a simple product document and upload it to the help page.
Design work that used to take two or three days before going to the frontend team for handoff and review now gets done within a day, deployed and confirmed.
Things to learn along the way
I wouldn't call these downsides, more things you'll have to learn and get better at.
You'll need to understand Git and GitHub, and how to set up code, because you'll be using all the things developers use. You have to get into that mindset and be prepared for it. A lot of people get turned off when they take on the more technical stuff. You just have to bear through it, learn, and understand things.
It's also not all smooth. The setup takes real time up front. Before the AI builds anything that looks like my product, the design system, tokens and rules all have to be laid out, and they have to stay updated.
It also still doesn't land everything on its own. The last 20 to 30% is on me, and some designs still have to go back to Figma to get right.
If I leave any gap in the context, it fills that gap with an assumption, so I still have to review everything it builds.
And I still believe the creative side is a while away from AI taking over. Brand work and marketing assets still need my hands on them in Figma to feel personal, though I think it will get there.
That said, AI has drastically changed how people work in design. You can still choose a fully hands-on design process with no AI, but that will hold you back, because things are changing really fast. It's better to get on the ride than be left behind.
You don't necessarily need to learn to code. I've done engineering, so I can understand code, but I wouldn't say you have to learn it. A basic understanding of how things work helps.
You're better off learning how these AI building tools work and how a product actually gets built. That will help you connect better with engineers and understand how things work, and their limitations.
If you want to see what this looks like in practice, look at my Sage case study and the design system I built.