Código de Figma con IA: qué se publica y qué se reescribe en 2026

El código que una IA genera desde Figma es el markup que un agente o un plugin escribe a partir de un frame. Reproduce el layout y los textos de la pantalla. Deja fuera casi todo lo que hace falta para publicar un componente sin riesgo: los tokens, los estados, la semántica y la conexión con los componentes que el código ya tiene.

La pregunta afecta a cualquier equipo con un design system que tenga que decidir cuánto fiarse de estas herramientas en 2026. En una captura el resultado parece terminado, y ahí está la trampa. A continuación comparamos, punto por punto, lo que generan las herramientas y lo que necesita el código de producción, a partir de la documentación de Figma y de la investigación publicada hasta ahora.

En pocas palabras: la estructura se queda, el estilo se reescribe, los elementos pasan a ser componentes de tu librería y cada estado se escribe a mano. El código generado es un primer borrador rápido del layout. Como primer borrador de un componente, vale poco.

¿Qué contiene de verdad el código generado desde Figma?

Lo producen tres tipos de herramientas. Los agentes conectados al servidor MCP de Figma leen el archivo directamente. Los plugins de exportación convierten el frame seleccionado en React, Vue o HTML. Los modelos screenshot-to-code trabajan con una imagen de la pantalla y no ven el archivo.

El servidor MCP de Figma es el más claro sobre lo que devuelve. Su herramienta principal, get_design_context, le da al agente una representación estructurada en React y Tailwind de la selección, y la guía de Figma pide tratarla como una representación del diseño y del comportamiento, no como el estilo final del código. Una segunda herramienta, get_variable_defs, enumera las variables que usa la selección, para que el agente pueda referirse a los tokens en lugar de a valores sueltos. Las dos solo llevan lo que hay en el archivo. Un frame sin variables ni auto layout le entrega al agente códigos hexadecimales y posiciones absolutas.

El screenshot-to-code parte con menos. El benchmark Design2Code puso a prueba modelos multimodales con 484 páginas web reales: se quedan atrás sobre todo en dos puntos, recoger todos los elementos visuales de la página y reconstruir bien el layout. Una captura no tiene nombres de capas, variables ni límites de componentes, y el modelo tiene que deducir las tres cosas.

Código generado frente a código publicado, punto por punto

La distancia se ve mejor aspecto a aspecto. A la izquierda, lo que suele salir de un archivo de Figma bien estructurado a través de un agente o un plugin. A la derecha, lo que necesita esa misma pantalla antes del merge.

Dónde el código generado se puede quedar

Una parte pasa la revisión casi intacta, y es justo la que antes costaba más teclear.

• El anidamiento. Si el archivo usa auto layout con gap, padding y dirección definidos, la estructura flex que se deduce suele ser correcta. La guía del MCP señala el auto layout como la forma de comunicar la intención responsive precisamente por eso.
• Los textos y su orden. Títulos, etiquetas y párrafos llegan tal como se escribieron, en orden de lectura.
• Las secciones únicas. Una franja de marketing que aparece una sola vez, sin estados ni datos, se publica casi como se generó, una vez cambiados los valores por tokens.
• Los prototipos. Una pantalla hecha para probar una idea con cinco usuarios no necesita estados de focus ni escala tipográfica. Con el código generado basta.

Dónde el código generado se reescribe

Tokens y valores sueltos

Un agente solo usa un token como color.surface.raised si el frame usaba esa variable. Cada capa rellena con un color elegido a ojo sale como un hexadecimal, y cada espaciado ajustado arrastrando sale como un valor en píxeles. La revisión de código se convierte en una caza de números. Explicamos por qué los tokens son una decisión aparte en design tokens, variables CSS y Tailwind.

Componentes

Sin un mapeo, el agente reconstruye cada botón a partir de sus rectángulos y su etiqueta. Sobre Code Connect, la guía de Figma es tajante: sin él, el modelo va a ciegas. Incluso con el mapeo, el agente elige las props según lo que ve, y un componente con una API demasiado abierta invita a combinaciones erróneas. Unas props acotadas, como en nuestras seis reglas, reducen ese margen de error.

Estados

Un frame es un solo momento de un componente. El código generado reproduce ese momento y nada más: ni anillo de focus, ni aspecto deshabilitado, ni camino de carga o de error. En los estados vive la mayoría de los bugs de interfaz, y ninguna herramienta genera un estado que nadie dibujó.

Semántica y accesibilidad

Es la distancia que no ven las comprobaciones automáticas. Un estudio presentado en CHI 2026 por Calo, Gurita y De Russis generó 300 interfaces web con tres modelos comerciales y encontró 541 infracciones de accesibilidad semántica de seis tipos, unas 1,8 por interfaz: alt text que no describe nada, enlaces de propósito poco claro, encabezados que no encajan con su contenido. Una imagen con alt="image" pasa cualquier comprobación automática. Una comparación entre código web escrito por LLM y por personas muestra que los modelos resuelven bien el contraste y el alt text y tropiezan con los atributos ARIA. Antes de publicarse, una interfaz generada necesita a una persona con un lector de pantalla.

Comportamiento responsive

Casi todos los frames se dibujan a uno o dos anchos. El código sigue esos anchos y adivina el resto: las cadenas traducidas largas, las imágenes que faltan y las listas vacías son las primeras en delatarlo.

Por qué el último tramo cuesta más que el primero

Addy Osmani lo llama el problema del 70%: la IA te lleva deprisa casi hasta el final, y lo que queda lleva más tiempo que ese primer 70%. Añade que mejores prompts, especificaciones y contexto suben la cifra quizá al 80-85 por ciento, y a partir de ahí se gana cada vez menos. Del diseño al código la curva es la misma. Lo que cubren las herramientas es la parte visible: cajas, espaciados, textos. Lo que queda para las personas es la parte invisible: tokens, estados, semántica, comportamiento. Hay que leerla línea a línea, porque en el navegador parece correcta hasta que alguien la recorre con el teclado.

En la práctica, el coste cambia de sitio. El código generado ahorra tecleo y añade revisión. Quien lo publica tal cual lo paga después, con el component drift: tres botones ligeramente distintos, cada uno correcto el día en que salió.

Cómo lo usamos

Para nosotros el código generado es una especificación del layout, nunca código para fusionar. La secuencia en un proyecto con design system:

1. Una sección cada vez. Una card, un header, un formulario. Con selecciones más pequeñas el agente tiene menos que adivinar. La configuración está en nuestra guía del traspaso con Figma MCP.
2. Primero, los componentes existentes. Las instrucciones del agente nombran la librería de componentes y prohíben markup nuevo para todo lo que ya cubre, como en nuestras reglas de gobernanza para agentes.
3. Ningún valor suelto. Una regla de lint rompe la build si encuentra un hexadecimal o un valor en píxeles fuera de los archivos de tokens.
4. Los estados se escriben a mano, a partir del contrato del componente y no del frame.
5. La semántica se comprueba de oído. Primero las auditorías automáticas, después una pasada con teclado y lector de pantalla en cada pantalla nueva.

El tiempo que se ahorra en los dos primeros pasos es real. En los pasos tres a cinco se van las horas, y ahí se decide la calidad del producto final.

Cómo evaluar una herramienta antes de adoptarla

Las demos de los proveedores usan archivos limpios y un solo estado. Una prueba más justa lleva una tarde. Elige una pantalla real del producto con al menos tres estados y un formulario. Genérala con la herramienta. Después cuenta cuatro cosas en el resultado: valores sueltos que deberían ser tokens, elementos que duplican un componente existente, estados que faltan y fallos semánticos detectados con un lector de pantalla. Por último, mide cuánto tarda ese código en llegar a una pull request aprobada.

Esa última cifra es la que cuenta. Una herramienta que en un minuto saca una pantalla idéntica al píxel y luego exige un día de arreglos ahorra menos que otra que saca una pantalla más tosca pero hecha con los componentes correctos. Repite la prueba después de mejorar el archivo de Figma: la puntuación suele moverse más con el archivo que con la herramienta.