Figma has unveiled a new integration with OpenAI’s Codex, enabling users to move between design files and code implementation through Figma’s MCP server. Engineers can iterate visually inside Figma. Designers can engage more closely with implementation without becoming full-time coders. On paper, it sounds like the handoff problem is solved.
It isn’t. But the announcement tells you a lot about where the industry is heading — and where the real gap still lives.
A tool for both designers and developers
One of the standout aspects of this integration is its ability to cater to both designers and engineers without requiring either to step fully into the other’s domain. Alexander Embiricos, Codex product lead, explained, “The integration makes Codex powerful for a much broader range of builders and businesses because it doesn’t assume you’re ‘a designer’ or ‘an engineer’ first. Engineers can iterate visually without leaving their flow, and designers can work closer to real implementation without becoming full-time coders.”
This dual-purpose functionality is expected to enhance collaboration by allowing engineers to contribute visually and designers to engage more closely with implementation.
Good timing — this news is perfect fodder for Pillar 3 messaging. Here’s the rewritten post:
What the Figma-Codex integration actually does
The integration works through Figma’s MCP server, connecting Figma’s canvas — design files, Figma Make, or FigJam — to Codex for code implementation. The goal, as Codex product lead Alexander Embiricos put it, is to serve builders who don’t want to be forced to identify as “a designer” or “an engineer” first.
Figma’s chief design officer Loredan Crisan framed it as a way for teams to “build on their best ideas — not just their first idea — by combining the best of code with the creativity, collaboration, and craft that comes with Figma’s infinite canvas.”
It builds on an already deep relationship between the two companies. Figma was among the first to launch an app in ChatGPT back in October 2025, and its earlier collaboration with Anthropic to incorporate Claude Code signalled a broader strategy of weaving AI tools into the design workflow.
This Codex integration continues that direction. It’s real, it’s useful, and for teams without existing design systems, it meaningfully closes the distance between design and development.
What Figma + Codes doesn’t solve
Here’s the thing about Figma’s MCP server: it exposes visual layer data. Frames, layers, colours, positions. It tells Codex what things look like.
It doesn’t tell Codex what things are.
When Codex receives that visual data and generates code, it’s interpreting pixels — making educated guesses about what component to use, what props to set, what your team actually calls things in your codebase. For greenfield projects, that’s fine. For enterprise teams with existing design systems — with their own Button components, their own Card variants, their own design tokens — the gap between “what Figma shows” and “what our codebase expects” doesn’t disappear. It just moves.
The handoff problem doesn’t live in the design tool anymore. It lives in the translation step between visual output and production code. Figma + Codex makes that translation faster. It doesn’t eliminate it.
How UXPin Forge AI approaches the same problem differently
Forge AI doesn’t start from visuals and work toward code. It starts from code and works toward design.
When you prompt Forge AI to generate a dashboard, it doesn’t draw rectangles that look like your Button component. It places your actual Button component — from your production React library, with your prop structure, your variants, your states. The canvas renders real components, not approximations of them.
This matters because of what it changes downstream.
What Figma’s MCP server exposes to Codex: visual layer data — frames, colours, positions that Codex must interpret and convert to code.
What UXPin’s component API exposes: actual component data — prop names, accepted values, variant options, state definitions — that developers can use directly.
The difference isn’t speed. Both are fast. The difference is fidelity. One gives AI a picture of your UI and asks it to reverse-engineer your codebase. The other gives AI your codebase and asks it to build UI from it.
| Figma + Codex | UXPin Forge AI | |
|---|---|---|
| What AI works from | Visual layers from canvas | Your actual React components |
| MCP server exposes | Pixel and layer data | Component props, variants, states |
| After generation | Codex interprets visuals → code | JSX references your existing library |
| Design system awareness | Advisory — Codex infers | Enforced — Forge generates within it |
| Post-generation editing | Back to design canvas or code editor | Professional design tools on the same canvas |
| Output fidelity | Codex approximation | Your component names, your prop structure |
The Design to Code workflow no other tool provides
Forge AI isn’t just a generation tool. After it generates, you have a complete professional design environment on the same canvas — pixel-level layout control, component property adjustment, responsive breakpoints, variant exploration, real-time collaboration. The refinement happens on the same code-backed components Forge placed.
And when you’re done, the export is JSX that references your actual component library. Your engineers receive code they can integrate immediately. Nothing to translate. Nothing to rebuild.
- Prompt — describe the UI you need
- Forge generates — real components from your library, correct props and variants
- Refine visually — professional design tools on the same canvas
- Iterate with AI — conversational modifications, not regeneration from scratch
- Export — production-ready JSX using your actual component library
- Ship — engineers integrate directly
The bottom line
Figma’s Codex integration is a meaningful step. For teams starting from scratch, it genuinely accelerates the path from idea to implementation. The partnership between two of the most widely-used tools in design and development will matter.
But for enterprise teams with existing design systems — where brand consistency, governance, and codebase alignment aren’t optional — the gap between visual output and production code remains. Making that translation faster isn’t the same as eliminating it.
Forge AI was built to eliminate it.
Want to see the difference? Try Forge AI with your own component library – MUI, shadcn/ui, Ant Design, or your custom system via Git. Generate a real UI in under five minutes and export the JSX.
Start your free trial today, or learn Learn more about Forge AI works with your design system
FAQs
Q: What does Figma’s OpenAI Codex integration actually do? Figma’s Codex integration connects Figma’s canvas to OpenAI Codex via Figma’s MCP server. Designers and engineers can move between Figma design files and code implementation without switching tools. Codex receives visual layer data from Figma and generates code based on that output — removing the need to manually translate designs into a development environment.
Q: Does Figma’s Codex integration work with existing design systems? Figma’s Codex integration works with any Figma file, but Codex generates code by interpreting visual layers rather than reading your actual component library. For teams with existing design systems, Codex must infer which components to use and how to structure the output. That inference is the remaining gap — faster than before, but not eliminated.
Q: What is the difference between Figma’s MCP server and UXPin’s component API? Figma’s MCP server exposes visual layer data — frames, positions, and colours — that AI must interpret to generate code. UXPin’s component API exposes actual component data: prop names, accepted values, variant options, and state definitions from your production React library. One gives AI a picture of your UI. The other gives AI your codebase.
Q: What is Forge AI and how is it different from Figma + Codex? Forge AI is UXPin’s AI design assistant. Rather than starting from visuals and generating toward code, Forge starts from your production component library and works outward. It generates UI using your actual React components — with their real props, variants, and states — on a professional design canvas. The output is JSX that maps directly to your codebase. Developers receive code they can integrate immediately, with nothing to interpret or rebuild.
Q: Which design systems and component libraries does Forge AI support? Forge AI supports any React-based component library. Built-in support is available for MUI, shadcn/ui, Ant Design, Bootstrap, Tailwind UI, Microsoft Fluent, and IBM Carbon. Custom proprietary systems connect via Git repository, npm package, or Storybook sync.
Q: Does Forge AI replace professional design tools? No — Forge AI handles the 0–80% generation problem. After generation, UXPin provides a complete professional design environment on the same canvas: pixel-level layout control, component property adjustment, variant exploration, responsive breakpoints, and real-time collaboration. The refinement happens on the same code-backed components Forge placed, not on vectors that need to be rebuilt separately.
Q: What does “production-ready JSX” mean in practice? When Forge AI exports JSX, it references the actual component names and prop structures from your library. If your library has a <Card> component that accepts a padding prop, the export reads <Card padding="lg"> — not a generic approximation. Your engineers receive code that maps directly to their codebase with no translation step required.
