Los Nuevos Flujos de Trabajo de AI

Hola a todos. Hoy quiero hablar sobre los nuevos flujos de trabajo de IA emergentes que los LLMs están impulsando para permitirte trabajar de manera diferente y realmente hacer más con menos. Pero primero, ¿quién soy yo? Soy el cofundador y CEO de Builder.io. También he creado algunos proyectos de código abierto interesantes como Mitosis, el compilador Crossframer, y proyectos de IA como GPT Crawler. También es posible que me hayas visto como Steve8708 en varias plataformas diferentes como YouTube.

Así que aquí está el núcleo de lo que quiero hablar. Como alguien que contrata a muchos ingenieros, puedo dar fe de esto. Contratamos ingenieros para resolver problemas y construir grandes productos, no específicamente para escribir código. Ahora que los LLMs pueden hacer mucho de la escritura de código, prefiero que los ingenieros que contrato los usen de manera eficiente como sea posible. Si el LLM va a generar desorden, entonces código a mano. Pero si el LLM puede generar código que funcione bien y trabaje más rápido para que podamos entregar a nuestros clientes más rápido, eso es un gran beneficio. Y tener personas capacitadas que sean efectivas en el uso de LLMs y que entiendan la tecnología subyacente es lo que más me importa. Y cuando contratamos, tratamos de evaluar quién es más efectivo en estas cosas.

Así que si piensas que tu trabajo es solo escribir código, podrías entrar en pánico y pensar, oh no, la IA está viniendo por mí. La realidad es totalmente opuesta. Cada ingeniero que contratamos es más capaz que en el pasado, por lo que tienen más valor para nosotros que en el pasado. Pero no me importa quién está escribiendo el código siempre y cuando sea un buen código y resuelva nuestros problemas de los clientes. Y eso cambia un poco cómo piensas sobre ser un ingeniero. Ahora, si alguna vez has sido un gerente de ingeniería, sabes que como gerente, generalmente no escribes mucho código tampoco. Gestionas a los desarrolladores y ellos escriben el código. Eso es una parte natural de la carrera de muchas personas. Y estoy encontrando que eso se acelera porque cuando puedes tener un equipo de agentes de IA escribiendo código para ti, si puedes supervisar que el código es bueno, similar a supervisar que el código de tus ingenieros que son tus empleados es bueno, puedes ser súper efectivo. Y aunque muchos grandes gerentes escriben código, los mejores ciertamente no escriben la mayoría del código para su equipo. Pero la mentalidad se aplica de la misma manera. La misma forma en que trabajas con ingenieros en un equipo de ingeniería es casi idéntica a cómo trabajas con ingenieros como agentes, o agentes de IA que están escribiendo código para ti. Y al contratar desarrolladores, realmente me importa ver personas que puedan tratar a la IA como un empleado y trabajar con ella. Se aplican las mismas habilidades, las mismas formas en que te comunicas, las mismas formas en que das orientación, aclaras requisitos, verificas y calibras. Todo se aplica de la misma manera. Así que ya sea que aspires a ser un gerente de ingeniería o no, vas a necesitar esas habilidades. Ahora, hay múltiples formas de manejar el uso de la IA para escribir código.

Muchas personas están familiarizadas con lo que podrías llamar un agente de primer plano o trabajo sincrónico donde estás escribiendo en el cursor o copilot o cloud code lo que quieres construir y ves cómo se construye o se corrige el error en tiempo real. Ahora hay algo emergente llamado agentes de fondo. A medida que la IA se vuelve más confiable en escribir código de buena calidad, probando su propio trabajo y validando que lo ha hecho correctamente, podemos delegar más trabajo agéntico para que sea asíncrono, como asignar tickets, o iniciar múltiples de estos en paralelo. Hay muchos grandes beneficios aquí, pero también puede haber algunas desventajas. Cubrir ambos en una demostración en un segundo y hablar sobre los pros y contras y cómo puedes saltar de uno a otro también.

Y luego lo importante a reconocer es que los LLMs no solo te hacen más productivo como desarrollador. Hacen que otras personas como los diseñadores y gerentes de producto con los que trabajas sean competentes al trabajar con código. Eso podría ser tan simple como cuando el PM te hace una pregunta, puedes decirles que vayan a preguntar al código ellos mismos. O si un diseñador sigue enviándote estos diseños que realmente no tienen sentido, son complicados de, simplemente son complicados de implementar, puedes hacer que tu diseñador trabaje directamente sobre el código. De esa manera, cuando algo se te entrega, si estás usando un buen agente que está informado para usar el sistema de diseño y las prácticas de codificación correctamente, en realidad estás obteniendo front-ends completos al 80% y puedes trabajar en las partes difíciles, los back-ends, la implementación y la lógica de negocio.

Estoy refactorizando el código. Si pudiéramos delegar más a nuestros miembros del equipo no técnicos, como desarrolladores, podríamos enfocarnos en las cosas sustanciosas, interesantes, de alto impacto y alto apalancamiento. Y eso es algo que no hay que pasar por alto y también lo cubriré. Al combinar estas cosas, puedes abrir nuevos flujos de trabajo. Lo que he visto en nuestro equipo y otros equipos son algunos nuevos patrones que no existían antes. En el pasado, tenías la gran cascada donde tenías que tener cien reuniones y cien memorandos y bla, bla, bla antes de que se construyera algo. Ahora hemos visto que la gente puede producir y enviar mucho más rápido. Si ingeniería tiene una idea o ve comentarios de clientes, tú mismo como un equipo de uno podrías tomar una primera iteración para mejorar el producto. Con la IA adecuada, las UIs pueden generarse con las mejores prácticas adecuadas. Puedes asegurarte de que la implementación funcione bien y si producto o diseño tienen comentarios, pueden entrar en el código después de ti y limpiar los píxeles, agregar el seguimiento o incluso simplemente hacer las preguntas que tienen. Y puedes enviar mucho más rápido sin bloqueos y esperas y cascadas. Puedes moverte más ágil que nunca. De manera similar, si tienes partes de un producto que son simplemente feas y se ignoran, de manera similar si tienes partes de tu producto que son simplemente feas y los diseños quieren actualizarlas para siempre, no tienen que hacer diseños que nadie va a trabajar nunca. Podrían simplemente entrar en el código, mejorar la UX y enviar una pull request. Ingeniería no tiene que perseguir estas líneas rojas y todas las formas detrás de un diseñador. Pueden simplemente revisar el código, comentar en un agente si quieren que el código se modifique o se limpie y fusionar. Y de manera similar, los PMs no tienen que enviarte estos largos memorandos y documentos de requisitos.

Puede enviarte un prototipo que tiene algunas de las piezas básicas funcionando y tiene algunos claros vacíos donde necesitamos implementar finalmente. El diseño puede trabajar sobre la parte superior y pulir la UI mientras que la ingeniería en paralelo trabaja en la implementación final. Hemos visto que esto mejora drásticamente la velocidad a la que los equipos pueden ejecutar mientras mantienen el mismo tipo de estándar de calidad y requisitos en torno al código.

Y en general, encontramos que estos equipos se divierten mucho más. Es simplemente divertido lanzar cosas en productos aprobados en lugar de estar atascado en la burocracia y en cascada. Y la mejor parte es que tienes muchas opciones diferentes de productos que puedes usar. Para agentes secretos, agentes asíncronos, agentes que tus no desarrolladores pueden usar, incluso algunos que pueden integrarse con tu código real, y agentes para ayudar con la revisión de código.

Así que si eso se vuelve demasiado pesado, puedes aligerar la carga de esa manera también. Ahora voy a demostrar algunas de estas cosas. Voy a usar Builder.io porque conozco muy bien ese producto. Yo construí la cosa. Pero solo ten en cuenta que puedes usar una gran cantidad de otros productos para muchas de estas diferentes cosas y, en última instancia, elegir tu propia combinación favorita de lo que funciona mejor para ti. Dicho esto, vamos a demostrar algunos de estos flujos de trabajo. Creo que será divertido. Así que aquí estoy en el panel de control de Builder.io y esto está diseñado para sentirse como un adorable o algún tipo de constructor de aplicaciones de IA fácil. Pero bajo el código, estos son todos repositorios de código reales existentes.

Importas desde tu GitHub o Enterprise Azure DevOps o lo que tengas. Para cualquiera de estos, podemos simplemente iniciar una rama y comenzar a hacer ediciones y enviar pull requests. Pero primero quiero iniciar un agente asíncrono. Como ves, hay íconos de Slack y Jira. Eso significa que podemos simplemente etiquetar al agente de Builder en Slack o podemos asignar al agente de Builder un ticket de Jira. Ya seas un PM, diseñador o desarrollador, probablemente tengas muchos tickets.

Y una cosa realmente genial es que si eres un desarrollador al que le asignan tickets, una cosa que podrías hacer es simplemente reasignarlo. Deja que la primera iteración sea realizada por el bot de Builder. Alternativamente, también podrías simplemente etiquetar al bot en los comentarios y decir, oye, haz esto por mí. Podrías asignar un conjunto completo de tickets de una vez, tal vez un backlog más voluminoso que nadie quiere manejar de todos modos, y dejar que el agente haga un primer intento en la implementación.

Recibirás un comentario de que el agente está trabajando en ello y estos agentes pueden ser muy personalizados para seguir todas tus mejores prácticas. Por defecto, por supuesto, también miran el código existente y replican lo más cerca posible los patrones que ya ven también. Así que dejemos que este agente en segundo plano funcione por un minuto y hagamos algo de trabajo sincrónico. Así que de vuelta en Builder, digamos que quiero editar este proyecto de Builder Academy. Simplemente haré clic en más nueva rama para crear una nueva rama, y entraremos en el entorno de edición visual.

Así que aquí tienes un modo de código completo donde puedes entrar y editar el código. Puedes generar todo esto localmente para que realmente esté editando directamente tu base de código local también. Hay una integración con VS Code, un CLI y un plugin de cursor.

Centrémonos primero en el lado de la IA. Lo genial es que, como esto puede ejecutarse en el navegador o en una aplicación de escritorio, puedes realmente delegar esto a tus compañeros no desarrolladores también. Cualquiera puede entrar aquí y dar indicaciones y también puedes pasar a otros compañeros.

Te mostraré a qué me refiero. Comencemos muy simple. Y noto este sitio de academy, que es nuestro sistema de gestión de aprendizaje real. Aquí es donde puedes tomar cursos y certificarte en saber cómo usar Builder. No tiene una página de Contact Us, así que simplemente entraré aquí y diré añadir una página de Contact Us.

Bajo el capó, el agente está haciendo lo que estás acostumbrado con herramientas como Cloud Code o Cursor. Está viendo cómo funciona el código. Sabe que para una página de Contact Us, probablemente necesites un formulario. Probablemente necesitemos una API. Descubrirá cómo hacemos esas cosas, creará una lista de tareas y comenzará a trabajar.

Actualmente estoy usando Cloud Haiku 4.5. Funciona realmente rápido, lo cual es muy divertido. Te mantiene mejor en flujo. Y hemos terminado.

Veamos nuestra página de Contact Us. Parece que encontré un error de ejecución. Simplemente hago clic en el botón de intentar corregir. Se resolverá aquí mismo. Eso es lo bueno de tener un navegador integrado, ya que puede detectar esos errores y luego simplemente corregirlos. Genial. Error de ejecución resuelto. Tenemos nuestra página de Contact Us.

Ahora aquí está lo interesante. Hasta ahora, este flujo de trabajo no ha sido tan diferente de lo que usarías para Cursor. Estos son agentes sincrónicos. Esto no debería ser demasiado loco. Ahora, lo que es genial es que cuando realmente tenemos el contexto de la UI aquí, podemos hacer algunas cosas interesantes. Así que lo genial de tener la visualización real aquí integrada es que aunque estamos editando nuestro propio código, ya sea localmente o en la nube, puedo simplemente saltar al modo de diseño y obtener un editor de nivel Figma para esto. Así que tal vez quiera hacer esta página más ancha.

Quizás quiero tomar esta sección y moverla al lado del formulario, cambiar el diseño, cambiar el ancho de la columna. Prefiero que estos tengan un color de fondo blanco. Simplemente creo que se ve mejor. Bam. Y no necesito un campo de asunto. Y usemos también un poco de lenguaje natural aquí. También podemos decir, añade un acordeón de FAQ debajo de esto y lánzalo.

Ya sea que prefiera usar la edición de UI al estilo Figma para ese tipo de edición precisa que quiero de mi código local, o quiero enviar este enlace a nuestro diseñador y decir, Oye, hice un primer intento en parte de la implementación aquí, pero el mío es un poco feo. Diseñador, ¿puedes entrar y hacerlo ver mejor? Obtienes estas transiciones realmente rápidas donde las personas pueden retomar donde otros dejaron y no hacer lo tradicional, que es como, Oye, diseñador, ¿puedes tomar una captura de pantalla de esto y luego ir a Figma y rediseñarlo, luego lo miraré y tendré que re-implementar eso, pero eso apesta.

Simplemente entreguemos el código, dejemos que el diseñador trabaje y lo traiga de vuelta. Genial. Tengo mi diseño de página actualizado. Tengo mi acordeón de FAQ. Esto es genial. Ahora, si encuentras que un diseñador aún preferiría trabajar en Figma, lo cual muchos hacen, hay una solución para esto también. Podemos volver al modo de diseño. Podemos seleccionar lo que queramos, como tal vez esta sección, y luego podemos exportarla a Figma. Tu diseñador en Figma puede entonces simplemente abrir el plugin de builder, ir a la pestaña de importación y pegar. Y ahí vamos. Aquí está nuestro diseño. Ahora podemos comenzar a hacer ediciones. Por ejemplo, tal vez queramos modificar este formulario a oscuro. Así que elijamos un relleno oscuro. Hagamos el texto blanco. Ba-bam. Ba-bam. Hagamos estos inputs oscuros también. Tal vez un poco más claros y darles un trazo que no sea tan claro. Bien. Ahora, cuando esté contento, puedo simplemente volver al plugin y puedo exportar esto.

Puedo volver a Builder, pegar y decir aplicar mis actualizaciones de diseño y dejar que se ejecute. Así que puedes hacer una transición bastante fluida para ir del código al diseño y viceversa o incorporar esos nuevos diseños también. Es importante destacar que gran parte de este trabajo ni siquiera tiene que ser realizado por ti, un desarrollador.

Puedes pedirle a tu diseñador u otros que lo hagan. Así que ahora estamos actualizando el código. Genial. Y genial. Tengo mi diseño actualizado. Parece que las entradas funcionan como se esperaba. El formulario todavía funciona como se esperaba con validación. Esto es genial.

Cuando tenemos lo que nos gusta, podemos simplemente enviar este PR. Muy bien. Se creó el PR. Vamos a abrirlo. Ahora tengo un buen título y descripción que describe los cambios. Podemos revisar la vista de archivos y esta es la primera vez que vamos a pasar de agente de primer plano a agente de fondo.

Así que aquí, ya sea que envíes esto como desarrollador o tu diseñador o PM o quien sea que envíe la pull request. Ahora la gente tiene comentarios. Ciertamente podrían preguntártelo a ti, pero digamos que tus diseñadores tienen el PR, como que ellos no van a saber cómo actualizar el código para cambiar nombres o estructura o lo que sea. La parte genial es que si queremos cambiar algo, como tal vez tomar esta sección de formulario, podemos simplemente entrar y etiquetar a los builder IO bots y simplemente decir lo que quieras hacer, como mover este formulario a un nuevo archivo y dejar que lo haga. La parte genial es que puedes colaborar con un bot como si fuera un humano y dejar todos los comentarios que quieras y luego el bot comenzará a hacerse cargo y hacerlo.

Así que este es el bot trabajando en segundo plano. Puede trabajar en muchos de estos comentarios en paralelo y aquí ya ha respondido. Volveré al trabajo de inmediato y subirá los cambios a medida que estén listos. Ahora, mientras eso está corriendo, porque esto está en modo de fondo, puedo hacer otras cosas. En mi caso, ¿por qué no revisamos ese ticket que comenzamos? Así que aquí teníamos este ticket de panel de control del clima y podemos ver, genial, hace unos minutos, el builder bot terminó el trabajo. Así que mientras estaba haciendo todo ese otro trabajo sincrónico, el bot estaba haciendo un montón de trabajo para mí en segundo plano directamente desde el ticket que tenía todas las especificaciones, podría haber archivos adjuntos, podría enlazar a otras cosas, que puedes usar servidores FCP para obtener ese contexto.

Así que solo abriré esto. Así que este era un proyecto trabajando en una aplicación totalmente diferente. Así que lo que pedí fue un panel de control del clima, y está dentro de esta aplicación, que está usando el sistema de diseño Cloudscape. Es el sistema de diseño de AWS. Así que vamos a ver y creo que en paneles de control, genial, deberíamos ver un panel de control del clima. Genial. Veamos si fue capaz de hacerlo de un solo golpe. Genial. Así que se ve bastante bien hasta ahora. Cerremos esto. El ticket pedía poder hacer un tipo de búsqueda de cabeza. Así que ubicación de San Francisco. Genial. Todo esto está usando el sistema de diseño Cloudscape. Se ve bien. Tenemos el clima actual nublado. Eso suena bien para San Francisco. Tenemos todos nuestros gráficos y tablas de Cloudscape.

Genial. Este es un gran primer intento, pero tengo algunos comentarios. Podríamos entrar en modo de diseño, hacer cosas así o usar lenguaje natural. Una cosa que me gusta hacer es simplemente decir, oye, haz que este pronóstico de siete días sea un desplazamiento lateral. También diré que me des una opción para cambiar entre Fahrenheit y Celsius. Como puedes ver, estos errores tipográficos no importan. El LLM generalmente puede descifrar estas cosas. Y la parte importante de entender aquí es que ahora hemos pasado de asíncrono a sincrónico. Hemos pasado de fondo a primer plano. Hacemos todo el trabajo de primer plano que queremos hacer aquí.

Y genial. Tenemos nuestras actualizaciones. Busquemos San Francisco de nuevo. Y bien. Tenemos nuestro desplazamiento lateral. Tenemos los interruptores de Fahrenheit y Celsius. Ahora tomemos un minuto para recapitular. Aquí tomamos un par de enfoques para pasar de ser el escritor de código directo a escritores de código gestionados. Delegamos un ticket a la IA y luego retomamos donde lo dejamos y refinamos. Hicimos un trabajo agéntico sincrónico.

Y luego desde la pull request, también hicimos un trabajo asincrónico y hablamos sobre una variedad de formas de colaborar con tus compañeros de trabajo como diseñadores y PMs. Puedes mezclar y combinar estas técnicas tanto como quieras. Puedes explorar una gran variedad de productos que pueden ayudar a resolver estas cosas. De cualquier manera, espero que tomes en serio la exploración de nuevas formas de trabajar. Aunque sé que eres completamente capaz de escribir el código a mano, estás obteniendo más y más herramientas y ahora más y más flujos de trabajo para trabajar y colaborar y construir productos más rápido como equipo. Muchas gracias por ver esto.