Cómo llevar software legado a un ciclo de vida de desarrollo con IA

Toda conversación sobre desarrollo asistido por IA acaba chocando con el mismo muro: «eso está bien para apps nuevas, pero nuestro negocio corre sobre un monolito de Rails de doce años y un sistema de facturación en Java que nadie entiende del todo». El muro es real, la mayoría de herramientas de desarrollo con IA asumen algo desde cero, pero la conclusión que sacan de él los equipos, que los sistemas legados deben esperar una reescritura antes de que la IA pueda ayudar, está exactamente al revés. Los sistemas legados son donde más paga la ingeniería asistida por IA, porque son donde realmente viven la carga de mantenimiento, el riesgo de conocimiento y la acumulación.

Llevar un sistema legado a un ciclo de vida de desarrollo con IA no significa pedirle a un modelo que lo regenere. Significa darle al código existente el mismo circuito de entrega que disfruta una app nueva construida con IA: un entorno donde el sistema corre de forma reproducible así los agentes pueden trabajar en él de forma segura; un mapa de qué código pertenece a qué función de negocio; políticas que protegen las zonas peligrosas; una línea base de tests automatizados en torno al comportamiento que no debe cambiar; y una ruta controlada del cambio al despliegue. Una vez que existe ese circuito, los agentes de IA pueden cargar con el trabajo que temen los humanos (actualizaciones de dependencias, acumulación de bugs, pequeñas funciones, documentación) bajo gobernanza, mientras el sistema sigue sirviendo producción.

El reencuadre estratégico: la modernización deja de ser un destino (la gran reescritura, siempre a dieciocho meses de distancia) y se convierte en una propiedad de cómo se mantiene el sistema de ahora en adelante. Los sistemas en el circuito se vuelven incrementalmente más saludables con cada cambio gobernado. Los sistemas fuera de él decaen según lo previsto.

Un modelo mental útil: trata el sistema legado como un paciente siendo admitido, no un edificio siendo demolido. La admisión significa observación primero (reprodúcelo, mapéalo, establece la línea base de su comportamiento) luego tratamiento en dosis crecientes conforme se acumula evidencia. Nada sobre la admisión requiere creer que el sistema es bueno; requiere solo que el sistema sea de carga estructural, que es precisamente por qué merece maquinaria en lugar de heroicidades. Las etapas de abajo son ese proceso de admisión, en orden, con el riesgo cargado al frente sobre pasos reversibles.

El dolor es estructural, no accidental. Los ingenieros que entendían el sistema se han ido o han avanzado, así que cada cambio empieza con arqueología. La cobertura de tests es delgada o ritual, así que cada despliegue es un pequeño acto de valentía, así que los despliegues son raros, así que los cambios se acumulan, así que los despliegues se vuelven más arriesgados, el clásico ciclo de fatalidad. Mientras tanto la acumulación de peticiones de negocio crece, y las personas capaces de tocar el sistema gastan su capacidad manteniéndolo vivo en lugar de mejorarlo. Esto es precisamente un problema de capacidad, que es precisamente lo que aborda la ingeniería asistida por IA, si existe la maquinaria de seguridad para que los agentes trabajen dentro de ella.

La válvula de escape tradicional, la reescritura de gran explosión, tiene un historial de fallos que conoce todo CIO: cronogramas de varios años, el sistema antiguo evolucionando por debajo del nuevo, el último 20% del comportamiento, sin documentar, de carga estructural, consumiendo la mayor parte del presupuesto. Las reescrituras fallan porque exigen que la organización entienda todo el sistema a la vez, que es exactamente el conocimiento que se perdió. Los enfoques incrementales tienen éxito porque solo requieren entender un cambio a la vez, y un cambio a la vez es exactamente la granularidad que manejan bien los agentes de IA más la gobernanza.

También hay una realidad de talento. Nadie quiere el asiento de mantenimiento en un sistema legado, y contratar para él se hace más difícil cada año. Envolver el sistema en un ciclo de vida de desarrollo con IA convierte ese asiento de arqueología a tiempo completo en dirección y revisión, un rol que las personas sénior realmente aceptarán.

La propia acumulación te dice cuánto valor está atrapado. La mayoría de sistemas envejecidos cargan años de peticiones aplazadas (pequeñas funciones, solicitudes de integración, cambios de informes) que individualmente nunca valieron el riesgo de despliegue. Esa es la aritmética cruel del ciclo de fatalidad: cuanto más arriesgados se vuelven los despliegues, más alto el listón para intentar uno, más larga crece la cola. Rompe el ciclo (cambios baratos, seguros, gobernados) y la cola se convierte de una lista de pasivos en un pipeline de valor, por eso la reducción de acumulación es la métrica temprana más persuasiva para estos programas.

Esta entrada es una ruta de primera clase en Ciao, no una adaptación. Las imágenes de sandbox personalizadas envuelven la ingeniería asistida por IA en torno a backends de Rails, Java, Go, Python, Node y multiproceso: la etapa dos del marco como capacidad de plataforma. Guardrails luego hace el mapeo y la protección: mapea el código en áreas de negocio, detecta cambios de riesgo, aplica políticas en lenguaje sencillo, registra la revisión humana y deja un registro de auditoría tras cada merge, que es exactamente la postura de gobernanza primero que exigen los sistemas legados. QA construye y ejecuta la línea base: réplicas deterministas del navegador, tests autorreparables, smoke gates antes de publicar, comprobaciones de producción después, y Doctor examina la app en vivo, el DNS y el CDN para diagnosticar la causa raíz cuando algo se comporta mal.

Para portafolios en lugar de sistemas individuales, Conductor da una sola pantalla para cientos, a veces miles, de proyectos con salud en vivo y visibilidad de zona protegida, que es lo que realmente necesita un programa de modernización continuo para ser gestionado por un equipo pequeño. El despliegue puede quedarse donde lo exija el cumplimiento: tu propia cuenta de AWS, Azure o GCP, VPC privada, u on-prem bajo términos aparte. Los programas de desarrollo serios empiezan en 10.000 USD al año. La conversación a tener con ventas es concreta: trae un sistema envejecido y su acumulación, y delimita cómo se ve la etapa uno para él.

Fija expectativas honestamente dentro de tu organización: las primeras semanas producen infraestructura, no funciones (un entorno reproducible, un mapa de áreas de negocio, una línea base de tests) y eso puede parecer lento para las partes interesadas a quienes se les prometió velocidad de IA. La acumulación empieza después: cada cambio subsiguiente monta sobre los mismos raíles, y el centésimo cambio gobernado cuesta una fracción del primero. Los programas que comunican esta forma por adelantado mantienen a sus patrocinadores; los programas que prometen velocidad instantánea en una base de código de doce años pasan el mes tres disculpándose.