Figma Code Layers Beta Brings Shared Exploration to Working Prototypes

Figma says its code layers beta now reaches 100% of users, bringing working prototypes directly onto the canvas where teams already review designs. Code layers, interactive prototypes backed by running code, give designers a shared place to compare behavior alongside appearance. The change puts pressure on a familiar workflow: building an experiment elsewhere, then bringing back a link for everyone to evaluate.

The announcement is about broader availability rather than a completely new launch. Figma’s November 4 workflow post describes full rollout, while its documentation dates the initial open beta to October 15, 2026. That distinction matters because the immediate question has shifted from access to usefulness. Teams can now evaluate whether a shared canvas improves decisions enough to justify another route between design and implementation.

Framer already offers code components on its canvas, so running code inside a visual workspace is not itself new. Figma’s pitch centers on collaborative exploration: preserving alternatives, editing their appearance, and combining ideas before committing to implementation. The central tension is between making a prototype easier to discuss and making its underlying changes ready to ship.

Figma Code Layers Beta Expands the Shared Review Surface

The meaningful change is that a working experiment can become part of the same review space as the designs surrounding it.

In its code layers workflow, Figma describes importing code, generating alternatives, refining extracted designs, and combining explorations. The Figma agent, its conversational AI assistant inside design files, helps carry out those changes. The post presents a fictional marketplace called Pickup, where a designer explores delivery-address selection alongside an existing map experience.

A fictional example can illustrate a workflow without proving its results. Pickup is useful for understanding Figma’s intended sequence, but it should not be mistaken for an independently measured deployment. The announcement supplies no basis for concluding that every team will shorten development cycles or produce better interfaces.

Still, the placement of the experiment changes what reviewers can discuss. A screenshot captures appearance at a particular moment. A working prototype lets someone test an interaction, return to the surrounding designs, and compare another direction without losing the broader visual context.

Consider a review where the disagreement concerns an address selector. An attractive layout might conceal an awkward transition after someone chooses a location. Conversely, a visually plain alternative might make the task clearer. Putting behavior next to appearance gives the discussion more direct evidence.

This does not automatically make feedback more precise. Reviewers still need to identify what they tested and explain why a difference matters. A canvas full of working alternatives can become as confusing as a folder full of prototype links when nobody labels their purpose.

The opportunity is to keep the question visible alongside the experiment. One variation might test whether people understand the entry point. Another might test how much information belongs before confirmation. Those are different product questions, even if both prototypes contain similar screens.

That distinction also helps prevent generated output from becoming the decision itself. An agent can supply plausible alternatives without establishing which alternative serves users best. The team remains responsible for choosing evaluation criteria and identifying missing evidence.

For readers assessing the rollout, availability is therefore the starting point. The more consequential question is whether the shared surface makes disagreements easier to resolve. If everyone can see the alternatives but nobody can explain the selection, the workflow has moved without becoming more accountable.

Figma code layers beta makes that question practical for a wider audience. Teams can evaluate the collaboration model directly, while treating the company’s workflow demonstration as a proposal to test.

Designers and Developers Face an Earlier Alignment Decision

Shared prototypes move some implementation conversations earlier, when changing direction should still be relatively inexpensive.

Figma’s code layers documentation describes starting from designs, prompts, webpages, or connected code. It also supports extracting editable design layers and sending their changes back into a code layer. The documentation cautions that code layers do not work with every repository.

That last qualification helps define who faces pressure. Designers gain another way to make an interaction concrete, but developers must determine how closely the experiment reflects the actual product. Product managers must distinguish a convincing demonstration from an agreed implementation scope.

Earlier developer involvement is valuable when it exposes a hidden dependency. A prototype might suggest an immediate response after a user action. The production product might need to wait for a service, check permissions, or handle information that is unavailable locally.

These are illustrative engineering concerns, not documented failures of Figma’s feature. They explain why a working interface cannot answer every implementation question. The prototype establishes what someone can experience inside the experiment, while production review establishes what the organization can reliably support.

The pressure also reaches the review process itself. If a designer can bring a working alternative into a meeting, a vague request for greater clarity becomes harder to sustain. Participants can point to the interaction and explain which part creates uncertainty.

Developers, meanwhile, can use the same discussion to separate visual decisions from architectural decisions. A button label might be ready to adopt immediately. A new sequence of requests might require a broader technical change. Keeping those judgments distinct can prevent a promising interface from acquiring an unrealistic delivery commitment.

Figma agent prototyping therefore changes the timing of collaboration more than it changes responsibility. Designers still own design judgments. Engineers still assess implementation. Product leaders still decide whether the proposed experience solves a worthwhile problem.

There is also a participation question. A shared workspace delivers little value if only the person generating prototypes understands how to evaluate them. Reviewers need enough context to explore the relevant behavior without requiring a narrated tour every time.

For organizations, the useful adoption signal is a clearer decision after review. A successful session should identify the preferred direction, unresolved assumptions, and work needed before release. Producing more alternatives is helpful only when those alternatives improve that decision.

The existing workflow faces pressure because it separates experimentation from collective evaluation. Figma’s approach brings those activities closer together. Whether that proximity reduces rework remains something each team must establish through its own projects.

The Agent Connects Visual Exploration With Running Behavior

The strongest part of Figma’s proposal is the ability to move between behavior and visual detail without abandoning the surrounding discussion.

In analytical terms, this is a feedback loop. A team tries an interaction, notices a design issue, revises the relevant appearance, and evaluates the updated behavior. The point is to keep each revision connected to the question that prompted it.

The distinction matters because interface quality involves both local details and broader sequences. Spacing can affect whether an action looks available. Wording can change what someone expects after selecting it. A transition can reveal that a visually balanced screen asks for information at the wrong moment.

Moving between these concerns is often where review loses precision. A conversation starts with an observable problem, then becomes a general preference about style. Keeping the working experience near the visual exploration gives participants a way to return to the original evidence.

Figma’s customer material offers some support for that interpretation. Its customer prototype examples describe Checkout.com designer Kris Murphy extracting screens to inspect them together, then returning visual edits to the prototype. The same collection describes Superside’s Leonardo Rica supplying precise measurements and motion details when exploring an interactive card concept.

These are named customer accounts published by Figma, rather than independent comparisons. They illustrate how people are using the feature, but they do not establish typical results. Their useful common thread is specificity: the workflow becomes more meaningful when someone knows what needs inspection or correction.

For example, a team evaluating a checkout interaction might separate uncertainty about wording from uncertainty about navigation. Revising both simultaneously makes it harder to understand why the result feels better. Preserving a comparison can help keep the discussion focused on the decision being tested.

That is an analytical benefit of comparison, not a claim that Figma performs a controlled experiment automatically. The team must still keep conditions sufficiently consistent. Different sample content or missing states can make one alternative appear stronger for unrelated reasons.

The same caution applies when combining explorations. Bringing appealing features together does not guarantee that the result remains coherent. Individually sensible choices can conflict when they share navigation, terminology, or expectations about what happens next.

A combined prototype consequently needs another review of its own. It should be evaluated as a complete experience rather than accepted because its ingredients previously received approval. This is where design judgment remains central despite faster generation.

Figma agent prototyping is most useful when the agent supports a concrete investigation. A request to explore a specific interaction leaves the team with something assessable. A request for a generally better experience leaves too much of the evaluation unstated.

The practical implication is that shared canvas exploration depends on clear intent. Running code makes behavior available for inspection. It does not decide which behavior deserves to survive.

Code on the Canvas Is Already a Competitive Category

Figma’s competitive argument rests on the continuity of team review, since canvas-based code already exists elsewhere.

Framer’s code components are React components, reusable interface elements written in a JavaScript library, that render on its canvas, in previews, and on published sites. Its documentation also describes visual property controls and component sharing.

That establishes a relevant historical reference without making the products interchangeable. A component that extends a website builder and a prototype explored inside a product-design file serve overlapping but different purposes. Their value depends on what the team is trying to deliver.

A team building a published website might prioritize the relationship between visual editing and its final site. A product team exploring an application change might prioritize alternatives, surrounding screens, and the discussion that explains the selected direction.

Neither requirement is inherently more advanced. They represent different endpoints. Comparing tools only by whether they can generate code overlooks the work that follows generation and the people who need to participate.

This puts Figma’s positioning in clearer terms. Its opportunity is to make the shared design file a useful place for reviewing working ideas. The question is whether that location preserves enough context to outweigh the effort of bringing code into it.

A separate coding environment can also be an effective place to explore an interface. Engineers may prefer to experiment where project conventions and development checks already exist. Designers may prefer the broader visual overview available in their design workspace.

Those preferences should not become an artificial contest between visual tools and code tools. The operational issue is where a particular decision can be made clearly. Different stages of the same project can reasonably use different environments.

The main opponent remains fragmented exploration. That fragmentation appears when the prototype, surrounding designs, feedback, and rationale become difficult to connect. Switching applications is only one symptom. A single application can also contain disconnected work.

This is why counting removed tool switches would be an incomplete evaluation. A team might move less often while spending more time identifying the current version. Another team might retain separate tools but maintain clear links between evidence and decisions.

The code layers explained by Figma’s examples offer a spatial answer: place alternatives and discussion together. Spatial proximity is helpful when relationships are visible. It is less helpful when an expanding canvas makes those relationships ambiguous.

The competitive pressure therefore concerns review quality as much as generation. Figma needs to show that its existing collaborative environment becomes more useful when prototypes can run inside it. Rival approaches remain credible wherever they give teams a clearer path from an idea to a justified implementation decision.

A Working Prototype Still Needs Code and Access Review

A prototype that runs inside a shared file creates review obligations around both its implementation and its visibility.

Figma’s Git integration documentation describes repository cloning, branches, and pull requests, proposed changes submitted for review before merging. It also explains that file viewers can see a code layer’s preview and preview source. File editors can access underlying repository code even without corresponding GitHub permissions.

That visibility model deserves attention before importing a private project. The relevant audience is the group with access to the design file. Teams should evaluate whether that audience matches the intended audience for the code being introduced.

This is a documented access characteristic, not evidence of a security incident. Its practical significance depends on the repository and sharing arrangement. An organization working with proprietary code needs to understand that arrangement before treating import as a routine design operation.

There is a separate implementation boundary. Figma documents a route back to repository review, but the existence of that route does not establish that generated changes are correct. A proposed change still needs assessment against the project’s requirements.

For an address-selection feature, reviewers might ask how unavailable locations are handled or whether confirmation remains clear after a failed request. Those are illustrative review questions. Their purpose is to distinguish convincing behavior in an experiment from dependable behavior under real conditions.

Accessibility requires the same distinction. An interface can look convincing while remaining difficult to operate without a pointer. Keyboard behavior, focus order, and understandable feedback need direct assessment rather than inference from visual polish.

The relationship between prototype code and existing project conventions also matters. A localized change can appear reasonable while introducing a pattern that is difficult to maintain elsewhere. Reviewing the change in context remains necessary even when the prototype makes its intended behavior obvious.

The skeptical case is therefore concrete: easier demonstration can encourage premature confidence. Stakeholders might interpret a working screen as evidence that the remaining work is minor. That interpretation needs to be challenged whenever the experiment leaves important dependencies unresolved.

A useful review should identify which behavior is implemented, which behavior is simulated, and which assumptions remain untested. This keeps the prototype valuable without allowing it to become an accidental promise.

Decision records help preserve that distinction after the meeting. Teams comparing alternatives can keep their rationale in a searchable knowledge base, alongside related technical documents. The relevant information is why the direction changed and what still needs verification.

Figma code layers beta should consequently be judged by the quality of the proposed change that reaches engineering review. A more understandable prototype is useful. A prototype accompanied by explicit assumptions and a reviewable implementation is a stronger outcome.

Watch Adoption, Revision Fidelity, and Exploration Economics

The next evidence should show whether teams reach clearer decisions, preserve intended changes, and sustain the workflow after initial experimentation.

The first signal is repeated collaborative use on real projects. Over the coming months, stronger evidence would include accounts where teammates compare alternatives and carry a chosen direction into implementation review. Repeated use would support Figma’s argument that the canvas solves an ongoing coordination problem.

A collection of impressive demonstrations would provide weaker support. Demonstrations establish that a workflow can produce an attractive result. They reveal less about whether a team returns to that workflow when project constraints become inconvenient.

The distinction should guide buyers evaluating adoption stories. Ask what decision became clearer, who participated, and what happened after the prototype review. Those details are more useful than a general statement that experimentation felt faster.

The second signal is revision fidelity: whether changes preserve their intended appearance and behavior as work moves between visual editing and code. This is a proposed evaluation criterion, rather than a published Figma benchmark. It addresses the central mechanism behind the product’s promise.

Evidence of limited corrective work would strengthen that promise. Repeated reports of unrelated changes, lost details, or difficult reconciliation would weaken it. Either result needs context about project complexity and the changes being attempted.

The third signal is sustained exploration under actual credit consumption. Figma’s AI credit rules say code-layer requests consume variable credits. The company also says it cannot predict exact consumption before an AI task runs.

That makes the complete review cycle the relevant unit of evaluation. Generating an alternative, refining it, and correcting it are all part of reaching a usable decision. Judging only the first output leaves the rest of that effort invisible.

Continued use would suggest teams find the result worth the required resources. A pattern of abandoning comparisons after initial trials would raise questions about repeatability. Neither conclusion can be established from the rollout announcement alone.

These signals keep the forecast tied to observable outcomes. Figma has made working exploration available within its shared design environment. The remaining question is whether the surrounding process becomes clearer enough for teams to keep using it.

For your next review, choose an interaction that already produces disagreement and keep the evaluation question explicit. Compare the alternatives against the same user task, preserve the reasoning behind the selected direction, and identify the assumptions engineering must verify. Ask reviewers whether the working comparison changed their judgment or merely made the presentation more engaging. Then follow the proposed change through implementation review, recording any corrections needed along the way. Treat Figma code layers beta as an opportunity to examine how your team makes decisions. Keep the workflow when it helps participants understand the tradeoffs and leaves developers with a clearer, reviewable proposal.