Las funciones de Figma Agent interponen reglas de diseño entre la IA y el lienzo
Figma presentó nuevas funciones de Figma agent que ofrecen a los equipos un mayor control sobre los resultados de la IA, pese al comportamiento impredecible de esta tecnología. El lanzamiento conecta a los agentes con especificaciones escritas, bibliotecas de diseño, fuentes de código y prototipos funcionales dentro de la misma plataforma.
Esto es más que otro asistente adquiriendo más comandos. Figma intenta definir el entorno operativo que rodea a los agentes antes de que las interfaces generadas se propaguen por los equipos de producto. Su apuesta es que el contexto compartido, el trabajo visible y las reglas de diseño aplicables importan más que la generación sin restricciones.
Esta posición sitúa a Figma entre los diseñadores y agentes externos de programación como Claude Code, Codex, GitHub Copilot y Cursor. En lugar de competir únicamente por el rendimiento de los modelos, Figma quiere que su lienzo se convierta en el plano de control donde los equipos deciden qué deben construir los agentes.
Las nuevas funciones de Figma Agent definen las reglas antes de la generación
Figma está trasladando el control de los agentes de los prompts individuales a una infraestructura de producto compartida.
La empresa anunció el flujo de trabajo ampliado durante su primer evento Config en India. La incorporación central es Figma Specs, un espacio de trabajo basado en Markdown para registrar requisitos de producto, decisiones, referencias y contexto técnico.
Una especificación puede existir como un archivo propio de Figma o junto al trabajo en el lienzo. Los equipos pueden hacer referencia a diseños, diagramas de FigJam, capas de código y otros materiales sin reducirlo todo a texto desvinculado.
Esa estructura importa porque un agente rara vez falla únicamente por una generación de lenguaje deficiente. A menudo carece de las relaciones entre un requisito, un componente visual, una implementación de código y una decisión previa del equipo.
Un archivo Markdown convencional puede describir esas relaciones, pero no las conserva automáticamente. Los enlaces quedan obsoletos, las imágenes pierden contexto y distintos archivos pueden presentar instrucciones contradictorias.
Figma Specs está diseñado para hacer nativas esas conexiones. Según la visión general del lanzamiento, los equipos pueden convertir ideas preliminares en especificaciones detalladas y enviarlas a agentes de programación mediante el servidor MCP de Figma.
Model Context Protocol, o MCP, es un estándar que permite a los sistemas de IA conectarse con herramientas externas y contexto estructurado. En la implementación de Figma, puede mover información de producto entre el lienzo y agentes de desarrollo compatibles.
El flujo de trabajo comienza antes de que un agente escriba código. Un equipo puede reunir requisitos, diagramas, referencias de diseño y contexto de código dentro de una especificación, y después usar ese material durante la generación.
El mismo contexto puede respaldar una capa de código, que es un prototipo interactivo sustentado por código en ejecución en el lienzo de Figma. Esto permite inspeccionar el prototipo junto a los diseños y decisiones que lo produjeron.
Figma también amplió la información disponible mediante los sistemas de diseño. Los equipos pueden añadir directrices escritas a bibliotecas publicadas y conectar fuentes de código desde repositorios de GitHub o paquetes de npm.
Las directrices pueden documentar reglas, patrones preferidos, tratamientos prohibidos y detalles de implementación. Los agentes pueden leer ese material cuando una biblioteca relevante está habilitada.
Las fuentes de código añaden otra capa de fundamentación. Dan a un agente acceso a componentes implementados, en lugar de obligarlo a inferir cada elemento de la interfaz a partir de capturas de pantalla o marcos visuales.
Esta combinación crea una jerarquía de contexto. Las especificaciones describen lo que un equipo pretende construir, las bibliotecas de diseño definen su lenguaje visual y las fuentes de código muestran cómo funcionan los elementos en el software.
El anuncio de los agentes también destacó la gestión centralizada de bibliotecas de diseño, bibliotecas de código y directrices. Figma afirma que los agentes pueden consultar este sistema al crear o editar trabajo.
Estos controles abordan un problema recurrente de las interfaces generativas. Un modelo puede producir una pantalla convincente y, aun así, ignorar las reglas de componentes, los patrones de interacción o las prácticas de accesibilidad de la organización.
Un resultado pulido no es necesariamente un resultado válido para el producto. Puede parecer correcto mientras crea componentes duplicados, estados no compatibles o trabajo de implementación que los desarrolladores deberán reemplazar más adelante.
La respuesta de Figma no es eliminar los prompts. Es rodearlos de contexto duradero que pertenezca al equipo, no a la persona que inicia un chat.
Eso cambia el papel del propio prompt. Se convierte en una solicitud dentro de un espacio de trabajo gobernado, no en la única instrucción entre un agente y el producto.
Las capas de código de Figma llevan software en ejecución al lienzo
Las capas de código de Figma convierten el lienzo en un lugar para probar comportamientos, no solo para revisar representaciones visuales.
Las capas de código pasaron de beta cerrada a beta abierta como parte del lanzamiento. Figma afirma que la función se está implementando gradualmente en sus planes, aunque las cuentas individuales pueden recibir acceso en distintos momentos.
Una capa de código contiene una interfaz funcional respaldada por código en ejecución. Los equipos pueden colocarla junto a marcos de diseño convencionales, duplicarla, probar diferentes direcciones e inspeccionar estados interactivos.
La distinción es importante. Los prototipos tradicionales pueden simular un recorrido mediante marcos vinculados, pero quizá no representen el comportamiento de un componente real.
Una implementación en ejecución puede exponer comportamientos de carga, estados vacíos, errores, diseños adaptativos e interacciones complejas. Estos detalles suelen revelar preguntas de producto que las pantallas estáticas dejan sin resolver.
La guía de capas de código describe varios puntos de partida. Los usuarios pueden generar una capa mediante Figma agent, convertir un diseño, importar código o comenzar desde una base de código existente del equipo.
Un diseñador podría seleccionar un flujo de pago establecido y pedir al agente que añada una opción de entrega alternativa. La capa de código resultante podría mostrar comportamientos de validación, carga, éxito y error.
El equipo podría entonces duplicar esa versión y probar otra interacción junto a ella. Responsables de producto, diseñadores e ingenieros compararían opciones funcionales en un único archivo compartido.
Figma afirma que los cambios pueden volver a la capa de código y, en flujos de trabajo compatibles, a la base de código conectada. Esa promesa sigue siendo más relevante que una simple exportación de diseño a código.
Una exportación suele ser un artefacto de entrega. Una capa de código conectada está concebida para seguir formando parte de un ciclo iterativo entre la exploración de diseño y la implementación.
Figma introdujo por primera vez las capas de código en beta cerrada en junio de 2026. Su anterior vista previa del lienzo admitía importaciones de GitHub, carpetas locales, plantillas, resultados de Figma Make y puntos de partida generados por agentes.
La beta abierta lleva ese modelo a una audiencia más amplia. También plantea una prueba mayor para determinar si la colaboración respaldada por código funciona fuera de equipos cuidadosamente seleccionados.
El caso de uso inmediato no consiste en enviar automáticamente código generado a producción. Consiste en hacer que el código sea lo bastante accesible para usarlo durante el descubrimiento de producto.
La directora de diseño de Figma, Loredana Crisan, describió una brecha creciente entre la creación de código y los lanzamientos reales. Dijo a TechCrunch que las organizaciones producen 17 veces más código, mientras que los lanzamientos solo han aumentado 1,3 veces.
Estas cifras son proporcionadas por la empresa y no deben tratarse como una referencia independiente del sector. Aun así, explican la estrategia detrás de las capas de código de Figma.
El código generado se utiliza cada vez más para explorar posibilidades que nunca llegan a producción. Figma quiere que ese trabajo exploratorio se produzca donde los equipos puedan verlo, debatirlo y perfeccionarlo juntos.
Esto replantea el código: deja de ser un medio de implementación final para convertirse en un material de diseño. Los equipos de producto pueden utilizar software funcional para aclarar qué deben construir antes de comprometerse con una arquitectura de producción.
El enfoque también reconoce que las sesiones de agentes basadas en terminal suelen ser difíciles de compartir. Un desarrollador puede generar varias interfaces rápidamente, pero los colaboradores quizá solo reciban después un enlace o una grabación.
Ese proceso oculta las alternativas, los prompts y las concesiones detrás del resultado. Llevar una versión funcional al lienzo hace visible la exploración y facilita cuestionarla.
Sin embargo, la visibilidad no convierte el código de un prototipo en código listo para producción. Los equipos aún necesitan revisión de ingeniería, pruebas, controles de seguridad, validación de accesibilidad y una arquitectura mantenible.
Por tanto, el valor de las capas de código depende de cómo los equipos clasifiquen sus resultados. Utilizadas como un artefacto exploratorio, pueden acortar los ciclos de retroalimentación sin pretender que los prototipos generados sean software terminado.
La verdadera competencia es el contexto compartido frente a los chats aislados con agentes
Figma apuesta a que el contexto gobernado importará más que el agente que genere el primer borrador más rápido.
El principal rival en esta historia no es otro proveedor de diseño. Es el flujo de trabajo aislado con agentes que sitúa el trabajo de producto dentro de chats privados, terminales o sesiones de navegador desconectadas.
Los agentes de programación ya generan interfaces a partir de texto e imágenes. Su velocidad crea un nuevo problema de coordinación cuando cada participante trabaja con instrucciones y contexto local distintos.
Un diseñador puede adjuntar la biblioteca de componentes más reciente. Un desarrollador puede utilizar una rama de repositorio anterior, mientras que un responsable de producto aporta requisitos copiados de un documento independiente.
Cada agente puede devolver una respuesta plausible. Los resultados aún pueden entrar en conflicto porque los sistemas nunca recibieron la misma fuente de verdad.
Figma Specs intenta reducir esa fragmentación al dar al contexto un hogar visible. Mantiene los requisitos cerca de los diagramas, diseños, capas de código y decisiones a los que hacen referencia.
La ampliación del sistema de diseño aborda un problema relacionado. Figma quiere que los agentes entiendan no solo los componentes disponibles, sino también las reglas que rigen su uso.
Una biblioteca podría contener varias variantes de botones sin explicar cuál corresponde a una acción destructiva. Las directrices pueden aportar esa lógica de decisión que falta.
De manera similar, el acceso a fuentes de código puede mostrar a un agente si un componente ya existe. Eso puede reducir la tentación de generar un reemplazo visualmente similar con un comportamiento incompatible.
El agente existente de Figma ahora admite búsquedas entre archivos, adjuntar contenido de la plataforma, hacer referencia a elementos de bibliotecas y ejecutar varios prompts simultáneamente. Su documentación del agente también distingue entre el agente integrado y los clientes MCP externos.
El agente integrado trabaja directamente en archivos de diseño. Los agentes externos pueden utilizar las capacidades de escritura en el lienzo de Figma para llevar a la plataforma contenido procedente de bases de código u otros proyectos de IA.
Esta distinción permite a Figma admitir varios agentes sin exigir que un solo asistente gestione todas las tareas. La empresa puede seguir siendo la capa compartida bajo un grupo cambiante de modelos y herramientas de desarrollo.
Según la empresa, su compatibilidad con MCP incluye ahora más de 20 socios nuevos. La lista anunciada incluye OpenCode, Dia, Meta Muse y la startup india de IA Sarvam.
Figma ya había citado Claude Code, Codex, GitHub Copilot y Cursor como ejemplos de agentes externos que pueden escribir en archivos. La ampliación del soporte a socios convierte la neutralidad de modelos en parte de la estrategia de la plataforma.
Es una posición defendible porque las clasificaciones de modelos cambian rápidamente. Un equipo puede preferir un agente para el código de interfaz y otro para investigación, documentación o generación de imágenes.
Figma no necesita ganar todas las comparaciones entre modelos si controla el contexto compartido del producto. Necesita que los agentes traten los archivos, las bibliotecas y las reglas de Figma como fuentes de información autorizadas.
La actualización del canvas MCP de la empresa deja explícita esa ambición. Las skills pueden indicar a agentes externos cómo ejecutar flujos de trabajo, secuenciar pasos y seguir las convenciones de los equipos.
Aquí, una skill es un conjunto reutilizable de instrucciones que moldea el comportamiento de un agente. Puede codificar conocimiento operativo que, de otro modo, permanecería dentro del historial de prompts de un solo empleado.
Un equipo de sistemas de diseño podría crear una skill para construir formularios. Las instrucciones podrían exigir componentes de campo aprobados, etiquetas accesibles, estados de validación documentados y tokens de espaciado específicos.
Un agente externo de programación podría aplicar esas reglas al crear o actualizar activos. El canvas de Figma mostraría el trabajo resultante allí donde ya colabora el equipo en general.
Esto se asemeja a una base de conocimiento de ingeniería estructurada, pero el contexto está vinculado directamente a los artefactos del producto. La diferencia está en el punto donde las decisiones se vuelven aplicables.
Por tanto, la competencia emergente gira en torno a la orquestación. Las herramientas de diseño, los editores de código, los repositorios y los sistemas de documentación quieren convertirse en el lugar donde los agentes reciben contexto fiable.
Figma tiene una ventaja porque muchas decisiones de interfaz ya viven en su canvas. Sin embargo, esa ventaja solo se mantiene si la plataforma conserva esas decisiones sincronizadas con el código de producción.
Los agentes predecibles siguen dependiendo de datos de entrada imperfectos
Figma puede restringir el comportamiento de los agentes, pero no puede garantizar que cada regla esté completa, actualizada o se interprete correctamente.
La empresa está introduciendo estos controles porque la IA generativa sigue siendo no determinista. La misma solicitud puede producir estructuras, detalles y decisiones de implementación diferentes entre ejecuciones.
Las directrices pueden reducir esa variabilidad. No pueden eliminarla, especialmente cuando las instrucciones entran en conflicto o no cubren una situación nueva.
Un equipo podría indicar a un agente que use un componente preferido mientras su repositorio conectado contiene dos implementaciones. La biblioteca de diseño puede identificar una versión, pero el código de producción puede depender de otra.
Las especificaciones introducen otra obligación de mantenimiento. Una especificación bien estructurada solo ayuda cuando sus requisitos reflejan las decisiones actuales.
Un contexto desactualizado puede hacer que un agente se equivoque de forma sistemática. Ese fallo es más peligroso que una alucinación evidente porque el resultado puede parecer controlado y fiable.
Los equipos de sistemas de diseño necesitarán reglas de responsabilidad para las instrucciones de los agentes. Deben decidir quién puede publicar directrices, conectar fuentes de código, resolver conflictos y aprobar cambios.
Figma está presentando una gestión centralizada de sistemas de diseño con mapas y comprobaciones del sistema. Estas herramientas pretenden exponer dependencias y carencias, incluidas descripciones o estados de interacción ausentes.
Esa capa administrativa es necesaria porque el acceso de los agentes aumenta las consecuencias de una documentación deficiente del sistema. Antes, un componente no documentado era más difícil de utilizar correctamente para las personas.
Ahora, un agente puede reproducir el malentendido en muchas pantallas en cuestión de minutos. La generación más rápida amplifica tanto los buenos estándares como los descuidados.
El control de acceso plantea otra preocupación. Conectar agentes a diseños, especificaciones, repositorios y servicios externos amplía la superficie que contiene información propietaria del producto.
Figma afirma que la capacidad MCP se beneficia de sus controles de seguridad y fiabilidad. Los equipos empresariales aún deberán revisar permisos, retención de datos, clientes conectados y acceso a repositorios.
La plataforma permite a los administradores desactivar las funciones de IA, pero los controles disponibles pueden ser demasiado amplios para algunas organizaciones. Desactivar las capas de código también puede desactivar otras funciones de IA, según la documentación de soporte de Figma.
Los equipos pueden querer políticas más acotadas según la sensibilidad del proyecto, el repositorio, el proveedor del modelo o el rol de usuario. La eficacia de la gobernanza dependerá de cómo evolucionen esos controles.
La adopción también sigue siendo incierta. Los diseñadores pueden valorar la exploración respaldada por código sin querer mantener instrucciones para agentes ni solucionar problemas con repositorios importados.
Los desarrolladores pueden resistirse a estructuras generadas que parecen convincentes, pero entran en conflicto con una arquitectura establecida. Los responsables de producto pueden crear especificaciones detalladas que se conviertan en otro documento que requiere sincronización.
Las primeras discusiones de usuarios ya han planteado dudas sobre las importaciones de repositorios, los errores de infraestructura y si las funciones de IA distraen de solicitudes de producto pendientes desde hace tiempo. Estas anécdotas no demuestran una calidad de producto generalizada.
Sí muestran lo que debe probar la beta abierta. Figma necesita demostrar que las capas de código funcionan de forma fiable con repositorios reales y las restricciones cotidianas de los equipos.
La plataforma también enfrenta un riesgo conceptual. Combinar requisitos, diseño, código, contenido y controles de agentes puede reducir la fragmentación, pero también puede hacer que Figma sea más complejo.
Un canvas compartido funciona cuando cada participante puede entender el estado relevante sin dominar todos los sistemas subyacentes. Demasiadas superficies superpuestas recrearían el problema de coordinación dentro de un solo producto.
Las afirmaciones de Figma sobre una generación de mayor calidad y alineada con la marca también requieren pruebas independientes. La empresa ha mostrado cómo entra el contexto en el flujo de trabajo, no con qué consistencia los agentes lo siguen.
Los equipos deberían medir los resultados en lugar de darlos por supuestos. Los indicadores útiles incluyen la reutilización de componentes, los defectos de accesibilidad, el retrabajo, el tiempo de revisión y la divergencia entre prototipos y código de producción.
La pregunta central no es si un agente puede generar una pantalla atractiva. Es si esa pantalla resiste el contacto con un sistema de diseño y una base de código reales.
Figma Specs amplía la plataforma más allá de los archivos de diseño
Specs convierte la estrategia de agentes de Figma en una apuesta más amplia por controlar las decisiones de producto antes y después del canvas.
Tradicionalmente, una especificación de producto ha vivido en una herramienta de documentos, un sistema de tickets o un repositorio. Después, el trabajo visual pasaba a Figma, mientras que la implementación técnica se trasladaba a otro lugar.
Cada transición creaba un paso de traducción. Los requisitos podían perder matices, los diseños podían desviarse del comportamiento aprobado y los desarrolladores podían interpretar de forma distinta unas notas de entrega incompletas.
Figma Specs cuestiona esa separación. Trata Markdown como un medio flexible mientras lo integra en la red de artefactos visuales y técnicos de Figma.
Un responsable de producto puede redactar un requisito y hacer referencia a un diagrama de FigJam. Un diseñador puede conectar las pantallas relevantes, mientras que un ingeniero puede añadir contexto de código desde GitHub.
A continuación, un agente puede usar el material combinado para crear una capa de código o transferir la especificación mediante MCP. La especificación se convierte en una entrada activa, en lugar de un documento revisado únicamente por personas.
Esto amplía el flujo de trabajo al que Figma puede dirigirse. La plataforma ya no se limita a crear diseños de interfaz y entregarlos a los equipos de desarrollo.
Quiere participar en la definición de producto, la creación de prototipos, el contexto de implementación y las operaciones de contenido. Cada superficie adicional hace que el contexto compartido sea más valioso para los agentes.
La integración de Payload de Figma refuerza esa dirección. Payload es un sistema de gestión de contenidos headless de código abierto que se unió a Figma en 2025.
La nueva integración conecta Payload con Figma Make, el creador de aplicaciones y sitios web de la plataforma basado en prompts. Los equipos pueden crear experiencias respaldadas por datos y gestionar contenido sin separar el prototipo visual de su modelo de contenido.
Figma afirma que las descargas de Payload se multiplicaron por seis durante los 12 meses anteriores. Es una métrica reportada por la empresa y no revela cuántos proyectos usan la nueva integración.
Aun así, la combinación aborda una limitación práctica de los sitios web generados. Una página pulida resulta menos útil cuando el contenido permanece codificado de forma fija o desconectado de los flujos de publicación.
Payload proporciona almacenamiento de contenido, API, flujos de trabajo y una interfaz administrativa. Figma afirma que los equipos de marketing pueden gestionar contenido mientras los desarrolladores conservan acceso al framework de código abierto.
Esto también acentúa la distinción entre crear para explorar y crear para lanzar. Un prototipo desechable solo necesita suficiente comportamiento para probar una idea.
Un sitio de producción requiere contenido persistente, permisos, estructuras de datos y flujos de trabajo operativos. Integrar un CMS acerca Figma Make a esa segunda categoría.
La empresa procura preservar una vía de salida. Afirma que los equipos pueden sacar de Figma su trabajo basado en Payload, algo importante para los desarrolladores preocupados por la dependencia de la plataforma.
Sin embargo, la portabilidad debe evaluarse mediante proyectos reales. El código exportable no es automáticamente fácil de mantener sin el entorno que lo generó.
La estrategia más amplia presiona varias categorías a la vez. Las herramientas de documentos alojan especificaciones, los agentes de programación generan implementaciones y los creadores de sitios web combinan edición visual con despliegue.
Figma no está sustituyéndolas todas por un único modelo. Está intentando convertirse en el sustrato compartido donde se conectan sus resultados.
Este enfoque encaja con el modelo de colaboración existente de la empresa. Figma se volvió central para los equipos de producto porque los archivos admitían edición multijugador, comentarios, componentes y bibliotecas compartidas.
Los agentes añaden un nuevo tipo de participante. A diferencia de los colaboradores humanos, pueden modificar grandes áreas rápidamente y operar entre herramientas mediante interfaces legibles por máquinas.
Por tanto, la plataforma debe admitir tanto la colaboración como las restricciones. Debe hacer visible el trabajo de los agentes mientras limita hasta dónde puede propagarse una instrucción incorrecta.
Figma Specs, las fuentes de código y las directrices son funciones independientes, pero su valor se acumula cuando se usan juntas. Cada una aborda una parte diferente del problema de contexto.
Las especificaciones explican la intención. Las bibliotecas expresan decisiones de diseño reutilizables, mientras que las fuentes de código fundamentan esas decisiones en la implementación.
Las capas de código proporcionan un lugar ejecutable para probar el resultado. MCP conecta entonces ese proceso con agentes que operan en otros lugares.
Así es como funcionan los agentes de Figma en el modelo emergente de la empresa. No se limitan a recibir un prompt y producir una pantalla.
Operan dentro de una cadena de contexto de producto, reglas compartidas, artefactos de trabajo y revisión humana. La cadena es la estrategia de producto.
Tres señales mostrarán si la estrategia de agentes de Figma funciona
La siguiente prueba es si los flujos de trabajo con agentes gobernados mejoran los resultados reales de los equipos sin añadir otra capa de mantenimiento.
La primera señal es la adopción de las capas de código tras el lanzamiento de la beta abierta. El acceso por sí solo no establecerá su valor.
Los equipos deben crear, duplicar, revisar y perfeccionar repetidamente prototipos funcionales en el canvas. El uso continuado sugeriría que la exploración respaldada por código resuelve un problema real de colaboración.
La evidencia más útil compararía los flujos de trabajo antes y después de la adopción. Ciclos de revisión más cortos, menos revisiones de entrega o una mejor representación de los estados interactivos respaldarían la tesis de Figma.
Las importaciones abandonadas, la ejecución poco fiable o la recreación frecuente en herramientas externas la debilitarían. La beta abierta ofrece a Figma una población mayor para detectar esos problemas.
La segunda señal es si las directrices de diseño y las fuentes de código reducen los errores de los agentes. Los equipos deberían observar una mayor reutilización de componentes aprobados y menos desajustes de marca o implementación.
Las notas de lanzamiento de octubre de Figma confirman que el agente puede leer directrices de bibliotecas, buscar archivos, adjuntar contexto de plataforma y admitir skills personalizadas. Estas capacidades establecen el mecanismo, no el resultado.
La evidencia decisiva procederá del uso repetido en producción. Un sistema exitoso debería ayudar a los agentes a seguir las convenciones sin exigir a los usuarios que las repitan en cada prompt.
También debería hacer visibles los conflictos. Si la biblioteca de diseño y el repositorio de código discrepan, el sistema debe ayudar a los equipos a identificar qué fuente es la autorizada.
De lo contrario, el contexto adicional puede aumentar la ambigüedad. Un agente puede recibir más información y, al mismo tiempo, tener menos certeza sobre qué instrucción seguir.
La tercera señal es cómo evoluciona el soporte para agentes externos. El argumento de plataforma de Figma se fortalece cuando los equipos pueden cambiar de modelos sin reconstruir su contexto de diseño.
El soporte para más clientes MCP genera distribución, pero la compatibilidad debe ir más allá del acceso básico de escritura. Los agentes externos necesitan acceso fiable a componentes, variables, directrices, imágenes y relaciones de código.
Figma ha dicho que está trabajando para lograr una mayor paridad con su Plugin API. El progreso en este ámbito determinará si los agentes externos se convierten en colaboradores plenos o en herramientas de importación limitadas.
La respuesta competitiva también será importante. Los editores de código y las plataformas de desarrollo pueden profundizar sus propias integraciones de diseño, mientras que los sistemas documentales pueden hacer que las especificaciones sean más legibles para los agentes.
Si esas herramientas conservan el contexto sin canalizar el trabajo a través de Figma, los equipos podrían preferir un flujo de trabajo distribuido. Figma debe demostrar que la consolidación produce decisiones más claras, no simplemente una mayor dependencia de la plataforma.
Para los diseñadores, la cuestión práctica es si el lienzo sigue siendo un espacio para el criterio. Los agentes deberían acelerar las variaciones y las ediciones rutinarias sin convertir la revisión de diseño en una limpieza de resultados.
Para los desarrolladores, la cuestión es si las capas de código conservan un contexto de implementación útil. Los prototipos generados deben revelar las compensaciones sin confundirse con código de producción revisado.
Para los responsables de producto, el valor reside en la trazabilidad. Un requisito debería conectarse con el diseño, el prototipo, la fuente de código y la decisión que lo configuró.
Las funciones de agentes de Figma ya proporcionan las piezas para ese flujo de trabajo. Los próximos meses mostrarán si los equipos pueden mantener esas piezas sincronizadas bajo la presión cotidiana.
Trate la beta abierta como un experimento operativo. Elija un flujo de trabajo acotado, conecte las fuentes actuales, defina la propiedad y mida el retrabajo antes de ampliarlo.
La pregunta importante ya no es si un agente de IA puede diseñar una interfaz. Es si su equipo puede explicar por qué esa interfaz sigue sus estándares y corregirla cuando no lo hace.
