Figma anunció que los agentes de IA pueden escribir directamente en el canvas mediante MCP. Un agente crea componentes, aplica variables y edita frames usando el design system existente. Claude Code, Codex, Copilot, Cursor y otros clientes participan a través del protocolo abierto.
Las skills asociadas son archivos Markdown que describen cómo debe actuar el agente dentro de Figma. El equipo expresa reglas de nombres, componentes, tokens y composición sin crear un plugin. La calidad depende menos de un prompt genérico y más de la estructura de la biblioteca y de la claridad de esas instrucciones.
Esto cambia el handoff porque el archivo de Figma se vuelve una superficie compartida. Desarrollo puede pedir un flujo de settings y recibir frames editables construidos con recursos conocidos. Diseño revisa el mismo artefato. El agente reduce transcripción; las personas todavía deciden estados, comportamientos y excepciones.
Sin biblioteca el agente dibuja fuera del sistema
use_figma opera con componentes y variables que ya están en el archivo. Si la biblioteca es un conjunto de frames sueltos, el agente monta más frames sueltos. Si hay tokens de color, spacing, tipografía y componentes con auto layout, el output tiene dónde encajar. Figma lo describe sin rodeos: el contexto de design system es lo que separa una pantalla genérica de una pantalla de la marca.
Code Connect y la syntax de variables en Dev Mode refuerzan el mismo punto desde el otro lado. Un agente que genera código a partir del frame necesita el mapeo. Un agente que genera un frame a partir de un pedido necesita la biblioteca. Los dos lados pobres producen UI que nadie quiere mantener.
Antes de encender el MCP para todo el equipo, haz un inventario corto: qué componentes cubren los flujos que más se piden, qué variantes existen de verdad, qué variables usa el archivo, qué sigue siendo texto suelto fingiendo token. Un agujero en el inventario se vuelve retrabajo, no "creatividad del modelo".
Los equipos sin design system pueden usar el agente para un bootstrap. El riesgo es publicar el bootstrap como si fuera sistema. Trata la primera tanda como borrador para que humanos nombren, recorten y conecten al código.
Las skills describen el rito; la revisión cierra el archivo
Una skill es Markdown. Cualquier persona del equipo puede escribir una. Eso baja la barrera y reparte regla informal. Sin dueño, cada squad manda al agente por un /figma-generate-design distinto, con nomenclatura en conflicto. El archivo se vuelve un campo de variantes que el DS no reconoce.
La skill base /figma-use enseña al agente a circular por el canvas. Las otras (generar biblioteca a partir de código, generar pantalla a partir de componentes, aplicar spacing, sincronizar token) son flujos. El equipo elige cuáles entran en el repositorio de skills y quién aprueba un cambio. El mismo cuidado que un linter: una regla sin mantenimiento se vuelve ruido.
La auto-comprobación con screenshot ayuda al modelo a iterar. No dispensa la revisión. El spacing jerárquico puede incluso quedar aceptable; el estado vacío, el error, el permiso, i18n y el contenido real casi nunca nacen bien en el primer paso. Diseño mira el archivo. Accesibilidad mira el nombre de capa y el contraste. Producto mira si ese flujo existe.
La skill puede pedir al agente que pare después de N frames y liste lo que inventó. Ese informe es más útil que un archivo lleno. Inventar sin lista es deuda.
Permiso de escritura en el canvas en esta fase beta
Figma avisó: beta, gratis ahora, cobrado por uso después. MCP hereda la seguridad de la cuenta. Aun así, un agente con use_figma escribe en el archivo que el equipo trata como fuente. Sin control de quién conecta el cliente (Claude Code, Codex, Copilot, Cursor, Warp), el canvas gana autores que no aparecen en el rito de critique.
Define un archivo o una página sandbox para el agente. El DS de producción (biblioteca publicada, team library) queda en modo lectura hasta que el flujo demuestre que el agente reutiliza componente en vez de duplicar. Duplicar es el defecto caro: el sistema pierde adopción y el código pierde mapeo.
El cobro por uso cambia la cuenta cuando acabe la beta. Mientras es gratis, el hábito se forma más rápido que la disciplina de sandbox. Un equipo que deja al agente escribir en todo archivo va a tener que desaprender cuando llegue el precio. Mejor tener ya la página-sandbox y el allowlist de clientes MCP.
La paridad con la Plugin API todavía no es un objetivo cumplido. Imagen y fuente custom están en la lista de expansión. Los flujos que dependen de eso hoy fallan de un modo opaco. No le prometas a diseño que "el agente hace lo que hace el plugin".
El frame compartido altera el handoff
Handoff clásico: diseño cierra, desarrollo implementa, el archivo envejece. Con un agente en los dos lados, desarrollo pide un flujo de settings y recibe frames editables en el mismo archivo en el que diseño ya trabaja. Eso reduce transcripción. También mezcla autoría. Sin una convención de página ("agente / humano / listo para build"), nadie sabe qué está estable.
Una convención mínima: página o sección con prefijo, estado en el nombre del frame, y regla de no publicar la library a partir de lo que el agente generó ese día. Diseño revisa, promueve, y ahí el componente entra al sistema. El agente puede seguir editando el borrador.
La ganancia de tiempo aparece en pantallas que el sistema ya cubre: settings, lista, formulario, empty state estándar. Desaparece en un flujo inédito, en marketing, en ilustración, en motion. Ahí el canvas abierto todavía ayuda a explorar, pero el criterio de listo sigue siendo humano y lento, como debe.
Stitch y los generadores aislados producen UI fuera del archivo. Aquí el artefacto ya nace donde el equipo discute. Esa es la diferencia operativa. Solo vale si el equipo de hecho abre el archivo después, en vez de mergear el frame al producto sin pasar por diseño.
Qué dejar fuera de la primera semana de uso
En la primera semana, no pidas rebrand, no pidas 72 variantes de un botón encima de la library publicada, no pidas al agente que "alinee toda la app al DS". Pide un flujo conocido, en un archivo sandbox, con la skill de generar diseño a partir de componentes existentes. Mide: cuántos componentes reutilizó, cuántos creó, cuánto reescribió diseño, cuánto tardó hasta el critique.
Si la tasa de reescritura es alta, el problema es la biblioteca o la skill, no el modelo. Ajusta tokens, nombres, reglas de composición. Solo entonces ábrelo a más personas. Abrir pronto a todo el equipo, con MCP encendido en archivos de producción, genera volumen que nadie revisa.
La accesibilidad no llega de regalo. Hay una skill comunitaria de spec de lector de pantalla; no sustituye una prueba. Si el agente nombra una capa "Frame 12" y el contraste falla, el canvas se volvió más rápido y el producto peor. Incluye en el criterio de listo el mismo checklist de siempre: foco, nombre accesible, estado de error, texto verdadero.
La apuesta de Figma (canvas como plataforma, skills como documentación ejecutable) solo retribuye al equipo que ya escribía la regla. Para los demás, el MCP hace visible la ausencia. Vale el experimento de una semana si el criterio de listo está escrito antes de abrir el archivo de producción.
Si tu empresa está evaluando algo parecido, escríbeme por LinkedIn o por WhatsApp.
