De Un Repo a Cientos: Construyendo una Flota de Agentes de IA para Migraciones de Código a Gran Escala

Hola, hola a todos. Estoy realmente contento y es genial que en realidad esté aquí hoy con ustedes. Estoy aquí hoy para compartir con ustedes una historia de migración. Trabajo en una plataforma detrás de más de 500 micro frontends y un día tuvimos que cambiarlos todos de manera que se introdujo una nueva versión de Node. ¿Y cómo podría hacer eso? Así que básicamente la primera idea fue que en realidad íbamos a lanzar un pequeño ejército para hacerlo, haciendo todo a mano. Pero tenemos LLMs, básicamente tenemos todas estas grandes herramientas ahí fuera. En su lugar, construimos una flota de agentes de IA para hacer eso por nosotros. Y esta charla es en realidad sobre cómo hicimos eso. Déjenme mostrarles dónde terminó esto.

Así que esto fue en realidad cuántos repositorios tuvimos que migrar. Estos son 527 repositorios y el 87% de ellos funcionan sin ningún humano en el bucle. Y esto es por diseño, no es un atajo que tomamos. La mayoría ya están fusionados, pero el despliegue aún está en curso. Así que una breve introducción sobre mí. Soy Konstantinos, soy un líder técnico en Monday. Dirijo iniciativas técnicas allí y soy dueño de la plataforma y los frameworks detrás de esos más de 500 micro frontends. Esta es una máquina que construimos para migrar todos estos repositorios, en su mayoría sin que nadie toque estos repositorios.

Pero primero, ¿por qué no simplemente hacer eso de la manera normal? Porque la manera normal se rompe a escala. Y cuando digo normal, esto es básicamente lo que quiero decir. Tenemos dos opciones aquí. Básicamente podemos migrar con PRs manuales y también con code mods. Hacerlo a mano, 527 repositorios, multiplicado por arreglarlos, revisarlos y cuidar todos los CIs no es posible. No escala. Escribir el code mod, este es un script que reescribe el código, pero los code mods solo arreglan básicamente lo que predijiste. No son muy buenos en los puntos ciegos donde el software realmente se rompe en el tiempo de ejecución. Y en el peor de los casos, no hace nada y deja el repositorio en un estado donde piensas que el software y la migración están hechos, pero en realidad no lo están. Y esto es en realidad bastante común en la industria. El propio equipo de migración de Google encontró que los scripts fallan en el código complejo no uniforme. Y cada gran cambio es una mayoría aburrida más una cola muy desordenada. Y esa cola básicamente decide cuál es la herramienta que vas a usar para este tipo de migraciones.

Y es muy fácil subestimarlas. Así que esto es en realidad cómo comienza todo. Es solo un aumento de versión de Node. Un día, como mucho. Luego, la realidad entra en juego. Tenemos cinco versiones de Node en todos estos repos que están en vivo. Tenemos un don nativo que en realidad se construye solo en un portátil específico. Un archivo de registro que en realidad ha sido actualizado desde el confinamiento, y nadie lo ha actualizado desde entonces. ¿Y las pruebas? En ninguna parte. Nunca encontramos ninguna prueba. Así que la estimación revisada, Q3 desde Q1. Y Dave desde entonces ha dejado la empresa, así que buena suerte con eso.

Así que no comenzamos con toda una flota. Comenzamos con un repo. Y la forma en que lo hicimos fue un agente primero, un repo, y cinco pasos diferentes. El agente mira tu repo y verifica básicamente lo que ya pasa y crea la línea base. Esta es nuestra línea base. Esta es nuestra construcción. Este es nuestro linting. Estas son nuestras pruebas. Luego, el agente en realidad migrará este repo. Ejecuta nuevamente todas las puertas de calidad, se asegura de que estén pasando, y finalmente abre el PR. Haz que esta cosa sea aburridamente confiable primero, antes de pasar a la flota de agentes.

Ahora vamos a ver básicamente cómo podemos hacer que todos estos diferentes pasos sean bastante confiables. La parte interesante es la migración. Así que cada migración se divide en dos pasos diferentes. Uno es el determinista, y el otro es el no determinista. Así que el determinista tiene el mismo resultado exacto cada vez. Aumentamos la versión, reconstruimos todo el repo, ejecutamos las pruebas, ejecutamos los archivos de registro, actualizamos los archivos de registro. Un script puede hacer eso.

Y el otro lado realmente necesita un juicio. Y el script no es un buen trabajo para ese lugar. Arreglar lo que realmente se rompió, arreglar lo que realmente se rompió, es muy difícil para cada repo diferente, porque todos los repos realmente se rompen en cosas diferentes. Y ese lado realmente necesita un cerebro detrás de eso.

Comenzando con el lado económico, la vía determinista es básicamente scripts puros. Los scripts puros no nos cuestan nada, porque los LLMs no necesitan ningún cerebro a su alrededor. Pueden simplemente ejecutarse, pueden actualizar los archivos de registro, pueden actualizar las versiones de node, los motores de node. La advertencia honesta es que solo un script puede fallar.

Una reconstrucción de archivo de registro depende del registro y del código nativo. Cuando falla, no adivina. Se detiene y pide un humano. Y así es como añadimos un humano en el bucle. Entonces, ¿dónde exactamente está la línea entre el script y pensar en ello? Básicamente, los scripts solo tocarán los archivos de versión y el archivo de registro.

ello? Básicamente, los scripts solo tocarán los archivos de versión y el archivo de registro. Y cuando realmente empezamos a necesitar el juicio, es aquí donde entran los LLMs. No queremos realmente inflar este tipo de migración con otros pasos irrelevantes, como no ejecutamos auto formateo en todo el repo, no ejecutamos correcciones de linting, u otros cambios irrelevantes. Así que podemos mantener los PRs muy pequeños y los humanos pueden revisarlos muy fácilmente. Esa línea también decide dónde realmente gastamos el dinero. Lo que necesitamos hacer es básicamente ajustar el modelo al trabajo que queremos implementar.

La vía de script, como dijimos, es gratuita. Solo pagamos por las correcciones. Un modelo económico puede clasificar cada corrección y manejar las fáciles, que son la mayoría. Y cuando esta primera clasificación realmente falla, entonces podemos delegar a los modelos más fuertes y reintentar para corregirlos. Así que esto puede ejecutar algunas clasificaciones más y el caso masivo se resolverá con los económicos, y luego solo pagaremos por los más fuertes para corregir estos pocos problemas que podríamos tener en estos repos. Ahora, una cosa que hace que todo este ciclo sea confiable es saber qué significa exactamente roto. Así que antes incluso de tocar el repo, ejecutamos la compilación, ejecutamos las pruebas, anotamos lo que ya pasa y lo que no. Esa es nuestra línea base.

Y luego el agente solo cambia fallos que sabe que han cambiado debido a esta migración. Nunca pierde tiempo en cosas que estaban rotas antes de que incluso hiciéramos esta migración. Aquí hay una pequeña trampa, porque si tenemos algunas pruebas inestables, esto realmente envenena la línea base. Así que ejecutamos varias veces y dejamos de lado las inestables si es necesario. Pero una línea base no vale nada si el repo no tiene una visión sobre sí mismo, lo cual es una verdadera que es una verdadera como primera puerta. Las pruebas son la visión del agente. Así que si no tenemos pruebas, no hay línea base, no hay señales. Así que la verificación viene antes que los riesgos, siempre. ¿Compila? ¿Hay un SCI? ¿Hay una cobertura real? Si no, inviertes allí primero o lo entregas a una persona.

Ahora cómo lo convertimos en cientos. Y esta es como la parte importante. Aquí está el truco que hizo que la escalabilidad fuera simple. El agente nunca se llama entre sí. Cada agente es sin estado. Lee el tablero, hace un trabajo, escribe el resultado de nuevo en el tablero y se detiene. Si algo se rompe, se queda atascado. Así que somos visibles de estos problemas. Somos visibles de esta situación. No lo estamos tragando. La transferencia a través del tablero nunca directamente entre sí.

Entonces, si nunca hablan entre sí, ¿cómo están de acuerdo en algo? Así que el mensaje no es el acuerdo, no es el formato del mensaje, sino el propio tablero. Cada agente tiene una regla, qué filas recogerá y qué columnas escribirá. El agente de riesgo toma las filas que están marcadas como PR abiertas. Como puedes ver allí, las puntúa de uno a cinco y escribe la puntuación de nuevo en el tablero. Esa escritura es exactamente lo que hace que la regla del agente coincida. Y nota que esta puntuación es determinista. Tenemos reglas simples allí. No se necesita modelo. Y la columna es el contrato real.

Porque ese es el único contrato, agregar pasos adicionales es muy fácil. Así que como puedes ver, podemos simplemente agregar un paso aquí. Lo que recoge, lo que escribe, lo que ejecuta, y nada más en la flota sabe que existe. En tu etapa, puedes simplemente agregarlo en esta lista y puede ejecutarse básicamente en este orden. Sin reconfiguración entre los agentes. Los agentes solo están hablando con el tablero. Entonces, ¿qué los ejecuta a todos? Menos de lo que piensas. Este es todo el orquestador. Muy simple. Sin mensajes, sin bus, sin cola, sin llamadas de agentes a agentes.

Solo un bucle sobre el tablero, leyendo los elementos, ejecutándose una vez cada pocas horas. Y para cada etapa, realmente tomamos estas filas coincidentes, hacemos el trabajo, luego escribimos de nuevo en el tablero. Sin estado, seguro para ejecutar. Y eso es todo. Ese es nuestro tiempo de ejecución.

Así es como podemos ejecutar múltiples pasos al mismo tiempo. Una pieza está haciendo el trabajo pesado. Los bucles realmente aterrizan el pull request. Así que tenemos dos bucles diferentes en este tipo de flujo de trabajo. El bucle número uno básicamente está revisando todos los fallos en nuestras puertas de CI.

Volvemos a ejecutar las puertas de calidad. Si hay una corrección que necesitamos aplicar, aplicamos esta corrección. Y luego, cuando todo está en verde, abrimos el PR en GitHub o en cualquier otra herramienta que usemos. Hay otro bucle a nivel de PR que realmente verifica cuando el CI falla. Luego actualizamos el PR, volvemos a activar hasta que esté en verde y finalmente hacemos una fusión automática cuando todo está en verde.

Pero un bucle que solo reintenta hasta que esté en verde es peligroso, ¿verdad? Entonces, ¿qué hacemos? Necesitamos arrendarlo. Y cada reintento hasta que esté en verde oculta un error real y quema dinero. ¿Qué hacemos? Lo limitamos. Intenta el modelo barato primero. Escala el fuerte solo en caso de fallo y solo dos veces. Sigue fallando. Márcalo como atascado, muévelo, y un humano realmente entrará en el bucle. Esto no es solo mi paranoia. Karpathy lo expresó en pocas palabras. Mantén la IA bajo arrendamiento. Un bucle sin límite es una autonomía. Es básicamente un escape. El agente que abre el PR es fácil, pero el bucle que lo lanza de manera segura es el producto real. Todo hasta ahora se apoya en la cosa compartida y déjame nombrarla. Esta es la parte que robaría para mi próximo propio proyecto.

El tablero no es solo el almacenamiento. Es el plano de control entre humanos y una flota de agentes. Cada columna es una señal. Los agentes leen y escriben. Un humano anula simplemente editando una celda y cuando la realidad se desvía, básicamente un humano puede entrar en el bucle y fusionar el PR a mano. Un agente puede reconciliar cuando los usuarios externos han actualizado realmente los PRs y siempre converge en la realidad. ¿Cuál es el estado actual del PR? Usamos Monday. Puedes usar cualquier cosa. Puedes usar una base de datos, puedes usar una hoja de cálculo, puedes usar prácticamente cualquier cosa. Así es como se ve el tablero. Esta es una lista de mis MFs. Todos los MFs a los que realmente estoy migrando. Puedes ver que tenemos diferentes estados sobre el estado de la fusión, el riesgo, los PRs, un enlace al PR para que los agentes realmente puedan pasar. Esto es básicamente cómo se comunican entre sí.

Así que déjame poner todo, cada pieza de nuevo en la pantalla.

Esto es lo que construimos. Tenemos el orquestador que recorre los diferentes pasos. Primero actualizamos, luego ejecutamos las puertas de CI, luego evaluamos el riesgo y finalmente hacemos la fusión automática. Todo se hace a través del tablero. Ese es el tercer bus, como puedes ver aquí en el medio. Luego tenemos algunos agentes más que mantienen el estado tanto del tablero como de los PRs en buen estado.

La actualización que realmente se ejecutará cuando haya conflictos a nivel de PR y la sincronización que devolverá el tablero a la situación real cuando los humanos también entren en este proceso. Finalmente, si el riesgo es bajo, podemos fusionar automáticamente estos PRs. Si el riesgo es alto, entonces realmente movemos el estado a un estado de pila y el humano puede entrar en el bucle. Entonces, ¿qué nos ha proporcionado todo esto? No envías a producción 527 PRs de una sola vez. Calificas el riesgo de 1 a 5 y luego envías primero los seguros. El riesgo bajo es la mayoría, al frente y luego la cola riesgosa al final.

Alrededor del 87% se ejecuta de extremo a extremo sin intervención humana y eso es por diseño. Los agentes manejan el volumen, los humanos poseen la cola de juicio. El 13% es donde una mala fusión automática puede realmente convertirse en un post-mortem muy memorable. Así que los humanos aquí poseen esos a propósito. Aquí lo que hicimos mal antes de hacerlo bien. CI verde no significa corrección. Como dice Simon Willison, una suite de pruebas aprobada no significa que el servidor siquiera arranque. Así que no cambiar el comportamiento de ejecución. Sé consciente de eso. La prueba podría nunca comprobarlo así que necesitamos probarlo con la diferencia de línea base.

Una prueba inestable que finalmente pasa al reintentar es una regresión disfrazada. Requerimos un verde estable verde dos veces en el CI antes de que hagamos la fusión automática. Finalmente, el repositorio sin pruebas es el que te va a morder. Así que la verificación es muy muy importante antes de la autonomía y no hay excepción a esto. No llegamos aquí por suerte, llegamos aquí sabiendo exactamente dónde se rompe. Así que aquí está el verdadero beneficio y no es solo una migración.

La máquina no es de un solo uso. Puedes usarla en tu próximo aumento de Node, puedes usarla en un despliegue lean, puedes usarla en una actualización de framework. Todos comienzan cerca de la parte inferior de esta curva. Misma máquina, una regla diferente. Conviertes un programa de meses de duración en un par de semanas. La ganancia no es la migración, es la capacidad de hacerlo. Así que aquí está lo que puedes llevarte a casa. Seis líneas. Divide el trabajo determinista versus no determinista y distribuye el costo por paso.

Las verificaciones vienen primero antes de cualquier paso y cualquier implementación de agentes. Si no tenemos pruebas, no vamos a tener autonomía y esto es lo que nos va a morder en el futuro. Construye un átomo muy confiable antes de comenzar a paralelizar con múltiples agentes de flota. Desacopla a través del tablero, consigue un tablero y hazlo realmente la dirección para tus propios agentes y la forma en que te comunicas con tus agentes entre humanos y agentes y luego cierra el bucle a través de este tablero y finalmente ordena por riesgo para poder fusionar automáticamente este tipo de cambios y no tienes que tomar mi palabra para ello.

Hay dos ideas en las que el campo realmente está convergiendo. Primero, la máquina es el activo. Hay un creciente consenso de que el modelo es intercambiable. El arnés alrededor de él, los bucles, las herramientas y las barandillas es donde vive el producto. Toda mi charla es un ejemplo mundial sobre eso. Segundo, el humano posee la cola. La autonomía despeja la mayoría mecánica. El juicio, saber cómo se ve lo bueno, es la parte que no puedes automatizar. Construye la fábrica. Mantén al humano en la cola de juicio. Esto es también lo que Gergely Oros propuso y aquí es donde el valor como experiencia de nuestros ingenieros entra en juego. Necesitamos poseer esta cola de juicio. Así que no migramos 527 repos. Construimos una máquina que migró estos repos por nosotros y está funcionando ahora mismo. La migración fue solo una demostración. La máquina que construimos es el verdadero activo.

Muchas gracias. Fantástico, muchas gracias. Muy bien, veo que tenemos algunas preguntas aquí. Recordatorio para todos en el stream o en la sala, si quieren hacer una pregunta pónganla en Slido 0607. Bien, primera pregunta. Mostraste algunos comandos slash pero también pseudo código. ¿Estás usando un enfoque de sdk de agente o un agente de ejecución de daemon? Sí, básicamente usamos ambos enfoques. Así que el primer enfoque fue realmente implementando nuestras propias habilidades. Así que podemos realmente implementar este flujo de trabajo de agente. Ahora estamos trabajando en implementar eso con el SDK de Anthropic. Lo siento por eso, y básicamente está bastante abstraído de una manera que realmente puede ser migrado también a diferentes tipos de proveedores y integraciones de elementos. Así que sí, creo que eso responde a la pregunta.

Increíble y la siguiente pregunta que tenemos aquí. ¿Cuál fue el problema más memorable causado por la fusión automática? ¿Los riesgos valen los beneficios? Sí, hemos tenido algunos problemas por supuesto en este tipo de migración.

Uno de ellos fue en realidad, quiero decir, no afectaron realmente a los usuarios finales de una manera significativa. Pero la cuestión es que aprendimos básicamente que, por ejemplo, el ci verde no significa necesariamente que la migración se haya realizado correctamente porque, como mencioné, esta migración realmente también tocará la ejecución en tiempo de ejecución. Así que esto es muy importante y si no tienes como suficientes verificaciones en su lugar, entonces será muy difícil para ti probar y asegurarte de que todo está funcionando bien. Así que sí, por eso invierte más y más en la parte de verificación, que es agregar más pruebas tantas como puedas.

Genial. Siguiente pregunta aquí. ¿Ha aumentado esto la cantidad de tiempo dedicado a revisar PRs por tus miembros del equipo? ¿Cómo manejas esto para que no estén bloqueados y no puedan hacer su propio trabajo? Sí, básicamente, como mencioné, la mayoría de ellos se fusionan automáticamente. Así que básicamente el 87 por ciento de ellos se fusionaron automáticamente. No tuvimos que agregar al humano en el proceso. Por eso estamos invirtiendo primero en las pruebas. Así que podemos realmente también basándonos en estos factores de riesgo evaluar el riesgo de cada uno de los PRs. Si el nivel de riesgo del PR es muy bajo, entonces podemos fusionarlo sin molestar a ningún otro tipo de colegas.

Todos estos cambios también tienen un propietario de los equipos, de sus equipos relevantes. Así que si algo sale mal en producción, ellos también son como los propietarios de este tipo de parte. Genial. Bien, siguiente pregunta. ¿Cuánto tiempo te llevó construir la fábrica?

Así que básicamente todo esto nos llevó un par de meses implementar y asegurarnos básicamente de que esté funcionando a una buena escala. No pudimos realmente ejecutarlo en como 500 repos al mismo tiempo, pero en realidad comenzamos a agregar básicamente esta fábrica de manera incremental. ¿Cuál fue la segunda parte de la pregunta? ¿Alguna lección aprendida del lado de la orquestación? Sí, del lado de la orquestación aprendimos básicamente que definitivamente necesitas tener un propietario como parte de cualquiera de estos cambios porque de lo contrario los equipos mismos podrían no estar tan conscientes de lo que está sucediendo y básicamente algo que podría salir mal cuando esto se lance a producción.

Genial. Siguiente pregunta. La metodología que propones parece beneficiosa no solo para migraciones sino también como un enfoque general para cualquier tarea que requiera automatización escalable de IA que se mantenga bajo control. ¿Cómo has utilizado este enfoque en otras áreas? Sí, así que básicamente esta es en realidad otra razón para invertir más en verificación.

Así que hay equipos que en realidad no están invirtiendo tanto tiempo, desafortunadamente, en agregar pasos adicionales, pruebas adicionales como pruebas de extremo a extremo o como pruebas de storybook o algo así. Así que es una muy buena oportunidad para realmente aumentar la conciencia de eso y básicamente asegurarse de que todo sea verificable y pueda realmente entregar mejor básicamente nuevas actualizaciones en el futuro. Correcto, hay tantas preguntas aquí sobre por qué tienes tantos repos. Eso no es todo. Eso ni siquiera es todo. Eso no es todo. Quiero decir, para 500 son los de producción, hay mundos que tienen internos. Sí, lo cual no es... ¿Por qué? ¿Por qué? Así que debido a nuestra implementación de micro frontends. Así que básicamente tenemos como, damos a los equipos básicamente autonomía en la forma en que quieren implementar nuevas características. Así que nuestra implementación de micro frontends en realidad les permite crear nuevas características al implementar básicamente nuevos micro frontends y básicamente, cada micro frontend puede ser parte de un mono repo o un repo. Así que en realidad son parte de su propia base de código. Genial. Bien, esta es una pregunta realmente interesante.

Bien, esta es una pregunta realmente interesante. Entonces, si has aplicado esto al desarrollo de productos, ¿cuál fue tu aporte? ¿Cuánto esfuerzo estás poniendo en el desarrollo de especificaciones humanas y/o de IA? Sí, esto sería en realidad un poco más difícil de implementar en el ciclo de vida completo de la característica debido a la incertidumbre de lo que la característica realmente será. Entonces, en realidad necesitamos volver al desarrollo impulsado por especificaciones y comenzar a discutir básicamente cómo escribimos una buena especificación, cuál es un buen flujo de trabajo. Este tipo de migración fue en realidad como una migración muy pequeña y muy determinista, pero planeamos aplicarla en más y más tipos de migraciones en el futuro. En cuanto a características, aún no estamos allí. Bien, había una pregunta realmente buena que acaba de desaparecer.

Bien, Jamie ha preguntado, con la fusión automática de código basada en el riesgo, siempre hay cosas que podrían salir mal. ¿Cómo estás protegiendo la producción al mismo tiempo? Siempre tenemos un mecanismo de reversión. Así que esto es muy importante. Así que cuando todo como mantener alertado, tener observabilidad, si algo sale mal, ya sea usar tus herramientas de seguimiento de errores, herramientas de registro. Cuando te alertan, poder revertir. Esto es muy importante. La escala de esto puede variar, pero tener básicamente como si es como crítico para el negocio tener un humano en el bucle es muy importante en esto. Realmente me gusta esta siguiente pregunta sobre observabilidad. Entonces, ¿cuál es tu observabilidad para depurar un elemento atascado? Cuando algo queda atascado, ¿cómo rastreas eso a través de qué agente lo hizo? Tenemos un, ¿cuál es el, sobre el agente, qué agente hizo eso? Sí, ¿qué agente hizo eso? Lo siento, mi diapositiva sigue saltando. No, no, no. Así que básicamente como este es como el agente, tenemos múltiples agentes, como en el proceso. Así que básicamente, dependiendo del estado, podemos identificar exactamente dónde estamos en este tipo de proceso. Así que básicamente al referenciar el tablero, podemos entender básicamente cuál es el paso exacto, qué agente realmente ejecutará último. Así que podemos entender básicamente dónde se atascó. Entonces un humano puede realmente entrar en el bucle y sacarlo de allí, como desbloquear el siguiente paso y luego asignarlo de nuevo al, al agente. Tomaremos una pregunta más porque nos queda un minuto aquí. Voy a preguntarte sobre métricas. Me encantan las preguntas sobre métricas. ¿Tienes métricas para el tiempo desde la idea hasta la producción antes y después de la IA? ¿Idea a producción antes y después de la IA? Específicamente para este tipo de, para este tipo de migración, diría que este tipo de migración tomaría aproximadamente, para todos estos repos, tomaría aproximadamente seis meses más o menos. Pero con este tipo de enfoque, incluso como construyendo también como esta especie de flota de agentes, nos tomó como tres, tres meses, digamos. Así que, y también puedes básicamente depender de este tipo de flota para el próximo tipo de migración también. Así que básicamente aquí es donde reside el valor.

Increíble. Sé que quedaron muchas preguntas en la diapositiva. No sé si te quedarás para el resto de la conferencia. Sí, estaré por aquí. Así que por favor siéntete libre de encontrarme y hacer cualquier pregunta. Muchas gracias. Increíble. Gracias a todos.