02 — Enfoque

Descomposición asistida por IA y ejecución paralela

Dos etapas encadenadas: primero entendemos, luego coexistimos con el legacy hasta ganar la confianza operativa.

1

1. Análisis y descomposición con IA

Analizamos código, logs y documentación. Un motor con LLMs y análisis estático identifica bounded contexts y propone fronteras de servicios desacoplables. El resultado es documentación viva en 4 niveles (0-3) navegable por negocio y por técnica.

LegacyIABounded contexts
2

2. Coexistencia y validación en paralelo (Shadow Mode)

Un router inteligente duplica las peticiones al nuevo microservicio en modo sombra. Un diff engine compara resultados con el monolito y sincroniza datos por CDC. El nuevo servicio solo asume tráfico real cuando la equivalencia funcional está probada.

ClienteRouterTráfico principalTráfico sombraLegacyMicroservicioDiff
Por qué modularizar el core paga

Objetivos estratégicos

01

Agilidad y Time-to-Market

Ciclos de desarrollo más cortos y despliegues autónomos por servicio.

02

Escalabilidad selectiva

Escalar servicios críticos sin sobredimensionar toda la infraestructura.

03

Mantenibilidad y calidad

Bases de código más pequeñas, comprensibles y testeables de forma aislada.

04

Resiliencia y tolerancia a fallos

El fallo de un servicio no compromete la disponibilidad global del sistema.

05

Innovación tecnológica

Adopción de nuevos stacks y lenguajes en servicios específicos de forma progresiva.

06

Reducción del riesgo operativo

Despliegues pequeños, controlados y reversibles frente al big-bang.

◇ Metodología

Del spaghetti al núcleo funcional dirigido por dominio

No basta con reescribir. Aprovechamos la migración para pasar de un monolito procedural entrelazado a un núcleo funcional puro modelado por dominios (DDD) y anclado con TDD. Cada regla de negocio queda expresada como función pura verificable.

Spaghetti proceduralDDD + TDDNúcleo funcional por dominioFoliosPrimaSiniestrosLiquidaciónReservasReporting✓ TDD · property-based · shadow diff
Legacy procedural→ Núcleo funcional + TDD
01

Dominios como frontera

Bounded contexts derivados del análisis IA: siniestros, folios, liquidación… cada uno con su lenguaje ubicuo y su modelo propio.

02

Núcleo funcional puro

Reglas de negocio como funciones puras, sin efectos secundarios. Los side-effects (BD, IO, colas) viven en los bordes, no dentro de la lógica.

03

TDD sobre la spec formal

Los contratos, invariantes y ejemplos extraídos del legacy se convierten en tests. La suite falla antes de escribir el código nuevo y valida cada refactor.

04

Property-based testing

Además de casos de ejemplo, generamos miles de inputs sintéticos para cazar regresiones que el shadow mode confirmará contra el legacy real.

◇ Ciclo de vida

El agente propone. Las personas y el CI/CD deciden.

Ninguna línea generada por IA llega a producción sin pasar por el mismo control que el código humano: pull request, revisión de otro developer, suite de tests, validación shadow y despliegue progresivo. El agente es un colaborador más del repo, no un canal paralelo.

AgentCodeGen + ReviewMCPGitHub PRrama por bloqueGitHub Actionslint · typesunit · property-basedcontract vs specshadow-diff run✓ green requiredHuman reviewotro developerMergeshadow → canarychanges requested → agent iteradivergencias detectadas → spec + código
STEP 01

1. El agente abre PR

Vía MCP-GitHub, el agente crea una rama por bloque migrado, sube código nuevo, tests generados desde la spec y la documentación de los niveles actualizada.

STEP 02

2. CI ejecuta la suite

GitHub Actions dispara linters, type-check, tests unitarios y property-based, contract tests contra la spec y un run de shadow-diff contra el legacy con tráfico sintético.

STEP 03

3. Revisión humana

Otro developer revisa el PR con contexto: diff de código, cambios en la spec, tabla de equivalencia funcional y enlace al bloque original del legacy. Comenta, pide cambios o aprueba.

STEP 04

4. Merge → shadow real

Al mergear, el nuevo servicio se despliega en shadow: recibe tráfico duplicado en producción sin devolver respuesta. El diff engine compara resultados 24/7 hasta alcanzar el umbral de equivalencia.

STEP 05

5. Cutover progresivo

Cuando la equivalencia supera el SLO (p.ej. 99.9%), un feature flag desvía tráfico real por canary, con rollback automático si aparecen divergencias.

◇ Arquitectura

Agentes especializados sobre stack open-source

La solución no es una caja negra: es una orquestación de agentes con responsabilidades claras, apoyados en herramientas open-source estándar. Cada capa es reemplazable.

FUENTESRepo legacy .4gm / .ec / .hDocumentación negocioEsquemas BD InformixLogs producciónTests históricosINDEXACIÓN & CONOCIMIENTOLlamaIndex RAGtree-sitter · chunksQdrant / pgvectorGrafo ontológicoNeo4j / Oxigraphentidades · sinónimoshomónimos · dominiosSpec storeversionada en GitAGENTES · LangGraphDiscoveryexplora repoDocumentationniveles 0–3Ontologydetecta conflictosSpeccontratos + tiposCodeGencódigo destinoTestpytest · HypothesisReviewresponde PRsShadowdiff engineSALIDA · GitHub / CI-CDMCP · GitHubPR · commits · docsGitHub Actionstest · shadow · deployArgo CD · Flagscanary · rollbackShadow difflegacy ↔ nuevo serviciodivergencias → refinar spec / ontologíaStack open-source · reemplazable capa a capa · el humano gobierna cada merge
Agentes
Discovery Agent

Recorre el repo legacy y descubre funcionalidades, dependencias y datos tocados.

Documentation Agent

Genera la documentación multinivel (0-3) bloque a bloque, decidiendo profundidad.

Ontology Agent

Extrae entidades, sinónimos y homónimos; construye y mantiene el grafo de conocimiento del dominio.

Spec Agent

Convierte los bloques en spec formal ejecutable: tipos, contratos, invariantes.

CodeGen Agent

Genera código en el lenguaje destino guiado por la spec y por el estilo del proyecto.

Test Agent

Deriva tests unitarios, property-based y de contrato desde la spec y los ejemplos del legacy.

Review Agent

Abre PRs, responde comentarios de revisores humanos y ajusta código o spec.

Shadow Agent

Compara respuestas legacy vs. nuevo servicio en tiempo real y reporta divergencias.

Stack open-source
Análisis & AST
tree-sitter · Semgrep · Comby · Joern
Indexación & RAG
LlamaIndex · Haystack · LangChain · Unstructured
Vector store
Qdrant · Chroma · LanceDB · pgvector
Grafo ontológico
Neo4j · Oxigraph · Apache Jena · RDFLib
Orquestación agentes
LangGraph · CrewAI · Autogen · Prefect
Modelos
Llama 3 · Qwen 2.5 Coder · DeepSeek · GPT/Claude vía API
Testing
pytest · Hypothesis · Schemathesis · dbt tests
CI/CD & MCP
GitHub Actions · MCP GitHub · Argo CD · OpenFeature