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. This is a mistake. figmascope exports structured context — the right input from the start.

What pixel context is

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 can 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.

What structured context is

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:

The figmascope IR is this. Each node in a per-screen JSON has kind, name, absoluteBoundingBox, children, fills resolved to token references where available, auto-layout properties if applicable, and componentId on instances. It's the design tree made explicit.

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.

What gets lost in the pixel-to-structured direction

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. 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 if you support dark mode, or if 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 or a margin or padding on each item? The pixels don't say. The agent picks. The picks differ between runs.

The Figma → React pipeline, with and without structure

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 design system. Ship. Next screen: repeat from scratch because the previous run's outputs don't compose.

With structured context: Export bundle (one click, runs in browser). Pass CONTEXT.md + screen IR to Claude with your system prompt specifying framework and design system conventions. Get JSX that uses your token names, your component names, 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.

Structure means: typed

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. The mapping is 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.

Structure means: spatial

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, primaryAxisAlignItems, counterAxisAlignItems — the agent has everything it needs to generate correct layout code without pixel-counting.

The absolute bounding boxes also let the agent verify its output: if a generated component has different dimensions than the IR specified, something went wrong. This is a testable property of structured context that has no equivalent in pixel context.

Structure means: identity-aware

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 in the instances, and renders four calls. This is the correct output. 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.

Structure means: version-controllable

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 this in your PR description. You can run automated checks on it. You can use it to audit whether the code change matches the design change.

Where this leads: design context infrastructure

The tooling category that's forming here isn't "Figma export, but better." It's a new layer in the stack: design context infrastructure. The job of this layer 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. It has responsibilities that neither side currently owns: snapshot management, semantic extraction, token resolution, component inventory, cross-screen string indexing, bundle versioning. These are infrastructure concerns, not design tool concerns and not LLM concerns.

Treating it as infrastructure means: it's automated, it's versioned, it runs in CI, it has a defined format, it's inspectable. The same way a build system is infrastructure for code — not the code itself, not the target binary, but the reliable, reproducible pipeline that converts one to the other.

Honest: pixels still matter

figmascope 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.

This 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.

Where this leads for multi-target codegen

Structured context enables a workflow that 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. You run three agents with three different CONTEXT.md files. You 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 main figmascope app, then use it with Cursor, Claude Code, or Aider for multi-target, composable UI generation.