Figma Make now assembles even the prototype's backend, and human curation moves elsewhere

A prototype born with a database already built in

Until recently, asking Figma Make for an app meant getting navigable screens with some interface logic. On October 13, 2026, Figma began running Gemini 4 Argon as a model option in Make, selectable from the model selector in the prompt box. Two days later, at Config India 2026, the company announced a feature package that changes what “ready” means: Make can now write the entire backend of what it generates.

The feature is called Payload in Figma. According to Figma's release notes, it gives the prototype generated from text a CMS, database, media storage, APIs, authentication, and an admin panel, all hosted by Figma itself.

Payload in Figma: Make now natively scaffolds a Payload backend, giving your app a CMS, database, media, APIs, auth, and an admin panel, turning a prototype into a production app.

Figma, release notes, October 15, 2026

For those who design product flows, this is a change in category, not degree. A prototype that only simulates clicks is usability-testing material. A prototype with a real database, real authentication, and an admin panel is, in practice, an MVP that someone could publish without going through engineering. The question this raises isn't whether Make can generate this (it can), but who decides whether what was generated is ready for real users.

Code sources and Guidelines: the attempt to teach consistency to AI

Along with Payload, Figma launched two features that directly target the design-system consistency problem. The first is Code sources, in closed beta: it lets teams import GitHub repositories or npm packages so the agent builds components and code layers reflecting the team's actual design system, instead of inventing a generic lookalike component.

The second is Guidelines, in open beta for all plans. Teams can add guidelines to published design libraries, and the agent then follows the design system's established patterns and avoids anti-patterns when generating interfaces.

The two features solve the same problem from different angles: Code sources gives the agent real code to copy; Guidelines gives the agent the rule to avoid mistakes when there's no code to copy. Neither works alone. Guidelines only avoids an anti-pattern if someone has already documented what that anti-pattern is; Code sources only reflects the design system if the imported repository is up to date. Figma also announced, as a preview only, centralized design systems that package design libraries, code libraries, and guidelines in a single place, to make maintenance easier.

In short: Make didn't learn on its own what a good interface pattern is. It now has somewhere to look up the answer, as long as the product team wrote that answer down beforehand.

Where research comes in (and where it still doesn't)

On October 30, 2026, Figma rolled out, for all plans including Starter, a Google Drive connector inside the Figma and Make agent. The stated goal in the release notes is to bring the context of existing files into the Figma file, including summarizing research insights, referencing real data, or pulling assets to edit on the canvas.

This changes where research enters the flow. Instead of the designer reading a research report and manually translating the findings into an interface decision, the agent can consume the research document directly from Drive and use it as context for the prompt. In practice, this means the quality of the generated prototype now depends on the quality of what's archived in the team's Drive, not just on the quality of the prompt typed in at the moment.

Accessibility is the piece that doesn't appear in any of the release notes reviewed here. Neither Guidelines, nor Code sources, nor Payload mention contrast, screen readers, keyboard navigation, or HTML semantics as criteria the agent checks. Guidelines talks about “design system patterns” and “anti-patterns,” but that's visual and component consistency, not WCAG compliance. A design system can be entirely consistent and still be inaccessible, if no one wrote the accessibility guideline into it.

The feature that could become the right place for this: Specs

Also announced at Config India 2026, in open beta for all plans, Figma Specs is described by the company as a “native home for context”: a place to bring together written intent, visual exploration, and technical details, for both the team and the AI agents.

This is the feature that, in Figma Make's current structure, is best suited to carry what's currently left out: an accessibility requirement, a research acceptance criterion, a technical constraint the generated prototype needs to respect. But Specs is infrastructure, not policy. It stores what the team decided to write down; it doesn't decide on its own that accessibility is mandatory.

What actually changes in the product flow

The practical effect, combining Payload, Code sources, Guidelines, and Specs, is that Figma Make has stopped being just a tool for quick interface exploration and has also become a product-scaffolding tool. This shifts where human work is concentrated:

• Before the prompt: curating what goes into Guidelines and Code sources, because that's what determines whether the agent gets the pattern right or wrong.
• During the prompt: deciding what goes into Specs as mandatory context, including accessibility requirements that Figma still doesn't automate.
• After the prompt: human review of the result, because none of the announced features include automatic WCAG checking, testing with real users, or validation that the backend scaffolded by Payload is safe for production.

For small teams, the gain is real: a prototype with Payload already has a working CMS and authentication, something that previously required a dedicated developer. The risk is publishing that prototype as if automatic generation had already solved accessibility and research, when what Figma delivered was just the technical plumbing. Curation hasn't gotten smaller with a more capable Figma Make; it just stopped happening on the screen and started happening in what the team writes beforehand, in Guidelines and Specs, and in what the team checks afterward, through manual review.