Decisiones de IA Modelo operativo
Reescribir el legacy o modernizarlo con IA: ¿empezar de cero o descifrar lo que ya tienes?
Reescribe desde cero solo cuando el sistema es pequeño, sus reglas están bien documentadas o el negocio quiere otro proceso de todas formas. Si el valor está en años de reglas que nadie ha puesto por escrito, usa la IA para recuperarlas del código como una especificación que revisan personas y regenera el sistema sobre la arquitectura objetivo, dominio a dominio. La IA acelera la lectura y la escritura; no quita la necesidad de expertos que validen las reglas ni de pruebas que demuestren que el sistema nuevo se comporta como el viejo.
Las opciones
Reescritura completa
Un sistema nuevo, diseñado y construido desde cero a partir de requisitos nuevos, que sustituye al legacy en un corte.
Modernización asistida por IA
La IA lee el código legacy y recupera sus reglas como una especificación que revisan personas y desde la que se genera código nuevo por partes.
Comparativa
| Criterio | Reescritura completa | Modernización asistida por IA |
|---|---|---|
| Punto de partida | Requisitos nuevos recogidos de personas y documentos, que casi nunca reflejan todas las reglas que aplica el sistema viejo. | El comportamiento del sistema en marcha, extraído de su código, sus datos y sus pruebas y convertido en una especificación revisable. |
| Reglas de negocio ocultas | Riesgo alto de perder excepciones y casos límite que solo existen en el código. | Las reglas salen a la luz, y los expertos deciden con intención cuáles se mantienen, cambian o retiran. |
| Forma de entrega | Normalmente, una construcción larga seguida de un corte grande. | Dominio a dominio, con el sistema viejo y el nuevo en paralelo hasta probar cada parte. |
| Tiempo hasta el primer valor | Tarde: poco llega a producción hasta que el sistema nuevo cubre buena parte del viejo. | Antes: la especificación recuperada ya sirve por sí sola, y cada dominio migrado puede salir por separado. |
| Libertad para rediseñar | Total para cambiar procesos, modelo de datos y arquitectura. | Posible, pero con intención: primero cambias la especificación y después regeneras. |
| Verificación | Pruebas de aceptación escritas desde los requisitos nuevos; demostrar la equivalencia con el viejo es difícil. | Pruebas derivadas de la especificación y de casos reales que comparan el comportamiento viejo y el nuevo. |
| Dependencia de expertos escasos | Alta durante la toma de requisitos, y el conocimiento se puede ir con quien lo tiene. | Los expertos revisan y validan en vez de explicarlo todo de memoria, y lo que confirman queda escrito. |
| Riesgo principal | El alcance y el presupuesto crecen mientras el sistema viejo sigue cambiando. | Fiarse de la IA sin revisar: una regla mal extraída con mucha seguridad sigue estando mal. |
Elige Reescritura completa cuando…
- El sistema es pequeño o reciente y sus reglas se conocen y están documentadas.
- El negocio quiere otro proceso, así que reproducir el comportamiento actual aporta poco.
- El código legacy está tan degradado o incompleto que recuperar su comportamiento cuesta más que redefinirlo.
- Hay un producto maduro en el mercado que cubre el proceso y lo que haces es sustituir, no reconstruir.
Elige Modernización asistida por IA cuando…
- El sistema es crítico y guarda años de reglas, excepciones y lógica regulatoria que nadie ha documentado del todo.
- Las personas que lo entienden son pocas, están cerca de irse, o las dos cosas.
- El negocio no puede permitirse una congelación larga ni un único corte grande.
- Necesitas evidencia de qué reglas se mantuvieron, cambiaron o retiraron, para auditoría o para el regulador.
- Quieres migrar dominio a dominio y decidir el orden por valor y riesgo.
Cuándo combinarlas
No se excluyen. Un patrón habitual es recuperar primero la especificación de todo el sistema, porque ese mapa cuesta poco comparado con la reescritura y muestra qué dominios guardan las reglas críticas. Después, los dominios cuyas reglas hay que conservar se regeneran desde la especificación revisada, y los que el negocio quiere cambiar se rediseñan desde requisitos nuevos, con las reglas antiguas encima de la mesa para que nada se pierda por despiste.
Errores típicos
- Tratar la reescritura como un proyecto técnico cuando el activo real es el conocimiento de negocio que hay en el código.
- Pedir a la IA que traduzca el código línea a línea a otro lenguaje; te quedas con el diseño viejo y su deuda con sintaxis nueva.
- Dar por buena una especificación recuperada sin que la revisen quienes conocen el negocio.
- Planificar un único corte en vez de tener el sistema viejo y el nuevo en paralelo y comparar resultados.
- Medir el avance por líneas de código generadas y no por reglas verificadas y dominios en producción.
Cómo lo enfoca Thinkia
Partimos de la tesis de nuestro whitepaper IA Brownfield: el código legacy no se reescribe; se descodifica en specs y se regenera. El spec es el activo. El valor de un sistema legacy es la intención de negocio atrapada dentro de él, y la ingeniería asistida por IA la extrae a una especificación gobernable que revisan personas antes de regenerar el código sobre una arquitectura objetivo.
Trabajamos dominio a dominio, no sistema a sistema. En cada dominio nos preguntamos cómo de legibles son sus reglas y qué pasa si se pierde una, y eso decide el orden y si conviene regenerar lo que existe o rediseñarlo. La recuperación, la regeneración y la verificación siguen la misma disciplina AI-SDLC que aplicamos al software nuevo: specs compartidas, gates y niveles de riesgo. Pulse da soporte a ese trabajo con Golden Specs firmables, trazabilidad AI-BOM y una entrega auditable.
También somos claros con los límites. La IA no sustituye a los expertos que confirman las reglas ni a las pruebas que comparan el comportamiento viejo y el nuevo con casos reales. Cuando el sistema es pequeño, está bien documentado o el negocio quiere otro proceso, una reescritura limpia puede ser la respuesta más sencilla, y lo decimos.
Productos de Thinkia implicados
- PulseAI-SDLC gobernado: especificaciones firmables, trazabilidad AI-BOM y entrega auditable.
- SynapsePlataforma agéntica gobernada: agentes, modelos, costes y datos en un solo sitio.
Soluciones de IA relacionadas
- Modernización legacy con copilotos IAModerniza incremental, gobierna mientras entregas
- Despliegue Enterprise AI-SDLCCopilotos IA a escala, con guardarraíles
- Auditoría de madurez en IAGaps, riesgos y los próximos 90 días sin maquillaje
- Estrategia y hoja de ruta de IADe la ambición a un plan que tus equipos puedan ejecutar
Preguntas frecuentes
¿Qué hace exactamente la modernización asistida por IA con el código legacy?
Lee el código, las estructuras de datos y las pruebas que existan para describir qué hace el sistema: entidades, reglas, cálculos, excepciones e integraciones. Esa descripción se convierte en una especificación que revisan y corrigen personas. El código nuevo se genera desde la especificación aprobada, no se traduce desde el viejo.
¿Es lo mismo que la traducción automática de código?
No. Traducir código de un lenguaje a otro conserva el diseño, la estructura y la deuda del original. Recuperar la especificación separa lo que el sistema debe hacer de cómo se construyó, y así el sistema nuevo puede seguir otra arquitectura.
¿Podemos fiarnos de una especificación extraída por IA?
Solo después de revisarla. Un modelo puede leer mal el código o rellenar huecos con reglas que suenan bien. Trata la especificación extraída como un borrador: los expertos la validan, las reglas dudosas se marcan y las pruebas con casos reales comprueban que el sistema regenerado se comporta como se espera.
¿La modernización con IA evita tener los dos sistemas en paralelo?
No. Tener el viejo y el nuevo funcionando a la vez, o comparar sus resultados con las mismas entradas, sigue siendo la forma más fiable de demostrar la equivalencia. El enfoque incremental lo facilita porque cada dominio es más pequeño.
¿Cuándo sigue teniendo sentido reescribir desde cero?
Cuando el sistema es pequeño, sus reglas se conocen bien, el negocio quiere cambiar el proceso o el código está tan degradado que no merece la pena leerlo. En esos casos reproducir el comportamiento actual aporta poco y reescribir desde requisitos claros puede ser más sencillo.
Para seguir explorando
Decisiones relacionadas
- Piloto de IA vs producción: ¿qué cambia de verdad al escalar?
- Construir o comprar agentes de IA: ¿qué agentes conviene tener en propiedad y cuáles alquilar?
- Arreglar primero los datos o empezar ya con IA: ¿qué va antes?
- Evals automáticas o revisión humana: ¿cómo garantizas la calidad de la IA en la empresa?
Términos clave
- Desarrollo guiado por especificaciones
- Especificación viva
- Especificación ejecutable
- Especificación funcional
- Criterios de aceptación
- AI Bill of Materials
Artículos de Thinkia
- Agentes de IA en los flujos de trabajo de los desarrolladores: el cambio de herramienta a compañero de equipo
- IA para la generación de código: la brecha de rendimiento oculta del 90 %
- Desarrollo de aplicaciones AI-native: guía para la dirección
- Agentes de codificación con IA: el respaldo de Gartner marca una nueva era para el software empresarial
Whitepapers
- El legado no se reescribe. IA Brownfield.Cómo la IA habilita la migración de sistemas legacy sin reescribirlos — el spec como activo, anatomía del reverse engineering y un método en cinco fases.
- Del core a la capa agéntica.¿Modernizar el núcleo o poner agentes encima? Lo que decide no es el sistema, sino la legibilidad de sus reglas. Un marco de cuatro cuadrantes para 2027.
- AI–SDLC. De código a intención.El playbook de Thinkia para entrega de software con IA gobernada: specs compartidas, gates obligatorios, niveles de riesgo y una pasarela de modelos única.