Este es el flujo de trabajo que se ha convertido en el predeterminado en todos los equipos de diseño-a-código ahora mismo: exportar un frame de Figma, pegar el PNG en Claude o Cursor, escribir "construye esto" e iterar desde la salida alucinada. Funciona lo suficientemente bien como para sentirse productivo. No funciona lo suficientemente bien como para publicar desde ahí.

Este no es un problema de capacidad del modelo. Es un problema de entrada. La captura de pantalla es la peor representación posible de un diseño de Figma para que un LLM razone sobre ella — y es casi universalmente lo que los equipos buscan primero. El bundle de contexto de figmascope es la alternativa estructurada.

La jerarquía ha desaparecido

Un archivo de Figma es un árbol. Los frames contienen grupos de auto-layout, que contienen instancias de componentes, que contienen capas de texto y relleno. Ese árbol codifica la intención de layout: esta fila es un contenedor flex, esta tarjeta es una caja con padding, estos tres elementos son hermanos con 16px de separación entre ellos.

Una captura de pantalla colapsa ese árbol a una cuadrícula de píxeles. El LLM ve formas y colores. No ve la estructura de layout — la infiere. Y la inferencia es con pérdida en ambas direcciones: el modelo puede reconstruir estructura que parece correcta visualmente pero es semánticamente incorrecta (un div de ancho fijo en lugar de un hijo flex, posicionamiento absoluto en lugar de auto-layout), o puede ver ambigüedad estructural y elegir una arbitrariamente.

No puedes saber desde un PNG si una fila horizontal de elementos está implementada con display: flex, CSS Grid, un HStack personalizado o tres divs absolutamente posicionados. Son visualmente idénticos. El LLM elige uno. La elección cambia entre ejecuciones.

La semántica no sobrevive a la rasterización

El LLM puede ver que un rectángulo con esquinas redondeadas contiene algo de texto y un icono. Lo que no puede ver:

La semántica en Figma vive en el árbol de capas: nombres de componentes, propiedades de variantes, tipos de nodos. Un componente Button/Primary/Large está explícitamente tipado. En una captura de pantalla, es un rectángulo redondeado con una sombra y una etiqueta. El modelo adivina "esto es probablemente un botón" correctamente la mayoría de las veces — y luego adivina "esto es probablemente la variante primaria" basándose en el color, que puede o no coincidir con el nombrado real de tu sistema de diseño.

Las pequeñas discrepancias se acumulan. Un botón ghost renderizado como un botón con borde. Un tooltip renderizado como un disparador modal. Un estado deshabilitado renderizado como activo. Cada uno de estos está a un paso de inferencia de captura de pantalla de la fuente de verdad.

Los sistemas de espaciado no se resuelven a números

Mira una captura de pantalla de una tarjeta con padding. ¿Cuánto es el padding? No puedes saberlo sin medir píxeles, conocer la escala del lienzo, conocer la resolución de exportación y hacer los cálculos. El LLM hace los cálculos mal — estima, redondea y no tiene forma de saber si tu sistema de espaciado usa una cuadrícula base de 8px o 4px o algo personalizado.

Entonces adivina. Genera padding: 12px cuando el diseño dice 16. Genera gap: 8px cuando el diseño dice 12. Estos números parecen plausibles de forma aislada pero están equivocados — y si tu sistema de diseño usa tokens de espaciado como spacing.md o Spacing/400, el LLM no sabe nada de ellos. Hardcodea literales que se desviarán de tu sistema en el momento en que algo cambie.

El LLM no está alucinando. Está haciendo exactamente lo que harías con solo una captura de pantalla: adivinando. Solo te sorprendes cuando las suposiciones son incorrectas porque podías ver la respuesta correcta en el archivo de Figma todo el tiempo.

Las relaciones de tokens desaparecen

Tu diseñador configuró ese fondo a #7F5CFE. En Figma, ese hex está vinculado a una variable: color/brand/primary. Ese vínculo es significativo — significa que el color participa en los temas, significa que el modo oscuro lo intercambia, significa que si el color de la marca cambia actualizas una variable y cada instancia se actualiza.

En la captura de pantalla: es morado. El LLM genera background-color: #7F5CFE. La relación de token ha desaparecido. Tu base de código ahora tiene un hex hardcodeado que nunca seguirá a tu sistema de diseño. Multiplica esto por cada componente en la pantalla.

Lo mismo aplica a las escalas tipográficas, los radios de borde y las definiciones de sombras. Cada valor en un archivo de Figma bien mantenido es potencialmente un token nombrado. Cada valor en una captura de pantalla es simplemente un número.

La reutilización de componentes es invisible

Una pantalla bien compuesta reutiliza componentes. Las cuatro tarjetas de producto son cuatro instancias del mismo componente ProductCard. El avatar en la navegación y el avatar en el hilo de comentarios son ambas instancias de Avatar/Medium. Esto importa para el código: quieres un componente React, no cuatro variaciones hechas a mano que divergirán.

Desde una captura de pantalla, el LLM ve cuatro rectángulos visualmente similares. Puede generar un componente reutilizable — o puede generar cuatro bloques de JSX casi idénticos porque no notó que eran los mismos. No hay señal en la imagen que le diga cuál es correcto.

El IR que exporta figmascope lleva componentId en cada nodo de instancia. El agente sabe: estos cuatro nodos son todos ProductCard. Generarlo una vez, renderizarlo cuatro veces con diferentes props. Esa es la salida que quieres. Esa es la salida que no puedes obtener de píxeles.

La identidad de cadenas se pierde

Tienes un botón "Continuar" en tres pantallas diferentes. ¿Son esas tres instancias la misma cadena, o las escribió un diseñador independientemente? En un archivo de Figma bien estructurado, referencian la misma clave de cadena. Eso significa una entrada i18n, un cambio se propaga a todas partes.

En tres capturas de pantalla: tres veces el LLM genera una cadena hardcodeada. Si estás construyendo una app internacionalizada, ahora tienes tres cadenas que buscar y reemplazar en lugar de una que buscar. Cosa pequeña. Se acumula en una base de código real.

Por qué el LLM alucina: re-deriva la estructura cada vez

El modelo no tiene memoria de ejecuciones anteriores. Cada vez que pegas la misma captura de pantalla, reconstruye la estructura desde cero. La reconstrucción es probabilística — lo que significa que la misma captura de pantalla + el mismo prompt + el mismo modelo puede producir salidas mediblemente diferentes en diferentes ejecuciones. Mismo diseño, código diferente. Nombres de componentes diferentes, patrones de className diferentes, elecciones de layout diferentes.

Esto no es un error del modelo. Es el comportamiento esperado de un modelo probabilístico dado restricciones insuficientes. La captura de pantalla proporciona restricciones insuficientes. El modelo llena los huecos. Los huecos se llenan de manera diferente cada vez.

Puedes sortear esto parcialmente con prompts más largos y detallados — "usa Tailwind, usa cuadrícula de 8px, usa estos nombres de componentes..." — pero entonces has especificado manualmente la estructura que debería haber estado en el archivo de diseño todo el tiempo. Estás haciendo el trabajo de extracción que debería hacer la herramienta.

El problema de reproducibilidad

Los equipos que usan capturas de pantalla para el handoff de diseño-a-código se topan con el mismo problema: la salida no es reproducible. Dos desarrolladores, la misma captura de pantalla de Figma, hacen prompt a Claude de forma independiente — obtienen estructuras de componentes diferentes, patrones de className diferentes, decisiones de anidamiento diferentes. Ahora tienes dos bases de código que se ven iguales visualmente pero son arquitectónicamente inconsistentes.

Esto hace que la revisión de código sea más difícil. Hace que la refactorización sea más difícil. Hace que la auditoría de cumplimiento del sistema de diseño sea imposible. No puedes hacer diff de "lo que generó el agente desde este diseño" si la respuesta cambia cada ejecución.

El contexto estructurado soluciona la reproducibilidad porque soluciona las entradas. Un bundle de entrada determinista — el mismo JSON con los mismos IDs de nodo, nombres de componentes, valores de tokens y relaciones espaciales — producirá salida mucho más consistente entre ejecuciones, agentes y desarrolladores. No perfectamente determinista: el modelo sigue siendo probabilístico. Pero la varianza cae dramáticamente cuando la estructura está especificada en lugar de inferida.

Lo que una captura de pantalla te da vs. lo que te da el IR

Toma una tarjeta de producto: imagen, título, subtítulo, precio, un botón "Añadir al carrito". Esto es lo que cada entrada le da al agente:

Entrada de captura de pantalla: Un rectángulo con una imagen en la parte superior, dos líneas de texto, un número y un botón. Los colores se infieren. El padding se estima. Si esto es un componente o algo único es desconocido. La variante del botón se infiere del color. El sistema de espaciado es desconocido.

Entrada de IR: Tipo de nodo FRAME, nombre ProductCard, ID de componente vinculado a la definición del componente. Auto-layout con dirección vertical, 16px de gap, 16px de padding horizontal, 12px de padding vertical. Nodos hijo: IMAGE (llena el ancho, altura fija), TEXT con stringRef.key: "product.title" y estilo typography/heading.sm, TEXT con stringRef.key: "product.subtitle" y estilo typography/body.md, TEXT con relleno color/price, INSTANCE de Button/Primary/Medium. Relleno de fondo color/surface.card. Radio de borde radius/card.

El IR le da al agente una especificación. La captura de pantalla le da una sugerencia.

El marco: este es el problema de la documentación

Resolvimos este problema exacto para el código fuente hace décadas. No le das a un agente una captura de pantalla de tu base de código y le pides que razone sobre la arquitectura. Le das el código — la representación estructurada, parseable y semánticamente significativa. El árbol de sintaxis abstracto, no una imagen del editor.

Los diseños de Figma son datos estructurados. Tienen una estructura de árbol bien definida con nodos tipados y valores nombrados. La API de Figma expone esta estructura completamente. La única razón por la que el flujo de trabajo de captura de pantalla persiste es que extraer la estructura y formatearla como contexto tiene fricción.

Reducir esa fricción es lo que hace figmascope. Pegas la URL de Figma, la exportación corre en tu navegador y obtienes un ZIP con contexto estructurado: CONTEXT.md, tokens.json, IR por pantalla, inventario de componentes, manifiesto de cadenas. Todo lo que el agente necesita, nada de ello inferido de píxeles.

Mantén las capturas de pantalla para confirmación visual — el bundle incluye PNGs 2x exactamente para eso. Usa la estructura para todo lo demás. Véalo en práctica: flujo de trabajo con Cursor, flujo de trabajo con Claude Code o flujo de trabajo con Aider.