En esta guía, paso a paso:
Mirar Claude Code trabajar no es productividad. Es entretenimiento. Si pasas 3 horas "trabajando con Claude Code" pero en realidad esas 3 horas las ocupas viendo cómo escribe código, revisando cada cambio en tiempo real, y esperando el siguiente output — has estado ocupado, no has producido. El tiempo de Claude no es tu tiempo. Puedes recuperarlo.
El primer cambio es en el CLAUDE.md. Necesitas que Claude sepa cómo completar una tarea sin pedirte confirmación en cada paso. Añade esta sección:
## Modo de trabajo autónomo Cuando recibas una tarea de implementación con contexto suficiente: 1. Confirma el alcance en 1-2 líneas antes de empezar 2. Implementa sin interrumpir con preguntas intermedias 3. Al terminar, resume en este formato: COMPLETADO: [qué hiciste] ARCHIVOS: [qué modificaste] PENDIENTE: [qué falta o ninguno] Solo interrumpe si vas a modificar configuración, base de datos o infraestructura.
Con esto en el CLAUDE.md, puedes lanzar una tarea y cerrar la ventana. Claude completa, reporta, y para. Tú revisas cuando quieres, no cuando Claude termina cada línea.
Para que Claude pueda trabajar completamente en paralelo — hacer commits, leer archivos, actualizar documentación — necesitas los MCPs correctos configurados en settings.json...
Un arquitecto define el sistema, establece los contratos, verifica los resultados. No escribe cada línea — decide qué se construye, cómo encaja, y qué standards debe cumplir. Con Claude Code, tu trabajo es exactamente ese: definir el qué y el cómo a alto nivel, dejar que Claude Code ejecute, y revisar el resultado contra tus criterios.
Esto tiene una implicación directa: no miras Claude Code trabajar. Le das la tarea, lo dejas correr, y vuelves cuando termina.
Tres ajustes que hacen posible este paradigma:
# En tu CLAUDE.md global o de proyecto:
# 1. Define estándares de output claros
Cuando completes una tarea, incluye siempre:
- Qué cambios hiciste y por qué
- Qué tests ejecutaste y su resultado
- Qué tienes pendiente si la tarea está parcialmente completa
# 2. Establece límites de autonomía
Antes de modificar archivos de configuración, base de datos, o
infraestructura: para y confirma conmigo.
# 3. Define el formato de entrega
Al terminar cada tarea, crea un resumen en formato:
COMPLETADO: [descripción]
ARCHIVOS: [lista]
PENDIENTE: [lista o ninguno]
Los servidores MCP (Model Context Protocol) son la pieza que convierte Claude Code de asistente a agente. Con los MCP correctos, Claude Code puede acceder a tu base de datos, hacer commits, desplegar en staging, y notificarte cuando termina — sin que tú hagas nada más que definir la tarea.
Los MCPs que uso en mi flujo diario:
# ~/.claude/settings.json (fragmento)
{
"mcpServers": {
"filesystem": {
"command": "npx @modelcontextprotocol/server-filesystem",
"args": ["./src", "./docs"] // acceso limitado a carpetas clave
},
"github": {
"command": "npx @modelcontextprotocol/server-github",
"env": {"GITHUB_TOKEN": "$GITHUB_TOKEN"}
}
}
}
Por la mañana defino las tareas del día en el archivo de contexto de Claude Code. Para cada tarea escribo: qué quiero conseguir, qué archivos relevantes debe conocer, y cuál es el criterio de 'done'. Luego arranco Claude Code con las tareas y me pongo con otra cosa.
Claude Code trabaja, hace commits con mensajes descriptivos, y cuando tiene dudas o llega a un punto de decisión — porque lo he configurado así — me notifica via hook. Yo reviso los commits, doy feedback si hace falta, y paso a la siguiente tarea.
El resultado: en lugar de 3 horas mirando una pantalla, tengo 3 horas de trabajo real — el mío — mientras Claude Code avanza en paralelo.
Este flujo no funciona para todo. Las decisiones de arquitectura, los trade-offs técnicos, el diseño de interfaces de usuario — eso requiere criterio humano. Usa Claude Code para la ejecución, no para la estrategia. Cuanto más claro seas en qué le delegas y qué decides tú, mejores resultados obtendrás.