Figma announced on Oct. 15, 2026, that code layers were moving into open beta on all plans, alongside Specs, a new container for context on its canvas. The changes make a practical issue more visible for design leaders: when requirements, generated code and visual exploration share a workspace, teams still need to agree which decisions are authoritative.
This analysis separates Figma’s announced workflow changes from questions teams should evaluate. NextNow has not tested the new release, and the launch does not establish improved delivery speed or product quality.
What the launch changes
In its launch account, Figma says code layers let teams explore code-backed ideas on the canvas. It describes several inputs, including existing designs, local folders, GitHub imports and prototypes brought through its Model Context Protocol server. The Oct. 15 open-beta announcement advances the earlier closed-beta rollout, rather than introducing the underlying concept for the first time.
Figma’s Specs announcement describes a context container that lives on the canvas and accepts existing Markdown files by drag-and-drop. The company presents Specs as a way to keep useful context connected to a project and refine it collaboratively, rather than leaving it isolated on individual computers.
The launch overview also describes working from a spec toward a code layer or sending context to a coding agent. These are descriptions of supported workflows, not evidence that an agent always interprets a requirement correctly or that a working prototype is ready for production.
One canvas does not settle decision ownership
Analysis: Bringing materials together can reduce the distance between a design conversation and an implementation experiment. It does not automatically resolve a disagreement between a written requirement and a prototype. A team needs a clear answer about who can approve a change and where that decision is recorded.
Consider a checkout experiment in which the written requirement calls for an explicit confirmation before submission. A prototype might omit the step while still looking polished and behaving smoothly. The review should compare the behavior with the agreed requirement, rather than treating the newest running version as the correct one.
That distinction is particularly important when several alternatives sit side by side. A team can explore competing ideas without promoting each one into the product specification. Labels, review status and a named decision owner could help distinguish an experiment from an approved direction. Those are suggested working practices, not claims about mandatory Figma settings.
A practical trial could therefore start with one small feature and a short list of acceptance criteria. Reviewers could ask whether they can trace a visible behavior back to a requirement, identify the latest approved decision and understand why an alternative was rejected.
Context needs maintenance as well as a container
Analysis: A specification becomes less useful if it retains an old constraint after the team has changed direction. Moving Markdown onto a shared canvas is an opportunity to examine how context stays current, not a guarantee that it will. The trial should include a deliberate requirement change and a check of the materials that depend on it.
For example, reviewers could revise a feature’s intended audience, then inspect the specification, prototype and handoff. The question is whether the change is visible and consistently reflected, or whether contradictory assumptions remain in different parts of the workflow. This is a process test, not a forecast about the product’s reliability.
Teams should also distinguish instructions from background material. A customer quotation, a rejected idea and a final requirement have different authority. Giving an agent access to all three does not explain which one should govern a decision. A useful review would examine whether those roles remain understandable to both people and tools.
Measure the review, not only generation
Analysis: The business case should include the effort required to reach an approved result. A quick prototype is valuable only in context: reviewers may still need to inspect behavior, correct assumptions and explain the decision to another team. Recording that work makes the comparison more meaningful than measuring time to the first generated screen.
A bounded evaluation could compare the new workflow with an existing handoff using the same feature and acceptance criteria. It should record unresolved questions as well as successful outputs. If the experiment makes decisions easier to inspect and revise, that is useful evidence; if it only produces more alternatives, the team has learned something different.
Figma’s launch expands where design, code and context can meet. The executive question remains whether that proximity improves the quality and clarity of the team’s decisions.