Software teams have spent decades building determinism into their toolchains. Lockfiles for package managers. Pinned base images for containers. Reproducible builds for compiled artifacts. The principle is well-understood: the same inputs should produce the same outputs, always, on any machine, at any time.

Design handoff has never applied this principle. It has been, by default, a fundamentally human and therefore non-deterministic process. A designer explains the design to a developer. The developer interprets it. The interpretation varies by person, by day, by how clearly the Zeplin comment was written. You can't replay that. You can't test it. You can't diff it.

In a world of AI coding agents, non-deterministic handoff is now a first-class engineering problem. figmascope addresses it with a frozen, portable context bundle.

Why current tooling is non-deterministic for agents

Zeplin and Avocode give you numbers extracted from Figma — layer dimensions, color values, font sizes. But they serve them as a browseable UI, not a machine-readable artifact. An agent pointed at Zeplin has to navigate a UI to find the values, which is brittle, rate-limited, and dependent on how the annotations were written.

Figma Dev Mode goes further: it gives you code snippets generated inline from the design. But the snippets are stateless — regenerated on demand, not versioned. There's no bundle you can check in. There's no file you can diff. If the designer updates the design, the Dev Mode view updates silently. You don't know when the underlying design changed relative to what you last exported.

Screenshots are the worst case: pure pixel data, fully non-deterministic to parse, yielding different structure inference every time.

Live MCP connections — tools that give agents real-time API access to the Figma file — are non-deterministic by definition. The file changes while the agent is reading it. The agent's run at 9am and its run at 2pm see different inputs. You can't reproduce the 9am run because the source has changed.

Agents are probabilistic systems. Giving them non-deterministic inputs doesn't just produce variance — it makes the system untestable. You can't tell whether a bad output was caused by the model, the prompt, or the fact that someone moved a layer between runs.

The bundle as a compilation unit

The right mental model for a figmascope export is a compilation artifact. Just as a compiler takes source code and produces a deterministic binary — same source, same flags, same binary — figmascope takes a Figma file state and produces a deterministic bundle: same file state, same bundle, every time.

The bundle is a frozen snapshot. It captures a specific version of the design and serializes every relevant property: spatial layout, component identity, token bindings, string content, hierarchy. Once exported, the bundle is immutable. The Figma file can change; the bundle doesn't. If you want to incorporate those changes, you re-export and get a new bundle.

This is the compilation unit model. The design file is source. The bundle is the artifact. Agents consume artifacts, not source.

Four properties of a deterministic handoff

Snapshot-able. The handoff artifact must represent a specific point in time. Not "the current state of the Figma file" — a named, versioned export. figmascope bundles carry a _meta.json with an export timestamp and a fingerprint of what was included. The bundle is a snapshot, not a live view.

Portable. The artifact must be self-contained. No dependencies on external services, live APIs, or logged-in sessions. A figmascope bundle is a ZIP of plain files — JSON, Markdown, PNG. You can copy it, email it, check it into git, attach it to a PR, hand it to a junior developer or a coding agent with no setup.

Inspectable. A deterministic artifact is useless if you can't verify what's in it. Every file in the bundle is human-readable. CONTEXT.md is Markdown. tokens.json is W3C-ish structure. The per-screen IR is JSON with clear field names. An engineer can open the bundle and audit exactly what the agent was told. This is qualitatively different from "I pasted the screenshot and got some code."

Reproducible. Given the same Figma file state, two separate exports should produce functionally equivalent bundles. Not byte-identical (timestamps differ), but semantically identical: same node structures, same token values, same component inventory. If you export twice from an unchanged file and the bundles differ semantically, something is wrong. This property lets you validate your export pipeline and catch regressions in the extractor itself.

How this plays out in practice

A designer finishes a sprint's worth of screens. They export a bundle. The bundle gets committed to the repo alongside the ticket — or attached to the Jira issue, or dropped in the shared drive, depending on your workflow. At this point, the handoff artifact is fixed. The agent (or the developer) works from the bundle, not from the live Figma file.

Midway through implementation, the designer updates three screens. No problem: the developer's working bundle is unchanged. The new screens get a new export. Now you have two bundles and you can diff them: what changed between the design the developer started with and the current design. This is exactly the kind of change visibility that's impossible with screenshot-based or live-connection-based workflows.

In a multi-agent workflow — one agent builds the component library, another builds the screen layouts, a third writes the tests — each agent gets the same bundle as its source of truth. They're all working from the same frozen design state. Their outputs are composable because their inputs are shared and fixed. This is the precondition for multi-agent UI generation that's actually reliable.

Diffing bundles

Because the bundle is plain files, it diffs like code. Two exports of the same file across two Figma versions give you a JSON diff that tells you exactly what changed:

This is design change visibility that doesn't exist in any current handoff tooling. Figma has its own version history, but it's visual and designer-facing. A bundle diff is structured and developer-facing: machine-readable change data that can drive automated tests, update changelogs, or trigger CI workflows.

CI/CD for design handoff

Once handoff is deterministic, CI/CD follows naturally. You can write tests that run against a bundle: "this screen must include a Button/Primary component," "this token must be bound and not a hardcoded value," "this string must have a stringRef key." These are static analysis checks against structured data. They run in milliseconds. They run in a pipeline.

You can also validate the output of the codegen agent against the bundle it was given. Did the agent use the tokens or hardcode literals? Did it generate the right number of instances of the repeated component? Did it use the correct spacing values? These questions are answerable when the source of truth is a structured file, not a PNG.

The MCP comparison

MCP-style live connections to Figma are gaining traction. The appeal is obvious: the agent always sees the latest design, no export step, no manual bundle management. But live connections trade determinism for convenience — and for AI agents that trade is bad.

Live connections mean: the agent's context depends on when it runs. A run at 9am and a run at 2pm see different data if the designer worked during the day. You cannot reproduce the earlier run. You cannot test against a fixed input. You cannot audit what the agent was told. If the generated code is wrong, you can't distinguish "the model made a bad inference" from "the design changed under the agent."

The right model is: live connections for design exploration and iteration (where recency matters), deterministic bundles for handoff and generation (where reproducibility matters). They're not competing — they operate at different points in the workflow.

Handing off to a junior developer

The same properties that make bundles good for AI agents make them good for human developers who are new to a codebase. A junior developer handed a bundle has: the complete spec in CONTEXT.md, all token values in tokens.json, every component listed with their properties, every string with their identity. They don't need to be in the Figma file. They don't need a Figma account. They don't need to know which screen is the authoritative one.

The bundle is a complete, self-contained work order. Same as an agent would receive. The only difference is the human reads it and the agent processes it programmatically — but the artifact is identical.

That unification — same artifact, human or agent consumer — is the point. The bundle is the unit of handoff. Everything else is implementation detail.

See deterministic handoff in practice with Claude Code, Cursor, or Aider. All start from the same figmascope export.