Figma Brings AI Agents and Code Layers Into

Figma is bringing AI agents closer to the files design teams actually share, while opening a beta for code layers. The pitch reaches beyond generating a quick mock-up: an agent working inside a team’s design environment could participate in the same workflow as the humans who have to review, build and maintain the result. That sounds useful. It also raises a very practical question: when the file changes, who knows what changed and who owns the next step?

The agent-focused features and code layers open beta put two familiar sources of friction next to each other. Designers spend time making revisions across connected screens and components. Engineers then spend time interpreting what those screens mean in a working product. AI might reduce some of that back-and-forth, but a faster first draft only helps if everyone can understand what survives the trip from canvas to code.

For teams already using Figma, the immediate decision is whether these tools improve a real handoff, rather than whether they produce an impressive demo. For a small team watching its software costs, hours spent checking agent changes or untangling generated code count alongside any time saved. No price or return-on-investment claim is needed to make that calculation: review time is part of the bill.

An Agent Needs a Job Description

A design file has structure. A button can be a reusable component rather than a rectangle someone drew once. A screen can contain text, layouts and visual choices that other people rely on. Change one shared element and the consequences may extend beyond the screen in front of you. That makes an agent operating in a file a different proposition from a tool that suggests a color or produces an image for someone to paste in.

The appeal is easy to see. Say a team has settled on a revised button label and needs to update several related designs. An agent that helps carry out a well-defined change could spare someone the scavenger hunt. But the job description has to include scope. Should it update only selected screens? Should it touch a shared component? Should it stop when two designs use different wording for a reason? Those are workflow questions that a persuasive preview cannot answer on behalf of a team.

Figma’s move toward custom AI plugins alongside code layers on the canvas gives teams another way to shape what AI does in their design work. Customization can be useful when a team has repeatable conventions. It can also create more things to maintain: someone must decide when a custom tool is appropriate, check its output and update it as the team’s process changes. A shortcut with no owner has an expiration date, even if nobody wrote one on the package.

The announcements leave the day-to-day limits of agent permissions, review and pricing to be judged in actual team use. A sensible pilot would give an agent a narrow assignment, compare the file before and after, and ask the designer and engineer who inherit the work whether the change was easy to understand. If reviewing takes longer than doing the edit, the agent has merely moved the work to another chair.

Code Layers Face the Old Handoff Problem

Code layers bring implementation closer to Figma’s canvas. That is an intriguing place to put code because the canvas is where a design’s layout and visual intent are already discussed. A developer looking at a design could, in principle, have a more direct conversation about the relationship between what appears on screen and how it gets built.

The hard part is what happens after the conversation. Production interfaces must accommodate real content, changing screen sizes, accessibility requirements and the conventions of an existing codebase. A beautiful representation of one state cannot settle all of those decisions. Nor should a team expect a design tool to know which implementation choices its developers will want to maintain six months later.

This is why the open beta is a chance to run a handoff test, not a reason to retire one. Pick a routine interface change. Have a designer specify it using the new workflow, then ask an engineer to turn it into the product’s existing code. How many decisions still require a message or meeting? Can the engineer identify what the design intended without guessing? Does the resulting code fit the product’s established components? Those answers will tell a team more than counting how quickly something appeared on the canvas.

Code layers could also prove useful even when they do not produce a ready-to-ship result. If they make a design’s behavior or implementation constraints easier to discuss, they may reduce the translation work between disciplines. That is a narrower win than automatic design-to-code, but it is one teams could actually notice in their daily work.

The Cheapest Alternative Might Already Be Open

A team deciding whether to adopt these features has a baseline: its current process. That might be a designer maintaining a tidy component library, an engineer using existing UI components and both people agreeing on a short checklist before handoff. It lacks the sparkle of an agent announcement. It also has known costs and clear owners.

For a small product team, the comparison should start with its most annoying recurring task. If the pain is repetitive file maintenance, test an agent on a contained set of changes. If the pain is developers repeatedly asking how a design should behave, test whether code layers make those decisions clearer. If the pain is inconsistent components, clean up the component library first; asking automation to work around a messy shared system gives it more opportunities to spread the mess.

Larger teams face a different calculation. They may have enough repetitive work to justify configuring custom tools, and enough collaborators that an unclear edit can travel far before anyone notices. Their pilot needs a review routine as much as it needs a prompt. A useful question for the team is simple: can the next person opening the file tell what the agent did, why it did it and which decisions still need a human?

That human need not be the person who requested the change. Designers, developers and people responsible for accessibility or content may each spot a different problem. An agent can help carry work across a file; it cannot assign responsibility by making the change quickly. Teams that already struggle with ownership should decide who approves an agent-assisted update before making those updates routine.

Speed Has to Survive Review

Figma is placing AI activity, visual design and code closer together. Each connection could remove a small piece of handoff friction. Each also creates a place where an error could look finished enough to pass along. A polished screen has always been capable of hiding an unanswered implementation question; an agent can make that screen faster to produce.

The strongest case for this direction is therefore modest and practical. Give people tools that act where the work lives, let them define useful tasks and make the output easy to examine. The strongest caution follows from the same premise: shared files are shared responsibility. If a team cannot trace a change or revise it without extra detective work, the time saving ends at the first person’s desk.

The beta offers teams a way to measure that trade-off on their own files. Try one familiar task, count the corrections, and follow it through to the person who builds it. If the handoff gets shorter without becoming murkier, Figma will have solved a problem far more valuable than making another mock-up appear quickly.