¿Y si tu Design System empezara a mantenerse solo? Figma Agent cambia las reglas

Durante mucho tiempo hemos hablado de la inteligencia artificial aplicada al diseño pensando sobre todo en generar cosas: crear una pantalla, escribir un texto o convertir un prompt en un prototipo. Pero creo que lo interesante empieza ahora.

Figma acaba de llevar su agente de IA un paso más allá y hay una parte que me ha llamado especialmente la atención: ahora también ayuda a mantener un Design System. Y cualquiera que haya trabajado de verdad con uno sabe que ahí hay mucho trabajo, porque crear una librería de componentes puede ser relativamente sencillo. Lo complicado viene después: mantenerla.

El trabajo que casi nunca se ve

Un Design System empieza normalmente bastante limpio: componentes bien nombrados, variables organizadas y tokens bien utilizados. Y entonces llega el mundo real. Un diseñador crea una variante porque tiene prisa, otro utiliza un color directamente en vez del token correspondiente, aparece un componente nuevo que se parece sospechosamente a otro que ya existía o se modifica una propiedad, pero la documentación continúa explicando el comportamiento anterior.

Nada especialmente grave por separado. El problema aparece cuando multiplicas esas pequeñas excepciones por decenas de diseñadores, cientos de pantallas y varios productos. Ahí empieza lo que podríamos llamar la entropía del Design System, y precisamente ese parece ser uno de los terrenos donde Figma quiere introducir sus nuevos agentes.

Desde el 6 de octubre de 2026, Figma Agent está disponible de forma general y deja atrás su etapa beta. Entre las posibilidades que plantea Figma está utilizar el agente para analizar el sistema, detectar inconsistencias y ayudar a generar documentación.

Figma explica algunas de estas posibilidades con bastante detalle en su artículo How to lighten design system upkeep with the Figma agent, centrado precisamente en tareas de mantenimiento que normalmente acabamos haciendo a mano. Sobre el papel, suena muy bien. A mí lo que me interesa es lo que puede significar para la forma en la que trabajamos, más que el hecho de que una IA pueda cambiar el nombre de cincuenta componentes de golpe.

De diseñar componentes a gobernar el sistema

Siempre he pensado que uno de los errores más habituales cuando se habla de Design Systems es reducirlos a una librería de Figma. Reducirlo a una colección de botones es quedarse con la parte más pequeña. Lo que de verdad lo sostiene es un conjunto de reglas y acuerdos que permiten que diferentes equipos construyan productos de forma coherente.

Por eso una de las tareas más importantes de un equipo de Design System es gobernar el sistema, no solo diseñar componentes: decidir cuándo merece la pena crear uno nuevo, cuándo una excepción tiene sentido o cuándo algo que funcionaba hace dos años necesita replantearse. Ese trabajo requiere mucho contexto.

Y aquí aparece una diferencia importante entre automatización y criterio. Un agente puede detectar que existen tres valores de azul ligeramente diferentes donde debería utilizarse un token, encontrar veinte componentes que no utilizan la versión publicada en la librería o incluso generar una primera documentación explicando propiedades y variantes.

Figma muestra precisamente un ejemplo de este tipo de flujo en Workflow Lab: Staying in the flow with Figma’s Agent, donde el agente participa en actualizaciones de librería, feedback y una primera versión de la especificación del Design System.

Todo eso puede ahorrar bastante tiempo, pero alguien sigue teniendo que decidir por qué existe esa excepción. Quizá ese azul diferente es un error, o quizá responde a una necesidad que el sistema todavía no contempla. Y esa diferencia sigue siendo diseño.

Limpiar el sistema sí, decidir por él no

Hay algo que me gusta especialmente de esta evolución de las herramientas de IA: nos obliga a separar dos cosas que durante años hemos mezclado, el trabajo mecánico y el trabajo de diseño. Buscar inconsistencias en cien pantallas no es especialmente creativo, comprobar manualmente si todos los componentes utilizan las variables correctas tampoco, y revisar uno por uno nombres, propiedades o estilos consume tiempo, pero aporta poco valor por sí mismo.

Si una herramienta puede encargarse de esa parte, bienvenida sea. Porque ese tiempo puede utilizarse en algo mucho más importante: entender por qué aparecen las inconsistencias. Muchas veces un componente se utiliza mal porque su estructura y sus propiedades no son suficientemente claras, una variante nueva aparece porque el componente existente no resuelve correctamente un caso de uso o un diseñador rompe el sistema porque seguirlo requiere más esfuerzo que saltárselo. Y ahí ningún botón de “Fix with AI” va a solucionar el problema de fondo.

De hecho, las primeras pruebas realizadas fuera de Figma muestran precisamente esa diferencia. En una prueba de Figma Agent realizada con Flex Design System, el agente resultó útil para tareas de análisis y mantenimiento, pero tuvo más problemas cuando se le pidió crear componentes nuevos respetando patrones, tokens y estructuras existentes.

Algo parecido encontraron en una prueba realizada por el equipo de Entify con un Design System real: al proporcionarle el contexto adecuado los resultados mejoraban, pero eso no significaba que entendiera automáticamente todas las reglas y decisiones acumuladas dentro del sistema.

Y creo que ahí está precisamente el punto: un Design System no contiene solamente componentes. Contiene contexto.

También cambia nuestra forma de documentar

Otro punto que me parece especialmente interesante es la documentación. Quienes trabajamos con Design Systems sabemos lo rápido que puede quedarse obsoleta: diseñas el componente, defines su comportamiento y documentas cómo usarlo, y tres meses después el componente ha cambiado cinco veces mientras una parte de la documentación continúa describiendo la primera versión.

Figma plantea ahora que el agente pueda ayudar a generar borradores de documentación utilizando el contexto del propio sistema. Eso puede ser tremendamente útil, pero para mí la palabra importante aquí es borrador.

Una IA puede explicar perfectamente que un componente tiene tres variantes y cinco propiedades. Lo que difícilmente sabrá por sí sola es por qué decidimos utilizar un patrón en lugar de otro, cuándo no debería utilizarse o qué problemas descubrimos después de probarlo con usuarios. Lo que separa una documentación útil de una simplemente correcta es que la primera explica por qué existe el componente y cuándo tiene sentido usarlo, no solo cómo funciona.

¿Significa esto que necesitaremos menos diseñadores?

Probablemente esta sea la pregunta que acaba apareciendo cada vez que hablamos de IA. Yo la formularía de otra manera: ¿necesitaremos diseñadores haciendo exactamente las mismas tareas que hacíamos hasta ahora? Seguramente no, y no creo que eso sea necesariamente malo.

Hace años dedicábamos muchísimo tiempo a tareas que hoy damos por automatizadas: crear versiones manualmente, actualizar símbolos o modificar decenas de pantallas una a una. Las herramientas evolucionaron, y nuestro trabajo evolucionó con ellas. Creo que con los agentes ocurrirá algo parecido.

Si pueden encargarse de revisar la consistencia de un sistema, actualizar documentación básica o detectar desviaciones de una librería, el valor del diseñador se desplaza todavía más hacia las decisiones. Y esto tampoco parece un fenómeno aislado. El Informe sobre IA de Figma 2026, basado en más de 8.400 respuestas y 639 entrevistas cualitativas, refleja cómo la IA está empezando a modificar no solo la productividad individual, sino también la forma en la que diseñadores, desarrolladores y Product Managers trabajan juntos.

Y, curiosamente, cuanto más fácil sea generar una interfaz, más importante será decidir qué interfaz merece la pena generar.

Un Design System preparado para agentes

Hay otra consecuencia que quizá sea todavía más interesante: para que un agente entienda correctamente un Design System, el sistema tiene que estar bien construido: nombres con sentido, variables organizadas, una estructura lógica.

De hecho, la propia Figma insiste en la importancia de proporcionar contexto al agente. Con la disponibilidad general se pueden añadir incluso guidelines a una librería mediante archivos Markdown con reglas, buenas prácticas y antipatrones que el agente tendrá en cuenta al trabajar con ella.

En otras palabras: la IA también necesita un buen Design System. Y sospecho que los sistemas mejor estructurados tendrán cada vez más ventaja: no solo serán más fáciles de usar para diseñadores y desarrolladores, también lo serán para las herramientas y agentes que trabajen con ellos.

Eso introduce una nueva capa en el diseño de sistemas. Hasta ahora diseñábamos principalmente para dos consumidores: personas y código. Quizá tengamos que empezar a pensar también en un tercero: los agentes.

La noticia no está donde parece

Dentro de unos meses seguramente dejaremos de sorprendernos cada vez que una herramienta anuncie una nueva función de inteligencia artificial. Pasó con el responsive, pasó con los componentes, pasó con Auto Layout y probablemente acabará pasando con los agentes.

Para mí la noticia no es que Figma haya metido otra IA dentro de Figma, sino que la inteligencia artificial empieza a entrar en la infraestructura del diseño y no solo en la generación de pantallas.

Mantener librerías, revisar inconsistencias y documentar componentes: todo ese trabajo que ocurre alrededor de la interfaz empieza también a automatizarse. Y eso puede ser una muy buena noticia, siempre que recordemos que mantener un Design System no consiste únicamente en conseguir que todo sea consistente.

A veces una inconsistencia es precisamente la pista que necesitas para descubrir que el sistema tiene que cambiar.