Un roadmap de modernización legacy con IA no comienza pidiendo al modelo que «modernice esta aplicación». En escenarios reales, el enfoque efectivo es justo el opuesto: mantener una conversación estructurada, prompt a prompt, para transformar el conocimiento disperso en decisiones técnicas fundamentadas.
Un sistema que lleva diez o quince años en producción acumula muchas más cosas que código.
Por tanto, construir un roadmap de modernización legacy con IA exige comprender primero el sistema actual. Este artículo complementa mi guía sobre cómo modernizar software legacy sin detener el negocio y el análisis de por qué conviene auditar una aplicación aunque todavía funcione.
- Dependencias.
- Decisiones arquitectónicas.
- Reglas de negocio.
- Integraciones.
- Procesos manuales.
- Scripts.
- Jobs.
- Excepciones.
- Deuda técnica.
- Conocimiento que nunca llegó a documentarse.
La pregunta equivocada: «¿Puede una IA reescribir mi aplicación?»
La pregunta útil: «¿Cómo puedo conversar con una IA para entender el sistema, reducir la incertidumbre y decidir qué modernizar primero?»
Ese cambio de enfoque es la base de todo el proceso que vamos a explorar.
Roadmap de modernización legacy con IA: el error del prompt único
Un prompt como este parece la vía rápida:
Analyze this legacy application and tell me how to modernize it.Pero mezcla demasiadas preguntas al mismo tiempo:
- ¿Cómo funciona?
- ¿Dónde está fallando?
- ¿Cuáles son los componentes críticos para el negocio?
- ¿Existe algún riesgo inminente?
- ¿Qué deberíamos cambiar?
- ¿En qué orden?
- ¿Hacia qué arquitectura objetivo?
Sin embargo, el resultado, aunque suene convincente, suele pecar de genérico.
Tal vez recomiende actualizar frameworks, introducir microservicios, aumentar la cobertura de testing, mejorar los pipelines de CI/CD y revisar la infraestructura.
En teoría, todo eso suena razonable.
Pero seguimos sin saber si realmente responde a las necesidades específicas del sistema que tenemos delante.
Por consiguiente, la mejor estrategia es dividir el problema.
flowchart TB
A["Discovery"] --> B["Assessment"]
B --> C["Priorización"]
C --> D["Quick wins"]
D --> E["Roadmap"]
E --> F["Revisión crítica"]
F --> G["Métricas"]
G --> H["Ejecución"]
H --> I["Aprendizaje"]
I --> CNo buscamos un prompt mágico. Diseñamos una conversación técnica.
Cada interacción reduce una parte de la incertidumbre y prepara la siguiente decisión.
Mermaid para documentar la modernización de software legacy
Los documentos en Markdown, basado en texto plano estructurado, son útiles; sin embargo, determinados problemas de ingeniería se entienden mucho mejor visualmente.
Arquitectura. Dependencias. Secuencias. Estados. Roadmaps. Árboles de decisión.
Aquí es donde Mermaid brilla especialmente: permite generar diagramas complejos que siguen siendo texto plano y versionable. Además, su documentación oficial de sintaxis cubre diagramas de flujo, secuencia, estados, arquitectura y otras representaciones útiles para un roadmap de modernización legacy con IA.
Markdown + Mermaid + Git + IA
Documentación técnica viva
Markdown estructura el conocimiento, Mermaid lo representa, Git conserva su evolución y la IA ayuda a analizarlo, contrastarlo y mantenerlo actualizado.
Podemos incorporar esta instrucción común en nuestros prompts:
MERMAID INSTRUCTIONS
Generate Mermaid diagrams whenever a visual representation improves understanding.
Choose the appropriate diagram type:
- flowchart: architecture, dependencies and processes
- sequenceDiagram: runtime interactions and critical flows
- classDiagram: structural and domain relationships
- stateDiagram-v2: lifecycle and state transitions
- erDiagram: data relationships
- timeline: roadmap phases
- gantt: execution plans
- mindmap: discovery and risk summaries
- quadrantChart: prioritization matrices
Rules:
- Use repository evidence as the source of truth.
- Do not invent components or relationships.
- Clearly distinguish confirmed facts from inferences.
- Keep diagrams readable.
- Prefer several small diagrams over one giant diagram.
- Explain what every diagram demonstrates.
- Return valid Mermaid syntax.Prompt 1. Consolidar el conocimiento para el roadmap de modernización legacy con IA
Supongamos que ya hemos utilizado la IA para analizar diferentes aspectos del proyecto durante una fase de descubrimiento.
TECHNICAL_INVENTORY.md
DOMAIN_MAP.md
ARCHITECTURE.md
CRITICAL_FLOWS.md
HOTSPOTS.md
TECHNICAL_DEBT.md
DEPENDENCIES.md
TESTING_ASSESSMENT.md
SECURITY_REVIEW.mdObjetivo de esta fase: consolidar la información disponible y construir una imagen fiable del sistema actual.
Todavía no buscamos: soluciones, arquitectura objetivo ni iniciativas de modernización.
You are acting as a senior software architect responsible for consolidating an existing technical discovery.
Analyze:
- TECHNICAL_INVENTORY.md
- DOMAIN_MAP.md
- ARCHITECTURE.md
- CRITICAL_FLOWS.md
- HOTSPOTS.md
- TECHNICAL_DEBT.md
- DEPENDENCIES.md
- TESTING_ASSESSMENT.md
- SECURITY_REVIEW.md
Create CURRENT_STATE_ASSESSMENT.md.
Identify:
- Business-critical components
- Technical hotspots
- Unsupported dependencies
- Security risks
- Testing gaps
- Operational risks
- Architectural bottlenecks
- Single points of failure
- High-change components
- Excessive coupling
For each finding include:
- Evidence
- Affected component
- Business impact
- Technical impact
- Probability
- Severity
Do not propose modernization actions yet.
MERMAID OUTPUT
Generate:
1. A flowchart showing the current high-level architecture.
2. A dependency diagram.
3. A mindmap summarizing the main risk areas.
Only represent relationships supported by evidence.
Clearly mark inferred relationships.
Generate CURRENT_STATE_ASSESSMENT.md.La última instrucción sigue siendo fundamental:
Do not propose modernization actions yet.
Entender → Contrastar → Decidir
La modernización comienza reduciendo incertidumbre, no eligiendo tecnología.
Una posible representación resultante sería la siguiente:
graph LR
USER["Usuario"]
WEB["Aplicación web"]
APP["Aplicación principal"]
DB["Base de datos"]
CACHE["Caché"]
QUEUE["Cola"]
WORKER["Workers"]
EXT["Servicios externos"]
USER --> WEB
WEB --> APP
APP --> DB
APP --> CACHE
APP --> QUEUE
QUEUE --> WORKER
APP --> EXTEl diagrama cumple una doble función: obliga al modelo a explicitar sus suposiciones sobre la topología del sistema.
Si el diagrama no tiene sentido, probablemente su comprensión del sistema sea todavía deficiente.
Prompt 2. Convertir hallazgos en prioridades
Dentro de un roadmap de modernización legacy con IA, un inventario de problemas todavía no conforma una estrategia ejecutable.
Por eso, la clave está en priorizar con criterios explícitos de impacto, fragilidad, riesgo y capacidad de cambio.
No toda deuda técnica tiene el mismo impacto ni merece resolverse al mismo tiempo.
Using CURRENT_STATE_ASSESSMENT.md, create MODERNIZATION_PRIORITY_MATRIX.md.
Evaluate each major component according to:
- Business criticality
- Technical fragility
- Frequency of change
- Existing test coverage
- Security exposure
- Operational complexity
- Dependency risk
Classify each component as:
Critical
High
Medium
Low
For each classification explain:
- Evidence
- Main risk
- Why this priority is justified
MERMAID OUTPUT
Create a quadrantChart.
X axis:
Low technical fragility → High technical fragility
Y axis:
Low business impact → High business impact
Do not invent false numerical precision.
Explain why each high-priority component occupies its position.
Generate MODERNIZATION_PRIORITY_MATRIX.md.El resultado puede combinar una tabla con una representación visual como esta:
| Componente | Impacto | Fragilidad | Cambio | Tests | Prioridad |
|---|---|---|---|---|---|
| Facturación | Crítico | Alta | Alta | Baja | Crítica |
| Autenticación | Crítico | Media | Media | Alta | Alta |
| Reporting histórico | Media | Alta | Baja | Baja | Media |
| Exportación | Baja | Media | Baja | Nula | Baja |
graph LR
Q1["Alto impacto · alta fragilidad: Facturación"]
Q2["Alto impacto · fragilidad media: Autenticación"]
Q3["Impacto medio · alta fragilidad: Reporting"]
Q4["Bajo impacto · fragilidad media: Exportación"]
Q4 --> Q3
Q3 --> Q2
Q2 --> Q1No debemos interpretar esas coordenadas como una fórmula matemática precisa.
Su utilidad principal radica en obligarnos a comparar componentes utilizando criterios explícitos.
Prompt 3. Buscar quick wins para la modernización legacy
A continuación, con el mapa de riesgos sobre la mesa, emerge otra pregunta fundamental:
¿Qué podemos mejorar ahora mismo para reducir el riesgo sin realizar cambios profundos en la lógica crítica?
Based on:
- CURRENT_STATE_ASSESSMENT.md
- MODERNIZATION_PRIORITY_MATRIX.md
identify the highest-impact quick wins that can be implemented in the next 2-4 weeks.
The goal is to reduce technical and operational risk without modifying critical business logic.
Prioritize initiatives using:
Impact / Effort
For each quick win include:
- Problem
- Proposed action
- Expected impact
- Effort
- Dependencies
- Risks
- Capability enabled
- Success metric
MERMAID OUTPUT
Generate a flowchart using:
Current problem
→ Quick win
→ Immediate benefit
→ Future capability enabled
Generate QUICK_WINS_PLAN.md.El output visual arrojará algo como esto:
graph LR
LOGS["Logging insuficiente"]
OBS["Logging estructurado"]
VIS["Mayor observabilidad"]
DIAG["Diagnóstico más rápido"]
MANUAL["Despliegue manual"]
CICD["Pipeline CI/CD"]
SAFE["Despliegue repetible"]
FREQ["Mayor frecuencia"]
NOTEST["Flujos críticos sin protección"]
SMOKE["Smoke tests"]
DETECT["Detección temprana"]
CHANGE["Mayor confianza para cambiar"]
LOGS --> OBS
OBS --> VIS
VIS --> DIAG
MANUAL --> CICD
CICD --> SAFE
SAFE --> FREQ
NOTEST --> SMOKE
SMOKE --> DETECT
DETECT --> CHANGEAsí, el gran valor del diagrama consiste en visibilizar que una pequeña acción táctica puede habilitar cambios mucho más ambiciosos en fases posteriores.
Prompt 4. Desacoplar el sistema legacy de forma progresiva
Una estrategia incremental suele requerir la extracción paulatina de ciertas capacidades del sistema heredado.
Pero esto no equivale al clásico:
«¡Convirtamos todo en microservicios!»
En cambio, se trata de identificar fronteras lógicas y razonables. El enfoque encaja con el patrón Strangler Fig descrito por Martin Fowler: sustituir capacidades de forma gradual, mantener el sistema operativo y reducir el riesgo frente a una reescritura Big Bang.
Analyze:
- ARCHITECTURE.md
- DEPENDENCIES.md
- CRITICAL_FLOWS.md
- MODERNIZATION_PRIORITY_MATRIX.md
Identify modules that are reasonable candidates for gradual extraction using the Strangler Pattern.
For each candidate analyze:
- Business capability
- Coupling
- Change frequency
- Technical complexity
- Data ownership
- Integration points
- Migration risk
- Recommended first step
Do not assume that every module should become a microservice.
Generate STRANGLER_CANDIDATES.md.
MERMAID OUTPUT
Generate two diagrams:
1. CURRENT STATE
2. TRANSITION STATE
Clearly distinguish:
- Legacy components
- New components
- Routing layer
- Shared dependencies
Do not invent a final target architecture.Por ejemplo:
graph LR
USER["Usuarios"]
ENTRY["Capa de entrada"]
CORE["Legacy · Core"]
BILL["Legacy · Facturación"]
REPORT["Legacy · Reporting"]
NOTIF_OLD["Legacy · Notificaciones"]
NOTIF_NEW["Nueva capacidad de notificaciones"]
USER --> ENTRY
ENTRY --> CORE
ENTRY --> NOTIF_NEW
CORE --> BILL
CORE --> REPORT
CORE --> NOTIF_OLD
CORE -. transición .-> NOTIF_NEWNo buscamos que la IA nos prescriba microservicios. Buscamos que dibuje fronteras.
Prompt 5. Generar el roadmap de modernización legacy con IA
Ahora sí: el discovery, la priorización y los quick wins ya ofrecen suficiente evidencia para estructurar el plan.
Tras entender, clasificar y priorizar, estamos en posición de pedir a la IA que estructure el roadmap.
You are acting as a senior software architect responsible for defining an incremental modernization strategy.
Use:
- CURRENT_STATE_ASSESSMENT.md
- MODERNIZATION_PRIORITY_MATRIX.md
- QUICK_WINS_PLAN.md
- ARCHITECTURE.md
- TECHNICAL_DEBT.md
- HOTSPOTS.md
- DEPENDENCIES.md
- TESTING_ASSESSMENT.md
- SECURITY_REVIEW.md
- STRANGLER_CANDIDATES.md
Create MODERNIZATION_ROADMAP.md.
Organize initiatives into:
0-30 days
31-90 days
3-6 months
6-12 months
For every initiative include:
- Problem
- Evidence
- Proposed action
- Expected outcome
- Dependencies
- Complexity
- Implementation risk
- Rollback strategy
- Success metric
Prefer incremental modernization.
Avoid recommending a full rewrite unless strongly justified.
MERMAID OUTPUT
Generate:
1. A timeline showing the four horizons.
2. A dependency flowchart between major initiatives.graph LR
P0["0-30 días · observar, proteger y documentar"]
P1["31-90 días · CI/CD, integración y automatización"]
P2["3-6 meses · modularizar y reducir acoplamiento"]
P3["6-12 meses · extraer capacidades y evolucionar infraestructura"]
P0 --> P1
P1 --> P2
P2 --> P3Un roadmap no es solo un calendario. También debe explicar qué iniciativa habilita a la siguiente, qué dependencias condicionan cada fase y qué capacidades deben existir antes de asumir cambios de mayor riesgo.
graph LR
OBS["Observabilidad"]
TEST["Tests críticos"]
CICD["CI/CD"]
SAFE["Capacidad de cambio segura"]
MOD["Modularización"]
DECOUPLE["Desacoplamiento"]
EXTRACT["Extracción progresiva"]
OBS --> SAFE
TEST --> SAFE
CICD --> SAFE
SAFE --> MOD
MOD --> DECOUPLE
DECOUPLE --> EXTRACT
Prompt 6. Pedir a la IA que critique su propia propuesta
Primero construir. Después cuestionar.
Invertir el rol de la IA obliga a revisar supuestos, complejidad, prioridades, alternativas y capacidad de rollback.
Act as a skeptical CTO with extensive experience in legacy software modernization.
Review MODERNIZATION_ROADMAP.md critically.
Challenge:
- Assumptions
- Complexity
- Business value
- Dependencies
- Reversibility
- Team capacity
- Implementation risk
For each initiative ask:
- Is this really necessary?
- What happens if we do nothing?
- Can it be simplified?
- Is there a simpler alternative?
- What dependencies have we overlooked?
- What could fail?
- Is rollback possible?
Classify:
Keep
Simplify
Postpone
Remove
Generate ROADMAP_REVIEW.md.
MERMAID OUTPUT
Create a decision tree for evaluating modernization initiatives.graph TD
A["Nueva iniciativa"]
B{"¿Resuelve un problema real?"}
C{"¿Reduce riesgo o aporta valor?"}
D{"¿Existe una opción más sencilla?"}
E{"¿Conocemos las dependencias?"}
F{"¿Es reversible?"}
G{"¿Tenemos capacidad?"}
EXEC["Ejecutar"]
SIMPLE["Simplificar"]
WAIT["Posponer"]
STOP["Descartar"]
A --> B
B -- No --> STOP
B -- Sí --> C
C -- No --> STOP
C -- Sí --> D
D -- Sí --> SIMPLE
D -- No --> E
E -- No --> WAIT
E -- Sí --> F
F -- No --> SIMPLE
F -- Sí --> G
G -- No --> WAIT
G -- Sí --> EXECUn buen roadmap debe poder sobrevivir a una revisión técnica hostil.
Prompt 7. Métricas para medir la modernización del software legacy
Un proceso de modernización puede generar mucho ruido y pocos resultados tangibles. Por ello, el roadmap de modernización legacy con IA debe incluir métricas desde el principio.
Migrar a una tecnología más moderna no es sinónimo automático de éxito. Como referencia, las métricas de rendimiento de entrega de DORA ayudan a observar velocidad, estabilidad y recuperación sin reducir el análisis a la cantidad de librerías actualizadas.
La pregunta clave es otra:
¿Es ahora el sistema más fácil y menos arriesgado de modificar?
Based on:
- MODERNIZATION_ROADMAP.md
- ROADMAP_REVIEW.md
define the key metrics required to measure modernization progress and impact.
Include:
- Technical metrics
- Delivery metrics
- Reliability metrics
- Business metrics
- Team metrics
For each metric define:
- What it measures
- Why it matters
- How to collect it
- Baseline
- Target
- Success threshold
- Measurement frequency
Include leading and lagging indicators.
Generate METRICS.md.
MERMAID OUTPUT
Generate a flowchart showing how engineering improvements are expected to produce operational and business outcomes.
Treat causal relationships as hypotheses that must be validated with real data.graph LR
TEST["Más protección automatizada"]
SAFE["Cambios más seguros"]
FAIL["Menos regresiones"]
DEPLOY["Mayor frecuencia de despliegue"]
MTTR["Menor tiempo de recuperación"]
VALUE["Mayor capacidad de entregar valor"]
TEST --> SAFE
SAFE --> FAIL
SAFE --> DEPLOY
FAIL --> MTTR
DEPLOY --> VALUE
MTTR --> VALUEY acompañaremos esto de métricas como:
- Deployment Frequency.
- Lead Time for Changes.
- Change Failure Rate.
- Mean Time to Recovery.
- Incidencias críticas.
- Dependencias fuera de soporte.
- Cobertura de flujos críticos.
- Pasos manuales de despliegue.
- Tiempo necesario para modificar módulos de alto riesgo.
El roadmap de modernización legacy con IA emerge de la conversación
Si analizamos todo el proceso en su conjunto, emerge un patrón evidente.
graph LR
P["Prompt"]
R["Respuesta estructurada"]
A["Artefacto Markdown"]
V["Validación humana"]
REF["Refinamiento"]
D["Nueva decisión"]
P --> R
R --> A
A --> V
V --> REF
REF --> P
V --> DNo es una conversación casual: cada respuesta genera un artefacto técnico que aporta contexto verificable a la siguiente interacción.
CURRENT_STATE_ASSESSMENT.md: consolida el estado actual.MODERNIZATION_PRIORITY_MATRIX.md: ordena riesgos y componentes.QUICK_WINS_PLAN.md: identifica mejoras de bajo riesgo.STRANGLER_CANDIDATES.md: localiza fronteras de extracción progresiva.MODERNIZATION_ROADMAP.md: organiza iniciativas y dependencias.ROADMAP_REVIEW.md: cuestiona la propuesta inicial.METRICS.md: define cómo medir el progreso real.
Prompt 8. Convertir el roadmap en un plan ejecutable
Un roadmap sigue siendo una visión a 30.000 pies de altura.
Para aterrizarlo y poder ejecutarlo, necesitamos concretar responsabilidades, dependencias, hitos y criterios de éxito a nivel de equipo.
Create IMPLEMENTATION_PLAN.md based on:
- MODERNIZATION_ROADMAP.md
- ROADMAP_REVIEW.md
- METRICS.md
For every modernization phase define:
- Key objectives
- Prioritized actions
- Required resources
- Dependencies
- Responsible roles
- Milestones
- Success metrics
- Main risks
- Mitigation strategy
- Rollback considerations
MERMAID OUTPUT
Generate a Gantt diagram.
Requirements:
- Represent roadmap-level initiatives.
- Show dependencies using "after" whenever possible.
- Avoid excessive task detail.
- Clearly state when dates are illustrative.
Generate IMPLEMENTATION_PLAN.md.La IA convertirá ahora la abstracción del roadmap en una estructura como esta:
gantt
title Plan de ejecución de modernización
dateFormat YYYY-MM-DD
section Estabilizar
Observabilidad :a1, 2026-09-01, 14d
Smoke tests :a2, after a1, 14d
section Crear capacidad
CI/CD :b1, after a1, 30d
Tests de integración :b2, after a2, 30d
section Desacoplar
Modularización :c1, after b2, 60d
section Evolucionar
Extracción progresiva :d1, after c1, 90dNaturalmente, las fechas deben considerarse referencias temporales orientativas hasta contrastarlas con la capacidad real de entrega del equipo de ingeniería.
Prompt 9. Detectar anti-patrones de modernización legacy
Aquí podemos introducir otra potente capa de revisión.
Consiste en preguntar explícitamente a la IA qué errores son los más habituales en contextos idénticos al nuestro.
Identify common anti-patterns in legacy modernization programs.
Use our modernization strategy as context.
For each anti-pattern include:
- Why it happens
- Warning signs
- Potential impact
- How to prevent it
- Recovery strategy
Pay special attention to:
- Big-bang rewrites
- Premature microservices
- Technology-driven modernization
- Excessive parallel change
- Lack of automated testing
- Missing observability
- Missing rollback strategies
- Obsolete documentation
- Poor stakeholder alignment
Generate MODERNIZATION_ANTI_PATTERNS.md.
MERMAID OUTPUT
Create a mindmap grouped into:
- Architecture
- Delivery
- Quality
- Operations
- Organizationgraph TD
ROOT["Riesgos de modernización"]
ARQ["Arquitectura"]
DELIVERY["Delivery"]
QUALITY["Calidad"]
OPS["Operaciones"]
ORG["Organización"]
BIG["Big Bang"]
MICRO["Microservicios prematuros"]
OVER["Sobreingeniería"]
PARALLEL["Cambios simultáneos"]
ROLLBACK["Sin rollback"]
TESTS["Sin tests"]
DEBT["Deuda invisible"]
OBS["Sin observabilidad"]
MANUAL["Procesos manuales"]
ALIGN["Falta de alineación"]
CAP["Capacidad insuficiente"]
ROOT --> ARQ
ROOT --> DELIVERY
ROOT --> QUALITY
ROOT --> OPS
ROOT --> ORG
ARQ --> BIG
ARQ --> MICRO
ARQ --> OVER
DELIVERY --> PARALLEL
DELIVERY --> ROLLBACK
QUALITY --> TESTS
QUALITY --> DEBT
OPS --> OBS
OPS --> MANUAL
ORG --> ALIGN
ORG --> CAP
Prompt 10. Utilizar un checklist antes de lanzar prompts estratégicos
Cuanto mayor impacto estratégico tenga la decisión que estamos perfilando, más importante resulta acotar la ambigüedad en nuestro prompt.
- ¿El objetivo final está definido con claridad?
- ¿He aportado suficiente contexto?
- ¿Quedan delimitadas las restricciones técnicas y de negocio?
- ¿Están separados los hechos probados de las inferencias?
- ¿He especificado exactamente el tipo de entregable?
- ¿Le he indicado en qué formato lo necesito?
- ¿He establecido los criterios de éxito?
graph TD
A["Prompt estratégico"]
B{"¿Objetivo claro?"}
C{"¿Contexto suficiente?"}
D{"¿Restricciones explícitas?"}
E{"¿Entregable definido?"}
F{"¿Formato definido?"}
G{"¿Criterios de calidad?"}
H["Enviar prompt"]
R["Revisar"]
A --> B
B -- No --> R
B -- Sí --> C
C -- No --> R
C -- Sí --> D
D -- No --> R
D -- Sí --> E
E -- No --> R
E -- Sí --> F
F -- No --> R
F -- Sí --> G
G -- No --> R
G -- Sí --> H
Prompt 11. Utilizar la IA como analista de riesgos
Antes de tocar una iniciativa core, cambiamos la pregunta. En lugar de pedir la solución, pedimos que se identifiquen los fallos posibles, sus desencadenantes, su impacto y las acciones de contingencia.
Act as a technical risk assessment advisor.
Evaluate the proposed modernization initiative.
Identify:
- Technical risks
- Operational risks
- Security risks
- Data risks
- Dependency risks
- Delivery risks
- Team capacity risks
For each risk include:
- Description
- Probability
- Impact
- Risk level
- Trigger
- Mitigation
- Early warning indicator
- Contingency action
Generate RISK_REGISTER.md.
MERMAID OUTPUT
Generate a flowchart showing causal relationships between the most important risks.
Do not present speculative relationships as confirmed facts.graph TD
CAP["Capacidad limitada"]
DELAY["Retrasos"]
RUSH["Cambios apresurados"]
INCIDENT["Más incidentes"]
LOAD["Mayor carga operativa"]
DEBT["Más deuda técnica"]
CAP --> DELAY
DELAY --> RUSH
RUSH --> INCIDENT
INCIDENT --> LOAD
LOAD --> CAP
RUSH --> DEBT
DEBT --> DELAYLos riesgos rara vez emergen de forma aislada.
Casi siempre configuran bucles que se retroalimentan y pueden bloquear por completo el progreso de un equipo.
Prompt 12. Iterar sobre la respuesta en lugar de conformarse con la primera
La principal diferencia entre utilizar la IA como un simple motor de búsqueda y utilizarla como una verdadera herramienta de ingeniería es, precisamente, la iteración.
Rara vez la primera propuesta es la definitiva.
graph TD
START["Inicio"]
P1["Prompt inicial"]
R1["Respuesta V1"]
EVAL{"Evaluar respuesta"}
REFINE["Refinar con más datos"]
COMPARE["Comparar alternativas"]
VALIDATE["Validar con evidencia"]
R2["Respuesta V2"]
FINAL["Resultado final"]
START --> P1
P1 --> R1
R1 --> EVAL
EVAL -- Faltan datos --> REFINE
EVAL -- Hay alternativas --> COMPARE
EVAL -- Es adecuada --> VALIDATE
REFINE --> R2
R2 --> EVAL
COMPARE --> REFINE
VALIDATE --> FINALTras una respuesta, podemos afinar el tiro con instrucciones muchísimo más granulares:
Make the proposal more conservative.
Reduce implementation complexity.
Assume the team cannot stop feature development.
Identify what can be postponed.
Give me three alternative approaches.
Challenge your previous assumptions.
Show me the trade-offs.
Reduce the plan to the highest-value initiatives.
What information are you missing before making this recommendation?Ya no somos meros receptores de una respuesta; somos arquitectos que moldean y construyen junto al modelo.
Prompt 13. Crear una plantilla reutilizable para el equipo
Al dominar esta dinámica iterativa, conviene destilar los aprendizajes en un framework o plantilla compartida para estandarizar el proceso dentro del equipo de ingeniería.
# ROLE
Act as [ROLE] with expertise in [DOMAIN].
# CONTEXT
We are working on [SYSTEM / PROJECT].
Current situation:
[CURRENT STATE]
Constraints:
[TECHNICAL / BUSINESS / TIME / TEAM CONSTRAINTS]
# OBJECTIVE
Help me achieve:
[SPECIFIC OBJECTIVE]
# TASKS
1. [TASK]
2. [TASK]
3. [TASK]
# INPUTS
Use:
[FILES / DOCUMENTS / CODE / DATA]
# OUTPUT
Generate:
[EXPECTED DELIVERABLE]
Use:
[MARKDOWN / TABLE / MERMAID / JSON / OTHER]
# QUALITY CRITERIA
The result must be:
- Evidence-based
- Incremental
- Actionable
- Risk-aware
- Explicit about assumptions
# MERMAID
Whenever visual representation improves understanding:
- Select the appropriate Mermaid diagram.
- Use only relationships supported by evidence.
- Prefer small diagrams.
- Explain the purpose of each diagram.
- Mark inferred relationships.
# VALIDATION
Clearly distinguish:
- Confirmed facts
- Inferences
- Unknowns requiring human validation
Before answering, identify critical missing information.graph LR
ROLE["Rol"]
CONTEXT["Contexto"]
OBJ["Objetivo"]
TASKS["Tareas"]
INPUTS["Entradas"]
OUTPUT["Entregable"]
QUALITY["Calidad"]
VISUAL["Mermaid"]
VALID["Validación"]
ROLE --> CONTEXT
CONTEXT --> OBJ
OBJ --> TASKS
TASKS --> INPUTS
INPUTS --> OUTPUT
OUTPUT --> QUALITY
QUALITY --> VISUAL
VISUAL --> VALID
El repositorio como memoria del proceso de modernización
Trabajar con esta cadencia genera un efecto colateral de un valor incalculable para cualquier organización.
Cada conversación genera documentación rica que podemos —y debemos— consolidar en nuestro repositorio junto al código base.
/docs
TECHNICAL_INVENTORY.md
ARCHITECTURE.md
CURRENT_STATE_ASSESSMENT.md
MODERNIZATION_PRIORITY_MATRIX.md
QUICK_WINS_PLAN.md
STRANGLER_CANDIDATES.md
MODERNIZATION_ROADMAP.md
ROADMAP_REVIEW.md
METRICS.md
IMPLEMENTATION_PLAN.md
MODERNIZATION_ANTI_PATTERNS.md
RISK_REGISTER.mdAl estar basados en texto plano y Markdown, integramos de forma natural tablas de decisión y diagramas Mermaid autogenerados.
graph LR
CODE["Código"]
DOCS["Documentación"]
DIAGRAMS["Mermaid"]
DECISIONS["Decisiones"]
PROMPTS["Prompts"]
CONTEXT["Contexto técnico"]
AI["IA"]
ANALYSIS["Nuevo análisis"]
CODE --> CONTEXT
DOCS --> CONTEXT
DIAGRAMS --> CONTEXT
DECISIONS --> CONTEXT
PROMPTS --> CONTEXT
CONTEXT --> AI
AI --> ANALYSIS
ANALYSIS --> DOCSBajo este paradigma, los documentos dejan de ser simples repositorios estáticos para humanos. Además, el roadmap de modernización legacy con IA queda conectado con las evidencias, decisiones y validaciones que justifican cada etapa.
Se convierten en vectores de contexto preprocesado, listos para realimentar futuras conversaciones con modelos de IA.
La IA propone, la ingeniería decide
Debemos tener algo claro: ninguno de estos prompts convierte, por arte de magia, la sugerencia de una LLM en una decisión estratégica infalible.
Un modelo puede leer todo tu repositorio en segundos.
Puede cruzar variables, identificar acoplamientos, detectar vulnerabilidades latentes y trazarte alternativas de rediseño maravillosas.
Pero siempre será ciego frente a componentes contextuales que, para la ingeniería real, son críticos:
- La realidad presupuestaria.
- Los compromisos comerciales inminentes.
- El nivel de madurez o el estrés actual del equipo.
- Cómo evoluciona el roadmap de producto a corto plazo.
- Por qué ciertas decisiones se tomaron de una forma concreta.
- La burocracia y estructura de la propia organización.
La IA amplía el análisis. La ingeniería conserva la decisión.
El modelo puede acelerar la lectura, el contraste y la generación de alternativas, pero no conoce por completo el contexto organizativo, comercial y humano.
El valor de no buscar el «prompt perfecto»
Existe una tendencia habitual cuando empezamos a experimentar con herramientas de inteligencia artificial generativa.
Perseguimos la ilusión del «prompt mágico».
Esa mega-instrucción que resuelva de un plumazo todo nuestro embrollo arquitectónico al primer intento.
Cuando nos enfrentamos a sistemas legacy, la estrategia más sólida es radicalmente distinta.
El secreto no reside en diseñar el prompt perfecto, sino en orquestar una excelente conversación.
Una conversación técnica fluida en la que:
- inyectamos capas progresivas de contexto;
- exigimos análisis focalizados;
- obligamos a la herramienta a generar representaciones visuales;
- deslindamos sistemáticamente evidencias empíricas de inferencias probables;
- cuestionamos de frente las recomendaciones;
- reducimos el radio de impacto de las soluciones propuestas;
- desafiamos al modelo para que aporte caminos alternativos;
- y blindamos las decisiones con métricas de validación.
graph LR
UNDERSTAND["Entender"]
VISUALIZE["Visualizar"]
QUESTION["Cuestionar"]
PRIORITIZE["Priorizar"]
PLAN["Planificar"]
EXECUTE["Ejecutar"]
MEASURE["Medir"]
LEARN["Aprender"]
UNDERSTAND --> VISUALIZE
VISUALIZE --> QUESTION
QUESTION --> PRIORITIZE
PRIORITIZE --> PLAN
PLAN --> EXECUTE
EXECUTE --> MEASURE
MEASURE --> LEARN
LEARN --> UNDERSTANDLa verdadera misión de la IA frente al software legacy
En definitiva, el valor de un roadmap de modernización legacy con IA no está en observar cómo el modelo genera líneas de código nuevo, sino en comprimir los tiempos de descubrimiento, contraste y análisis.
El verdadero poder consiste en utilizar la IA como un embudo que convierte información difusa y caótica en decisiones ejecutables y trazables.
Y en este marco, Mermaid aporta una capa de pragmatismo espectacular.
Fuerza a la inteligencia artificial —y a nosotros mismos— a mapear la abstracción en bloques, dependencias, ciclos de vida y fronteras auditables.
Modernizar software legacy no empieza reescribiendo. Empieza comprendiendo.
Solo cuando conocemos las dependencias, los riesgos, los flujos críticos y las restricciones podemos decidir dónde intervenir de forma objetiva, incremental y segura.
Lecturas relacionadas sobre arquitectura y modernización
- Cómo modernizar software legacy sin detener el negocio.
- Tu aplicación funciona: por qué deberías revisarla igualmente.
- Más artículos de arquitectura de software.
¿Tienes un sistema legacy y no sabes por dónde empezar?
Antes de fantasear con una reescritura épica, la adopción del framework de moda o la implantación de una microarquitectura, el paso cero es reconstruir el contexto.
Analiza el código base. Extrae la topología del sistema. Genera los mapas de arquitectura. Identifica los puntos de fricción. Prioriza sin piedad. Pregunta a la IA. Cuestiona duramente sus respuestas. Y utiliza cada ciclo para iluminar zonas de sombra.
La mejor estrategia de modernización jamás arranca preguntándole a un LLM «qué stack debo usar». Arranca exigiéndole respuestas y evidencias sobre el sistema que ya soportas en producción, forzándole a justificar todo aquello que dice haber comprendido.
Deja una respuesta