DEV Community: romantsisyk

Structured Context vs Pixel Context: What Coding Agents Actually Need

romantsisyk — Sun, 09 Aug 2026 23:00:43 +0000

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.

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 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:

Typed nodes: every element has a kind (FRAME, TEXT, INSTANCE, VECTOR) that carries semantic meaning about its role in the layout
Named values: colors are token references, not hex strings; spacings are token keys, not pixel values
Spatial relationships: layout direction, gap, padding, alignment — preserved as properties, not inferred from position
Identity links: component instances carry their source component ID; strings carry cross-reference keys
Hierarchy: the full node tree, with parent-child relationships intact

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

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

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

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

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

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

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 that in your PR description, run automated checks on it, and audit whether the code change matches the design change.

Where this leads: design context infrastructure

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.

Honest: pixels still matter

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.

One design, multiple targets

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.

Why Pasting Figma Screenshots into Claude Fails (And What to Use Instead)

romantsisyk — Sun, 09 Aug 2026 22:27:56 +0000

Here's the workflow that's become default in every design-to-code team right now: export a frame from Figma, paste the PNG into Claude or Cursor, type "build this", and iterate on the hallucinated output. It works just well enough to feel productive. It doesn't work well enough to ship from.

This isn't a model capability problem. It's an input problem. A screenshot is the worst possible representation of a Figma design for an LLM to reason about — and yet it's almost universally what teams reach for first. The structured alternative is what figmascope exports: a context bundle of typed IR, design tokens, component inventory, and UI strings that the agent can read instead of guess. Let's walk through everything a screenshot silently destroys.

The hierarchy is gone

A Figma file is a tree. Frames contain auto-layout groups, which contain component instances, which contain text and fill layers. That tree encodes the layout intent: this row is a flex container, this card is a padded box, these three items are siblings with 16px gaps between them.

A screenshot flattens that tree to a grid of pixels. The LLM sees shapes and colors. It does not see the layout structure — it infers it. And inference is lossy in both directions: the model may reconstruct structure that looks right visually but is wrong semantically (a fixed-width div instead of a flex child, absolute positioning instead of auto-layout), or it may see structural ambiguity and pick one arbitrarily.

You can't tell from a PNG whether a horizontal row of items is implemented with display: flex, CSS Grid, a custom HStack, or three absolutely-positioned divs. They're visually identical. The LLM picks one. The pick changes between runs.

Semantics don't survive rasterization

The LLM can see that a rectangle with rounded corners contains some text and an icon. What it can't see:

Is this a Button component or a custom card?
If it's a button, what variant is it — primary, secondary, ghost?
Is the icon decorative or meaningful?
Does this element have interactive states in the design system, or is it one-off?

Semantics in Figma live in the layer tree: component names, variant properties, node kinds. A Button/Primary/Large component is explicitly typed. In a screenshot, it's a rounded rectangle with a shadow and a label. The model guesses "this is probably a button" correctly most of the time — and then guesses "this is probably the primary variant" based on color, which may or may not match your design system's actual naming.

Small mismatches compound. A ghost button rendered as an outlined button. A tooltip rendered as a modal trigger. A disabled state rendered as active. Each of these is one screenshot-inference step away from the source of truth.

Spacing systems don't resolve to numbers

Look at a screenshot of a card with padding. What's the padding? You can't tell without measuring pixels, knowing the canvas scale, knowing the export resolution, and doing the math. The LLM does the math badly — it estimates, it rounds, and it has no way to know if your spacing system uses an 8px base grid or a 4px one or something custom.

So it guesses. It generates padding: 12px when the design says 16. It generates gap: 8px when the design says 12. These numbers look plausible in isolation but they're wrong — and if your design system uses spacing tokens like spacing.md or Spacing/400, the LLM doesn't know about them at all. It hardcodes literals that will drift from your system the moment anything changes.

The LLM isn't hallucinating. It's doing exactly what you'd do with only a screenshot: guessing. You're just surprised when the guesses are wrong because you could see the right answer in the Figma file all along.

Token relationships vanish

Your designer set that background to #7F5CFE. In Figma, that hex is bound to a variable: color/brand/primary. That binding is meaningful — it means the color participates in theming, it means dark mode swaps it, it means if the brand color changes you update one variable and every instance updates.

In the screenshot: it's purple. The LLM generates background-color: #7F5CFE. The token relationship is gone. Your codebase now has a hardcoded hex that will never track with your design system. Multiply this by every component on the screen.

The same applies to typography scales, border radii, and shadow definitions. Every value in a well-maintained Figma file is potentially a named token. Every value in a screenshot is just a number.

Component reuse is invisible

A well-composed screen reuses components. The four product cards are four instances of the same ProductCard component. The avatar in the nav and the avatar in the comment thread are both instances of Avatar/Medium. This matters for code: you want one React component, not four hand-rolled variations that will diverge.

From a screenshot, the LLM sees four visually similar rectangles. It may generate one reusable component — or it may generate four nearly-identical blocks of JSX because it didn't notice they were the same. There's no signal in the image to tell it which is correct.

Structured context carries componentId on every instance node. The agent knows: these four nodes are all ProductCard. Generate it once, render it four times with different props. That's the output you want. That's the output you can't get from pixels.

String identity is lost

You have a "Continue" button on three different screens. Are those three instances the same string, or did a designer write them independently? In a well-structured Figma file, they reference the same string key. That means one i18n entry, one change propagates everywhere.

In three screenshots: three times the LLM generates a hardcoded string. If you're building an internationalised app, you now have three strings to find and replace instead of one to look up. Small thing. Compounds across a real codebase.

Why the LLM hallucinates: it re-derives structure every time

The model has no memory of previous runs. Every time you paste the same screenshot, it reconstructs the structure from scratch. The reconstruction is probabilistic — which means the same screenshot + same prompt + same model can produce measurably different outputs on different runs. Same design, different code. Different component names, different className patterns, different layout choices.

This is not a model bug. It's the expected behavior of a probabilistic model given insufficient constraints. The screenshot provides insufficient constraints. The model fills the gaps — and the gaps are filled differently each time.

You can partially work around this with longer, more detailed prompts — "use Tailwind, use 8px grid, use these component names..." — but then you've manually specified the structure that should have been in the design file all along. You're doing the extraction work the tool should do.

The reproducibility problem

Teams that use screenshots for design-to-code handoff hit the same wall: the output is not reproducible. Two developers, same Figma screenshot, independently prompt Claude — they get different component structures, different className patterns, different nesting decisions. Now you have two codebases that look the same visually but are architecturally inconsistent.

This makes code review harder. It makes refactoring harder. It makes design system compliance auditing impossible. You can't diff "what did the agent generate from this design" if the answer changes every run.

Structured context fixes reproducibility because it fixes the inputs. A deterministic input bundle — the same JSON with the same node IDs, component names, token values, and spatial relationships — produces much more consistent output across runs, agents, and developers. Not perfectly deterministic: the model is still probabilistic. But the variance drops dramatically when the structure is specified rather than inferred.

What a screenshot gives you vs. what the IR gives you

Take a product card: image, title, subtitle, price, an "Add to cart" button. Here's what each input gives the agent:

Screenshot input: A rectangle with an image at the top, two lines of text, a number, and a button. Colors are inferred. Padding is estimated. Whether this is a component or one-off is unknown. The button variant is inferred from color. The spacing system is unknown.

IR input: Node kind FRAME, name ProductCard, component ID linking to the component definition. Auto-layout with vertical direction, 16px gap, 16px horizontal padding, 12px vertical padding. Child nodes: IMAGE (fills width, fixed height), TEXT with stringRef.key: "product.title" and style typography/heading.sm, TEXT with stringRef.key: "product.subtitle" and style typography/body.md, TEXT with fill color/price, INSTANCE of Button/Primary/Medium. Background fill color/surface.card. Border radius radius/card.

The IR gives the agent a spec. The screenshot gives it a suggestion.

The frame: this is the documentation problem

We solved this exact problem for source code decades ago. You don't give an agent a screenshot of your codebase and ask it to reason about architecture. You give it the code — the structured, parseable, semantically-meaningful representation. The abstract syntax tree, not a picture of the editor.

Figma designs are structured data. They have a well-defined tree structure with typed nodes and named values, and the Figma API exposes it completely. The only reason the screenshot workflow persists is that extracting the structure and formatting it as context has friction.

Reducing that friction is what figmascope does. You paste the Figma URL, the export runs in your browser, and you get a ZIP with structured context: CONTEXT.md, tokens.json, per-screen IR, component inventory, strings manifest. Everything the agent needs, none of it inferred from pixels.

Keep the screenshots for visual confirmation — the bundle includes 2x PNGs for exactly that. Use the structure for everything else. If you're on Claude Code, the full handoff pipeline walkthrough shows the pattern end-to-end; there are also variants for Cursor and Aider.