Introduction
My Cursor sidebar has 12 AI extensions installed. Last week, I added a conversation view to a ticketing system I'm building. The design was ready in Figma, so I used a Figma-to-React generator to speed things up. The component was ready in minutes.
Integrating it into my project took 30+ minutes.
The generated code ignored my existing components, import paths, and styling setup. I ended up replacing half of it just to make it match the patterns already in my codebase.
This is the real problem with most Figma-to-code workflows. They generate code that runs, not code that fits into your codebase. And that gap between “it works” and “it works in my project” quietly consumes hours every week.
Why does this gap cost me hours every week? What's actually breaking in the workflow between Figma and my IDE?
Why Most Figma-to-Code Workflows Break at the IDE
A Fastly survey showed that 95% of developers spend extra time fixing AI-generated code**, and nearly a third say the fixes erase most of the time saved.
The core issue isn’t code quality, it’s context.
Browser-based tools generate components purely from the design file. IDE extensions can at least see your project, but “seeing” isn’t the same as integrating. Many detect what library you’re using, but still output code that doesn’t match your patterns, props don’t line up, structures differ, and naming doesn’t follow your conventions.
It ends the way it usually does for most developers:
generate in minutes, spend the next half hour fixing imports, replacing components, and aligning styles.
GitClear’s study of 211 million changed lines found an 8× increase in duplicated code blocks with AI assistants, a clear sign of poor integration.
[Image Source: https://www.gitclear.com/ai_assistant_code_quality_2025_research]
The problem isn’t that tools can’t read your project. It’s that they don’t understand how your components work together, the patterns your team follows, or the conventions your codebase enforces. Without that, the integration work falls back on you.
So what would a different approach look like?
I recently came across Kombai, a tool that tries to close this gap by scanning the codebase first. It learns your components and patterns, then generates code that fits your project instead of starting from scratch. Since it runs inside Cursor, it already knows the project context before writing anything.
How Kombai Works Inside Cursor
Kombai is a frontend-specific AI agent built to fit new UI code into existing projects.
Kombai doesn’t try to build a new app for you. It tries to fit into the one you already have. The difference shows up as soon as you launch it inside Cursor.
When Kombai runs, it scans your project. It reads through your workspace and sees how your code is structured, which components you use, and how you handle things like state, styles, and API calls. This isn’t a surface-level scan, Kombai actually recognizes your imports, custom hooks, folder structure, and naming conventions.
In internal benchmarks, Kombai compiled successfully in 96% of cases and passed 72% of code review checks, both higher than any of the general-purpose setups tested. Feature implementation was also better, with Kombai verifying almost half of the requested features, while others averaged about a quarter.
Working inside Cursor, this means you get components that don’t feel foreign or out of place. There isn’t a back-and-forth where you’re fixing broken props, rewriting import paths, or swapping out styles. The generated code connects to the right context automatically.
The time I usually spend adjusting code to fit my stack isn’t wasted. I can drop the new UI straight into my project and keep moving.
Still, I wanted to see for myself how this would hold up with a feature from my actual workflow.
Adding Features to a Real Project
I wanted to see what happens when you use Kombai on a project that already has structure, patterns, and established components. Not a blank template, but something that resembles production code.
So I used a small ticketing system called HelpDesk, built with React and Tailwind. It has its own message components, status badges, and a clear folder and naming pattern.
- Design: Conversation detail view designed in Figma, with message threads, avatars, timestamps, and a reply input.
- What I'm testing: Can Kombai generate this feature so it fits my established component and style patterns?
- What I measure: If the generated code uses my existing components, matches my styles, keeps import paths correct, and needs minimal manual fixes.
The Results
Most extensions I tried gave mixed results. Some only generated part of the UI, a few had styling or layout broken, and almost all needed several prompts before they got close to what I wanted. The UI rarely matched my existing components or styles, even simple things like status badges or avatars looked slightly off.
Example outputs from typical extensions:
With Kombai, the process was smoother. I dropped in the Figma link, Kombai scanned the project, planned the changes, and generated the conversation view UI, all in just over three minutes. The output matched the design and replicated every pattern from my codebase, from import paths to component styling and structure.
Kombai’s generated view:
The main difference was that the UI required just a few small adjustments to fit perfectly, no endless style fixes or swapping components. Kombai didn't always get every prop or layout exactly right, but most changes were quick and didn't disrupt the overall integration. For the first time, the back-and-forth felt more like a review than a repair.
Comparing the Figma design to the rendered output, they're identical. Same layout. Same spacing. Same colors. Same interaction patterns. Kombai didn't approximate the design, it recreated it exactly while respecting every architectural decision I'd already made.
The 30 minutes I usually spend fitting generated code turned into 4 minutes of reviewing and approving Kombai's plan.
What Changed in My Workflow
| Metric | Before | After |
|---|---|---|
| Time to integration | 15-45 minutes | ~4 minutes |
| Manual fixes | Multiple component swaps, import corrections, style adjustments | Minor tweaks (one prop rename, added onClick handler) |
| Prompts to context | 3-5 iterations | 1 (Figma link) with shorter single prompt |
| Component reuse | Created new primitives | Used existing library |
| Integration effort | High (refactoring needed) | Low (mostly approval and minor edits) |
The shift isn't in code quality, it's in whether the code fits. I went from spending most of my time fixing output to reviewing a plan and making small adjustments.
When This Workflow Makes Sense
This approach works when your project already has established components, conventions, folder structure, and naming patterns you want to preserve. If you’re starting fresh, any Figma-to-code tool can help you in that, but fitting new UI into an existing codebase is where things usually get difficult.
If you’re tired of fixing imports, adjusting styles, or re-explaining your project in every prompt, this workflow cuts down a lot of that repetitive cleanup. While Kombai isn’t perfect and you’ll still make a few manual fixes, but, it’s noticeably better than the usual workflow. As it helps to maintain the codebase's health in the long run and reduces technical debt.
Getting Started
- You can learn more about Kombai or try it yourself at kombai.com.
- The Figma files shown above are available here.
- The open task benchmarking dataset is at kombai.com/benchmarks for those interested in reviewing the real-world tests.
If you want production-ready code that matches your existing architecture, with less time spent fixing, and more time shipping, this is a workflow worth trying.
Top comments (1)
Didn't know about this, sounds great! To add on, builder.io is also another great alternative worth knowing.