Imagina que abres Figma, copias el link de un frame y ese mismo diseño aparece como un Lightning Web Component dentro de Salesforce. Sin armar el estilo desde cero y sin mandarle al agente una captura con un "impleméntalo y vamos".
Esa es la idea central de la charla en vivo que dieron Josué Mendoza (Josu) y Esteban Morales (Esti) en Dreamforce: Figma to Vibes: From Design to Lightning Web Components. Forman parte del equipo de Vantegrate y, en 20 minutos, mostraron el camino completo, desde el diseño hasta el componente en la organización.
En este artículo te contamos cómo pasar de un frame de Figma a un LWC usando Figma MCP, las skills de Salesforce y un agente. En la demo usaron Agents for Vibes, aunque el mismo enfoque sirve con otros agentes.
Si te interesa la otra charla que el equipo llevó a Dreamforce, la de agentes que te avisan solos, está en la nota de agentes proactivos con Flow, Agentforce y Slack.
El problema del handoff: un screenshot no alcanza
Josu arrancó por el diseño que quieres llevar a una página de Salesforce. En pantalla mostraron varios layouts: información de cuentas, datos del cliente, una experiencia de servicio y un ejemplo para mostrar contactos.
El objetivo de la sesión era construir esa vista. Para empezar, hay que elegir una sola pieza.
Josu lo dijo sin vueltas. Lo que quieren evitar es sacar un screenshot de todos los diseños y pedirle a un agente que lo implemente de una.
Un diseño no es una foto de lo que quieres ver. Adentro hay estados, colores, paletas, espaciado y el comportamiento que el componente tiene que respetar.
Si mandas solo una captura, el agente tiene que adivinar esa información. Por eso el handoff clásico se queda corto, aunque la imagen se vea perfecta.
Esti lo reforzó en un momento: no alcanza. El diseño es más que una imagen, y hay una forma mejor de dárselo al agente.
Enfoca un solo frame, no todo el diseño
La primera idea que quisieron dejar en claro es esa. Haz foco en un componente dentro del diseño, no en la pantalla entera.
En la demo eligieron un frame puntual. El resultado que buscaban era el bundle del componente: el HTML, el CSS, el estilo y la metadata.
Josu lo resumió así: seleccionas un frame enfocado en Figma y lo conviertes en un componente. Esa es la puerta de entrada, y después puedes iterar sobre el resto de la vista.
Si estás armando experiencias para clientes o partners, ese mismo criterio aparece cuando se construye un portal con Experience Cloud. Ahí el Lightning Web Component entra cuando el Flow se queda corto, no al revés.
El contexto que falta: Figma MCP
Para no mandar una descripción vaga, hay que traerle al agente más contexto. Ahí entra Figma y, sobre todo, el protocolo que conecta el diseño con el editor.
Josu presentó el Figma MCP como el puente entre el archivo de Figma y el entorno donde estás generando código. Por esa vía se comparte lo que una captura no transporta: estados, capas, padding y comportamiento.
MCP, en pocas palabras, es una forma estándar de conectar una herramienta con un agente. Acá la herramienta es Figma, y el agente necesita leer el frame de verdad, no una foto.
Sin esa conexión, el modelo completa huecos con suposiciones. Con esa conexión, trabaja sobre la información que ya vive en el diseño.
En Pulse ya vimos cómo un MCP puede unir sistemas en vivo, por ejemplo en la nota de Salesforce MCP con Jira, Confluence y Rovo. La idea es la misma: menos copiar y pegar, más contexto directo.
Las skills de Salesforce (y por qué SLDS2 importa)
El contexto del diseño no alcanza para una buena implementación en Salesforce. Hace falta otra pieza que sirva de guía: las skills, o habilidades, del ecosistema.
Josu las definió como reglas que el agente sigue para desarrollar mejor. Durante Dreamforce aparecieron en muchas sesiones, y no son solo para Lightning Web Components: hay skills para Apex, para Flows, para metadata y para otros tipos de trabajo.
Salesforce tiene un repositorio con ese material. La idea es usarlo en lugar de explicarle todo al agente desde cero.
Un ejemplo concreto: evitar que el agente invente un estilo desde el principio. Dentro de Salesforce ya existe SLDS2, el sistema de diseño de la plataforma, y una de las skills pide usarlo dentro del componente.
Eso no es un detalle estético. Si el agente improvisa CSS, el resultado puede verse bien en el preview y romper la consistencia de la organización.
Cómo entra SLDS2 en otras conversaciones del equipo se ve en esta nota sobre secretos de un release de Salesforce. Con el contexto y las skills en su lugar, llega el primer draft del componente, y recién ahí decides el siguiente paso.
Tres verbos: Design, Guide, Generate
Josu propuso recordar todo el flujo con tres verbos cortos, fáciles de retener.
Design: crea tu diseño en Figma.
Guide: guía al agente con el MCP y las skills.
Generate: genera el componente.
El contexto y las habilidades, juntos, son la guía para un desarrollo correcto. El diseño solo no alcanza, y el agente solo tampoco.
El último mensaje de Josu, antes de pasarle la palabra a Esti, fue directo: siempre revisa el resultado de tu vibe coding. Los agentes a veces adivinan, y en tu organización puede haber nombres o convenciones gráficas que el componente tiene que respetar.
Por eso la revisión es parte del método: generas, miras, corriges y recién ahí iteras. Esa disciplina aparece también en los artículos de Pulse sobre desarrollar con IA en Salesforce.
El prompt como contrato
Esti tomó la segunda mitad con una idea simple. Cuando metes IA en el loop de desarrollo, todo empieza con un prompt.
Lo comparó con la forma en que ya interactúas con ChatGPT o con Claude. La diferencia es cómo piensas ese texto: a Esti le gusta ver el prompt como el contrato entre lo que quieres hacer y lo que le pides al agente.
En este caso, el contrato era claro. Querían que el agente desarrolle un Lightning Web Component a partir de un diseño que ya existía.
Mostraron un prompt de ejemplo con cuatro partes. La primera: definir el nombre del componente, porque no quieres que el agente lo decida por ti.
La segunda: llamar al Figma MCP cuando esté disponible en el contexto del agente. La tercera: usar las skills de Salesforce, que aceleran el desarrollo porque traen reglas y contexto que ya existen.
Esti remarcó que esas skills sirven en distintos agentes. Puedes usar Claude, Codex u otra herramienta, pero necesitas esas reglas si quieres que el proceso rinda.
La cuarta parte del contrato es la revisión. Hay que pedirle un resultado que puedas mirar después (en general en un entorno local) y dejar explícito que ese paso no se saltea.
Ese prompt es un ejemplo, no una receta única. Si te sirve ver cómo se trabajan prompts en Salesforce, mira el pack de prompts para vibe coding.
Demo: Frame Link y Agents for Vibes
Llegó el momento que todos querían ver. Esti abrió el diseño real de Figma, armado para verse muy parecido a Salesforce, y mostró el primer gesto práctico: en Figma, con clic derecho, copias el link de la selección.
Eso es el Frame Link, el MCP que eligieron para esta demo. Esti aclaró que Figma tiene otros MCP, pero para traducir un frame a un LWC este alcanza.
Después abrieron Agents for Vibes. Pegaron el prompt con los requerimientos: construir un Lightning Web Component, cuidar la accesibilidad y usar SLDS más las skills.
Al final pegaron la URL copiada de Figma, que es la que le indica al agente que tiene que usar el MCP.
El agente empezó a tomar información de las skills, detectó que necesitaba el MCP de Figma y pidió permiso para conectarse (seguir o cancelar).
Cuando terminó, el componente ya estaba creado, con sus archivos listos para revisar.
Un detalle práctico: cómo saber si el MCP está conectado. En Agents for Vibes, en la sección de servidores, aparece Figma Frame Link; si figura en verde, ya estás hablando con Figma.
La charla no dice que tengas que casarte con esa herramienta. Esti repitió que puedes usar Claude u otro agente con capacidad de MCP, y que el beneficio de Agents for Vibes, en su caso, fue que el set de skills ya venía incluido.
Si te interesa el mismo estilo de trabajo en integraciones, en Pulse cubrimos MuleSoft Vibes y el vibe coding. Y si tu agente de cabecera es Claude, también puedes leer cómo Salesforce entra en Claude.
El componente ya en Salesforce
Con el bundle generado, fueron a la organización. Abrieron una cuenta, refrescaron y el componente estaba ahí.
Esti lo describió como muy similar o idéntico a lo que tenían en Figma. Misma claridad, misma consistencia, con la paleta del diseño.
Ese es el punto de la demo. No es un bosquejo suelto: es un componente que ya vive en Salesforce y se puede mirar en el contexto real de un registro.
El frame deja de ser un archivo de diseño y pasa a ser parte de la experiencia que el usuario ve. Si tu equipo todavía revisa un LWC subiendo el componente a una página de prueba, vale cruzar esta idea con los hacks de los últimos releases, donde aparece el preview local de un Lightning Web Component.
Blueprints de la comunidad Salesforce en Figma
La demo no terminó en el componente propio. Esti recordó que Salesforce tiene una comunidad en Figma, con componentes listos para usar como punto de partida.
Son Blueprints. Si quieres algo que ya está construido, por ejemplo una tienda de e-commerce, puedes tomar ese Blueprint y empezar desde ahí.
En la sesión eligieron uno, copiaron la selección, se la pasaron al agente con las skills y después fueron a Salesforce a ver el resultado. El componente quedó disponible para colocarlo donde hiciera falta.
Esta puerta es útil cuando el equipo no quiere reinventar patrones que ya existen. Y si más adelante tu portal pide ir más allá de LWC, en Pulse también está la nota de Experience Cloud con React y multi-framework.
Empieza chico e itera
Esti cerró esa parte con una recomendación de método. Empieza con componentes pequeños y, de ahí, itera sobre el resto de tus diseños en Figma.
El agente debería producir lo esperable en un bundle de LWC: el HTML, el JavaScript si hace falta, el CSS del diseño y el archivo de configuración. Eso es lo que tienes que revisar, no un screenshot nuevo.
Hay una salvedad importante, y Esti la dijo claro: el agente acelera el desarrollo, pero tú sigues siendo quien desarrolla. Tú le dices qué hacer y qué diseño usar.
Si quieres quedarte dentro del sistema visual de Salesforce, tienes que pedírselo al agente. Si no se lo pides, puede irse por otro camino.
El frame, el contrato y las skills te dan velocidad. El criterio sigue siendo tuyo.
Accesibilidad, datos sensibles y revisión local
La última parte técnica de la charla fue una lista de cuidados, no un extra opcional. El primero es la accesibilidad.
Que el componente se vea bien no significa que funcione para todos. Hay que pedirlo en el contrato desde el principio, como hicieron en la demo.
El segundo cuidado es de seguridad. Los componentes no deberían exponer información sensible ni claves de API, y tampoco deberías poner esos datos dentro de un prompt.
Esti fue enfático: eso es muy peligroso. El prompt es un contrato de trabajo, no un lugar para pegar secretos.
Si tu preocupación es cómo dar acceso a un agente sin perder el control, te sirve la nota de seguridad y gobernanza en Salesforce. Acelerar no puede significar abrir una puerta de más.
El tercer cuidado es la revisión local. Josu lo había pedido al inicio y Esti lo repitió: mira el componente en local antes de llevarlo a producción o a cualquier otro ambiente.
No alcanza con que Figma se vea igual al primer render. Alguien tiene que validar cómo se comporta el componente dentro del sistema.
Qué llevarte de la sesión
Al cierre dejaron una lista corta de takeaways: el mapa para repetir la demo en tu organización.
Empieza con un frame chico y una URL, y recién después pasa a componentes más grandes.
Haz foco en Figma primero, no en una captura de toda la pantalla.
Usa skills. Sin ellas, el agente hace asunciones sobre un Lightning Web Component y no termina de entender la estructura.
Elige un agente que te ayude. Ellos usaron Agents for Vibes porque ya traía las skills, pero puedes usar Claude, Codex u otro.
Valida todo antes de desplegar, y pide que otra persona revise accesibilidad y comportamiento.
Las skills fueron un tema cruzado de Dreamforce, y Esti insistió en que no son un accesorio. Aceleran el proceso porque evitan que el agente improvise la forma de un componente de Salesforce.
Si estás armando agentes como parte de tu forma de desarrollar, también puedes mirar Agentforce DX y el trabajo con agentes como código. El hilo común es el mismo: reglas claras y una revisión humana antes de subir nada.
Al final de la charla mostraron un código QR con recursos: una guía para conectar el Figma MCP con Agents for Vibes, material para desarrollar componentes y el set de skills de Salesforce para sumar a tu agente.
Por qué este enfoque sirve a empresas medianas
Lo más útil del método es que no pide inventar un stack nuevo: parte de un diseño en Figma, de skills que ya existen y de un agente que el equipo puede elegir.
Para empresas medianas, eso baja la barrera de entrada. No hace falta rediseñar toda la experiencia ni escribir cada estilo a mano.
Empieza con un frame, un contrato corto y una revisión local. Si esa pieza funciona, iteras; si no, ajustas el prompt y las skills antes de escalar.
La promesa no es que el agente reemplace al desarrollador. Es más honesta: el agente acelera, y el equipo sigue decidiendo qué se implementa y cómo se valida.
De un frame a tu primer LWC
El cambio que propusieron Josu y Esti es de método. Dejas de mandar una foto del diseño y empiezas a pasarle al agente el frame, las reglas de Salesforce y un contrato que se puede revisar.
Elige un componente chico, copia el Frame Link y pide un bundle que puedas mirar en local. Si el resultado se parece al Figma y respeta SLDS, recién ahí das el siguiente paso.
![Masterclass » Desarrollar con IA en Salesforce: Casos reales y los Trucos [que nadie te cuenta]](https://info.vantegrate.com/pulse/images/ia-salesforce-desarrollo-productividad-prototipos-flujo-trabajo-crm-inteligenciaartificial.png.webp)
