¿Ya estamos listos para pasar de Figma a React con IA?

Hola a todos. Hoy vamos a hablar sobre la IA y en particular, cómo los recientes avances en las tecnologías de IA nos van a permitir en un futuro cercano escribir mejor código React, más rápido y al mismo tiempo automatizar algunas de las partes aburridas de nuestro trabajo.

Así que antes de empezar una breve presentación, soy Federico, soy un arquitecto de software en Anima y nuestra misión es automatizar tanto como sea posible las partes aburridas del desarrollo front-end. Así que si estás interesado, visita animaapp.com. Dicho esto, comencemos.

Como desarrollador front-end, solía centrarme mucho en cómo escribir un buen código React. Pero eso no es lo que vamos a discutir hoy. Hoy no seremos desarrolladores tratando de escribir código React, sino más bien desarrolladores tratando de crear una máquina que escriba código React para nosotros automáticamente. Y vamos a empezar este viaje con una historia.

Trabajé durante aproximadamente un año como desarrollador front-end. Y mi trabajo diario implicaba muchos de los problemas con los que estoy seguro que todos ustedes están muy familiarizados como la interfaz con APIs, gestión de estado, optimizaciones de rendimiento. Pero había una tarea en particular que encontraba extremadamente tediosa. Cada vez que teníamos que implementar una característica, un diseñador venía a mí con un diseño, generalmente en Figma, y luego me pedía que lo hiciera realidad como una característica real. Pero antes de implementar la funcionalidad real, la lógica de negocio, lo que realmente me gustaba, mi primer trabajo era tomar el diseño y luego recrearlo dolorosamente en código, con todo el estilo, estructura, elementos, y así sucesivamente. Y como recrear un diseño pixel perfecto con código no es fácil, el proceso a menudo requiere un poco de ida y vuelta entre los desarrolladores y los diseñadores. Porque estoy seguro de que saben, los diseñadores son realmente buenos para detectar ligeras diferencias entre sus diseños y el código de producción. En fin, muy tedioso. Hasta el punto de que muchos desarrolladores empezaron a hacerse una pregunta, ¿podemos automatizarlo? Y si vamos desde una perspectiva de alto nivel, la pregunta es, ¿podemos traducir la información en un diseño de Figma en una representación de código? Y al principio, puede parecer una tarea imposible, ya que las dos representaciones parecen bastante diferentes.

Entonces, vamos a profundizar un poco en lo que es posible en Figma. En primer lugar, en un diseño de Figma, los nodos están estructurados en una jerarquía, que es muy similar a la estructura del DOM en una página HTML. Figma también soporta componentes, y esos componentes soportan propiedades, y esas propiedades pueden definir cosas como contenido de texto, visibilidad, instancias, y muchas otras cosas. Figma también soporta subcomponentes. Así que podemos tener un componente de botón en lugar de un componente de coche. Y finalmente, Figma incluso soporta acciones y eventos. Así que por ejemplo, puedo decir, cuando hago clic en este botón, abre esta página web. Y a estas alturas, podrías haber te dado cuenta de que esta información no es tan diferente de nuestro código React. Es más o menos la misma información, pero en una representación totalmente diferente. Y así que nuestra misión hoy es traducir la representación de Figma en una representación React. Antes de sumergirnos en este proceso de traducción, necesitamos discutir brevemente cómo acceder realmente a la información contenida en un diseño de Figma. Y resulta que Figma lo hace realmente fácil, porque no sólo proporciona una API para acceder a la información sobre un diseño, sino que proporciona dos.

Uno que se basa en REST, y otro que se basa en JavaScript. Si estás interesado, te recomiendo que consultes la documentation, pero para el propósito de esta charla, puedes básicamente pensar en un diseño de Figma design como un documento JSON. Esta estructura JSON contiene todos los nodos del design, junto con sus propiedades de estilo y otra información útil. Es como HTML, pero en JSON y usando propiedades específicas de Figma. La información contenida es más o menos la misma.

Entonces, tenemos este documento JSON que representa un design, ¿verdad? ¿Cómo lo convertimos en código? Y hay múltiples enfoques posibles, así que veamos algunos de ellos. Empezamos por el más básico, las heurísticas. Y quizás hayas oído hablar del término heurística antes. Para el propósito de esta charla, nos referiremos a las heurísticas como una colección de reglas que definen el comportamiento de nuestro sistema. En palabras simples, imagina un código que dice, si esto sucede, haz esto, de lo contrario haz aquello. Bastante sencillo.

Y en realidad podemos convertir un diseño de Figma design en código usando sólo heurísticas. De hecho, aquí hemos preparado una pequeña función de JavaScript que es menos de 20 líneas de código que puede convertir cualquier diseño de Figma design en código HTML más o menos funcional. Entonces, veamos lo que hace paso a paso. En primer lugar, la función toma como entrada un nodo de Figma. Luego necesitamos decidir a qué etiqueta HTML corresponde el nodo actual y usamos una regla muy simple. Si es un nodo de texto, hazlo un span, de lo contrario hazlo un div. Luego usamos un método de Figma llamado getCSSAsync que básicamente nos da una representación CSS aproximada de los estilos del nodo. Y finalmente, básicamente llamamos a la función recursivamente para todos los hijos. Luego podemos juntar toda esta información en una cadena HTML y si abro Figma, tengo un video aquí para mostrarte. Así que básicamente si abres Figma y vas a Plugin, Desarrollo, Abrir Consola, esto abre una consola en la que puedes pegar cualquier JavaScript que quieras ejecutar. Si pego la función que acabamos de crear, esto produce algún código HTML. Ahora si cogemos ese código HTML y lo pegamos en CodePen, dale un segundo, esta es la tarjeta. Eso es bastante impresionante.

Y la cosa es, déjame ir al siguiente, la cosa es que este es el código resultante y seguro que no está listo para producción. Es feo, es verboso, usa estilos en línea, pero la cosa es que funciona y nos llevó menos de 20 líneas de código. Así que puedes imaginar que aunque no sea perfecto, puedes extender estas heurísticas para manejar más y más casos y producir código de mayor calidad. Pero aunque la heurística puede llevarnos bastante lejos en la creación de código de alta calidad, no es una solución a prueba de balas y tiene sus problemas. Por ejemplo, digamos que quieres generar código que use clases CSS en lugar de estilos en línea. Uno de los problemas a los que te enfrentas es que necesitas idear buenos nombres de clase CSS para cada nodo.

Por ejemplo, el nodo body en Figma fue, necesitamos idear una clase para ese nodo dentro del código. El primer enfoque podría ser usar el nombre del nodo Figma como un nombre de clase CSS. Entonces, por ejemplo, puedes ver que el nodo body en Figma se convierte en un div con la clase body, el contenido se convierte en un div con la clase content y así sucesivamente.

Ahora, en teoría esto funciona, pero no estoy seguro de cuán familiarizado estás con los diseños de Figma del mundo real, pero generalmente a los diseñadores no les importa mucho el nombre correcto de las capas. En lugar de buenos nombres como body, content, title, verás cosas como frame 23, frame 32, button 3 y así sucesivamente. Y si alimentamos esto a nuestras heurísticas, el código resultante tendrá nombres de clase terribles.

Y para expandir esto, preparé una de mis citas favoritas, hay dos problemas difíciles en ciencias de la computación, la validación de la caché, nombrar cosas y errores de uno por uno. Y me encanta esta cita porque es divertida, pero también es realmente cierta. Nombrar cosas es difícil también para los humanos. Y es posible que no siempre lo notemos, pero nuestro trabajo requiere un alto grado de creatividad para resolver problemas. Resulta que las heurísticas carecen de creatividad. Es realmente difícil codificar como una heurística, una tarea que requiere creatividad. Como idear buenos nombres de clases CSS. Hace cinco años, este habría sido un problema muy difícil de resolver. Habrías necesitado un equipo completo de ingenieros de machine learning y semanas para abordarlo. Pero las cosas han cambiado.

Es posible que hayas oído hablar de esta reciente tecnología transformadora que, entre otras cosas, es realmente buena en tareas creativas. Y por supuesto, estoy hablando de grandes modelos de lenguaje como Chadjupt, Claude, Lama, o muchos otros. No podremos profundizar en los grandes modelos de lenguaje durante esta charla, pero en un los grandes modelos de lenguaje se entrenan en enormes conjuntos de datos, incluyendo proyectos de código abierto en GitHub, Wikipedia, Stack Overflow, en general, una buena parte de Internet. Y su trabajo, en resumen, es siempre predecir lo que viene a continuación. Entonces, por ejemplo, si alimento al modelo con, el CAD está en, podría decidir que la mesa es lo que viene a continuación. Y porque ha sido entrenado en código de código abierto, también conoce la estructura y convenciones de populares frameworks como React. Y entonces, si volvemos a nuestro ejemplo anterior con malos nombres de clases CSS, resulta que podemos resolver el problema en 20 segundos simplemente preguntando, carga un poco. Y aquí, le pido que reescriba este componente React para usar mejores nombres de clases CSS, y 20 segundos después, tengo un código que está usando nombres de clases CSS mucho mejores. Por ejemplo, user car container, user profile, user name heading, y así sucesivamente.

Y entonces, gracias a los recientes avances en IA, lo que solía llevar a un equipo entero semanas ahora toma segundos. Pero esto es solo la punta del iceberg de lo que es posible con estas tecnologías. Entonces, veamos otro caso de uso. En Anima, nuestro objetivo es pasar de cualquier diseño de Figma a un código que realmente pondrías en producción. Y eso es un problema muy difícil de resolver.

Una de las quejas comunes que recibimos de nuestros usuarios es que, aunque generamos código de alta calidad, no podían ponerlo en producción porque no seguía las convenciones de su equipo. Y ese es uno de los problemas de la code generation basada en heurísticas. Sería extremadamente difícil hacer una heurística que sea lo suficientemente general para manejar todas las posibles variaciones en convenciones, estilo de código, frameworks de estilos, state management, y así sucesivamente.

Entonces, ¿cómo generamos realmente código que siga las convenciones de cada equipo? Hace unos años, es posible que hayas visto una imagen como esta. Esto se llama transferencia de estilo neural, y es una técnica basada en aprendizaje profundo. La idea es que empiezas desde una imagen, en este caso un Lamborghini, y una referencia, en este caso una pintura de Van Gogh. Los alimentas en una red neuronal profunda, y obtienes como resultado un Lamborghini pintado al estilo de Van Gogh. En resumen, este proceso transfiere el estilo de la referencia, la pintura de Van Gogh, a la imagen original.

Te estarás preguntando por qué estamos discutiendo esto en una conferencia de React. La razón es que, desde una perspectiva de alto nivel, podríamos enmarcar nuestro problema de manera similar. Digamos que tenemos una heurística que genera código de alta calidad, pero desafortunadamente no es personalizado, no sigue las convenciones del usuario. ¿Qué pasaría si pudiera haber un sistema que tome como entrada tanto el código de alta calidad generado por heurísticas como las convenciones de tu equipo, combinándolos, básicamente tomando el código original y refactorizándolo para seguir la convención de tu equipo?

Ahora, veamos un ejemplo. Este es un código básico de React que generó una de nuestras heurísticas. El código funciona bien, pero nuestro usuario hipotético no está muy contento con él porque no sigue las convenciones de su equipo. Digamos que quieren usar funciones de flecha, quieren usar exportaciones nombradas y muchas otras cosas. Ahora, ¿cómo podemos resolver eso? Podríamos extender nuestras heurísticas para ser más y más y más complejas, para manejar más y más casos, pero eso no es escalable porque sabes cuán variable pueden ser las convenciones y el estilo y el state management entre los equipos.

Lo que podemos hacer hoy es, de nuevo, preguntar a charging PT. No entraré demasiado en los detalles del prompt que usamos, pero veamos los puntos clave. Empiezo enmarcando el programa. Eres un desarrollador frontend experto. Deberías refactorizar un proyecto de React para seguir las pautas dadas. Luego hay algunas plantillas, y finalmente las pautas. Deberías usar funciones de flecha para definir componentes, y luego los componentes deberían usar exportaciones nombradas. Y luego proporcionamos el código del componente, y después de unos 30 segundos, tenemos código de React que usa funciones de flecha, que usa exportaciones nombradas, y eso es exactamente lo que el usuario quería.

Entonces, para reiterar en esto, partimos de un código de alta calidad generado por heurísticas que era genérico, y luego usamos grandes modelos de lenguaje para personalizarlo para que realmente siga la convención de tu equipo. Y por cierto, estas técnicas también son extremadamente útiles si tu equipo está pasando por una migración o una reescritura. Esas cosas pueden ahorrar semanas de tiempo. Y esto no es lo más emocionante que quiero mostrarte hoy. Quiero cerrar la charla con lo que creo que es un vistazo al futuro, porque aunque la tecnología aún no está ahí, estoy seguro de que en dos o tres años la mayoría de nosotros integrará algo similar en su flujo de trabajo. Así que, hasta ahora hemos discutido cómo puedes convertir un design de Figma en código de React.

Pero eso es algo puntual. Y lo que necesitamos hacer, lo que realmente necesitamos hacer, es actualizar componentes y pantallas existentes en lugar de crear nuevas. Y eso es especialmente relevante si tu empresa utiliza un sistema de diseño.

Por ejemplo, un diseñador podría agregar un icono en un componente inferior en Figma y luego algún desarrollador tiene que actualizar realmente el código para soportar ese icono. Así que preparé una pequeña prueba de concepto en uno de nuestros hackathons internos en Anima Y quiero compartirlo contigo. Así que empezamos desde un botón en Figma, puedes ver aquí, y aquí está el código correspondiente en nuestra base de código. Tenemos el JSX, tenemos el CSS y fingimos que somos diseñadores y actualizamos este diseño. Cambiamos el radio del borde a cinco. Cambiamos el color de fondo. Quitamos el icono.

Ahora, imagina si el diseñador pudiera hacer clic, enviar cambios, y luego después de unos segundos, nuestra base de código se actualizaría automáticamente. Como puedes ver, el icono ha sido eliminado y los estilos han sido actualizados. El radio del borde, el color de fondo, todo esto se hizo automáticamente usando grandes modelos de lenguaje. Y lo cierto es que esos grandes modelos de lenguaje son tan potentes que el proceso también puede hacerse al revés. Así que, por ejemplo, puedo entrar en el estilo, actualizar el radio de 20 a 1, y luego un diseñador en el otro lado puede pulsar obtener cambios. Y después de unos segundos, aquí vamos, el radio del borde refleja el código.

La primera vez que vi esto, me quedé impresionado. Imagina cuánto puedes automatizar con una solución como esta, como todo el tedioso vaivén entre diseñadores y desarrolladores. Incluso si pudieras automatizar el 30, 40 por ciento de esas pequeñas actualizaciones, sería un gran ahorro de tiempo. Voy a mostrarte la siguiente diapositiva. Así que aquí vamos. Algunos podrían argumentar que el ejemplo que hemos discutido hasta ahora era demasiado trivial. ¿Cómo funciona con escenarios más complejos? Y para responder a esa pregunta, permíteme discutir otra característica clave de los grandes modelos de lenguaje Así que digamos que tienes esta tarjeta en Figma será la de la parte superior izquierda y en la parte inferior derecha, tienes el código de React correspondiente. Digamos que nuestro diseñador cambia la descripción predeterminada de la tarjeta de esto es una descripción de prueba a, he cambiado la descripción. Si alimento este diseño al código anterior que mostré en la demostración antes, este es el resultado. Como puedes ver, la IA, en lugar de actualizar la constante de descripción predeterminada como yo esperaba, básicamente actualizó el texto en línea. Y eso no es lo que esperaba. Quería que actualizara una constante. Ahora, finjamos por un segundo que este código no fue generado por IA, sino que fue hecho por un nuevo becario en la empresa.

¿Qué harías? Bueno, si hay problemas en una solicitud de extracción, normalmente escribes comentarios de revisión, y en este caso, sugiero que no deberías eliminar la constante. Y lo cierto es que los grandes modelos de lenguaje están entrenados para ser conversacionales, lo que significa que pueden manejar sugerencias e iterar en sus respuestas basándose en esas sugerencias.

Y si volvemos a ejecutar el sistema con mi comentario, este es el resultado. Bingo. La IA actualizó la constante exactamente como esperábamos. Y lo que hace, de nuevo, a los grandes modelos de lenguaje tan transformadores es que pueden adaptarse a escenarios y bases de código muy diferentes mientras también son capaces de iterar en sus respuestas basándose en sugerencias en lenguaje natural, que es algo que estamos muy acostumbrados a hacer en las solicitudes de extracción.

Y lo que me emociona tanto hoy es que estas tecnologías tienen el potencial de automatizar muchas de las tareas aburridas de nuestro trabajo para que podamos centrarnos realmente en las cosas importantes como construir características y entregar valor a los usuarios. Dicho esto, muchas gracias por escuchar. Si quieres saber más, quieres charlar, puedes contactarme en Twitter, YouTube, LinkedIn y también en mi sitio web. Y si quieres saber más sobre Anima y lo que hacemos, puedes visitar el sitio web animaapp.com. Ten en cuenta que muchas de las cosas que he mostrado hoy son productos realmente utilizables que puedes usar hoy. Así que si estás interesado y quieres saber más, simplemente contacta conmigo. Estaré encantado de responder a todas tus preguntas. Gracias.