Todos los posts
IAMCPGGAEngramAI WorkflowsDeveloper Tools

IA en el flujo de trabajo real: MCP Servers, GGA y memoria persistente con Engram

Cómo transformé el workflow de un equipo de desarrollo con MCP Servers personalizados, revisión automática de código con GGA y memoria persistente entre sesiones con Engram. Casos de uso reales, no teoría.

28 de abril de 20267 min de lectura

La promesa del AI en el desarrollo de software lleva años siendo la misma: "vas a programar el doble de rápido". La realidad es más matizada. El AI es tan poderoso como el contexto que le das — y la mayoría de los equipos no le dan ninguno.

Este post no es sobre usar AI. Es sobre integrar AI en la arquitectura de un equipo de forma que escale, sea reproducible y genere valor real más allá del desarrollador individual.

CLAUDE.mdSesiónMCP SERVERScodebaselineardocs✦AI⚔GGApre-commit✓CommitENGRAMmemoria persistente entre sesionesmem_save / mem_search─────────────────── flujo de trabajo ───────────────────
El AI actúa con contexto real — no desde cero cada sesión

El problema que nadie nombra

Cuando un desarrollador usa un asistente de AI por primera vez, la experiencia es mágica. Cuando lo usa el día 30, empieza a notar algo: el AI no recuerda nada.

No sabe cómo está estructurado tu proyecto. No conoce tus convenciones. No sabe que la semana pasada decidisteis migrar de axios a fetch, o que el equipo acordó no usar any bajo ningún concepto. Cada sesión empieza desde cero.

El resultado: el AI genera código que hay que corregir, que no sigue los patrones del proyecto, que viola convenciones establecidas. El time-to-value baja, la frustración sube, y el equipo concluye que "el AI no funciona para nosotros".

El problema no es el AI. Es la falta de contexto estructural persistente.

MCP Servers: el contexto que el AI necesita

El Model Context Protocol (MCP) es el estándar que permite a los modelos de IA conectarse a herramientas, datos y sistemas externos de forma estandarizada. En la práctica: es la forma de darle al AI acceso a tu mundo, no al mundo genérico sobre el que fue entrenado.

Un MCP Server es un proceso que expone herramientas y recursos. El AI puede llamar a esas herramientas como si fueran funciones. Ejemplos de lo que podés construir:

Lo revolucionario no es que el AI haga más cosas. Es que el AI toma mejores decisiones porque conoce tu contexto específico, no un contexto genérico.

Cómo se integra en el equipo

La clave para que los MCP Servers tengan impacto a nivel equipo es centralizarlos. Un servidor MCP que solo vive en la máquina de un desarrollador es una mejora individual. Un servidor MCP versionado en el repo, con configuración en CLAUDE.md o equivalente, es una mejora sistémica.

# CLAUDE.md — instrucciones que el AI lee en cada sesión
## Convenciones del equipo
- Atomic Design: atoms → molecules → organisms → templates
- No any, no as unknown
- Variants de Framer Motion siempre en lib/motion.ts
- Tests con Testing Library, nunca implementación

## MCP Servers disponibles
- mcp-codebase: acceso al árbol de archivos y patrones existentes
- mcp-linear: crear y actualizar issues
- mcp-docs: consultar documentación interna

Esto no es documentación que el humano lee. Es contexto que el AI lee automáticamente antes de cada tarea.

GGA: code review automatizado que conoce tus reglas

GGA (Gentleman Guardian Angel) es un hook de pre-commit que ejecuta una revisión de código con AI antes de cada commit, validando contra las reglas específicas de tu proyecto definidas en AGENTS.md.

La diferencia con un linter clásico: el AI entiende intención, no solo sintaxis. Puede detectar:

# AGENTS.md — reglas que GGA revisa en cada commit

## Arquitectura
- Container/Presentational: los smart components nunca tocan UI directamente
- Sin lógica de negocio en componentes UI
- Las animaciones viven en lib/motion.ts, no inline

## TypeScript
- Strict mode siempre. No any, no as unknown as X
- Preferir type sobre interface salvo extensión

## Lo que GGA debe marcar
- DOM manipulation fuera de hooks
- console.log en producción
- Strings hardcodeadas que deberían ser constantes o i18n
- Componentes con más de 150 líneas
- Excepciones conocidas (documentarlas en AGENTS.md)

El flujo en la práctica: desarrollador hace commit → GGA ejecuta review → si hay violaciones, el commit no pasa y el desarrollador ve exactamente qué y por qué. No hay revisión humana bloqueada esperando; el feedback es inmediato.

El impacto real

En nuestro equipo, GGA redujo el tiempo dedicado a code review en issues de estilo y arquitectura. Los reviewers humanos pueden enfocarse en lógica de negocio, edge cases y decisiones de producto — que es donde el juicio humano es irremplazable.

Más importante: GGA establece un contrato técnico explícito. Cuando alguien nuevo entra al equipo, las reglas no están en la cabeza de nadie — están en AGENTS.md, son ejecutables y verificables automáticamente.

Engram: memoria persistente entre sesiones

El segundo problema de los AI assistants es la amnesia. Cada sesión empieza desde cero. Cada vez que abris una nueva conversación, tenés que re-explicar el contexto, las decisiones tomadas, los bugs resueltos, los patrones acordados.

Engram es un sistema de memoria persistente que sobrevive entre sesiones y compactaciones de contexto. Su modelo es simple pero poderoso:

Tipos de memoria:

mem_save({
  title: "Migración a Zustand completada",
  type: "decision",
  content: `
    What: Migramos de Redux a Zustand en el módulo de auth
    Why: Redux añadía boilerplate sin beneficio real para state local
    Where: src/stores/auth.ts
    Learned: Los selectores memoizados de Redux no tienen equivalente directo — usar useMemo en los consumers
  `
})

En la próxima sesión, el AI puede recuperar esa memoria:

mem_search("zustand auth migration")
→ Devuelve el contexto completo de la decisión

El resultado: el AI actúa como un compañero de equipo que recuerda el proyecto, no como un consultor externo que necesita onboarding cada vez.

El workflow completo

Así se ve integrado:

1. Desarrollador empieza sesión
   → AI lee CLAUDE.md (convenciones, MCPs disponibles)
   → AI recupera memorias relevantes via Engram
   → AI consulta codebase via MCP para entender contexto actual

2. Desarrollador trabaja con el AI
   → AI propone código coherente con los patrones existentes
   → AI recuerda decisiones previas del equipo
   → AI puede crear tickets, actualizar docs via MCPs

3. Desarrollador hace commit
   → GGA revisa contra AGENTS.md
   → Commit bloqueado si hay violaciones
   → Feedback inmediato y accionable

4. Al final de la sesión
   → AI guarda memorias relevantes via Engram
   → Decisiones, bugs, patrones documentados automáticamente

Lo que esto no es

No es magia. No reemplaza el criterio técnico del equipo. No toma decisiones de arquitectura sola.

Es infraestructura de contexto. Le da al AI las condiciones para ser útil de verdad — y eso requiere inversión inicial: definir las reglas en AGENTS.md, construir los MCP Servers relevantes, establecer qué vale la pena guardar en Engram.

La diferencia entre un equipo que "usa AI" y un equipo que la integra de verdad no está en el modelo. Está en el trabajo invisible de estructurar el contexto.

Para empezar

Si querés implementar algo de esto en tu equipo:

  1. Empezá por AGENTS.md — escribe las reglas que tus code reviews mencionan más frecuentemente. Eso es lo que GGA va a revisar.
  2. Identifica los 3 MCPs con más ROI para tu contexto específico. Casi siempre son: documentación interna, codebase navigation, y tu herramienta de gestión de tareas.
  3. Sé consistente con Engram — el valor viene de la acumulación. Una sesión sin guardar memorias no rompe nada; un mes sin guardar memorias es una oportunidad perdida.

El AI es tan bueno como el contexto que le das. Dárselo es trabajo de ingeniería, no de prompting.