Diseño a Código Usando un Sistema de Diseño Personalizado con AI

Hola, amigos, soy Chaitanya y trabajo como Ingeniero Principal en Atlassian. Estoy muy feliz de estar aquí en el React Summit hoy. Hoy voy a hablar sobre el trabajo que hice en Razorpay donde trabajé como Ingeniero de Personal. Y voy a hablar sobre IA, UI, DS. Bueno, eso es mucho argot. Me pregunto quién creó este título. Bueno, intentemos profundizar en las cosas individuales e intentemos desenredarlo lentamente.

Primero, ¿qué es un sistema de diseño? Básicamente es una colección de componentes reutilizables, patrones y guías que ayudan a los equipos a construir UI de alta calidad de manera consistente y eficiente. Bueno, esencialmente construyes bien y construyes rápido. Y eso es exactamente lo que hicimos en Razorpay. En Razorpay construimos un sistema de diseño llamado Blade y con Blade pudimos tener una apariencia y sensación consistentes en todos nuestros productos. Hicimos componentes reutilizables, más de 65 componentes y patrones y todo lo que estábamos construyendo era accesible desde el primer momento. Y vimos un aumento de aproximadamente 3x en la productividad de diseñadores y desarrolladores. Estábamos muy contentos con lo que logramos y amamos Blade.

Y fue entonces cuando nos golpeó el auge de la IA. Y todos comenzaron a hacer preguntas sobre si realmente necesitamos un sistema de diseño. ¿Puede la IA hacerlo mejor que el sistema de diseño? ¿Podemos simplemente reemplazar el sistema de diseño con IA? Y eso nos hizo pensar y comenzamos a jugar con la IA. Y lo que descubrimos es que la IA sabe mucho. Definitivamente conoce React y conoce TypeScript. Así que le pedimos que construyera una UI. Y hizo un trabajo decente. En realidad construyó alguna UI pero parecía un proyecto universitario. Lo que nos dimos cuenta es que la IA es buena para construir código de UI realmente, realmente rápido, pero no puede generar buen código de UI realmente, realmente rápido. Y ahora sé que esto es muy controvertido, ¿verdad? ¿Cómo defines qué significa buen código de UI? Así que eso es lo que nos preguntamos en Razorpay. ¿Qué significa buen código de UI para Razorpay? Y la respuesta fue simple. Necesita ser consistente en todos nuestros productos. Necesita ser reutilizable y necesita ser accesible desde el primer momento. Y esto sonaba terriblemente similar a algo que ya estábamos tratando de resolver con nuestro sistema de diseño. Y nos dimos cuenta de que los sistemas de diseño y la IA son una pareja hecha en el cielo como Romeo y Julieta menos el final trágico donde el sistema de diseño asegurará que lo que sea que construyas, sea bueno y la IA te ayudará a hacerlo realmente, realmente rápido. Así que naturalmente solo le pedimos a la IA que usara nuestro sistema de diseño y para su crédito, hizo un trabajo decente porque Blade ya es de código abierto. Tiene un poco de comprensión sobre cómo usar Blade. Pero nos encontramos con un montón de errores que no pudimos resolver y comenzamos a preguntarnos por qué falló. Pero nos dimos cuenta de que la IA sabe mucho, pero no sabe mucho sobre nuestro sistema de diseño.

Así que no podemos simplemente decir, oye, adelante y construye una página de inicio de sesión. Necesitamos decirle a la IA que use estos componentes específicos. Necesitamos proporcionarle la documentación de estos componentes. Necesitamos darle algunos ejemplos de cómo usar estos componentes. Y necesitamos darle algunas instrucciones sobre nuestras prácticas internas de codificación. Así que construimos un prompt muy detallado para ayudar a la IA a entender cómo construir una simple página de inicio de sesión. Tenía una estructura realmente agradable. Tenía tareas, guías y contexto, lo que ayudó a que fuera muy simple para la IA entender cómo construir una UI. Pero esto es extremadamente agotador de hacer cada vez. Y algunos desarrolladores incluso argumentarían que es más fácil simplemente escribir código de UI que escribir tales prompts detallados para la IA.

Entonces, ¿cómo se vería nuestro prompt soñado si no queremos escribir prompts tan largos y detallados? ¿Qué pasaría si pudiéramos simplemente pedirle a la IA que construya esto? Simplemente darle un enlace de Figma y pedirle que descubra cómo construir exactamente la misma UI desde Figma. Esto aseguraría que estamos aprovechando la experiencia de nuestro equipo de diseño y no confiamos en que la IA invente un nuevo diseño. Asegurará que no estamos escribiendo prompts detallados para la IA y pasamos la mayor parte de nuestro tiempo realmente enfocándonos en la lógica de negocio. Esto suena bastante mágico, ¿verdad? Vamos a ver si esto realmente funciona en acción.

Así que aquí tengo un diseño de Figma de una simple UI de inicio de sesión. Voy a copiar el enlace a la selección de este diseño de Figma y dárselo a Cursor, que es nuestro IDE preferido, y pedirle que construya este diseño. Va a hacer un montón de cosas en el lado derecho que vamos a ignorar por ahora. Y generó un montón de código que hemos aceptado y todo este código viene directamente de Blade. Y si intentamos ejecutar este código, se ve exactamente como el diseño de UI que teníamos en Figma. Eso es absolutamente mágico. Pero, ¿cómo funciona realmente? Así que tenemos nuestro Cursor IDE que habla con el servidor MCP de Blade, que a su vez habla con el servidor de IA de Blade. Y así es como realmente funciona. Así que para entender esto mejor, tendremos que profundizar en las piezas individuales. Así que el MCP de Blade es un Model Context Protocol. Es un protocolo estándar para que los modelos de IA se conecten a diferentes fuentes de datos y herramientas. Piénsalo como un puerto USB para la IA. Hace que conectar nuevos datos o herramientas sea simple y universal. Funciona en una configuración cliente-servidor, donde tienes clientes MCP como Cursor o Cloud Desktop, y tienes servidores MCP como el MCP de Blade, que proporcionan datos o características muy específicas. Y esto sigue siendo mucho argot, y es difícil entender lo que realmente hace. Así que como lo entendí, es como si tuvieras Alexa en casa, y le pides a Alexa que toque uptown funk, Alexa, con suerte, no va a cantar la canción ella misma.

Ella va a contactar a un proveedor de música como Spotify y pedirle a Spotify que reproduzca la canción. Pero si le pregunto a Alexa qué hora es, Alexa ya sabe inherentemente la hora. No necesita contactar a nadie para obtener esta respuesta. Así que simplemente te dirá la hora. Si le preguntas a Alexa cuáles son las noticias de hoy, va a contactar a un proveedor de noticias como CNN y te leerá el resumen de noticias. Así que esta conexión de qué y cómo conectar es lo que MCP hace para la IA.

Así que en lugar de Alexa, imagina que tienes tu Cursor IDE. Si le preguntas a Cursor cómo construir una página de inicio de sesión con Blade, sabe que necesita contactar al MCP de Blade para entender cómo hacerlo realmente. Si le preguntas qué es una promesa en JavaScript, ya sabe inherentemente qué son las promesas y no necesita contactar a ningún otro proveedor de servicios para esto. Si le pides a Cursor que deshabilite este botón de Blade, sabe que nuevamente necesita ir al MCP de Blade para averiguar cómo deshabilitar este botón. Si le das un prompt soñado, que es construir este enlace de Figma, sabe que nuevamente necesita ir al MCP de Blade para averiguar cómo construir esto. Así que nos damos cuenta de que el MCP de Blade tiene algunas tareas muy específicas. Necesita entender cómo usar componentes específicos, y necesita entender cómo convertir Figma a código. Así que construimos dos herramientas separadas para dos tareas específicas.

La primera herramienta es get-blade-component-docs, que simplemente obtiene la documentación de cualquier componente de Blade. Y la segunda es get-figma-to-code, que convierte el diseño de Figma a código. Así que el get-blade-component-docs toma nombres de componentes separados por comas como entrada, y da la documentación real de todos los componentes solicitados como salida. Así que veamos esto en acción. Así que aquí voy a pedirle a Cursor cómo deshabilitar este botón. Hizo una herramienta llamada get-blade-component-docs tool. Y si miro esta llamada de herramienta, la entrada es el componente del botón y la salida es la documentación real del componente del botón. Y así es como averiguó cómo deshabilitar este botón de Blade. De manera similar, la herramienta MCP de Blade Figma-to-code, aquí la entrada es la URL de Figma donde lo que es importante es la clave del archivo y el ID del nodo que es parte de la URL de Figma. Y la salida es el código UI real escrito con React y Blade. Así que veamos el ejemplo anterior que vimos, pero esta vez un poco más despacio. Así que voy a seleccionar el enlace a este diseño, pedirle a Cursor que construya esto. Ahora Cursor realmente contactará a la herramienta MCP de Blade. Aquí está la llamada de herramienta, la entrada es la clave del archivo y el ID del nodo. Y la salida es el código React real que se construye con nuestro sistema de diseño. Cursor se dio cuenta de que necesita obtener algunos detalles más sobre algunos de los componentes, así que está haciendo otra herramienta llamada get Blade component docs.

Tiene la documentación que necesitaba. Ahora está tratando de averiguar dónde colocar este código UI. Se ha dado cuenta de que hay algunos errores de linting en el código. Está corrigiendo esos errores, aplicando todos los cambios y haciéndote saber todos los cambios que ha realizado. Todo lo que tengo que hacer es aceptar el código y ejecutarlo. Y el código UI se ve exactamente como el diseño de Figma.

Pero aquí la gran pregunta sigue siendo. La llamada de herramienta sí convierte Figma a código. Está tomando la URL como entrada y de alguna manera mágicamente generando el código UI como salida. Entonces, ¿cómo sucede realmente? Así que cuando Cursor hace una llamada de herramienta al servidor MCP de Blade con la clave del archivo y el ID del nodo, el servidor MCP de Blade simplemente reenvía esto a una API, que es Figma a código en el servidor de IA de Blade con la clave del archivo y el ID del nodo.

Y aquí es donde ocurre toda la magia. El servidor de IA de Blade habla con Figma y OpenAI para averiguar cómo generar realmente el código UI. Así que el servidor de IA de Blade primero hablará con Figma. Pedirá a Figma que proporcione la captura de pantalla del diseño UI. Y lo que vamos a hacer es almacenar todo esto en un almacén de contexto.

Primero tomamos la captura de pantalla del diseño y la guardamos en nuestro almacén de contexto. Luego obtenemos la representación JSON del diseño de Figma. Así como tenemos una representación HTML de cada UI web, también tenemos una representación de nodo de cada diseño de Figma. Pero es un poco complicado y no es fácil de entender para humanos o IA. Así que lo que hicimos fue un poco de ajuste de datos aquí para hacerlo un poco más claro. En este ejemplo, puedes ver que el nombre del componente es text input y puedes ver todos los props para el text input que también están en este diseño de Figma. También almacenaremos esto en nuestro contexto.

Luego, porque conocemos la representación JSON del diseño, también conocemos la lista de componentes que se utilizan en este diseño. Y porque conocemos la lista de componentes que se utilizan en el diseño, también podemos obtener toda la documentación para todos estos componentes y ponerla en nuestro almacén de contexto también. Ahora vamos a enviar la captura de pantalla del diseño a un LLM y pedirle que describa lo que ve en detalle. Preguntaremos cómo se ve la jerarquía y agrupación de los componentes, cuál es la posición de los componentes, cuáles son las alineaciones de los componentes, cuál es el espaciado entre los componentes y si hay colores en el diseño que pueda ver y si hay algún contenido de texto en el diseño. Y vamos a tomar esta descripción de UI y almacenarla en nuestro almacén de contexto también.

Finalmente, vamos a construir el prompt que va a convertir nuestro enlace de Figma en código UI. Aquí vamos a tener una estructura de tareas, directrices y contexto. Tenemos la tarea que es generar código UI dado una captura de pantalla de UI y descripción. Tenemos directrices muy detalladas sobre cómo usar los componentes, cómo usar los prompts, cuál debería ser la regla de importación, cómo construir layouts con Blade y cómo convertir un nodo de Figma en un componente React con mapeos de props adecuados y qué requisitos de salida esperamos de esto. Y vamos a tomar todo el contexto que recopilamos y pasarlo aquí en el prompt del sistema. Y con todo este prompt del sistema, vamos a invocar una llamada a LLM y aquí es donde ocurrirá la conversión real del diseño de Figma a código UI.

Entonces, para recapitular, el servidor de Blade AI se comunicará con Figma y obtendrá tanto contexto de diseño como sea posible. Se comunicará con un LLM, pasará todas las instrucciones, el contexto de diseño y de componentes y obtendrá el código UI real que está escrito con nuestro sistema de diseño. Así que cuando construimos ambas llamadas de herramientas, nos damos cuenta de que no solo estamos construyendo para ingenieros, también estamos construyendo para no ingenieros que ahora son constructores en Razorpay. Así que no nos detuvimos solo en estas dos llamadas de herramientas. Construimos una llamada de herramienta que te da una visión general de lo que es Blade, una herramienta que ayuda a crear reglas de cursor, una herramienta que te da documentación general de Blade, una herramienta que te da documentación para patrones de Blade, una herramienta que te ayuda a estructurar un nuevo proyecto usando Blade. Y la mejor parte es que todo esto está disponible en código abierto.

Dado que Blade es de código abierto, nuestro Blade MCP también es de código abierto, así que puedes ir a este enlace y ver todas estas herramientas y cómo las hemos construido. Y la verdadera magia ocurre cuando todas estas herramientas trabajan juntas para construir algo hermoso. Vamos a verlo en acción. Así que aquí estoy pidiendo a Cursor que construya un tablero simple usando Blade. Está haciendo una llamada de herramienta para estructurar un nuevo proyecto. Está insertando algunas reglas de cursor y realmente comenzando el proyecto. Ahora sabe que, dado que este es un tablero simple, un tablero necesita una navegación superior y una navegación lateral, según las directrices de Blade. Así que estoy tratando de construir este tablero, averiguando dónde colocar esto, corrigiendo algunos errores básicos que encuentra, y ahora iniciando el servidor.

Y realmente tenemos un tablero interactivo con una navegación superior y lateral adecuada que se alinea con la filosofía de diseño de Razor. Pero el área de contenido principal aún está vacía. Intentemos llenar el área de contenido principal. Vamos a tomar un diseño de Figma, copiar un enlace a este diseño, y pedir a Cursor que construya este diseño y lo coloque en el área de contenido principal. Ahora Cursor está haciendo una llamada para obtener la herramienta de código de Figma. Tenemos el código UI, Cursor está averiguando dónde y cómo colocar esto en el área de contenido principal. Genial, realmente tenemos el diseño ya colocado allí. Vamos a pedirle que ponga un encabezado en el área de contenido principal. Lo que nos damos cuenta es que el botón aún no es interactivo, no hace nada. Es un botón de añadir sitio web adicional, pero no es funcional. Así que vamos a pedir a Cursor que realmente haga funcional ese botón y añada el flujo de sitio web adicional. Y este flujo necesita adherirse al lenguaje de diseño de Razor. Necesita tener un grupo de formularios escalonados. Así que está consultando la herramienta de documentación de patrones de Blade, y está obteniendo patrones para la vista de creación y grupos de formularios. Tiene la documentación para estos, ahora necesita contextualizarlo para añadir el flujo de sitio web adicional. Está haciendo un montón de cosas, averiguando cómo crear un grupo de formularios.

Ahora, si hago clic en el botón de añadir sitio web adicional, hay un flujo real que está funcionando y no solo un flujo ficticio. Tiene validaciones y todo en su lugar. Y todos estos patrones están de acuerdo con el lenguaje de diseño de Razorpay. Esto es completamente funcional. Y en cuestión de minutos pudimos no solo crear un tablero simple, sino realmente tener uno funcional.

Ahora todo lo que necesitamos hacer es conectar esto con nuestras APIs y debería estar listo para producción pronto. Y así es como todas estas llamadas de herramientas trabajarán juntas para realmente construir algo hermoso que no solo los ingenieros pueden construir, sino también otros constructores en nuestra organización. Y así es como no solo aprovechamos AI en nuestro sistema de diseño, sino que fundamentalmente cambiamos cómo los ingenieros y otros constructores interactúan con nuestro sistema de diseño y aprovechan AI para construir productos con nuestro sistema de diseño.

A lo largo de este proceso, enfrentamos muchos desafíos, muchos cambios de dirección. Comenzamos como un plugin de Figma y eventualmente nos convertimos en un MCP. Escribimos un montón de evaluaciones para medir la precisión de la generación y hacer que mejore constantemente con el tiempo. Nos dimos cuenta de que posiblemente necesitamos integrarnos con herramientas de codificación en blanco como Replit y Lovable en algún momento. Nos dimos cuenta de la importancia de la documentación y queremos seguir mejorando la precisión con estrategias como el diseño por partes en las que ya estamos trabajando.