
The Beginning: The Tension of That First Commit
I remember the moment I pushed code to the development branch for the first time. I hesitated for a few seconds before hitting the push button in Cursor after writing my commit message. "What if my code breaks someone else's work?" That was my fear. But after that commit, the way I approach building products as a designer completely changed.
The Problem We Faced
Product designers have traditionally been positioned at the front end of product development. We research, design, create prototypes, and refine our designs through coordination with teams and customers. Then we hand off our designs to developers in the form of Figma files. Developers implement Figma into code.
A lot gets lost in this process. To properly implement a designer's intent, designers need to create detailed Figma files and repeatedly communicate with developers and test the implemented code. Despite everyone's best efforts, mismatches between design and code still frequently occur.

"What if designers implemented the design and interactions themselves instead of asking developers to do this and that—wouldn't that improve the quality?"
This question sparked a new experiment.
The AI Agent Studio Project


AppZen recently launched AI Agent Studio. It's a platform product that enables enterprise finance teams to build, test, and deploy AI agents tailored to their financial operations. I'm participating in the development as the product designer for this product.
In building this product, I'm expanding beyond the traditional boundaries of product design. Instead of handing off Figma files to developers, I'm using Cursor and Claude Code to push code directly to the development branch.
As a result, this process has improved the quality of the product. My teammates and I are still experimenting to figure out the best approach, but I want to share our journey.
I believe that in the near future, the boundaries between designers, developers, and product managers will disappear, and we'll all become builders. Builders with strengths in design, builders with strengths in development, and so on. I want to express my gratitude once again to Tiffany Choy, Sonal Pansari, and Damian Bocanegra for embarking on this new experiment together.
Preparation: Setting Up the Tech Stack and Workflow
When we started the project, we were considering a new frontend tech stack. At that time, vibe coding tools like Cursor, Claude Code, and Codex were showing tremendous potential. We wanted to adopt vibe coding as much as possible. So we chose platforms that we thought were vibe coding-friendly. AI Agent Studio heavily utilizes Next.js, Tailwind, and ShadCN.
We had discussions beforehand about how I, as a designer, would push code to the code repository. I previously worked as a UX Engineer at Adobe and had experience collaborating with other developers on iOS app development, so I wasn't starting from scratch.
Nevertheless, I had fears about actually touching the code. Fears like "What if I'm actually hindering my colleagues' work?" or "What if I'm creating more work for them?" We created a feature dev branch where my code and the developers' code would come together, and later we'd create a pull request from the feature dev branch.
Since this was my first time developing in our product's codebase, I experienced some trial and error. Even though I was only writing frontend code, there were still various backend dependencies, including authentication, so I needed to set up and learn various things on my computer.
How We Actually Work
Figma's New Role
The importance of Figma didn't diminish in the process of building AI Agent Studio. I still used Figma to create various components, interactions, and user flows. With designs made in Figma, I coordinated and communicated with internal stakeholders, including the CEO and CTO, and was able to share multiple versions with customers and receive feedback.

If there's a difference from previous projects, it's that this time, Figma focused on the overall context and didn't work on the details. For example, I didn't work on granular details in Figma, like how to express component states, how interactions are specifically expressed, or what patterns appear at each breakpoint. Instead, I started working with Cursor and Claude Code.
My goal wasn't to prototype through vibe coding. Since I was creating code that would go into the actual product, I needed to follow our codebase conventions, and the quality had to be high.
(Note: I started using Claude Code after exhausting my allocated Cursor usage.)
From Figma to Code: My Workflow
I experimented with various ways to re-implement designs made in Figma using Cursor.
First, style system unification: I unified Figma variables with the codebase's globals.css
. Both Figma and the codebase avoided hard coding and enforced the use of style variables. This was a method that showed great results in terms of style implementation quality.
Second, code generation tools: I tried using MCP when implementing components and pages into code, but it wasn't very helpful. Instead, I used a paid Figma plugin called "Figma to Shadcn," which worked really well. Through this plugin, I implemented the overall structure in Cursor.
Third, detail adjustments: I adjusted detailed parts in Cursor, mainly subtle spacing differences. At this point, it was more effective to directly open files and edit them rather than instructing the AI.
Playground: A Space for Free Experimentation
I needed a way to bypass the backend dependencies I mentioned earlier. We created a playground
folder in our codebase. It was a space where I could freely experiment while still utilizing existing codebase components. I particularly used it well when designing various components.
For example, AI Agent Studio has a markdown text editor similar to Notion, with various interactions. Text editing is basic, but you can use slash commands to add elements and specify parameters for each element. You can also generate and edit text through chatting with AI. It's a design that could take quite a bit of time since various patterns exist simultaneously, but I was able to work on it with high quality in a short time.

Refactoring: Making Free Code Follow the Rules
Components finished in the playground aren't used as-is. Things finished with design and testing on this side were often created too freely. So they needed to be organized to match our codebase conventions.
We have shared Cursor rules that we use, and I used them for refactoring. The part that teammates mainly pointed out and I paid attention to was the separation of logic. I was able to successfully organize things through interaction with Cursor.
Components organized this way are moved to page-specific component folders or the overall shared component folder depending on their purpose. After the work is done, I push the code, and developers proceed with other tasks including API connections.
Results and Lessons Learned
I still think vibe coding is in its early stages at the team level.
From a personal perspective: From my standpoint as a designer, this process improves product quality, but it also increases my workload. However, I felt a greater sense of achievement from being able to be more directly involved in the product.
From an efficiency perspective: The cost of communication with engineering partners has been reduced incomparably. I think work speed will become even faster as designs, components, and patterns accumulate in the codebase.
From a team perspective: From the engineering partners' perspective, I think there are still many areas where I fall short. I think we can quickly improve this through continuous exchange of opinions and updates to cursor rules.
Next Steps: Expanding to the Entire Team
I need to organize this process I went through so that our other designers can do it too. Recently, I helped set up various things so that another designer's computer could clone our codebase. As we progress further, I'll share stories related to this as well.
Closing Thoughts
I understand that many companies and teams are experimenting with vibe coding these days. As designers, the process of adopting AI tools will unfold differently in each context. I hope we can share our experiences and trial-and-error together.
If you have questions that this article didn't address, or if you're facing difficulties while attempting something similar, please feel free to leave a comment. I'll answer to the best of my knowledge. I'd also love to hear your stories. I believe this is a process we're learning together.
Comments ()