geek vibes.geek vibes.
UX-UI · 5 min · 8 jul 2026

Figma ya no solo diseña: ahora te construye tus propias herramientas (y esto cambia cómo operamos como agencia)

En Config 2026, Figma lanzó plugins generativos, code layers y un agente conectado vía MCP a GitHub, Notion y Slack. Ya no necesitas saber programar para crear tu propia herramienta interna. En Geek Vibes vemos la oportunidad — y el riesgo de operar sin control.

Ilustración editorial minimalista en tonos navy, verde y violeta de un panel de diseño conectado a un agente de IA que genera herramientas automáticamente.

El 24 de junio, Figma anunció en su conferencia Config 2026 una actualización que cambia una pregunta que llevamos años haciéndonos en la industria: ¿quién construye las herramientas que usa un equipo de diseño? La respuesta, cada vez más, es "el equipo mismo, sin escribir una línea de código". Figma lanzó plugins generativos, code layers y una versión ampliada de su agente conectado por MCP (Model Context Protocol) a herramientas como GitHub, Notion, Slack y Atlassian. No es una actualización cosmética. Es un cambio de quién tiene permiso para construir dentro del flujo de diseño — y eso nos afecta directamente como agencia.


Qué anunció Figma exactamente


Config 2026 trajo varias piezas, pero tres son las que más nos importan a quienes vivimos entre diseño y desarrollo:


- Plugins generativos: describes la herramienta que necesitas —comportamiento, controles, parámetros— y el agente de Figma la construye dentro del archivo, sin entorno de desarrollo local ni conocimiento de la API de plugins. Empezaron a habilitarse de forma gradual el mismo 24 de junio.

- Code layers: cualquier capa de diseño se puede convertir en una capa de código interactivo con un clic o un prompt, editable por todo el equipo desde el canvas. El rollout arranca en julio, por lista de espera.

- Agente con conectores MCP: el agente ya no solo entiende el canvas — puede leer y escribir en GitHub, Notion, Slack, Atlassian, Hex y Granola. Eso significa que un componente generado en Figma puede referenciar un ticket real de Jira o actualizar un doc de Notion automáticamente.


Todo esto corre sobre "skills": instrucciones reutilizables que empaquetan el flujo de trabajo y las convenciones de un equipo, para que el agente no invente su propio estilo cada vez que lo usas.


Por qué esto no es solo "otra feature de IA"


La diferencia con actualizaciones anteriores de IA en Figma es que esta democratiza la construcción de herramientas internas. Antes, si un equipo de diseño quería un plugin específico —digamos, uno que reordene capas por criterio de contraste, o que genere variantes de un componente con reglas de negocio propias— necesitaba a alguien que supiera JavaScript y la API de plugins de Figma. Ahora ese plugin se describe en lenguaje natural y aparece en el archivo.


Esto conecta con algo que ya veíamos venir: la línea entre "diseñador" y "desarrollador" se sigue borrando, no porque los diseñadores aprendan a programar, sino porque el agente absorbe esa fricción. Dylan Field, CEO de Figma, lo dijo en el blog de lanzamiento: la IA bajó el piso de entrada, pero el techo lo siguen subiendo las personas que se atreven a construir con estas herramientas nuevas.


El riesgo que nadie está mencionando


Aquí está el ángulo que nos importa como agencia y que casi nadie está cubriendo: plugins generativos sin gobernanza son shadow tools con esteroides. Si cualquier persona del equipo puede crear su propia herramienta dentro de un archivo compartido, en unos meses vas a tener quince variantes de "el plugin que ordena capas" hechas por distintas personas, con distintos criterios, sin documentación y sin control de versiones real.


No es un problema hipotético. Ya lo vivimos con el crecimiento descontrolado de librerías de componentes y estilos duplicados cuando Figma abrió Auto Layout y variables a todo el mundo sin una capa de gobernanza clara. La lección de esa etapa fue simple: la velocidad que gana el equipo individual se pierde en consistencia de sistema si nadie audita lo que se está creando.


Lo mismo aplica a los code layers. Que una capa de diseño se convierta en código interactivo con un clic suena maravilloso hasta que ese código termina en producción sin pasar por revisión, o hasta que dos personas "extraen a diseño" el mismo componente y generan versiones divergentes.


Lo que esto significa para agencias y equipos de producto


Si diriges un equipo de diseño o una agencia como la nuestra, esto es lo que cambiaría en tu forma de operar en los próximos meses:


- Define quién puede publicar plugins generativos antes de que la gente empiece a crearlos. Figma ya anunció que pronto se podrán publicar a nivel equipo, organización o comunidad — eso necesita un dueño y un proceso de revisión, igual que cualquier librería interna.

- Trata las "skills" del agente como documentación viva de tu design system, no como un extra. Si tu equipo ya tiene convenciones de nomenclatura, espaciado o accesibilidad, empaquétalas ahora como skills antes de que cada persona improvise las suyas.

- Aprovecha los conectores MCP para cerrar el ciclo diseño-desarrollo-negocio. Si un componente puede referenciar directamente un ticket de GitHub o un brief de Notion, hay una oportunidad real de reducir el tiempo de handoff — pero solo si tu stack ya está ordenado (si tus tickets están mal escritos, el agente va a heredar ese desorden).

- No confundas "más rápido para prototipar" con "listo para producción". Los code layers son excelentes para explorar direcciones en paralelo, pero necesitan el mismo proceso de code review que cualquier otro pull request antes de tocar producción.


En Geek Vibes ya empezamos a mapear qué partes de nuestro flujo con clientes se benefician de esto —principalmente exploración rápida de variantes y generación de specs para developers— y cuáles necesitan una capa de revisión humana explícita antes de que el agente tenga permiso de escribir directo en nuestros repos.


El punto real


Figma no está vendiendo "IA que diseña por ti". Está vendiendo la posibilidad de que cada equipo construya sus propias herramientas sin depender de un ingeniero de plugins interno. Eso es poder real, pero el poder sin gobernanza se convierte en deuda técnica de diseño. La pregunta que le hacemos a los equipos con los que trabajamos no es "¿ya probaste los plugins generativos?" sino "¿quién audita lo que se construye con ellos?".


Si estás evaluando cómo integrar estas herramientas en tu flujo de diseño-desarrollo sin perder consistencia, en Geek Vibes ayudamos a agencias y equipos de producto a construir esa capa de gobernanza antes de que la velocidad se vuelva caos. Escríbenos a comercial@geekvibes.agency.

¿Te resuena algo de esto?

Si vienes operando con piezas que no terminan de conectar, lo diagnosticamos juntos en 30 min.

Agenda un diagnóstico →
ACTIONS
← Volver al blog