La UI que se construye sola: Explorando el Front-End Generativo

Hola, soy Kiko y hoy quiero compartir con ustedes un concepto en el que he estado trabajando y que llamo Interfaces de Usuario Dinámicas. Es el concepto donde un LLM, una IA, genera la interfaz de usuario sobre la marcha basada en la indicación deseada del usuario, personalizada solo para ellos. Pero antes de eso, permítanme contarles un poco más sobre mí. Así que soy Kiko y vengo desde Bulgaria. Si no han oído hablar de Bulgaria, acabamos de ganar Eurovisión. En los últimos 10 años he estado trabajando para una empresa llamada Progress y me he centrado en el desarrollo de componentes de UI y sistemas de diseño específicamente. Y últimamente, he estado explorando cómo la IA puede afectar este espacio de usuario exacto.

Así que mi viaje comienza explorando la historia de la web como plataforma. Si echamos un vistazo atrás, realmente muy atrás, atrás, atrás, ni siquiera había nacido entonces, pero teníamos los primeros sitios web estáticos, los llamo. Puedes pensar en ellos como el primer sitio web de Space Jam si lo has visto. Y lo específico de ellos es que cada persona experimenta el sitio web de la misma manera. Así que es lo mismo para todos. Esto es lo que llamo un sitio web estático. Avanzando hasta hoy, tenemos las aplicaciones web modernas. Ahora tenemos datos dinámicos que provienen de servidores, personalizados para cada usuario individual, pero hay algo distintivo sobre las aplicaciones web que permanecen estáticas.

Y esta es la fase de usuario alrededor de ellas. Puedes hacer pruebas A-B, puedes hacer todo tipo de cosas. Pero al final del día, fue el desarrollador quien ha predefinido esta fase de usuario. Así que un pequeño spoiler. Vamos a explorar si eso puede cambiar lo que el futuro puede habilitar mediante un AOM. Entonces, ¿cuál es exactamente el problema con las interfaces de usuario estáticas? Esta es tu típica página de inicio de SAS. Estás cargado con todos los caminos posibles que el usuario puede ver. Y tienes un usuario que probablemente quiera comenzar una prueba. Y no le das uno, ni dos, sino en realidad tres botones de llamada a la acción. Luego tienes al usuario que está listo para comprar una licencia. También tienes una interfaz de usuario para eso. Y luego tienes a este pobre tipo que está tratando de postularse para un trabajo en tu empresa. No solo tienen que desplazarse hasta el final de tu página de carreras, probablemente deberían ir a tres páginas solo para poder enviar su CV. Quiero definir el problema de manera diferente. Así que no es el número de páginas.

No es la duplicación de elementos que tenemos en esa página. Es que hemos predefinido como desarrolladores todos los caminos disponibles que el usuario puede tomar. Así que los hemos limitado en este laberinto de UX para que naveguen. Y lo que vamos a desafiar hoy es si podemos revertir esto desde los primeros principios, ¿qué pasaría si comenzamos el recorrido desde el usuario y les damos la capacidad que nuestra aplicación expone? Así que cómo estamos tratando de abordar esto es a través de esta fórmula. La interfaz de usuario es una función de datos y estado de la manera más básica.

El estado es dinámico por defecto. Así que es diferente cada vez, dependiendo del usuario, dependiendo de las condiciones. Los datos se han vuelto dinámicos. Así que conoces los datos exactos de este usuario. Así que si tanto los datos como el estado son dinámicos, lo único que no es dinámico es la función. Somos nosotros, los desarrolladores. Estamos proporcionando, estamos generando esta interfaz de usuario, pero lo estamos haciendo una vez en tiempo de construcción. Así que quiero hacer una separación clara entre los LLMs creando interfaces de usuario durante el tiempo de construcción, y lo que intentaremos hoy es lo opuesto. Desplegaremos el LLM en la aplicación real.

Así que la barrera que estamos cruzando aquí es que esto es después del límite de despliegue. Así que ya hemos desplegado nuestra aplicación. No hay desarrollador entre el usuario y la aplicación. Entonces, ¿cómo hacemos eso? Comenzamos con lo que todos están acostumbrados, que es la indicación de usuario más básica. Y lo que intentamos hacer en el lado del código es como hacer una función, que toma la indicación del usuario, los datos del usuario, el estado actual, todas nuestras capacidades de aplicación y nuestro sistema de diseño para tratar de crear una interfaz de usuario sobre la marcha. Así que estoy entrando en el código por ahora. Y esperaría que no muchos de ustedes estén codificando manualmente. Así que hoy vamos a estar viendo indicaciones y revisando el código que generaron en lugar de codificación en vivo.

Así que lo primero que he preparado es esta empresa imaginaria llamada Boxcell que vende software. Y vamos a intentar comprar una licencia para ello. Tenemos nuestro shell de aplicación alrededor y solo un único prompt en el que diremos qué queremos lograr en esta aplicación web exacta.

Y avanzando, la primera adición que queremos es que queremos lo mínimo absoluto. Conectaremos esta entrada para hacer un post al servidor y el back end llamará a un LLM con la indicación del sistema y la entrada del usuario. Luego solicitaremos una salida estructurada que intentaremos renderizar en el cliente. Y les mostraré solo las partes importantes del código para que podamos identificarlas.

Lo primero es la llamada LLM y trataré de mantener la indicación del sistema lo más pequeña posible y en lugar de volcar instrucciones allí, construiremos alrededor de ella todo un sistema para apoyar nuestras interfaces de usuario dinámicas. Así que tendremos una indicación del sistema, la intención del usuario y la llamada LLM real. Y la parte importante aquí es qué solicitamos al LLM como estructura para representar la interfaz de usuario. No pedimos HTML. No pedimos código React. Pedimos una estructura que pueda representar el árbol DOM. Así que este es el esqueleto.

Esta definición de un solo nodo es la columna vertebral de nuestra aplicación. Y luego, a partir de esta estructura, haremos una renderización del lado del cliente, es solo una renderización recursiva del elemento y sus hijos.

Así que avanzando desde aquí, el primer punto de control, lo que sucedería es que si pedimos, quiero comprar una licencia, el LLM tomaría todo en consideración y generaría alguna interfaz de usuario arbitraria. Todavía no sabe nada más allá del prompt del usuario. Así que estos datos no son nuestros. Son solo alucinados por el LLM.

Así que el siguiente paso que intentaremos hacer es alimentar o fundamentar la respuesta del modelo basándonos en los datos que hemos creado localmente. Eso será un único archivo JSON con algunos datos simples para nuestras licencias. Debería verse como, ups. No importa. Así que añadiremos esto al LLM y lo anexaremos a toda la conversación.

Así que el LLM ahora sabrá cuáles son nuestros datos. Así que para los datos, tenemos una licencia de equipo y una licencia de negocio. Y la próxima vez que solicitemos estos datos, esperaríamos que los resultados coincidan con esto. Así que vemos la licencia de equipo, tenemos la licencia de negocio y los precios son exactamente los que ajustamos. Así que ahora mismo genera algunos botones, pero no funcionan. Desafortunadamente, todavía no le hemos dicho a nuestro modelo cómo interactuar con el sitio web.

Así que el siguiente prompt en nuestro sitio es hacer que la interfaz de usuario sea interactiva. Y añadiremos nuestra primera capacidad, que es comprar una licencia. Lo definiremos en un archivo separado e intentaremos derivar qué hace, cuáles son sus argumentos. Así que debería parecerse a las capacidades en el marco de control.

Así que debería verse así. Esta es nuestra primera capacidad que nuestra aplicación expuso. Y lo que hice es que tengo una función de utilidad que toma estos comentarios y los alimenta al LLM para que sepa cómo funciona con nuestra aplicación. Así que lo que esperaríamos a continuación, si generamos esta interfaz de usuario, es que el LLM genere una interfaz de usuario funcional y cómo interactúa realmente. Resulta que la plataforma WebAssembly tiene esta cosa llamada el formulario.

Así que en el lado del LLM estaremos enseñando, esto es lo único que estamos añadiendo al prompt del sistema, estaremos enseñando al LLM a generar formularios y pasar campos para cada uno de los argumentos de nuestra capacidad. Así que veremos que ahora tenemos como tres campos distintivos, cada uno de ellos se asigna a un argumento específico en el backend. Así que si hacemos una prueba e intentamos comprar una licencia de equipo única, no pasaría nada. Pero al ir a la pestaña de Red, haré un poco de zoom. Veremos que nuestro backend respondió que hemos comprado con éxito una licencia.

Así que avanzando, lo que queremos hacer es hacer que el LLM sea consciente del estado. Así que tenemos algún tipo de estado del cliente. Entonces lo primero es que enviaremos este estado del cliente de vuelta al LLM para que pueda trabajar con él y enseñarle cómo incrustarlo en la aplicación real. Así que también estaría añadiendo en algún lugar por aquí una capacidad de registro y mantendremos las credenciales de registro en el estado real del cliente. Así que hice un panel de registro por aquí. Ahora mismo no estamos registrados y si solicito una licencia, ahora el LLM debería... Sí, ahora el LLM sabe que podemos iniciar sesión y podemos comprar una licencia. Así que si intentamos iniciar sesión por aquí, haremos otra solicitud para iniciar sesión. El backend devolverá que hemos iniciado sesión con éxito y una vez más solicitaremos la interfaz de usuario del LLM. Y ahora podemos ver que nuestro ID de cuenta ya está poblado porque el LLM es consciente del estado de cuál es realmente el estado de nuestra aplicación. Así que avanzando, no quiero esperar por toda la interfaz de usuario. Si has visto que aparece de una vez, pero para mostrar esto, añadiré un poco más de capacidades. Así que ese será nuestro próximo punto de control donde añadiremos anuncios al carrito, revisar actualizaciones de cantidades y algunas otras capacidades, pero aún dejaremos que el LLM dicte el flujo real del usuario. Y a través de esto, solicitaremos al LLM que no nos dé todo el árbol, sino que transmita todos los elementos individuales uno por uno para que podamos mostrar retroalimentación al usuario lo antes posible. Así que una sola acción de añadir al carrito no toma como cinco segundos o así. ¿Cómo se ve eso en la práctica? Así que si hago clic aquí, puedes ver que el LLM está generando todo esto sobre la marcha. Y ahora uno de los beneficios de trabajar para una gran empresa es que tengo acceso a todas las nuevas herramientas para que podamos ver lo que realmente está sucediendo en el fondo y cómo el LLM transmite esas cosas. Así que primero tenemos el prompt del sistema, luego hemos ajustado todos los datos. Luego estas son nuestras capacidades que le dimos. Ups, esta es la solicitud anterior.

Está transmitiendo comandos, así que nos está diciendo, nos está diciendo, crea este nodo, crea este nodo, crea este nodo, crea este nodo. Y la forma en que estamos reconstruyendo el árbol es que los referenciamos por ID y ID de padre. Así que decimos que este nodo va bajo este nodo y este nodo va bajo este nodo. Y de esta manera podemos tener transmisión desde el LLM pero al mismo tiempo podemos reconstruir una estructura similar a un árbol que es el DOM.

Así que lo siguiente que quiero añadir, si ves esta interfaz de usuario es un poco fea, así que eso no es subjetivo, es realmente fea. Y sí, lo que quiero hacer es realmente ajustar nuestro propio sistema de diseño para que sea nuestro próximo punto de control. Demos al modelo nuestro sistema de diseño y en el esquema, ese será nuestro próximo punto de control, en el esquema ajustaremos no solo nuestros propios tipos, déjame encontrar esto, no solo nuestros tipos de nodo sino más bien los tipos de todos los elementos del sistema de diseño personalizado que tenemos. Podemos tener un botón personalizado, una tarjeta personalizada, un componente de tarjeta personalizada, lo que sea, y queremos habilitar al LLM para usar nuestros componentes, para que la UI se mantenga igual.

No solo eso, los LLM son realmente buenos usando clases de utilidad, cosas como Tailwind. Podemos enseñarle a utilizar nuestros propios primitivos, para que use nuestros propios colores, nuestros propios espacios y nuestra propia tipografía para generar la interfaz de usuario y se mantenga igual que el resto de nuestro sitio web. Ahora al hacer clic aquí, no solo comenzará a transmitir, estaremos buscando nuestro botón blanco y deberíamos verlo por aquí.

No solo eso, el LLM se mantiene consistente utilizando nuestros primitivos de diseño a través de clases de utilidad para también usar la tipografía, el espaciado y todo lo demás. Y también comenzó a generar este diseño de cuadrícula, no es realmente bueno en la capacidad de respuesta pero se lo concederé. Así que finalmente, comenzamos dándole solo los datos de muestra y quiero cambiar eso en producción. Los datos provienen de muchas fuentes, la mayoría de ellos son estáticos. Así que en lugar de datos codificados, quiero darle al LLM la capacidad de consultar sus propios datos. Para esto usaré una base de datos RAC que he preparado de antemano. Así que volcamos toda la información que actualmente tenemos para esta demostración, que son las licencias, los complementos adicionales, todo lo que está sucediendo en nuestra aplicación y simplemente dejaremos que el LLM decida qué es relevante para la consulta del usuario y no recupere gigabytes de datos. Así que cambiando a nuestro último punto de control, dándole un poco de tiempo, es código en vivo para un LLM, uso el modelo más rápido posible. Así que lo dejaremos terminar y luego veremos qué está sucediendo en el fondo y cómo está solicitando los datos. Así que para esta interfaz de usuario exacta, creo que debería hacer una consulta de datos, herramientas, en algún lugar. Así que está obteniendo los datos del backend real construyendo como necesito todas las licencias relevantes. Así que si hago nuestra próxima cosa, que es quiero postularme para un trabajo, el LLM no solicitará los datos de la licencia porque esto no es relevante para nuestra solicitud actual, sino que pediría las posiciones abiertas actuales. Así que quiero completar todo el flujo con la licencia para hacer una última ejecución. Intentaré agregar una sola licencia de equipo, en realidad dos licencias y agregaré algo extra. Los agregaré al carrito. Y veremos que el LLM está generando una interfaz de usuario adicional en lugar de reemplazar toda la interfaz de usuario. Y finalmente, nos dará la capacidad de realizar el pago. Así que intentemos realizar el pago. Ese es mi número de tarjeta de crédito no real, pero al hacer clic en el pago, el LLM ha construido una serie de elementos de formulario para avanzar en el flujo de trabajo. Así que con esto concluido, quiero volver a nuestra presentación y ver lo que hemos hecho. Tomamos a los usuarios de los datos, el estado, las capacidades y nuestro sistema de diseño. Damos todos esos argumentos a un modelo de lenguaje grande y generó una interfaz de usuario sobre la marcha, moviendo al usuario hacia adelante sin ninguna interfaz de usuario predefinida por otros desarrolladores más allá de nuestros primitivos de sistema de diseño. Y lo que esto nos permite hacer es eliminar el laberinto. Así que solo nosotros como desarrolladores somos libres de agregar cualquier funcionalidad, enfocarnos en la parte comercial de nuestra aplicación y simplemente dejar que el usuario o el flujo comience desde el usuario y no al revés. Y esta demostración tomó un poco de tiempo para generar interfaces de usuario. Y hoy creo que el cuello de botella es realmente el LLM, el modelo de IA real que está detrás de él. Pero creo que en el futuro eso no será el caso. Y si quieres construir las experiencias del futuro, deberíamos comenzar a construir las herramientas del mañana desde hoy. Así que esta fue mi charla. Muchas gracias.

Tenemos un stand. Puedes echarle un vistazo. En primer lugar, fue una charla realmente buena y también una buena demostración en vivo. Realmente, realmente disfruté el hecho de que nos mostraras los prompts porque creo que la ingeniería está cambiando. Así que las demostraciones en vivo de ingeniería van a cambiar. Eso va a ser muy interesante.

Y la primera pregunta que llegó habla sobre la subvención. Entonces, por ejemplo, tokens, el precio de un token. Un segundo. Pausa, amigos, aquellos de ustedes que están saliendo de la sala.

Absolutamente. Está bien. ¿Te importaría bajar la voz para que aquellos de nosotros que estamos aquí y participando en la sesión de preguntas y respuestas también podamos escuchar y para que el orador también pueda escuchar? Muy bien. Entonces, dado el hecho de que estamos obteniendo la descontinuación de las facturas de LLM subvencionadas, los tokens se están volviendo más caros, eventualmente vamos a seguir este gran camino de, está bien, vamos a comenzar a almacenar en caché respuestas similares.

Entonces, ¿por qué no lo aseguramos? Y eventualmente nos encontramos de nuevo en sitios web estáticos. Eso es absolutamente posible. Los usuarios podrían saltar directamente a, puedes acortar la distancia entre el usuario que llega a tu sitio web y compra algo en este, haciendo su trabajo. Y al final, podría ser más barato hacerlo dinámicamente en lugar de tener esas interfaces de usuario y patrones predefinidos que los usuarios simplemente están luchando por atravesar. Eso es interesante.

Creo que hay mucha gente que está realmente emocionada. Esto parece técnicamente realmente, realmente genial. Pero están haciendo la pregunta más grande sobre el por qué. Hay algunas preguntas sobre esto. Así que voy a agruparlas porque una de estas preguntas era sobre casos de uso. Entonces, como, ¿qué tipo de caso de uso dirías que es realmente, realmente bueno para, como esta idea de una UI dinámica que se está generando?

Oh, eso es realmente agradable. Puedo pensar en dos, de hecho. Uno es que puedes tener una versión Swash Explore de tu sitio web. Así que puedes tener tus caminos predefinidos, pero puedes tener una página de exploración donde solo saludas a tu usuario con un prompt y solo ves de dónde vienen. Podrían estar explorando la documentación, podrían estar buscando invertir en tu empresa y simplemente explorarlo a través de tu sitio web. Y el segundo está surgiendo últimamente, que son las aplicaciones MCP, donde ya tienes un LLM y quiere generar una interfaz de usuario dentro de los prompts.

Así que el concepto está ahí. Es solo que el consumidor es diferente. No es tu sitio web. Es tu usuario a través de una interfaz de chat. Es realmente interesante porque creo que este es un caso donde la tecnología existe y estamos descubriendo los casos de uso para ella a medida que avanza. Muchas gracias por eso. Esas fueron como un montón de preguntas diferentes que voy a agrupar bajo ese tema y luego pasar a las otras.

La siguiente, y hay como este siguiente conjunto de temas, que es todo sobre pruebas. Porque, quiero decir, piensa en los ingenieros. Nos encanta cuando las cosas son deterministas. Todos hemos estado allí cuando estamos tratando de recrear un error o incluso tratando de recrear cosas funcionando, y no está en nuestra máquina. Así que voy a hacer esta pregunta, y hay algunas otras preguntas que estaban relacionadas. ¿Cómo realizarías pruebas de regresión de extremo a extremo en tales aplicaciones? ¿Hay alguna herramienta que usarías? Evitamos pruebas inestables, pero esto parece un caldo de cultivo para pruebas inestables. Y luego, si no vas a usar una herramienta de prueba de extremo a extremo, ¿cómo asegurarías la calidad de la aplicación? Yo diría de la misma manera que pruebas cualquier agente básicamente. Básicamente, solo solicitas la interfaz de usuario de ella y no otra cosa. Así que cosas como evaluación comparativa, evaluación de problemas, y cosas así. Y no la típica prueba de usuario de extremo a extremo que estás probando el LLM y sus capacidades, no la interfaz de usuario en sí.

Esa es una muy buena respuesta también. Y el hecho de que lo estaríamos evaluando de la misma manera que evaluamos otros agentes y la forma en que funcionan. Y esto genera otra pregunta, que es, lo hemos evaluado, estamos haciendo un seguimiento. Notamos que a veces está haciendo lo suyo, se está saliendo de los rieles. ¿Qué medidas de seguridad son necesarias para asegurar una experiencia de usuario adecuada y prevenir que los usuarios hagan algo que no queremos? Y aquí es donde se ramifica en dos, accidentalmente y deliberadamente. Así que, ¿por qué no empezamos con lo accidental, un usuario que está muy inocentemente tratando de trabajar a través de la aplicación. Asegúrate de que sigan caminos aprobados, incluso si están creando su propio camino. Yo diría que puedes tener una colección más grande con componentes predefinidos que hagan más cosas. Por eso incluí la parte del sistema de diseño. Así que puedes darles botones, puedes darles entradas, pero también puedes darles un componente de tarjeta completo que mantendría los pagos reales, para que no se desvíen de eso. Y eso es realmente interesante también porque la siguiente pregunta está muy, muy vinculada a la respuesta, que es, ¿la UI generativa solo puede crear componentes de los que dimos contexto? ¿Cómo evitamos, además de crear componentes con datos que no existen? Así que creo que hablaste un poco sobre darle algo de contexto, aquí hay una tarjeta o aquí hay datos y cómo se conecta a nuestro sistema. Así que puede usar eso. ¿Cómo te aseguras de que va a usar esos en lugar de inventar algo por su cuenta? Creo que la alucinación es un problema común en los LLMs.

Así que la idea no es ajustarlo con no alucines, no alucines en el prompt del sistema, sino más bien construir un sistema alrededor de él que sea confiable y tenga todos los pasos de validación necesarios para asegurarse de que está usando datos relevantes. Así que dale la herramienta para consultar un dato y lo preferirá cada vez en lugar de inventar datos arbitrarios. ¿Y cuáles son algunas de las, y esto es, realmente me interesa esto, cuáles son algunas de las formas en que podemos asegurarnos de crear esos sistemas? ¿Hay alguna lista de verificación o consejo que puedas darnos para pensar mientras estamos asegurándonos de darle toda la información que necesita para que no alucine? Básicamente validas las cosas antes de pasarlas al LOM, luego validas las cosas que pasas al LOM, que básicamente son herramientas y el prompt del sistema en sí. Y después de eso, le das una herramienta para validarse a sí mismo. Esto es lo que he explorado últimamente, es que si le das al LOM la herramienta para validar su propio output, puede dar vueltas y vueltas hasta que todo esté bien. Absolutamente. Absolutamente.

De acuerdo. Voy a omitir la pregunta de pruebas porque ya la cubrimos antes. Pero la siguiente es sobre cambiar modelos. Ahora, lo bueno de ahora es que mucha gente siente que puedes cambiar entre modelos con bastante facilidad y cosas así. Y a menudo el usuario, tal vez pueda ver una diferencia en la generación de texto, pero no necesariamente va a tener un impacto masivo. Pero ahora estamos haciendo componentes, UIs, cosas que requieren mucha más complejidad. ¿Has visto, tal vez mientras trabajas con diferentes modelos, alguna gran diferencia en el output y la calidad de los componentes que se generan y transmiten según el modelo que usas? No específicamente. Mientras el modelo pueda utilizar llamadas de herramientas, lo cual creo que todos los modelos más recientes hacen, debería estar bien. Y he usado deliberadamente el modelo más barato y rápido, que es la versión nano de GPTs. Y puedes usar Heiko para una cita o incluso un modelo local que puedes usar solo para describir esas cosas. Pero la otra cosa es el gusto. Y no puedes enseñar gusto al LLM. Así que tal vez trabaja con habilidades o simplemente dale tu sistema de diseño. Y si tu sistema de diseño está estructurado correctamente, será intuitivo para el propio LLM. Sí. No podemos enseñar gusto a los LLMs, así que todavía nos van a necesitar a nosotros los ingenieros.

Gracias. Amigos, démosle una ronda más de aplausos. Muchas gracias.