Figma to React: How Kombai Finally Solved My Frontend Workflow

As a frontend developer, much of my job is converting Figma designs into React code—a process that’s both meticulous and repetitive. Every pixel, color, font weight, spacing, and padding has to match the designer’s intent exactly. It can be satisfying when it comes together, but it’s also a huge time sink.

Naturally, to save time and speed up my workflow, I’ve tried out various tools that promise to automate the conversion from Figma to React. But most of them ended up creating more cleanup work than they saved. Then I tried Kombai — and the difference was immediately clear.

Unlike most generic code generators I’ve tried, Kombai is the only frontend-specific AI agent I can genuinely vouch for that actually understands frontend development and produces code I’d write myself, not code I need to rewrite.

Why Figma to React tools didn’t work for me

Let’s be honest, Figma-to-React tools have existed for years, but most can’t handle real-world frontend needs or the realities of production code. After trying most of the popular solutions available, some of the problems I consistently faced with these tools:

Hardcoded <div>s everywhere

This was the most frustrating issue I ran into. When a Figma design is given to these tools, they translate what’s visible literally. If your design shows 10 customer orders, you get code that hardcodes those 10 orders directly into the markup as <div>s.

What I’d typically get:

<div className=”orders-table”>
  <div className=”order-row”>
    <div className=”customer-name”>Gabriel Esu</div>
    <div className=”order-id”>#12345</div>
    <div className=”price”>$2,499.99</div>
    <div className=”status”>Paid</div>
  </div>
  <div className=”order-row”>
    <div className=”customer-name”>Jane Smith</div>
    <div className=”order-id”>#12346</div>
    <div className=”price”>$29.99</div>
    <div className=”status”>Pending</div>
  </div>
  {/* Every single row hardcoded like this... */}
</div>

Everything’s just baked into the component, including details that should typically come from an API, like payment info.

This is fine for static mockups, but impractical for real production apps that need dynamic data. It also makes it impossible to reuse the component with different data. I’d end up spending hours refactoring everything to separate data from presentation—might as well code it from scratch.

Bad component structure

These tools organize components by Figma layer grouping, not logical boundaries or reusability. They just follow whatever layer grouping exists in Figma and generate component structures that don’t always translate well into logical component hierarchies.

For example, a dashboard grouped in Figma as “Header,” “Main Content,” and “Sidebar” becomes one giant monolithic component mirroring those groups—impossible to reuse or maintain.

export default function Dashboard() {
  return (
    <div className=”dashboard”>
      {/* Everything dumped in one component */}
      <div className=”header-section”>
        <div className=”logo”>...</div>
        <div className=”search-bar”>
          <input type=”text” placeholder=”Search...” />
          <button>Search</button>
        </div>        

    <div className=”user-menu”>
          <img src=”avatar.png” />
          <div className=”dropdown”>
            <div>Profile</div>
            <div>Settings</div>
            <div>Logout</div>
          </div>
        </div>
      </div>

      <div className=”main-content”>
        <div className=”stats-cards”>
          <div className=”card”>...</div>
          <div className=”card”>...</div>
          <div className=”card”>...</div>
        </div>
        <div className=”orders-table”>
          {/* 50+ lines of table markup */}
        </div>
        <div className=”pagination”>...</div>
      </div>

      <div className=”sidebar”>
        {/* Navigation, filters, etc. */}
      </div>
    </div>
  );
}

It’s a nightmare: a 300-line component you can’t reuse or test in isolation. Any change means digging through hundreds of lines of code.

What’s worse is that it didn’t even extract the most obvious reusable pieces. The stats cards are clearly the same component repeated three times with different data, but instead of creating a <StatsCard /> component, the tool just copied and pasted the markup three times.

The result: code that ignores React’s modularity is hard to maintain and impossible to reuse. A proper component tree separates reusable units, not just frame layers.

Didn’t follow tech stack-specific best practices

Most Figma-to-React generators are stack-agnostic: they ignore TypeScript types, prop definitions, naming patterns, and linting rules. They don’t know your preferred libraries, folder structure, coding conventions, or how your team handles props and state—so the code always feels generic and disconnected.

// What you get from most tools
function Button(props: any) {
  return <button style={{ background: ‘#0066FF’ }}>{props.text}</button>;
}

// What you actually need
interface ButtonProps {
  variant: ‘primary’ | ‘secondary’ | ‘danger’;
  size?: ‘sm’ | ‘md’ | ‘lg’;
  disabled?: boolean;
  onClick?: () => void;
  children: React.ReactNode;
}

function Button({ 
  variant, 
  size = ‘md’, 
  disabled = false, 
  onClick, 
  children 
}: ButtonProps) {
  return (
    <button 
      className={`btn btn-${variant} btn-${size}`}
      disabled={disabled}
      onClick={onClick}
    >
      {children}
    </button>
  );
}

Proper TypeScript types and clear prop interfaces matter in real projects. Generic tools skip these entirely.

Limited styling options

Most Figma-to-React code tools supported only a handful of styling options. Typically just CSS Modules and maybe Material-UI. That’s it. Want Tailwind, Styled Components, or Emotion? You’re out of luck. Even when a styling option is “supported,” the implementation is inconsistent. No shared theme, no design tokens, no variants—components are styled differently all over.

The worst part was that my team already had established styling conventions. We used Tailwind with a custom theme configuration, specific utility patterns, and component variants. These tools ignored all of that, producing generic styles that don’t match our codebase.

I’d spend hours replacing inline styles, fixing spacing, and restructuring components—work that should have been done automatically.

No reuse of existing repo components

These tools had zero awareness of my existing codebase. When they generated code for a new design, they’d create brand-new components from scratch. Meanwhile, my existing reusable components were sitting right there in the repo, unused.

This happened with everything: we had a <Button /> component with variants, size options, and loading states; a custom <Modal /> component with our company’s specific styling and focus management. But these tools didn’t reuse any of the existing components; they generated new ones with none of these functionalities.

They weren’t aware of our design system either. We had design tokens for colors, spacing, typography, and shadows. Every component in our repo used these tokens. But the generated code would contain hard-coded values, resulting in massive inconsistencies.

Bad Code Fidelity

​​Almost every tool had code fidelity issues. The generated layout looked fine in the preview, but the underlying HTML structure made no semantic sense. You’d find nested containers wrapped around single elements for no reason, or siblings that should be grouped placed in different parent divs. The hierarchy often didn’t match the visual structure at all.

This matters because a poorly structured DOM makes everything harder. Styling becomes a pain, and layouts break at different screen sizes. The biggest culprit was absolute positioning. Most tools default to positioning elements absolutely because it’s the easiest way to match pixel-perfect coordinates from Figma. They grab the x and y values from the design file and translate them directly into CSS.

.container {
  position: relative;
  width: 1440px;
  height: 900px;
}

.sidebar {
  position: absolute;
  left: 0;
  top: 0;
  width: 250px;
  height: 100%;
}

.header {
  position: absolute;
  left: 250px;
  top: 0;
  width: 1190px;
  height: 80px;
}

.main-content {
  position: absolute;
  left: 250px;
  top: 80px;
  width: 1190px;
  height: 820px;
}

This might match the design at 1440px, but when you resize the window, everything overlaps or breaks because they’re locked to fixed positions. Modern CSS layouting techniques like flexbox and grid exist specifically to solve this problem, yet most tools ignore them completely.

Typography inconsistencies were another constant headache. A design might specify Inter with a weight of 600 and a size of 16px, but the tool would pick a completely different font family, weight, and size because it couldn’t access the exact one from Figma.

Colors were no different. The generated code would often be close enough that you might not notice immediately, but wrong on closer inspection. Images also presented their own set of problems; they often used the wrong images, placeholders, or were rendered at the wrong dimensions.

Even when fidelity was good, code quality would be so poor that you risk breaking fidelity trying to fix it.

No interactivity

Most tools treat Figma designs like screenshots, translating the visuals to static code with no interactivity. A search bar would just be a div with an icon and some placeholder text. No input field. No onChange handler. Nothing is actually functional.

// What gets generated
function SearchBar() {
  return (
    <div className=”search”>
      <img src=”search-icon.svg” alt=”search” />
      <div className=”placeholder-text”>Search by product #, name, date...</div>
    </div>
  );
}

They don’t understand that a magnifying glass icon next to text is universally recognized as a search field, and can’t infer the role of UI elements from their visual appearance. They just reproduce rectangles, not functionality.

Dropdowns are worse—the tools would see a button labeled “More Actions,” but the generated code would do nothing—no menu, no options, just a static button that looks interactive but isn’t. I’d end up rebuilding every interactive element myself, making the generated code just a wireframe that requires the same amount of work as coding it from scratch.

Friction in saving code

Most Figma-to-React tools didn’t work inside my IDE. They ran as Figma plugins or in separate browser windows, which meant a tedious workflow just to get generated code into my project

First, I’d generate the code, download a zip or copy to clipboard, navigate to the correct directory, create the file, paste, and save. Then I’d fix import issues manually, move any referenced images or icons to the right assets folder, and update all paths. A complex component could take 10-15 minutes to integrate.

The constant context switching was the worst part. I’d be in my IDE, need a component from a design, switch to the browser, generate code, download it, switch back, navigate the file tree, paste, fix imports, move assets, fix paths, and test. Every new component meant repeating the entire cycle.

General-purpose agents help, but

General-purpose AI agents like Claude and ChatGPT feel like they should solve these problems. They’re smarter, more flexible, and reason about code in ways Figma-to-code tools can’t. They do work better most of the time, but they still lack understanding of my codebase, so the outcome wasn’t as good as I expected.

Bad Code Fidelity

General-purpose AI agents avoid the worst offenses. They don’t spam absolute positioning or generate nonsensical div structures like generic Figma-to-React tools. But they still produce code that breaks on resize, with colors slightly off and fonts that don’t match.

The issue shifts from “terrible structure” to “slightly wrong decisions.” An agent would use flexbox correctly but ignore responsiveness, or hallucinate aspects of the design entirely. It’d add proper semantic HTML but miss the exact border radius or shadow. Colors are close but not pixel-perfect. The layout works for specific viewport sizes.

It’s less obviously broken, which makes it harder to catch. Everything looks good until you compare side-by-side with the design and notice the heading is 18px instead of 20px, the gap is 16px instead of 24px, and the card shadow is entirely different.

No interactivity

Same problem. Agents treated Figma files like static screenshots. They could describe what they saw, but couldn’t infer that a magnifying glass icon meant a search input should actually search, or that a down arrow meant a dropdown should expand.

When you look at a design, you intuitively understand the behavior. A hamburger icon opens a menu. A card with a hover state responds to mouse movement. But AI agents only see pixels and layers, so I still had to add all the interactivity myself or prompt separately outside the scope of the design.

Limited use of existing repo components

This is where AI agents should shine compared to Figma-to-code tools, and they do, but only barely. They have search tools and can find existing components in your codebase. But their understanding is shallow.

They’d find my <Button /> component and see that it exists with props like variant and size. But they don’t understand when to use it or that every button in the app should use this component.

// My existing Button component
<Button variant=”primary” icon={<SaveIcon />}>
  Save Changes
</Button>

// What the AI agent generates in the same file
<button className=”icon-btn”>
  <TrashIcon />
  Delete
</button>

This happens because agents don’t have the same intuition that a human developer builds over time through working in a codebase. A developer who’s worked in a codebase for a few weeks knows “we always use the Button component” or “we have a Card wrapper for everything.” They’ve internalized the patterns.

AI agents search cold each time, trying to piece together what exists without understanding the intent behind your architecture. They treat each generation as an independent task and never build that cumulative understanding of “how we do things here.”

Asset handling

This is where things get messy, especially with Figma integrations. When using something like the Figma MCP server, the agent can access images from Figma files, but the implementation is problematic. It generates code with image sources pointing to localhost URLs.

<img src=”http://localhost:3000/figma-image-xyz.png” alt=”hero” />

This works while developing locally with the MCP server running. But the moment I stop the server, push the code, or deploy to production, all images break. I’m left with broken references that need manual replacement.

Even when images load locally, they often render at the wrong dimensions. The Figma design might show a 16:9 hero image, but the agent generates a fixed width and height, squashing it to 4:3. There’s also no consideration for asset organization. In a real project, icons go in an icons folder, images in public/images, or maybe through a CDN. The agent just dumps URLs inline wherever needed.

Kombai solved the pain points

Kombai was one of the last agents I tried, but it turned out to be the best. Unlike general-purpose AI models, Kombai is purpose-built for front-end engineers, and it felt like the first tool that understood what front-end development actually is.

I first used Kombai while building an e-commerce application, then again for a job-application tracker. Despite the projects being completely different, my experience remained consistent.

Proper data structures, not hardcoded markup

The first thing I noticed was that Kombai didn’t hardcode data into JSX. When I gave it a design with an orders table, it generated proper data structures and mapped over them.

interface Order {
  id: string;
  customerName: string;
  price: number;
  status: ‘Paid’ | ‘Pending’ | ‘Cancelled’;
}

function OrdersTable({ orders }: { orders: Order[] }) {
  return (
    <div className=”orders-table”>
      {orders.map((order) => (
        <div key={order.id} className=”order-row”>
          <div className=”customer-name”>{order.customerName}</div>
          <div className=”order-id”>#{order.id}</div>
          <div className=”price”>${order.price.toFixed(2)}</div>
          <div className=”status”>{order.status}</div>
        </div>
      ))}
    </div>
  );
}

The component was immediately reusable. I could pass any array of orders, and it would render them. No refactoring needed. The TypeScript interface was already defined, the data was properly typed, and the component expected props instead of having everything baked in.

This extended to everything: product cards accepted product data, user profiles took user objects, stats dashboards mapped over metrics arrays. Every component was built from the start to handle dynamic data.

Component structure that makes sense

Kombai didn’t just mirror the Figma layer structure. It actually thought about how components should be organized in React.

For the job application portal, I gave it a waitlist Figma design to implement, instead of one massive component, Kombai broke it into logical, reusable pieces:

Each component had a single responsibility and could be imported and used anywhere. The structure matched how I’d actually architect it myself, even down to how it implemented the route and separated the route content from regular component elements.

It also did the same in my e-commerce project:

import { createRouter, createRoute, createRootRoute, Outlet } from ‘@tanstack/react-router’;
import { Box, Group } from ‘@mantine/core’;
import Sidebar from ‘./components/Sidebar/Sidebar’;
import Header from ‘./components/Header/Header’;
import OrdersPage from ‘./pages/OrdersPage’;
import OrderDetailsPage from ‘./pages/OrderDetailsPage’;
import { mockRootProps } from ‘./data/ordersMockData’;

const rootRoute = createRootRoute({
  component: () => (
    <Group gap={0} align=”flex-start” wrap=”nowrap”>
      <Sidebar teamMembers={mockRootProps.teamMembers} />
      <Box style={{ marginLeft: ‘256px’, width: ‘calc(100% - 256px)’ }}>
        <Header 
          currentTime={mockRootProps.currentTime} 
          userAvatar={mockRootProps.currentUser.avatar} 
        />
        <Outlet />
      </Box>
    </Group>
  ),
});

This is exactly how I would structure it myself. Clean, modular, and easy to understand.

Proper mock data separation

Kombai created a dedicated file, mockData.ts, that stores all the mock data for the project based on the design’s raw data. It includes details such as mock user profiles, analytics data, payment info, application lists, and stats summaries.

import type { Application, Stats, UserProfile } from “../types”;

export const mockUser: UserProfile = {
  name: “Snow”,
  avatar: “/avatar-snow.svg”,
  hasNotifications: true,
};

export const mockStats: Stats = {
  totalApplications: 72,
  totalApplicationsChange: 2.7,
  totalInterviews: 7,
  totalInterviewsChange: -2.7,
  responseRate: 28,
  responseRateChange: 2.7,
};

export const mockApplications: Application[] = [
  {
    id: “1”,
    jobTitle: “Product Designer”,
    companyName: “Moniepoint MFB”,
    companyLogo: “/company-stripe.jpg”,
    location: “Remote”,
    status: “interviewing”,
    lastUpdated: new Date(”2025-07-26T09:14:00”),
    createdAt: new Date(”2025-07-25”),
  },
  {
    id: “2”,
    jobTitle: “Senior UX Designer”,
    companyName: “Moniepoint MFB”,
    companyLogo: “/company-stripe.jpg”,
    location: “Remote”,
    status: “not_moving_forward”,
    lastUpdated: new Date(”2025-07-26T09:14:00”),
    createdAt: new Date(”2025-07-25”),
  },
//  ...more mock applications
];

This meant I could later connect the same UI to a real API by simply replacing the mock file. No UI logic needed to change. This is exactly how production-ready code should be structured.

Tech stack integrity, and follows React best practices

Kombai was able to scan my codebase and understand my tech stack, with the added flexibility to edit it or set it up myself.

It generated proper TypeScript interfaces, followed React conventions, and produced code that looked like it belonged in my project.

interface ButtonProps {
  variant: ‘primary’ | ‘secondary’ | ‘danger’;
  size?: ‘sm’ | ‘md’ | ‘lg’;
  disabled?: boolean;
  loading?: boolean;
  onClick?: () => void;
  children: React.ReactNode;
}

function Button({ 
  variant, 
  size = ‘md’, 
  disabled = false,
  loading = false,
  onClick, 
  children 
}: ButtonProps) {
  return (
    <button 
      className={`btn btn-${variant} btn-${size}`}
      disabled={disabled || loading}
      onClick={onClick}
    >
      {loading ? <Spinner /> : children}
    </button>
  );
}

Proper TypeScript types. Sensible prop defaults. Even handling for loading states. This wasn’t generic code that needed cleanup; it was production-ready.

Styling flexibility

Kombai, let me choose how I want the styles generated. I could use Tailwind, CSS Modules, Styled Components, or even vanilla CSS. More importantly, it respected my existing styling conventions.

When I selected Tailwind as my styling option, Kombai generated code using my project’s existing utility classes and design tokens:

function Card({ title, description }: CardProps) {
  return (
    <div className=”rounded-lg border bg-(--bg-dark) border-gray-200 bg-white p-6 shadow-sm”>
      <h3 className=”text-lg text-(--text-primary) font-semibold “>{title}</h3>
      <p className=”mt-2 text-sm text-gray-600”>{description}</p>
    </div>
  );
}

The colors used are our existing Tailwind theme, and even the spacing values (p-6, mt-2) matched our design system. The component looked consistent with the rest of the codebase without any manual adjustments, which is more than I can say for most of the other Figma-to-React tools I’ve tried in the past.

Actually uses existing components

This was the game-changer. Kombai understood my codebase and reused existing components instead of recreating them. When I asked it to build a new page or component, it searched my repo, found my <Button /> component, and used it consistently throughout:

function QuickSettings() {
  return (
    <div className=”settings-page”>
      <div className=”settings-header”>
        <h1>Account Settings</h1>
        <Button variant=”primary” icon={<SaveIcon />}>
          Save Changes
        </Button>
      </div>

      <div className=”settings-actions”>
        <Button variant=”secondary”>Cancel</Button>
        <Button variant=”danger” icon={<TrashIcon />}>
          Delete Account
        </Button>
      </div>
    </div>
  );
}

Every button used my existing <Button /> component. It recognized that my component handled icons through a prop, so it used that instead of creating inline button elements. It understood the variant system and picked appropriate variants for different actions.

The same happened with other components. It found my <Modal />, <Input />, and <Select /> components and used them properly. It felt like working with another developer who knew the codebase, not a tool that was seeing my project for the first time.

Interactivity built-in

Kombai didn’t treat designs as static screenshots. It inferred behavior from visual cues and added proper interactivity. That search bar I mentioned earlier? Here’s what Kombai generated for a page that had that, along with a date range picker filter:

The search bar wasn’t just a div with placeholder text. It was a fully functional search component with debouncing, loading states, and proper result handling. Kombai recognized the visual pattern of a search interface and implemented the behavior that pattern implies.

The <DateRangePicker/> worked the same way, with a fully functional date range picker, click-outside behavior, proper positioning, and keyboard navigation support. The kind of polish that usually requires multiple iterations to get right.

Code fidelity that actually matches

The generated code matched the design pixel-perfectly. But unlike other tools, it did so using proper CSS techniques.

function DashboardLayout() {
  return (
    <div className=”flex min-h-screen”>
      <Sidebar className=”w-64 border-r border-gray-200” />

      <div className=”flex flex-1 flex-col”>
        <Header className=”h-16 border-b border-gray-200” />

        <main className=”flex-1 overflow-y-auto p-6”>
          <div className=”mx-auto max-w-7xl”>
            {children}
          </div>
        </main>
      </div>
    </div>
  );
}

Flexbox for layout instead of absolute positioning. Proper responsive patterns. The layout worked across all screen sizes. Font weights, sizes, colors, spacing—everything matched the Figma design exactly as I wanted. There were a few instances I had to make a minor tweak or ask it to fix something, but fortunately, it does have the ability to track and autofix issues on its own.

Seamless workflow integration

Kombai worked directly in my IDE through its VS Code extension. No context switching, no downloading zip files, no manually fixing import paths.

I’d select a Figma frame, run the Kombai command in VS Code, and the component appeared in my project with all imports already configured. If the component used icons or images, they were automatically saved to the correct directories with the correct paths.

// All imports worked immediately
import { Button } from ‘@/components/ui/Button’;
import { Modal } from ‘@/components/ui/Modal’;
import { SearchIcon } from ‘@/components/icons’;
import { useOrders } from ‘@/hooks/useOrders’;

The component was also created in the right location, following my project’s folder structure. It respected my import aliases. It even used my existing custom hooks when appropriate. There was no friction between generating code and actually using it.

After finishing the project, I asked Kombai to review the page’s performance and suggest improvements.

It identified key performance issues and recommended changes that significantly improved speed and responsiveness. The loading time improved by 60%, the bundle size dropped by 52%, and overall interactivity and rendering performance improved by roughly 70–80%. It also suggested additional ways to continue improving the performance of my web app.

How was Kombai able to perform better?

It wasn’t by accident that Kombai worked better than Figma-to-React tools or general-purpose agents. Kombai has implemented domain-level optimizations to fit into React developers’ workflows and generate the best React code from Figma designs.

Human-tested RAG

Most AI agents rely on model-generated documentation extracts that miss common pitfalls. Kombai is powered by human-tested RAG, not the usual mix of scraped docs and guesswork most agents rely on. That means its generated code is based on real-world frontend patterns and version-specific best practices that developers have actually validated.

It supports 30+ frontend libraries with a focus on the React ecosystem, including React 18 and 19, JavaScript and TypeScript, and common React stacks. You can combine React with Next.js and Tailwind, TanStack Router with MUI, or any other combination.

What impressed me most was the flexibility. If you’re using a library Kombai doesn’t officially support, you can write custom rules for it, and the agent will follow your guidelines.

Best Figma interpretation

Kombai doesn’t just read Figma files; it understands them the way a frontend developer would. Real-world Figma files are messy. Designers leave invisible elements, use incorrect grouping, have overlapping nodes, or add unintended fills and shadows. Most tools translate everything literally, including the mistakes.

Kombai handles this gracefully. It recognizes invisible layers and excludes them, understands when grouping is just for designer organization rather than component structure, and filters out accidental styling properties. This interpretation engine is the next evolution of the Figma-to-code model that became Product Hunt’s top developer tool of 2023, built and refined based on how real teams design and ship products.

Understands codebase like a human

Kombai takes a human-like approach to understanding codebases. It identifies key parameters for writing quality code in a given repository, then extracts necessary information like code files and configurations.

In a codebase with a custom component library, Kombai understands each reusable component’s function, UI appearance, and required props, much like a developer onboarding to a new project. Its search and indexing tools are optimized for codebases, enabling it to find and reuse relevant code faster and more accurately than general-purpose agents.

Browser tool for preview, debugging, and performance improvements

Kombai includes a browser tool that lets you preview the generated code, debug issues, and identify performance problems. You can see how your components render, check network requests, and spot layout issues before even opening your IDE.

This is useful for various use cases. UI fixes, network errors, component refactoring, and performance improvements. You get a full development environment right inside Kombai.

Conclusion

For years, I tried to make Figma-to-React tools work. I wanted automation to handle the repetitive parts of frontend development so I could focus on interesting problems. But every tool created more work than it saved.

Kombai was different. It didn’t just convert designs to code; it understood what I was building and how I wanted to build it. It generated components I could actually use, worked with my existing codebase, and handled tedious parts while respecting my architecture decisions.

The result is a tool that actually speeds up my workflow. I’m not spending hours refactoring generated code or manually adding interactivity. I’m building features faster, with fewer bugs, and with code that fits seamlessly into my project. That’s what I wanted from Figma-to-code automation all along.