Figma is making a bid for the place where a team decides which generated work is worth keeping. Its October 15 launch brings written specifications, running prototypes, design-system context and content management closer together. The strategic proposition is broader than producing another screen from a prompt: keep the decisions, experiments and subsequent edits inside a shared workspace. That could make Figma more useful even when another company's agent writes the code. It is a bid for the collaboration around software, not evidence that the difficult parts of shipping software have disappeared.
The package announced by chief executive Dylan Field spans different stages of availability, from open beta to closed beta and preview. Those labels matter when evaluating a workflow that depends on several features working together. A team should not budget around an entire demonstrated chain simply because one part is accessible. TechCrunch also reported the launch. The capabilities examined here come from Figma's announcements and documentation, not our own hands-on testing. Our reading is that the company wants to connect exploratory building with deliberate delivery, while the release boundaries still require careful attention.
Specs is the clearest expression of that ambition. Figma's announcement describes a collaborative document that can hold written decisions alongside embedded frames, diagrams and code layers. Existing Markdown can be brought onto the canvas, while the agent can participate in comment threads. The useful unit is therefore not just a paragraph of instructions. It is the paragraph together with the design or interaction that explains it. For a reviewer, that arrangement could make an ambiguous requirement easier to question before it becomes an implementation task.
The announcement also describes bringing in repository context through a GitHub connector and product analysis through Hex, then carrying a specification's linked context to a coding agent through Figma's MCP server. That is a more connected handoff than pasting a detached brief. It still deserves a basic editorial discipline: distinguish an agreed decision from a suggestion, an unanswered question and an agent's proposed answer. Those are recommended working conventions, not enforcement features established by the announcement. A shared document can expose disagreement without resolving it on the team's behalf.
Figma's Specs guide makes a less flashy point that is important for everyday use: people can write and edit the document directly without invoking an agent or consuming AI credits. Specs can stand alone or sit inside a Design file or FigJam board, and editing requires file edit access. That preserves a straightforward way to correct the record. If a requirement is wrong, a person need not ask another probabilistic system to reinterpret the correction. Direct editing and agent assistance are different choices, rather than inseparable parts of the document.
The same guide says connected agents can read, create and update Specs, with targeted edits that retain comments on the relevant text. It also describes sending context back to tools such as Linear or GitHub. For a team adopting this workflow, the practical question becomes which artifact is authoritative after that transfer. A reasonable convention would name an owner for the specification and record when a downstream task reflects it. Otherwise, multiple editable copies can remain multiple editable copies, even if moving between them becomes easier. That is an adoption risk to test, not a reported product defect.
Code layers supplies the interactive counterpart. Figma's launch article describes importing supported, lightweight prototyping codebases from GitHub or a local folder, bringing in existing designs, and comparing running alternatives on the canvas. The lightweight qualification is worth preserving. This is not a statement that an arbitrary production repository can be imported unchanged. The strongest proposed use is a bounded product question: compare two flows with the same reviewers, rather than sending everyone separate prototype links and hoping they evaluate the same conditions.
Review can move back toward visual design, too. Figma describes extracting screens or flows into editable design layers, revising them, and applying changes to the prototype. Updated code can be pushed to a branch and reviewed through a pull request before merging. That creates a useful place for engineering judgment to remain explicit. Approval of a prototype's interaction is not automatically approval of every implementation detail. Teams can use the shared canvas to settle what an experience should do, then use code review to decide whether the proposed change is fit for the shared project.
The code-layer help page adds constraints that a demonstration can easily obscure. Imports may take ten minutes or more, and some projects need changes to run. Its MCP import section says creating code layers requires a Full seat; file editing also requires appropriate access. These details make a small, representative trial more informative than a sweeping migration promise. Test the actual project shape and the actual participants, including whoever must review the result. Access for one designer does not establish that every collaborator can perform every step.
There is also a temporary pricing distinction. On paid plans, generating and editing within code layers is free through November 4, 2026. Other agent work within the same request can still consume credits. After that date, code-layer tasks use credits as well. The help page says administrators can disable code layers by turning off AI features, but that also disables other Figma AI features. Teams therefore need to evaluate the broader effect of that control, and should not interpret the launch promotion as a permanently free or separately isolated capability.
Design-system guidance addresses another source of inconsistency. Figma's Config documentation says guidelines attached to a published library are automatically supplied when the agent uses that library. They can describe patterns and practices that visual assets alone do not communicate. This is useful context, not a demonstrated guarantee of compliance. Review should still ask whether an output used the intended component and handled the relevant states. The purpose of writing a rule is to make the desired behavior clearer and testable, not to make checking the result unnecessary.
The availability distinctions are particularly sharp here. Guidelines are in open beta, while adding repository or npm code sources to libraries is in closed beta. The centralized design-system workspace, dependency map and diagnostic reporting remain a preview. Importing a GitHub prototype into a code layer should not be confused with the separate library code-source feature. A team could reasonably adopt the available guidance while deferring a plan that depends on centralized diagnostics. That is a more precise purchasing and rollout decision than treating the entire design-system presentation as one shipped product.
Payload changes what happens after a prototype needs maintained content. Figma's announcement describes a built-in backend with storage, authentication and an administrative interface, allowing different teammates to work on the experience and its records. Routine content changes can happen through the admin panel instead of repeated prompts or source-code edits. That separation is consequential: a change to an article's wording or an event's details should not require regenerating the surrounding application. It gives teams a more conventional editing path inside a workflow marketed around generative creation.
The announcement describes permissions and versioning as part of that content workflow, but the commercial arrangement is still developing. Payload access is rolling out over the coming weeks, and the hosting infrastructure for Payload-backed Make projects is currently in beta and free. Figma says pricing and packaging will be announced before they take effect. A working budget should therefore distinguish today's trial cost from the eventual operating cost. The announcement supports trying the integrated workflow; it does not establish a long-term hosting price or an independently audited production-service record.
The backend documentation narrows the portability story further. Payload-backed Make apps are currently hosted in the eastern United States. Additional regions are planned, not available everywhere today. More importantly, GitHub integration and local codebase workflows are not yet available for these apps. That is a different boundary from the repository workflow described for code layers. Payload's open-source foundation does not, by itself, establish a completed export or local-development workflow for this managed integration. Teams with a required region or repository process should verify that requirement before treating the hosted path as interchangeable.
Figma's backend guide also separates data edits from structural changes: use the CMS to change records, and the chat to request new fields, collections or features. That distinction should shape permissions and review. An editor correcting a record and someone changing what the application stores are doing different jobs. For external-service credentials, the guide directs users to designated environment-variable settings and explicitly says not to paste API keys into chat prompts. The recommended evaluation is concrete: check who can alter records, who can change the data model, and where secrets are entered.
The AI-credit documentation makes context part of the operating bill. Model choice, task complexity and the quantity and complexity of attached material affect consumption. Figma says an exact charge cannot be predicted before a request; the receipt becomes available afterward, and published examples are approximate. Undoing an action does not refund the credits. That means the useful cost measure for a trial is not the number of prompts alone. Record the credits spent reaching an accepted result, including revisions, and compare that with the work the result actually replaces.
Correction has a specific billing distinction as well: Figma says its Auto fix and Fix for me actions do not add credits within the existing prompt, whereas a new correction prompt does. That is a reason to inspect usage receipts rather than extrapolate from a clean demonstration. For a bounded trial, count reviewer time, rejected alternatives and the work still needed after approval. The launch offers several ways to keep decisions and artifacts connected. Its practical value should be established through that complete working sequence, not inferred from how quickly the first version appears.
LaunchPad positionTest a complete review and handoff with the actual project, participants and credit bill before expanding the workflow.
This report draws on the linked primary sources and reputable reporting. Company statements are treated as claims until independently demonstrated.