Claude Code y MCP: agentes LLM en tu ciclo de desarrollo

La mayoría de demos de “agentes” que circulan resuelven un caso de juguete y se rompen en cuanto las pones delante de un repositorio real. La diferencia entre un agente que ayuda y uno que estorba no está en el modelo, sino en qué contexto le das, qué herramientas le dejas usar y dónde le pones límites. Esto es lo que he aprendido integrando Claude Code y el Model Context Protocol (MCP) en mi flujo de trabajo diario.

El problema: el contexto es el cuello de botella

Un LLM no “conoce” tu proyecto. En cada petición solo sabe lo que cabe en su ventana de contexto. Un agente útil tiene que decidir, sin que se lo digas, qué ficheros leer, qué comandos ejecutar y cuándo parar. Si le das demasiado, diluyes la señal y aumentas coste y latencia; si le das de menos, alucina rutas y APIs que no existen.

La trampa habitual es pensar que el problema se resuelve con un modelo más grande. No. Se resuelve con ingeniería de contexto: recuperar lo justo, en el momento justo.

Qué resuelve MCP

El Model Context Protocol es un estándar abierto para conectar un LLM con fuentes de datos y herramientas a través de servidores. En lugar de pegar el contenido de tus ficheros en el prompt, expones capacidades: un servidor de sistema de ficheros, uno de base de datos, uno de tu API interna. El modelo descubre esas herramientas y las invoca cuando las necesita.

La ventaja práctica es doble:

• Desacoplas el contexto del prompt. El agente pide lo que necesita en vez de recibirlo todo de golpe.
• Reutilizas la misma integración entre clientes distintos: lo que expone un servidor MCP sirve para Claude Code, para un asistente propio o para un pipeline batch.

Cómo lo uso en la práctica

En mi día a día, Claude Code actúa como el orquestador: lee el repositorio, propone cambios, ejecuta la suite de tests y itera sobre el resultado. El patrón que mejor me funciona tiene tres reglas:

1. Un fichero de instrucciones del proyecto. Convenciones de commits, comandos de build, arquitectura, lo que NO se debe tocar. Es la diferencia entre un agente que respeta tu estilo y uno que reescribe medio repositorio “porque sí”.
2. Herramientas con permisos explícitos. Leer es barato; escribir, ejecutar comandos o tocar la red, no. Conviene que esas acciones pasen por una confirmación, sobre todo al principio.
3. Tareas pequeñas y verificables. Un agente brilla cuando puede comprobar su propio trabajo: tests que pasan, un type-check limpio, un linter sin errores. Sin un criterio objetivo de “hecho”, el agente se queda dando vueltas.

Un agente sin forma de verificar su trabajo no es autónomo: es un generador de texto plausible al que todavía tienes que revisar línea a línea.

Apliqué exactamente esta forma de trabajar construyendo DevFlow AI, una suite de herramientas para desarrolladores donde el desarrollo asistido por IA formó parte del proceso de principio a fin.

Dónde poner los límites

Los agentes fallan de formas predecibles, así que conviene anticiparlas:

• No les des acceso a producción. Un agente que puede desplegar es un agente que puede romper producción a las 3 de la mañana.
• Versiona todo. Si cada cambio del agente es un commit revisable, un error es un git revert, no una crisis.
• Desconfía de la confianza. Un LLM expresa la misma seguridad cuando acierta que cuando inventa una función. La verificación la pones tú, no el modelo.

Qué me llevo

Claude Code y MCP no sustituyen criterio de ingeniería: lo amplifican. El trabajo de fondo —decidir la arquitectura, definir qué es correcto, poner los límites— sigue siendo humano. Lo que cambia es la velocidad a la que iteras sobre tareas mecánicas y bien acotadas.

Si estás integrando agentes LLM en un equipo y quieres evitar los baches que ya me he comido, escríbeme. Es justo el tipo de problema en el que disfruto.