Este artículo propone un reparto: qué conviene dejar que automatice la IA en una modernización de aplicaciones heredadas y qué debe seguir firmando una persona, con el criterio y la evidencia que eso exige.
1. Por qué vuelven las aplicaciones que nadie priorizaba
Casi toda organización tiene un parque de aplicaciones internas que nunca llegó al primer puesto de la lista: la herramienta de un departamento, el batch que alguien escribió hace quince años, la aplicación que «funciona» y que solo entiende una persona. No eran urgentes y modernizarlas costaba lo mismo que las críticas, así que esperaban.
La IA agéntica cambia esa cuenta por un lado: baja el coste de analizar código, de extraer reglas, de generar documentación y de proponer una primera versión del código nuevo. Es la parte que antes obligaba a meses de arqueología. Pero el coste que no baja es el de responder por el resultado: alguien tiene que poder decir «esto hace lo mismo que lo anterior, y estas son las diferencias que hemos aceptado». Mi tesis es sencilla: la IA abarata producir el cambio; no abarata certificarlo, y los proyectos que se tuercen son los que presupuestan lo primero y olvidan lo segundo.
2. Qué automatiza hoy la oferta pública
Para no hablar en abstracto, conviene mirar qué dice el propio proveedor. La documentación de AWS Transform (consultada el 3 de noviembre de 2026) describe agentes especializados para cinco casos de uso: evaluaciones de migración, migraciones de servidores (incluido VMware), modernización de Windows y .NET, modernización de mainframe y modernización de código a medida. Lo relevante para este artículo es qué hacen con el código:
- Mainframe: análisis de COBOL, PL/I y JCL con mapas de dependencias; refactorización a Java o C# «preservando la lógica de negocio»; un flujo trazable que extrae reglas de negocio, genera requisitos y produce código en el que cada requisito se vincula al código de origen; y «pruebas de equivalencia automatizadas» para comprobar la paridad funcional.
- Windows y .NET: actualización de .NET Framework a .NET 8 o superior, migración de SQL Server a motores abiertos, actualización de interfaces (por ejemplo, Web Forms a Blazor o React) y paso de despliegues en IIS a contenedores.
- Código a medida: transformaciones predefinidas (actualizaciones de versión de Java, Python o Node.js, de SDK, de frameworks) y transformaciones propias que se definen en lenguaje natural, se prueban sobre repositorios de muestra y después se aplican a escala.
- Modernización continua: análisis periódico de deuda técnica sobre repositorios en GitHub, GitLab o Bitbucket que termina abriendo pull o merge requests con las correcciones.
La misma página recoge cifras de aceleración («hasta 5 veces más rápido», «hasta un 70 % de reducción de costes operativos») que son afirmaciones del proveedor, con la condición de «hasta». No las trato como un resultado esperable en cualquier proyecto; las trato como un orden de magnitud del techo.
Del lado del desarrollo, la documentación de Kiro (consultada el mismo día) describe un flujo basado en especificaciones: cada especificación genera tres artefactos, requisitos con criterios de aceptación, diseño y plan de tareas. En el IDE hay un botón de revisión que permite comentar pasajes concretos de los documentos y enviarlos juntos al agente. También existe una «especificación rápida» que genera los tres artefactos de una vez, sin puertas de aprobación, pensada para funcionalidades bien entendidas.
3. Lo que no se delega
De ese catálogo se deduce qué queda en manos humanas. No es una lista de tareas «difíciles», sino de decisiones que alguien tiene que firmar.
| Tarea | La IA aporta | Sigue siendo humano |
|---|---|---|
| Entender el sistema | Inventario, dependencias, descripción funcional, borrador de reglas | Validar que las reglas extraídas son las reglas reales y decidir cuáles se conservan |
| Escribir el código nuevo | Primera versión, a menudo correcta en lo mecánico | Revisar el diseño y aceptar o rechazar cada desviación |
| Probar | Generar casos, ejecutar comparativas, buscar contraejemplos | Decidir qué comportamiento es el de referencia y qué diferencia es tolerable |
| Declarar equivalencia | Evidencia (resultados, trazas, informes) | La firma: quién responde si el resultado difiere en producción |
| Cambiar de plataforma | Planes por oleadas, configuración de red, conversión de infraestructura | Calendario, ventanas de corte, aceptación de riesgo por el negocio |
La fila crítica es la cuarta. Una herramienta puede ofrecer pruebas de equivalencia automatizadas y eso es valioso, pero el informe de una herramienta es una evidencia, no una aceptación. Quien contrata la modernización necesita una persona o un comité que lea esa evidencia y asuma la decisión. Si esa persona no existe, la responsabilidad queda en el vacío.
4. Primero se caracteriza, después se transforma
Hay una técnica antigua que cobra sentido con agentes: las pruebas de caracterización. Consisten en registrar lo que el sistema actual hace, no lo que debería hacer, y exigir que el nuevo se comporte igual ante las mismas entradas. Los pasos son los de siempre:
- Congelar un conjunto de entradas representativo, con una semilla fija si se generan, para que la comparativa sea repetible.
- Ejecutar el sistema original y guardar las salidas como referencia, incluidos los resultados «feos» o inesperados.
- Ejecutar el sistema nuevo y comparar campo a campo, con un informe de divergencias clasificado por tipo e impacto.
- Dejar que el agente corrija y vuelva a comparar, pero con la comparativa fuera de su control: el árbitro no puede ser quien escribe el código.
El punto de diseño importante es el cuarto. Un agente al que se permite modificar tanto el código como las pruebas puede cerrar la brecha por el camino equivocado. La referencia tiene que ser independiente del agente y versionada.
Las divergencias que aparecen rara vez son errores obvios. Suelen ser cosas como redondeos, tratamiento de fechas y zonas horarias, orden de ejecución, valores nulos o juegos de caracteres: comportamientos implícitos del sistema viejo que nadie documentó y que el nuevo no reproduce. Sacarlas a la luz es el trabajo de las pruebas; decidir si cada una es un defecto o una diferencia aceptable es el trabajo del negocio.
5. «Equivalente» no es «idéntico»
Exigir igualdad exacta suele ser inviable y a veces indeseable: el sistema viejo puede tener un comportamiento que es, de hecho, un error. Conviene definir desde el principio una categoría explícita de diferencia controlada: una divergencia concreta, descrita, con su alcance acotado y aprobada por quien responde del proceso de negocio. Tres condiciones evitan que se convierta en un cajón de sastre:
- Cada diferencia se aprueba por escrito y por separado, con el impacto estimado.
- El alcance es estricto: la aprobación cubre ese comportamiento en esas condiciones, no una familia de casos.
- Queda trazada en el expediente de la modernización, junto con la evidencia que la sustenta.
Esto conecta con la especificación como contrato. El flujo por especificaciones es útil precisamente porque deja requisitos y criterios de aceptación revisables antes de generar código. Pero hay que ser honesto con sus límites: la propia documentación de Kiro sobre corrección advierte de que las pruebas basadas en propiedades dan «evidencia de corrección, no prueba», que no son verificación formal, que una propiedad demasiado débil puede pasar mientras el comportamiento real sigue siendo erróneo y que no todos los requisitos se traducen limpiamente en una propiedad. Es la lectura correcta de cualquier herramienta de este tipo: reduce el riesgo, no lo elimina.
6. Trade-offs que hay que decidir explícitamente
| Decisión | Beneficio | Coste o riesgo | Criterio |
|---|---|---|---|
| Especificación rápida frente a revisión por fases | Velocidad en cambios bien entendidos | Se saltan las puertas de aprobación | Rápida solo en piezas pequeñas y reversibles; por fases en lógica de negocio |
| Transformación a escala frente a caso a caso | Coste unitario bajo en patrones repetidos | Un error del patrón se replica en cientos de repositorios | Piloto sobre muestra, comparativa y despliegue por oleadas |
| Modernización continua con pull requests | La deuda técnica se reduce de forma constante | Carga de revisión sobre los equipos | Límite de PR abiertas por equipo y revisor con nombre |
| Informe de equivalencia de la herramienta | Evidencia rápida y repetible | Se confunde con la aceptación | Firma humana aparte, con diferencias controladas listadas |
7. Qué hacer el lunes
- Elige una aplicación que no sea crítica pero tenga reglas de negocio reales, y úsala como piloto de método, no de herramienta.
- Construye la referencia antes de transformar: conjunto de entradas congelado, salidas del sistema actual guardadas y un comparador que el agente no pueda modificar.
- Define por escrito qué es una diferencia controlada y quién puede aprobarla. Sin nombre y apellido, no hay proceso.
- Pide a cada herramienta su evidencia, no su veredicto: qué comparó, con qué datos y qué quedó fuera.
- Mide lo que cuesta de verdad: horas de revisión humana por unidad de código modernizada, no solo horas de generación.
Las opiniones expresadas en este artículo son personales.
Fuentes
Páginas consultadas el 3 de noviembre de 2026. Las capacidades, las regiones y las cifras de los productos cambian con frecuencia: conviene revalidarlas antes de tomar decisiones.
- Amazon Web Services. AWS Transform (Launch Guide)
- Kiro. Specs
- Kiro. Correctness (property-based testing)