You are looking at a new interface with a designer in the same Figma file. In the past, you mostly saw frames, buttons, text, components, and prototype links. They showed what the interface looked like and where a click would go.

A code layer changes that everyday scene: some interaction is now a runnable piece of UI code sitting directly on the Figma canvas. A designer can duplicate it, adjust a version, and compare interaction directions; an engineer or product manager can see, on the same canvas, what the interaction actually feels like when it runs.

That is useful because design files, interactive prototypes, animation tests, and engineering experiments used to live in different tools. But convenience creates a new question: when something on the canvas already runs and looks like a product, who decides whether it is still exploration or ready for engineering handoff?

At Config 2026, Figma announced code layers, Figma Motion, shader fills and effects, generative plugins, Weave tools, and a more context-aware Figma agent. Code layers treat runnable or editable code as design material on the canvas. Shader fills and effects are visual materials calculated by code in real time. Weave tools package AI image-processing workflows into reusable tools. The Figma agent reads canvas context and carries out several design or cleanup actions from a prompt; it is not just a chat bot that answers one sentence. Multiple technology outlets focused on the same shift: Figma is pulling design, code, animation, and AI workflows into one collaborative canvas.

This mini class is not about whether you should adopt every new Figma feature immediately. It offers a handoff rule: separate the “exploration canvas” from the “delivery specification.”

First separate freedom on the canvas from clarity in the handoff

Figma describes code layers as treating code as a new design material. The point is not that Figma exports a little CSS. It is that code can become a material on the canvas, like an image, component, or text layer: something the team can discuss, duplicate, and compare. A team can turn a design layer into an interactive code layer, duplicate directions for comparison, or pull flows from code back into editable design layers. Motion keeps timelines, keyframes, and exports inside Figma. Shaders and generative plugins let people create visual effects or custom tools from prompts.

These capabilities are strong for exploration because the team can see “what if we tried this?” earlier. Designers, product managers, and engineers do not have to wait until every detail is finalized before discussing the interaction direction.

The risk is that exploration starts to look too much like a finished product. A canvas effect can run, but that does not mean:

  • the code fits the product architecture;
  • the animation is stable across devices and browsers;
  • an AI-generated plugin or effect can be maintained by the team;
  • engineers know which parts are design intent and which are temporary experiments.

So the team needs one agreement: the Figma canvas may hold many materials, but the official handoff still needs explicit review fields.

Use one table to separate the exploration canvas and delivery specification

The next time a Figma prototype looks complete, classify it before asking whether it can be handed to engineering.

Review areaAcceptable on an exploration canvasRequired in a delivery specification
CodeA code layer can compare interaction directions and test feasibilityMark which code is prototype-only and which logic must be rewritten or owned by engineering
MotionMotion can demonstrate rhythm, transitions, 3D changes, and feelingList timing, triggers, accessibility alternatives, and performance limits
AI-generated contentAn agent can help generate effects, plugins, or variantsMark AI-generated content and assign an owner to review maintainability, licensing, and brand fit
External tool linksThe canvas may connect to Notion, Slack, GitHub, or other tools for contextConfirm data sources, permission boundaries, and documents that must not be read or imported automatically
Final responsibilityThe team can comment and test directions togetherName the owner who decides scope, change history, and rejection conditions

The point is not to slow the team down. It is to prevent “looks complete” from becoming “ready to ship.” The stronger the design canvas becomes, the more clearly the boundary between exploration and delivery must be written down.

Advertisement

A safer rollout: treat it as an isolated test zone

A practical first step is to treat these new canvas capabilities as an isolated test environment. You can try interactions, animations, and AI-generated effects there, but you should not let them replace production code or the design system by default.

Small teams can start with three rules.

First, label every code layer as “exploration,” “needs engineering rewrite,” or “reference only.” Do not hand code to engineers and make them guess which parts are usable.

Second, every Motion or shader effect needs one line for “what happens if this fails.” On low-performance devices, should it turn off? Does a screen reader need another explanation? If the animation stalls, can the page still be used?

Third, every AI-generated plugin, effect, or asset needs a human reviewer. That reviewer is not just “someone who knows Figma.” It should be someone who can judge brand, licensing, maintenance cost, and engineering handoff risk.

When not to switch too quickly

Even if the new Figma features look attractive, avoid moving the whole workflow too quickly in these situations:

  • Your team does not have a clear handoff template yet: add the specification fields before chasing the new tool.
  • Design and engineering do not agree whether prototype code can enter the product: define responsibility first.
  • The product has high accessibility, performance, or security requirements: test limits for animation, shaders, and external tool links before adoption.
  • The design system is already messy: AI will generate more variants faster, not clean up your standards automatically.

This is not conservatism. It is putting the tool where it helps most: exploration, comparison, and communication first; delivery only after the team decides what can be handed off.

The takeaway

Figma putting code, animation, shaders, plugins, and an AI agent on the same canvas is a meaningful change for design collaboration. It may make early exploration faster and help product managers, designers, and engineers look at the same direction sooner.

But handoff quality does not improve automatically. The real time-saver is not that the canvas looks more like a finished product. It is that the team can say clearly what is exploration, what is deliverable, what must be rewritten, and what needs human confirmation.

If you want to try these Figma capabilities, do not start with “should we switch tools?” A better question is: can we explore on one canvas while still keeping a delivery specification that is not ambiguous?

Everyday four-panel comic

Four-panel comic: a design and engineering team explores interaction and AI effects on a shared canvas, then separates the work into delivery specifications, rewrite items, and human-review checks.

  1. A shared canvas makes interactions, animation, and AI effects feel closer to a finished product.
  2. The team separates exploration from delivery before anyone treats the demo as production-ready.
  3. Each effect goes into a review field: code, motion, permissions, owner, and fallback behavior.
  4. Engineering receives an organized specification package, not a beautiful prototype with hidden assumptions.

AI handoff card

Ask AI to organize this article's specific situation

Copy this into your own AI chat tool to turn this mini class into a personal checklist. BMC will not see what you paste into your AI tool.

Advertisement

Share

Share this mini class

If this lesson helps untangle a work bottleneck, share it with someone deciding how to use AI.

References