Most AI agents can build a standalone page from scratch, but they often stumble when asked to ship features inside a real repo. They ignore your design system, recreate existing components, and break architectural patterns. The result? A "working" PR that requires hours of manual rework before it can even be considered for a merge.
Kombai approaches this differently. By learning your specific tech stack, component libraries, and coding patterns, it generates code that integrates seamlessly into your existing codebase.
In this guide, we’ll explore the different ways to leverage Figma with Kombai, alongside key features like component indexing, planning, and Kombai browser that streamline your Figma to code workflow.
Using Figma with Kombai
Kombai features a specialized Figma interpretation engine that gives the Agent a native understanding of your designs. It is significantly more advanced than existing Figma to code tools and Figma MCPs, capable of handling complex design structures with ease.
Kombai can handle common Figma issues like messy grouping and invisible layers without requiring you to clean up the file or use Auto-layout. It generates high-quality, production-ready code that handles the UI heavy lifting, giving you a solid foundation to iterate on.
Figma as the main design source
When you use Figma as your starting point, Kombai does a lot of the heavy lifting that usually takes up a significant amount of time.
It doesn’t just "read" pixels; it actually interprets the behavior implied by the design. For instance, it’s smart enough to recognize a calendar icon as a functional date-picker or a button with a chevron as a dropdown trigger, and it builds the component logic to match that. It also handles the tedious part of asset management by automatically identifying and extracting the SVGs and images you need directly from your Figma frames.
Additionally, if your design introduces new states or variations, Kombai can also extend your existing components to incorporate them instead of generating duplicate versions. All of this is done while converting with very high fidelity, meaning the generated code closely matches the original design and typically requires only minor adjustments, if at all.
Figma as an Inspiration
There are times when you want to borrow the structure of a design without inheriting its specific styling. You might need the layout logic of a dashboard, but you want the final implementation to strictly follow your repository's existing theme and colors.
Kombai can handle this by treating your Figma design as a structural reference. Instead of copying the entire values from the design, it extracts the layout hierarchy and applies your repo’s existing UI patterns on top. This ensures that even if the source design uses different aesthetics, the generated code looks native to your codebase.
Multiple Figma designs in one prompt
You can also use Kombai to generate code for multiple Figma designs in a single prompt. This is useful for building multi-step flows(e.g., signup, checkout processes) in one go, preventing the context switching of generating screens individually.
To convert multiple designs, simply paste the links to your Figma files directly into the chat input box and provide your prompt.
Indexing, Rules, and Planning
High-fidelity code is useless if it’s unmaintainable. To ensure Kombai writes code that follows your repo's coding patterns and architecture, you need to provide context. This section covers three critical steps to give Kombai context of your repo and the task in hand: identifying components, defining Rules, and generating code plan.
Start by indexing the components
When adding a feature to an existing repo, consistency is one of your biggest hurdles. The new code should naturally inherit your existing colors, borders, and layout styles. Basically, it should reuse existing components from your repo.
This is where most AI agents fail. They tend to recreate similar components from scratch instead of reusing the existing components from your codebase.
Kombai solves this by allowing you to explicitly index your existing components. By indexing your codebase components, you give Kombai a clear understanding of each component's role and behavior. This helps the Agent intelligently reuse your existing components into the new feature instead of generating redundant code.
However, component reuse is only one part of the problem. The generated code should still use your repo's specific patterns and conventions. So the next question becomes: How do you ensure the agent follows your specific repository conventions?
Set up rules so you don’t repeat yourself
When using Agents in a real codebase, you often find yourself repeating the same constraints. Rules allow you to write those constraints down once, ensuring the Agent follows them automatically for every future code generation.
Beyond simply saving time, rules are also how you control behavior. They allow you to enforce coding standards, architectural patterns, and specific output formats.
In Kombai, rules can be project-level or global-level:
- Project-level rules: Specific to a single repo. These can be stored in .kombai/rules in your root directory.
- Global (User) rules: Apply to every repo you work on. These are stored in your system’s home directory (~/.kombai/rules).
Pro Tip: If you don't want to set rules manually, you can ask Kombai to analyze your repo and generate them for you.
At this point, Kombai knows what to reuse and what conventions to follow. The next question is how the feature will actually be implemented inside your repo. That’s where planning helps.
Plan the implementation to minimize rework
Before generating code, you need to be informed upfront about how Kombai is planning to implement your feature. Plan Mode acts as a blueprint, showing you the exact strategy before a single line of code is written.
The plan provides a comprehensive preview, including:
- Structure: A lo-fi mockup of the page layout.
- Tokens: The specific design tokens pulled from your Figma.
- Reuse: A list of existing components Kombai intends to use from your codebase.
- Scope: A clear "Definition of Done" based on your prompt, along with a checklist of TODOs.
You can edit the generated plan or approve it as-is. This step creates alignment from the start, drastically reducing the likelihood of hallucinations or manual rework later.
Kombai Browser
Speed in frontend engineering comes from fast iteration loops. The Kombai Browser lets you interact quickly with your generated UI and refine the results live. Whether you are iterating on a Figma implementation or adapting a layout from a live website, this is your tool for finishing the job.
Iterate on the result using the browser
No design is perfect on the first render. Complex features usually require a few rounds of polishing to get to production-ready status.
Kombai Browser shortens this iteration loop. Instead of typing long, abstract prompts to describe a change, you can point directly at an element in the preview. By selecting the element, you provide Kombai with the exact DOM context it needs to update the code in-place.
Iterate using live websites as reference
Sometimes, the best inspiration isn't in a Figma file — it’s already live on the web. Whether you’re trying to replicate a complex navigation pattern or a specific data-grid layout, you can use existing websites as a blueprint.
To adapt a section from a live site, simply:
- Open the URL directly within the Kombai browser.
- Select the DOM element you want to emulate.
- Prompt Kombai to adapt that structure using your repo’s existing components and styling.
This approach is far more effective than using screenshots, which often leave room for interpretation. By selecting the actual DOM element, Kombai understands the underlying HTML hierarchy and CSS logic, leading to significantly more accurate results.
Conclusion
Shipping frontend features isn’t just about generating UI code. The real challenge is integration—ensuring new features fit seamlessly into an existing codebase by reusing shared components, adhering to routing conventions, and respecting established styling patterns.
The workflows covered here – component indexing, setting up rules, upfront planning, and browser-based iteration – are what make it possible to go from a Figma design to a mergeable feature inside a real repo.
If you’re evaluating agentic tools for frontend engineering, this is the true benchmark: it’s not about whether a tool can build a standalone page, but whether it can build a feature that fits cleanly in the repo you maintain every day.