Figma Make Generates Functional Prototypes with AI and Shifts Technical Quality to Design's Side

The problem that Figma Make tackles isn't new: the gap between the static screen that design delivers and the product the user actually touches. For decades, that bridge was the handoff, the moment when the designer hands Figma over to engineering and hopes the result resembles what was imagined. The official Figma Make page sums up the promise in three verbs: "Prototype. Polish. Ship." Translating what that means for those working in product in Brazil: the designer now generates functional code straight from the design, with AI in between. And that's where the conversation shifts.

What Make Does, in Practice

Figma Make is an AI-assisted generation tool that produces prototypes (and, according to Figma, increasingly production-ready things) from a prompt combined with design context. The difference from a generic code generator lies exactly in that context: Make consumes the design systems, style libraries, components, and images that already exist in the file. According to the page's own documentation, this happens via Make kits (which sync npm packages, library styles, and guidelines), attached Figma frames, PDFs, and other files.

The technical point that matters: Figma states that "everything you build is code-backed and visually editable," meaning the result is real code, not an interactive mockup pretending to be an app. You can switch between editing on the canvas and working directly in the code. There's a Plan mode that structures intent before generating (clarifying what you want before you start producing), Point and edit to click an element and request a change directly in the preview, version history that tracks every edit (AI or manual), and even voice prompting. There's also a beta version announced as "coming soon" to run Make on top of the local codebase and convert designs into production-ready assets.

In other words: Make isn't just a prototyping toy. The stated intent is to shorten the path from idea to shipped feature.

Why This Shakes Up the Handoff

The sales argument Figma chose to highlight is speed. Vishal Kapoor, SVP of product at Affirm, is quoted on the page saying that instead of an idea taking six weeks to become something tangible, it now takes "just a few hours." Brian Muehlenkamp, PM at Ticketmaster, says Make "shortened the path from idea to finished feature in a way I can't imagine replacing."

These are vendor testimonials, and it's worth reading them as such. But the structural change they point to is real and deserves the attention of designers: when the prototype already comes out as code that resembles the final product, the handoff moment stops being a clean handover ("here's the layout, implement it") and becomes a gray zone. Design gets closer to actually working, and engineering receives something that already has structure, behavior, and, potentially, built-in technical debt.

This is where the axis of responsibility shifts. If the designer generates the code, the designer also generates the decisions that used to belong to engineering: component hierarchy, error states, behavior on small screens, and (the point that worries me most) accessibility.

Where Technical Quality Now Falls on Whoever Designs

Generating a pretty, clickable interface with AI is easy. Generating an interface that works for everyone is a different story, and the marketing demo never shows that part. Some concrete risks that become the problem of whoever prototypes in Make:

• Accessibility: AI-generated code tends to get the visuals right and everything else wrong. Focus order, alt text on images, contrast that passes WCAG, correct use of roles and landmarks, keyboard navigation, form field labels. None of that shows up in a prototype that "seems to work" with a mouse. If Make has become part of the definition of done, accessibility has to be part of the same check, not something left to be discovered in production.
• Markup semantics: a layout built by stacking divs until it forms the right screen is visually identical to one built with semantic HTML, and completely different for screen readers and SEO.
• States the demo doesn't show: loading, empty, error, long data that breaks the layout, network timeout. The prompt rarely covers this, and neither does the generated result.
• Consistency with the real design system: Make kits help pull in existing components, but nothing stops the AI from recreating a button from scratch instead of using the official component. Then the prototype diverges from the system, and the divergence leaks into the code.

The speed gain is real. But speed without a quality standard just pushes the work down the line, usually for engineering to clean up, which cancels out much of the promised time savings.

One Way to Fit This Into the Workflow

The path I'd propose for a product team that wants to adopt Make without falling into the trap of the prototype-that-looks-done:

1. Use Plan mode before generating. Defining intent, states, and accessibility requirements as part of the plan is cheaper than fixing them later.
2. Tie the Make kits to the real design system. If the system has components with accessibility already solved, force the generation to use them instead of inventing new ones.
3. Treat the generated code as a draft, not a deliverable. Make's code-backed nature is an advantage precisely because it lets you inspect and fix the markup. Use that.
4. Put accessibility in the handoff check. Test with a keyboard, run a screen reader, validate contrast. This isn't an optional end-of-project step, it's part of saying the prototype is done.
5. Make explicit who validates what. If the boundary between design and engineering has blurred, governance needs to be agreed upon, not assumed.

When It's Not Worth It

Make shines for exploring ideas quickly, testing a flow with users before committing an engineering sprint, or aligning teams around something tangible. In these cases, generating in hours what used to take weeks is a legitimate gain for research and validation.

For features with strict requirements around accessibility, performance, security, or deep backend integration, treating Make's output as production code is risky. The tool offers the local codebase version (still in beta) precisely to move closer to that scenario, but beta is beta. In these cases, Make remains useful as an accelerator for the exploration phase, not as a replacement for engineering work.

The takeaway: Figma Make doesn't eliminate the handoff, it moves it earlier and redistributes it. Whoever designs gains the power to generate something functional and, along with it, inherits quality decisions that weren't theirs before. Design has always been an argument backed by evidence; now the argument comes with code attached, and the responsibility for that code comes with it too.