Los equipos de software han pasado décadas construyendo determinismo en sus cadenas de herramientas. Lockfiles para gestores de paquetes. Imágenes base fijadas para contenedores. Builds reproducibles para artefactos compilados. El principio está bien entendido: las mismas entradas deben producir las mismas salidas, siempre, en cualquier máquina, en cualquier momento.

El handoff de diseño nunca ha aplicado este principio. Ha sido, por defecto, un proceso fundamentalmente humano y por tanto no determinista. Un diseñador explica el diseño a un desarrollador. El desarrollador lo interpreta. La interpretación varía según la persona, el día, cuán claramente se escribió el comentario de Zeplin. No puedes reproducirlo. No puedes probarlo. No puedes hacer diff de él.

En un mundo de agentes de codificación de IA, el handoff no determinista es ahora un problema de ingeniería de primer orden. figmascope lo aborda con un bundle de contexto congelado y portátil.

Por qué las herramientas actuales son no deterministas para los agentes

Zeplin y Avocode te dan números extraídos de Figma — dimensiones de capas, valores de color, tamaños de fuente. Pero los sirven como una UI navegable, no como un artefacto legible por máquina. Un agente apuntado a Zeplin tiene que navegar una UI para encontrar los valores, lo cual es frágil, con límite de velocidad y dependiente de cómo se escribieron las anotaciones.

Figma Dev Mode va más lejos: te da fragmentos de código generados en línea desde el diseño. Pero los fragmentos son sin estado — regenerados bajo demanda, no versionados. No hay ningún bundle que puedas hacer commit. No hay ningún archivo que puedas hacer diff. Si el diseñador actualiza el diseño, la vista de Dev Mode se actualiza silenciosamente. No sabes cuándo cambió el diseño subyacente en relación con lo que exportaste por última vez.

Las capturas de pantalla son el peor caso: datos de píxeles puros, completamente no deterministas de analizar, produciendo inferencias de estructura diferentes cada vez.

Las conexiones MCP en vivo — herramientas que dan a los agentes acceso API en tiempo real al archivo Figma — son no deterministas por definición. El archivo cambia mientras el agente lo lee. La ejecución del agente a las 9am y su ejecución a las 2pm ven entradas diferentes. No puedes reproducir la ejecución de las 9am porque la fuente ha cambiado.

Los agentes son sistemas probabilísticos. Darles entradas no deterministas no solo produce varianza — hace que el sistema sea no testeable. No puedes saber si una salida mala fue causada por el modelo, el prompt o el hecho de que alguien movió una capa entre ejecuciones.

El bundle como unidad de compilación

El modelo mental correcto para una exportación de figmascope es un artefacto de compilación. Igual que un compilador toma código fuente y produce un binario determinista — misma fuente, mismos flags, mismo binario — figmascope toma un estado de archivo Figma y produce un bundle determinista: mismo estado del archivo, mismo bundle, siempre.

El bundle es una instantánea congelada. Captura una versión específica del diseño y serializa cada propiedad relevante: layout espacial, identidad de componentes, enlaces de tokens, contenido de cadenas, jerarquía. Una vez exportado, el bundle es inmutable. El archivo Figma puede cambiar; el bundle no. Si quieres incorporar esos cambios, vuelves a exportar y obtienes un nuevo bundle.

Este es el modelo de unidad de compilación. El archivo de diseño es la fuente. El bundle es el artefacto. Los agentes consumen artefactos, no fuentes.

Cuatro propiedades de un handoff determinista

Capturables en instantánea. El artefacto de handoff debe representar un punto específico en el tiempo. No "el estado actual del archivo Figma" — una exportación nombrada y versionada. Los bundles de figmascope llevan un _meta.json con una marca de tiempo de exportación y una huella digital de lo que se incluyó. El bundle es una instantánea, no una vista en vivo.

Portátiles. El artefacto debe ser autónomo. Sin dependencias de servicios externos, APIs en vivo o sesiones con sesión iniciada. Un bundle de figmascope es un ZIP de archivos planos — JSON, Markdown, PNG. Puedes copiarlo, enviarlo por correo, hacer commit en git, adjuntarlo a un PR, entregarlo a un desarrollador junior o a un agente de codificación sin configuración.

Inspeccionables. Un artefacto determinista es inútil si no puedes verificar qué hay en él. Cada archivo del bundle es legible por humanos. CONTEXT.md es Markdown. tokens.json es una estructura similar a W3C. El IR por pantalla es JSON con nombres de campo claros. Un ingeniero puede abrir el bundle y auditar exactamente qué se le dijo al agente. Esto es cualitativamente diferente de "pegué la captura de pantalla y obtuve algo de código."

Reproducibles. Dado el mismo estado del archivo Figma, dos exportaciones separadas deberían producir bundles funcionalmente equivalentes. No idénticos byte a byte (las marcas de tiempo difieren), pero semánticamente idénticos: mismas estructuras de nodos, mismos valores de tokens, mismo inventario de componentes. Si exportas dos veces desde un archivo sin cambios y los bundles difieren semánticamente, algo está mal. Esta propiedad te permite validar tu pipeline de exportación y detectar regresiones en el propio extractor.

Cómo se desarrolla esto en la práctica

Un diseñador termina un sprint de pantallas. Exporta un bundle. El bundle se hace commit en el repositorio junto con el ticket — o adjunto al issue de Jira, o en la unidad compartida, según tu flujo de trabajo. En este punto, el artefacto de handoff está fijado. El agente (o el desarrollador) trabaja desde el bundle, no desde el archivo Figma en vivo.

A mitad de la implementación, el diseñador actualiza tres pantallas. Sin problema: el bundle de trabajo del desarrollador está sin cambios. Las nuevas pantallas obtienen una nueva exportación. Ahora tienes dos bundles y puedes hacer diff de ellos: qué cambió entre el diseño con el que el desarrollador comenzó y el diseño actual. Esto es exactamente el tipo de visibilidad de cambios que es imposible con flujos de trabajo basados en capturas de pantalla o conexiones en vivo.

En un flujo de trabajo multi-agente — un agente construye la biblioteca de componentes, otro construye los layouts de pantalla, un tercero escribe los tests — cada agente recibe el mismo bundle como fuente de verdad. Todos trabajan desde el mismo estado de diseño congelado. Sus salidas son componibles porque sus entradas son compartidas y fijadas. Esta es la condición previa para la generación de UI multi-agente que sea realmente fiable.

Hacer diff de bundles

Porque el bundle son archivos planos, hace diff como código. Dos exportaciones del mismo archivo en dos versiones de Figma te dan un diff JSON que te dice exactamente qué cambió:

Esta es la visibilidad de cambios de diseño que no existe en ninguna herramienta de handoff actual. Figma tiene su propio historial de versiones, pero es visual y orientado al diseñador. Un diff de bundle está estructurado y orientado al desarrollador: datos de cambio legibles por máquina que pueden impulsar tests automatizados, actualizar changelogs o desencadenar flujos de trabajo de CI.

CI/CD para el handoff de diseño

Una vez que el handoff es determinista, el CI/CD sigue naturalmente. Puedes escribir tests que se ejecuten contra un bundle: "esta pantalla debe incluir un componente Button/Primary", "este token debe estar vinculado y no ser un valor codificado directamente", "esta cadena debe tener una clave stringRef". Estas son verificaciones de análisis estático contra datos estructurados. Se ejecutan en milisegundos. Se ejecutan en un pipeline.

También puedes validar la salida del agente de codegen contra el bundle que se le dio. ¿Usó el agente los tokens o codificó literales directamente? ¿Generó el número correcto de instancias del componente repetido? ¿Usó los valores de espaciado correctos? Estas preguntas tienen respuesta cuando la fuente de verdad es un archivo estructurado, no un PNG.

La comparación con MCP

Las conexiones en vivo estilo MCP a Figma están ganando tracción. El atractivo es obvio: el agente siempre ve el diseño más reciente, sin paso de exportación, sin gestión manual de bundles. Pero las conexiones en vivo intercambian determinismo por conveniencia — y para los agentes de IA ese intercambio es malo.

Las conexiones en vivo significan: el contexto del agente depende de cuándo se ejecuta. Una ejecución a las 9am y una ejecución a las 2pm ven datos diferentes si el diseñador trabajó durante el día. No puedes reproducir la ejecución anterior. No puedes probar contra una entrada fija. No puedes auditar qué se le dijo al agente. Si el código generado es incorrecto, no puedes distinguir "el modelo hizo una mala inferencia" de "el diseño cambió bajo el agente."

El modelo correcto es: conexiones en vivo para la exploración e iteración de diseño (donde importa la actualidad), bundles deterministas para el handoff y la generación (donde importa la reproducibilidad). No están compitiendo — operan en diferentes puntos del flujo de trabajo.

Entregar a un desarrollador junior

Las mismas propiedades que hacen que los bundles sean buenos para los agentes de IA los hacen buenos para los desarrolladores humanos que son nuevos en una base de código. Un desarrollador junior al que se le entrega un bundle tiene: la especificación completa en CONTEXT.md, todos los valores de tokens en tokens.json, cada componente listado con sus propiedades, cada cadena con su identidad. No necesitan estar en el archivo Figma. No necesitan una cuenta de Figma. No necesitan saber cuál pantalla es la autoritativa.

El bundle es una orden de trabajo completa y autónoma. Lo mismo que recibiría un agente. La única diferencia es que el humano lo lee y el agente lo procesa programáticamente — pero el artefacto es idéntico.

Esa unificación — mismo artefacto, consumidor humano o agente — es el punto. El bundle es la unidad de handoff. Todo lo demás es detalle de implementación.

Ve el handoff determinista en práctica con Claude Code, Cursor o Aider. Todos comienzan desde la misma exportación de figmascope.