El contexto se está convirtiendo en el cuello de botella en el desarrollo asistido por IA. No la capacidad del modelo. Los modelos mejoran lo suficientemente rápido como para que regularmente no sean la restricción. Lo que limita la calidad del código generado por IA es la calidad del contexto que reciben esos modelos.
Para los flujos de trabajo de Figma-a-código, el contexto viene en dos formas fundamentalmente diferentes: contexto de píxeles (capturas de pantalla, imágenes renderizadas) y contexto estructurado (IR tipado, tokens, relaciones semánticas). Estos no son solo formatos diferentes para la misma información. Son categorías diferentes de entrada, con diferentes propiedades, diferentes características de pérdida y diferentes techos sobre lo que un agente puede producir a partir de ellos.
La industria todavía usa principalmente contexto de píxeles. Esto es un error. figmascope exporta contexto estructurado — la entrada correcta desde el principio.
Qué es el contexto de píxeles
El contexto de píxeles es cualquier representación rasterizada de un diseño: una captura de pantalla exportada de Figma, un PNG de "Exportar frame," un renderizado de una herramienta de diseño. Es lo que obtienes cuando presionas Cmd+Shift+4 sobre tu lienzo de Figma.
Los LLM con capacidad visual pueden procesar el contexto de píxeles impresionantemente bien. Reconocen patrones de UI, identifican regiones de layout, infieren tipos de componentes a partir de la apariencia visual y generan código plausible solo desde imágenes. Si has usado Claude o GPT-4V para captura-de-pantalla-a-código, lo has visto. Las salidas parecen correctas más a menudo de lo que esperarías.
Pero "parece correcto" y "es correcto" no son lo mismo, y la brecha entre ellos es donde viven el cumplimiento del sistema de diseño, la fidelidad de tokens, la identidad de componentes y la reproducibilidad.
Qué es el contexto estructurado
El contexto estructurado es una representación tipada y legible por máquinas que preserva la semántica del diseño: qué es cada elemento, no solo cómo se ve. Incluye:
- Nodos tipados: cada elemento tiene un tipo (
FRAME,TEXT,INSTANCE,VECTOR) que lleva significado semántico sobre su rol en el layout - Valores nombrados: los colores son referencias de tokens, no cadenas hexadecimales; los espaciados son claves de tokens, no valores en píxeles
- Relaciones espaciales: dirección del layout, gap, padding, alineación — preservados como propiedades, no inferidos desde posición
- Vínculos de identidad: las instancias de componentes llevan su ID de componente fuente; las cadenas llevan claves de referencia cruzada
- Jerarquía: el árbol de nodos completo, con relaciones padre-hijo intactas
El IR de figmascope es esto. Cada nodo en un JSON por pantalla tiene kind, name, absoluteBoundingBox, children, fills resueltos a referencias de tokens donde estén disponibles, propiedades de auto-layout si aplica, y componentId en instancias. Es el árbol de diseño hecho explícito.
El contexto de píxeles le dice a un agente cómo se ve un diseño. El contexto estructurado le dice qué significa un diseño. Un agente de codificación necesita significado para escribir código, no apariencia. La apariencia es para lo que sirven los tests visuales.
Qué se pierde en la dirección píxeles-a-estructurado
El modo de falla central del contexto de píxeles es la pérdida de información irreversible. Cuando Figma renderiza un frame a PNG, descarta exactamente la información que más importa para la generación de código:
El árbol de capas se colapsa. Ya no hay "un grupo de tres elementos con espacios de 8px." Hay una región de píxeles que sugiere un grupo. El agente tiene que reconstruir la estructura del árbol a partir de evidencia visual, y la reconstrucción es aproximada. Estará equivocada un cierto porcentaje del tiempo. Ese porcentaje crece a medida que los diseños se vuelven más complejos.
Los vínculos de tokens desaparecen. El fondo naranja que se mapea a color/action/primary se convierte en #FF6B00. El agente genera un hex hardcodeado. Si tu color alguna vez cambia, o si admites modo oscuro, o si necesitas auditar el uso de tokens, ese valor hardcodeado es un pasivo.
La identidad de componentes desaparece. Cuatro instancias del mismo componente de tarjeta son cuatro rectángulos de aspecto similar. El agente puede generar un componente reutilizable o cuatro bloques similares-pero-no-idénticos, dependiendo de cuánta similitud estructural infiera. Quieres salida predecible; obtienes salida probabilística.
La intención de layout es ambigua. ¿Es esto una fila flex o una cuadrícula? ¿El espaciado entre elementos es un gap, un margen o padding en cada elemento? Los píxeles no lo dicen. El agente elige. Las elecciones difieren entre ejecuciones.
El pipeline Figma → React, con y sin estructura
Considera el camino desde Figma hasta React de producción.
Con contexto de píxeles: Exportar PNG. Pegar en Claude. Obtener JSX. Revisar JSX para verificar corrección. Notar valores hardcodeados. Notar estructura de componentes incorrecta. Hacer prompt para correcciones. Iterar. Eventualmente obtener algo plausible. Editar manualmente para coincidir con el sistema de diseño. Publicar. Siguiente pantalla: repetir desde cero porque las salidas de la ejecución anterior no componen.
Con contexto estructurado: Exportar bundle (un clic, corre en el navegador). Pasar CONTEXT.md + IR de pantalla a Claude con tu prompt del sistema especificando el framework y las convenciones del sistema de diseño. Obtener JSX que usa tus nombres de tokens, tus nombres de componentes, estructura de layout correcta. Revisar para verificar corrección. Publicar. Siguiente pantalla: mismo bundle, mismo agente, salidas componibles porque las entradas son consistentes.
Los ahorros de trabajo son reales pero secundarios. La ganancia principal es la componibilidad. El contexto estructurado permite salidas que componen entre pantallas y agentes. El contexto de píxeles no — la salida de cada pantalla es una isla generada desde un pase de inferencia fresco.
Estructura significa: tipado
Cada nodo en el IR tiene un kind. Esto importa inmediatamente. Un nodo TEXT genera un elemento de texto. Un FRAME con auto-layout genera un contenedor. Una INSTANCE de Button/Primary/Large genera una llamada a componente de botón con las props correctas. Un VECTOR genera una referencia de icono.
El agente no adivina. Mapea tipos a primitivas de código. El mapeo está especificado en CONTEXT.md para el framework objetivo. "Para nodos INSTANCE, usa el nombre del componente para determinar el componente React. Para FRAME con layoutMode HORIZONTAL, usa una fila flex. Para TEXT con estilo typography/heading.lg, usa el componente Heading." Estas son reglas estilo compilador, no tareas de inferencia.
Estructura significa: espacial
El absoluteBoundingBox en cada nodo proporciona posición y tamaño en el espacio de coordenadas de Figma. Combinado con las propiedades de auto-layout — layoutMode, itemSpacing, paddingLeft/Right/Top/Bottom, primaryAxisAlignItems, counterAxisAlignItems — el agente tiene todo lo que necesita para generar código de layout correcto sin contar píxeles.
Las cajas delimitadoras absolutas también le permiten al agente verificar su salida: si un componente generado tiene dimensiones diferentes a las especificadas en el IR, algo salió mal. Esta es una propiedad verificable del contexto estructurado que no tiene equivalente en el contexto de píxeles.
Estructura significa: consciente de la identidad
Cuando cuatro nodos en el IR comparten un componentId, el agente sabe que son instancias del mismo componente. Genera la definición del componente una vez, deriva props de las variantes en las instancias y renderiza cuatro llamadas. Esta es la salida correcta. No es alcanzable desde el contexto de píxeles sin una ingeniería de prompts significativa que esencialmente le pide al agente que re-derive la estructura que el archivo de diseño ya tenía.
Las referencias cruzadas de cadenas funcionan de la misma manera. Cuando múltiples nodos de texto referencian stringRef.key: "action.continue", el agente sabe que debe usar una sola búsqueda i18n, no tres cadenas hardcodeadas. La información de identidad está en el IR; el agente simplemente la lee.
Estructura significa: controlable por versión
Los archivos JSON planos tienen diff limpiamente. Un valor de padding cambiado aparece como un cambio de una línea en el IR por pantalla. Un token renombrado aparece como un diff de buscar-y-reemplazar en el archivo de tokens. Una nueva instancia de componente aparece como un objeto añadido en el array de hijos.
Este es el historial de versiones de diseño que realmente es útil para los ingenieros. No "el diseño fue actualizado el martes" sino "aquí están las tres propiedades que cambiaron entre las exportaciones v2 y v3 de esta pantalla." Puedes poner esto en la descripción de tu PR. Puedes ejecutar verificaciones automatizadas sobre él. Puedes usarlo para auditar si el cambio de código coincide con el cambio de diseño.
A dónde lleva esto: infraestructura de contexto de diseño
La categoría de herramientas que se está formando aquí no es "exportación de Figma, pero mejor." Es una nueva capa en el stack: infraestructura de contexto de diseño. El trabajo de esta capa es transformar la fuente de diseño (archivos de Figma, bibliotecas de componentes, sistemas de tokens) en artefactos estructurados, legibles por agentes y controlados por versión que alimentan la capa de generación de código.
Esta capa se sitúa entre la herramienta de diseño y el agente de codificación. Tiene responsabilidades que ninguno de los dos lados posee actualmente: gestión de instantáneas, extracción semántica, resolución de tokens, inventario de componentes, indexación de cadenas entre pantallas, versionado de bundles. Estas son preocupaciones de infraestructura, no preocupaciones de la herramienta de diseño ni del LLM.
Tratarla como infraestructura significa: es automatizada, está versionada, corre en CI, tiene un formato definido, es inspeccionable. De la misma manera que un sistema de build es infraestructura para el código — no el código en sí, no el binario objetivo, sino el pipeline confiable y reproducible que convierte uno en el otro.
Honestamente: los píxeles todavía importan
Los bundles de figmascope incluyen PNGs 2x de cada pantalla exportada. No porque el PNG impulse la generación de código, sino porque la confirmación visual importa. Un agente debe poder hacer referencia cruzada de su salida generada contra el PNG. Un desarrollador debe poder ver la pantalla sin abrir Figma. El PNG es una verificación de cordura, no una especificación.
Esta distinción — píxeles para confirmación, estructura para especificación — es el modelo mental correcto. No eliminas el contexto de píxeles; lo degradas a su rol correcto. Es el artefacto de QA, no la entrada de build.
De la misma manera que no le darías a un compilador una captura de pantalla de tu código fuente: le das el código, y usas capturas de pantalla para documentación. El archivo de diseño es el código fuente. El bundle es el artefacto de compilación. El PNG es la imagen de documentación.
A dónde lleva esto para el codegen multi-objetivo
El contexto estructurado permite un flujo de trabajo que el contexto de píxeles no puede: un diseño, múltiples objetivos. El mismo IR puede alimentar un generador React/Tailwind, un generador Jetpack Compose y un generador SwiftUI. El diseño subyacente es el mismo; el contexto específico del objetivo (primitivas del framework, convenciones de nomenclatura, APIs de layout) vive en CONTEXT.md, que se genera por objetivo.
Este es el codegen multi-objetivo que realmente escala. Exportas un bundle desde el diseño. Ejecutas tres agentes con tres archivos CONTEXT.md diferentes. Obtienes tres implementaciones que son estructuralmente equivalentes porque fueron generadas desde el mismo IR, no desde tres pases de inferencia separados sobre tres capturas de pantalla.
El cuello de botella para este flujo de trabajo no es la capacidad del modelo. Es la calidad del contexto. El contexto estructurado es lo que lo hace posible.
Exporta tu bundle de contexto estructurado desde la app principal de figmascope, luego úsalo con Cursor, Claude Code o Aider para generación de UI multi-objetivo y componible.