Context AI-assisted development में bottleneck बन रहा है। Model capability नहीं। Models इतनी तेज़ी से improve हो रहे हैं कि वे regularly constraint नहीं हैं। AI-generated code की quality को जो limit करता है वह है उन models को मिलने वाले context की quality।
Figma-to-code workflows के लिए, context दो fundamentally अलग-अलग forms में आता है: pixel context (screenshots, rendered images) और structured context (typed IR, tokens, semantic relationships)। ये सिर्फ same information के अलग-अलग formats नहीं हैं। ये input की अलग-अलग categories हैं, अलग-अलग properties, अलग-अलग loss characteristics, और agent उनसे क्या produce कर सकता है इसकी अलग-अलग ceilings के साथ।
Industry अभी भी largely pixel context use कर रही है। यह एक गलती है। figmascope structured context export करता है — शुरू से सही input।
Pixel context क्या है
Pixel context design का कोई भी rasterized representation है: Figma से export किया screenshot, "Export frame" से PNG, design tool से render। यह वह है जो आपको Figma canvas पर Cmd+Shift+4 press करने पर मिलता है।
Vision-capable LLMs pixel context को impressively well process कर सकते हैं। वे UI patterns recognize करते हैं, layout regions identify करते हैं, visual appearance से component types infer करते हैं, और images अकेले से plausible code generate करते हैं। अगर आपने screenshot-to-code के लिए Claude या GPT-4V use किया है, तो आपने यह देखा है। Outputs अक्सर आपकी expectation से ज्यादा right लगते हैं।
लेकिन "looks right" और "is right" same चीज़ नहीं हैं, और उनके बीच का gap वह जगह है जहां design system compliance, token fidelity, component identity, और reproducibility सब रहते हैं।
Structured context क्या है
Structured context एक typed, machine-readable representation है जो design की semantics preserve करती है: हर element क्या है, न कि बस यह कैसा दिखता है। इसमें शामिल हैं:
- Typed nodes: हर element का एक kind है (
FRAME,TEXT,INSTANCE,VECTOR) जो layout में उसकी role के बारे में semantic meaning carry करता है - Named values: colors hex strings नहीं, token references हैं; spacings pixel values नहीं, token keys हैं
- Spatial relationships: layout direction, gap, padding, alignment — properties के रूप में preserved, position से inferred नहीं
- Identity links: component instances अपना source component ID carry करते हैं; strings cross-reference keys carry करती हैं
- Hierarchy: full node tree, parent-child relationships intact
figmascope IR यही है। Per-screen JSON में हर node में kind, name, absoluteBoundingBox, children, available होने पर token references से resolved fills, applicable होने पर auto-layout properties, और instances पर componentId है। यह design tree explicit बना दी गई है।
Pixel context agent को बताता है कि design कैसा दिखता है। Structured context उसे बताता है कि design का क्या मतलब है। Coding agent को code लिखने के लिए meaning चाहिए, appearance नहीं। Appearance visual tests के लिए है।
Pixel-to-structured direction में क्या lose होता है
Pixel context का core failure mode irreversible information loss है। जब Figma एक frame को PNG पर render करता है, यह exactly वह information discard करता है जो code generation के लिए सबसे ज्यादा matter करती है:
Layer tree collapse हो जाता है। अब "8px gaps के साथ तीन items का group" नहीं रहता। एक region of pixels है जो group suggest करता है। Agent को visual evidence से tree structure reconstruct करनी होती है, और reconstruction approximate है। यह कुछ percentage of time गलत होगा। वह percentage designs complex होने पर बढ़ती है।
Token bindings disappear हो जाती हैं। color/action/primary पर map होने वाला orange background #FF6B00 बन जाता है। Agent hardcoded hex generate करता है। अगर आपका color कभी बदलता है, या आप dark mode support करते हैं, या आपको token usage audit करनी है, वह hardcoded value एक liability है।
Component identity चली जाती है। Same card component के चार instances चार similar-looking rectangles हैं। Agent एक reusable component या चार similar-but-not-identical blocks generate कर सकता है, इस बात पर depend करते हुए कि वह कितनी structural similarity infer करता है। आप predictable output चाहते हैं; आपको probabilistic output मिलता है।
Layout intent ambiguous है। क्या यह flex row है या grid? Items के बीच spacing gap है या margin है या हर item पर padding? Pixels नहीं बताते। Agent pick करता है। Picks runs के बीच differ करते हैं।
Figma → React pipeline, structure के साथ और बिना
Figma से production React तक के path पर consider करें।
Pixel context के साथ: PNG export करें। Claude में paste करें। JSX पाएं। Correctness के लिए JSX review करें। Hardcoded values notice करें। Wrong component structure notice करें। Corrections के लिए prompt करें। Iterate करें। Eventually कुछ plausible पाएं। Design system match करने के लिए hand-edit करें। Ship करें। Next screen: scratch से repeat करें क्योंकि previous run के outputs compose नहीं होते।
Structured context के साथ: Bundle export करें (एक click, browser में चलता है)। Framework और design system conventions specify करने वाले system prompt के साथ Claude को CONTEXT.md + screen IR pass करें। JSX पाएं जो आपके token names, आपके component names, correct layout structure use करता है। Correctness के लिए review करें। Ship करें। Next screen: same bundle, same agent, composable outputs क्योंकि inputs consistent हैं।
Work savings real हैं लेकिन secondary हैं। Primary gain composability है। Structured context ऐसे outputs enable करता है जो screens और agents में compose होते हैं। Pixel context नहीं करता — हर screen का output एक island है जो fresh inference pass से generate हुआ है।
Structure का मतलब: typed
IR में हर node का kind है। यह immediately matter करता है। TEXT node text element generate करता है। Auto-layout के साथ FRAME एक container generate करता है। Button/Primary/Large का INSTANCE right props के साथ button component call generate करता है। VECTOR icon reference generate करता है।
Agent guess नहीं करता। यह kinds को code primitives पर map करता है। Mapping target framework के लिए CONTEXT.md में specified है। "INSTANCE nodes के लिए, component name use करके React component determine करें। HORIZONTAL layoutMode के साथ FRAME के लिए, flex row use करें। typography/heading.lg style के साथ TEXT के लिए, Heading component use करें।" ये compiler-style rules हैं, inference tasks नहीं।
Structure का मतलब: spatial
हर node पर absoluteBoundingBox Figma coordinate space में position और size देता है। Auto-layout properties के साथ combine करके — layoutMode, itemSpacing, paddingLeft/Right/Top/Bottom, primaryAxisAlignItems, counterAxisAlignItems — agent के पास pixel-counting के बिना correct layout code generate करने के लिए सब कुछ है।
Absolute bounding boxes agent को अपना output verify भी करने देते हैं: अगर generated component की dimensions IR ने specify की से different हैं, कुछ गलत हुआ। यह structured context की एक testable property है जिसका pixel context में कोई equivalent नहीं है।
Structure का मतलब: identity-aware
जब IR में चार nodes एक componentId share करते हैं, agent जानता है कि वे same component के instances हैं। यह component definition एक बार generate करता है, instances में variants से props derive करता है, और चार calls render करता है। यह correct output है। यह pixel context से significant prompt engineering के बिना achievable नहीं है।
String cross-references same तरह काम करते हैं। जब multiple text nodes stringRef.key: "action.continue" reference करते हैं, agent जानता है एक single i18n lookup use करना है, तीन hardcoded strings नहीं। Identity information IR में है; agent बस इसे read करता है।
Structure का मतलब: version-controllable
Plain JSON files cleanly diff होती हैं। Changed padding value per-screen IR में एक one-line change के रूप में दिखती है। Renamed token tokens file में find-replace diff के रूप में दिखता है। New component instance children array में एक added object के रूप में दिखता है।
यह design version history है जो engineers के लिए actually useful है। "Design Tuesday को update हुआ" नहीं बल्कि "यहाँ वे तीन properties हैं जो इस screen के v2 और v3 exports के बीच बदलीं।" आप इसे अपने PR description में रख सकते हैं। आप इस पर automated checks run कर सकते हैं।
यह कहाँ lead करता है: design context infrastructure
यहाँ forming tooling category "Figma export, but better" नहीं है। यह stack में एक नई layer है: design context infrastructure। इस layer का काम design source (Figma files, component libraries, token systems) को structured, agent-readable, version-controlled artifacts में transform करना है जो code generation layer को feed करते हैं।
यह layer design tool और coding agent के बीच बैठती है। इसमें responsibilities हैं जो currently न तो side own करती है: snapshot management, semantic extraction, token resolution, component inventory, cross-screen string indexing, bundle versioning। ये infrastructure concerns हैं, design tool concerns नहीं और LLM concerns भी नहीं।
इसे infrastructure treat करने का मतलब है: यह automated है, versioned है, CI में चलता है, इसका defined format है, inspectable है। जैसे build system code के लिए infrastructure है — code खुद नहीं, target binary नहीं, बल्कि reliable, reproducible pipeline जो एक को दूसरे में convert करती है।
ईमानदारी: pixels अभी भी matter करते हैं
figmascope bundles में हर exported screen के 2x PNGs शामिल हैं। इसलिए नहीं कि PNG code generation drive करता है, बल्कि इसलिए कि visual confirmation matter करती है। एक agent PNG के against अपना generated output cross-reference करने में सक्षम होना चाहिए। एक developer को Figma खोले बिना screen देखने में सक्षम होना चाहिए। PNG एक sanity check है, specification नहीं।
यह distinction — confirmation के लिए pixels, specification के लिए structure — सही mental model है। आप pixel context eliminate नहीं करते; आप इसे उसकी correct role पर demote करते हैं। यह QA artifact है, build input नहीं।
जैसे आप compiler को अपने source code का screenshot नहीं देंगे: आप उसे source देते हैं, और screenshots को documentation के लिए use करते हैं। Design file source है। Bundle compilation artifact है। PNG documentation image है।
Multi-target codegen के लिए यह कहाँ lead करता है
Structured context एक ऐसा workflow enable करता है जो pixel context नहीं कर सकता: एक design, multiple targets। Same IR एक React/Tailwind generator, एक Jetpack Compose generator, और एक SwiftUI generator को feed कर सकता है। Underlying design same है; target-specific context (framework primitives, naming conventions, layout APIs) CONTEXT.md में रहता है, जो per-target generate होता है।
यह multi-target codegen है जो actually scale करता है। आप design से एक bundle export करते हैं। आप तीन different CONTEXT.md files के साथ तीन agents run करते हैं। आपको तीन implementations मिलती हैं जो structurally equivalent हैं क्योंकि वे same IR से generate हुई थीं, तीन screenshots पर तीन अलग-अलग inference passes से नहीं।
इस workflow के लिए bottleneck model capability नहीं है। यह context quality है। Structured context इसे possible बनाता है।
अपना structured context bundle main figmascope app से export करें, फिर multi-target, composable UI generation के लिए इसे Cursor, Claude Code, या Aider के साथ use करें।