Las organizaciones que tomen en serio esta transición no funcionarán mejor; tendrán una ventaja estructural compuesta que se desarrollará con cada ciclo de implementación.
Durante gran parte de la historia de la ingeniería de software hemos operado bajo un modelo engañosamente simple. Los ingenieros determinan el comportamiento. Los sistemas se ejecutan. Cuando el comportamiento es incorrecto, los ingenieros lo solucionan. Cuando los requisitos cambian, los ingenieros los reescriben. Entre publicaciones, el sistema es lento. No aprende de lo que ve en la producción. No se ajusta a la forma en que realmente juegan los usuarios. No mejora por sí solo.
Ese modelo se está volviendo obsoleto. No porque los ingenieros de software estén siendo reemplazados, sino porque los sistemas que construyen están cambiando fundamentalmente por naturaleza. Una nueva generación de sistemas de software aprende continuamente de los datos generados en operación, mejora su comportamiento mediante el aprendizaje por refuerzo y la experimentación estructurada y, en algunos casos, genera y extiende su propio código en tiempo de ejecución.
La disciplina de la ingeniería de software está pasando de la construcción de software a la construcción de sistemas de aprendizaje. Este cambio es tan importante como cualquier transición que haya experimentado el campo desde que pasó de cascada a ágil. Este fue el argumento principal que expuse en la Conferencia Internacional sobre Ingeniería de Software 2026 en Río de Janeiro, y quiero intentar desentrañarlo aquí con la ayuda de algunas empresas que ya lo están concretando.
Vale la pena trazar con cuidado la distinción entre un sistema que utiliza IA y un sistema que aprende continuamente. La mayoría de las organizaciones han hecho lo primero. Han incorporado modelos de IA en sus productos, han mejorado las predicciones y han implementado funciones más inteligentes. Muy pocos han hecho esto último: construir sistemas de producción que cierren el ciclo de retroalimentación entre la implementación y la mejora, sin requerir que los ingenieros recopilen datos manualmente, rediseñen y rediseñen los modelos.
La diferencia no es de grado; es arquitectónico. Un sistema de aprendizaje trata cada interacción de producción como una señal de entrenamiento, cada implementación como un experimento y cada falla como retroalimentación. Construir uno requiere diferentes patrones de diseño, diferente infraestructura y otra comprensión de lo que es fundamentalmente la ingeniería de software.
Se están uniendo cuatro técnicas para hacer esto posible a escala de producción. El primero es el aprendizaje por refuerzo. A diferencia del aprendizaje supervisado, que requiere datos de capacitación etiquetados y preparados de antemano, RL permite que un sistema aprenda haciendo: tomando acciones, observando resultados y actualizando su comportamiento en la dirección de mejores resultados. En dominios con decisiones secuenciales, desde la recomendación de contenido hasta el enrutamiento logístico y la optimización de la red, el cambio en las capacidades es profundo. Un sistema que optimiza las rutas de envío con RL no necesita que un ingeniero le diga cuál es la ruta correcta; descubre lo que funciona recorriendo rutas, midiendo resultados y mejorando constantemente.
Anyscale, la compañía detrás del marco de computación distribuida Ray, ha hecho que este tipo de aprendizaje por refuerzo de nivel de producción esté disponible operativamente a través de RLlib. Empresas como Grab, Ericsson y JPMorgan ejecutan cargas de trabajo de RL en vivo en esta infraestructura y Physical Intelligence la utiliza para entrenar sistemas robóticos. Lo que Anyscale ha demostrado es que RL ya no es una curiosidad de investigación limitada a los puntos de referencia de los juegos; Es una disciplina operativa en los procesos de negocio que se ejecutan a escala de producción.
La segunda técnica es el aprendizaje federado. Se enfrenta a un problema estructural que ha limitado la IA a lo largo de su historia comercial: los datos más valiosos del mundo no se pueden mover. Los registros médicos están sujetos a reglas de privacidad. Las transacciones financieras están sujetas a confidencialidad contractual. Los datos de los sensores de equipos industriales pertenecen a clientes que no los compartirán. La telemetría automotriz está ubicada en vehículos distribuidos en decenas de países. Los enfoques tradicionales para entrenar modelos de IA requieren centralizar datos, lo que los hace inaccesibles para la mayoría de las aplicaciones comerciales de alto valor. El aprendizaje federado revierte esto por completo. En lugar de mover los datos al modelo, el modelo se distribuye donde residen los datos. La formación se realiza localmente. Sólo se comparten las actualizaciones matemáticas del modelo, no los datos subyacentes, para fusionarlos en un modelo global compartido.
Flower Labs, una empresa con sede en Cambridge y Berlín que surgió de la investigación de la Universidad de Cambridge y ahora cuenta con el respaldo del director ejecutivo de Felicis, Mozilla Ventures y Hugging Face, entre otros, ha creado el marco de código abierto más aceptado para el aprendizaje federado. Nokia, Porsche, Samsung y Brave son usuarios de producción. El marco se ha utilizado en experimentos simultáneos con quince millones de clientes. Para las empresas con uso intensivo de software que operan en sectores con datos distribuidos, confidenciales o regulados, incluidos los de automoción, atención sanitaria, servicios financieros e IoT industrial, Flower AI es la forma de entrenar sistemas con datos que antes no estaban disponibles. La implicación competitiva es significativa: las organizaciones que aprenden a capacitarse con datos privados distribuidos tendrán sistemas de inteligencia artificial que sus competidores, que dependen únicamente de datos públicos o centralizados, no podrán igualar.
La tercera técnica es la generación de código en tiempo de ejecución y la autorreparación. Éste es el más maduro comercialmente de los cuatro, pero posiblemente el más intelectualmente significativo para la disciplina de la ingeniería de software. El software tradicional falla de dos maneras: o falla de dos maneras, lo cual es detectable y reparable, o se degrada silenciosamente, lo cual no lo es. Un sistema de aprendizaje puede hacer algo diferente: cuando encuentra un error de tiempo de ejecución que no ha visto antes, puede crear dinámicamente un controlador para ello, implementar la solución y continuar trabajando sin intervención humana.
Grupos de investigación de diferentes universidades lo han demostrado con sistemas prototipo que utilizan grandes modelos de lenguaje para generar estrategias de manejo de excepciones en tiempo de ejecución, utilizando el contexto de error, el estado del programa y el comportamiento deseado. En el aspecto comercial, la arquitectura de sistemas como Cursor y Windsurf está empezando en esta dirección, aunque cuentan con el apoyo de desarrolladores y no son completamente autónomos. Aquí la brecha entre la investigación y la expansión de la producción sigue siendo amplia. Pero la dirección no es ambigua: los sistemas que pueden cambiar a sí mismos en respuesta a una falla son cualitativamente diferentes de los sistemas que requieren intervención humana para recuperarse.
La cuarta técnica, la experimentación sistemática A/B, puede ser la más subestimada. La mayoría de las organizaciones realizan experimentos de vez en cuando cuando un gerente de producto tiene una hipótesis que vale la pena probar. Las organizaciones que aprenden más rápido han hecho que la experimentación sea continua y estructurada: cada implementación es un experimento, cada decisión del sistema es una hipótesis comprobable y el canal entre la observación y la mejora se ejecuta automáticamente. Este no es un simple cambio de herramienta; Representa otra teoría de cómo el software mejora los sistemas.
Fundada en París y ahora una de las plataformas de experimentación líderes en Europa, Kameleoon ha trabajado para capas en línea y de pila completa, combinando puntuación de funciones, pruebas A/B, experimentos multivariados y segmentación basada en IA en tiempo real en una sola plataforma. La idea que ha incorporado en su arquitectura es que la experimentación y la personalización no son actividades separadas: las señales de cada experimento mejoran la orientación para el siguiente, y los datos de orientación informan qué probar. Las organizaciones que realizan miles de experimentos al año aprenden de sus sistemas a un ritmo muy diferente al de aquellas que realizan docenas.
Lo que hace que estas cuatro técnicas sean más que una interesante colección de herramientas es lo que sucede cuando se combinan en una arquitectura de aprendizaje coherente. El aprendizaje por refuerzo requiere una señal de recompensa y, en los sistemas de producción, esa señal proviene de la observación continua del comportamiento del usuario y del sistema. El aprendizaje federado requiere activos de datos distribuidos, pero el modelo que produce puede mejorarse continuamente mediante RL y experimentación. La generación de código ejecutable proporciona un mecanismo para un cierre más rápido de lo que permite el ciclo de desarrollo humano. Y la experimentación sistemática A/B valida el comportamiento real antes de la implementación completa, creando un volante de datos que agrava la calidad de cada iteración de aprendizaje posterior. Cada técnica potencia a las demás. Juntos definen lo que significa construir un sistema de aprendizaje en lugar de un sistema estático.
Las implicaciones para la disciplina de la ingeniería de software no son triviales. Construir un sistema de aprendizaje requiere habilidades que la mayoría de las organizaciones de ingeniería no han desarrollado. El diseño de funciones de recompensa, la especificación de para qué debería optimizarse un sistema RL, es una disciplina de ingeniería nueva y verdaderamente desafiante que se encuentra en la intersección del pensamiento de producto y la ingeniería ML. La gobernanza de datos y la arquitectura de privacidad son requisitos previos para el aprendizaje federado, no ideas tardías. Monitorear un sistema que cambia su comportamiento requiere herramientas de observabilidad diferentes a las de monitorear un sistema que ejecuta código fijo. Y las estructuras organizativas que surgieron de modelos de desarrollo basados en proyectos a menudo no se adaptan a los ciclos de mejora continua basados en datos que requieren los sistemas de aprendizaje.
Las organizaciones que tomen en serio esta transición no funcionarán mejor; tendrán una ventaja estructural compuesta que se desarrollará con cada ciclo de implementación. Cada interacción que tiene su sistema en producción genera datos. Cada dato mejora el modelo. Cada mejora del modelo hace que el siguiente experimento sea más informativo. El aprendizaje se acelera con el tiempo. Las organizaciones que permanecen en sistemas estáticos tienen una creciente brecha de habilidades que no se puede cerrar contratando más ingenieros o enviándolos más rápido. Parafraseando a Donella Meadows: «No se puede entender un sistema desde dentro del sistema».
