Selected Work

Ocho sectores, dos paradigmas, frameworks propios.

Cloud y on-prem. Tres con caso completo aquí; los ocho, en Industrias. No un proyecto: un método repetible con activos reutilizables.

Más obra

Profundidad on-demand: el resto de la obra, con su estado honesto. Producto, distribución, meta-tooling e IA agéntica propia.

ProductoMVP en desarrolloPlataforma de marketing autónomoProducto de Stack Overflight, no propio: SaaS de optimización autónoma de campañas para travel — "trading algorítmico aplicado a publicidad". Diseñé la arquitectura de datos, toda la infraestructura y la API en Go; lo sigo construyendo. Es un core Go completo corriendo en AWS Lambda vía Function URL, sin servidor persistente. El núcleo de decisiones es cortex-ai, el motor de enrutamiento agéntico que diseñé para Luna Azul —desplegable como backend en cualquier producto— y que travel-marketing adoptó, no al revés.
Meta-toolingProducciónCore — framework ETL MedallionPlataforma-fábrica Medallion: clases base, registro declarativo y factory de handlers. Añadir un fact = implementar un método. ~90 KLOC de núcleo soportan 185+ módulos de datos operados por equipo y agentes.
Meta-toolingProduccióntf-admin — CLI de infra agent-firstCLI unificada de administración Terraform: 1 entrypoint, ~40 comandos, multi-proyecto. Diseñada agent-first para que un agente de IA opere infraestructura de forma segura, con barandillas humanas en lo destructivo. ~22 KLOC, en solitario.
Meta-toolingProducciónbi-ai-tool — automatización de BIEscribí el cliente que opera Superset y Grafana por API: un core REST genérico compartido —dos backends, un solo cliente base, JWT+CSRF para uno, Bearer para el otro— con aislamiento multi-tenant por proyecto. Cada cambio queda escrito, revisable y reversible. Lo opera el agente Armando.
Meta-toolingProducciónazure-devops — IaC para gestión de proyectoEl mismo patrón de Terraform —spec declarativa, diff detecta deriva, apply reconcilia— aplicado a la gestión de proyecto en sí: sprints, teams, work items, wiki, dashboards de Azure DevOps. Infraestructura como código aplicada a la gestión: el estado deseado vive en archivos versionados y el tablero es el resultado, con los mismos verbos (import, diff, apply --dry-run) que uso para infraestructura real. Lo opera un humano o el agente Yuki.
IP propiaProducciónEcosistema propio — Luna Azul + multi-tenantConglomerado de agentes legales y administrativos en producción real (revisan contratos, no demos), con un meta-agente que los diseña y una plataforma multi-tenant con memoria persistente y multi-canal.
DistribuciónEntregadoData lake departamentalGreenfield on-prem donde no había ninguna infraestructura de datos: ingeniería inversa del ERP, ETL config-driven, ML de predicción de ventas con Prophet y 13 dominios de negocio. Full-stack de datos en solitario.
DistribuciónProducciónOptimización de SQL Server — ERP SiesaUn cuello de botella que parecía de hardware y no lo era. El servidor de una distribuidora sobre el ERP Siesa tenía 64 vCPU y memoria dinámica sin techo, pero la carga real usaba uno solo de sus núcleos. Diagnostiqué con mis agentes Atlas, Charys y Veldora desde la capa física hasta el optimizador de consultas: memoria estática y 16 vCPU, 128 índices fragmentados reconstruidos a 0 en 22 minutos, y el backup rediseñado de 8 copias completas diarias a un esquema por niveles. La intuición culpaba al motor de consulta; un A/B en una copia aislada lo refutó —el optimizador subestimaba la cardinalidad por dos órdenes de magnitud y elegía un plan en serie sin importar cuántos núcleos hubiera—. Migrar a NVMe da 25x en operaciones secuenciales, pero solo 1,4x en la latencia que le duele a facturación: ayuda, no es la bala de plata. Diagnóstico y corrección: ~3 horas.