Coding agents can read your repository. Figma Specs tries to give them the decisions behind the product

A coding agent picks up a ticket: add a filter to the orders page. It reads the repository, finds the component library, writes clean code and opens a pull request. The reviewer rejects it in a minute. The filter should have been hidden for one customer segment, the empty state needed the legal team’s wording, and the design team had already decided that filters live in a side panel, not a dropdown. None of that was in the repository. It was in a meeting, a design file and a document three links away.

It is one of the most common ways coding agents fail. The code is plausible and the product is wrong, because the agent had access to the implementation and not to the intent.

What Figma launched

On October 15, at Config India, Figma introduced Specs: a Markdown-based workspace that lives on the Figma canvas next to designs, FigJam diagrams and code layers. A spec can embed frames and any canvas node alongside text. Existing Markdown files can be dropped onto the canvas to become specs. Connectors such as GitHub and Hex can pull outside context in, and Figma’s agent can document design-system component usage and reply to comments.

The part that matters for enterprise AI is the exit: specs connect to Figma’s MCP server, so external agents such as Codex can read a spec together with its linked frames, diagrams, code layers and Code Connect snippets. Code layers, which put interactive code-backed prototypes on the canvas, moved into open beta the same day.

Specs itself is rolling out in open beta to paid plans, on web, desktop and mobile.

Context is a supply chain

The idea is right. Microsoft found that coding agents keep misusing an API when its documentation is poor; the same is true of products. An agent cannot respect a decision it never sees. Putting requirements in a machine-readable format, next to the designs they describe, and exposing them through a standard protocol shortens the distance between what was decided and what gets built.

But context that agents act on behaves like any other input to production: it has a source, a version and an owner, or it should. Figma’s announcement says little about the governance side:

• Which version did the agent read? A spec can be duplicated so teammates work on separate versions before aligning. Two versions of a requirement, both readable through MCP, is a recipe for an agent implementing the wrong one.
• Who approved it? Engineers can mark frames as ready for development, but the announcement does not describe approval for a spec itself. A draft and a decision look the same to an agent.
• Who can read it? Agent access through MCP depends on permissions. Specs that embed customer research or unreleased plans need the same access thinking as the documents they came from.

Make the spec part of the change record

Teams adopting Specs, or any similar approach, can close most of those gaps with process rather than features:

1. Mark which specs are authoritative, and keep drafts out of the folders agents read.
2. Reference the spec and its version in the pull request. When a reviewer rejects an agent’s change, the first question should be whether the agent read the right decision.
3. Write acceptance criteria an agent can check, not just prose it can paraphrase. “Filters appear in the side panel” can be tested; “make filtering intuitive” cannot.
4. Give requirements an owner, the way we argued business definitions need owners once agents read them.

A readable spec is not a verified implementation

Figma’s own framing is careful, and buyers should keep the distinction: a spec makes intent available; it does not make an agent follow it. Prototypes in code layers are also not production software; complex codebases are not necessarily supported. The verification still happens where it always did, in review and tests.

What Specs changes is the quality of the question a reviewer can ask. Instead of “why did the agent do this?”, it becomes “did the agent do what the spec says?” That second question has an answer, and it moves the conversation from taste to evidence.