Figma has released a set of features that pull design, working code, written specifications and AI agents onto the same collaborative canvas. The announcement matters beyond design teams because it addresses a familiar problem in software delivery: the decisions behind a product often become scattered across mock-ups, documents, messages, prototypes and source code.
In its 15 October announcement, Figma moved code layers into open beta, introduced Specs and expanded the context available to its agent and MCP integrations. Teams can bring in code from a GitHub repository, an npm package, a local folder or a live website. They can also keep written intent beside designs and pass that context to coding agents.
The practical consequence is a shorter route from an idea to something people can test together. It does not make the route from prototype to dependable production software automatic. Businesses will get the most value when they use the shared workspace to improve decisions and handoffs, while keeping engineering review, testing and release controls intact.
What Figma Has Changed
Code layers put interactive, code-backed prototypes on the Figma canvas. A team can explore how an interface behaves, compare alternatives and discuss the result in the place where designers already work. Figma says teams can convert an existing design, import code or capture a live website, then extract parts of the working experience back into editable design layers.
Specs gives teams a shared Markdown document that can sit beside designs, diagrams and code layers. Unlike a document stored separately, a spec can reference the material on the canvas and retain the comments and decisions that shaped it. Figma's agent can help draft or update that document, while people can review it together.
Figma has also expanded its MCP connections. The company says agents can now work with Specs and code layers, create visual assets and use published workflows. Design libraries can include written guidelines and code sources, giving an agent more than a screenshot or a short prompt when it generates a component.
This combination is more important than any single feature. It creates a place where the intended behaviour, visual rules, working prototype and implementation context can remain connected for longer.
The Business Problem It Can Reduce
Consider a company improving the customer portal used to submit service requests. The operations manager explains that customers need to add several sites to one request. A designer produces the new screens. An engineer receives a link and a short ticket, then discovers that the design does not show validation, empty states, permissions or what happens when one site fails.
The team holds another meeting. Notes are added to the ticket, a revised prototype is shared and the engineer builds an interpretation of the missing behaviour. During acceptance testing, operations spots that staff cannot see which site caused the error. The change goes back around the loop.
A shared code and design workspace can make that discussion more concrete earlier. The team can keep the operating rules in a spec, place the relevant flow beside it and use a code layer to test the interaction. Operations can comment on a working version rather than interpreting static screens. Engineering can identify technical constraints before the visual direction is treated as final.
The useful outcome is not simply a faster mock-up. It is fewer assumptions surviving until development or acceptance testing, when they are more disruptive to correct.
Treat the Prototype as Evidence, Not Production
Working code on a canvas can look convincing. That makes it particularly important to label what has and has not been proved.
A prototype may demonstrate the main interaction while omitting authentication, accessibility, audit records, browser support, performance, error recovery and integration behaviour. Imported code may depend on packages the team has not approved. An agent can produce a component that looks consistent while handling data differently from the rest of the application.
Every code layer should therefore have a clear purpose. It might be an exploration, a usability prototype or an implementation candidate. The label tells reviewers what conclusions they can safely draw. If the work is moving towards production, an engineer still needs to review the code in the repository, understand its dependencies and run the normal automated and manual checks.
The source repository should remain the authority for released software. Figma can improve the route into that repository, but a visually approved canvas should not become an alternative release process.
Make the Spec Describe Decisions
A long document is not necessarily useful context. Agents and people both work better when a spec records the decisions that change the result.
For the portal example, the spec should state who can create a request, which fields are required, how site permissions work, what happens after a partial failure and which events need an audit record. It should identify unresolved questions rather than filling them with plausible assumptions. Relevant designs and diagrams can sit beside those rules, so a reviewer can see the intended journey and the reasons behind it.
Ownership matters as the spec evolves. A product or operational owner should approve business behaviour. A designer should own the interaction and accessibility intent. An engineer should confirm the implementation approach and operational constraints. The agent can assemble, compare and update material, but it should not quietly settle a disagreement between those roles.
Comments also need closure. If an agent can reply to or act on comments, teams should distinguish suggestions from accepted decisions. A resolved thread should leave the agreed rule in the spec itself, rather than making future readers reconstruct the decision from a conversation.
Start With One Difficult Handoff
The safest first use is a live piece of work where design and development regularly lose context between them. Choose a contained feature with a real user journey and several edge cases. Keep the existing delivery process in place while testing whether the new workspace improves it.
Record the questions that would normally emerge during development. Ask operations, design and engineering to review the working flow together. Then compare the result with a recent similar change. Useful evidence includes late requirement changes, clarification cycles, defects caused by misunderstood behaviour and the time spent rebuilding prototypes in another tool.
Also test the return journey. When an engineer changes the implementation, the team needs a reliable way to bring the relevant behaviour back into the shared workspace without creating a misleading copy. When the spec changes, a visible owner should carry that change into code and tests. A connected toolset only helps when the team can tell which version reflects reality.
A Better Handoff Is the Real Opportunity
Figma's release reflects a wider change in software work. AI agents can produce designs, specifications and code quickly, so the limiting factor is increasingly the quality of the context and review around them.
Bringing those materials together can help a small team test ideas sooner and make product decisions with fewer translations between roles. It can also create a polished shortcut that hides unfinished engineering. The difference comes from clear ownership, explicit status and a release process that still checks the real application.
Start with one handoff that repeatedly causes rework. Use the shared canvas to expose decisions and edge cases earlier. If that produces fewer surprises downstream, the new capability has delivered something more valuable than another fast prototype.
