Modernización de Legado Acelerada por AI

Así que sí, quiero hablarles hoy sobre nuestros aprendizajes en la adopción de IA en modernizaciones de sistemas heredados. Y primero, por qué este es realmente un problema muy importante es que nuestro mundo funciona con sistemas de TI heredados construidos hace más de 20 años. A medida que el software ha consumido nuestro mundo y se ha apoderado de aviones, coches, hogares y atención médica, esto en realidad se ha construido como capas y capas sobre el TI heredado que opera nuestro mundo, la energía, y el transporte, las infraestructuras de finanzas y comunicación. Y esto en realidad está comenzando a mostrar algunos problemas bastante grandes porque está creando tres tipos de riesgos.

Primero, el riesgo empresarial. Por ejemplo, Nike Capital, una empresa de comercio, se apresuró a lanzar una nueva función y reactivaron por error ese código en los sistemas que no habían tocado durante nueve años, pero que habían olvidado eliminar. Y esto creó actividades de entrenamiento extrañas y perdieron $440 millones en solo un día. Luego está el riesgo de seguridad. Otro ejemplo es que el sistema Scala que controla la red eléctrica de Ucrania que data de la era soviética permitió a los atacantes cortar remotamente la energía dos veces en el país. Y finalmente, un riesgo de cumplimiento.

Sabes, cuando Citigroup transfiere $81 billones a uno de sus clientes por error, lo que te hace querer convertirte en cliente de Citigroup, por supuesto. Y en realidad es la décima vez que han transferido más de $1 billón por error. Bueno, cada vez lograron deshacer la transferencia, pero en algún momento fueron multados con $136 millones por estos sistemas muy torpes. Así que invertir en la modernización de TI heredado se está convirtiendo en un problema global. Pero, por supuesto, todas las organizaciones en todo el mundo están procrastinando porque las modernizaciones son problemas increíblemente difíciles. De alguna manera categorizamos los desafíos en cuatro categorías.

El primero es la ecología heredada. Una vez que comienzas a intentar entender el sistema, te das cuenta de que nadie en la organización recuerda las reglas de negocio. Luego tienes la ruptura de confiabilidad. Todo el mundo tiene miedo de tocar algo que más o menos funciona porque tocarlo probablemente creará más problemas al menos al principio. Luego está la congelación de características. Sabes, el negocio se molesta mucho cuando les dices que vas a dejar de construir nuevas características durante mucho tiempo mientras modernizas la infraestructura subyacente. Y finalmente, el motín de migración, porque los equipos que trabajan en los sistemas heredados a menudo no están tan emocionados de ayudar al equipo que migra a nuevos sistemas, a pesar de ser realmente bastante críticos para lograr el éxito de la modernización.

Así que aquí es donde entra la IA, especialmente desde que diría Cloud4, GPT4, cuando la IA comenzó a poder realmente codificar tareas decentes por sí sola. Así que es una oportunidad única. Y en Theodo, cuando llegó la IA, se preguntaban, OK, no está muy claro cómo adoptar la IA en la resolución de problemas y la construcción de nuevos productos porque estos son problemas muy difíciles, muy complejos. Pero probablemente cuando se trata de reescribir tecnologías, modernizar pilas, ese debería ser un gran lugar para comenzar. El problema es que la IA trae velocidad, pero también variabilidad. Y así, la combinación de los dos, cuando no se controla, lleva al caos. Y esto es, por supuesto, lo que todos sabemos como ingenieros, lo que todos tememos como ingenieros es como una codificación de vibraciones locas entrando en producción.

Entonces, ¿cómo aceleramos con IA, pero evitamos el caos? Así que voy a mostrarlo muy concretamente en un ejemplo, muy inspirado en un ejemplo de la vida real pero he fusionado algunas cosas, algunos ejemplos múltiples juntos. Ese ejemplo era un líder en el espacio de la telemedicina que quería fusionar su pila. Así que el backend necesitaba una migración completa porque había sido construido en Loopback 2, lo que significaba que estaban atrapados con Node 10. Eso era inaceptable. Así que la idea era migrar a Node 20 y salir de Loopback. Y con 114 puntos finales de API migrados, esto parecía un proyecto factible en unas 26 semanas.

Por supuesto, tan pronto como comenzaron a analizar la migración, tan pronto como comenzaron a ejecutar y también comenzaron a usar herramientas de análisis estático para analizar adecuadamente el sistema, se dieron cuenta de que el sistema era mucho, mucho más complicado de lo esperado con muchas, muchas dependencias y dependencias cruzadas. Y peor aún, incluso la herramienta de análisis estático había pasado por alto grandes partes de dependencias ocultas detrás de hooks. Así que la nueva estimación pasó de 26 semanas a 70 semanas. Si has hecho un proyecto de migración por el momento, todo es normal. Así que el pobre CTO tiene que encontrar una solución y por suerte nos encontramos y le cuento sobre nuestra experiencia de migrar una aplicación en cuatro meses en lugar de 12 usando IA.

Así que esta fue realmente nuestra primera gran monetización acelerada por IA pasando de iOS y Android a React Native. Así que no sé si eso lo convenció o si simplemente no tenía otra opción. Pero de todos modos, aceptó trabajar juntos. Y así es como comenzamos. Así que, por supuesto, volviendo a la pregunta inicial, que es cómo aceleramos con IA pero evitamos el caos. Traemos nuestra salsa secreta en Theodos, que es Lean Tech. Entonces, ¿qué es Lean Tech? Lean Tech es el sistema que hemos construido en Theodos durante los últimos 12 años, creciendo de 10 personas a 700 personas. Y así, trayendo todo el conocimiento de Lean Thinking. Así que básicamente lo que hace de Toyota una empresa increíble para la ingeniería de software, para mantener la agilidad empresarial y técnica mientras escalamos.

Y lo que hemos descubierto es que Lean Tech no solo era súper relevante para nosotros para crecer como empresa, sino que en realidad es aún más relevante en esta era de IA. Así que el primer principio de Lean Tech es el valor para el cliente. Y ese es un principio guía muy interesante porque lo que nos dimos cuenta es que cuando estamos monetizando, lo primero que necesitamos hacer es descomponer el sistema heredado en puntos de contacto, eso es lo que llamamos, que tienen sentido para un usuario de negocios. Y para eso, tenemos un agente de descubrimiento que recorre el sistema y comienza a mapear como puntos finales individuales y las dependencias. Y luego usamos otro agente, un agente de ingeniería inversa para explicar cada punto de contacto, pero a nivel empresarial, para que realmente podamos entender lo que está sucediendo. Así que una documentación adecuada, bastante técnica, pero que realmente explica cuál es el valor.

Así que espero que esto funcione. Es hora de la demostración. Correcto. ¿Cómo funciona esto? Sí, es tiempo de semi-demostración. Es un video, no soy yo, por favor. Tal vez me lo estoy perdiendo. Bien, está funcionando. Así que esta es una herramienta que construimos para visualizar todos los endpoints que tenemos en un sistema, y podemos seleccionar el endpoint que queremos migrar. Probablemente sea hora de ir un poco más rápido. Y aquí puedes ver para eso, para los endpoints seleccionados, todas sus dependencias, puedes navegar a través de eso. Quiero decir, ya obtienes instantáneamente una sensación de la complejidad de esto. Así que aquí ves primero muchas dependencias, pero también dependencias cruzadas entre clases y funciones. Así que esto no parece el mejor y más fácil ejemplo, y luego puedes hacer clic en una clase particular, por ejemplo, función, y generar documentación aquí. Esto explicará, en realidad hay bastante trabajo en el fondo, y explicará que esto, por ejemplo, es responsable de cargar CSVs a S3. Y luego tienes, ya sabes, esquemas y explicaciones.

Bien, así que ese fue el paso uno, entender mejor lo que hace el sistema heredado, y descomponer el problema en fragmentos que realmente tengan sentido para los usuarios de negocios que llamamos puntos de contacto. Entonces, ¿por qué los llamamos puntos de contacto? Porque son ya sea endpoints de API, cuando estamos hablando de backend generalmente, o cuando estamos hablando de frontend, serán pantallas o interacciones, que de todos modos, cosas que un usuario puede luego validar y probar. Así que vamos al revés, probamos y validamos. El siguiente principio de Lean Tech es la red de equipos habilitada por tecnología. Y así, la idea es que si quieres agilidad a escala, necesitas la arquitectura modular adecuada para apoyar la topología de equipo correcta. Así que, por supuesto, lo que queremos cuando estamos modernizando un sistema es mejorar en gran medida la arquitectura. Entonces, ¿cómo hacemos eso? Aquí es donde traemos a nuestro agente arquitecto que combina la comprensión del sistema heredado. Así que básicamente, todo lo que hemos construido en la etapa anterior con los códigos y con nuestros estándares de arquitectura, para escribir lo que esto realmente significa en términos de estrategia técnica de migración.

Es hora de escribir el código ahora, y ahí es donde el principio de hacerlo bien a la primera de Lean Tech es súper importante. Porque lo que decimos en Lean es que si quieres industrializar y mantener una calidad súper alta, necesitas asegurarte de que desplazas la calidad hacia la izquierda y que te detienes lo antes posible cuando detectas problemas de calidad. Entonces, ¿qué significa eso en la práctica? Eso significa en la práctica que no estamos codificando al azar aquí. Estamos usando lo que llamamos el enfoque Jidoka para IA, para usar una palabra elegante de Lean. Pero básicamente, la idea es que iteramos en nuestros codificadores agentes hasta que logran una precisión muy, muy alta en, digamos, los primeros ejemplos que estamos escribiendo. Por supuesto, eso significa que estamos escribiendo pruebas, el código está probado, y luego todavía programamos en pareja con los codificadores agentes.

Otro gran aspecto es que nos hemos dado cuenta de que si queremos una precisión muy alta, dependiendo del tamaño del problema, a menudo tenemos que descomponer el punto de contacto y los componentes más pequeños para obtener resultados mucho más fiables. Aquí es donde hay un gran, digamos, esfuerzo de arquitectura por parte del líder técnico.

Finalmente, tenemos un agente de QA que luego ejecuta una batería de pruebas en el sistema para verificar que todo esté funcionando. Tiempo de demostración. Al igual que un truco de magia, esto es solo para confirmar que no hay un conejo en el sombrero. Básicamente, que este endpoint no funciona. Bien, 500 no funciona. Perfecto. Ahora vamos a ejecutar el codificador agente. Podrás verlo codificar en el lado derecho, y en el lado izquierdo, VS Code te muestra el resultado.

Esto está acelerado. Ves el tiempo en la esquina superior derecha. Y así, ocho minutos después, el agente ha terminado. Así que es hora de ejecutar el agente de QA. Eso toma menos de cuatro minutos. Y hemos terminado. Todas las pruebas están en verde. Ahora es el momento de verificar si funcionó. Sí, el endpoint de la API ahora está liberando, produciendo los resultados correctos. Este ejemplo, por supuesto, para el efecto de demostración, no es uno donde necesitábamos programar en pareja. La tarea era lo suficientemente simple como para que realmente funcionara bien a la primera. Estimamos que si hubiéramos necesitado codificarlo por nuestra cuenta, nos habría llevado alrededor de dos horas. Así que de 12 a 120 minutos. Eso es interesante porque es un tipo de orden de magnitud consistente que nos damos cuenta. En tareas específicas, tenemos aproximadamente una aceleración de 10x. Muy bien. No, por favor. No otra vez. Luego hay un paso crítico, claramente informado por nuestra cultura lean tech, que es aprovechar el principio de construcción y aprendizaje organizacional haciendo Kaizen. Kaizen es otra palabra elegante de lean.

Hay muchos de ellos. Para capturar la idea de mejora continua. Y aquí lo que estamos haciendo, lo cual es interesante, es que estamos verificando todas las modificaciones que hicimos durante la sesión de programación en pareja. Así que cosas con las que no estuvimos de acuerdo, etcétera. Y el agente recopila todos esos datos, analiza lo que podría haberse mejorado. Así que aquí, por ejemplo, un comentario sobre estar descontento con algo. Y eso luego se utiliza para escribir sugerencias de lo que debería mejorarse a nivel del sistema. Así que cómo deberían modificarse los agentes o los estándares para evitar ese error en el futuro. Así que eso es algo que, por supuesto, debería ser hecho por los humanos. Pero nuevamente, usamos un agente para acelerar parte de ese trabajo.

Y esto significa, por supuesto, que luego podemos industrializar. Porque cuanto más robusto y resiliente se vuelve el sistema, más podemos comenzar a acelerar toda la migración. Así que es hora del último principio de este sistema LeanTech, que es ajustar a tiempo. Así que ajustar a tiempo son realmente principios que son bastante famosos en la manufactura. Inspirados en cómo Toyota produce millones de autos cada año con una calidad súper alta y una flexibilidad súper alta. Así que en resumen, industrializamos toda la migración alrededor de estos principios de confianza en el tiempo, asegurándonos de que si hay algún problema en cualquier etapa, hay una luz roja que aparece, detiene la cosa, valida los problemas, y siempre hay un humano para verificar y ensamblar todas estas cosas juntas para asegurarse de que funcione.

Así que los resultados en ese ejemplo particular, como dije, una aceleración de 10x por endpoint. Por supuesto, no solo estamos migrando los endpoints. Tenemos que invertir en el ajuste de la IA. Tenemos que invertir en la descomposición del problema, etcétera, etcétera, etcétera. Y luego tenemos que reensamblar todo. Así que lo que realmente hemos hecho en la práctica es terminar la migración en 21 semanas, en lugar de las 70 semanas que se habían estimado después del primer paso. El primer intento. Y lo que es muy importante cuando hablamos de IA, debido a la forma en que usamos la IA, que definitivamente no es codificación de vibraciones, en realidad terminamos con una arquitectura de mucho mayor calidad. Los dos aprendizajes que quiero compartir de todo esto. Primero, que los 70 años de aprendizajes de Toyota sobre cómo automatizar la fabricación de automóviles, así que un problema de entrega muy, muy complejo, y hacerlo mientras se entrega una calidad superior. Toyota es muy famosa por tener cuatro veces menos problemas de fiabilidad en los autos que la mayoría de los competidores. Todos estos aprendizajes, que generalmente se capturan bajo el cuerpo de conocimiento llamado Pensamiento Lean, son increíblemente relevantes para nuestra era de IA. Y eso es muy bueno para nosotros, porque hemos invertido 12 años, así que estamos bastante contentos. Y el segundo aprendizaje es que la IA puede contribuir a reconstruir infraestructuras saludables si se hace correctamente o si se usa de la manera correcta.

Eso es todo. Gracias. Muy bien. Genial. Así que tenemos muchas preguntas para ti. Comenzaremos con esta, de hecho. ¿Cómo manejas la gran cantidad de código generado por la IA? ¿No se vuelve abrumador bastante rápido? Quiero decir, esa es definitivamente una de las razones por las que solo estamos yendo tres veces más rápido en esta etapa, porque está acelerando mucho del código repetitivo que tienes que escribir, pero como todavía lo estamos validando, no estamos obteniendo una aceleración de 10x o 100x. Esa es una respuesta. Y la otra respuesta es, por supuesto, en nuestros estándares de arquitectura y en las guías que estamos escribiendo, estamos tratando de aportar todo nuestro conocimiento de cómo crear mejores sistemas, así que típicamente creando los niveles correctos de abstracción, para que no crees miles de líneas de código inútiles. Exactamente. Gracias.

Y eso en realidad se relaciona bien con cómo sabes que el agente de QA lo está probando correctamente. Así que cosas como el alcance, true equals true, y cosas así. Medimos claramente la cobertura del código. Bueno, diseñamos un agente de QA para probar las características, por eso también separamos la comprensión de lo que hace la característica del plan de migración tecnológica, eso es parte de la respuesta. Pero para dar una respuesta más transparente, también hemos intentado generar pruebas sobre el código solo para aumentar la cobertura del código. Así que un ejercicio muy interesante donde, claramente, estás completamente sesgado porque estás generando la prueba a partir del código. Pero un aprendizaje interesante de hacer eso es que en realidad identificamos errores en el código porque la IA tiene esta extraña inteligencia donde no probó lo que hacía el código, sino que probó cuál era la intención de la función, y así identificó este caso límite que no había sido capturado antes. Gracias por eso.

Y alguien tiene una pregunta sobre si tu enfoque de múltiples agentes y desarrollo algo específico también sería adecuado para cualquier nueva característica en un entorno empresarial. Así que eso es muy interesante. Quiero decir, entonces Theodore, soy el cofundador de Theodore, somos una consultoría tecnológica. Y entonces nuestro trabajo es construir productos tecnológicos para una amplia gama de clientes. Y claramente, la razón por la que estoy hablando hoy sobre modernizaciones es que, tan pronto como la IA se convirtió en este tipo de pregunta existencial, no amenaza, pero pregunta existencial para nosotros, también nos dimos cuenta de que no estaba claro cómo la aprovecharíamos en la construcción de productos. Así que eso es realmente algo importante. Así que sabíamos que si invertíamos en modernizaciones, aprenderíamos mucho mientras creábamos valor muy rápidamente. Y algunos de estos aprendizajes podrían luego capturarse en la construcción de productos. Así que sí, en algunos proyectos ahora, podemos ir, diría, sí, casi 2, 3x más rápido en como nuevas construcciones. Pero aún con muchas restricciones, básicamente necesitas que los líderes tecnológicos, aprovechando la IA, tengan mucha autonomía sobre el producto. Porque no tienen, como si dependieras de un propietario del producto, y si ese propietario del producto depende de muchos interesados para tomar decisiones, entonces la IA básicamente va demasiado rápido. Y el cuello de botella ya no es la IA, ni la codificación. Es realmente como las decisiones del producto.

Así que si las decisiones del producto no son el cuello de botella, ahora estamos alcanzando una etapa donde realmente estamos mejorando en la construcción de productos. Así que esos son la mayoría de los productos que he visto en mi vida. Las decisiones del producto son el cuello de botella. Sí, de acuerdo.

¿Y qué modelos de IA has utilizado para la migración de eso, por ejemplo? ¿Y cómo evaluaste qué modelo usar? Sí, así que los evaluamos todos de manera regular, por supuesto. El que aún destaca, y necesitamos probar Gemini 3 seriamente, pero Claude ha sido nuestra preferencia, porque es mucho más, no quiero decir obediente, pero esa es la intención, sigue las reglas mucho mejor. Y dado que nuestro enfoque es que cada vez que hay un error, iteramos y añadimos como una regla para evitar ese error en el futuro, es mucho mejor tener un Claude que realmente tenga en cuenta cada una de las reglas, en lugar de un GPT que es bastante creativo y decide a veces no seguir las reglas que le hemos dado. Gracias.

Y esto en realidad es agradable para este. ¿Tienes algún ejemplo, ya que parece que estás usando Claude, archivos de comando que estás usando en un repositorio de GitHub, en algún lugar para ayudarnos a implementar este enfoque de lean tech? Oh, ¿quieres decir ejemplos de código abierto? Sí. Ah. No, aún no. Es una buena pregunta cuánto queremos compartir. Quiero decir, parte de esto es como, digamos, propiedad intelectual. No, estoy muy feliz de compartir muchos de nuestros aprendizajes, porque creo que es un problema global. Y no lo abordaremos por nuestra cuenta. Pero sí, no, no creo que hayamos abierto nada aún. Así que aún no es la respuesta. Bien, genial. Hay algunas preguntas más. Bien. Lo siento, es solo que tengo algunas. Aquí estamos. Así que una pregunta sobre si todos los equipos pierden su conocimiento de sus bases de código y se vuelven dependientes de la IA incluso para la solución de problemas básicos. ¿Cómo ves eso manifestándose? Quiero decir, claramente, ahora mismo, de nuevo, sabes, los casos de uso de los que estoy hablando, el equipo ha olvidado completamente lo que el negocio incluso hace. Como, ni siquiera entienden las características. Así que no estamos empeorando la situación. La estamos mejorando. Esa es la respuesta real. Pero por supuesto, sí, pero ese es otro debate completo, que es que cuando usas IA en productos actuales, hay un compromiso entre la velocidad a la que vas y el dominio de las características que estás construyendo. Fabrice, muchas gracias. No podemos responder a todas las preguntas, pero este es el tiempo. Muchas gracias. Gracias, Fabrice.