Migración de Bibliotecas de Componentes de UI Potenciada por LLM

Hola a todos. Gracias por unirse a mi charla hoy. En la sesión de hoy, hablaré sobre cómo en Zalando utilizamos LLMs para impulsar la migración de bibliotecas de componentes en nuestra aplicación de una biblioteca de componentes a otra. Antes de comenzar, una breve introducción. Soy Nawal. Soy ingeniera principal en Zalando. Zalando, si no estás familiarizado, es una de las principales plataformas de moda en Europa y colabora estrechamente con miles de marcas en todo el mundo.

Mi equipo es responsable de construir las plataformas, herramientas y bibliotecas de componentes que son utilizadas por otros equipos de ingeniería dentro de Zalando para construir sus propias aplicaciones B2B externas y estas aplicaciones externas son luego utilizadas por las marcas o nuestros socios para interactuar con Zalando y gestionar su negocio en Zalando. Como parte de la operación y mantenimiento de esta plataforma central, encontramos diferentes tipos de migraciones en nuestro trabajo diario. Estas migraciones pueden variar desde simples actualizaciones de versión, por ejemplo, actualizar de React 18 a 19.

Sin embargo, pueden ser migraciones más complejas como migrar de una biblioteca de componentes a otra o migrar de un marco de UI a otro o actualizar la temática de marca de nuestras aplicaciones. Una cosa fundamental sobre todas estas migraciones que llevamos a cabo es que no solo tenemos que realizar la migración para nuestras propias plataformas y herramientas centrales, sino que cuando planificamos la migración, tenemos que planificar para cada aplicación que se ejecuta en nuestra plataforma. Así que eso significa que para estas migraciones tenemos que pensar en cómo podemos automatizar a escala y llevar a cabo la migración de manera más eficiente.

Ahora hablando de un problema de migración que encontramos recientemente. En Zalando para nuestras aplicaciones externas B2B, había dos bibliotecas de componentes diferentes que se estaban utilizando. Estas bibliotecas de componentes tenían estructuras totalmente diferentes, tenían diferentes interfaces, tenían diferentes componentes y tenían diferentes filosofías de diseño. Mantener dos bibliotecas de componentes diferentes era un poco costoso porque teníamos que duplicar nuestro esfuerzo y también reducía la consistencia de las UIs para nuestros socios. Los socios verían diferentes UIs dependiendo de en qué aplicación estuvieran.

Por lo tanto, queremos unificar en una sola biblioteca de componentes. Queríamos migrar todas las aplicaciones usando la biblioteca de componentes que ves en la parte superior. Digamos que la biblioteca fuente a una biblioteca de componentes en la parte inferior, digamos biblioteca objetivo. Sin embargo, esta migración de la biblioteca de componentes fuente a la biblioteca de componentes objetivo fue un esfuerzo muy grande. Si hablamos en días de desarrollador, se esperaba que tomara más de un año completar y por lo tanto queríamos ver cómo podíamos automatizar esta migración y hacerla más rápida.

Primero, intentamos con codemods. Los codemods son como el enfoque tradicional para manejar estas tipos de migraciones. Los codemods funcionan modificando directamente el árbol de sintaxis abstracta o AST para abreviar. Un simple AST para una declaración de importación puedes ver en el lado derecho. Como puedes ver, si quieres cambiar el nombre del paquete de old UI a digamos new UI, todo lo que tienes que hacer es encontrar dónde en el AST está el valor de old UI y luego convertirlo al nuevo valor y luego convertirlo de nuevo al código. Así que los codemods son realmente muy eficientes y hacen las transformaciones y son muy rápidos y deterministas y son una herramienta bastante buena para manejar muchas diferentes migraciones.

Sin embargo, para nuestro caso de uso, lo que descubrimos fue que los codemods no eran una buena opción. Hubo algunas razones para esto. La primera razón fue que había muchas variaciones en nuestra base de código y si teníamos que crear codemods para atender cada caso de uso, los codemods rápidamente se volvían muy engorrosos y desafiantes. Por ejemplo, si tomo el elemento de tipografía que es digamos el elemento más simple que tenemos e incluso en este elemento había muchas variaciones diferentes y los equipos estaban usando diferentes prácticas. Por ejemplo, algunos equipos usaban los elementos directamente. Sin embargo, algunos equipos asignaban la tipografía a un valor más corto y luego lo usaban. Algunos equipos también usaban el objeto de encabezado y lo asignaban a una variable y luego lo usaban. Algunos equipos no usaban el contenido como componente de texto sino que lo usaban solo como una propiedad. Así que como puedes ver, había muchas variaciones diferentes y llegar a cada variación rápidamente se volvía muy desafiante.

Otra limitación que notamos para los codemods fue que teníamos que hacer muchas migraciones complejas. Si miras la imagen en el lado derecho, puedes ver que cuando tenemos que migrar el componente select desde la biblioteca fuente a la biblioteca objetivo, no solo tenemos que migrar el componente sino también los datos en ese componente. Por ejemplo, aquí las opciones de selección son una variable que es generada por una lógica de negocio de iterar sobre las opciones y eso significa que si tenemos que aplicar codemods, debemos tener cuidado de que la lógica de negocio se mantenga intacta. Además, hay otras variaciones posibles aquí. Por ejemplo, aquí es una variable pero puede ser una función nombrada, una función flecha y así sucesivamente. Así que como puedes ver, el desafío aquí era que había tantas variaciones y complejidades que los codemods eran un poco imprácticos y lo que queríamos era alguna herramienta que pudiera entender por sí misma la relación entre diferentes partes del código y la diferente lógica que está sucediendo en el código y luego la combinamos con nuestras instrucciones y la herramienta puede hacer la migración.

Así que una buena opción para eso eran los LLMs. Y los LLMs o modelos de lenguaje grande eran algo que ya estábamos usando para nuestros propósitos de codificación a través de la interfaz de usuario de co-pilot o herramientas similares. Sin embargo, nunca habíamos usado LLMs o modelos de lenguaje grande a esta escala y teníamos muchas preguntas abiertas al respecto. ¿Puede realmente manejar esto el LLM? Quiero decir, teníamos la idea de que teóricamente podría funcionar pero no estábamos seguros de si puede manejar este tipo de migraciones. Además, las bibliotecas o bibliotecas de componentes que teníamos eran bibliotecas internas y los LLMs no estaban entrenados en ellas. Así que otra pregunta era cómo podíamos usarlos. Finalmente, qué tipo de precisión o consistencia podíamos esperar de este LLM. Así que en lugar de sumergirnos directamente en la implementación, lo que decidimos fue tener una exploración de tres días. Nos sentaremos como equipo e intentaremos responder estas preguntas abiertas una por una y evaluar si los LLMs pueden ser utilizados para nuestro propósito o no.

Aunque llevamos a cabo muchas actividades durante nuestra fase de experimentación, me gustaría centrarme en esta presentación en una serie de experimentos iterativos que realizamos para mejorar la precisión del resultado y asegurar que los LLMs puedan transformar nuestros componentes correctamente. Para la primera iteración, lo que hicimos fue simplemente pasar los archivos fuente del componente al LLM. Luego le dimos al LLM un archivo de prueba que contenía diferentes usos de los componentes con variada complejidad y le pedimos que lo migrara y queríamos ver qué tan bien podía hacerlo. Los resultados no fueron muy buenos. LLM no pudo transformar los usos complejos. Podía transformar los usos simples pero no podía transformar los usos complejos. El problema era, después de investigar, que pedimos al LLM que hiciera demasiadas cosas de una sola vez o en un solo paso. Por ejemplo, leer el archivo fuente, extraer la interfaz, crear las instrucciones del transformador por sí mismo, luego hacer la migración y ocuparse de demasiados pasos redujo la precisión y causó que el LLM fallara.

Luego intentamos una segunda iteración donde intentamos simplificar la cantidad de datos y el contenido que enviamos al LLM al no dar el archivo fuente sino dar la interfaz detallada del componente. Esta interfaz contenía toda la información que el LLM necesitaría saber sobre el componente como las propiedades, los subcomponentes, los valores predeterminados, etc., y luego le pedimos que hiciera lo mismo. Sin embargo, aquí tampoco el LLM hizo un buen trabajo. Podía transformar archivos simples o usos simples pero no podía transformar usos más complejos. Una razón fue que el LLM estaba perdiendo mucho contexto aquí. Para dar un ejemplo, en la biblioteca fuente el componente botón tenía tres tamaños diferentes, pequeño, mediano, grande, mientras que en la biblioteca objetivo solo tenía dos tamaños, pequeño y grande. Entonces, si el LLM encuentra un botón de tamaño mediano, ¿qué debería hacer? ¿Dónde debería colocarlo, pequeño o grande?

Este tipo de preguntas el LLM no pudo responder y por eso hubo problemas. Luego comenzamos la tercera iteración donde pusimos el mismo prompt que antes pero también dimos instrucciones de migración paso a paso que le decían al LLM cómo manejar este caso y también aclaraban cualquier ambigüedad que el LLM tuviera. Los resultados fueron definitivamente mejores esta vez. Sin embargo, todavía había alguna inconsistencia. Parte de la lógica de negocio más compleja no fue migrada. Algunas cosas como limpiar las importaciones antiguas o variables no utilizadas tampoco se hicieron correctamente. En este punto, comenzamos a investigar qué podíamos hacer para mejorar el resultado. Por ejemplo, miramos alrededor y revisamos diferentes artículos de investigación, etc. Lo que descubrimos es que si proporcionamos patrones que podrían realmente aumentar la precisión del LLM y eso es exactamente lo que hicimos. Junto con el contexto anterior, también pasamos un conjunto de ejemplos de transformación que eran simplemente ejemplos de antes y después y los pasamos. Con esto, la precisión del LLM fue bastante buena. Tenía un 90% de precisión y estábamos bastante satisfechos con ello y luego decidimos proceder más allá. Una pequeña nota sobre la precisión, como usamos una métrica para calcular qué tan bien se comportaba el LLM y esta métrica de precisión era simplemente el número de líneas que fueron correctamente migradas por el LLM dividido por el total de líneas de código migradas. Por correctamente, me refiero a que si había importaciones no migradas correctamente o algunas variables no utilizadas o algunos errores, esos fueron excluidos y luego calculamos estas métricas. Ahora, una vez que la estructura del prompt o fue definida, así es como se veía el prompt final.

fue definida, así es como se veía el prompt final. Tenía cuatro secciones. Las primeras tres secciones, como mencioné antes, son solo la interfaz, las instrucciones de mapeo y los ejemplos que fueron generados y la sección final era el archivo que se necesitaba, que debía ser transformado.

Una cosa a tener en cuenta aquí es que mantuvimos la interfaz, las instrucciones y los ejemplos en la parte superior porque estos no diferían de un archivo a otro. Para un componente, siempre eran los mismos y de esta manera, podíamos, de esta manera, esto podía ser almacenado en caché y podíamos ahorrar algunos costos en el lado de LLM debido al almacenamiento en caché del prompt. Una vez que el prompt estaba listo, decidimos construir una pequeña herramienta, que era una herramienta CLI. Esta herramienta, lo que hacía era en el primer paso, escanear todo el repositorio para encontrar todos los archivos que contenían los componentes que queríamos migrar. Luego, construía el prompt con los componentes como mostré en la diapositiva anterior y el archivo y luego lo enviaba al LLM para la transformación.

LLM tomará el archivo, lo transformará y lo enviará como respuesta, que luego era extraída por la herramienta y se aplicaba al archivo existente y se comprometía. Y luego, se creaba una revisión para que un ingeniero la verificara, la probara y luego la fusionara y desplegara. Ahora, hablando un poco sobre los detalles técnicos, usamos muchas herramientas diferentes. Estas herramientas eran de código abierto, pero realmente nos ayudaron a reducir mucho el esfuerzo y también mucho tiempo. Usamos una herramienta llamada continue.dev. Continue.dev hizo que fuera muy fácil crear los prompts. Todo lo que teníamos que hacer era dar los archivos fuente a la herramienta y luego pedirle que generara las instrucciones, la interfaz y los ejemplos y era capaz de hacerlo fácilmente.

muy agradable que nos permitía interactuar con LLM y también continuar respuestas si se cortaban, etc. Finalmente, también utilizamos una herramienta, AIDAR, que también estaba basada en IA. Esta herramienta nos ayudó a automatizar los git commits y también ayudó a crear un buen mensaje de commit y descripción para que el usuario que va a revisar la pull request, sepa lo que se ha hecho y haga las revisiones de solicitudes más fáciles para ellos. Para la herramienta, también teníamos un marco de pruebas de regresión en su lugar. Lo que teníamos era un conjunto dorado de ejemplos de migración antes y después y cada vez que hacíamos cambios en los prompts, intentábamos ejecutar la herramienta nuevamente en los ejemplos anteriores y luego compararlo con los ejemplos posteriores. Lo comparábamos manualmente o bien a través de LLM y esto se utilizaba para ver si había alguna regresión o disminución en la precisión de la herramienta.

También era muy útil si queríamos probar un nuevo modelo y ver cómo ese modelo se comportaba. Esta configuración de regresión fue muy útil para nosotros. Otra cosa que tuvimos que hacer para mantener la precisión de la salida de LLM fue gestionar el tamaño del contexto de los prompts que enviábamos a la herramienta. Primero, queríamos intentar ejecutar la herramienta con tantos componentes como fuera posible. Sin embargo, lo que notamos es que si el tamaño del contexto se vuelve muy grande, la precisión de la salida comenzaba a degradarse bastante.

Así que lo que, después de un poco de prueba y error, descubrimos es que alrededor de 40,000 tokens era un buen tamaño para el prompt y eso es lo que usamos para nuestra herramienta. Así que migramos un pequeño conjunto de componentes, asegurándonos de que el tamaño de los tokens estuviera por debajo de 40,000 tokens. Ahora, hablemos un poco sobre cuál fue el resultado. Pudimos migrar más de 11 aplicaciones B2B complejas. Estas aplicaciones eran aplicaciones bastante complejas. Se esperaba que la migración de cada una de estas aplicaciones tomara entre uno a cuatro meses y LLM asistió en esta migración realizando las tareas de transformación o migración más repetitivas y comunes, configurando nuestro equipo de diseño de producto e ingeniería para centrarse en tareas más desafiantes, puliendo la UI, refinando errores, probando y luego desplegando y fusionando. LLM también realizó las transformaciones o migraciones con una precisión muy alta del 90 por ciento o más. Y muchos de estos, y no hubo problemas específicos aquí. Hubo algunos errores aquí y allá, pero la mayoría de las cosas eran solo entradas no utilizadas. Así que esto aseguró que nuestros ingenieros no necesitaran pasar mucho tiempo corrigiendo problemas causados por LLMs. El costo por repositorio para nosotros fue de 40 USD. Si miras cuánto esfuerzo nos ahorró LLM durante esta migración, fue un muy buen retorno de inversión. Por otro lado, también enfrentamos un incidente aquí. Este incidente se debió al hecho de que cuando LLM migró los datos esperados por un componente, LLM cometió un error en esa migración. Sin embargo, este problema fue muy difícil de detectar y también se pasó por alto durante la revisión, resultando en que el código se desplegara en producción y los usuarios vieran una página rota. Dos aprendizajes de este incidente para nosotros fueron, primero, LLMs pueden generar un código bastante plausible, que parece plausible, pero puede ser incorrecto. Y por eso es muy importante que siempre que tengas algo como esto, algún código generado por LLM, lo revises muy cuidadosamente. Otro problema fue que cuando LLMs migran el código, puede crear una brecha de conocimiento porque los usuarios no lo han migrado ellos mismos.

Así que, y esto en realidad puede causar un incidente o puede hacer que la depuración sea difícil y así sucesivamente. Y lo que recomendamos aquí es que un equipo debería básicamente estar tan cerca del código como sea posible, intentar incorporarse e intentar entender lo que está sucediendo para que este tipo de problemas no ocurran. Dando un ejemplo de cómo se vería la migración. Como pueden ver, este es un ejemplo de un PR, que fue básicamente hecho por el LLM. Pueden ver, es un PR muy grande. Así que si pueden imaginar la cantidad de esfuerzo que nos ahorró cuando la migración automatizada fue realizada por el LLM.

También hizo un muy buen trabajo al migrar los diferentes componentes. Una cosa interesante es que si miran el componente select, el componente select tenía un poco de lógica dentro de él. Por ejemplo, tenía un map, que en realidad iteraba sobre las opciones de selección. Y también había un componente de texto dentro de la opción de selección. El LLM pudo migrar todo esto con éxito. Extrajo la lista de opciones y la convirtió en un objeto. También extrajo la función y la puso en el campo de etiqueta. Así que como pueden ver, LLM pudo realizar con mucho éxito transformaciones complejas de varios pasos sin ninguna información extra o adicional.

Luego hay algunos ejemplos más que me gustaría compartir donde los LLMs hicieron un trabajo bastante bueno. Este fue un popup de notificación y en la biblioteca de origen, el popup de notificación tenía un tiempo de espera de 4.5 segundos. Pero en la biblioteca de destino, no había tiempo de espera para el popup de notificación. Tenía que ser especificado explícitamente. Y aunque no instruimos al LLM para hacerlo, automáticamente tomó el valor predeterminado de la fuente y lo agregó aquí. Así que se puede ver lo inteligentes que son los LLMs en algunos casos. Además, solucionó un problema en uno de los nombres de función. Este problema fue, no sé, por mucho tiempo, pero aún así pudo solucionar este tipo de problemas. Hablando de los desafíos, la alucinación e ignorar instrucciones son algunas de las preocupaciones más comunes cuando usamos LLM.

Y también vimos el mismo problema. Un ejemplo es este campo exclusivo, que no estaba en nuestras instrucciones, por ejemplo, pero LLM aún lo agregó. Otro problema es que la salida no siempre es determinista. Algo que funcionaba hoy puede empezar o dejar de funcionar mañana. Por ejemplo, si miras la imagen en la parte inferior, puedes ver que cambió el nombre de la función de un correcto a uno incorrecto. Algo así no sucede cada vez, pero puede suceder, digamos, una vez cada 10, 15 ejecuciones. Teníamos la temperatura configurada en cero, pero aún así sucedió. Y estas son las cosas que pedimos a nuestros ingenieros que vigilen durante las revisiones.

Otro problema fue que tuvimos que gestionar los prompts con mucho cuidado. Si el input era muy grande, entonces la precisión del prompt comenzaba a disminuir y los LLMs no podían transformarlo muy correctamente. Y por lo tanto, tuvimos que tener cuidado con eso. Otro problema fue que las respuestas eran bastante lentas, especialmente en comparación con los code mods. Cada respuesta de LLM tomó alrededor de 30 a 200 segundos por archivo. Y aunque esto no fue un problema durante la migración, ya que la herramienta de migración podía ejecutarse en segundo plano, sin embargo, ralentizó nuestras fases iterativas y experimentales debido a este tiempo tomado. También hubo algunas restricciones relacionadas con el proyecto debido a las cuales no pudimos usar la herramienta a su máxima capacidad. Por ejemplo, hubo restricciones de tiempo debido a las cuales no pudimos migrar los casos de prueba. Hubo algunas diferencias en los componentes donde cada uno de ellos necesitaba ser manejado caso por caso. Y hubo muchas variaciones en las bases de código, lo que hizo que el uso de la herramienta fuera más desafiante.

Ahora, hablando de las lecciones aprendidas, los LLMs son bastante efectivos. A través de este proyecto, pudimos ver que los LLMs fueron bastante efectivos para nuestra migración y ahora hemos estado usando LLMs en todas nuestras migraciones futuras también. El enfoque iterativo y experimental que aplicamos durante este proyecto resultó ser muy útil. Y este es el modelo que usamos siempre que tenemos algunas preguntas abiertas sobre la claridad acerca del uso de LLMs en nuestro proyecto. Los LLMs pueden migrar, pero no transfieren el conocimiento. Y esto puede, como mostré antes, causar problemas en la depuración o incluso causar incidentes en el peor de los casos. Por lo tanto, nuestra recomendación para los equipos es que se mantengan al tanto del código, sepan lo que está sucediendo y si hay algo nuevo, intenten incorporarse a esa base de código. Como se mostró en la diapositiva anterior, hubo muchos problemas inesperados causados por los LLMs y los equipos necesitan asegurarse de que haya algún ingeniero que esté revisando cada cambio y revisándolo cuidadosamente porque los LLMs aún pueden cometer muchos errores. Usamos muchas herramientas y estas herramientas fueron muy útiles para reducir nuestro tiempo y también reducir nuestro esfuerzo. Estas herramientas también son como un paisaje que se mueve muy rápido. Siempre, obtenemos nuevas herramientas todo el tiempo en este espacio. Por lo tanto, siempre que comenzamos un proyecto, primero evaluamos qué herramientas podemos usar para esto.

Finalmente, las mejores prácticas de PROMPT y la ingeniería de PROMPT no son solo una palabra de moda, es algo que es muy útil para mejorar la precisión de tu salida. Lo usamos mucho. Por ejemplo, usamos patrones, lo usamos para descomponer un conjunto complejo de PROMPTS en otros más pequeños para que los LLMs puedan manejar esto mejor, etc. Así que, aplicar la ingeniería de PROMPT definitivamente vale la pena.

Finalmente, este proyecto fue algo que hicimos hace algún tiempo y ahora la pregunta es si esto de lo que hablamos es aplicable hoy también. El panorama ha evolucionado ahora. Hay mejores herramientas, los modelos son mucho mejores ahora, los conceptos también son más nuevos como MCP, Cloud Code y todas esas cosas. Sin embargo, lo que diría es que el enfoque central todavía se mantiene. La discusión central de la que hablamos sigue siendo precisa, pero ahora tenemos mejores herramientas para experimentar y usarlas.

Todavía diríamos que los code mods son muy útiles para transformaciones predecibles ya que son rápidos, deterministas y no tendrían sorpresas. Todavía usaríamos LLMs y la biblioteca para migraciones simples donde tenemos que migrar un archivo con mucha lógica de negocio como las migraciones de la biblioteca de componentes. Sin embargo, una limitación de la herramienta actual era que no funcionaba bien con casos donde había cambios en varios archivos, que la herramienta primero necesitaba entender y luego hacer los cambios. Nos encontramos con un caso de uso así cuando estábamos migrando un marco interno a otro en nuestro departamento.