Tag: Agentes IA

  • Self-Improving Loop: Enseña habilidades a tu agente de IA

    Self-Improving Loop: Enseña habilidades a tu agente de IA

    Estaba cansado de tener que crear APIs e integraciones cada vez que quería que mi agente de IA resolviera un nuevo problema técnico en mi servidor. Cada vez que aparecía un error inédito en los logs, me tocaba sentarme a abrir el código, programar un script a medida en Python, testearlo localmente, hacer commit y volver a desplegar.

    El proceso era lento, repetitivo y manual. Es decir, todo lo contrario a lo que se supone que debe ser un sistema agéntico inteligente.

    Entonces decidí implementar el bucle de auto-aprendizaje en producción.

    La primera vez que falló una conexión a la base de datos, el agente me contactó por Telegram preguntando cómo repararlo. Le respondí con un comando simple en lenguaje natural. El agente levantó su entorno, ejecutó la orden, validó el resultado y escribió un script en su base de datos. Me respondió: "Entendido. Skill guardada para la próxima vez".

    Nunca más me volvió a molestar por esa caída. Hoy te quiero explicar en detalle cómo funciona el Self-Improving Loop en Hermes Agent y cómo puedes usarlo para que tus agentes programen sus propias herramientas.


    La anatomía del Bucle de Auto-Mejora

    En los frameworks tradicionales como LangChain o CrewAI, las herramientas (Tools) que tiene un agente son estáticas. Si no programaste una herramienta para leer archivos de Excel, el agente jamás podrá hacerlo.

    El Self-Improving Loop en Hermes Agent rompe este límite. Si el agente se encuentra con un problema para el cual no tiene herramientas asociadas, entra en un estado de espera y abre un canal conversacional con el desarrollador o administrador (por ejemplo, a través de Telegram o Slack).

    Este proceso sigue tres fases clave:

    1. La Solicitud de Instrucción: El agente detecta un fallo y te envía el contexto y los logs de error preguntando cómo proceder.
    2. La Validación en Sandbox: Cuando le indicas la solución (ej: "corre este comando para liberar el puerto"), el agente ejecuta la instrucción en su contenedor de Docker seguro para verificar que el código no da errores.
    3. La Auto-Redacción de la Skill: Si la validación es exitosa, el agente utiliza su modelo de lenguaje interno para empaquetar esa solución en una función reutilizable (una Skill), la guarda en su disco y la registra para futuros usos.

    Cómo se escribe y registra una Skill en caliente

    Una Skill en Hermes Agent no es un bloque de texto plano. Es un archivo de código estructurado y documentado (usualmente en Python o Node.js) que se guarda directamente en el volumen de almacenamiento persistente del agente.

    Por ejemplo, si le enseñas a tu agente a resetear un puerto bloqueado en Linux, el agente escribirá automáticamente un script en su carpeta de habilidades:

    # skills/reset_port.py
    import subprocess
    
    def reset_port(port_number):
        """
        Habilidad autogenerada para resetear puertos bloqueados.
        Llamada automáticamente cuando se detecta un puerto en uso.
        """
        try:
            cmd = f"fuser -k {port_number}/tcp"
            subprocess.run(cmd, shell=True, check=True)
            return f"Puerto {port_number} liberado con éxito."
        except Exception as e:
            return f"Error liberando el puerto: {str(e)}"
    

    La próxima vez que ocurra la caída, el agente no consultará al administrador ni le enviará una alerta. Escaneará sus Skills locales, identificará que reset_port es la herramienta idónea mediante búsqueda vectorial semántica y resolverá el incidente de forma 100% autónoma.

    Este tipo de flujos reactivos autogenerados son los que marcan la diferencia entre un script básico y la verdadera ingeniería agéntica de producción que enseñamos en el curso de Construye con IA.


    La importancia de la persistencia de datos

    Para que este bucle funcione en producción, tu contenedor del agente no puede ser efímero. Si destruyes el contenedor al actualizar tu servidor, el agente perderá todas las Skills que ha auto-programado a lo largo del tiempo.

    Por eso es vital mapear un volumen físico del servidor host a la carpeta /app/skills del agente, tal como detallamos en nuestro post sobre cómo configurar Docker Sandboxing en Hermes Agent. De esta forma, las nuevas capacidades de tu agente quedan blindadas contra reinicios y despliegues Git-Ops.


    Enseña a tu agente a trabajar por ti

    El objetivo final de la IA no es que pases todo el día chateando con ella en una ventana web. El objetivo es delegar tareas de largo recorrido para que el sistema se auto-corrija y aprenda mientras tú te enfocas en diseñar mejores especificaciones.

    En el nuevo [curso de Agentes IA Autónomos en Producción con Hermes Agent]([ENLACE PENDIENTE]) dedicamos una sección práctica completa a construir este bucle de auto-aprendizaje, permitiendo que tu agente DevOps de guardia amplíe sus herramientas de forma interactiva desde Telegram.

    Si quieres debatir sobre arquitectura de software y el futuro del desarrollo agéntico con otros ingenieros senior, te espero en Dominicode Labs.


    Preguntas Frecuentes (FAQ)

    ¿Qué es el Self-Improving Loop (Bucle de Auto-Mejora)?

    Es la capacidad nativa de Hermes Agent para generar, testear y almacenar nuevas herramientas de ejecución de forma dinámica en tiempo de ejecución. Permite que el agente pase de ser un sistema estático a un agente adaptativo que aprende de su experiencia y de la retroalimentación del programador.

    ¿Cómo aprende el agente a usar una nueva Skill?

    Cuando el agente guarda una nueva Skill, genera una descripción semántica de su funcionamiento. Antes de realizar cualquier acción posterior, el agente realiza una búsqueda vectorial para ver si el problema coincide con la descripción de alguna de sus Skills almacenadas, utilizándola si es pertinente.

    ¿Dónde se guardan las habilidades autogeneradas?

    Se guardan como archivos de script independientes en el directorio local /skills del agente. En producción, esta carpeta debe estar mapeada a un volumen persistente de Docker para asegurar que no se pierdan al reiniciar o actualizar el contenedor del agente.

    ¿Es seguro dejar que el agente escriba su propio código?

    Es seguro siempre que se cumplan dos reglas críticas: primero, que el código se ejecute y valide en un sandbox aislado (Docker Container); segundo, que el agente exija aprobación en dos pasos del administrador antes de aplicar cualquier Skill correctiva que involucre escrituras o borrados en el servidor real.


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

  • Cómo correr LLMs locales en 2026: Guía de hardware y modelos

    Cómo correr LLMs locales en 2026: Guía de hardware y modelos

    El mes pasado vi la factura de API de OpenAI de un desarrollador independiente que estaba probando un agente de traducción automática de bases de datos. Había consumido $842 USD en un solo fin de semana debido a un bucle infinito de prompts que devoró el contexto de su modelo repetidamente.

    Casi le da algo.

    La experimentación con agentes de IA es el futuro, pero depender ciegamente de APIs en la nube puede ser una ruina financiera para desarrolladores independientes o empresas con políticas estrictas de privacidad.

    Hoy te quiero explicar cómo configurar tu entorno para correr LLMs locales en 2026, analizando qué hardware necesitas realmente y qué modelos de código abierto superan a las opciones comerciales para desarrollo local.


    Por qué el desarrollo local es el estándar en 2026

    Hasta hace poco, correr un modelo en tu propio ordenador era una experiencia frustrante: los modelos pequeños de 7B parámetros eran lentos, "alucinaban" demasiado y carecían de capacidades de razonamiento para escribir código complejo.

    En 2026, la situación ha cambiado radicalmente por tres factores:

    1. Eficiencia en la cuantización: Gracias a formatos avanzados de compresión (como GGUF y EXL2), un modelo de 8B o 14B parámetros mantiene el 98% de su precisión consumiendo la mitad de VRAM.
    2. Capacidad de razonamiento nativa: Modelos como Llama 3.3, Qwen 2.5 Coder y la serie DeepSeek R1 en local ofrecen razonamiento avanzado sin salir de tu máquina.
    3. Privacidad absoluta: Tus datos de código, logs de clientes y bases de datos nunca viajan por internet.

    Correr modelos locales es la mejor forma de testear tus agentes y automatizaciones antes de desplegarlos a producción en la nube.


    El Hardware que necesitas (VRAM es el único rey)

    El error más común al planificar un entorno local de IA es invertir en procesadores rápidos (CPU) o grandes cantidades de memoria RAM convencional. Para la IA, la velocidad del procesamiento y la latencia dependen de la VRAM (Memoria de Vídeo) de tu tarjeta gráfica.

    Aquí tienes la matriz de hardware recomendada según tu presupuesto y objetivos en 2026:

    Nivel Hardware Mínimo Capacidad de Modelos
    Básico (Estudiante) GPU de 8GB VRAM (RTX 4060) o Mac M-Series (16GB RAM) Llama 3.2 3B / Qwen 2.5 Coder 7B (Cuantizados)
    Sweet Spot (Developer) GPU de 16GB VRAM (RTX 4080 / 4070Ti) o Mac M-Series (36GB RAM) Llama 3.1 8B / Qwen 2.5 Coder 14B (Precisión Completa)
    Avanzado (Enterprise) 2x GPU de 24GB VRAM (RTX 3090/4090) o Mac Studio (64GB+ RAM) Llama 3.3 70B / DeepSeek R1 32B (Razonamiento Completo)

    Si eres usuario de Mac, la memoria unificada de Apple Silicon funciona como VRAM. Un Mac Mini o Macbook Pro con 36GB o 64GB de RAM unificada es una de las soluciones más eficientes y silenciosas para correr agentes locales.


    Los mejores modelos locales para Developers en 2026

    Si tu objetivo principal es escribir código, configurar bases de datos o crear agentes DevOps, no uses modelos genéricos. Estos son los reyes del código abierto en 2026:

    • Qwen 2.5 Coder (7B y 14B): Es el rey indiscutible para autocompletado y edición en IDEs como Cursor o VS Code. Supera a muchos modelos propietarios en sintaxis de TypeScript, Python y Rust.
    • Llama 3.1 (8B) / Llama 3.3 (70B): La opción de Meta es la más estable para agentes conversacionales que requieren memoria semántica persistente o integrarse con herramientas externas.
    • DeepSeek R1 (Versiones destiladas de 8B o 14B): Excelente para resolución de bugs complejos y optimización de algoritmos que requieren pasos de pensamiento lógico antes de emitir una respuesta.

    Setup de Arranque Rápido con Ollama

    La forma más sencilla de empezar hoy es utilizar Ollama, una herramienta que gestiona los modelos locales en segundo plano y expone una API compatible con OpenAI para que puedas conectarla a cualquier aplicación.

    1. Descarga Ollama de su sitio oficial.
    2. Ejecuta en tu terminal el modelo deseado:
      ollama run qwen2.5-coder:7b
      
    3. Conecta tus agentes o herramientas de desarrollo apuntando la API Base a: http://localhost:11434/v1.

    Este es exactamente el flujo de base local que enseñamos a configurar y optimizar en nuestro curso de Construye con IA para evitar costes recurrentes de API durante el desarrollo de productos.


    Conclusión: Controla tus costes de desarrollo

    Depender exclusivamente de la nube no solo te hace vulnerable a caídas de red y cambios de precios de API, sino que limita tu velocidad de experimentación. Al aprender a correr LLMs locales, desbloqueas pruebas infinitas y seguras, las cuales son ideales para testear el bucle agéntico o agentic loop sin costes de API.

    Si quieres debatir sobre configuraciones de hardware personalizadas, benchmarks de modelos en local y cómo conectar estos LLMs a tus pipelines de producción, te espero en Dominicode Labs.


    Preguntas Frecuentes (FAQ)

    ¿Se pueden correr LLMs locales en 2026 sin tarjeta gráfica (GPU)?

    Sí, herramientas como Ollama y Llama.cpp admiten ejecución en CPU utilizando la memoria RAM del sistema. Sin embargo, la velocidad de generación (tokens por segundo) será extremadamente lenta en comparación con una GPU, lo que los hace poco prácticos para flujos de desarrollo ágiles.

    ¿Qué es la cuantización de un modelo de IA?

    Es un proceso de compresión matemática que reduce la precisión de los pesos del modelo (por ejemplo, de 16 bits a 4 u 8 bits). Esto reduce drásticamente el uso de VRAM y memoria, permitiendo correr modelos grandes en tarjetas gráficas de gama media con una pérdida de precisión casi imperceptible.

    ¿Ollama es compatible con herramientas como Cursor o VS Code?

    Sí, Ollama expone un servidor local compatible con la especificación de API de OpenAI. Puedes configurar tu editor de código o framework de agentes favorito para que use la URL http://localhost:11434 como proveedor personalizado y consuma tus modelos locales de forma directa.

    ¿Qué modelo local es mejor para desarrollo de software en 2026?

    Para autocompletado y redacción de código rápido, Qwen 2.5 Coder (en sus variantes de 7B o 14B) ofrece el mejor rendimiento en relación al consumo de recursos. Para tareas complejas de depuración o lógica pesada, las variantes cuantizadas de DeepSeek R1 son la opción recomendada.


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

  • Hermes Agent: Cómo capturar y calificar leads de forma autónoma

    Hermes Agent: Cómo capturar y calificar leads de forma autónoma

    Hace unos meses, un domingo por la tarde, me di cuenta de que mi bot de Telegram había calificado a tres desarrolladores interesados en entrar a Dominicode Labs. No solo respondió a sus dudas técnicas sobre el stack de la comunidad, sino que guardó sus datos en mi base de datos de Notion y me envió un resumen limpio por correo a las 8:00 PM.

    Yo estaba cenando con mi familia. El bot hizo el 80% del trabajo de captación de forma autónoma.

    La mayoría de los marketers y creadores de contenido siguen perdiendo el tiempo configurando integraciones complejas en Zapier que se rompen constantemente, o usando chatbots interactivos de árbol de decisión que aburren a cualquiera en dos segundos.

    Hoy te quiero explicar cómo utilizar Hermes Agent en marketing para dejar atrás las herramientas rígidas y poner a funcionar agentes de IA que capturan, califican e informan sobre prospectos de forma autónoma las 24 horas del día. En mi post anterior te hablé de qué es Hermes Agent y cómo funciona su bucle de auto-aprendizaje, pero hoy nos enfocaremos puramente en negocio.


    El problema de los “chatbots de marketing” tradicionales

    Los chatbots tradicionales de marketing funcionan con flujos rígidos: “Si el usuario pulsa A, muestra B”. Son frustrantes para el usuario porque no toleran variaciones y se rompen en cuanto alguien hace una pregunta fuera del guión.

    Por otro lado, los frameworks de IA tradicionales (como conectar simplemente la API de OpenAI a un webhook) no tienen memoria persistente. Si el usuario vuelve al día siguiente, el sistema no recuerda lo que hablaron, obligándolo a empezar de cero.

    Utilizar Hermes Agent en marketing cambia las reglas del juego gracias a dos pilares fundamentales: memoria multi-usuario persistente y protocolo MCP (Model Context Protocol).

    Calificación conversacional sin formularios

    Nadie quiere rellenar un formulario de 10 campos para ver si tu producto encaja con lo que busca. Pero a todo el mundo le gusta hablar con un sistema inteligente que responda al instante.

    Con Hermes Agent, puedes programar al agente para que mantenga una conversación fluida sobre las necesidades del usuario. A medida que chatea, el agente extrae información de valor de forma natural:

    • El stack tecnológico del prospecto
    • El tamaño de su proyecto o presupuesto
    • Su principal problema actual

    En lugar de forzar un interrogatorio, el agente califica al lead mientras responde sus dudas reales sobre tu plataforma o servicio.

    Sincronización en caliente vía MCP (Model Context Protocol)

    Una vez que el agente ha recopilado el perfil del usuario, no necesitas complicados flujos de automatización externos. A través de la integración nativa del estándar abierto Model Context Protocol (MCP) de Hermes Agent con Notion, el agente escribe directamente en tu CRM o base de datos.

    Aquí tienes una muestra de cómo se configura el flujo de almacenamiento en Notion dentro del entorno de Hermes:

    {
      "tools": [
        {
          "name": "notion-mcp-server",
          "command": "npx -y @modelcontextprotocol/server-notion",
          "env": {
            "NOTION_API_KEY": "tu_api_key",
            "NOTION_DATABASE_ID": "tu_db_id"
          }
        }
      ]
    }
    

    El agente decide de forma autónoma cuándo ha recogido suficientes datos del prospecto para activar la herramienta de Notion y registrar la fila con los datos limpios y estructurados.


    El Bucle de Venta y Calificación Autónoma

    Imagina este flujo operando en tu canal de soporte o comunidad de Telegram:

    1. Interacción Inicial: Un usuario pregunta en Telegram si tu curso cubre despliegues en Railway.
    2. Consulta a la Base de Conocimientos: El agente lee tu catálogo de productos y le explica qué módulos cubren Railway.
    3. Calificación: El agente le pregunta qué tipo de aplicaciones quiere desplegar.
    4. Registro: El usuario responde y el agente registra el lead en Notion como “Interés en DevOps/Railway”.
    5. Briefing diario (Cron): A las 9:00 PM, una tarea programada interna de Hermes te envía un correo a ti (el administrador) con la lista de leads cualificados listos para el seguimiento comercial.

    Esta arquitectura de agentes de marketing no solo ahorra horas de gestión manual, sino que mejora drásticamente la tasa de conversión al dar respuestas de alto nivel técnico al instante. Esta es la potencia que enseñamos a construir en el curso de Construye con IA, aplicando IA a la resolución de problemas de negocio reales.


    Da el salto a la automatización agéntica

    Dejar que una IA interactúe con tus clientes potenciales puede dar cierto vértigo al principio. Por eso Hermes Agent incluye sandboxes locales y la opción de configurar alertas interactivas para que el agente te pida confirmación antes de enviar ciertos mensajes o realizar acciones críticas.

    En el próximo [curso de Agentes IA Autónomos en Producción con Hermes Agent] dedicamos una sección entera a construir este Operador Autónomo de Comunidad, conectándolo a Telegram y Notion paso a paso.

    Si quieres debatir con otros ingenieros de software sobre cómo implementar estos sistemas agénticos para capturar leads y escalar operaciones en tus propios proyectos, te espero en Dominicode Labs.


    Preguntas Frecuentes (FAQ)

    ¿Cómo ayuda Hermes Agent en marketing y ventas?

    A diferencia de los chatbots interactivos sencillos, Hermes Agent gestiona conversaciones completas con memoria a largo plazo. Puede responder dudas técnicas sobre tus productos, calificar a los prospectos haciendo preguntas contextuales y guardar automáticamente sus perfiles en herramientas como Notion sin necesidad de usar Zapier.

    ¿Qué ventajas tiene el uso de MCP (Model Context Protocol) en marketing?

    El protocolo MCP permite al agente conectarse directamente a bases de datos, repositorios de contenido o herramientas de mensajería usando un estándar seguro y unificado. Esto significa que tu agente de marketing puede consultar en tiempo real tus guías de producto o actualizar tu base de datos de leads de forma nativa.

    ¿Se puede configurar el agente para que trabaje en varios canales como Telegram y Discord?

    Sí. Al desacoplar la lógica del agente del canal de mensajería, Hermes Agent puede usar el mismo motor conversacional y base de conocimiento para atender usuarios en Telegram, Discord o mediante un chat embebido en tu web, manteniendo la consistencia de la información.

    ¿El agente puede enviar informes o briefings comerciales automáticamente?

    Sí, Hermes Agent cuenta con un planificador de tareas Cron integrado. Esto te permite programar al agente para que realice tareas offline, como recopilar todos los prospectos calificados del día y enviarte un resumen detallado por email o Slack a una hora fija todas las noches.


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

  • Hermes Agent: Por qué los chatbots ya no bastan en producción

    Hermes Agent: Por qué los chatbots ya no bastan en producción

    Hace unas semanas dejé corriendo un script para monitorear una base de datos en Railway. A las 3:00 AM la base de datos se cayó debido a un pico de memoria. El sistema clásico me habría enviado una alerta al móvil despertándome. Pero yo no quería una alerta a esa hora; quería que se solucionara.

    El problema con los chatbots tradicionales y los scripts de juguete es que son pasivos y no tienen memoria real a largo plazo ni capacidad de ejecución autónoma. Se quedan bloqueados esperando que un humano les diga qué hacer, o simplemente repiten el mismo error una y otra vez.

    Ahí es donde entra la verdadera IA agéntica y frameworks como Hermes Agent. Con un agente autónomo de larga duración (Long-Running Autonomous Agent) operando en un bucle agéntico o agentic loop, el sistema no solo detecta el fallo: levanta un sandbox, diagnostica el problema y, si es necesario, aprende cómo arreglarlo para la próxima vez.

    Hoy te quiero hablar en detalle de este framework de código abierto (desarrollado con la colaboración del equipo de Nous Research) que está cambiando las reglas del juego al permitir crear agentes que realmente operan de forma autónoma las 24 horas del día.


    ¿Qué hace diferente a Hermes Agent?

    Si has intentado crear agentes con frameworks como LangChain o CrewAI, te habrás dado cuenta de que están diseñados para responder preguntas en un bucle síncrono. Están muy bien para flujos sencillos, pero fallan en producción por tres motivos:

    1. Carecen de autonomía real de largo recorrido: No pueden correr en segundo plano esperando eventos o triggers temporales (Crons).
    2. Su memoria es efímera: Si se reinicia el servidor, el agente olvida todo lo que ha aprendido o discutido con los usuarios.
    3. No pueden aprender solos: No generan nuevas capacidades a partir de su experiencia.

    Hermes Agent soluciona esto de raíz mediante una arquitectura diseñada específicamente para ejecutarse en entornos como Docker, VPS o plataformas de nube como Railway.

    El Bucle de Auto-Mejora (Self-Improving Loop)

    La característica más potente de Hermes Agent es su capacidad de auto-mejora. En lugar de limitarse a usar las herramientas que el programador le define estáticamente, Hermes puede crear nuevas Skills (habilidades) dinámicamente.

    Imagina que tu agente DevOps de auto-sanación encuentra un error inédito en los logs de producción. Al no saber cómo solucionarlo, te envía un mensaje por Telegram: “Detectado error X en Railway. No tengo herramientas para solucionarlo. ¿Cómo procedo?”

    Tú le respondes con la solución o el comando a ejecutar. El agente ejecuta la orden dentro de un sandbox seguro de Docker para validar que funciona. Pero lo más importante: escribe un script (una nueva Skill), lo guarda en su base de datos y lo registra.

    La próxima vez que ocurra ese error exacto, el agente no te preguntará. Usará la Skill que él mismo generó y resolverá el problema de forma autónoma. Esta es exactamente la lógica que exploramos en profundidad en el curso de Construye con IA para pasar de simples prompts a automatizaciones reales.

    Memoria persistente multi-capa

    Un agente autónomo en producción necesita recordar quién eres, qué problemas ha resuelto y qué configuraciones ha cambiado en el servidor.

    Hermes implementa un sistema de almacenamiento persistente en disco (o volúmenes de Docker). Esto permite que, aunque el contenedor se reinicie o se actualice mediante Git-Ops en Railway, el agente no sufra de “amnesia”. Mantiene:

    • Memoria episódica: Registros de ejecuciones pasadas y sus resultados.
    • Memoria semántica: Una base de conocimiento vectorial que consulta antes de tomar decisiones complejas.
    • Memoria de conversación: El historial exacto con cada usuario, ideal para canales como Telegram o Discord.

    Cómo estructurar un Agente de Auto-Sanación

    Para que un agente opere de manera segura en tu infraestructura, nunca debes darle acceso directo al sistema operativo anfitrión. Hermes Agent utiliza Docker Sandboxes por defecto.

    Aquí tienes un flujo conceptual de cómo se define la configuración de un agente autónomo de diagnóstico con Hermes:

    {
      "agent": {
        "name": "DevOpsGuard",
        "model": "anthropic/claude-3-5-sonnet",
        "sandbox": {
          "provider": "docker",
          "image": "node:20-alpine",
          "volumes": ["/var/run/docker.sock:/var/run/docker.sock"]
        },
        "persistence": {
          "path": "./data/memory"
        }
      }
    }
    

    Al iniciarse, el agente arranca el contenedor Docker. Cada vez que necesite ejecutar un comando de diagnóstico (como un ping, un script de Node.js o una query a la base de datos), lo hará de forma aislada dentro de ese contenedor. Si el script falla o hace algo inesperado, tu servidor principal sigue estando 100% a salvo.


    El futuro es de los agentes de largo recorrido

    El desarrollo de software con IA ha dejado atrás los simples chats interactivos. Si quieres ir más allá de los juguetes y construir sistemas que operen, monitoricen y solucionen problemas de forma autónoma en Railway o en tu propio VPS, necesitas entender este cambio de paradigma.

    Pronto lanzaremos el nuevo [curso de Agentes IA Autónomos en Producción con Hermes Agent], donde construiremos paso a paso un operador de comunidad en Telegram conectado a Notion mediante MCP y un agente de guardia DevOps que se auto-sana.

    Si quieres empezar a aplicar estas arquitecturas agénticas avanzadas hoy mismo en tus proyectos y discutir estos patrones con otros developers senior, te espero en Dominicode Labs.


    Preguntas Frecuentes (FAQ)

    ¿Qué es Hermes Agent y quién lo desarrolla?

    Hermes Agent es un framework de código abierto desarrollado originalmente con la colaboración del equipo de Nous Research. Está diseñado específicamente para construir agentes de IA autónomos de largo recorrido (Long-Running Autonomous Agents) que poseen memoria persistente y la capacidad de adquirir nuevas habilidades.

    ¿Cómo funciona el Bucle de Auto-Mejora (Self-Improving Loop) en Hermes?

    Funciona combinando la interacción del agente con el entorno y la retroalimentación del desarrollador. Cuando el agente se enfrenta a una tarea para la cual no tiene una herramienta predefinida, puede recibir instrucciones en lenguaje natural, probar la solución en un entorno aislado, empaquetar esa solución en un script de código (Skill) y guardarlo en su almacenamiento persistente para futuras ocasiones.

    ¿Por qué se utiliza Docker Sandbox en la ejecución de agentes?

    Se utiliza por motivos de seguridad y control de entorno. Los agentes autónomos pueden generar y ejecutar código en tiempo real. Ejecutar este código dentro de un contenedor Docker aislado (sandbox) garantiza que cualquier fallo, script infinito o acción no deseada no afecte al servidor principal ni ponga en riesgo la infraestructura del sistema.

    ¿Es Hermes Agent adecuado para entornos de producción DevOps?

    Sí, gracias a su integración con APIs de infraestructura (como Railway o Kubernetes), su soporte nativo para volúmenes Docker persistentes y su programador de tareas Cron integrado. Esto lo hace ideal para tareas continuas como monitoreo de logs, auto-sanación de servicios caídos e informes diarios de estado.


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

  • 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 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.

  • 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 Fable 5 vuelve: qué pasó y qué cambia para developers

    Claude Fable 5 vuelve: qué pasó y qué cambia para developers

    El 12 de junio de 2026, Anthropic apagó Claude Fable 5 de golpe.

    Sin aviso previo. Sin fecha de vuelta. Sin explicación técnica completa. El modelo que llevaba apenas tres días disponible desapareció para todos los usuarios del planeta — Europa, Latinoamérica, Asia, todos — porque el gobierno de EE.UU. no podía verificar nacionalidades en tiempo real y decidió cortar el acceso global en lugar de arriesgarse.

    Ese mismo día, developers de medio mundo abrieron Claude.ai y encontraron un modelo degradado. Los que habían empezado a construir pipelines con Fable 5 tuvieron que pivotar sobre la marcha. Y los que llevábamos años viendo cómo la IA maduraba como industria recibimos un recordatorio brutal: cuando un modelo tiene capacidades que un Estado considera amenaza para la seguridad nacional, el interruptor lo tiene el Estado, no Anthropic.

    Hoy, 1 de julio de 2026, Claude Fable 5 vuelve. Y la historia de cómo llegamos hasta aquí dice más sobre el futuro de la IA que cualquier benchmark.


    Lo que pasó: el jailbreak que lo cambió todo

    Investigadores de Amazon descubrieron una técnica que permitía a Fable 5 identificar vulnerabilidades en software y, en al menos un caso documentado, demostrar cómo explotarlas. El gobierno de EE.UU. reaccionó con rapidez: el mismo día 12 de junio, el Departamento de Comercio aplicó controles de exportación de emergencia que afectaron tanto a Fable 5 como a Mythos 5.

    La tensión entre ambas partes fue pública. El gobierno argumentó que el problema podría haberse corregido antes de la suspensión. Anthropic respondió que la técnica era más estrecha y específica de lo que la orden de emergencia implicaba — no una vulnerabilidad sistémica, sino un vector concreto que requerirían semanas de investigación para reproducir.

    El debate sobre la severidad real del jailbreak sigue abierto. El resultado fue inequívoco: controles de exportación de emergencia, suspensión global, y Anthropic sin poder verificar la nacionalidad de sus usuarios en tiempo real.

    No había otra salida. Apagaron todo.


    Fable 5 y Mythos 5: la diferencia que importa

    Aquí hay un matiz que mucha cobertura mediática perdió.

    Mythos 5 es la denominación interna de los modelos con capacidades cibernéticas más avanzadas que Anthropic ha construido jamás — superiores a cualquier otro modelo del mercado en ese dominio. Tras la suspensión, Anthropic decidió que Mythos 5 solo estará disponible para socios del Proyecto Glasswing, un programa de ciberseguridad defensiva con acceso controlado y supervisión directa.

    Fable 5 es diferente. Es el modelo de propósito general que se lanza hoy con los salvaguardas más fuertes que Anthropic ha implementado en ningún modelo de su historia. Anthropic afirma explícitamente que Fable 5 "no proporciona capacidades ofensivas únicas" — es decir, no hace nada que un atacante sofisticado no pudiera hacer con las herramientas que ya existen.

    Fable 5 Mythos 5
    Propósito General (razonamiento, código, escritura) Ciberseguridad avanzada
    Acceso Público (planes de pago) Solo Proyecto Glasswing
    API pública ✅ Sí ❌ No
    Capacidades ofensivas No únicas respecto a herramientas existentes Superiores a cualquier otro modelo del mercado

    La distinción es importante para cualquier developer que esté construyendo con la API. No estás usando Mythos 5. Estás usando Fable 5, que ha pasado por una revisión de seguridad que ningún modelo anterior había tenido.


    Qué cambió en Claude Fable 5: los nuevos salvaguardas

    Anthropic no volvió con el mismo modelo. Volvió con un clasificador de seguridad reentrenado específicamente para detectar y bloquear la técnica descrita en el reporte de Amazon.

    Según el anuncio oficial de Anthropic, el nuevo clasificador bloquea el comportamiento problemático en más del 99% de los casos. Cuando se activa, la solicitud no falla en silencio — se redirige automáticamente a Claude Opus 4.8. El usuario recibe respuesta, pero sin las capacidades que generaron el problema.

    El mecanismo de defensa tiene tres capas:

    1. El entrenamiento base del modelo, que ya rechaza asistencia con solicitudes peligrosas.
    2. Un clasificador específico para el patrón de jailbreak identificado por Amazon.
    3. Un margen de seguridad ampliado — Anthropic subió el umbral de bloqueo de forma deliberada, asumiendo más falsos positivos para reducir el riesgo de usos maliciosos.

    Ese tercer punto es el que más impacta a developers en producción. Más falsos positivos significa que algunas solicitudes legítimas relacionadas con ciberseguridad, análisis de código o auditoría de vulnerabilidades van a llegar a Opus 4.8 en lugar de Fable 5. No es un bug. Es una decisión consciente de arquitectura de seguridad.

    El Departamento de Comercio de EE.UU. verificó los salvaguardas y los calificó de "extraordinariamente fuertes". El 30 de junio levantó los controles de exportación. El 1 de julio, Fable 5 vuelve.


    Disponibilidad desde hoy: lo que necesitas saber

    La reactivación es global desde el 1 de julio en Claude.ai, Claude Platform, Claude Code y Claude Cowork.

    AWS, Google Cloud y Microsoft Foundry se reactivarán "lo antes posible" — sin fecha concreta confirmada.

    Hay un período de transición con límites temporales:

    • Hasta el 7 de julio: planes Pro, Max, Team y empresas seleccionadas tienen acceso a Fable 5 con hasta el 50% de sus límites de uso semanal habituales.
    • Después del 7 de julio: disponible mediante créditos de uso, sin restricción porcentual.

    Si estás en el plan gratuito, no hay cambios respecto a antes de la suspensión. Fable 5 era y sigue siendo acceso de pago.

    Para los que construimos con la API de Anthropic, el modelo vuelve a estar disponible desde hoy. Si tenías pipelines configurados con Fable 5 antes del 12 de junio, probablemente ya están activos de nuevo. Verifica tu dashboard y el comportamiento del clasificador con tus casos de uso específicos — especialmente si tienes prompts relacionados con análisis de código o seguridad.


    El nuevo marco de evaluación de jailbreaks

    Lo más interesante de lo que Anthropic publicó esta semana no son los salvaguardas. Es el marco que proponen como estándar industrial para evaluar la severidad de un jailbreak.

    Cuatro criterios:

    1. Ganancia de capacidad. ¿Cuánto supera lo que ya existe? Un jailbreak que replica lo que hace una herramienta de código abierto pesa menos que uno que desbloquea algo genuinamente nuevo.

    2. Amplitud. ¿Cuántas tareas ofensivas distintas habilita? Un jailbreak muy específico (un tipo de ataque, un vector) no es lo mismo que uno que abre la puerta a toda una clase de capacidades.

    3. Facilidad de armamento. ¿Cuánto esfuerzo humano experto requiere convertir el output en un ataque real? Hay una diferencia enorme entre "el modelo identifica una vulnerabilidad" y "el modelo produce un exploit listo para ejecutar".

    4. Descubribilidad. ¿Cómo de fácil es que un actor malicioso llegue a esta técnica? Un jailbreak que requiere semanas de ingeniería de prompts por parte de investigadores avanzados no tiene el mismo riesgo que uno que circula en un foro público.

    Este marco no es solo teoría. Anthropic lo propone como base para que gobiernos, empresas y laboratorios de IA puedan hablar de jailbreaks con criterios objetivos en lugar de reacciones políticas de emergencia.

    Si trabajas en seguridad o builds productos con IA, este marco te va a ser útil.


    Lo que esto significa para developers que construyen con IA

    Hace tres semanas, el modelo más capaz del mercado desapareció sin fecha de vuelta. Hoy está de vuelta con salvaguardas que ningún modelo anterior había tenido, respaldado por verificación gubernamental y un nuevo marco de evaluación que puede convertirse en estándar.

    ¿Qué cambia para nosotros?

    Primero, la confirmación de algo que debíamos asumir pero que muchos ignoraban: los modelos más capaces van a estar regulados. No es una posibilidad futura. Es el presente. El mismo día que Fable 5 volvió, Mythos 5 quedó restringido a socios controlados del Proyecto Glasswing. La IA de alto impacto va a tener fricción institucional. Cuanto antes lo integremos en nuestra planificación de producto, mejor.

    Segundo, la arquitectura de fallback importa más de lo que pensamos. Si tu producto dependía de Fable 5 el 12 de junio, tuviste un problema durante diecinueve días. Los mejores sistemas tienen fallback a modelos alternativos — no porque anticipen este escenario exacto, sino porque construyen con redundancia desde el principio.

    Tercero, y esto es lo más importante: la madurez del sector se mide en cómo responde a los errores, no en si los comete. Anthropic tardó diecinueve días en volver. En esas tres semanas entrenaron un nuevo clasificador, pasaron una auditoría gubernamental, propusieron un marco de evaluación de jailbreaks que puede convertirse en estándar, y redefinieron el acceso a Mythos 5. Eso no es una crisis mal gestionada. Es una empresa que aprendió en tiempo real bajo presión máxima.

    Nosotros podemos hacer lo mismo en nuestros productos.

    En el curso Construye con IA hablo de esto en profundidad: cómo construir sistemas que no colapsen cuando el modelo subyacente cambia, se actualiza o desaparece temporalmente. La resiliencia arquitectural no es un añadido. Es la condición de base para cualquier producto serio con IA.


    Preguntas frecuentes sobre Claude Fable 5

    ¿Claude Fable 5 está disponible hoy para todos los usuarios?

    Desde el 1 de julio de 2026, Fable 5 está disponible en Claude.ai, Claude Platform, Claude Code y Claude Cowork para usuarios en todos los países. AWS, Google Cloud y Microsoft Foundry se reactivarán próximamente. El acceso a Fable 5 requiere un plan de pago (Pro, Max, Team o Enterprise).

    ¿Qué es el jailbreak que causó la suspensión de Claude Fable 5?

    Investigadores de Amazon descubrieron una técnica de prompting que permitía a Fable 5 identificar vulnerabilidades en software y, en al menos un caso, demostrar cómo explotarlas. El gobierno de EE.UU. aplicó controles de exportación de emergencia el 12 de junio de 2026, lo que llevó a Anthropic a suspender el acceso global porque no podía verificar la nacionalidad de sus usuarios en tiempo real.

    ¿Cuál es la diferencia entre Claude Fable 5 y Mythos 5?

    Fable 5 es el modelo de propósito general disponible desde hoy para el público. Mythos 5 es la denominación de los modelos con capacidades cibernéticas avanzadas — superiores a cualquier otro modelo del mercado — restringido exclusivamente a socios del Proyecto Glasswing para ciberseguridad defensiva. No es accesible a través de la API pública.

    ¿Cómo afectan los nuevos salvaguardas al uso de Fable 5 en desarrollo de software?

    El nuevo clasificador bloquea el patrón de jailbreak en más del 99% de los casos, redirigiendo esas solicitudes a Claude Opus 4.8. Anthropic aumentó deliberadamente el margen de seguridad, lo que genera más falsos positivos en tareas de análisis de código, auditoría de seguridad o detección de vulnerabilidades. Si tu caso de uso incluye estas áreas, testea tu pipeline con Fable 5 para verificar el comportamiento del clasificador.

    ¿Qué límites de uso tiene Claude Fable 5 tras la vuelta?

    Hasta el 7 de julio de 2026, los planes Pro, Max, Team y empresas Enterprise seleccionadas tienen acceso a Fable 5 con hasta el 50% de sus límites de uso semanal habituales. Después del 7 de julio, el modelo estará disponible mediante créditos de uso sin restricción porcentual.

    ¿Puede volver a ocurrir una suspensión similar con otros modelos de Anthropic?

    Sí. Los controles de exportación son un instrumento legal que el gobierno de EE.UU. puede aplicar a cualquier modelo con capacidades que considere una amenaza. La colaboración reforzada entre Anthropic y el gobierno reduce la probabilidad de una suspensión de emergencia, pero no la elimina. Cualquier arquitectura de producto con IA debe contemplar escenarios de indisponibilidad del modelo principal.


    Si quieres estar al día de cómo estos eventos impactan a los developers que construyen con IA, en Dominicode Labs analizamos en tiempo real las decisiones de los grandes laboratorios y sus implicaciones para producción. Y en el canal de YouTube seguiré cubriendo la evolución de Fable 5 en las próximas semanas.


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

  • Claude Sonnet 5: el modelo que trabaja solo mientras tú duermes

    Claude Sonnet 5: el modelo que trabaja solo mientras tú duermes

    Me pasó hace unos meses revisando el output de un agente que había dejado corriendo toda la noche.

    Esperaba encontrar la tarea a medias. Un formulario sin completar. Alguna herramienta mal llamada. Lo habitual con los modelos de la generación anterior: empezaban bien, pero a mitad de camino se perdían, pedían confirmación o simplemente paraban.

    En cambio, encontré el trabajo terminado. Del principio al fin. Sin intervención.

    Ese momento cambia algo en tu cabeza como developer. No es que la IA sea "mejor". Es que ya no necesita que estés mirando.

    Claude Sonnet 5 es exactamente esa promesa hecha modelo. Anthropic lo lanzó el 30 de junio de 2026 y lo describe como "el modelo Sonnet más agéntico hasta la fecha". No es marketing vacío — la diferencia en tareas autónomas y multi-paso es medible y, para quien construye con IA, es relevante desde el primer día.


    Por qué Sonnet 5 es distinto a todo lo anterior

    Hasta ahora, la frontera estaba clara: si querías un agente que realmente terminase el trabajo, necesitabas Opus. Sonnet era el punto medio — rápido, accesible, suficientemente bueno para tareas simples. Pero en flujos complejos con múltiples pasos, herramientas y decisiones encadenadas, Sonnet se quedaba corto.

    Claude Sonnet 5 rompe esa frontera.

    Anthropic no ha simplemente subido los parámetros. Han optimizado específicamente para comportamiento agéntico: planificación de tareas, uso coordinado de herramientas (navegadores, terminales, APIs), y lo más relevante — la capacidad de verificar su propio resultado sin que se lo pidas.

    Eso último importa más de lo que parece. Un modelo que ejecuta código y luego comprueba si el output es el esperado, sin que tú se lo digas, está un paso más cerca de un colaborador que de una herramienta.


    Las capacidades agénticas en detalle

    Hay tres áreas donde el cambio es palpable:

    Tareas multi-paso sin interrupciones. Modelos anteriores tendían a pedir confirmación o detenerse cuando encontraban ambigüedad. Sonnet 5 mantiene el hilo. Algunos partners de Anthropic reportan que "terminó el trabajo de principio a fin sin intervención" — algo que antes era territorio exclusivo de Opus 4.

    Uso de herramientas coordinado. Puede combinar búsqueda web, ejecución de código y llamadas a APIs en la misma tarea sin perder el contexto de lo que estaba haciendo. No es nuevo que los modelos puedan usar herramientas — lo nuevo es que lo hacen con coherencia a lo largo de cadenas largas de razonamiento.

    Auto-verificación del resultado. Si ejecuta una query de base de datos o genera un archivo, puede evaluar si el resultado tiene sentido antes de dártelo. Esto reduce drásticamente la necesidad de loops de revisión en tus agentes.

    Si estás construyendo con la API de Claude o con Claude Code, estas tres capacidades cambian el diseño de tus flujos. No necesitas los mismos guardrails de antes. No necesitas los mismos puntos de control manual.

    En el curso de Construye con IA cubrimos exactamente este tipo de arquitectura de agentes — y con Sonnet 5 muchos de esos patrones se simplifican considerablemente.


    Benchmarks: qué dicen los números

    Los benchmarks importan, pero necesitan contexto. Aquí va la comparativa relevante para developers:

    Benchmark Claude Sonnet 5 Claude Sonnet 4.6 Claude Opus 4.8
    BrowseComp Superior Base de comparación Superior
    OSWorld-Verified Superior Base de comparación Superior
    Razonamiento general Muy cercano a Opus Inferior Referencia
    Codificación Notable mejora Base Referencia
    Esfuerzo "extra high" Iguala a Opus 4.8 Referencia

    Evaluaciones cualitativas basadas en el anuncio oficial de Anthropic (30 jun 2026).

    El dato más interesante: a nivel de esfuerzo máximo, Sonnet 5 iguala a Opus 4.8. Esto es arquitectónicamente significativo. Significa que para la mayoría de las tareas que antes justificaban pagar el precio de Opus, ahora puedes usar Sonnet 5 a un coste mucho menor.

    La excepción es ciberseguridad. Anthropic es explícito: Sonnet 5 no fue entrenado deliberadamente para tareas de seguridad ofensiva, y Opus 4.8 sigue siendo superior en ese dominio específico.


    Precios y disponibilidad

    Plan Precio hasta 31 ago 2026 Precio desde 1 sep 2026
    Input tokens $2 / M tokens $3 / M tokens
    Output tokens $10 / M tokens $15 / M tokens

    Anthropic ha aplicado un precio introductorio hasta finales de agosto. Si estás evaluando el switch en la API, este es el momento óptimo para hacerlo.

    Dónde está disponible:

    • Modelo predeterminado en los planes Free y Pro de Claude.ai
    • Disponible en Max, Team, Enterprise
    • Claude Code
    • API (model ID: claude-sonnet-5)

    Si usas Claude.ai directamente, ya lo tienes — es el modelo por defecto desde el lanzamiento.


    El tokenizador actualizado: impacto práctico

    Este punto se menciona poco y puede sorprenderte en producción.

    Sonnet 5 usa un tokenizador actualizado similar al que se introdujo con Opus 4.7. El resultado es que el mismo texto que antes ocupaba X tokens ahora puede ocupar entre 1.0× y 1.35× más tokens.

    ¿Qué significa esto en la práctica?

    Si tienes prompts largos con contexto extenso (documentos, conversaciones, sistemas de RAG), tu consumo de tokens aumentará. Anthropic compensa esto con el precio introductorio, pero necesitas tener este factor en cuenta al proyectar costes para producción.

    Una regla rápida: si venías de Sonnet 4.6 y tienes prompts de más de 5.000 tokens, haz una prueba controlada antes de cambiar el modelo en producción. Mide el consumo real, no lo estimes desde los benchmarks públicos.

    Para esto el post sobre prompt caching en Claude es directamente aplicable — con el nuevo tokenizador, el caching se vuelve aún más relevante para controlar costes.


    Cómo empezar hoy

    En Claude.ai: Ya está activo. Es el modelo por defecto. No necesitas hacer nada.

    En la API:

    El siguiente ejemplo muestra la integración mínima con el SDK oficial @anthropic-ai/sdk para TypeScript. El único cambio respecto a modelos anteriores es el model ID: claude-sonnet-5.

    import Anthropic from "@anthropic-ai/sdk";
    
    const client = new Anthropic();
    
    const response = await client.messages.create({
      model: "claude-sonnet-5",
      max_tokens: 4096,
      messages: [
        {
          role: "user",
          content: "Analiza este código y sugiere mejoras de rendimiento...",
        },
      ],
    });
    

    El cambio de model ID es inmediato. Si tienes un sistema en producción con claude-sonnet-4-6, cambiar a claude-sonnet-5 no requiere modificar nada más en la integración básica.

    Si usas Claude Code, el modelo ya está disponible y puedes seleccionarlo desde la configuración del cliente.


    Qué significa esto para developers que construyen con IA

    Voy a ser directo porque creo que es lo que necesitas saber.

    El lanzamiento de Sonnet 5 no es un update de rendimiento incremental. Es un reposicionamiento del tier medio.

    Hasta ahora, la decisión era: velocidad y coste (Haiku/Sonnet) vs. capacidad y razonamiento complejo (Opus). Con Sonnet 5, esa brecha se cierra de forma significativa. Puedes construir agentes que realmente terminen el trabajo, a un coste que tiene sentido para producción.

    Para quien está construyendo productos con IA — y no solo experimentando — esto cambia la ecuación de build vs. cost. Puedes subir la ambición de tus agentes sin subir proporcionalmente el presupuesto.

    El riesgo que veo es el de siempre: sobreestimar la autonomía del modelo en los primeros días. Sonnet 5 es notablemente mejor en tareas autónomas, pero sigue siendo un modelo de lenguaje. Sigue necesitando specs claras, herramientas bien definidas y tests que verifiquen los outputs.

    En Dominicode Labs estamos ya trabajando con Sonnet 5 en los proyectos de la comunidad — si quieres ver cómo se integra en flujos reales de producción, es donde está pasando.


    Preguntas frecuentes sobre Claude Sonnet 5

    ¿Qué diferencia hay entre Claude Sonnet 5 y Claude Sonnet 4.6?

    Claude Sonnet 5 está optimizado para comportamiento agéntico: puede planificar y ejecutar tareas multi-paso sin interrupciones, verificar sus propios resultados automáticamente y usar herramientas (navegadores, terminales, APIs) de forma coordinada en cadenas largas de razonamiento. Sonnet 4.6 era capaz, pero tendía a detenerse o pedir confirmación en tareas complejas. La mejora en benchmarks como BrowseComp y OSWorld-Verified refleja exactamente esta diferencia en tareas autónomas.

    ¿Es Claude Sonnet 5 tan bueno como Claude Opus 4.8?

    En la mayoría de tareas cotidianas de codificación, razonamiento y trabajo de conocimiento, Sonnet 5 está muy cerca de Opus 4.8 — y a nivel de esfuerzo máximo puede igualarlo. La excepción es el dominio de ciberseguridad, donde Opus 4.8 sigue siendo superior porque fue entrenado deliberadamente para esas tareas. Para el 90% de los casos de uso de desarrollo con IA, Sonnet 5 es suficientemente capaz y mucho más accesible en precio.

    ¿Cómo afecta el nuevo tokenizador a mis costes en la API?

    El tokenizador actualizado puede incrementar el consumo de tokens en un factor de 1.0× a 1.35× respecto a modelos anteriores. Esto es especialmente relevante con contextos largos: documentos, conversaciones extendidas, sistemas RAG. Anthropic compensa esto con el precio introductorio vigente hasta el 31 de agosto de 2026. La recomendación práctica es medir el consumo real con tus prompts de producción antes de estimar costes a escala.

    ¿Puedo usar Claude Sonnet 5 en Claude Code?

    Sí. Claude Sonnet 5 está disponible en Claude Code desde el lanzamiento. Dado que Claude Code es una herramienta diseñada precisamente para tareas agénticas de desarrollo — escribir, ejecutar, verificar código de forma autónoma — la combinación con Sonnet 5 es especialmente potente. Puedes seleccionar el modelo desde la configuración del cliente.

    ¿Qué precio tiene Claude Sonnet 5 y cuándo cambia?

    El precio introductorio vigente hasta el 31 de agosto de 2026 es $2/M tokens de input y $10/M tokens de output. A partir del 1 de septiembre de 2026 pasa a $3/M input y $15/M output. Si estás evaluando la migración en producción, hacerlo antes de septiembre tiene sentido económico.

    ¿Claude Sonnet 5 ya está disponible en el plan gratuito de Claude.ai?

    Sí. Desde el lanzamiento el 30 de junio de 2026, Claude Sonnet 5 es el modelo predeterminado en todos los planes de Claude.ai, incluyendo el gratuito. No necesitas hacer ningún cambio — si abres Claude.ai hoy, ya estás usando Sonnet 5.


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

  • 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.