Here is a contradiction most teams are about to live inside without noticing: Figma just shipped a workflow whose whole point is that you move fluidly back and forth between canvas and code, and in the same season a design systems consultancy published a model whose whole point is that going back and forth is the exact thing you must never do once AI is involved. Both are pitched as the cure for drift. They cannot both be right in the same repo.
Reportedly, Figma Make now opens pull requests, and the contract model has been formalized down to a checkable JSON file. The argument has stopped being philosophical. It's now a fight over where a component's authoritative version physically lives.
Start with the scene Figma staged in its own Workflow Lab. A fictional museum, the Museum of Speculative Futures, is doing an accessibility pass alongside an architecture rewrite. The engineer needs to stay heads-down on the rewrite. So the designer, instead of writing a ticket that lands in the backlog and dies, asks for repo access and fixes the accessibility gaps directly.
The handoff runs backwards. The designer builds; the engineer reviews. The engineer's judgment lands at review instead of implementation.
Figma frames this as unblocking the last 20%—the small, high-craft fixes too granular to prioritize and too important to drop. And on that framing it's a genuine restructuring, not a demo trick. The path from "I noticed a minor thing" to "it shipped" no longer routes through a queue.
But the scene accidentally reveals something harder than the workflow it's selling.
Here's the moment. The designer goes to fix the date picker—in a static mock, a five-minute change. Working against the actual code, Make surfaces what the canvas couldn't: the date picker isn't a one-off. It's a shared component rendering in three places—the exhibition page, the events calendar, and the membership sign-up flow.
A ticket would have said "fix the date picker on the exhibition page." One screen, one fix. It would have shipped a correct fix to one place and left two stale—an inconsistency nobody notices until much later, if at all.
The code knew about the dependency even when the ticket didn't. That's the real lesson buried in the demo, and it's not "designers should touch code." It's a question: where does the fix belong? Where does the component actually live?
Because "the exhibition page" and "the shared component in three places" are two different answers to that question—and there are, right now, three competing architectures each betting on a different one.
There are, right now, three competing architectures each betting on a different answer to one question: where does the component actually live?
Bet one: the component lives on the designer's machine. This is Figma Make's wager. You connect your GitHub repo, make direct visual edits, annotate the interaction changes, and the agent finds the relevant code and edits it. Until you open a PR, everything sits as local commits. The canvas is where the authoritative change originates; the repo is downstream of it. Figma is explicit about the loop it wants—canvas to code and back, "no right place to start."
Bet two: the component lives in neither Figma nor code. This is the design system contract, built on Nathan Curtis's "components as data" and, per Southleft, formalized in their playground. For each component you write a small JSON or YAML file—its options, its tokens, what's allowed inside. Both the Figma variants and the typed code options get generated from that one file. Neither is the original; both are printouts of the same recipe. A checker compares all three and tells you exactly where they stopped agreeing.
The contract's central rule is the one that matters here: Figma and code are never allowed to update each other directly. A designer changes a color, an engineer adds an option—the change goes into the contract first, gets reviewed, and both sides rebuild. One source in the middle, everyone else follows.
Bet three: the component's ownership is zoned, and CI enforces the zones. This is MCP governance. Three ownership zones—system-owned (tokens, spacing, accessibility defaults), product-owned (composition, variants), engineer-owned (runtime, state, performance). The operating rule: generate aggressively in zone 2, cautiously in zone 1, never auto-commit zone 3. Authority isn't a single file or a single machine; it's a policy that a gate refuses to let you cross.
Now put them side by side and the incompatibility is not stylistic. It's structural.
Make says the designer, on their machine, produces the authoritative change and pushes it toward a PR. The contract says no human—designer or engineer—may author the real thing directly; you edit the middle file and let both sides regenerate. These are opposite answers to "who holds the source."
The tell is right there in Figma's own language. The whole pitch is that you "go back and forth between canvas and code." The contract model names that exact motion as the failure. Curtis's own hand-authored workflow reads examples out of Figma and refines in both places—which, the contract argues, is perfectly sensible when a careful human holds both ends. The bet is that once AI is in the loop, "we go back and forth" stops being a workflow and becomes a hole.
According to Southleft, an AI left to build unsupervised reportedly scored 69 out of 100. Not a catastrophe—but not something you'd ship without review, and exactly the kind of quiet degradation that "back and forth" lets slip through because no single edit looks wrong.
So a team running both is running two contradictory instructions at once. Make invites the designer to edit code on the canvas and sync it back. The contract forbids precisely that sync. Adopt both and you don't get redundancy—you get a repo where half your changes originate on a canvas and half get regenerated from a middle file, and the two overwrite each other on a schedule nobody controls. You'll drift faster than either model alone.
MCP governance arguably doesn't reconcile them; it just draws the boundary somewhere else. Its zones would let Make run wild in product-owned composition, treat tokens with suspicion, and hard-stop before runtime. It's compatible with the contract in spirit—both are trying to constrain the generator—but it locates authority in a CI policy rather than a source file, which is a third answer, not a merger of the first two.
Which brings us to the quiet ground where the winner actually gets decided: vocabulary. Specifically, the move from styles to Variables and tokens.
This looks like housekeeping. It is not. A Variable is a named, reusable value—reference color/text/primary instead of hardcoding #1A1A1A. A semantic token is named for its purpose, not its value; it aliases down to a primitive; the resolved value is whatever the current mode produces. Once your components reference names instead of values, the component stops being a picture and becomes data—options, aliases, scopes.
And data is exactly what a contract checks and what a governance gate lints against. A component made of bound Variables is one a checker can compare across all three surfaces deterministically—same file in, same answer out. A component made of hardcoded styles can only be eyeballed, and eyeballing is where drift creeps back in.
So the teams migrating from styles to tokens right now think they're tidying their design system. What they're really doing is quietly making the contract and governance models possible—and making Make's freehand canvas-to-code loop harder to justify, because the moment everything is a checkable token, "go back and forth" is no longer a convenience. It's an unguarded edge.
Pick your locus of authority before the vocabulary picks it for you. The component lives in exactly one place. The only question left is whether you decided which, or found out at review.