Context is becoming the bottleneck in AI-assisted development. Not model capability — models are improving fast enough that they're regularly not the constraint. What limits the quality of AI-generated code is the quality of context those models receive.
For Figma-to-code workflows, context comes in two fundamentally different forms: pixel context (screenshots, rendered images) and structured context (typed IR, tokens, semantic relationships). These aren't just different formats for the same information. They're different categories of input, with different properties, different loss characteristics, and different ceilings on what an agent can produce from them. The industry is still largely using pixel context. That's a mistake. figmascope exports structured context — the right input from the start. Here's how the two categories compare, and why the difference determines whether your generated code composes, diffs, and survives contact with a real design system.
Pixel context is any rasterized representation of a design: a screenshot exported from Figma, a PNG from "Export frame", a render from a design tool. It's what you get when you press Cmd+Shift+4 over your Figma canvas.
Vision-capable LLMs process pixel context impressively well. They recognize UI patterns, identify layout regions, infer component types from visual appearance, and generate plausible code from images alone. If you've used Claude or GPT-4V for screenshot-to-code, you've seen this. The outputs look right more often than you'd expect.
But "looks right" and "is right" are not the same thing — and the gap between them is where design system compliance, token fidelity, component identity, and reproducibility all live.
Structured context is a typed, machine-readable representation that preserves the semantics of the design: what each element is, not just what it looks like. It includes:
FRAME
, TEXT
, INSTANCE
, VECTOR
) that carries semantic meaning about its role in the layoutA structured IR is the design tree made explicit: each node has kind
, name
, absoluteBoundingBox
, children
, fills resolved to token references where available, auto-layout properties if applicable, and componentId
on instances.
Pixel context tells an agent what a design looks like. Structured context tells it what a design means. A coding agent needs meaning to write code, not appearance. Appearance is what visual tests are for.
The core failure mode of pixel context is irreversible information loss. When Figma renders a frame to PNG, it discards exactly the information that matters most for code generation:
The layer tree collapses. There is no longer a "group of three items with 8px gaps." There is a region of pixels that suggests a group. The agent has to reconstruct the tree structure from visual evidence, and reconstruction is approximate. It will be wrong some percentage of the time — and that percentage grows as designs get more complex.
Token bindings disappear. The orange background that maps to color/action/primary
becomes #FF6B00
. The agent generates a hardcoded hex. If your color ever changes, or you support dark mode, or you need to audit token usage, that hardcoded value is a liability.
Component identity is gone. Four instances of the same card component are four similar-looking rectangles. The agent may generate one reusable component or four similar-but-not-identical blocks, depending on how much structural similarity it infers. You want predictable output; you get probabilistic output.
Layout intent is ambiguous. Is this a flex row or a grid? Is the spacing between items a gap, a margin, or padding on each item? The pixels don't say. The agent picks — and the picks differ between runs.
Consider the path from Figma to production React.
With pixel context: Export PNG. Paste into Claude. Get JSX. Review JSX for correctness. Notice hardcoded values. Notice wrong component structure. Prompt for corrections. Iterate. Eventually get something plausible. Hand-edit to match the design system. Ship. Next screen: repeat from scratch because the previous run's outputs don't compose.
With structured context: Export a bundle (one click, runs in browser). Pass CONTEXT.md + screen IR to Claude with a system prompt specifying framework and design system conventions. Get JSX that uses your token names, your component names, and correct layout structure. Review for correctness. Ship. Next screen: same bundle, same agent, composable outputs because the inputs are consistent.
The work savings are real but secondary. The primary gain is composability. Structured context enables outputs that compose across screens and agents. Pixel context doesn't — each screen's output is an island generated from a fresh inference pass.
Every node in the IR has a kind
. This matters immediately. A TEXT
node generates a text element. A FRAME
with auto-layout generates a container. An INSTANCE
of Button/Primary/Large
generates a button component call with the right props. A VECTOR
generates an icon reference.
The agent doesn't guess. It maps kinds to code primitives — rules specified in CONTEXT.md for the target framework: "For INSTANCE nodes, use the component name to determine the React component. For FRAME with layoutMode HORIZONTAL, use a flex row. For TEXT with style typography/heading.lg, use the Heading component." These are compiler-style rules, not inference tasks.
The absoluteBoundingBox
on each node gives position and size in the Figma coordinate space. Combined with auto-layout properties — layoutMode
, itemSpacing
, paddingLeft/Right/Top/Bottom
, alignment — the agent has everything it needs to generate correct layout code without pixel-counting.
The bounding boxes also let the agent verify its own output: if a generated component has different dimensions than the IR specified, something went wrong. That's a testable property of structured context with no equivalent in pixel context.
When four nodes in the IR share a componentId
, the agent knows they're instances of the same component. It generates the component definition once, derives props from the variants, and renders four calls. This is the correct output — and it's not achievable from pixel context without significant prompt engineering that essentially asks the agent to re-derive structure the design file already had.
String cross-references work the same way. When multiple text nodes reference stringRef.key: "action.continue"
, the agent knows to use a single i18n lookup, not three hardcoded strings. The identity information is in the IR; the agent just reads it.
Plain JSON files diff cleanly. A changed padding value shows up as a one-line change in the per-screen IR. A renamed token shows up as a find-replace diff across the tokens file. A new component instance shows up as an added object in the children array.
This is design version history that's actually useful for engineers. Not "the design was updated on Tuesday" but "here are the three properties that changed between the v2 and v3 exports of this screen." You can put that in your PR description, run automated checks on it, and audit whether the code change matches the design change.
The tooling category forming here isn't "Figma export, but better." It's a new layer in the stack: design context infrastructure. Its job is to transform design source (Figma files, component libraries, token systems) into structured, agent-readable, version-controlled artifacts that feed the code generation layer.
This layer sits between the design tool and the coding agent, with responsibilities neither side currently owns: snapshot management, semantic extraction, token resolution, component inventory, cross-screen string indexing, bundle versioning. Treating it as infrastructure means it's automated, versioned, CI-runnable, defined-format, and inspectable — the same way a build system is infrastructure for code: not the code, not the binary, but the reliable, reproducible pipeline that converts one to the other.
Structured context bundles include 2x PNGs of every exported screen. Not because the PNG drives code generation, but because visual confirmation matters. An agent should be able to cross-reference its generated output against the PNG. A developer should be able to look at the screen without opening Figma. The PNG is a sanity check, not a specification.
That distinction — pixels for confirmation, structure for specification — is the right mental model. You don't eliminate pixel context; you demote it to its correct role. It's the QA artifact, not the build input.
The same way you wouldn't give a compiler a screenshot of your source code: you give it the source, and you use screenshots for documentation. The design file is the source. The bundle is the compilation artifact. The PNG is the documentation image.
Structured context enables a workflow pixel context can't: one design, multiple targets. The same IR can feed a React/Tailwind generator, a Jetpack Compose generator, and a SwiftUI generator. The underlying design is the same; the target-specific context (framework primitives, naming conventions, layout APIs) lives in CONTEXT.md, which is generated per-target.
This is multi-target codegen that actually scales. You export one bundle from the design, run three agents with three different CONTEXT.md files, and get three implementations that are structurally equivalent — because they were generated from the same IR, not from three separate inference passes over three screenshots.
The bottleneck for this workflow isn't model capability. It's context quality. Structured context is what makes it possible.
Export your structured context bundle from the figmascope app, then use it with Cursor, Claude Code, or Aider for multi-target, composable UI generation.