Design tools have traditionally represented software without actually being software. A frame can show a button, a prototype can imitate a transition and a design system can describe component states, but the production behaviour still lives somewhere else. Figma’s 2026 introduction of code layers challenges that separation by allowing interactive code to sit on the same shared canvas as vectors, images, components and comments.
The idea is larger than adding another way to generate a prototype. Code becomes a material that teams can duplicate, compare and reshape during exploration. A working interface can be placed beside alternative directions, converted back into editable design layers and updated through direct edits or prompts. This brings behaviour into discussions that previously relied on static representations and handoff documents.
The old handoff compressed too much
Traditional design handoff asks a visual artifact to communicate many invisible decisions: responsive rules, data states, keyboard behaviour, animation, loading, errors and accessibility. Specifications and annotations help, but they are interpretations of an intended implementation. Developers discover missing cases while building, and designers often see the real consequences only after the work has moved into a different environment.
A code layer can make some of those decisions tangible earlier. Teammates can resize a working experience, try a real interaction and compare multiple behavioural options in one file. That does not remove the need for engineering judgement. It changes when the conversation happens. Questions about feasibility and system behaviour can enter exploration before a design direction hardens into a polished but incomplete specification.
Working software becomes explorable
Figma describes code layers as something teams can treat much like frames. A designer can generate a layer from an existing frame, bring in a codebase or start from a template. Variants can sit side by side instead of replacing one another in a branch or isolated chat. The canvas retains the spatial history of exploration, which is useful because design decisions are often comparative rather than linear.
The ability to extract selected states from code back into editable design layers also matters. Teams do not always need an entire application represented visually. They may need a checkout state, an error flow or a particular responsive breakpoint. Choosing what returns to the canvas can make code legible to colleagues who are evaluating experience rather than implementation detail.
AI needs context more than clever prompts
Figma’s design agent accompanies the code features with custom tools, team context and reusable skills. This reflects a practical limit of generic generation: a plausible interface is not necessarily the right interface. It may ignore a company’s components, content model, accessibility requirements or visual language. Prompt quality cannot fully compensate for missing organizational context.
A useful design agent needs access to constraints and must leave room for direct manipulation. Designers should be able to inspect the result, change it manually, compare alternatives and preserve decisions that should not be regenerated. The agent is strongest when it accelerates material exploration while the human remains responsible for purpose, hierarchy, interaction and quality.
Roles may overlap without disappearing
When designers can create working code and developers can manipulate visual states, job boundaries become less rigid. That does not mean everyone becomes interchangeable. Deep expertise in systems, performance, accessibility, research and visual communication still matters. The likely change is that more people can participate meaningfully in the space between an idea and a production implementation.
This can improve collaboration if teams treat the shared artifact as a place for negotiation rather than a shortcut around one another. Generated code still needs engineering review. Visual changes still need design reasoning. Product decisions still need evidence. Tools can reduce the cost of expressing an idea, but lowering expression cost can increase the number of ideas that require thoughtful evaluation.
The canvas becomes a meeting place
The most durable part of Figma’s announcement may be the attempt to make code collaborative in a spatial environment. Code editors are excellent for precise implementation but usually present one current state through a file structure. Design canvases make alternatives, relationships and history visible at once. Combining those strengths could help teams reason about software as both a system and an experience.
There are risks: generated implementations may look convincing while hiding weak semantics, inaccessible controls or fragile dependencies. Teams will need review standards and clear ownership. Still, the underlying direction is valuable. When code becomes another material on the canvas, design can move beyond describing software from a distance. The working experience itself becomes something a multidisciplinary team can see, question and shape together.
What to watch next
The organisational implications may be larger than the interface change. Design systems teams will need components whose visual rules, interaction behaviour and implementation details remain connected. Product designers may review responsive states and real data earlier, while engineers can spend less time reconstructing intent from static frames. That does not erase specialist roles. It raises the value of people who can define durable systems, spot accessibility failures and make trade-offs across performance, maintainability and experience. Teams should begin with bounded experiments: a mature component library, a small workflow and clear review ownership. Measure whether the new tools reduce rework and improve decisions, not merely whether a prototype appears faster. Code becomes a useful design material when it brings reality into the conversation without disguising unfinished work as production-ready software.
