It cannot merge itself
The pipeline pauses for a human approval and is architecturally incapable of continuing without one. Nothing lands in your codebase that a person on your side did not approve, edit or reject.
Digital development · Delivery capability
Your Figma frames arrive as pull requests, not guesswork.
MxD runs a design-to-code pipeline that writes production React against your component library and opens a reviewed pull request. We point it at your design file and your repository when we set you up.
The problem
The handoff is where the design system goes to die.
A design system is agreed, documented and published in Figma. Then a screen gets built, and someone re-implements a button that already exists, hard-codes a hex value that is already a token, and ships a spacing scale that is nearly but not quite the one in the file. Nobody did anything wrong. The system simply has no mechanism to enforce itself at the point where code gets written.
The current wave of AI codegen makes this worse, not better. Point a general-purpose model at a screenshot and it will happily invent a component library from scratch, because it has no knowledge of the one you already maintain. You get code that looks right and shares nothing with the rest of your product.
The fix is not more review discipline. It is a pipeline that reads your Figma file, matches what it finds to components that genuinely exist in your library, verifies the output by machine, and then puts it in front of a human as a pull request they can reject.
How it works
How the MxD design-to-code pipeline works
We configure it against your design file and your repository
At launch we point the pipeline at your Figma file, map your component library to it through Figma Code Connect, and set the repository and branch the pull requests should land against. This is deliberate setup work, and it is the part that makes everything after it reliable.
It plans against components that actually exist
The pipeline pulls the frame's structure and a rendered image straight from Figma, then queries a design-system service that exposes your real component catalogue, tokens and per-component accessibility specs. The build plan is written against that catalogue, so the agent reuses vetted components instead of re-implementing them.
Machine verification runs before a human sees anything
Generated files are type-checked, linted and unit-tested in an isolated sandbox, then rendered in a browser and pixel-diffed against the frame rendered straight out of Figma. A run that falls short of the similarity threshold does not quietly proceed. We say pixel-diffed rather than pixel-perfect on purpose.
A human approves, edits or rejects. Then it becomes a PR
The pipeline hard-stops and waits for a person. The reviewer approves, rejects, or writes free-text notes that are turned into a retry instruction. Only on approval does it open a pull request. It cannot merge on its own, and that is a structural property, not a setting.
What you get
What the design-to-code pipeline gives you
Design that reaches production as reviewable code, written against the system you already maintain.
You get a pull request per change, with the evidence attached: the pixel-diff score against the Figma frame, the type and lint results, the files touched and lines changed, and the review decision that let it through. Your engineers review code, rather than translating pictures.
Verified before review, not after
Type-check, lint, unit tests and a pixel diff against the Figma render all run in a sandbox first. Your reviewers spend their attention on judgement calls rather than catching the mechanical failures.
Your components, not invented ones
Figma Code Connect maps your design nodes to real React components, and a design-system service exposes your tokens and accessibility specs to the agent. The output belongs to your system instead of drifting away from it.
Full capability list
Everything the pipeline does today
We configure and run the pipeline for you, so this is what your engagement includes. Every line below is something the pipeline does today, not something planned.
What it reads
- Figma frame ingesteach run pulls the frame's structure and a rendered image of it through Figma's API
- Component catalogue lookupthe build plan is grounded by querying the component library rather than guessing at it
- Code Connect mappingFigma nodes are mapped to the real React components they are meant to become
- Token sync on library publishpublishing the design library triggers a fresh pull of the tokens
How each run is checked
- Parallel analysis passeslayout, token mapping, localisation and component matching are worked out concurrently
- Accessibility spec per componenta fixed, non-generative step fetches the accessibility rules for every matched component before any code is written
- Sandboxed type, lint and test gategenerated files are type-checked, linted and unit-tested in an isolated checkout
- Pixel diff against the framethe component is rendered, compared with the Figma image and scored against a threshold
Output and delivery
- A pull request, never a mergethe run ends by opening a pull request on the target we configure at onboarding
- Human approval is unavoidablethe run halts and waits for an approve, reject or edit decision before anything is opened
- Plain-English edit instructionsreviewer notes are turned into a structured retry rather than needing a rewritten brief
- Run evidence you can readvisual score, type errors, lint errors, lines changed per file, retries and the review decision
- Configured against your design filethe source file and the delivery target are set up at onboarding rather than left open
- Run by our team throughoutour operators start each run, watch it and take the approval decision with you
Why it is different
Built to be reviewed, and honest about what that means.
Most design-to-code demos optimise for the moment the screen appears. We optimise for the moment your senior engineer opens the diff. That is a different product: it means constraining what the agent is allowed to write, grounding it in a component catalogue and token set that already exist, and making machine verification a gate rather than a nice-to-have.
It also means being straight about the limits. This is pre-1.0 software under active engineering, and we are not going to tell you it is finished. The first codegen attempt on a new file frequently comes back with type drift, which is exactly why the sandbox exists. Anything beyond the primitives in a mapped component library gets authored rather than matched, and that code needs the same review as any other. The visual diff is a similarity score against a rendered frame, not a guarantee of identical pixels, and it can be unavailable on a given run.
What we will not do is quote you a speed or a volume figure. There is no benchmark behind such a number, so publishing one would be a decision to mislead. What we can show you is the mechanism, run against your own design file, once we have set it up.
Compare
Same Figma frame. Very different code.
The distinction is not how quickly a screen appears. It is what the resulting code is made of, and what had to be true before it reached your main branch.
| MxD design-to-code pipeline | Builder.io Visual Copilot | v0 by Vercel | |
|---|---|---|---|
| Arrives as a pull request on your existing repository | Yes, by design | Yes, Send PR with pull request or draft modes | No, pushes directly to a connected repository |
| Written against your existing component library | Yes, mapped via Figma Code Connect | Yes, syncs Figma components to your code components | No, generates fresh components |
| Type-checked, linted and unit-tested before review | Yes, in an isolated sandbox | Not published | Not published |
| Pixel-diffed against the rendered Figma frame, scored and gated | Yes, scored against a threshold | Not published | Not published |
| Accessibility spec pulled per component before codegen | Yes, a deterministic step | Not published | Not published |
| Can land code without a human approving | No, architecturally impossible | No, the pull request awaits review | Yes, a direct push bypasses review |
| Design token changes propagate from Figma | Yes, on library publish | Not published | Not published |
Swipe the table to see every column.
Competitor details taken from vendor product, pricing and documentation pages checked on 22 July 2026. "Not published" means the vendor does not state the capability publicly, not that it is absent. Pricing and features in this category change quickly, so reverify before quoting.
Common
Questions
Does this replace our front-end engineers?
No. It cannot finish a run without one. The pipeline stops and waits for a person to approve, edit or reject, so a human is a structural requirement rather than an optional safeguard. What changes is what your engineers spend their time on: reviewing a diff against a system they already know, instead of translating a frame into markup.
What if we do not have a component library yet?
Then that is the first piece of work, and it is worth doing on its own merits. The pipeline gets its leverage from matching Figma nodes to components that genuinely exist, so without a library and its Code Connect mappings there is nothing to match against and the output is just generated code. Building the library and the token pipeline is part of what we do.
How accurate is the generated code?
Accurate enough to review, which is the bar we design for. Every run is type-checked, linted, unit-tested and pixel-diffed against the Figma render before anyone looks at it, and a run below the similarity threshold does not sail through. We do not claim pixel-perfection, and the honest expectation on a first pass at a new file is that it needs a round of edits.
Is our code or our design file exposed anywhere?
Access is scoped and gated. The pipeline runs behind staff authentication, only accepts design files that have been explicitly allowed, and can only write into the paths it has been configured for. The operator interface never sends generated file contents to a browser: it shows the run state, the scores and the file paths. We will walk your team through the specifics before anything is connected.
How mature is this?
It is deployed and in use, and it is pre-1.0. It sits on a versioned component library and token pipeline with roughly a thousand automated tests across the workspace and continuous integration on every change, and it is still being actively built. We would rather set that expectation now than oversell a piece of software that is genuinely still moving.
Want this running on your product?
The pipeline is one part of how MxD builds front-ends. Our digital development team stands up the component library and token set behind it, maps your Figma file to real components, configures the pipeline against your repository, and reviews what it produces alongside your engineers.