DOMINICODE

Category: Claude Code

  • Claude Managed Agents: cuándo delegarle el harness a Anthropic

    Claude Managed Agents: cuándo delegarle el harness a Anthropic

    Llevaba tres semanas construyendo lo mismo que ya había construido dos veces antes: mi propio harness para correr Claude Managed Agents — el nombre que Anthropic le da a un agente que opera solo, durante horas, sin que nadie lo esté mirando.

    Un agent loop que decide cuándo llamar a una tool y cuándo parar.

    Un sandbox donde ese agente puede correr comandos de shell sin tumbar mi máquina — ni la de un cliente.

    Una capa de persistencia para que la sesión sobreviva si el proceso se cae a mitad de una tarea de cuarenta minutos.

    Reintentos cuando una tool falla a medio camino. Un sistema de eventos para poder decirle "espera, cambia esto" sin que el agente pierda todo el contexto acumulado.

    Nada de eso es difícil por separado. Lo difícil es que todo tenga que funcionar junto, de forma confiable, mientras el agente corre solo durante horas y tú estás durmiendo.

    Ahí es exactamente donde entra Claude Managed Agents: la apuesta de Anthropic de que la mayoría de equipos no debería tener que resolver ese problema de infraestructura por su cuenta.

    Messages API vs Claude Managed Agents: dos formas distintas de construir

    Anthropic te da dos caminos para construir con Claude, y elegir mal el camino te cuesta semanas.

    El primero es la Messages API: prompting directo al modelo. Tú decides el system prompt, tú implementas el loop que decide qué tool llamar, tú montas el sandbox donde esa tool corre. Control total — y responsabilidad total sobre cada pieza.

    Tú resuelves, además, qué pasa cuando el proceso se reinicia a mitad de tarea. Nada de eso viene resuelto de fábrica.

    El segundo camino son los Claude Managed Agents: un harness pre-construido y configurable que corre en infraestructura gestionada por Anthropic.

    En vez de montar tú el agent loop, la ejecución de tools y el runtime, obtienes un entorno donde Claude puede leer archivos, correr comandos, navegar la web y ejecutar código de forma segura — sin operar tú ni una línea de esa infraestructura.

    Ya escribí sobre qué significa en la práctica construir tu propio harness de agentes: agent loop, tool execution, memoria, checkpoints. Todo lo que Managed Agents te ahorra construir desde cero.

    Los 4 conceptos que necesitas entender

    Managed Agents se organiza alrededor de cuatro piezas:

    • Agent — el modelo, el system prompt, las tools, los servidores MCP y las skills. Se define una sola vez y se referencia por ID en tantas sesiones como necesites.
    • Environment — dónde corren las sesiones: un sandbox en la nube gestionado por Anthropic, o un sandbox self-hosted en tu propia infraestructura.
    • Session — una instancia del agente corriendo dentro de un environment, ejecutando una tarea concreta y generando outputs.
    • Events — los mensajes que se intercambian entre tu aplicación y el agente: turnos de usuario, resultados de tools, actualizaciones de estado.

    El flujo, de principio a fin

    1. Creas un agente (modelo + system prompt + tools + MCP servers + skills). Se crea una vez y se reutiliza.
    2. Creas un environment: sandbox en la nube o self-hosted.
    3. Inicias una sesión que referencia ese agente y ese environment.
    4. Envías events y recibes respuestas en streaming vía server-sent events. Claude ejecuta tools de forma autónoma; el historial completo se persiste server-side y puedes recuperarlo entero cuando quieras.
    5. Puedes "steerear" — dirigir — o interrumpir al agente a mitad de ejecución simplemente enviando eventos adicionales.

    Conceptualmente, el flujo se ve algo así (pseudo-código, no la sintaxis exacta del SDK):

    // Flujo conceptual — no es sintaxis literal del SDK
const agent = await client.agents.create({
  model: "claude-...",
  systemPrompt: "Eres un agente de investigación de incidentes...",
  tools: ["bash", "file_edit", "web_search"],
  mcpServers: [datadogMcp, githubMcp],
});

const environment = await client.environments.create({
  type: "cloud_sandbox", // o "self_hosted"
});

const session = await client.sessions.create({
  agentId: agent.id,
  environmentId: environment.id,
});

const stream = client.sessions.sendEvent(session.id, {
  type: "user_message",
  content: "Investiga por qué el deploy de ayer rompió el checkout",
});

for await (const event of stream) {
  // tool_call, tool_result, status_update...
}

    Out-of-the-box tienes Bash, operaciones de archivos (lectura, escritura, edición, glob, grep), web search y fetch, y servidores MCP para conectar tool providers externos.

    El harness también trae prompt caching y compaction integrados — dos cosas que, si construyes tu propio loop, terminas resolviendo tú mismo tarde o temprano. Todo esto también está disponible en Claude Platform on AWS, con algunas diferencias de disponibilidad de features.

    Cuándo tiene sentido delegar el harness (y cuándo no)

    No todo agente necesita esto. La documentación oficial es clara sobre las señales, y las convertí en una matriz de decisión:

    Señal Managed Agents Tu propio harness (Agent SDK / Claude Code)
    La tarea corre minutos u horas con múltiples llamadas a tools Resuelto de fábrica Construyes scheduler, retries y timeouts tú mismo
    Necesitas sandboxes seguros con paquetes preinstalados y acceso de red Cloud environment gestionado Lo montas y mantienes tú
    Compliance exige que el sandbox corra en tu propia infraestructura Self-hosted environment Ya lo tienes si construiste el tuyo desde cero
    Necesitas sesiones stateful — filesystem persistente e historial entre interacciones Nativo Lo implementas a mano
    Quieres runs recurrentes en un cron schedule Scheduled deployments Montas tu propio orquestador
    Necesitas control fino sobre hooks, skills, checkpoints y cada paso del loop No es el objetivo de la herramienta Aquí gana el Agent SDK o Claude Code
    Zero Data Retention o HIPAA BAA son un requisito duro No elegible actualmente Depende de cómo lo construyas tú

    Si tu caso de uso cae casi entero en la columna izquierda, delegar el harness te ahorra semanas de trabajo de infraestructura. Si cae en la derecha, seguir construyendo con el Agent SDK o Claude Code — donde tienes control total sobre hooks, skills y checkpoints — sigue siendo la decisión correcta.

    Las 3 features que cambiaron el juego en mayo 2026

    El 19 de mayo de 2026, en el evento "Code with Claude", Anthropic anunció tres features nuevas sobre esta base.

    No están todas en el mismo punto de madurez, y eso importa antes de decidir si construyes sobre ellas hoy.

    Dreaming — memoria que se auto-mejora entre sesiones (research preview)

    Dreaming es un proceso programado que revisa las sesiones de tu agente y sus memory stores, extrae patrones y cura las memorias para que tus agentes mejoren con el tiempo.

    La idea central: un agente individual no detecta los patrones que emergen a través de decenas de sesiones. Dreaming sí. Saca a la luz errores recurrentes y los workflows en los que tus agentes convergen una y otra vez — algo especialmente efectivo en escenarios de larga duración y multi-agente.

    Tú eliges: actualizaciones automáticas de memoria, o revisión manual antes de que los cambios se apliquen. Dreaming se combina con la feature Memory (ya disponible de forma general): los agentes capturan aprendizaje mientras trabajan, y Dreaming lo refina entre sesiones.

    Estado actual: research preview, con acceso vía formulario de solicitud. No es algo que actives hoy sin pedir permiso.

    Outcomes — un grader que evalúa sin el sesgo del propio agente (public beta)

    Outcomes te deja escribir una rúbrica describiendo qué es el éxito para una tarea. Un grader separado evalúa el output contra esos criterios en su propia ventana de contexto — así que no está influenciado por el razonamiento que el agente ya generó para justificarse a sí mismo. Cuando algo no está bien, el grader señala qué cambiar y el agente hace otro intento.

    Esta es, para mí, la feature con más impacto inmediato de las tres.

    Los números que publica Anthropic en sus benchmarks internos: hasta 10 puntos porcentuales de mejora en éxito de tarea, +8.4% en generación de archivos .docx y +10.1% en .pptx. No es marginal.

    Esto es exactamente la misma disciplina que defiendo en el libro de Spec-Driven Development: especificar qué es "éxito" antes de ejecutar, no después. Outcomes lo formaliza a nivel de infraestructura — la rúbrica es tu spec, el grader es quien la hace cumplir.

    Es especialmente útil para tareas que necesitan cobertura exhaustiva y detallada, o calidad subjetiva difícil de verificar con un test automatizado — voz de marca, guías de diseño. Soporta webhooks para enterarte cuando la tarea termina, sin hacer polling.

    Estado: public beta. Puedes usarlo hoy.

    Multiagent Orchestration — un líder, especialistas en paralelo, un filesystem compartido (public beta)

    Aquí el patrón es distribuir trabajo complejo entre agentes especializados que trabajan en paralelo, con un agente líder coordinando y manteniendo contexto compartido.

    El líder delega tareas a especialistas — cada uno con su propio modelo, prompt y tools. Todos comparten un filesystem, y los eventos son persistentes: los agentes recuerdan lo que hicieron antes, incluso entre sesiones distintas. Puedes seguir la traza completa en Claude Console: qué acción tomó cada agente, en qué secuencia, con qué razonamiento.

    El ejemplo oficial que da Anthropic es concreto: un agente líder de investigación con subagentes analizando en paralelo el historial de deploys, los logs de errores, las métricas y los tickets de soporte — cada uno especializado en su fuente, todos alimentando la misma conclusión.

    Estado: public beta. También disponible hoy, aunque con menos tiempo de maduración en producción que Outcomes.

    El detalle que no puedes ignorar: datos y compliance

    Managed Agents es stateful por diseño. Eso es justo lo que lo hace útil — sesiones long-running que se resumen limpiamente tras una pausa, con historial de conversación, estado del sandbox y outputs guardados server-side.

    Y esa misma característica tiene una consecuencia que no puedes pasar por alto: actualmente Managed Agents no es elegible para Zero Data Retention (ZDR) ni para HIPAA BAA.

    Si trabajas en un contexto regulado — salud, finanzas, cualquier cliente que exija ZDR contractualmente — esto descarta Managed Agents para esa carga de trabajo específica, al menos por ahora.

    Lo que sí tienes: puedes borrar sesiones y archivos en cualquier momento vía la API. No es lo mismo que ZDR, pero es un control real que deberías usar activamente si trabajas con datos sensibles dentro de un environment gestionado.

    Si tu producto necesita ZDR o HIPAA, la Messages API con tu propio harness sigue siendo el camino — al menos hasta que Anthropic mueva esta pieza.

    Qué significa esto para tu forma de trabajar con agentes

    Claude Code, Routines y Managed Agents son tres capas de automatización distintas, no tres versiones de lo mismo — y Managed Agents completa la tercera.

    Claude Code es la capa donde tú controlas cada paso: escribes el prompt, revisas el diff, decides cuándo commitear.

    Routines — de lo que ya hablé en este post sobre Claude Code y Routines — dispara automáticamente una tarea puntual: un trigger, una tarea, un resultado.

    Managed Agents es la infraestructura completa y autónoma: memoria que se auto-mejora con Dreaming, verificación de calidad integrada con Outcomes, coordinación multi-agente sin que tú operes el runtime.

    Cada capa reduce cuánto tienes que operar tú mismo, a cambio de menos control fino. Esa es la transacción real — no "automatización buena vs automatización mala".

    Messages API Claude Managed Agents
    Qué es Prompting directo, tú construyes el loop Harness pre-construido sobre infraestructura gestionada
    Quién opera el agent loop y el sandbox Tú Anthropic
    Persistencia de estado entre sesiones La implementas tú Nativa (sessions stateful)
    Mejor para Casos específicos, latencia baja, control total Tareas largas, asíncronas, multi-tool, multi-sesión
    Madurez Estable, uso general Beta — header managed-agents-2026-04-01

    Sé honesto sobre algo: esto sigue siendo beta. Todos los endpoints requieren ese header (el SDK lo configura solo).

    Dentro de la beta, MCP tunnels y Dreaming están en un research preview todavía más limitado — hay que solicitar acceso. Es una superficie que sigue moviéndose, no una API congelada lista para apostar tu negocio entero sin plan B.

    Si estás en el punto de pasar de "prototipo que funciona en mi máquina" a "producto que alguien más usa", esta es exactamente la conversación que trabajamos en el curso de Construye con IA: qué construyes tú y qué le delegas a la infraestructura de Anthropic.

    La pregunta correcta no es "self-hosted o managed"

    Construir un harness de agentes confiable es un problema de infraestructura, no solo de prompting. Lo aprendí de la forma cara: reconstruyendo el mismo agent loop tres veces antes de aceptarlo.

    Claude Managed Agents es la apuesta de Anthropic de que la mayoría de equipos no debería tener que resolver ese problema por su cuenta. Y para tareas largas, asíncronas, con necesidad de sandboxes seguros y memoria que mejora sola, tienen razón.

    Pero la pregunta que de verdad importa no es "self-hosted o managed" en abstracto. Es qué tan crítico es el control fino sobre tu harness para tu caso específico.

    Si la respuesta es "necesito controlar cada hook, cada skill, cada checkpoint" — sigue construyendo el tuyo. Si la respuesta es "necesito que esto simplemente funcione durante seis horas sin que yo lo esté mirando" — deja que Anthropic cargue con esa infraestructura.

    Si quieres discutir esto con otros developers que ya están probando Managed Agents en proyectos reales, en Dominicode Labs es exactamente el tipo de conversación que tenemos cada semana.

    Preguntas frecuentes sobre Claude Managed Agents

    ¿Qué son los Claude Managed Agents?

    Es un harness de agentes pre-construido y configurable que corre en infraestructura gestionada por Anthropic.

    En vez de que tú implementes el agent loop, el sandbox de ejecución de tools y la persistencia de estado, Anthropic te da un entorno donde Claude puede leer archivos, correr comandos, navegar la web y ejecutar código de forma segura, organizado alrededor de cuatro conceptos: Agent, Environment, Session y Events.

    ¿En qué se diferencian de construir mi propio agente con la Messages API?

    Con la Messages API tú controlas todo: el system prompt, el loop que decide qué tool llamar, el sandbox donde corre, y qué pasa si el proceso se cae a mitad de tarea.

    Con Managed Agents esa infraestructura la opera Anthropic — tú defines el agente y el environment, y el harness se encarga de la ejecución, el streaming vía eventos, la persistencia y, opcionalmente, el self-hosting del sandbox.

    ¿Qué es "Dreaming" en Claude Managed Agents?

    Es un proceso programado que revisa las sesiones de un agente y sus memory stores para extraer patrones que un agente individual no puede detectar por sí solo, y curar las memorias para que el agente mejore entre sesiones.

    Se puede configurar para aplicar cambios automáticamente o para requerir revisión manual. Actualmente está en research preview, con acceso vía formulario de solicitud — no es de disponibilidad general.

    ¿Qué es "Outcomes" y cómo mejora la calidad del output?

    Outcomes te deja definir una rúbrica de éxito para una tarea. Un grader independiente — con su propia ventana de contexto, sin el sesgo del razonamiento que el agente ya generó — evalúa el output contra esa rúbrica y le pide otro intento si no cumple.

    En benchmarks internos de Anthropic, esto mejoró el éxito de tarea hasta en 10 puntos porcentuales, con mejoras específicas de +8.4% en .docx y +10.1% en .pptx. Está en public beta, disponible hoy.

    ¿Qué es "Multiagent Orchestration" en Claude Managed Agents?

    Es el modelo donde un agente líder distribuye trabajo complejo entre varios agentes especializados que trabajan en paralelo, cada uno con su propio modelo, prompt y tools.

    Todos comparten un filesystem y los eventos son persistentes, así que el equipo de agentes recuerda lo que hizo antes. Está en public beta, con trazabilidad completa de cada acción disponible en Claude Console.

    ¿Puedo usar Claude Managed Agents en producción hoy?

    Puedes usarlo hoy, pero con matices importantes. Todo el sistema de Managed Agents está en beta y requiere el header managed-agents-2026-04-01 (el SDK lo configura automáticamente).

    Outcomes y Multiagent Orchestration están en public beta y son razonablemente estables. Dreaming y MCP tunnels están en un research preview más limitado, con acceso solicitado por formulario. Evalúa cada feature por separado antes de apostar tu producto entero a ella.

    ¿Managed Agents cumple con HIPAA o Zero Data Retention (ZDR)?

    No, actualmente no. Managed Agents es stateful por diseño — guarda historial de conversación, estado del sandbox y outputs server-side para que las sesiones long-running se puedan resumir limpiamente — y eso lo hace no elegible para ZDR ni para un HIPAA BAA.

    Sí puedes borrar sesiones y archivos en cualquier momento vía la API, pero si tu carga de trabajo exige ZDR o HIPAA de forma contractual, tu propio harness sobre la Messages API sigue siendo el camino correcto por ahora.

    Por Bezael Pérez — Developer senior con más de 15 años de experiencia y fundador de Dominicode.

  • Claude Code hooks: guardrails, logging y automatización para tus agentes

    Claude Code hooks: guardrails, logging y automatización para tus agentes

    Hook PreToolUse para Bash: bloquea rm -rf y loguea todo

    set -euo pipefail

    Leer el JSON de entrada desde stdin

    INPUT=$(cat)

    Extraer el comando que Claude quiere ejecutar

    COMMAND=$(echo "$INPUT" | jq -r '.tool_input.command // ""')

    Timestamp para el log

    TIMESTAMP=$(date -u +"%Y-%m-%dT%H:%M:%SZ")
    LOG_FILE="${CLAUDE_PROJECT_DIR:-$HOME}/.claude/bash-audit.log"

    Loguear el comando (siempre, antes de cualquier decisión)

    echo "[$TIMESTAMP] CMD: $COMMAND" >> "$LOG_FILE"

    Patrones peligrosos que bloqueamos sin excepciones

    BLOCKED_PATTERNS=(
    "rm -rf /"
    "rm -rf ~"
    "rm -rf *"
    "rm -rf ."
    ":(){ :|:& };:"
    "dd if=/dev/zero"
    "> /dev/sda"
    "mkfs."
    )

    for PATTERN in "${BLOCKED_PATTERNS[@]}"; do
    if echo "$COMMAND" | grep -qE "$PATTERN"; then
    echo "[$TIMESTAMP] BLOCKED: $COMMAND" >> "$LOG_FILE"
    echo "Comando bloqueado por hook de seguridad: patrón destructivo detectado ('$PATTERN')" >&2
    exit 2
    fi
    done

    Todo bien — salida silenciosa, flujo normal

    exit 0

    
Ahora la configuración en `.claude/settings.json`:

```json
{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "command": "${CLAUDE_PROJECT_DIR}/.claude/hooks/bash-guard.sh",
            "timeout": 10
          }
        ]
      }
    ]
  }
}

    Dale permisos de ejecución al script:

    chmod +x .claude/hooks/bash-guard.sh

    A partir de aquí, cada vez que Claude intente ejecutar un comando Bash, el hook se dispara primero. Si detecta un patrón peligroso, Claude recibe el mensaje de error en stderr y no ejecuta nada. Si todo está limpio, el agente continúa sin ninguna interrupción visible.

    El archivo bash-audit.log crece con cada comando ejecutado. En una sesión de trabajo normal con un agente activo, ese log te cuenta la historia completa de lo que hizo Claude — sin tener que scrollear el historial de conversación.

    Añadir una notificación cuando el agente termina

    Si lanzas tareas largas y quieres saber cuándo terminan sin estar mirando la pantalla, el hook Stop es lo que necesitas.

    {
  "hooks": {
    "Stop": [
      {
        "hooks": [
          {
            "type": "command",
            "command": "${CLAUDE_PROJECT_DIR}/.claude/hooks/notify-done.sh",
            "timeout": 5
          }
        ]
      }
    ]
  }
}

    #!/bin/bash
# .claude/hooks/notify-done.sh
# Notificación de escritorio cuando Claude termina una tarea

# En macOS
if command -v osascript &> /dev/null; then
  osascript -e 'display notification "Claude ha terminado la tarea" with title "Claude Code"'
fi

# En Linux con notify-send
if command -v notify-send &> /dev/null; then
  notify-send "Claude Code" "El agente ha terminado la tarea"
fi

exit 0

    El hook Stop no tiene matcher porque no hay herramientas que filtrar — aplica siempre que Claude decide parar. Si necesitas que Claude continúe trabajando hasta que se cumpla alguna condición (por ejemplo, todos los tests en verde), haz que el script devuelva exit 2 y escribe en stdout un JSON con {"hookSpecificOutput": {"additionalContext": "Los tests aún fallan. Corrígelos antes de terminar."}} para que Claude sepa qué debe hacer a continuación. El stderr en Stop hooks no interrumpe el flujo.

    Cuándo usar hooks, cuándo CLAUDE.md y cuándo sub-agentes

    Esta es la pregunta que más se repite cuando alguien empieza a añadir capas de control a sus agentes.

    Usa CLAUDE.md para instrucciones de comportamiento en lenguaje natural: convenciones de código, qué herramientas preferir, cómo formatear los commits. Es lo primero que Claude lee. Es contexto, no control.

    Usa hooks cuando necesitas una garantía técnica que no dependa de que Claude interprete bien una instrucción. Un rm -rf bloqueado por un hook es un rm -rf bloqueado, siempre, independientemente de cómo estaba redactado el prompt. Un rm -rf "prohibido" en CLAUDE.md es una sugerencia que Claude puede ignorar bajo presión de contexto.

    Usa sub-agentes cuando necesitas razonamiento sobre una situación: revisar si el código generado cumple los requisitos de arquitectura, validar que una migración de base de datos es correcta antes de ejecutarla, resumir los resultados de diez herramientas en paralelo. Los sub-agentes piensan. Los hooks no necesitan pensar — esa es su ventaja.

    La regla general: hooks para lo que debe ser determinista, sub-agentes para lo que requiere juicio.

    Preguntas frecuentes

    ¿Los hooks se ejecutan con cada mensaje del usuario o solo cuando Claude usa herramientas?

    Depende del tipo de hook. PreToolUse y PostToolUse solo se disparan cuando Claude invoca una herramienta — no con cada mensaje de texto. UserPromptSubmit se dispara con cada mensaje enviado, antes de que Claude lo procese. Stop se dispara cuando Claude decide terminar, no cuando el usuario escribe algo.

    ¿Puedo tener hooks diferentes para proyectos distintos?

    Sí. Los hooks en .claude/settings.json (dentro del proyecto) solo aplican a ese proyecto. Los hooks en ~/.claude/settings.json aplican a todos tus proyectos. Si hay configuraciones en ambos archivos, se combinan. En caso de conflicto en el mismo evento, la configuración más específica (proyecto) tiene precedencia.

    ¿Un hook puede modificar lo que Claude va a hacer, no solo bloquearlo?

    Sí, en PreToolUse. Puedes devolver por stdout un JSON con hookSpecificOutput.updatedInput para reemplazar los argumentos que Claude iba a usar. Por ejemplo, si Claude quiere ejecutar rm -rf build, puedes interceptarlo y devolver rm -rf build/ (con trailing slash) para que solo borre el contenido del directorio, no el directorio en sí. Esta capacidad es poderosa — úsala con cuidado.

    ¿Hay alguna forma de ver qué hooks están activos en mi sesión?

    Sí. Escribe /hooks en el prompt de Claude Code y se abre una vista en el navegador con todos los hooks configurados, organizados por evento, con su matcher y tipo de handler. Es de solo lectura, pero es la forma más rápida de auditar qué está activo.

    ¿Los hooks se pueden desactivar sin borrarlos?

    Sí. Añade "disableAllHooks": true en cualquiera de los archivos de settings. Solo los settings de usuario y proyecto pueden desactivar hooks definidos en esos mismos niveles — los hooks de configuración administrada (managed settings) requieren intervención del administrador.

    ¿Hay límite en cuántos hooks puedo configurar?

    No hay un límite documentado en el número de hooks. Sí hay un timeout por hook (por defecto 600 segundos para comandos, 30 para prompts). Si un hook supera el timeout, se cancela como error no bloqueante (igual que un exit 1) — el flujo continúa pero el hook no tuvo efecto.

    Lo que cambia cuando añades hooks a tu workflow

    La primera semana que empecé a usar hooks en mis propios agentes, lo que más me sorprendió no fue la seguridad — fue la visibilidad.

    El archivo de log de comandos Bash me reveló patrones que no había visto antes. Claude ejecutaba con frecuencia ciertos comandos que yo no esperaba. Algunos eran ineficientes. Uno de ellos era potencialmente problemático en un contexto de CI. Sin el log, nunca me habría enterado.

    Los hooks no solo protegen tu sistema. Te dan información real sobre cómo trabaja el agente — y esa información es la que necesitas para mejorar tus prompts, tu CLAUDE.md y tu arquitectura de agentes con el tiempo.

    Si estás construyendo algo serio con Claude Code — más de un agente, un workflow automatizado, código que toca producción —, los hooks no son opcionales. Son la diferencia entre un agente que funciona y uno en el que confías.

    Si quieres ver cómo encajan los hooks dentro de un sistema de agentes más completo — con sub-agentes, routines y MCP — en el curso Construye con IA cubrimos el stack completo desde la idea hasta el producto, incluyendo cómo estructurar los guardrails de seguridad para workflows que corren sin supervisión constante.

    Y si prefieres un entorno donde experimentar con otros developers que están construyendo lo mismo, en Dominicode Labs compartimos proyectos, configuraciones y workflows reales cada semana.

    Bezael Pérez — Developer senior, fundador de Dominicode. Lleva 15+ años construyendo software y los últimos años construyendo con IA. Escribe sobre arquitectura de agentes, Angular moderno y cómo pasar de idea a producto sin caos.

  • Registrar un MCP server en Claude Code con claude mcp add

    Registrar un MCP server en Claude Code con claude mcp add

    Ya tienes tu MCP server escrito y compilado. Arranca sin errores, los tools están declarados, y ahora quieres usarlo desde Claude Code.

    Ese último paso parece trivial y es donde se atasca casi todo el mundo. No porque el comando sea difícil, sino porque claude mcp add tiene tres scopes distintos que deciden en qué proyectos aparece tu server y con quién se comparte. Elegir mal el scope se manifiesta como un server que "no funciona" cuando en realidad está perfectamente registrado — en otro sitio.

    Esta guía es el registro y nada más: el comando, los scopes, cómo pasar variables de entorno y qué mirar cuando no conecta.

    El comando

    La sintaxis para un server local por stdio es esta:

    claude mcp add [opciones] <nombre> -- <comando> [args...]

    Aplicado a un server compilado en tu máquina:

    claude mcp add --transport stdio github-issues -- node /ruta/absoluta/build/index.js

    El -- no es decorativo. Separa las opciones de Claude Code de lo que se le pasa a tu server. Todo lo que va después se ejecuta tal cual, sin que Claude Code intente interpretarlo:

    # Sin --, Claude Code intentaría parsear --port como opción suya
claude mcp add --transport stdio myserver -- python server.py --port 8080

    Usa siempre ruta absoluta. El comando se resuelve desde el directorio donde arranque Claude Code, no desde donde ejecutaste claude mcp add.

    Si prefieres no compilar mientras desarrollas, npx tsx funciona igual:

    claude mcp add --transport stdio github-issues -- npx tsx /ruta/src/index.ts

    Scopes: dónde queda registrado tu server

    Aquí es donde se pierde la gente. El flag -s / --scope decide dónde se guarda la configuración, y eso determina en qué proyectos ves el server.

    Scope Disponible en Compartido con el equipo Se guarda en
    local (por defecto) Solo el proyecto actual No ~/.claude.json
    project Solo el proyecto actual Sí, por control de versiones .mcp.json en la raíz
    user Todos tus proyectos No ~/.claude.json 
    # local (por defecto): solo este proyecto, solo tú
claude mcp add --transport stdio github-issues -- node /ruta/build/index.js

# user: disponible en todos tus proyectos
claude mcp add --scope user --transport stdio github-issues -- node /ruta/build/index.js

# project: se escribe en .mcp.json y viaja con el repositorio
claude mcp add --scope project --transport stdio github-issues -- node /ruta/build/index.js

    El caso típico de confusión: registras el server en scope local estando en un proyecto, abres Claude Code en otro directorio, y el server no aparece. No se ha roto nada — local significa literalmente este proyecto. Si lo quieres en todas partes, es --scope user.

    Y si trabajas en equipo, --scope project es el que te interesa: escribe un .mcp.json en la raíz que puedes commitear, y tus compañeros lo tienen al clonar.

    Variables de entorno

    Para un server que necesita credenciales, pásalas con --env (o -e) en el registro:

    claude mcp add --env GITHUB_TOKEN=ghp_xxx --transport stdio github-issues \
  -- node /ruta/absoluta/build/index.js

    La variable se define en el entorno del server, no en el de Claude Code. Dentro de tu código la lees con process.env.GITHUB_TOKEN como siempre.

    Ojo con esto si usas --scope project: ese .mcp.json acaba en el repositorio. No metas ahí tokens en claro.

    Comprobar que ha quedado registrado

    claude mcp list

    Deberías ver github-issues en el listado.

    Un detalle que confunde: el estado Pending approval solo aparece en servers de scope project que vienen de un .mcp.json. Es la aprobación que Claude Code te pide antes de ejecutar algo que ha llegado por el repositorio, no por tus manos. Un server que añadiste tú con claude mcp add en scope local o user no pasa por esa aprobación.

    Para inspeccionar la configuración concreta de uno:

    claude mcp get github-issues

    Cómo probarlo desde una sesión de Claude Code

    Abre Claude Code en el directorio donde registraste el server y escribe algo que active tu tool:

    Lista los issues abiertos del repo microsoft/vscode

    Claude detecta que tiene acceso al tool list_issues, lo llama con { owner: "microsoft", repo: "vscode", state: "open" }, y devuelve la lista formateada directamente en el chat.

    Sin salir del editor. Sin copiar y pegar. Sin fricción.

    Cuándo no llega a conectar

    Por orden de frecuencia, esto es lo que suele pasar:

    • Ruta relativa en el comando. Se resuelve desde donde arranca Claude Code, no desde donde registraste. Usa ruta absoluta.
    • Scope equivocado. El server está registrado, pero en otro proyecto. Comprueba con claude mcp list desde el directorio en el que estás trabajando.
    • Un console.log en el server. En transporte stdio, stdout es el canal JSON-RPC exclusivo del protocolo. Un solo console.log corrompe el flujo y produce un error de parseo que no dice nada útil. Todo el logging va a console.error.
    • El server tarda en arrancar. Ajusta el timeout con MCP_TIMEOUT, en milisegundos: MCP_TIMEOUT=10000 claude.

    Antes de dar por rota la integración, aísla el server con MCP Inspector, la herramienta oficial:

    npx @modelcontextprotocol/inspector node /ruta/build/index.js

    Abre una interfaz web donde ves los tools registrados y puedes invocarlos a mano. Si ahí funciona y en Claude Code no, el problema es el registro, no el server.

    Ir más allá: cuándo crear tu propio MCP server

    Esta es la pregunta real. El ecosistema de MCP servers públicos ya tiene integraciones para GitHub, Slack, Notion, bases de datos, filesystems y decenas más. No construyas lo que ya existe.

    Crea el tuyo cuando:

    1. Tienes una API interna que nadie más va a integrar.
    2. Necesitas transformar o filtrar datos antes de que lleguen al modelo — la lógica de negocio importa.
    3. Quieres controlar exactamente qué puede hacer Claude y qué no en tu entorno.
    4. Estás construyendo un producto y necesitas que Claude interactúe con él de forma programática.

    Si todavía no tienes claro qué es MCP ni qué expone realmente un server, aquí lo explico desde cero.

    Y si quieres profundizar en este modelo de trabajo — construir con IA de forma estructurada, con specs, con MCP servers propios, con agentes que hacen trabajo real — en el curso Construye con IA: De la Idea al Producto con Claude Code trabajamos exactamente este flujo. Desde la idea hasta tener algo en producción.

    Preguntas frecuentes

    ¿Necesito compilar TypeScript para registrar el server?

    No. Para desarrollo local, npx tsx /ruta/src/index.ts funciona igual. Compilar a JS es más fiable para uso continuado porque no dependes de que tsx esté disponible, pero para iterar no hace falta.

    ¿Cuál es la diferencia entre los scopes local, user y project?

    local es el valor por defecto y limita el server al proyecto actual, solo para ti. user lo hace disponible en todos tus proyectos. project lo escribe en un .mcp.json en la raíz del repositorio, así que viaja por control de versiones y lo tiene todo el equipo. Si el server no aparece donde esperabas, casi siempre es un scope mal elegido.

    ¿Cuál es la diferencia entre stdio y HTTP como transporte?

    stdio es el modo local: Claude Code lanza tu server como proceso hijo y se comunican por stdin/stdout. Es lo más simple y suficiente para tools personales o de equipo. El transporte HTTP es para servers remotos que expones como servicio — por ejemplo, un MCP server de empresa desplegado en un servidor. Se registra con --transport http <nombre> <url>.

    ¿Mis tools pueden leer archivos del sistema o ejecutar comandos?

    Sí. Un MCP server tiene acceso completo al sistema donde se ejecuta: puede leer archivos con fs, lanzar procesos con child_process y hacer peticiones de red. Eso es también la responsabilidad — el server corre con los permisos del usuario que lo lanza, así que diseña los tools con cuidado y no expongas capacidades destructivas sin confirmación.

    ¿Funciona con Claude Desktop o solo con Claude Code?

    Funciona con cualquier cliente MCP compatible. Claude Desktop usa claude_desktop_config.json en lugar de claude mcp add, pero el server es exactamente el mismo. También es compatible con Cursor, Continue y cualquier cliente que implemente el protocolo. Ese es el punto de MCP: escribes el server una vez y lo consumes desde donde quieras.

    Conclusión

    Registrar un MCP server es un comando, pero el scope es lo que decide si lo vas a encontrar donde esperas. local para lo tuyo en un proyecto, user para lo tuyo en todos, project para lo del equipo.

    Y cuando algo no conecte, aísla antes de investigar: MCP Inspector te dice en treinta segundos si el problema está en el server o en cómo lo registraste.

    Si estás construyendo flujos de trabajo con agentes de IA y quieres ir más allá de los MCP servers públicos, en Dominicode Labs publicamos proyectos completos, code reviews y recursos exclusivos para developers que construyen con IA en serio.

    Por Bezael Pérez — Developer senior con más de 15 años de experiencia y fundador de Dominicode.

  • CLAUDE.md y memoria persistente: mi flujo real con Claude Code

    CLAUDE.md y memoria persistente: mi flujo real con Claude Code

    Nombre y propósito del proyecto

    [Una o dos líneas. Para qué sirve y quién lo opera.]

    Reglas globales

    [Idioma, tono, convenciones no negociables. Las cosas que si Claude Code
    ignora, el output es inutilizable.]

    Estructura del repositorio

    [Árbol de directorios con una línea explicando qué hay en cada carpeta.
    Claude Code necesita saber dónde está cada cosa sin tener que explorar.]

    Comandos disponibles

    [Los scripts, CLIs y comandos que puede ejecutar. Con ejemplo real de uso.]

    Convenciones de nomenclatura

    [Patrones de nombres de archivos. Crítico para proyectos con muchos docs.]

    Qué NO hacer

    [Igual de importante que lo que sí hacer. Archivos que no tocar,
    patrones que evitar, decisiones ya tomadas que no reabrir.]

    
Lo que no incluyo: historia del proyecto, motivaciones, "por qué elegimos X tecnología". Eso es contenido para un ADR o el README. El CLAUDE.md tiene que ser operativo al 100%.

**Longitud objetivo: menos de 200 líneas.** Si supera eso, estás incluyendo demasiado. Claude Code no necesita el contexto completo de cada decisión — necesita las reglas de operación.

### Lo que la mayoría mete en CLAUDE.md y no debería

He revisado muchos CLAUDE.md de proyectos de developers en la comunidad. El error más común: meter todo lo que "podría ser útil".

Eso mata el propósito del documento. Cuando el CLAUDE.md tiene 500 líneas, Claude Code lo lee entero pero no distingue qué es crítico y qué es relleno. El resultado es el mismo que no tener CLAUDE.md: ruido.

Solo va al CLAUDE.md lo que, si Claude Code lo ignora, rompe el proyecto o produce output inutilizable.

---

## El sistema de memoria persistente

El contexto de una sesión de Claude Code desaparece cuando la sesión termina. Eso es una limitación real y no va a cambiar pronto — la ventana de contexto no es memoria a largo plazo.

El workaround que funciona: archivos Markdown.

### La estructura que uso

En el directorio del proyecto tengo una carpeta `memory/` con dos tipos de archivos:

1. **`MEMORY.md`** — el índice. Una lista de una línea por cada archivo de memoria con un enlace y una descripción de qué contiene. Claude Code lo lee al arrancar la sesión y sabe qué hay disponible.

2. **Archivos individuales de memoria** — uno por tema. Nomenclatura descriptiva: `project_kursar.md`, `feedback_email_style.md`, `reference_tools.md`.

Una entrada en `MEMORY.md` tiene esta forma:

```markdown
# Memory Index — Dominicode Company Agents

- [User Profile](user_profile.md) — Solo creator, YouTube + Udemy + books, comunidad en español
- [Curso Angular 22](project_curso_angular22.md) — Regrabación en curso; ejemplos verificados en ejemplos/v22-features/
- [Estilo emails Bezael](feedback_email_style.md) — Abrir con historia breve; no estilo telegráfico
- [WordPress taxonomía](reference_wordpress_taxonomia.md) — IDs reales verificados (AI=37, TypeScript=42…)

    Hay tres prefijos que uso para distinguir el tipo de contenido:

    • project_ — estado de un proyecto activo con decisiones tomadas
    • feedback_ — algo que salió mal o que aprendí de una sesión anterior y no quiero volver a repetir
    • reference_ — datos estáticos que Claude Code necesita consultar (IDs, URLs, credenciales de formato)

    Por qué funciona mejor que repetirlo en cada sesión

    La alternativa es pegar el contexto en el primer prompt de cada sesión. Lo hice durante semanas. El problema: acumulas un primer prompt de 800 palabras que tarde o temprano omites porque es tedioso, y cuando lo omites, Claude Code trabaja sin ese contexto.

    Con archivos de memoria, el contexto está disponible siempre que Claude Code los lea. Y como están versionados en el repo, no se pierden entre sesiones ni entre máquinas.

    El inconveniente honesto: Claude Code no lee esos archivos automáticamente a menos que se lo indiques. Tienes que incluirlos en el arranque de sesión o referenciarlos con @archivo cuando son relevantes. Esto lo resuelvo con el ritual de inicio que cuento más adelante.

    Gestión del contexto en sesiones largas

    Esto es lo que menos se habla y lo que más impacta en la calidad del trabajo.

    Una sesión larga de Claude Code acumula contexto de forma lineal. Cada intercambio, cada archivo leído, cada respuesta generada ocupa espacio en la ventana. Cuando la ventana se llena, el modelo empieza a "comprimir" el historial — mantiene las instrucciones recientes y los bloques de código más relevantes, pero los matices de conversaciones anteriores se difuminan.

    El resultado es exactamente lo que me pasó esa tarde: Claude Code responde con coherencia local (el último intercambio está bien) pero pierde coherencia global (contradice decisiones tomadas hace cuarenta minutos).

    Cómo lo detecto

    Hay tres señales de que el contexto está degradado:

    • Claude Code propone algo que ya descartamos explícitamente en la misma sesión
    • Las respuestas se vuelven más genéricas y pierden el tono específico del proyecto
    • Me pide información que ya le di al inicio de la sesión

    Cuando aparece cualquiera de las tres, no sigo. Empiezo sesión nueva.

    Cuándo empezar sesión nueva (aunque duela)

    La respuesta rápida: cuando terminas un bloque de trabajo concreto.

    No esperes a que el contexto se degrade. Trata cada sesión de Claude Code como una unidad de trabajo enfocada. Si estoy escribiendo un post del blog, esa es la sesión. Si paso a revisar el curriculum de un curso, es una sesión nueva.

    Este cambio de mentalidad es lo que más impacta en la consistencia del output. Una sesión larga y dispersa produce resultados mediocres. Sesiones cortas y enfocadas producen resultados que puedes usar directamente.

    @files: cuándo y cómo los uso

    Claude Code tiene la sintaxis @archivo para incluir el contenido de un archivo específico en el contexto. Es la herramienta más infrautilizada que conozco entre developers que llevan meses con Claude Code.

    Uso @archivo para tres cosas:

    Dar contexto específico sin abrir un archivo manualmente. Si estoy trabajando en el agente de blog y necesito que Claude Code vea el estado actual del MEMORY.md, escribo @memory/MEMORY.md en el prompt. El contenido entra directamente en el contexto sin que yo tenga que copiarlo.

    Anclar decisiones pasadas. Si en una sesión nueva necesito que recuerde una decisión de arquitectura que está en specs/agentkit-pro/spec.md, la referencio con @. Entra en el contexto de esa sesión específicamente donde la necesito.

    Forzar coherencia entre archivos. Si estoy modificando un componente y quiero que Claude Code sea consciente de cómo lo usa otro módulo, incluyo ambos con @. Sin eso, trabaja con el archivo aislado y puede romper la integración.

    Lo que no hago: incluir diez archivos con @ en el mismo prompt. Cuantos más archivos incluyes, más contexto consumes antes de empezar el trabajo real. Selecciono solo los que son directamente relevantes para la tarea concreta de esa sesión.

    El ritual de inicio de sesión

    Después de meses ajustando esto, tengo un primer prompt que uso como plantilla base. No es magia — es contexto específico entregado de forma eficiente.

    Contexto de esta sesión:
- Proyecto: [nombre]
- Tarea: [qué voy a hacer hoy, en una línea]
- Decisiones previas que aplican: @memory/MEMORY.md
- Archivos relevantes: @[archivo-1] @[archivo-2]
- Restricciones: [lo que NO quiero que haga en esta sesión]

Empieza por [primera acción concreta].

    Los tres elementos críticos son:

    La tarea en una línea. No el proyecto entero, solo lo que hacemos hoy. Cuanto más específico, mejor el foco de Claude Code durante toda la sesión.

    Las restricciones. Es lo que más me ha ahorrado tiempo. "No toques el archivo X", "no propongas cambiar el stack", "si necesitas más información, pregunta antes de generar código". Sin restricciones explícitas, Claude Code optimiza para completar la tarea con las decisiones que considera mejores — que no siempre son las que tú ya tomaste.

    Una primera acción concreta. No "ayúdame con el proyecto". Sino "lee el archivo X y dime si la estructura de directorios es coherente con las reglas de CLAUDE.md". La primera acción específica establece el tono de toda la sesión.

    Lo que todavía falla y cómo lo mitigo

    Honestidad completa aquí, porque la mayoría de posts sobre Claude Code solo muestran los casos de éxito.

    Los archivos de memoria no se actualizan solos. Si en una sesión tomo una decisión importante — por ejemplo, cambio la arquitectura de un módulo o descubro que una librería no funciona para mi caso de uso — tengo que acordarme de actualizar el archivo de memoria correspondiente antes de cerrar la sesión. Si no lo hago, en la siguiente sesión Claude Code no tiene ese contexto. Todavía me olvido. La solución parcial: incluir "actualiza MEMORY.md con las decisiones de esta sesión" como último paso de cada sesión de trabajo.

    El CLAUDE.md global a veces entra en conflicto con el del proyecto. Tengo reglas globales que son sensatas para el 90% de mis proyectos pero que en algún proyecto específico quiero anular. Claude Code no siempre resuelve bien ese conflicto — a veces aplica la regla global aunque el CLAUDE.md del proyecto diga lo contrario. La solución: en el CLAUDE.md del proyecto, cuando necesito anular una regla global, lo digo explícitamente: "Aunque el CLAUDE.md global indica X, en este proyecto aplicamos Y."

    La compresión de contexto no es predecible. No hay un indicador que te diga "estás al 80% de la ventana de contexto, es hora de empezar sesión nueva". Lo detecto por los síntomas que describí antes. Estoy esperando que Claude Code añada algún tipo de indicador de uso de contexto — de momento no existe.

    Las sesiones cortas y enfocadas son más difíciles de mantener. Cuando estoy en el flow, la tentación de seguir en la misma sesión es real. Cada vez que cedo, la calidad del output en la segunda mitad de la sesión baja. Es un problema de disciplina, no de herramienta.

    FAQ

    ¿Cuántas secciones debe tener un CLAUDE.md?

    No hay un número correcto. Lo importante es que cada sección tenga una función operativa clara. Si no puedes responder "qué hace Claude Code diferente por tener esta sección", esa sección sobra. En mis proyectos suelo tener entre 5 y 8 secciones.

    ¿Puedo tener múltiples CLAUDE.md en subdirectorios?

    Sí. Claude Code lee el CLAUDE.md del directorio raíz y también los de subdirectorios cuando trabaja en ellos. Esto es útil en monorepos o cuando tienes un frontend y un backend con convenciones distintas. No lo abuses — si tienes CLAUDE.md en diez subdirectorios, el agente pasa más tiempo leyendo instrucciones que trabajando.

    ¿Qué diferencia hay entre poner algo en CLAUDE.md y decirlo en el primer prompt?

    El CLAUDE.md aplica a todas las sesiones del proyecto de forma permanente. El primer prompt aplica solo a esa sesión. Usa CLAUDE.md para convenciones estables que no cambian entre sesiones. Usa el primer prompt para el contexto específico de lo que haces hoy.

    ¿Cuándo tiene sentido usar memoria persistente vs. simplemente tener un CLAUDE.md más completo?

    CLAUDE.md es para reglas e instrucciones: cómo trabajar en este proyecto. Los archivos de memoria son para estado e historial: qué ha pasado ya, qué decisiones están tomadas, qué feedback recibí en sesiones anteriores. Si en tu CLAUDE.md estás escribiendo cosas como "el curso de Angular lleva dos semanas atrasado" o "el cliente pidió cambiar el color primario a azul", eso debería ir en un archivo de memoria, no en CLAUDE.md.

    ¿Funciona igual en proyectos de código que en proyectos de contenido?

    Igual de bien, o incluso mejor en proyectos de contenido. Todo lo que describí aquí lo uso tanto para el repositorio de código de Kursar como para el sistema de agentes de Dominicode — que no tiene una sola línea de código productivo, pero tiene 18 agentes, 118 documentos en la base de conocimiento, y decisiones editoriales acumuladas durante meses. El sistema de memoria persistente es especialmente valioso cuando el "código" son documentos, estrategias y decisiones.

    Conclusión

    El contexto no es un detalle técnico de Claude Code que puedas ignorar. Es el recurso central que determina si el agente trabaja contigo o contra ti.

    CLAUDE.md bien estructurado te da coherencia por defecto. La memoria persistente te da continuidad entre sesiones. El ritual de inicio te da foco en cada sesión. Y saber cuándo empezar sesión nueva te salva de la degradación silenciosa que destruye la calidad del output.

    No necesitas implementar todo esto de golpe. Empieza por el CLAUDE.md del proyecto — 100 líneas operativas, sin relleno. Eso solo ya cambia radicalmente cómo trabaja Claude Code en tu repositorio.

    Si quieres ver este sistema aplicado a un proyecto real de principio a fin, en el curso Construye con IA trabajamos exactamente con este flujo: CLAUDE.md, memoria, gestión del contexto y SDD como metodología para que el agente tenga siempre el contexto correcto en el momento correcto.

    Y si ya tienes Claude Code corriendo y quieres profundizar con otros developers que están en el mismo camino, en Dominicode Labs compartimos los patrones que van funcionando en producción — incluyendo los que fallan y cómo los arreglamos.

    Posts relacionados

    Bezael Pérez es developer senior con 15+ años de experiencia y fundador de Dominicode. Construye con Claude Code, Angular y TypeScript, y documenta lo que funciona — y lo que no — para developers que quieren ir más allá del vibe coding.

  • Claude Code Routines: automatiza agentes sin encender tu PC

    Claude Code Routines: automatiza agentes sin encender tu PC

    El viernes por la tarde cerré el portátil con 23 issues sin triagear en el repo, tres PRs esperando revisión de documentación y un changelog que nadie había actualizado en dos semanas.

    El lunes por la mañana, todo estaba hecho.

    No porque contraté a nadie. No porque dejé el ordenador encendido todo el fin de semana. Fue la primera vez que sentí que las Claude Code Routines no eran una feature más de Anthropic — eran la diferencia entre usar IA como herramienta y usarla como infraestructura.

    De herramienta a infraestructura: el salto que cambia todo

    Si ya usas Claude Code de forma interactiva, sabes lo que puede hacer. Le das contexto, le pides algo, revisa tu código, abre PRs. Pero todo depende de que tú estés sentado delante del teclado, iniciando cada conversación.

    Las Routines rompen esa dependencia.

    Una Routine es una configuración guardada de Claude Code: un prompt, uno o más repositorios y un conjunto de conectores (MCP), empaquetados una sola vez y ejecutados de forma automática. Lo que las hace distintas de cualquier script de bash con un cron job es que corren en la infraestructura cloud de Anthropic. Tu máquina puede estar apagada. Claude sigue trabajando.

    Están disponibles desde abril de 2026 en research preview para todos los planes de pago: Pro, Max, Team y Enterprise. Se crean desde claude.ai/code/routines — consulta la documentación oficial de Claude Code para ver los últimos límites y cambios.

    Los tres tipos de trigger

    Una Routine puede tener uno o varios triggers combinados. Esto es lo que hace que el modelo sea flexible de verdad.

    1. Schedule (cron)

    Ejecuta la Routine de forma recurrente: cada hora, diariamente, entre semana o cada semana. Si necesitas un intervalo personalizado — por ejemplo, cada dos horas o el primer día de cada mes — configuras el preset más cercano en la interfaz de claude.ai/code/routines.

    El intervalo mínimo es una hora. Expressions que corren con más frecuencia se rechazan.

    También existe el concepto de one-off run: disparas la Routine una sola vez en un timestamp futuro. Útil para recordatorios diferidos, limpiezas post-deploy o tareas que tienen que correr "cuando aterrice ese PR de upstream". Después de ejecutarse, la Routine se auto-deshabilita. Y un detalle importante: los one-off runs no cuentan contra el límite diario de Routines.

    2. GitHub event

    Dispara una sesión nueva automáticamente cuando ocurre un evento en un repositorio conectado. Los eventos soportados incluyen pull request (opened, closed, labeled, synchronized…) y release (created, published, edited…).

    Puedes añadir filtros para reducir exactamente cuándo se dispara: autor del PR, título, rama base, rama head, labels, si es draft o no, si está mergeado. Cada evento que pasa los filtros abre su propia sesión independiente — no hay reutilización de sesiones entre eventos.

    Para usar GitHub triggers hace falta instalar la Claude GitHub App en el repositorio. No basta con el acceso que configuras en /web-setup para clonar repos.

    3. Webhook (API trigger)

    Cada Routine con este trigger tiene un endpoint HTTP dedicado. Le haces POST con un bearer token y arranca una sesión nueva. El cuerpo de la request acepta un campo text opcional — puedes pasarle el cuerpo de una alerta, un stack trace o cualquier contexto que la Routine necesite para esa ejecución concreta.

    La respuesta devuelve el ID y la URL de la sesión creada, así puedes abrirla en el navegador para ver qué está haciendo Claude en tiempo real.

    curl -X POST https://api.anthropic.com/v1/claude_code/routines/trig_01ABCDEF.../fire \
  -H "Authorization: Bearer sk-ant-oat01-xxxxx" \
  -H "anthropic-beta: experimental-cc-routine-2026-04-01" \
  -H "anthropic-version: 2023-06-01" \
  -H "Content-Type: application/json" \
  -d '{"text": "Error crítico en producción: SEN-4521. Stack trace adjunto."}'

    Tres Routines que puedes activar esta semana

    Estos no son ejemplos de documentación. Son los casos de uso que más sentido tienen para un developer indie o un equipo pequeño.

    Triage de issues cada noche

    Un trigger de schedule que corre de lunes a viernes a las 23:00. El prompt le dice a Claude que lea todos los issues abiertos desde la última ejecución, aplique labels según el área de código referenciada, asigne propietario y publique un resumen en Slack. Llegas por la mañana con la cola de trabajo ya priorizada.

    Requiere: conector de GitHub + conector de Slack configurados como MCP connectors en tu cuenta de claude.ai.

    Code review automatizado en cada PR

    Un trigger de GitHub que reacciona a pull_request.opened con filtro is draft: false. El prompt aplica el checklist de revisión de tu equipo: seguridad, performance, style. Deja comentarios inline y un resumen para los revisores humanos. Los humanos se concentran en diseño y arquitectura — lo mecánico lo hace Claude.

    Este es el tipo de automatización que en equipos de 1-3 personas elimina el cuello de botella de revisión completamente.

    Changelog automático post-merge

    Un trigger de GitHub en pull_request.closed filtrado a is merged: true en la rama main. El prompt le pide a Claude que lea el diff del PR mergeado, extraiga el cambio relevante en lenguaje humano y lo añada al CHANGELOG.md en un PR nuevo. Sin nunca más tener que acordarte de documentar lo que acabas de subir a producción.

    Lo que paga el coste

    Las Routines consumen cuota de suscripción de la misma manera que una sesión interactiva. Además, hay un límite diario de runs por cuenta según el plan:

    • Pro: 5 runs diarios
    • Max: 15 runs diarios
    • Team / Enterprise: 25 runs diarios

    Si superas el límite o la cuota de suscripción, las ejecuciones siguientes se rechazan hasta que se resetea la ventana — salvo que tengas usage credits activados, en cuyo caso sigue corriendo en modo metered.

    Los GitHub triggers también tienen un cap por hora durante la research preview. Si un repositorio muy activo dispara demasiados eventos, los excedentes se descartan hasta que se resetea la ventana. Los límites actuales los ves en claude.ai/code/routines.

    El hecho de que sea research preview significa que los límites, la API y el comportamiento pueden cambiar. No construyas pipelines de producción críticos sobre esto todavía — pero sí es el momento perfecto para experimentar y entender cómo integrar esto en tu workflow.

    Routines vs. Managed Agents: no es lo mismo

    Anthropic también ha lanzado Claude Managed Agents con dos features que suenan parecidas pero son una capa distinta: Dreaming y Outcomes.

    La diferencia es importante para no confundirlos.

    Las Routines son un mecanismo de scheduling y ejecución. Definen cuándo y cómo corre una sesión de Claude Code. Son infraestructura de automatización.

    Dreaming es un proceso que revisa las sesiones pasadas de tus agentes y los memory stores, extrae patrones y perfecciona las memorias para que el agente mejore con el tiempo. Es un sistema de aprendizaje retrospectivo, no de ejecución de tareas.

    Outcomes es una feature de evaluación: defines un rubric de éxito y un evaluador separado (con su propio context window, para no contaminarse con el razonamiento del agente) revisa el output y le dice al agente qué corregir si no cumple el criterio. Es un loop de calidad, no de scheduling.

    Dicho de forma directa: las Routines responden a "¿cuándo y con qué trigger corre esto?". Managed Agents responde a "¿cómo mejora y cómo evalúa su propio output el agente?". Pueden usarse juntos, pero son capas con responsabilidades distintas.

    Un detalle que no está en la documentación oficial

    Cuando una Routine corre, lo hace de forma completamente autónoma. Sin permission mode, sin prompts de aprobación durante la ejecución. Claude puede ejecutar comandos de shell, usar skills del repositorio clonado y llamar a todos los conectores que hayas incluido.

    Esto es potente. Y también es la razón por la que el prompt de la Routine es el artefacto más importante del sistema. A diferencia de una sesión interactiva donde puedes corregir el rumbo, aquí el prompt tiene que ser autocontenido y explícito sobre qué hacer y qué aspecto tiene el éxito.

    Por defecto, Claude solo puede hacer push a ramas con prefijo claude/. Para permitirle escribir en ramas existentes o protegidas, tienes que habilitar explícitamente "Allow unrestricted branch pushes" en la configuración de la Routine. Una salvaguarda razonable.

    Las Routines pertenecen a tu cuenta individual de claude.ai. Los commits, los PRs y las acciones en conectores como Slack o Linear aparecen como tú — con tu identidad de GitHub, tu Slack, etc. Eso tiene implicaciones de auditoría que vale la pena tener en cuenta si trabajas en equipo.

    El shift real

    Llevo tiempo diciendo que el developer indie de 2026 puede operar con la capacidad de un equipo pequeño si usa bien las herramientas que tiene. Si llegas nuevo a Claude Code, el post sobre Effort, Models, Tools y Context te da el mapa completo antes de entrar en Routines. Y si quieres entender la capa de arquitectura detrás de los agentes, el post sobre agentic harness completa el cuadro. Las Routines son la prueba más concreta de eso que he visto hasta ahora.

    No es sobre chatear con IA. Es sobre delegar trabajo real a agentes que corren en la nube con tu identidad, contra tus repos, con tus herramientas. Y que lo hacen mientras tú duermes, estás en una reunión o simplemente tienes el portátil cerrado.

    Si llevas tiempo usando Claude Code de forma interactiva, las Routines son el siguiente paso natural. Si quieres un sistema para construir esto de forma ordenada — desde la idea hasta el producto sin caos — en el curso Construye con IA en Udemy cubrimos exactamente ese proceso: cómo estructurar el trabajo con Claude Code para que escale más allá de la sesión interactiva.

    Y si quieres ver cómo otros developers están implementando esto en proyectos reales, en Dominicode Labs estamos documentando los patrones que funcionan — incluyendo los prompts de Routines que uso en mi propio workflow.

    Preguntas frecuentes

    ¿Necesito tener mi servidor propio para usar Claude Code Routines?

    No. Las Routines corren directamente en la infraestructura cloud de Anthropic. No necesitas EC2, Railway, Fly.io ni ningún servidor propio. El único requisito es una suscripción de pago a Claude (Pro, Max, Team o Enterprise) con Claude Code on the web habilitado.

    ¿Cuál es la diferencia entre una Routine y un Desktop Scheduled Task?

    Los Desktop Scheduled Tasks corren en tu máquina local cuando el app de escritorio de Claude Code está abierto. Tienen acceso a tus archivos locales pero requieren que tu ordenador esté encendido. Las Routines corren en la nube de Anthropic independientemente de si tienes el ordenador encendido o el app abierto.

    ¿Puedo combinar varios tipos de trigger en la misma Routine?

    Sí. Una misma Routine puede tener triggers de schedule, de GitHub event y de API al mismo tiempo. Por ejemplo, una Routine de revisión de PRs puede correr de forma programada cada noche, dispararse también cuando se abre un PR nuevo en GitHub, y aceptar ejecuciones manuales vía webhook desde tu pipeline de CI/CD.

    ¿Qué pasa si una Routine falla o Claude no completa la tarea?

    El indicador de estado verde en el historial de runs solo significa que la sesión se inició y terminó sin errores de infraestructura — no que la tarea se completó con éxito. Para saber qué hizo Claude realmente tienes que abrir la sesión y revisar el transcript. Los errores de red, los conectores que faltan o los fallos a nivel de tarea aparecen en el transcript, no en el indicador de estado.

    ¿Las Routines tienen acceso a todos mis conectores MCP?

    Por defecto, cuando creas una Routine, incluye todos tus MCP connectors conectados en claude.ai. La recomendación de Anthropic es quitar los que no necesita la Routine específica para limitar el alcance de lo que Claude puede hacer durante la ejecución. Los MCP servers que hayas añadido localmente en el CLI con claude mcp add no están disponibles en Routines — tienes que añadirlos como connectors en claude.ai/customize/connectors.

    Por Bezael Pérez — Developer senior con más de 15 años de experiencia y fundador de Dominicode.

  • Claude Code: Effort, Models, Tools y Context para developers

    Claude Code: Effort, Models, Tools y Context para developers

    La primera vez que abrí Claude Code, lo traté como un chat más inteligente. Le pegaba código, le pedía que lo arreglara, copiaba la respuesta. Funcionaba, pero lo estaba usando como una versión cara de Stack Overflow.

    Tardé tres semanas en entender que Claude Code no es un chatbot. Es un agente que ejecuta herramientas reales en tu sistema, que puede leer tu repositorio entero, que tiene niveles de razonamiento configurables y que toma decisiones en cadena sin que tú intervengas en cada paso.

    Cuando lo entendí así, cambió todo.

    Este post es lo que me hubiera gustado leer antes de empezar. No es un tutorial de instalación — asume que ya lo tienes corriendo. Es una explicación honesta de los cuatro conceptos que determinan si Claude Code trabaja para ti o contra ti: Effort, Models, Tools y Context.

    Effort — el nivel de razonamiento que decides gastar

    Cuando Claude Code procesa una tarea, no siempre piensa igual de profundo. Puedes configurar cuánto razonamiento aplica desde la UI de Claude Code o mediante la opción de esfuerzo en la configuración. Los niveles son cuatro: low, medium, high y max.

    Esto no es marketing. Es la diferencia entre gastar dos segundos y gastar dos minutos en una misma pregunta, con respuestas radicalmente distintas.

    Low — cuando la velocidad importa más que la precisión

    Con low, Claude Code responde rápido y sin profundizar demasiado. Es útil para tareas mecánicas y predecibles: renombrar variables, formatear código, generar boilerplate que ya tienes en mente pero no quieres teclear.

    Si le pides "añade un método toString() a esta clase", no necesita razonar sobre arquitectura. low es suficiente.

    Medium — el nivel por defecto para trabajo diario

    medium es lo que usas el 80% del tiempo. Hay razonamiento real, considera contexto, pero no entra en análisis profundo de consecuencias. Funciona bien para refactoring moderado, explicaciones técnicas, generación de tests unitarios para funciones simples.

    Es el equilibrio entre velocidad y calidad que necesitas en un flujo de trabajo normal.

    High — cuando el error cuesta caro

    Aquí Claude Code empieza a razonar sobre consecuencias. Evalúa múltiples opciones antes de decidir, considera casos borde, analiza impacto en el resto del sistema.

    Úsalo cuando toques código crítico: un servicio de autenticación, la lógica de pagos, una migración de base de datos, un cambio arquitectural en el core de la aplicación. El tiempo extra que tarda se justifica con la reducción de errores no detectados.

    Max — análisis exhaustivo, sin atajos

    max activa el razonamiento más profundo disponible. Claude Code descompone el problema en partes, considera múltiples estrategias, evalúa trade-offs explícitamente.

    Esto no es para trabajo diario. Es para cuando necesitas que te ayude a diseñar la arquitectura de un módulo nuevo, cuando tienes un bug imposible de reproducir que llevas días persiguiendo, o cuando vas a tomar una decisión técnica con consecuencias a largo plazo.

    El coste es tiempo y tokens. La ganancia es profundidad real.

    Regla práctica: empieza con medium. Si la respuesta no llega al nivel que necesitas, sube un nivel. No uses max por defecto — no tiene sentido pagar el coste de razonamiento exhaustivo para añadir un campo en un formulario.

    Models — cuál elegir y por qué importa

    Claude Code tiene acceso a varios modelos bajo el capó. No todos son iguales en velocidad, coste ni capacidad. Elegir mal aquí es tirar dinero o tirar tiempo.

    A junio de 2026, los modelos disponibles en Claude Code son:

    Claude Haiku 4.5 — velocidad máxima, coste mínimo

    Haiku es el modelo pequeño. Responde en segundos, cuesta muy poco por token, y es más que suficiente para tareas de bajo peso cognitivo: completar líneas de código, responder preguntas de documentación, generar snippets concretos que ya tienes pensados.

    En un workflow agentic donde Claude Code ejecuta decenas de llamadas encadenadas (leer archivos, buscar patrones, escribir logs), Haiku hace el trabajo de las subtareas sin disparar el coste.

    Claude Sonnet 4.6 — el modelo de trabajo diario

    Sonnet es el punto dulce. Más capaz que Haiku en razonamiento y contexto largo, más rápido y barato que Opus, suficientemente potente para el 90% de las tareas de un developer.

    Refactoring complejo, generación de tests con lógica no trivial, debugging asistido, implementación de features completas — Sonnet lo maneja bien. Si no sabes cuál usar, empieza aquí.

    Claude Opus 4.8 — para problemas difíciles

    Opus es el modelo grande. Más lento, más caro, y considerablemente más capaz cuando el problema requiere razonamiento profundo, comprensión de contexto muy largo o análisis de consecuencias en sistemas complejos.

    No lo uses para tareas rutinarias. Sí lo uses cuando estés diseñando una arquitectura nueva, cuando el problema tiene múltiples dependencias que hay que razonar en paralelo, o cuando los outputs de Sonnet no son suficientemente precisos para tu caso.

    Claude Fable 5 — el modelo más potente

    Fable es el frontier model de Anthropic. Capacidades extendidas de razonamiento, mejor manejo de contexto muy largo y mayor precisión en tareas de alta complejidad. En Claude Code aparece como opción para las tareas más exigentes.

    Úsalo con criterio: el coste es significativamente mayor. Tiene sentido cuando diseñas sistemas críticos, cuando necesitas que el modelo razone sobre un codebase completo de miles de archivos, o cuando el nivel de precisión que necesitas no lo alcanza Opus.

    La decisión práctica: para trabajo diario usa Sonnet. Para subtareas rápidas y repetitivas dentro de un agente, Haiku. Para decisiones técnicas importantes o problemas difíciles, Opus o Fable. El modelo correcto no es el más potente — es el que resuelve el problema con el menor coste posible.

    Tools — las herramientas built-in que hacen a Claude Code un agente real

    Aquí está la diferencia fundamental entre Claude Code y un chatbot: Claude Code tiene herramientas que ejecuta de verdad en tu sistema. No simula leer archivos — los lee. No describe cómo haría una búsqueda — la hace.

    Estas son las herramientas principales y para qué sirve cada una:

    Herramienta Qué hace
    Read Lee el contenido de un archivo del filesystem. Claude ve exactamente lo que hay en el archivo, con números de línea.
    Edit Modifica un fragmento concreto de un archivo existente. Solo envía el diff, no reescribe todo el archivo.
    Write Crea un archivo nuevo o sobreescribe uno completo. Más costoso que Edit — úsalo solo cuando el cambio afecta a todo el archivo.
    Bash Ejecuta comandos de shell reales en tu sistema. Tests, builds, git, scripts, cualquier cosa que harías en terminal.
    Glob Busca archivos por patrón (**/*.ts, src/**/*.spec.ts). Útil para que Claude Code entienda la estructura del proyecto antes de actuar.
    Grep Busca contenido dentro de archivos por expresión regular. Para localizar dónde se usa una función, qué archivos importan un módulo, qué tests cubren una clase.
    WebSearch Hace búsquedas web reales. Útil cuando necesita documentación actualizada, información sobre versiones recientes o validar datos externos.
    WebFetch Descarga y procesa el contenido de una URL concreta. Para leer documentación oficial, specs de una API, changelog de una librería.
    Agent Lanza un subagente — una instancia paralela de Claude Code que ejecuta una subtarea de forma independiente. Arquitectura agentic en acción.
    TodoRead / TodoWrite Gestiona una lista de tareas interna de la sesión. Claude Code se auto-organiza las tareas que tiene pendientes en una tarea compleja.

    Lo que hace potente a este conjunto no es ninguna herramienta por sí sola — es la combinación. Claude Code lee la estructura del proyecto con Glob, localiza el código relevante con Grep, lo lee con Read, lo modifica con Edit, y ejecuta los tests con Bash. Todo en secuencia, sin que tú intervengas en cada paso.

    Este es el flujo que hace que una instrucción como "refactoriza el módulo de autenticación para que use el nuevo interceptor HTTP" produzca cambios reales en diez archivos distintos, con los tests pasando al final.

    La referencia completa de todas las herramientas y sus parámetros está en la documentación oficial de Claude Code.

    Si quieres ver cómo encajan estas herramientas con el resto del stack IA, en Stack IA agéntica en 2026: qué usar, qué ignorar y cuál elijo analizo exactamente eso.

    Si te interesa construir workflows agenticos más avanzados con Claude Code — desde la idea hasta un producto deployado — el curso Construye con IA: De la Idea al Producto con Claude y Specs cubre exactamente eso: cómo orquestar estas herramientas para que Claude Code trabaje con autonomía real.

    Context — cómo sabe Claude Code dónde está y qué importa

    El contexto es el factor más subestimado de Claude Code. Puedes tener el modelo correcto, el nivel de esfuerzo correcto y todas las herramientas disponibles — si Claude Code no entiende el contexto de tu proyecto, los outputs serán genéricos.

    @files y @folders — lo que le pones delante

    En la interfaz de Claude Code puedes mencionar archivos o carpetas con @. Cuando escribes @src/app/auth/auth.service.ts, Claude Code lee ese archivo y lo incluye directamente en el contexto de la conversación antes de procesar tu instrucción.

    Con @src/app/auth/ incluyes toda la carpeta. Claude Code procesa los archivos relevantes y construye una comprensión del módulo antes de actuar.

    Esto no es solo "adjuntar archivos". Es darle a Claude Code el mapa del territorio antes de pedirle que navegue.

    @url — documentación externa en tiempo real

    @url le permite a Claude Code leer el contenido de una URL y usarlo como contexto. Si necesitas que siga la documentación oficial de Angular v22 antes de modificar tu código de routing, puedes darle la URL del changelog y él la procesa.

    Esto elimina el problema clásico de los LLMs con conocimiento desactualizado. Si la librería sacó una versión nueva hace dos semanas, puedes darle la fuente actualizada directamente.

    CLAUDE.md — la memoria persistente del proyecto

    El archivo CLAUDE.md en la raíz de tu proyecto es la forma de darle a Claude Code instrucciones permanentes que se cargan en cada sesión.

    Aquí defines las convenciones del proyecto: cómo nombrar archivos, qué patrones arquitecturales seguís, qué comandos son los válidos, qué herramientas externas usáis, qué NO debe tocar sin confirmación explícita. Un CLAUDE.md bien escrito hace que Claude Code se comporte como un developer que conoce las reglas del equipo desde el primer día.

    No es opcional. Es la diferencia entre un agente que trabaja contigo y uno que trabaja en paralelo a ti sin coordinación.

    Memoria entre sesiones

    Por defecto, cada sesión de Claude Code empieza sin memoria de conversaciones anteriores. El contexto no persiste automáticamente.

    La forma correcta de manejar esto es el CLAUDE.md: las decisiones técnicas importantes, las convenciones acordadas, las restricciones del proyecto — todo lo que necesita persistir va ahí. No en el historial de conversación.

    Para proyectos más complejos, puedes estructurar archivos adicionales de contexto (specs, planes, documentos de arquitectura) y referenciarlos con @ al inicio de cada sesión. Es un flujo de trabajo, no una feature automática.

    En Dominicode Labs tenemos proyectos reales donde aplicamos exactamente esta estructura — con los archivos de contexto organizados para que Claude Code mantenga coherencia a lo largo de semanas de desarrollo.

    Cuatro hábitos para usar Claude Code como un agente real

    Claude Code no es difícil. Pero usarlo bien requiere entender que no es un chatbot avanzado — es un agente con herramientas reales, niveles de razonamiento configurables, múltiples modelos con características distintas, y un sistema de contexto que tú controlas.

    Elegir el modelo correcto para cada tarea, configurar el esfuerzo según lo que está en juego, dejar que las tools hagan el trabajo sin microgestionar cada paso, y mantener un CLAUDE.md que le dé continuidad al proyecto — esos cuatro hábitos son la diferencia entre usarlo como un buscador caro y usarlo como un colaborador técnico real.

    El siguiente paso es construir algo con él. No un script de prueba — un flujo de trabajo real donde Claude Code gestione decisiones en cadena. Si quieres ver ese proceso desde el principio, el curso Construye con IA: De la Idea al Producto con Claude y Specs parte exactamente de aquí.

    FAQ — Preguntas frecuentes sobre Claude Code

    ¿Claude Code funciona con cualquier lenguaje de programación?

    Sí. Claude Code no está limitado a ningún stack. Funciona igual con TypeScript, Python, Go, Rust, Java o cualquier lenguaje que puedas ejecutar desde terminal. Las herramientas como Bash, Glob y Grep operan sobre el filesystem, no sobre el lenguaje. Lo que sí varía es la calidad del output según el lenguaje — para TypeScript y Python la precisión es especialmente alta porque son los lenguajes más representados en el entrenamiento.

    ¿Cuál es la diferencia real entre Sonnet y Opus para trabajo diario?

    En la práctica, para el 90% de las tareas cotidianas no notarás diferencia en calidad. Sí notarás diferencia en velocidad y coste. Opus tarda más y consume más tokens. La diferencia se hace evidente en problemas complejos con mucho contexto: cuando le das un módulo de 3.000 líneas y le pides que entienda las dependencias implícitas antes de refactorizar, Opus razona más profundo. Para añadir un endpoint nuevo a una API que ya funciona, Sonnet es suficiente.

    ¿Cómo evito que Claude Code modifique archivos que no debe tocar?

    Con el CLAUDE.md. Puedes definir explícitamente qué archivos o carpetas son de solo lectura, qué operaciones requieren confirmación explícita tuya antes de ejecutarse, y qué convenciones debe respetar siempre. Claude Code en modo interactivo ya solicita confirmación antes de ejecutar operaciones destructivas — y con autoApproveEdits: false en tu settings.json puedes reforzar ese control para cualquier edición de archivos.

    ¿Claude Code puede trabajar en proyectos con múltiples repositorios?

    Sí, pero con matices. Claude Code opera desde el directorio donde lo lanzas y puede leer rutas relativas o absolutas fuera de él si tienes los permisos correctos. Para proyectos monorepo o arquitecturas con múltiples repos relacionados, la práctica recomendada es lanzarlo desde la raíz del monorepo y gestionar el contexto con @carpetas específicas para cada subtarea. Si trabajas con Angular en un monorepo, el curso de Angular Moderno cubre la estructura de proyectos que mejor se integra con flujos agenticos.

    ¿Cuánto contexto puede manejar Claude Code en una sesión?

    Depende del modelo. Los modelos actuales de Claude tienen ventanas de contexto de 200.000 tokens, lo que equivale a varios cientos de miles de líneas de código. En la práctica, el límite operativo es antes: a partir de cierto volumen, la calidad del razonamiento empieza a degradarse aunque técnicamente quepa más. La buena práctica es ser selectivo con el contexto que cargas — usar @ para incluir solo los archivos relevantes para la tarea actual, no volcar el repositorio entero en cada sesión.

    Por Bezael Pérez — Developer senior con más de 15 años de experiencia y fundador de Dominicode.

  • Automatizar el proceso de desarrollo con IA: de Jira al deploy

    Automatizar el proceso de desarrollo con IA: de Jira al deploy

    Hace tres meses le propuse a un cliente algo que le sonó a ciencia ficción: que el agente iba a leer el ticket de Jira, implementar la feature, abrir el navegador para testearla, hacer el code review y crear el PR en GitHub. Que él solo tendría que revisar y aprobar.

    Su respuesta fue "sí, claro". Con la misma energía con la que alguien te dice "ajá" cuando no te está escuchando.

    Lo puse en marcha. En la primera semana el agente cerró cuatro tickets de forma autónoma. El quinto lo paré yo a mitad porque se estaba inventando un requisito que no estaba en el ticket. Ajusté el prompt. El sexto salió limpio.

    Esto no es el futuro. Es lo que puedes montar hoy con Claude Code, el MCP de Jira, el MCP de Chrome y un CLAUDE.md bien escrito. Y en este post te cuento exactamente cómo funciona el pipeline para automatizar el proceso de desarrollo con IA de principio a fin.

    Un pipeline agentico de desarrollo es un flujo automatizado donde un agente de IA ejecuta de forma autónoma los pasos de implementación, testing y revisión de código a partir de un ticket, reduciendo la intervención humana al momento de aprobar el resultado.

    El problema con el workflow de desarrollo tradicional

    El ciclo habitual de un developer en un equipo tiene un patrón claro: leer el ticket, entender el contexto del código, implementar, escribir el test manual en el navegador, hacer el PR, esperar el code review, corregir los comentarios, mergear, rezar para que el CI pase.

    Cada uno de esos pasos tiene rozamiento. Cambios de contexto. Interrupciones. El developer senior pasa entre un 20% y un 30% de su tiempo en tareas que no son escribir código: leer tickets, crear PRs, hacer reviews de código propio.

    Con agentes, ese porcentaje puede recortarse a la mitad.

    No estoy hablando de reemplazar al developer. Estoy hablando de eliminar la fricción mecánica para que el developer se quede con las decisiones que importan.

    El pipeline completo: de Jira al deploy en seis pasos

    Así es el flujo que tengo montado:

    [Ticket Jira]
     ↓
[Claude Code lee ticket via MCP Jira]
     ↓
[Lee CLAUDE.md + contexto del proyecto]
     ↓
[Implementa la feature o bug fix]
     ↓
[MCP Chrome: abre navegador, navega, verifica]
     ↓
[/code-review: detecta problemas antes del merge]
     ↓
[Crea PR en GitHub con descripción del ticket]
     ↓
[CI/CD se dispara tras el merge]
     ↓
[Deploy a producción]

    El developer entra en el paso de revisar el PR. Todo lo anterior lo hace el agente.

    Paso 1: leer el ticket de Jira

    Claude Code tiene acceso al MCP de Jira. Cuando invocas el agente con el ID del ticket, extrae la descripción, los criterios de aceptación, el tipo de tarea y cualquier comentario relevante.

    # Invocar el agente con un ticket específico
claude "Lee el ticket PROJ-412 de Jira e implementa la tarea"

    El agente extrae:

    • Descripción de la tarea
    • Criterios de aceptación (los usará para el testing)
    • Labels y tipo (bug, feature, refactor)
    • Comentarios con contexto adicional

    Si los criterios de aceptación están mal escritos o son ambiguos, el agente lo detecta y puede preguntar antes de implementar. Ese comportamiento se configura en el CLAUDE.md del proyecto.

    Paso 2: leer el contexto del proyecto con CLAUDE.md

    El CLAUDE.md es la memoria del agente sobre tu proyecto. Antes de escribir una sola línea de código, Claude Code lee este archivo para entender:

    • Convenciones de nomenclatura
    • Arquitectura del proyecto (qué hace cada capa)
    • Comandos para correr tests y el servidor local
    • Patrones prohibidos o recomendados
    • Cómo se estructuran los PRs en este equipo

    Un CLAUDE.md bien escrito transforma al agente de "asistente genérico" a "developer que conoce el proyecto". La diferencia entre los dos es enorme en producción.

    # CLAUDE.md — ejemplo mínimo

## Arquitectura
- Feature modules en `src/features/<nombre>/`
- Services solo en la capa de aplicación, nunca en componentes
- Todos los efectos secundarios pasan por el store (NgRx)

## Comandos importantes
- Dev server: `bun run dev`
- Tests: `bun run test`
- Build: `bun run build`

## Convenciones de PR
- Título: `[PROJ-XXX] descripción breve`
- Descripción: resumen del ticket + cambios técnicos + steps to test

    Si quieres ver cómo construir un CLAUDE.md completo para un proyecto real, en el curso Construye con IA lo hago desde cero con un proyecto en TypeScript.

    Paso 3: implementar la feature

    Claude Code implementa la tarea. Lee los archivos relevantes, sigue las convenciones del CLAUDE.md, escribe los tests unitarios si el proyecto los requiere y ejecuta el servidor local para verificar que compila sin errores.

    Aquí es donde el contexto importa más que el modelo. Un agente con buen contexto (CLAUDE.md + ticket detallado) implementa con una tasa de acierto mucho más alta que uno que empieza desde cero.

    El agente también puede hacer preguntas aclaratorias antes de implementar si detecta ambigüedad. Ese comportamiento se configura así en el CLAUDE.md:

    ## Comportamiento del agente
- Si los criterios de aceptación son ambiguos, pregunta antes de implementar
- No inventes requisitos que no estén en el ticket
- Si necesitas crear un nuevo módulo, describe la estructura antes de crearla

    Paso 4: testing en el navegador con el MCP de Chrome

    Este es el paso que más sorprende a los developers cuando lo ven por primera vez.

    El MCP de Chrome (servidor MCP que usa Playwright por debajo para controlar el navegador) le da a Claude Code control total: abrir URLs, hacer clic en elementos, rellenar formularios, tomar screenshots, leer el contenido del DOM, verificar mensajes de error en consola.

    El agente usa los criterios de aceptación del ticket como guión de testing. Si el ticket dice "el usuario debe poder filtrar la tabla por fecha y ver solo los registros del rango seleccionado", el agente:

    1. Abre la app en localhost:4200
    2. Navega a la sección de la tabla
    3. Selecciona un rango de fechas
    4. Verifica que los registros mostrados coinciden con el filtro
    5. Toma un screenshot del resultado
    6. Revisa la consola del navegador para detectar errores
    // API de Playwright que ejecuta el servidor MCP internamente
await page.goto('http://localhost:4200/dashboard/reports');
await page.click('[data-testid="date-filter"]');
await page.fill('[data-testid="date-from"]', '2026-01-01');
await page.fill('[data-testid="date-to"]', '2026-01-31');
await page.click('[data-testid="apply-filter"]');

const rows = await page.$$('[data-testid="table-row"]');
// Verifica que todos los rows tienen fechas dentro del rango

    Si algo falla, el agente lo reporta, corrige el código y vuelve a ejecutar el test. Es un loop de implementar → testear → corregir que el developer antes hacía manualmente.

    Referencia: Playwright — documentación oficial de automatización de navegadores.

    Paso 5: code review automático antes del PR

    Antes de crear el PR, el agente ejecuta /code-review — un slash command de Claude Code que analiza todos los cambios del diff:

    • Detecta problemas de seguridad (inputs sin sanitizar, secrets hardcodeados)
    • Verifica que se siguen las convenciones del proyecto
    • Revisa cobertura de casos edge
    • Detecta código duplicado o patrones que el equipo tiene como prohibidos

    Si el code review detecta problemas críticos, el agente los corrige antes de crear el PR. Si son sugerencias menores, las incluye como comentarios en la descripción del PR para que el reviewer humano las evalúe.

    Tengo un post completo sobre cómo configurar el agentic code review con Claude Code si quieres profundizar en esa parte del pipeline.

    Paso 6: crear el PR y disparar el CI/CD

    El agente crea el PR en GitHub con:

    • Título siguiendo la convención del proyecto (extraído del ticket)
    • Descripción generada del ticket: contexto, criterios de aceptación, cambios técnicos
    • Screenshot del testing en navegador como evidencia visual
    • Checklist de testing para el reviewer
    # El agente ejecuta esto internamente
gh pr create \
  --title "[PROJ-412] Filtro por fecha en tabla de reportes" \
  --body "$(cat pr-description.md)" \
  --base main

    Cuando el developer aprueba el PR y hace el merge, el CI/CD se dispara automáticamente. GitHub Actions corre los tests, valida el build y despliega a producción. El agente ya no interviene en este paso — el pipeline de CI/CD es responsabilidad del equipo de infraestructura.

    Lo que el developer sigue haciendo

    Dejar claro este punto porque es importante: el agente no reemplaza al developer. El developer hace tres cosas:

    1. Escribir tickets con criterios de aceptación claros. Esto es ahora la habilidad más valiosa. Un ticket ambiguo produce código ambiguo.
    2. Revisar y aprobar el PR. El agente implementa, pero el developer decide si el resultado es correcto.
    3. Mantener el CLAUDE.md actualizado. Las convenciones del proyecto, la arquitectura, los patrones — el agente es tan bueno como el contexto que le das.

    El rol evoluciona de "el que escribe el código" a "el que define qué construir y valida que se construyó bien". Que es, paradójicamente, donde está el valor real de un developer senior.

    En Dominicode Labs estamos implementando este pipeline en proyectos reales con la comunidad — si quieres ver el setup completo con errores incluidos, es donde lo hacemos en directo.

    Cómo empezar a automatizar tu proceso de desarrollo con IA

    No montes el pipeline completo de golpe. Empieza con esto:

    1. Escribe un CLAUDE.md sólido para tu proyecto
    2. Instala el MCP de GitHub en Claude Code
    3. Prueba crear un PR automático desde un cambio pequeño
    4. Añade el MCP de Chrome y testea un flujo simple en el navegador
    5. Conecta Jira cuando los pasos anteriores funcionen de forma estable

    El pipeline completo lleva tiempo afinar. El valor llega antes de tenerlo completo.

    Preguntas frecuentes

    ¿El MCP de Chrome funciona con cualquier framework frontend (React, Vue, Angular)?
    Sí. El MCP de Chrome opera sobre el navegador real, no sobre el framework. No le importa si la app está en Angular, React o Vue — interactúa con el DOM resultante. Solo necesitas que la app esté corriendo en un servidor local accesible.

    ¿Qué pasa si los criterios de aceptación del ticket están mal escritos o son incompletos?
    El agente intentará inferir la intención, pero si la ambigüedad es suficientemente alta, puede preguntar antes de implementar o implementar algo que no era lo esperado. La calidad del output del agente es directamente proporcional a la calidad del input (el ticket). Invertir en escribir buenos tickets es la palanca más subestimada de este pipeline.

    ¿Se puede usar este pipeline sin Jira? ¿Con Linear, GitHub Issues u otras herramientas?
    Sí. Claude Code tiene MCPs para Linear, Asana y GitHub Issues. El principio es el mismo: el agente lee el ticket desde la fuente, extrae los criterios de aceptación y los usa como guión de implementación y testing. La integración específica depende del MCP disponible para cada herramienta.

    ¿Es seguro dejar que el agente tenga acceso a la base de datos o a servicios externos durante el testing?
    No. El testing del agente debe hacerse contra un entorno de desarrollo o staging, nunca contra producción ni contra una base de datos con datos reales. El CLAUDE.md debe especificar explícitamente contra qué entorno corre el agente y qué permisos tiene. El principio de mínimos privilegios aplica igual para agentes que para cualquier proceso automatizado.

    ¿Cuánto tiempo lleva montar este pipeline desde cero?
    El pipeline mínimo (CLAUDE.md + MCP GitHub + PR automático) puede estar funcionando en un día. El pipeline completo con MCP de Jira, MCP de Chrome y code review automático lleva entre una semana y dos de ajuste para que funcione de forma estable en un proyecto real. La mayor parte del tiempo se va en escribir un CLAUDE.md completo y en afinar los prompts para que el agente entienda las convenciones del proyecto.

    Si quieres aprender a construir con IA desde cero hasta producción, echa un vistazo al curso Construye con IA.

    Por Bezael Pérez — Developer senior con más de 15 años de experiencia y fundador de Dominicode.

  • MCP server para empresas: por qué necesitas el tuyo en 2026

    MCP server para empresas: por qué necesitas el tuyo en 2026

    Un cliente llega a tu empresa con su propio agente de IA. Ha construido workflows con Claude, con GPT-4o, con lo que sea. Quiere que ese agente use tu plataforma — consultar datos, lanzar acciones, integrarse con lo que tú ya tienes.

    Tu equipo responde: “Tenemos una API REST. Aquí está la documentación.”

    El cliente asiente, se va, y dos semanas después vuelve con una lista de preguntas sobre autenticación, rate limits y por qué el agente no entiende el schema de tu respuesta. Tu equipo dedica tres sprints a construir un wrapper custom. El cliente queda satisfecho. Pero el siguiente cliente viene con el mismo problema. Y el siguiente.

    Ese es el problema que un MCP server para empresas resuelve de raíz.

    Qué es MCP y por qué importa ahora

    Si ya leíste MCP explicado para developers: conecta Claude a tus herramientas, tienes el contexto técnico. El resumen ejecutivo es este: MCP (Model Context Protocol) es el protocolo abierto que estandariza cómo los agentes de IA se comunican con herramientas y servicios externos. Lo creó Anthropic en noviembre de 2024. En menos de 18 meses alcanzó 97 millones de descargas mensuales del SDK.

    OpenAI lo adoptó en marzo de 2025. Microsoft en mayo, durante el Microsoft Build. La Agentic AI Foundation — con Anthropic, OpenAI, Google, AWS y Cloudflare como cofundadores — lo recibió bajo la Linux Foundation en diciembre de 2025. Ya no es el protocolo de Anthropic. Es el estándar del sector.

    Forrester predice que el 30% de los vendors de software empresarial lanzarán su propio MCP server en 2026. Si tu empresa tiene una API, ese porcentaje incluye a tu competencia. Puedes ver el listado oficial de MCP servers en el repositorio de la especificación.

    El problema de las integraciones N×M que un MCP server resuelve

    Antes de MCP, el problema era sencillo de enunciar e imposible de escalar: cada cliente que quería conectar su agente de IA a tu servicio necesitaba una integración custom. Tú necesitabas mantenerla. Ellos necesitaban documentarla para cada LLM que usaran.

    Un cliente con Claude, otro con GPT, otro con Gemini. Tres integraciones. Cinco clientes, quince integraciones. La complejidad crece de forma cuadrática.

    MCP colapsa esa matriz. Un server, muchos clientes. Cualquier agente compatible con MCP — Claude, Cursor, tu herramienta interna — puede usar tu servidor sin que tú ni tu cliente escriban una línea de código de integración adicional.

    Empresas con MCP server en producción: Stripe, Cloudflare, GitHub

    No es teoría. Hay empresas que ya tienen MCP servers en producción y que están redefiniendo cómo sus clientes interactúan con ellas.

    Cloudflare expone toda su API — más de 2.500 endpoints de Workers, R2, D1, DNS y Zero Trust — a través de un MCP server con solo dos herramientas: search() y execute(). Un agente puede desplegar un Worker, configurar un dominio o gestionar reglas de acceso sin que un humano abra el dashboard. Cloudflare no creó una integración por cada herramienta de IA. Creó un punto de entrada único.

    Stripe tiene un MCP server que permite a los agentes inspeccionar clientes, suscripciones, pagos y disputas. El caso de uso es claro: un agente de soporte o de análisis financiero puede consultar el estado de una transacción directamente, sin que alguien tenga que entrar al dashboard o llamar a la API manualmente.

    GitHub expone issues, pull requests y búsqueda de código. Los agentes de desarrollo — como Claude Code — pueden abrir issues, revisar PRs o buscar en el código base directamente desde el contexto de trabajo del desarrollador.

    Notion, Linear, Sentry, Asana y Atlassian convergen en el mismo patrón: un servidor MCP alojado en su propia infraestructura, protegido por OAuth, que cualquier agente compatible puede usar sin configuración adicional.

    El patrón que se está convirtiendo en referencia de la industria es el que estableció Cloudflare: un MCP server remoto alojado en Workers, expuesto como endpoint público, autenticado con OAuth. Stripe, Linear y Sentry siguieron exactamente ese camino.

    MCP server vs API REST: la diferencia que importa

    Dimensión API REST MCP Server
    Consumidor Un programador (o su código) Un agente de IA de forma autónoma
    Autodescripción Documentación externa (OpenAPI, etc.) Nombre, descripción y schema integrados
    Integración por cliente Una por LLM / plataforma Una sola, vale para todos los clientes MCP
    Mantenimiento N adaptadores en paralelo Un único punto de entrada
    Compatibilidad Depende del cliente Cualquier agente que soporte MCP

    La diferencia no está en el transporte HTTP — está en quién consume y cómo lo hace.

    Por qué esto es una ventaja competitiva, no solo una feature técnica

    Aquí está la tesis central de este post: exponer tu servicio como MCP server no es una integración más. Es posicionarte en la capa de infraestructura de los agentes de IA.

    En los próximos dos o tres años, los workflows empresariales se van a orquestar mediante agentes. Esos agentes van a conectarse con los servicios que estén disponibles en su ecosistema. Si tu empresa no está accesible vía MCP, tus clientes van a usar el servicio de tu competidor que sí lo está. No porque sea técnicamente superior — sino porque es el que el agente puede usar sin fricción.

    Piénsalo como los plugins de ChatGPT en 2023, pero con el soporte de toda la industria detrás y un estándar real. O como tener presencia en el App Store en 2010 — todavía temprano, todavía diferenciador.

    Las ventajas concretas son estas:

    1. Distribución sin esfuerzo de integración. Cualquier agente MCP-compatible puede usar tu server el día que lo publicas. Sin SDK propio. Sin documentación de integración por plataforma.

    2. Reducción drástica del coste de integración. Mantener un único MCP server en lugar de N adaptadores custom elimina la mayor parte del trabajo de integración. En la práctica, organizaciones que han estandarizado en MCP reportan reducciones superiores al 60% frente a conectores custom independientes.

    3. Posicionamiento como infraestructura. Los servicios que se convierten en infraestructura para otros tienen una tasa de churn históricamente baja. Si los workflows de tus clientes dependen de tu MCP server, la barrera de salida sube.

    4. Acceso al ecosistema de agentes sin inversión en partnerships. Cuando Cursor, Claude Code o cualquier nuevo cliente MCP busque herramientas disponibles, tu server ya estará ahí. No necesitas acuerdos con Anthropic ni con OpenAI para aparecer en su ecosistema.

    5. Datos de uso más ricos. Un MCP server te dice exactamente qué operaciones realizan los agentes de tus clientes, con qué frecuencia, con qué parámetros. Eso es señal de producto que una API tradicional no te da con la misma granularidad.

    6. Velocidad de adopción por parte de clientes técnicos. Los developers y los equipos de ingeniería que ya trabajan con agentes van a evaluar tu producto por si tiene MCP server. Es una señal de que entiendes el ecosistema en el que operan.

    Cuándo tiene sentido construirlo — y cuándo no

    No todo servicio necesita un MCP server hoy. Tiene sentido si se cumplen al menos dos de estas condiciones:

    • Tu API ya tiene clientes externos que la integran en sus workflows.
    • Tus clientes son developers o equipos técnicos que trabajan con agentes de IA.
    • Tienes operaciones discretas y definibles — acciones que un agente puede invocar con claridad.
    • Tu competencia ya está evaluando o construyendo el suyo.

    No tiene sentido si tu producto es puramente transaccional sin lógica de negocio expuesta, si tus clientes no tienen ninguna adopción de IA aún, o si tu API no está estabilizada. Un MCP server mal diseñado puede crear más fricción que eliminarla.

    La clave es pensar en términos de herramientas, no de endpoints. Un MCP server no expone rutas HTTP — expone acciones con nombre, descripción y schema de parámetros que un LLM puede entender sin documentación adicional.

    El momento es ahora, no en 2027

    En 12 meses, tener un MCP server no será una ventaja competitiva. Será la línea de base. Como tener una API REST en 2015 o estar en el App Store en 2012. Los que entraron antes construyeron workflows y convenciones que son difíciles de desplazar.

    El patrón de adopción de MCP sigue exactamente la curva que siguieron los SDKs de OAuth, los webhooks y las APIs GraphQL. Primero una empresa pionera. Luego los líderes del sector. Luego todos. El mercado está en la segunda fase.

    Si estás construyendo un producto con IA o evaluando cómo posicionar tu servicio en el ecosistema de agentes, en el curso Construye con IA trabajamos exactamente este tipo de decisiones arquitectónicas: desde la idea hasta el producto, con las herramientas que el sector ya usa en producción.

    Cómo empezar sin un proyecto completo

    El punto de entrada mínimo no es construir un MCP server completo. Es identificar las tres o cinco operaciones de tu API que más valor aportarían a un agente externo.

    Para Stripe, son: consultar cliente, listar pagos, ver disputa. Para Cloudflare, son: buscar recurso, ejecutar acción. Para tu empresa, probablemente sean las mismas operaciones que ya documentas como “casos de uso principales” en tu developer portal.

    El SDK oficial de MCP en TypeScript y Python tiene menos de 200 líneas para un servidor funcional. El coste de entrada es bajo. El coste de no entrar ahora es más alto de lo que parece.

    Si quieres explorar esto con más profundidad junto a otros developers que ya están construyendo con agentes, en Dominicode Labs tenemos recursos, proyectos y conversaciones activas sobre arquitectura MCP en producción.

    FAQ

    ¿Es MCP solo para empresas grandes como Stripe o Cloudflare?

    No. El SDK es open source, la implementación mínima es trivial y los casos de uso más interesantes están en productos medianos con APIs bien definidas. Las empresas grandes lo lanzaron antes porque tienen más exposición pública, no porque sea técnicamente más accesible para ellas. Una startup con una API limpia puede tener un MCP server en producción en días.

    ¿MCP funciona con todos los modelos de IA, no solo con Claude?

    Sí. Aunque MCP lo desarrolló Anthropic, OpenAI lo adoptó en abril de 2025 y Microsoft en julio de 2025. Hoy es un estándar de la industria bajo la Agentic AI Foundation (Linux Foundation). Cualquier cliente que implemente el protocolo — Claude, GPT, Cursor, tu agente interno — puede consumir tu MCP server sin cambios en el servidor.

    ¿Qué diferencia hay entre un MCP server y una API REST normal?

    Una API REST expone endpoints que un humano (o un código que alguien escribió) llama con parámetros concretos. Un MCP server expone herramientas con nombre, descripción semántica y schema de parámetros que un LLM puede interpretar, seleccionar y usar de forma autónoma dentro de un workflow. La diferencia no es en el transporte — es en que el consumidor es un modelo de lenguaje, no un programador.

    ¿Hay riesgos de seguridad al exponer un MCP server?

    Los mismos riesgos que tiene cualquier API expuesta: autenticación, autorización, rate limiting y auditoría. El patrón de referencia de la industria (Cloudflare, Stripe) usa OAuth 2.0 con tokens de acceso limitados al scope que el usuario autoriza. El MCP server no añade superficie de ataque nueva — la gestiona con el mismo modelo que ya usan las APIs modernas. Lo importante es no exponer herramientas destructivas sin confirmación explícita del usuario.

    ¿Necesito cambiar toda mi arquitectura para tener un MCP server?

    No. El MCP server es una capa adicional, no un reemplazo. Tu API REST sigue funcionando igual. El MCP server actúa como un adaptador que traduce las herramientas del protocolo a llamadas a tu API existente. En la mayoría de los casos es una capa delgada de 200-500 líneas de TypeScript o Python sobre lo que ya tienes.

    Por Bezael Pérez — Developer senior con más de 15 años de experiencia y fundador de Dominicode.

  • sdd-creator: genera spec, plan y tasks con cualquier agente IA

    sdd-creator: genera spec, plan y tasks con cualquier agente IA

    Llevaba tres horas implementando un sistema de autenticación con JWT cuando me di cuenta de que no había especificado nada.

    ¿El token debía expirar en la sesión o persistir entre reinicios? ¿Qué pasaba cuando el refresh token vencía estando el usuario activo? ¿El endpoint de logout invalidaba en servidor o solo limpiaba el cliente?

    Yo respondí esas preguntas sobre la marcha. Sin coherencia, sin registro de decisiones. El código resultó funcional pero arquitectónicamente un desastre.

    Eso no es un problema del agente. Es un problema de proceso. Para eso existe sdd-creator.

    El problema de codear sin especificar

    Los agentes de IA son extremadamente buenos ejecutando instrucciones. También son extremadamente buenos ejecutando instrucciones mal definidas — y el resultado es lo que imaginas.

    Cuando le das a Claude Code o a Cursor un prompt del tipo “implementa login con JWT”, el agente toma decisiones. Muchas. Las toma rápido, sin preguntarte, porque así trabajan. El output es código funcional que responde a una interpretación del problema, no necesariamente a tu interpretación.

    El fallo no está en la IA. Está en que nunca estableciste qué querías exactamente.

    Spec-Driven Development (SDD) resuelve esto con una premisa simple: antes de generar código, genera el spec. Un documento que responde qué hace la feature, por qué existe, quién la usa, qué flujos cubre y bajo qué criterios está terminada.

    El problema es que hacer bien un spec lleva disciplina. Y cuando tienes el agente abierto y las ganas de construir, la tentación de saltártelo es enorme.

    Qué es sdd-creator y cómo funciona

    sdd-creator es un skill para agentes de IA que impone el proceso de especificación antes de ejecutar cualquier implementación. No es un generador de documentos — es un interrogador. El agente no escribe código hasta que el spec esté completo y confirmado.

    A diferencia de pedirle directamente al agente que “genere un spec libre”, sdd-creator impone siempre las mismas 6 secciones y bloquea la implementación hasta recibir confirmación explícita. Sin esa estructura, los specs se convierten en párrafos de texto libre que el agente interpreta como quiere.

    El flujo tiene siete pasos:

    1. Describes el feature o proyecto que quieres construir
    2. sdd-creator detecta la complejidad (LOW / MEDIUM / HIGH)
    3. Te hace una entrevista interactiva — te pregunta lo que no especificaste
    4. Genera spec.md con 6 secciones estructuradas
    5. Espera tu confirmación antes de continuar
    6. Genera plan.md con las decisiones técnicas y la planificación por fases
    7. Genera tasks.md con las tareas ordenadas para TDD — y solo entonces empieza la implementación

    El repositorio está en GitHub: bezael/sdd-creator — MIT, v1.2.0.

    Si quieres entender la metodología detrás con más profundidad, el libro SDD cubre los principios completos, con patrones reales de proyectos en producción.

    Instalación

    Una sola línea:

    npx skills@latest add bezael/sdd-creator

    El CLI detecta tu herramienta y copia el skill al directorio correcto automáticamente. Como referencia, los directorios destino son:

    • Claude Code: ~/.claude/skills/
    • Cursor: .cursor/rules/ del proyecto

    No hay configuración adicional. No hay API keys. No hay dependencias de runtime. El skill vive como un archivo de instrucciones que el agente carga en contexto cuando lo invocas.

    Para instalación manual o integración con otros agentes, consulta la documentación oficial de Claude Code o los docs de tu herramienta.

    Tutorial paso a paso — feature de login con JWT

    Vamos con un ejemplo concreto. Tienes una app NestJS y quieres implementar autenticación con JWT. Sin sdd-creator, abres el agente y escribes: “implementa autenticación con JWT”. Con sdd-creator, el proceso es diferente.

    Paso 1 — Invoca el skill

    En Claude Code o en Cursor, activa sdd-creator. Luego describe tu feature:

    Quiero implementar un sistema de autenticación con JWT para una API NestJS.
Incluye registro, login, refresh de token y logout.

    Paso 2 — La entrevista interactiva

    sdd-creator detecta complejidad media y empieza a preguntarte:

    • ¿El token de acceso expira en cuánto tiempo?
    • ¿El refresh token se invalida en servidor o solo en cliente?
    • ¿El endpoint de logout invalida todos los dispositivos activos o solo el actual?
    • ¿La app requiere rate limiting en los endpoints de auth?
    • ¿Los usuarios pueden tener múltiples sesiones simultáneas?

    Preguntas incómodas. Preguntas que el agente habría respondido solo — con su mejor criterio — si no le hubieras forzado a preguntarte.

    Paso 3 — Confirmas el spec.md

    El agente genera el spec.md completo. Lo revisas, corriges lo que no cuadra, y confirmas. Solo entonces avanza.

    Paso 4 — plan.md y tasks.md

    sdd-creator genera el plan técnico (decisiones de arquitectura, librerías, estructura de módulos) y la lista de tareas ordenadas para TDD. Primero los tests de los casos de error — token expirado, credenciales inválidas, refresh token revocado. Luego el código que los hace pasar.

    Resultado: el agente implementa exactamente lo que especificaste. Sin sorpresas. Sin decisiones implícitas. Sin “lo hice así porque parecía razonable”.

    Los 3 archivos que genera

    spec.md — La especificación en 6 secciones

    La estructura es fija e invariable:

    1. Visión — qué problema resuelve y por qué existe esta feature
    2. Usuarios — quién la usa y cuáles son sus necesidades reales
    3. Funcionalidades — qué puede hacer el sistema (listado concreto)
    4. Flujos — cómo se comporta el sistema en los escenarios principales
    5. Arquitectura — cómo está organizado técnicamente
    6. NFRs — requisitos no funcionales: performance, seguridad, disponibilidad

    La estructura fija es deliberada. Cuando el spec siempre tiene las mismas 6 secciones, puedes revisarlo en segundos y saber exactamente qué falta. Un spec libre en prosa no tiene esa propiedad.

    Si quieres ver cómo aplicar estas 6 secciones en un proyecto greenfield completo, este post sobre SDD con slices verticales lo cubre en detalle.

    plan.md — Las decisiones técnicas

    El plan responde: ¿cómo vamos a construir esto? Librerías seleccionadas y por qué. Estructura de módulos. Fases de implementación. Dependencias entre componentes. Riesgos identificados.

    No es un documento académico — es el registro de las decisiones que tomarías antes de empezar, aunque fueran en tu cabeza. Externalizar ese razonamiento tiene valor: el agente lo usa como referencia durante la implementación, y tú lo usas para hacer review.

    tasks.md — La lista ordenada para TDD

    Las tareas están ordenadas para Test-Driven Development. Los tests de los contratos del sistema van primero. El código que los satisface, después. Cada tarea es atómica — una sola responsabilidad, verificable por sí sola.

    Cuando tienes esta lista, puedes darle una tarea al agente y pedirle que haga solo esa. Sin divagar. Sin añadir “mejoras” que no pediste. La tarea acotada, con su test, con su criterio de aceptación.

    Esta es exactamente la forma de trabajar que desarrollamos en el curso Construye con IA — de la idea al producto real, con agentes IA y sin perder el control del código.

    Cuándo NO usar sdd-creator

    sdd-creator añade valor cuando el problema tiene suficiente complejidad para merecer una especificación. Hay casos donde el overhead no compensa:

    • Scripts de un solo uso: automatizaciones de 20-30 líneas que se ejecutan una vez y se descartan
    • Prototipos desechables: experimentos para validar si algo es técnicamente posible, sin intención de iterar sobre el código
    • Hotfixes triviales: corregir un typo, cambiar un color, ajustar un literal de texto

    La regla práctica: si el feature va a producción y va a ser mantenido, usa sdd-creator. Si es exploración o descarte, ve directo al código.

    Compatible con cualquier agente de IA

    sdd-creator no está atado a un agente específico. Funciona con todos los entornos de desarrollo con IA más usados:

    Agente Tipo de integración Directorio
    Claude Code Skills nativo ~/.claude/skills/
    Cursor Rules .cursor/rules/ del proyecto
    Codex CLI (OpenAI) AGENTS.md / system prompt Configuración de proyecto
    Gemini CLI System prompt Configuración de proyecto
    Aider Contexto personalizado .aider.conf.yml
    Continue config.json .continue/

    El formato MIT también significa que puedes adaptarlo a tu equipo. Si tienes convenciones de nomenclatura propias, o secciones adicionales en tus specs, puedes forkear el repositorio y ajustarlo.

    FAQ

    ¿Qué es sdd-creator?

    sdd-creator es un skill para agentes de IA que implementa el flujo de Spec-Driven Development. Cuando lo activas, el agente no escribe código directamente — primero te hace una entrevista para entender el problema, luego genera tres documentos estructurados (spec.md, plan.md, tasks.md), y solo después implementa. Es la diferencia entre darle instrucciones a un agente y darle una especificación.

    ¿Con qué agentes de IA funciona sdd-creator?

    Con Claude Code, Cursor, Codex CLI (OpenAI), Gemini CLI, Aider y Continue. El skill es un archivo de instrucciones, no una integración específica — cualquier agente que soporte archivos de contexto puede usarlo. La instalación varía: en Claude Code se copia a ~/.claude/skills/, en Cursor va a .cursor/rules/.

    ¿Cuánto tiempo lleva generar la spec con sdd-creator?

    Entre 5 y 20 minutos, dependiendo de la complejidad del feature. Una feature simple puede especificarse en 5 minutos. Una feature con múltiples flujos, integraciones externas y requisitos de seguridad puede tomar 20. Ese tiempo es siempre menor que el que cuesta refactorizar código que el agente implementó sin especificación.

    ¿Es sdd-creator compatible con proyectos legacy?

    Sí. SDD no requiere empezar desde cero — puedes aplicarlo feature a feature sobre una base de código existente. El spec refleja las restricciones reales del sistema existente: qué puedes cambiar, qué no, y qué deuda técnica tienes que tener en cuenta durante la implementación.

    ¿Puedo usar sdd-creator en equipos?

    Sí, y es donde más valor aporta. El spec.md generado es el contrato de la feature — cualquier miembro del equipo puede revisarlo, cuestionarlo y aprobarlo antes de que empiece la implementación. Elimina el “yo entendí que…” de las reuniones de review.

    Ahora, cuando tengo el agente abierto y las ganas de construir, lo primero que activo es sdd-creator. Los 15 minutos de spec se pagan solos. Esas tres horas de JWT no se van a repetir.

    Si quieres ver cómo SDD encaja en el ciclo completo de desarrollo con IA — desde la idea hasta el producto desplegado — en Dominicode Labs tienes acceso a proyectos reales donde aplicamos este flujo de principio a fin.

    Por Bezael Pérez — Fundador de Dominicode.

  • Plan, Steer, Decompose: el framework de agentic engineering

    Plan, Steer, Decompose: el framework de agentic engineering

    Llevaba tres horas con el agente.

    Tres horas corrigiendo. El agente seguía haciendo lo mismo: tomaba decisiones razonables para el contexto que tenía, pero el contexto que tenía era incompleto desde el principio. Yo le daba feedback, él ajustaba, y en la siguiente iteración el problema aparecía en otro sitio. Dos pasos adelante, uno y medio atrás.

    No era el modelo. Era yo — y el problema era la ausencia de agentic engineering en mi flujo de trabajo.

    No había planificado lo que quería construir antes de empezar. No había descompuesto el problema en piezas que el agente pudiera manejar sin ambigüedad. Le había dado un objetivo vago y esperado que el agente lo resolviera. Y el agente hacía lo que podía — que no era suficiente para lo que yo necesitaba.

    Eso es lo que diferencia a alguien que usa agentic engineering de alguien que simplemente le pide cosas a la IA: un framework de trabajo. Un ciclo operativo que convierte la delegación caótica en colaboración sistemática.

    El framework tiene cinco pasos: Plan → Steer → Decompose → Delegate → Systematize.

    El agentic engineering es la disciplina de orquestar agentes de IA de forma sistemática — definiendo objetivos, descomponiendo problemas, delegando tareas con el contexto preciso y capturando los patrones que funcionan para reutilizarlos. Es la diferencia entre usar la IA como herramienta de texto y tratarla como un sistema de producción.

    Por qué el prompting no es suficiente

    Hay un malentendido que veo constantemente en developers que llevan meses usando IA sin resultados consistentes: creen que el problema es el prompt.

    Mejoran el prompt. Añaden más contexto. Usan few-shot examples. Prueban otro modelo. Y los resultados mejoran marginalmente pero el problema de fondo persiste — siguen obteniendo outputs que tienen que reescribir, completar o corregir antes de poder usar.

    El problema no es el prompt. Es que no hay agentic engineering en el proceso — están tratando al agente como un oráculo al que preguntas. Y los oráculos funcionan bien para respuestas, no para construcción.

    Construir con IA no es preguntar. Es orquestar. Y orquestar requiere un proceso, no una técnica de redacción.

    El framework de agentic engineering: los 5 pasos

    Paso Objetivo Señal de que lo estás haciendo bien
    Plan Define qué construir antes de abrir el editor Tienes objetivo, contexto y criterios de éxito escritos
    Steer Guía la dirección durante la ejecución Intervienes en los puntos de decisión, no en cada acción
    Decompose Rompe el problema en tareas atómicas y verificables Cada tarea tiene bordes claros, sin decisiones implícitas
    Delegate Asigna la tarea correcta con el contexto mínimo necesario El agente no necesita hacer preguntas para empezar
    Systematize Convierte lo que funciona en proceso repetible Tienes CLAUDE.md, templates y hooks activos

    1. Plan — Define antes de abrir el editor

    El Plan no es el prompt inicial. Es la decisión de qué quieres construir, para quién, con qué criterios de éxito, y qué contexto necesita el agente para no tener que improvisar.

    La mayoría de los problemas de agentic engineering empiezan aquí — o mejor dicho, por saltarse este paso.

    Cuando no hay Plan, el agente trabaja con hipótesis. Asume el stack que le parece más probable. Asume la arquitectura que ha visto más en su entrenamiento. Asume que los casos edge no existen porque no se los mencionaste. Y esas hipótesis se propagan a través de todo el trabajo posterior.

    Un Plan mínimo tiene tres elementos:

    Objetivo concreto — No "implementa el módulo de usuarios". Sí: "Implementa el endpoint POST /users que recibe { email, name }, valida con Zod, crea el registro en la tabla users de Supabase y devuelve { id, email, createdAt }. Error 409 si el email ya existe."

    Contexto relevante — El stack, las convenciones de naming que ya usa el proyecto, las decisiones de arquitectura tomadas, las restricciones conocidas. Esto es lo que va en el CLAUDE.md del proyecto — no como documentación, sino como memoria estructurada que el agente lee al inicio de cada sesión.

    Criterios de éxito — Cómo sabes que el agente terminó bien su trabajo. Tests que deben pasar. Comportamientos que debes poder demostrar. Sin criterios de éxito explícitos, "listo" significa cosas distintas para ti y para el agente.

    El Spec-Driven Development es la metodología que formaliza este paso: especificar el sistema antes de construirlo, con contratos concretos que el agente puede implementar sin inventar.

    2. Steer — Guías la dirección, no desapareces

    El Steer es el feedback loop activo durante la ejecución.

    Hay un patrón que veo repetidamente: el developer escribe un prompt elaborado, lanza el agente y vuelve veinte minutos después esperando encontrar la tarea completada. A veces funciona. Cuando no funciona, el agente ha pasado esos veinte minutos construyendo en la dirección equivocada con mucha confianza.

    Steer no significa microgestionar. Significa estar presente en los puntos de decisión que importan.

    La señal de que necesitas intervenir: el agente está a punto de tomar una decisión con consecuencias amplias sin haber pedido confirmación. Cambiar la estructura de un módulo. Renombrar una abstracción clave. Elegir entre dos arquitecturas posibles. Esos son los momentos en que tu presencia tiene más palanca.

    En práctica, Steer implica:

    • Revisar el output de las primeras iteraciones antes de que el agente avance demasiado
    • Corregir la dirección cuando el agente toma una decisión incorrecta — y hacerlo en el momento, no cuando ya hay diez archivos afectados
    • Hacer preguntas explícitas al agente sobre sus decisiones: "¿Por qué elegiste este enfoque sobre el alternativo?" — no para cuestionar todo, sino para verificar que el razonamiento es el correcto antes de comprometerte con esa dirección

    El objetivo del Steer no es hacer el trabajo del agente. Es hacer que el agente haga el trabajo correcto. Sin Steer, el agentic engineering se convierte en delegación ciega — y la delegación ciega escala los errores, no los resultados.

    3. Decompose — Rompe el problema en tareas atómicas

    La Decompose es donde más se gana en calidad de output y donde menos developers invierten tiempo.

    Un agente que recibe "implementa el sistema de autenticación completo" toma demasiadas decisiones implícitas. Qué estrategia de sesiones. Qué campos en el token. Cómo manejar el refresh. Qué pasa cuando el token expira durante una request. Cada una de esas decisiones tiene consecuencias, y el agente las toma sin consultarte porque no sabe que importan.

    La descomposición transforma decisiones implícitas en decisiones explícitas.

    Una tarea bien descompuesta tiene estas características:

    Atómica — Se puede completar en una sola sesión sin depender de otras tareas que no estén terminadas.

    Sin ambigüedad en los bordes — Define qué entra, qué sale y cómo interactúa con lo que ya existe. "Implementa el endpoint de login que recibe { email, password } y devuelve { accessToken, refreshToken, user } usando el servicio AuthService ya existente" — eso es una tarea sin ambigüedad en los bordes.

    Verificable — Al terminar puedes saber con certeza si la tarea está bien hecha o no. Si no puedes verificar, la tarea está mal definida.

    // Tarea mal definida — demasiado scope, demasiadas decisiones implícitas
// "Implementa el sistema de autenticación con JWT y manejo de sesiones"

// Tarea bien definida — atómica, verificable, bordes claros
// "Implementa la función generateTokenPair(userId: string): Promise<TokenPair>
// que genera accessToken (15min) y refreshToken (7d) firmados con RS256.
// TokenPair = { accessToken: string; refreshToken: string; expiresAt: Date }
// Usa la clave privada de process.env.JWT_PRIVATE_KEY.
// Test: genera un par, verifica que accessToken expira correctamente."

    La diferencia no está en la complejidad. Está en quién toma las decisiones.

    4. Delegate — Asigna al agente correcto con el contexto mínimo necesario

    Delegate es donde muchos developers confunden prompt engineering con delegación real.

    Prompt engineering es refinar las instrucciones para obtener un output mejor del mismo agente. La delegación dentro del agentic engineering es asignar la tarea correcta al agente correcto con el contexto que necesita para ejecutarla — ni más ni menos.

    Dos errores opuestos destruyen la delegación:

    Delegación sin contexto suficiente. El agente no tiene acceso a las decisiones de arquitectura previas, no conoce las convenciones del proyecto, no sabe qué existe ya. El resultado es código que no encaja — funcionalmente correcto, arquitecturalmente incorrecto.

    Delegación con contexto excesivo. Pegas en el prompt el README completo, los últimos cinco commits, tres archivos relacionados y la descripción del sistema entero. El modelo procesa todo ese contexto pero el ruido diluyente reduce la precisión. Más contexto no siempre es mejor contexto.

    El contexto mínimo necesario es el que responde a: ¿qué necesita saber el agente para tomar las mismas decisiones que yo tomaría? No el contexto que me tranquiliza a mí — el que necesita el agente.

    En Claude Code esto se traduce en ser deliberado sobre qué archivos mencionas explícitamente (@auth.service.ts, @user.schema.ts) y qué instrucciones incluyes en el CLAUDE.md del proyecto para que estén disponibles en cada sesión sin tener que repetirlas.

    5. Systematize — Lo que funciona una vez se convierte en proceso

    El Systematize es el paso que separa a los developers que mejoran semana a semana de los que repiten los mismos errores en cada proyecto nuevo.

    Cuando un flujo de trabajo de agentic engineering funciona bien — un tipo de tarea, un patrón de prompt, una estructura de descomposición — el Systematize lo captura como proceso reutilizable. No como documentación que nadie leerá. Como artefacto operativo que puedes invocar directamente.

    Tres formas concretas de systematizar:

    CLAUDE.md por proyecto — Las decisiones de arquitectura, las convenciones, las restricciones del proyecto. Este archivo es la memoria del proyecto que persiste entre sesiones. Sin él, cada sesión nueva parte de cero.

    Templates de tareas — Si descompones el mismo tipo de problema una y otra vez (endpoints REST, componentes Angular, tests de integración), el template captura la estructura de descomposición que ya demostró funcionar. No vuelves a pensar cómo descomponer — aplicas el template y ajustas los detalles.

    Hooks y workflows — En Claude Code, los hooks de PreToolUse y PostToolUse permiten ejecutar validaciones automáticas antes o después de que el agente actúe. Un hook que ejecuta tsc --noEmit antes de cada escritura de archivo previene que el agente introduzca errores de tipos que luego tienes que depurar a mano. Automatizas la verificación, no solo la generación.

    // .claude/settings.json — hook que valida TypeScript antes de escribir
{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Write|Edit",
        "hooks": [
          {
            "type": "command",
            "command": "npx tsc --noEmit 2>&1 | head -20"
          }
        ]
      }
    ]
  }
}

    El Systematize convierte el conocimiento tácito en proceso explícito. Y el proceso explícito escala — a proyectos futuros, a otros developers del equipo, a agentes que ejecutan workflows sin supervisión.

    Cómo se conectan los 5 pasos en un ciclo

    Los cinco pasos del agentic engineering no son lineales. Son un ciclo que se repite a dos escalas.

    Escala de proyecto:

    • Una vez al inicio: Plan global
    • Primera Decompose en bloques grandes
    • Primera ronda de Delegate al agente
    • Steer durante la ejecución
    • Systematize los patrones que funcionaron para el siguiente proyecto

    Escala de tarea:

    • Plan de la tarea concreta
    • Decompose en subtareas si es necesario
    • Delegate al agente con el contexto mínimo
    • Steer durante la ejecución
    • Systematize si el patrón vale la pena capturar

    Lo que conecta los dos niveles es el contexto acumulado. Cada Systematize en una tarea pequeña alimenta el Plan del bloque siguiente. El CLAUDE.md que actualizas después de cada sesión hace que la siguiente sesión parta de un estado mejor que la anterior.

    El ciclo se mejora a sí mismo. Eso es lo que distingue un sistema de una técnica.

    Aplica el framework construyendo un producto real

    Leer el framework es útil. Aplicarlo en un proyecto real con presión de tiempo y decisiones concretas es lo que lo hace tuyo.

    El Workshop Beyond Prompts (https://workshop.dominicode.com/) del 9 de julio es exactamente eso: 3 horas donde aplicamos el agentic engineering construyendo un producto real con Claude Code — de idea a producto deployado usando Plan → Steer → Decompose → Delegate → Systematize en vivo. No es una clase magistral. Es una sesión de trabajo donde tomas decisiones, te equivocas, corriges y sales con un sistema que puedes replicar.

    Si quieres prepararte antes del workshop, el curso Construye con IA: de la idea al producto con Claude Code cubre los fundamentos de agentic engineering con el mismo enfoque: criterio para cada decisión, no solo instrucciones que seguir.

    Y si quieres trabajar el framework con proyectos concretos en comunidad — revisar tu arquitectura, discutir las decisiones que no están claras, ver cómo otros developers aplican estos pasos — en Dominicode Labs hacemos exactamente eso semana a semana.

    FAQ

    ¿Cuál es la diferencia entre el agentic engineering y el Spec-Driven Development?

    SDD es la metodología que cubre en detalle el paso Plan — cómo especificar un sistema antes de construirlo, con contratos y criterios de éxito concretos. El framework de agentic engineering Plan → Steer → Decompose → Delegate → Systematize es más amplio: cubre todo el ciclo de trabajo con agentes, desde antes de escribir la spec hasta capturar los patrones que funcionaron para reutilizarlos. SDD y agentic engineering son complementarios — SDD es la respuesta detallada a "cómo hacer bien el Plan".

    ¿El agentic engineering funciona con cualquier herramienta de IA o solo con Claude Code?

    Los cinco pasos son agnósticos a la herramienta. La lógica de Plan, Steer, Decompose, Delegate y Systematize aplica igual si usas Claude Code, Cursor, Copilot o la API directamente. Lo que cambia son los artefactos concretos: en Claude Code el contexto persistente vive en CLAUDE.md y los hooks en .claude/settings.json; en Cursor vive en .cursor/rules/; en otros entornos en AGENTS.md. El framework es la estructura. Los artefactos son la implementación específica de cada herramienta.

    ¿Cuánto tiempo tarda implementar este framework en un proyecto que ya existe?

    Para un proyecto existente sin ningún sistema, el mínimo viable —un CLAUDE.md básico con el stack y las convenciones principales, más una primera descomposición del backlog pendiente— tarda entre dos y cuatro horas. No es un proceso de migración completa. Es añadir las piezas que hacen que cada sesión futura sea más efectiva que las anteriores. El Systematize es acumulativo — mejora con el tiempo, no requiere estar completo desde el día uno.

    ¿El paso Steer no anula el beneficio de la autonomía del agente?

    No. Steer es intervención en los puntos de decisión de alto impacto, no supervisión constante de cada acción. Un agente ejecutando tareas bien definidas puede trabajar durante decenas de ciclos sin necesitar tu input — eso es autonomía real. Steer te pide que estés presente cuando el agente enfrenta una bifurcación arquitectural, no cuando está implementando un endpoint que ya tiene todos los criterios claros. La diferencia práctica: Steer activo tarda minutos por sesión. Steer ausente puede costar horas de corrección cuando el agente ha tomado veinte decisiones incorrectas en cadena.

    ¿Por dónde empiezo si nunca he trabajado de forma estructurada con agentes?

    Empieza por el Plan y el Decompose. Son los dos pasos del agentic engineering que más impacto tienen en la calidad del output y los que más developers saltan. Coge una tarea concreta de tu backlog y antes de lanzar el agente escribe: objetivo específico, contexto relevante y criterios de éxito. Luego divídela en subtareas que tengan bordes claros. Esas dos prácticas solas van a mejorar notablemente la calidad de lo que obtienes. El resto del framework puedes añadirlo gradualmente.

    Por Bezael Pérez — Developer senior con más de 15 años de experiencia y fundador de Dominicode.