Figma software engineer Noah Finer wrote a spec, gathered his coworkers’ comments, and handed both to his coding agent. Then, he says in Figma’s launch post for Specs , “As I made progress on my code, I used MCP to update the original spec on the canvas.” Figma offers this as best practice. It is also the whole problem in one sentence: the document meant to say what to build can end up describing whatever got built.
A spec the implementer can edit
Figma Specs, which entered open beta on 15 October 2026, is pitched as a shared document that holds a team’s written intent, on the canvas or standalone. Coding agents reach it through the Figma MCP server (the connector that lets an agent use Figma’s tools). According to Figma’s help guide , an agent uses a “figma-spec” skill to read, create and update Specs, with edits that are targeted and comments that stay attached to their text. It needs only edit access to the file.
The launch post gives a second case. Engineer Kat Busch’s agent reads her spec as Markdown, and if “the name of a feature changes, she can prompt the agent to make those updates directly to the spec.” A rename is harmless. But the documented flow draws no line between a rename and a substantive change of scope. Both travel through the same prompt, the same skill, the same write.
That matters because of who holds the pen. Handoff has long failed because the spec goes stale after kickoff, and requirements that surface after coding starts already cost agents roughly double the rework. Specs fixes that by letting the builder’s agent keep it fresh, which also makes the builder the author of the standard its work is judged against.
Why intent and implementation shouldn’t share an author
Nathan Curtis, writing about spec-driven component development , wants specs to be a hub that “versions the intent” expressed across a team’s sources of truth. He says “we favor generated over authored,” and he prefers deterministic scripts to agents for transforms because inference brings cost and a risk of data loss. His model assumes that intent is versioned and that changes to it are traceable.
Specs, as documented, meets neither condition. The help guide says nothing about whether agent edits are labeled, whether they need approval, or how they appear in version history.
Here the evidence stops, and Pipeline’s reasoning begins. No study has measured agent edits to Specs; the feature is days old. What exists is a study of 5,851 real developer sessions by Obada Kraishan and Kulsawasd Jitkajornwanich, which measured agents’ end-of-session reports. They cited about one action in eleven, and they drifted toward the stated plan when execution had diverged from it. We covered that paper on its own . It examined wrap-up summaries, not spec edits. Read across, it suggests that an agent describing its own work tends to describe the plan it was given, not the work it did, and a spec updated by that agent could inherit the habit. The review step then breaks: a review against the spec ends up comparing the code with itself.
When the same agent builds the code and rewrites the spec, a review against the spec ends up comparing the code with itself.
The strongest defense is a fair one
The best objection is that this is the cure, not the disease. A spec nobody updates after kickoff is the usual way handoff fails, and a spec that follows the code is at least accurate. Perhaps edits made by an agent can be inspected and reverted like any manual change. Figma’s documentation is silent on that: it says nothing about version history, labelling or approval of agent edits, so the safeguard is plausible but undocumented.
Grant all of it. Then the risk is not a missing trail but an unread one. Version history is a log, not a review. Nothing in the documented flow asks anyone to look at it before sign-off, and a quiet substantive edit looks the same in it as a rename.
Consider the product designer who signs off a build against “the spec.” She used to ask whether the build matched it. Now she must first ask whether the spec still says what she agreed to, or whether an agent reworded it partway through to fit the code. That means opening the history, reading the diffs, and treating the spec as a moving target. It is a new job, and a tool that markets itself as “a native home for context” doesn’t mention it.
The fix is cheap to state. Keep intent and implementation under different authors: a locked baseline, or agent edits that arrive as suggestions a human accepts. Until Figma documents something like that, a spec that agents can rewrite is a draft, and the sign-off should say so.
