DOMINICODE

Tag: Automatización

  • ¿La IA va a sustituir a los programadores? Estás preguntando mal

    ¿La IA va a sustituir a los programadores? Estás preguntando mal

    Hace unas semanas terminé una formación de Claude Code con un equipo de backend. Nueve personas. Al acabar, el más senior de la sala esperó a que se fueran los demás para hacerme la pregunta de verdad.

    "Bezael, sin rodeos: ¿la IA va a sustituir a los programadores? Aquí ya no hay nadie de RRHH."

    Le dije que la respuesta no le iba a gustar, porque no es sí ni es no. Es que la pregunta está mal hecha, y por eso lleva tres años sin producir nada útil aparte de hilos de Twitter.

    La IA no va a sustituir a los programadores: está sustituyendo tareas de programación. Nadie automatiza puestos. Se automatizan tareas — y casi ningún puesto es una sola tarea.

    Tu trabajo no es una cosa: la IA sustituye tareas, no puestos

    Piensa en un abogado. Redacta escritos, busca jurisprudencia, interpreta la ley, negocia y responde de lo que firma. Las dos primeras se automatizan razonablemente bien hoy. Las tres últimas, nada.

    Ahora hazlo con tu semana.

    Un developer teclea implementación, busca en documentación, lee stack traces, escribe boilerplate, migra sintaxis vieja a sintaxis nueva. Y además decide la arquitectura, decide qué no se va a construir, negocia el alcance con producto, entiende el contexto que no está escrito en ningún ticket, y responde de lo que se despliega un viernes a las seis.

    El primer grupo se está automatizando de verdad, hoy, no en 2030. El segundo no se ha movido ni un milímetro.

    Lo que ocurre entonces no es que desaparezca el puesto. Es que cambia la proporción. Menos horas de lo mecánico, más horas de lo otro.

    Y ahí está el problema real, el que casi nadie nombra: no todo el mundo quiere —o sabe— pasar más tiempo en la parte que queda.

    El patrón tiene cincuenta años: el cajero automático no acabó con los cajeros

    Esto ya pasó. Varias veces.

    El caso mejor documentado es el del cajero automático. En 1990 había unos 100.000 instalados en Estados Unidos; dos décadas después rondaban los 400.000. Entre finales de los ochenta y mediados de los dos mil, la sucursal urbana media pasó de necesitar unos 21 empleados de ventanilla a unos 13.

    El titular obvio era "los cajeros automáticos acaban con los cajeros humanos". Y durante dos décadas no ocurrió: el economista James Bessen documentó que el empleo total de cajeros de banca no solo aguantó el despliegue, sino que creció ligeramente.

    ¿Por qué? Porque operar una sucursal salía más barato y los bancos abrieron más. Y porque las tareas que no se automatizaron —vender, resolver el caso raro, sostener la relación con el cliente— pasaron a ser la mayor parte del puesto.

    El empleado de ventanilla de 2005 hacía un trabajo distinto al de 1980 con el mismo nombre en la nómina.

    Y aquí va la parte que casi nunca se cita, porque estropea la moraleja: a partir de 2010 el empleo de cajeros sí se hundió. Ha caído cerca de un 30% desde entonces, hasta quedar en poco más de 340.000 puestos. La banca online remató lo que el cajero automático solo había recolocado.

    Esa es la lección completa, y es bastante más útil que la versión bonita: primero cambia la composición del trabajo; después, si la tecnología sigue avanzando, cambia el número de puestos. Los veinte años de margen no fueron una garantía. Fueron un plazo.

    Lo mismo con la hoja de cálculo: desapareció sumar columnas a mano, y con ello buena parte del puesto de auxiliar contable — pero no la contabilidad. Lo mismo con el CAD: desapareció el tablero de dibujo, y el oficio de delineante se encogió, pero convertir una idea en un plano que se pueda construir sigue siendo trabajo de alguien.

    En los tres casos, la composición del trabajo cambió antes que su existencia.

    Lo nuevo hoy es la velocidad. El cajero automático tardó veinte años en reconfigurar una sucursal. Aquí el ciclo es de producto: lo que tu equipo hacía a mano en enero puede estar delegado en septiembre. No tienes una generación para adaptarte. Tienes un par de trimestres.

    Sobre cómo se ha sentido ese cambio desde dentro escribí hace poco en Llevo 15 años programando: esto es lo que cambió con la IA. Este post es la otra mitad: qué haces con ello.

    El riesgo real para un programador no es quedarse sin trabajo

    Es quedarte solo con la parte difícil.

    Si la IA te quita el 40% mecánico de la semana, lo que queda no es una semana más corta. Es la misma semana llena de decisiones y responsabilidad, sin los ratos de teclear a piloto automático que antes te servían de descanso mental.

    La carga mental sube aunque las horas bajen. Y eso casi nunca se prevé.

    Hay una consecuencia de gestión que va con esto: hay que decidir de antemano qué se hace con el tiempo que se libera, y decirlo en voz alta. Si no se decide, se llena solo de más volumen. Más tickets, más features, más PRs por revisar.

    Ese volumen extra rara vez llega como una decisión explícita: llega como una frase en una reunión que nadie tradujo. De eso va cómo explicar IA a tu jefe: 6 frases que acaban en tu sprint.

    Ese es el momento exacto en el que has cambiado un trabajo llevadero por uno más intenso, con el mismo sueldo y peor cara. Si tu equipo está midiendo esto con líneas de código o PRs mergeados, te va a pasar sin que lo veas venir; sobre eso va cómo medir la productividad en equipos que usan IA.

    Copiloto o agente: la pregunta que hacerle a cualquier herramienta de IA

    La forma de usar IA que mejor funciona hoy es la menos vistosa: la persona conserva el criterio y la responsabilidad, y la herramienta se lleva el trabajo mecánico.

    El mercado etiquetó eso como copiloto —un nombre comercial convertido en genérico— y ahora todo se llama igual. Así que cuando alguien te venda uno, la pregunta es siempre la misma:

    ¿Qué decide la herramienta y qué decides tú?

    Si el que decide es el modelo, eso no era un copiloto. Era un agente con un nombre más tranquilizador. La diferencia técnica entre ambos la desgloso en IA generativa vs IA agéntica.

    Esa frontera no la define el fabricante. La defines tú, en cada proyecto, cuando escribes el objetivo y los permisos. Por eso insisto tanto con las especificaciones: escribir la spec antes es el acto de decidir tú, por adelantado, lo que si no decidirá el modelo sobre la marcha. Lo desarrollo entero en el libro de Spec-Driven Development.

    Y no, esto no es un consuelo: a quién sí le cambia el puesto

    Decir que "cambia la mezcla" no significa que no haya consecuencias.

    Si el 80% de tu puesto era la parte automatizable, tu puesto cambia de forma muy seria. No hace falta que desaparezca la profesión para que desaparezca tu encaje concreto en ella.

    Por eso el ejercicio que viene no es opcional.

    El ejercicio: audita qué parte de tu semana puede automatizar la IA

    No es teoría. Se hace en veinte minutos y da un número incómodo.

    Coge la semana pasada. Mira tu historial de git, tu calendario y tu gestor de tareas. Lista los bloques de trabajo reales —no las tareas del sprint, lo que hiciste de verdad— y clasifica cada uno.

    La regla para clasificar, y hay que aplicarla con honestidad:

    • Mecánica: pudiste describir lo que había que hacer en tres frases, y otro developer competente lo habría resuelto prácticamente igual.
    • Criterio: tuviste que decidir algo que se podía haber decidido de otra forma, y no había respuesta correcta escrita en ningún sitio.
    Día Bloque de trabajo Horas Tipo
    Lun CRUD del endpoint de facturación 3h Mecánica
    Lun Decidir si el estado vive en cliente o API 40min Criterio
    Mar Migrar 12 componentes a la nueva sintaxis 4h Mecánica
    Mar Negociar con producto qué sale del scope 1h Criterio
    Mié Depurar el timeout intermitente de staging 2h Criterio

    Suma las horas de cada columna y saca la proporción.

    Si quieres el paso siguiente —qué delegas exactamente de la columna mecánica y cómo—, va entero en clasificar tareas con IA en desarrollo de software.

    Ahora lee el resultado sin dramatismo:

    Si sales 80% mecánica, eso es una señal, no un insulto. La mayor parte de tu semana está en la franja que se mueve primero. No significa que te vayan a echar el mes que viene: significa que tienes un par de trimestres para mover parte de esas horas al otro lado.

    Si sales 80% criterio, enhorabuena a medias. Tu puesto es de los que la IA hace más productivos, y también más agotadores. Tu problema no es la sustitución: es la carga.

    Y si sales 50/50, ese es más o menos el sitio donde está hoy un senior sano. El objetivo no es llegar a 0% mecánica. Nadie funciona así.

    Repite el ejercicio dentro de tres meses. La proporción es la métrica; el número absoluto de un día suelto no dice nada.

    Lo que haces mañana como programador

    Haz la auditoría esta semana, con tu propio historial, y guarda el resultado.

    Después, coge el bloque mecánico más grande —el que más horas se come— y delégalo de verdad: con contexto, con spec, con revisión tuya. No para ir más rápido. Para ver cuánto de tu semana era realmente insustituible cuando lo miras de cerca.

    Esa es la única pregunta que importa, y no la contesta ningún informe de McKinsey. La contesta tu tabla.

    Si quieres aprender a delegar esa parte sin soltar el criterio, es exactamente el flujo que enseño en Construye con IA: de la idea al producto con Claude Code. Y si lo prefieres sobre proyectos reales y con gente haciéndose las mismas preguntas, en Dominicode Labs es la conversación de cada semana.

    Preguntas frecuentes

    ¿La IA va a sustituir a los programadores?

    La pregunta no tiene respuesta útil porque mezcla dos cosas. La IA está sustituyendo tareas concretas de programación —boilerplate, migraciones mecánicas, búsqueda en documentación, primer diagnóstico de un stack trace— y no está sustituyendo otras: decidir arquitectura, negociar alcance, entender el contexto no escrito y responder de lo que se despliega.

    Lo que cambia no es la existencia del puesto, sino la proporción entre sus tareas. Y cambia más rápido que nunca.

    ¿Qué tareas de developer se automatizan bien hoy?

    Las que cumplen tres condiciones a la vez: se repiten, tienen un criterio de éxito verificable y el error se detecta rápido. Escribir la implementación cuando ya sabes qué quieres, generar tests de andamiaje, migrar sintaxis entre versiones, resumir un stack trace largo.

    Lo que no se automatiza bien es lo que exige asumir consecuencias. Un modelo puede proponer una decisión de arquitectura; no puede responder de ella dentro de dos años.

    Si mi semana sale 80% mecánica, ¿estoy en peligro?

    Estás en la parte del puesto que se mueve primero, que no es lo mismo que estar en peligro inmediato. Es información, y mejor tenerla ahora que dentro de dos años.

    Lo accionable: elige una de esas tareas mecánicas al mes y conviértela en algo que delegas y revisas, en lugar de algo que tecleas. El tiempo que recuperas lo inviertes en la columna de criterio: decisiones de diseño, escribir specs, revisar PRs de otros.

    ¿Qué diferencia real hay entre un copiloto y un agente?

    Quién toma la decisión. En un copiloto, la persona conserva el criterio y la responsabilidad, y la herramienta ejecuta lo mecánico. En un agente, la herramienta decide la ruta y actúa.

    Ninguno es mejor en abstracto: son herramientas para riesgos distintos. Lo peligroso es comprar un agente pensando que es un copiloto porque el fabricante lo llamó así. Si puede actuar sin que tú apruebes cada acción con consecuencias, es un agente y hay que tratarlo como tal.

    ¿Especializarme más me protege?

    Especializarte en una tecnología concreta te protege poco; especializarte en un dominio de negocio, mucho. El conocimiento de una API estable es exactamente el tipo de cosa que un modelo tiene mejor memorizada que tú — con las APIs nuevas va al revés, pero eso se arregla pegándole la documentación.

    Lo que sí acumula valor es lo que no se puede leer en la documentación: conocer el dominio del negocio, saber qué pregunta hay que hacer antes de escribir código, y tener el historial de decisiones que te dice por qué la opción elegante va a fallar aquí. Eso es criterio, y solo se construye con reps.

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

  • Cómo evaluar un proyecto de IA: cinco preguntas antes de aprobar

    Cómo evaluar un proyecto de IA: cinco preguntas antes de aprobar

    Un responsable de operaciones entra en la reunión con la frase ya montada: "queremos un agente para las devoluciones".

    Primera pregunta del árbol. ¿Los pasos son siempre los mismos, y en el mismo orden?

    Sí. Salvo cuando el importe supera cierto umbral.

    Fin del árbol. En la pregunta uno.

    Lo que necesitaba era un workflow con una excepción. Y estaba presupuestando diez veces eso.

    Esto es lo que no sale en la diapositiva de nadie que venga a venderte algo, y es el fondo de cómo evaluar un proyecto de IA: el resultado más frecuente de hacerlo bien es descubrir que no hacía falta un agente. No es falta de ambición. Es lo que hace que el proyecto siga vivo dentro de dos años.

    Y hay un motivo egoísta para que te importe aunque tú no firmes ningún presupuesto: la decisión mala la acabas implementando tú.

    Si lo que buscas es el vocabulario —qué es un agente y qué no—, está entero en esta guía. Aquí no definimos nada. Aquí decidimos, y le ponemos precio a cada decisión.

    Resumen rápido

    • Cinco preguntas, en orden, y se para en la primera que aplique. No es un cuestionario: es un árbol.
    • Cada peldaño que subes multiplica el coste. La gracia está en pararse en el más bajo que resuelve el problema.
    • En IA el éxito es lo que dispara el coste: se paga por uso, así que si la herramienta gusta, la factura sube con ella.

    Cómo evaluar un proyecto de IA: el árbol de cinco preguntas

    Evaluar un proyecto de IA es recorrer estas cinco preguntas en orden y parar en la primera que aplique:

    1. ¿Los pasos son siempre los mismos, y en el mismo orden? Si sí, es un workflow, no un agente.
    2. ¿Basta con leer y escribir texto, sin tocar ningún otro sistema? Si sí, basta un chat con buen contexto.
    3. ¿Hay que decidir sobre la marcha según lo que se encuentre? Si no, workflow otra vez.
    4. Si se equivoca, ¿se puede deshacer? Si no, agente con una persona aprobando cada acción con consecuencias.
    5. ¿Puedes medir si lo ha hecho bien? Si no, todavía no va a producción.

    Cada peldaño que superas multiplica el coste, así que evaluar bien un proyecto de IA consiste en pararse en el escalón más bajo que resuelve el problema.

    La decisión se toma casi siempre al revés. Alguien quiere hacer algo con IA y después busca dónde encajarlo. Así es como acabas pagando la flexibilidad de un agente para ejecutar cinco pasos que nunca cambian.

    El árbol invierte el orden. Primero el problema, después la herramienta. Y así es como se ve cuando lo pones en una hoja, que es la forma en que de verdad se usa en una reunión:

      1. ¿Los pasos son siempre los mismos,
     y en el mismo orden?
       └─ SÍ → workflow. No agente.
       ↓ NO

  2. ¿Basta con leer y escribir texto,
     sin tocar ningún otro sistema?
       └─ SÍ → un chat con buen contexto.
       ↓ NO

  3. ¿Hay que decidir sobre la marcha
     según lo que se encuentre?
       └─ NO → workflow otra vez.
       ↓ SÍ

  4. Si se equivoca, ¿se puede deshacer?
       └─ NO → agente, pero con una
                persona aprobando todo
                lo que tenga consecuencias.
       ↓ SÍ

  5. ¿Puedes medir si lo ha hecho bien?
       └─ NO → todavía no va a producción.
       ↓ SÍ

     → Adelante. Empieza con los permisos
       mínimos y ábrelos según se los gane.

    Ninguna de las cinco es técnica: se contestan describiendo el proceso. Vamos una a una, con el precio de quedarse en cada peldaño al lado. Porque el árbol no va de arquitectura. Va de dinero.

    Uno. ¿Los pasos son siempre los mismos y en el mismo orden?

    Si la respuesta es sí, ya has terminado. No necesitas un agente: necesitas un workflow.

    Más barato, más rápido, auditable, y no improvisa. Cuando falla, el informe de incidencia cabe en una línea: falló el paso tres. Eso también es dinero, porque nadie factura horas reconstruyendo qué pasó.

    Esta pregunta se salta por una razón muy humana: describir un proceso como "variable" suena mejor que describirlo como "cinco pasos y una excepción". Pero el caso de las devoluciones es el típico, no la anomalía. Los pasos son fijos salvo un caso, y ese salvo se convierte en el argumento para presupuestar un sistema entero.

    Un if no es variedad. Es un if.

    Y aquí está el multiplicador que hace que esta pregunta valga tanto dinero: un agente que da quince vueltas en lugar de tres no cuesta cinco veces más. Cuesta bastante más, porque el coste no crece con el número de vueltas, sino con la suma de todas las anteriores: cada una reenvía el contexto completo. Un workflow ejecuta los pasos que escribiste y para.

    Muchos candidatos a agente son procesos que pueden escribirse tal cual, y los desmenucé en cómo automatizar tu proceso de desarrollo con IA.

    Lo que pagas aquí: ingeniería una vez, ejecución predecible. Es el único escalón donde la factura no depende de que la herramienta guste.

    Dos. ¿Basta con leer y escribir texto, sin tocar ningún otro sistema?

    Si es que sí, te sobra con un chat con buen contexto. Súmale tus documentos y ya está.

    Redactar, resumir, reformular, clasificar. Nada de eso toca un sistema ni necesita permisos, y montarlo es cuestión de días.

    Lo que se subestima aquí no es la capacidad. Es la latencia.

    Un asistente que tarda ocho segundos sirve perfectamente para redactar un informe. El mismo asistente delante de un cliente al teléfono es inaceptable. La calidad es idéntica; el uso, imposible. Y un agente multiplica esa espera por el número de vueltas: lo que en un chat son ocho segundos, en un agente pueden ser dos minutos.

    Regla que uso siempre: si hay una persona esperando, la latencia es un requisito, no un detalle. Si el proceso corre de madrugada, da igual lo que tarde.

    Lo que pagas aquí: sube con el número de personas, no con la complejidad. Es el escalón que menos sorpresas da.

    Tres. ¿Hay que decidir sobre la marcha según lo que se encuentre?

    Si es que no, workflow otra vez.

    Esta pregunta existe porque hay procesos que tocan varios sistemas —por eso pasaron la dos— pero donde el orden sigue estando escrito de antemano. Leer un correo, extraer datos, meterlos en el CRM, avisar por Slack. Toca cuatro cosas. No decide ninguna.

    El error de asignación es carísimo y se repite: mover datos de un sitio a otro no necesita un modelo eligiendo el siguiente paso. Necesita una automatización de las de siempre, con IA solo en el hueco donde hace falta criterio.

    El árbol decide un proyecto entero. Cuando lo que tienes delante es un backlog y no un presupuesto, la unidad cambia: se decide tarea por tarea, y eso está en cómo clasificar tareas de desarrollo para delegarlas a la IA.

    Lo que pagas aquí: lo mismo que en la uno, más las ramas que hay que mantener. Sigue siendo el barato.

    Cuatro. Si se equivoca, ¿se puede deshacer?

    Si la respuesta es no, la respuesta tampoco es "no lo hagas". Es: agente sí, pero con una persona aprobando cada acción con consecuencias.

    Sin excepciones. Y sin renegociarlo a la baja tres semanas después porque aprobar es un incordio.

    Pagar, contratar, publicar, borrar, escribir a clientes reales, migrar datos de producción. Ninguna de esas se deshace con un ctrl+Z, y todas tienen un coste que ya no es de infraestructura: es de reputación, de contrato o de nómina.

    La parte que no aparece en ninguna hoja de cálculo: esa persona es un coste recurrente y no escala. Revisar el diez por ciento de las salidas es viable con cien casos al día e imposible con diez mil. El proveedor absorbe el volumen sin despeinarse. Quien lo vigila, no.

    Y si el proyecto solo sale a cuenta cuando quitas al humano de en medio, entonces no sale a cuenta. Eso es información valiosa, y llega gratis si haces la pregunta antes de firmar.

    Lo que pagas aquí: el modelo por las vueltas, más el tiempo de quien aprueba. Este es el peldaño donde el presupuesto cambia de orden de magnitud, no de porcentaje.

    Cinco. ¿Puedes medir si lo ha hecho bien?

    Si es que no, no lo pongas en producción todavía.

    No porque vaya a salir mal desde el primer día. Al revés: va a salir bien, porque los pilotos salen bien.

    El problema llega después. Sin forma de medir no vas a saber si empeora, y va a empeorar: cambias de modelo, cambia el tipo de casos que llegan, alguien toca un prompt. Todo eso ocurre sin que salte ninguna alarma, porque no hay alarma.

    Medir son dos cosas y hacen falta las dos. Una señal automática que diga si la ejecución fue correcta. Y la traza de qué decidió el sistema y con qué información, que es lo que te deja reconstruir un incidente en vez de opinar sobre él — la lista de qué guardar de cada ejecución la tienes en este repaso de observabilidad para agentes.

    Decidir qué salida es aceptable antes de construir, en lugar de parchearlo cuando ya ha explotado, es el trabajo que describo en el libro de Spec-Driven Development. No es burocracia: es lo que hace que la pregunta cinco tenga respuesta el día que la haces.

    Lo que pagas aquí: todo lo anterior más la infraestructura de medir. Y esa no se va nunca, porque es la que sostiene el resto.

    Si llegas al final del árbol, adelante. Un agente es la respuesta correcta y merece la pena. Empieza con los permisos mínimos y ábrelos según se los gane.

    Dónde te paras y qué pagas

    Cada parada del árbol tiene un perfil de coste distinto, y esa es la información que falta en casi todos los presupuestos:

    Dónde se para el árbol Lo que pagas de verdad
    Pregunta 1 → workflow Ingeniería una vez. Ejecución predecible
    Pregunta 2 → chat con contexto Por conversación. Sube con las personas
    Pregunta 3 → workflow otra vez Igual que 1, más ramas que mantener
    Pregunta 4 → agente con aprobación Modelo × vueltas + tiempo de quien aprueba
    Pregunta 5 → agente instrumentado Todo lo anterior + medir, para siempre

    Esta tabla es la razón de que el orden de las preguntas no sea decorativo.

    Anthropic lo dice sin rodeos en Building effective agents (diciembre de 2024): la recomendación es buscar siempre la solución más simple posible, y eso "puede significar no construir sistemas agénticos en absoluto". Es la empresa que te cobra por vuelta diciéndote que des menos vueltas.

    Cuánto cuesta un proyecto de IA: la cuenta que casi nadie hace

    Un proyecto de IA no se paga por licencia: se paga por uso. Un taxímetro, no un abono.

    En el software al que estás acostumbrado, el usuario número mil sale casi gratis. Aquí no: cada respuesta rehace un cálculo entero, y ese cálculo cuesta dinero.

    De ahí sale la frase que te va a servir en cualquier reunión de presupuesto: en IA, el éxito es lo que dispara el coste. Si la herramienta gusta y la usa todo el mundo, la factura sube en la misma proporción. Al revés de lo que espera un director financiero.

    Así que la cuenta es esta, y se hace antes: coste por consulta × número de consultas al mes, con el escenario de que la herramienta guste.

    Un piloto de diez personas y una implantación de dos mil no se diferencian en dos veces. Se diferencian en dos órdenes de magnitud. Y dos detalles estropean cualquier estimación hecha a ojo: lo que sale se cobra varias veces más caro que lo que entra —está en las tarifas públicas de Anthropic y en las de cualquier otro proveedor—, y una conversación larga cuesta más que la suma de sus mensajes, porque cada turno reenvía todo lo anterior.

    Esa asimetría entre lo que entra y lo que sale, con los números de coste al lado, la desglosé en IA generativa vs IA agéntica.

    El piloto es el diez por ciento del trabajo aunque parezca el noventa

    Un piloto se monta en semanas y sale bien: casos elegidos, gente motivada y alguien vigilando de cerca.

    Producción es otra cosa. Aparecen los casos raros, los usos que nadie previó, el mantenimiento de la base de conocimiento y la factura de verdad. Y aparece el punto que más proyectos entierra: quién se ocupa de esto dentro de un año. El piloto lo llevó alguien con ilusión en un rato libre. Producción necesita un dueño en el organigrama.

    Piloto Producción
    Casos Elegidos a mano Los que lleguen, incluidos los raros
    Usuarios Motivados y avisados Todos, y sin leer las instrucciones
    Supervisión Alguien mirando de cerca Una revisión semanal que hay que asignar
    Coste Casi ruido Coste por consulta × volumen real
    Dueño Quien tuvo la idea Una persona en el organigrama

    La regla, dura a propósito: si al terminar el piloto no sabes decir quién lo mantiene, cuánto costará al volumen real y quién lo revisa cada semana, el piloto no ha terminado. Ha terminado la parte divertida.

    Cómo evaluar un proyecto de IA cuando no hay un "antes" que medir

    Empieza por procesos donde puedas medir el antes. Es la regla que evita la mayoría de los disgustos, y se entiende sola: si no sabes cuánto tardabais en tramitar una devolución antes de la IA, tampoco vas a poder demostrar que ahora tardáis menos. Y sin eso, la renovación del presupuesto se decide por sensaciones.

    Cuidado con lo que eliges medir, porque lo que midas es lo que vas a conseguir. Si mides volumen tendrás volumen: más documentos generados, más tickets cerrados y ninguna certeza de que algo haya mejorado. Qué métricas dicen la verdad lo desarrollé en cómo medir la productividad de equipos que usan IA.

    Por qué te importa aunque tú no firmes nada

    Este árbol es cosa de quien firma. Por eso te importa a ti.

    Cuando alguien aprueba un agente para un proceso de cinco pasos fijos, tú eres quien pasa los seis meses siguientes intentando que un sistema no determinista se comporte de forma determinista. Vas a montar guardrails para forzar un orden que cabía en un switch. Vas a depurar ejecuciones que no se repiten. Vas a explicar por qué sube la factura.

    Todo eso era evitable en la pregunta uno, en una reunión de veinte minutos a la que probablemente no te invitaron.

    La jugada es sencilla: haz tú las cinco preguntas, en voz alta, antes de que se decida nada. No hace falta ser quien firma para ser quien pregunta.

    Y cuando la decisión ya está tomada y lo que te llega es una frase de reunión, el trabajo es traducirla antes de que se convierta en alcance: cómo explicar IA a tu jefe y las seis frases que acaban en tu sprint.

    Y si quieres contrastar el árbol antes de usarlo, esa conversación pasa cada semana en Dominicode Labs, con gente que ya tiene estos sistemas corriendo.

    Y si quieres el recorrido de idea a producto con este criterio aplicado desde el primer día, es el camino del curso Construye con IA.

    Lo único que tienes que hacer hoy

    Coge el proyecto de IA que ya está aprobado. Ese, no el que viene.

    Y contesta la pregunta uno: ¿los pasos son siempre los mismos y en el mismo orden?

    Si la respuesta empieza por "sí, salvo cuando…", ese salvo es la conversación que tienes que provocar esta semana. Porque casi siempre es un if, y estás pagando por un sistema que decide para no tener que escribirlo.

    El árbol sale de un libro que estoy terminando, El mapa de la inteligencia artificial: 120 conceptos para gente que decide sin escribir código. Mientras tanto, esos conceptos colocados por zonas —y estas cinco preguntas en formato imprimible— los tienes gratis en el mapa desplegable.

    Imprímelo y déjalo en la sala de reuniones. Mejor aún: pásaselo a quien te aprueba el presupuesto. Ahí es donde de verdad hace su trabajo.

    Preguntas frecuentes

    ¿Cómo se evalúa si un proyecto de IA merece la pena?

    Con un árbol de cinco preguntas que se recorre en orden y se detiene en la primera que aplique: si los pasos son siempre los mismos, si basta con leer y escribir texto, si hay que decidir sobre la marcha, si el error es reversible y si puedes medir el resultado. Cada peldaño que subes multiplica el coste y el riesgo, así que evaluar bien es pararse en el escalón más bajo que resuelve el problema.

    ¿Cuándo compensa pagar por un agente y cuándo basta con un workflow?

    Un agente solo justifica su precio cuando el camino cambia según lo que el sistema encuentra durante la ejecución, y pagar flexibilidad para un proceso fijo es el error más caro de esta lista. Si los pasos están fijados de antemano, un workflow es más barato, más rápido y auditable. Si el trabajo se agota en leer y escribir texto sin tocar otros sistemas, un chat con buen contexto y tus documentos resuelve el caso en días.

    ¿Por qué la primera pregunta ahorra tanto dinero?

    Porque corta los proyectos más caros antes de que existan. Un agente que da quince vueltas en lugar de tres multiplica la factura, y cada vuelta reenvía todo el contexto anterior, así que el coste no crece con el número de pasos sino con la suma de todos los anteriores. Cuando el proceso es fijo salvo una excepción, pagas por una decisión que se toma miles de veces y siempre sale igual.

    ¿Cuánto cuesta realmente un proyecto de IA?

    No se paga por licencia, se paga por uso: la cuenta correcta es coste por consulta multiplicado por consultas al mes, calculada con el escenario de que la herramienta guste. Un piloto de diez personas y una implantación de dos mil se separan en dos órdenes de magnitud, no en dos veces. Súmale lo que casi nunca se presupuesta: quien revisa, el mantenimiento de la base de conocimiento y el dueño del sistema.

    ¿Por qué un piloto que funciona no garantiza que el proyecto funcione?

    Porque el piloto se hace con casos elegidos, gente motivada y alguien vigilando de cerca. En producción aparecen los casos raros, los usos que nadie previó, los límites de las APIs y la supervisión semanal. Lo que no escala no es la infraestructura, que el proveedor absorbe sin inmutarse: es la parte humana de revisar, mantener y decidir.

    ¿Qué hago si no puedo medir si el sistema lo hace bien?

    No lo pones en producción todavía. Sin una señal que diga si una ejecución fue correcta no vas a enterarte de que el sistema empeora, y va a empeorar en cuanto cambie el modelo, cambien los casos o alguien toque un prompt. Antes de subirlo necesitas dos cosas: una comprobación automática del resultado y la traza de qué decidió el sistema con qué información.

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

  • Cómo meter Hermes Agent en tu flujo de trabajo diario

    Cómo meter Hermes Agent en tu flujo de trabajo diario

    Llevo meses metiendo Hermes Agent en mi flujo de trabajo diario, y el momento en que decidí hacerlo en serio no fue leyendo la documentación. Fue una noche en la que tenía Claude Code abierto en una terminal, revisando un PR que no avanzaba. Slack abierto en otra pestaña, esperando una respuesta que tardaba. Y un cron corriendo a las 3am que revisaba PRs pendientes en tres repos con un script de bash que yo mismo mantenía a mano.

    Me detuve a mirar ese script y vi algo incómodo: acababa de reinventar, con cron y bash, exactamente lo que Hermes Agent hace nativo. Desde ese día dejó de ser un experimento de fin de semana — pasó a ser la pieza que corre en segundo plano mientras yo hago otra cosa.

    Para quien no lo tenga fresco: Hermes Agent es el framework open source de agentes autónomos de Nous Research — sandbox Docker, memoria persistente y soporte multicanal (CLI, Telegram, Discord, Slack, WhatsApp, Signal). Dicho eso, este post no es una intro de "qué es Hermes Agent". Es cómo lo uso yo: cuándo lo disparo desde el móvil en vez de abrir la laptop, dónde le doy acceso real a mi código sin miedo a que rompa nada, y qué reviso antes de conectarlo a un VPS con datos reales.

    Claude Code y Hermes Agent no compiten — resuelven turnos distintos

    La primera pregunta que me hacen es la obvia: ¿esto reemplaza a Claude Code? No. Si alguien te dice que sí, no lo ha usado en serio.

    Claude Code vive en tu editor. Es una sesión interactiva: tú escribes, el agente responde, revisas el diff, iteras. Pair programming con alguien que no se cansa. La sesión termina cuando cierras la terminal.

    Hermes Agent vive en otro sitio: en background, disparado por un evento — un mensaje, un cron, un webhook — y sigue corriendo aunque cierres la laptop.

    La regla que uso: si estoy decidiendo diseño en tiempo real, Claude Code. Si la tarea es "revisa esto, hazlo, y avísame" — y puedo estar en el metro sin laptop — es trabajo para Hermes Agent.

    Instalar Hermes Agent en menos de un minuto

    En Linux, macOS, WSL2 o Termux:

    curl -fsSL https://hermes-agent.nousresearch.com/install.sh | bash

    En Windows nativo, sin WSL, desde PowerShell:

    iex (irm https://hermes-agent.nousresearch.com/install.ps1)

    El instalador de Windows resuelve solo uv, Python 3.11, Node.js, ripgrep, ffmpeg y un Git Bash portable — sin pedirte permisos de administrador. Esperaba instalar media docena de dependencias a mano. No hizo falta.

    Los comandos que necesitas el primer día

    Después de instalar, el wizard completo:

    hermes setup

    Si prefieres ir pieza por pieza:

    • hermes — abre el chat interactivo, punto de arranque de cualquier sesión
    • hermes model — elige proveedor y modelo LLM
    • hermes tools — configura qué herramientas están habilitadas
    • hermes gateway — levanta el gateway de mensajería (Telegram, Discord, Slack…)
    • hermes doctor — diagnostica problemas de configuración antes de que te den una sorpresa
    • hermes update — mantiene el binario en la última versión

    Si no quieres juntar API keys de cada proveedor por separado, hermes setup --portal hace login OAuth contra el Nous Portal: más de 300 modelos, web search, imágenes, TTS y browser en la nube bajo una sola suscripción. Es el atajo para no tener seis .env con llaves sueltas.

    Sacarlo de la terminal: dispararlo desde el móvil

    Aquí está el cambio real de flujo de trabajo. Antes de Hermes, "revisar algo desde el móvil" era abrir una app de VNC o SSH y sufrir un teclado táctil. Con el gateway de mensajería, no:

    hermes gateway setup    # Configura Telegram, Discord, Slack, WhatsApp, Signal
hermes gateway start
hermes gateway status

    El mismo agente que usas en la CLI responde en Telegram, Discord, Slack, WhatsApp o Signal, con los mismos slash commands:

    • /new o /reset — arrancar de cero
    • /model — cambiar de modelo
    • /personality — cambiar de contexto/personalidad
    • /retry y /undo — cuando algo sale mal
    • /compress — cuando la conversación se alarga
    • /usage — ver el gasto
    • /insights --days 7 — resumen semanal
    • /stop (o Ctrl+C en la CLI) — interrumpirlo

    En la práctica: voy caminando, me acuerdo de que quiero que revise un PR, le escribo por Telegram, y sigo caminando. Eso es lo que cambió — no la inteligencia del modelo, la fricción de acceder a él.

    El sandbox: que toque código real sin que te dé miedo

    La parte que a cualquier developer con experiencia le genera desconfianza, con razón: darle a un agente acceso de ejecución en tu máquina o servidor.

    Hermes soporta seis backends — local, Docker, SSH, Singularity, Modal, Daytona. Para cualquier cosa que toque un repo real, uso Docker (aquí entré en más detalle sobre por qué en la guía completa de Docker sandboxing en Hermes Agent):

    hermes config set terminal.backend docker

    No es un sandbox decorativo. El hardening por defecto elimina todas las capabilities de Linux y solo re-agrega tres: DAC_OVERRIDE, CHOWN, FOWNER. Límite de 256 procesos. /tmp como tmpfs de 512MB nosuid. /var/tmp con noexec y nosuid a 256MB. Bloqueo de escalación de privilegios (no-new-privileges). Límites de CPU, memoria (5GB por defecto) y disco (50GB por defecto).

    La diferencia práctica: si el agente ejecuta un comando destructivo dentro del sandbox, se lleva el contenedor, no tu servidor. Es la diferencia entre "cometí un error" y "cometí un error y ahora restauro un backup".

    Conectar las herramientas que ya usas: MCP

    Lo que hace que Hermes valga la pena en tu día a día no es que chatee bien — es que puede tocar las herramientas que ya usas. Los servidores MCP se declaran en ~/.hermes/config.yaml:

    mcp_servers:
  github:
    command: npx
    args: ["-y", "@modelcontextprotocol/server-github"]
    env:
      GITHUB_PERSONAL_ACCESS_TOKEN: "ghp_xxx"

    Con eso conectado, el agente revisa issues, comenta PRs o abre ramas sin que tú abras GitHub. Si ya construyes servidores MCP para Claude Code, funcionan igual aquí — el protocolo es el mismo, el cliente cambia (si quieres el detalle completo de cómo montar un servidor MCP propio, lo cubrí en Model Context Protocol: conecta tu base de datos a la IA). Es la misma lógica de interoperabilidad que trabajamos en el curso Construye con IA al conectar agentes a herramientas reales de producción.

    El checklist antes de darle acceso a algo real (VPS, producción)

    Esto diferencia un despliegue de fin de semana de uno que no te explota en la cara. Antes de conectar Hermes a un VPS, reviso la lista completa, no las tres primeras líneas:

    1. Nunca actives GATEWAY_ALLOW_ALL_USERS=true — define allowlists explícitos por plataforma
    2. Usa el backend de contenedor (terminal.backend: docker) para aislar la ejecución
    3. Configura límites de recursos en ~/.hermes/config.yaml
    4. Guarda secretos en ~/.hermes/.env con permisos restringidos — nunca en config.yaml
    5. Usa códigos de DM pairing en vez de IDs de usuario hardcodeados
    6. Audita el command_allowlist con regularidad, no solo la primera vez
    7. Define terminal.cwd para limitar el directorio de trabajo del agente
    8. Corre el gateway como usuario no-root
    9. Monitorea ~/.hermes/logs/ — que no falle no significa que hizo lo correcto
    10. Mantente actualizado con hermes update

    Si quieres esta lista y la chuleta completa de comandos en una sola hoja para imprimir, la armé gratis aquí: dominicode.com/hermes-agent. Y si tu siguiente paso es un VPS propio, el paso a paso completo está en cómo desplegar Hermes Agent en tu propio VPS con Docker.

    El modo YOLO no es tan yolo como suena

    Hay un modo --yolo (también /yolo, o HERMES_YOLO_MODE=1) que salta las confirmaciones de comandos. Lo uso cuando confío en la tarea y no quiero aprobar cada paso — casi siempre dentro del sandbox de Docker, nunca contra mi máquina local sin aislar.

    Incluso en YOLO hay un blocklist permanente que no se salta nunca: rm -rf /, fork bombs, escritura directa a dispositivos. No es marketing, es una capa que existe pase lo que pase.

    De fábrica también trae:

    • Protección SSRF — bloquea IPs privadas, loopback, link-local, CGNAT y metadata de nube antes de cualquier fetch
    • Filtrado de credenciales en subprocesos MCP — solo pasa variables seguras como PATH, HOME, USER, LANG
    • Escaneo de context files contra prompt injection
    • Advisories de supply-chain — hermes doctor te avisa directo si algo tiene una vulnerabilidad conocida

    Qué hacer hoy

    No necesitas resolver todo esto en una tarde. Esto es lo que haría en tu lugar.

    Instala Hermes hoy y corre hermes setup. No conectes nada todavía — úsalo desde la CLI un par de días, como probarías cualquier herramienta nueva.

    Cuando le confíes algo real, cambia el backend a Docker antes de darle acceso a un repo que te importe. Es un comando, no una migración.

    Y antes de conectarlo a un VPS o a mensajería pública, pasa por el checklist completo de arriba. Es la diferencia entre automatizar tu flujo de trabajo y crear un incidente de seguridad con tu nombre encima.

    Si estás diseñando cómo encajan Claude Code, Hermes y el resto de tu stack de IA — no solo conectando un agente suelto — es el tipo de conversación que tenemos cada semana en Dominicode Labs con developers que ya tienen esto en producción. (Ya estamos preparando, además, un curso completo dedicado solo a esto — sin fecha todavía, pero viene.)

    FAQ — Preguntas frecuentes sobre Hermes Agent

    ¿Hermes Agent es lo mismo que Claude Code?

    No. Claude Code es una sesión interactiva en tu editor para pair programming en tiempo real: tú decides, el agente ejecuta, revisas el diff al instante. Hermes Agent corre en background, disparado por mensajería o eventos, y sigue trabajando aunque cierres la laptop. Son complementarios, no competidores.

    ¿Necesito un servidor o VPS para usarlo?

    No para empezar. hermes corre local desde tu CLI en Linux, macOS, WSL2, Termux o Windows nativo. Un VPS se vuelve necesario cuando quieres el gateway de mensajería disponible 24/7 sin depender de que tu laptop esté encendida — ahí entra el checklist de seguridad de este post.

    ¿Es gratis?

    El framework es open source. Lo que cuesta es el consumo de tokens del proveedor que elijas con hermes model, o la suscripción del Nous Portal si usas hermes setup --portal para acceder a los 300+ modelos sin gestionar API keys sueltas.

    ¿Qué tan seguro es darle acceso a mi terminal?

    Depende del backend. Correr hermes directo contra tu máquina local sin sandbox es la opción de mayor riesgo. Cambiar a terminal.backend: docker te da capabilities reducidas, límites de proceso, memoria y disco, y contención real. Sumado al checklist de este post, es un nivel razonable para producción.

    ¿Puedo usarlo con modelos locales?

    Sí, vía Ollama, con su endpoint compatible con la API de OpenAI en localhost:11434/v1 — cualquier modelo con tool calling funciona. La restricción real es de contexto: el agente necesita al menos 64.000 tokens disponibles para el system prompt, los esquemas de herramientas y la conversación, así que un modelo local con ventana pequeña queda descartado desde el arranque. Prueba primero con un modelo mediano (14B-32B) que soporte tool calling y esa ventana de contexto antes de comprometerte a un flujo 100% local.

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

  • Cómo configurar un webhook en Hermes Agent paso a paso

    Cómo configurar un webhook en Hermes Agent paso a paso

    Un compañero me enseñó, orgulloso, su automatización de code review: un cron cada cinco minutos que llamaba a la API de GitHub y, si aparecía un PR nuevo, lanzaba el agente.

    Funcionaba. Más o menos.

    Cuando GitHub tardaba, se duplicaban las revisiones. Cuando el proceso moría de madrugada, nadie se enteraba hasta el lunes.

    El problema no era el agente. Era que estaba preguntando en lugar de escuchar.

    Un webhook en Hermes Agent invierte esa relación: en vez de sondear, dejas que GitHub, GitLab o cualquier servicio que hable HTTP llamen a tu puerta con la firma criptográfica verificada, y el agente reacciona solo cuando de verdad ha pasado algo.

    Una aclaración antes de seguir, porque me lo preguntáis mucho: Hermes Agent es el agente autónomo open source de Nous Research, no un producto mío. Yo hago contenido sobre él porque me parece una de las piezas más interesantes del ecosistema agéntico actual.

    Todo lo que sigue está verificado contra la documentación oficial de Hermes Agent en julio de 2026. El adaptador webhook sigue evolucionando, así que contrasta con la doc si tu instalación es posterior.

    Los 7 pasos para configurar un webhook en Hermes Agent

    1. Activa el adaptador con hermes gateway setup o las variables WEBHOOK_* en ~/.hermes/.env.
    2. Comprueba que el servidor responde en http://localhost:8644/health.
    3. Define la ruta dentro de platforms.webhook.extra.routes en ~/.hermes/config.yaml.
    4. Elige el esquema de firma del proveedor y valida el HMAC (usa el genérico V2).
    5. Dispara la ruta a mano con hermes webhook test antes de conectar el proveedor real.
    6. Marca con deliver_only: true las rutas que no necesitan que el agente razone.
    7. Ajusta y lista las rutas desde la CLI sin volver a editar YAML.

    Tiempo estimado: 15 minutos.
    Necesitas: Hermes Agent instalado, acceso a la configuración de webhooks del proveedor y una URL pública (o un túnel) que llegue a tu puerto.

    Vamos al lío.

    Qué es un webhook en Hermes Agent y qué hace el adaptador

    Un webhook en Hermes Agent es una ruta HTTP que recibe eventos POST de un servicio externo, valida su firma HMAC y los convierte en una ejecución del agente. Lo gestiona el adaptador webhook, que levanta un servidor HTTP y por cada petición hace cuatro cosas en orden:

    1. Valida la firma HMAC del emisor.
    2. Transforma el payload JSON en un prompt para el agente.
    3. Ejecuta el agente con ese prompt.
    4. Enruta la respuesta de vuelta al origen o a otra plataforma que hayas configurado.

    Ese paso 4 es el que la gente subestima. No es solo "recibir eventos": es cerrar el círculo. El PR entra por GitHub y el comentario sale por GitHub. O por Telegram. Tú decides.

    Paso 1: activa el webhook en Hermes Agent

    Puedes activar el adaptador de dos formas: con el asistente interactivo o declarando las variables de entorno. El asistente:

    hermes gateway setup

    O directamente las variables de entorno en ~/.hermes/.env:

    WEBHOOK_ENABLED=true
WEBHOOK_PORT=8644
WEBHOOK_SECRET=your-global-secret
    Variable Default Para qué sirve
    WEBHOOK_ENABLED false Activa el adaptador
    WEBHOOK_PORT 8644 Puerto del servidor HTTP
    WEBHOOK_SECRET (ninguno) HMAC global de fallback

    Respeta la separación: la configuración general vive en ~/.hermes/config.yaml y los secretos en ~/.hermes/.env. El día que compartas tu config con alguien lo vas a agradecer.

    Paso 2: comprueba que el servidor webhook responde

    El adaptador expone un endpoint /health en el puerto configurado. Si devuelve respuesta, está escuchando y puedes seguir:

    curl http://localhost:8644/health

    Si esto no responde, no sigas. Todo lo demás depende de que el servidor esté escuchando.

    Paso 3: define tu primera ruta de webhook en config.yaml

    Aquí está el núcleo de todo. Una ruta es un bloque dentro de platforms.webhook.extra.routes en tu config.yaml:

    platforms:
  webhook:
    enabled: true
    extra:
      port: 8644
      secret: "global-fallback-secret"
      rate_limit: 30
      max_body_bytes: 1048576
      routes:
        github-pr:
          events: ["pull_request"]
          secret: "github-webhook-secret"
          prompt: |
            Review this pull request:
            Repository: {repository.full_name}
            PR #{number}: {pull_request.title}
            Author: {pull_request.user.login}
            URL: {pull_request.html_url}
          skills: ["github-code-review"]
          deliver: "github_comment"
          deliver_extra:
            repo: "{repository.full_name}"
            pr_number: "{number}"

    Léelo de arriba abajo y tienes la historia completa: escucha eventos pull_request, valida con este secreto, construye este prompt, usa esta skill y devuelve la respuesta como comentario en el PR.

    Estas son las propiedades que puede llevar una ruta:

    Propiedad Obligatoria Para qué sirve
    events No Tipos de evento a aceptar; si lo dejas vacío, acepta todos
    secret Sí* Secreto HMAC de validación
    prompt No Plantilla con dot-notation; si se omite, vuelca el JSON completo
    skills No Skills que se cargan para esa ejecución del agente
    filters No Filtrado declarativo del payload
    script No Ruta a un script de filtro o transformación propio
    deliver No Destino: github_comment, telegram, discord, slack, log…
    deliver_extra No Configuración del destino (chat_id, repo, pr_number…)
    deliver_only No Salta el agente y envía el prompt como mensaje literal

    *secret es obligatorio salvo que la ruta herede el secreto global.

    Sobre las plantillas de prompt, cuatro detalles que te van a morder si no los sabes:

    • La dot-notation resuelve rutas anidadas: {pull_request.title} equivale a payload["pull_request"]["title"].
    • Si una clave no existe, se renderiza literalmente como {clave}. No falla, no avisa. Tu prompt simplemente llega con basura dentro. Este es el error número uno.
    • {__raw__} vuelca el payload entero como JSON indentado, truncado a 4000 caracteres. Muy útil mientras exploras un proveedor nuevo, mala idea en producción.
    • Las estructuras anidadas se serializan a JSON y se truncan a 2000 caracteres. Si un prompt te llega cortado por la mitad, es esto.

    Paso 4: valida la firma HMAC del proveedor

    Hermes trae cuatro verificadores de firma. Dos específicos y dos genéricos para todo lo demás:

    • GitHub: cabecera X-Hub-Signature-256, formato sha256=<hex>, HMAC-SHA256 del body.
    • GitLab: cabecera X-Gitlab-Token, comparación literal del secreto.
    • Genérico V2 (el recomendado): cabeceras X-Webhook-Signature-V2 y X-Webhook-Timestamp. El HMAC-SHA256 se calcula sobre <timestamp>.<body> y el timestamp debe caer dentro de ±300 segundos.
    • Genérico V1 (legacy, deprecado): cabecera X-Webhook-Signature, HMAC solo del body y sin protección anti-replay.

    Usa V2. La diferencia no es cosmética: al meter el timestamp dentro del material firmado, una petición capturada deja de servir pasados cinco minutos. Con V1, un payload robado es válido para siempre.

    Y ahora el matiz que separa a quien ha metido esto en producción de quien no: validar el HMAC prueba la identidad del emisor, no que el contenido sea de fiar. Que GitHub firme el evento confirma que viene de GitHub, no que el título del PR no contenga una inyección de prompt escrita por un colaborador externo. Todo campo que venga de fuera se trata como no confiable, siempre. Es la misma disciplina de límites de confianza que aplico al conectar herramientas externas vía servidores MCP.

    Paso 5: prueba la ruta con hermes webhook test

    No configures una ruta y te quedes mirando GitHub a ver si pica. Hermes trae un comando para dispararla a mano:

    hermes webhook test github-issues
hermes webhook test github-issues --payload '{"issue": {"number": 42}}'

    Con --payload controlas exactamente qué recibe la plantilla, así que puedes verificar que tu dot-notation resuelve bien antes de que el evento real llegue.

    Si el ciclo de "defino el comportamiento, lo pruebo, lo ajusto" te suena a especificar antes de implementar, es exactamente eso. Es el mismo enfoque que desarrollo en el libro de Spec-Driven Development: decide el contrato primero, verifica después.

    Paso 6: usa deliver_only para rutas sin coste de LLM

    Esta es mi parte favorita y la más ignorada. No todo evento necesita un LLM detrás.

    routes:
  antenna-matches:
    secret: "antenna-webhook-secret"
    deliver: "telegram"
    deliver_only: true
    prompt: "🎉 New match: {match.user_name} matched with you!"
    deliver_extra:
      chat_id: "{match.telegram_chat_id}"

    Con deliver_only: true el prompt renderizado se envía tal cual como mensaje y el agente nunca se invoca. Coste de inferencia: cero.

    Un despliegue terminado, un pago recibido, un test que falla: no necesitas que un modelo razone sobre eso, necesitas que llegue a tu Telegram. Reserva el agente para lo que exige criterio y usa deliver_only para el resto. Es la decisión que más reduce la factura de tu stack de IA agéntica.

    Paso 7: gestiona las rutas desde la CLI de Hermes

    La CLI crea, lista y elimina rutas sin tocar el YAML, que es lo cómodo para iterar:

    hermes webhook subscribe github-issues \
  --events "issues" \
  --prompt "New issue #{issue.number}: {issue.title}\nBy: {issue.user.login}" \
  --deliver telegram \
  --deliver-chat-id "-100123456789" \
  --description "Triage new GitHub issues"

hermes webhook list
hermes webhook remove github-issues

    Códigos de respuesta del webhook y qué significa cada uno

    El adaptador te dice con precisión qué ha pasado. Aprende esta tabla y te ahorras horas:

    Código Significado
    200 Entregado, o duplicado descartado por idempotencia
    401 Firma inválida o ausente
    400 JSON malformado
    404 Ruta desconocida
    413 El body supera max_body_bytes
    429 Rate limit superado
    502 El destino rechazó la entrega

    Dos protecciones que vienen puestas de serie y conviene conocer: el rate limit por defecto es de 30 peticiones por minuto y por ruta (ajustable con rate_limit), y hay una caché de idempotencia de una hora basada en las cabeceras de delivery ID. Ese reenvío duplicado que rompía el cron de mi compañero aquí devuelve 200 y no ejecuta nada.

    Una última nota de seguridad: toda ruta necesita un secreto, propio o heredado del global. INSECURE_NO_AUTH existe, pero solo funciona en loopback (127.0.0.1, localhost, ::1). Está bien pensado: no puedes dejarte una puerta abierta en producción por accidente.

    Empieza por lo pequeño

    Si vas a hacer una sola cosa hoy, que sea esta: activa el adaptador, crea una ruta con deliver_only: true que te avise por Telegram de algo que ahora mismo miras a mano, y déjala corriendo una semana.

    No montes el code review automático el primer día. Comprueba antes que los eventos llegan, que la firma valida y que tus plantillas resuelven. Cuando eso sea aburrido y predecible, le pones el agente detrás.

    La documentación de referencia está en la guía oficial de webhooks de Hermes Agent y el código en el repositorio de NousResearch.

    Y si lo que quieres es el marco completo —cómo pasar de una idea a un producto real apoyándote en agentes sin acabar con un montón de automatizaciones frágiles— eso es justo lo que enseño en el curso Construye con IA, y lo que practicamos cada semana dentro de Dominicode Labs.

    Preguntas frecuentes

    ¿Necesito exponer mi máquina a internet para usar un webhook en Hermes Agent?

    Sí, el proveedor externo tiene que poder alcanzar el puerto donde escucha el adaptador (8644 por defecto), así que necesitas una URL pública o un túnel hacia tu equipo. Para probar en local sin montar nada de eso puedes fijar el secreto de la ruta a INSECURE_NO_AUTH y saltarte la validación de firma, pero Hermes solo lo acepta cuando el gateway escucha en loopback (127.0.0.1, localhost, ::1), precisamente para que no puedas dejarte esa puerta abierta de cara a internet.

    ¿Qué diferencia hay entre la firma genérica V1 y la V2?

    La V2 incluye protección anti-replay y la V1 no. V2 usa las cabeceras X-Webhook-Signature-V2 y X-Webhook-Timestamp, calcula el HMAC-SHA256 sobre <timestamp>.<body> y rechaza cualquier petición cuyo timestamp se salga de ±300 segundos. V1 firma solo el body, está deprecada y una petición capturada sigue siendo válida indefinidamente.

    ¿Puedo recibir webhooks sin gastar tokens de LLM?

    Sí. Añade deliver_only: true a la ruta y Hermes renderiza la plantilla del prompt y la envía como mensaje literal al destino configurado, sin invocar nunca al agente. El coste de inferencia es cero. Es la opción correcta para notificaciones de despliegues, pagos o alertas donde no hace falta ningún razonamiento.

    ¿Qué pasa si el proveedor reenvía el mismo evento dos veces?

    Se descarta. Hermes mantiene una caché de idempotencia de una hora basada en las cabeceras de delivery ID del proveedor, y el duplicado recibe un 200 sin ejecutar el agente de nuevo. Es la protección que hace innecesario el típico registro manual de eventos ya procesados que se monta con sondeo por cron.

    ¿Es obligatorio poner un secreto en cada ruta?

    Sí. Toda ruta necesita un secreto para validar la firma HMAC, aunque puede heredar el valor global definido en WEBHOOK_SECRET o en platforms.webhook.extra.secret en lugar de declarar el suyo propio. Sin secreto válido, las peticiones se rechazan con 401. Lo recomendable es un secreto distinto por ruta.

    Mi webhook devuelve 401, ¿qué reviso?

    Un 401 significa firma inválida o ausente, casi siempre por desajuste entre el secreto configurado en Hermes y el que registraste en el proveedor. Verifica que coinciden exactamente, que el proveedor envía la cabecera esperada (X-Hub-Signature-256 en GitHub, X-Gitlab-Token en GitLab) y, si usas V2, que el reloj del emisor no se desvía más de 300 segundos.

    ¿Webhook o polling con cron para disparar un agente?

    Webhook, salvo que el proveedor no los ofrezca. El polling introduce latencia igual al intervalo del cron, duplica ejecuciones cuando la API tarda en responder y falla en silencio si el proceso muere. El adaptador webhook reacciona en el momento del evento, descarta reenvíos con su caché de idempotencia de una hora y devuelve un código HTTP que dice exactamente qué ha fallado. El cron solo gana cuando el sistema origen no emite eventos.

    ¿Por qué mi prompt llega con {algo} sin sustituir?

    Porque esa clave no existe en el payload. Hermes renderiza literalmente como {clave} cualquier ruta que no resuelva, sin lanzar error. Dispara la ruta con hermes webhook test <nombre> --payload '<json>' para inspeccionar la estructura real, o usa {__raw__} temporalmente para volcar el payload completo y localizar el nombre correcto del campo.

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

  • 5 agentes de IA que puedes construir con Hermes para tu negocio

    5 agentes de IA que puedes construir con Hermes para tu negocio

    Cuando hablo con fundadores de startups y desarrolladores sobre agentes de IA, casi todos se imaginan lo mismo: un chatbot de soporte básico en la esquina inferior de su web que responde preguntas frecuentes sacadas de un PDF de texto plano.

    Qué aburrimiento. Y qué desperdicio de tecnología.

    Los agentes de IA no están pensados para ser meros contestadores automáticos. Están diseñados para ejecutar flujos operativos complejos de tu negocio en segundo plano: monitorizar sistemas, calificar prospectos o conciliar facturas de forma 100% autónoma.

    Hoy te quiero enseñar 5 agentes que puedes construir con Hermes (el framework open-source de Nous Research) para delegar las tareas repetitivas de tu negocio y centrarte únicamente en la estrategia y la especificación.

    1. El Operador Autónomo de Comunidad (Soporte + Captación)

    Este es uno de los agentes más demandados. No se limita a responder dudas. Vive en tus canales de Slack, Telegram o Discord y atiende a los usuarios con memoria a largo plazo (recordando lo que habló con cada uno días atrás). Como vimos en nuestro post anterior, un agente de marketing con Notion puede calificar y almacenar leads de forma totalmente autónoma.

    • Cómo opera: Consulta la documentación de tu producto mediante MCP (Model Context Protocol), responde las dudas del usuario y, si detecta interés de compra, inicia una calificación conversacional natural.
    • Acción de negocio: Registra al prospecto en Notion y te envía un resumen por email al final del día con los leads calificados.

    2. El Agente DevOps de Auto-Sanación (Monitoreo + Reparación)

    Tener un desarrollador de guardia para resolver caídas sencillas del servidor a las 3:00 AM es ineficiente y costoso. Un agente de guardia DevOps puede encargarse de la primera línea de defensa.

    • Cómo opera: Monitorea logs y alertas en tu infraestructura en la nube (como Railway o un VPS). Al detectar un error de base de datos o puerto bloqueado, levanta un Sandbox seguro de Docker.
    • Acción de negocio: Ejecuta scripts de diagnóstico, soluciona el fallo de forma aislada y, si es un error inédito, te contacta por Telegram para pedirte instrucciones. Tras recibir la solución, genera una nueva Skill en Python para corregirlo solo la próxima vez.

    3. El Redactor y Programador de Contenidos (Blog + SEO)

    Mantener un blog técnico con posts semanales de alta calidad técnica requiere horas de redacción, auditoría de palabras clave y maquetación. Un agente de contenidos automatiza el pipeline entero.

    • Cómo opera: Dado un tema o palabra clave, redacta el borrador en markdown en estilo directo conversacional, realiza una auditoría SEO y de visibilidad en paralelo y genera una portada Open Graph (thumbnail) en base a tu sistema de diseño.
    • Acción de negocio: Conecta con la REST API de tu CMS (como WordPress) y sube el borrador completo listo para publicar.

    4. El Investigador de Leads y Clientes (Outbound + Ventas)

    El trabajo de buscar prospectos calificados en directorios, registrar sus datos de contacto en una hoja de cálculo y redactar propuestas personalizadas consume gran parte del tiempo de cualquier equipo de ventas.

    • Cómo opera: Scrapea listas de asistentes a eventos tecnológicos o directorios públicos, analiza las webs de las empresas y evalúa si encajan con tu Perfil de Cliente Ideal (ICP).
    • Acción de negocio: Extrae correos, nombres de fundadores y genera un dossier PDF detallado con un ángulo personalizado para realizar la propuesta.

    5. El Asistente de Finanzas y Conciliación Mensual

    Llevar la contabilidad de tu empresa a final de mes suele implicar descargar facturas de múltiples plataformas, buscar transacciones en el banco y meter datos manualmente en un Excel.

    • Cómo opera: Lee tus registros de cobros de plataformas de pago (como Stripe) mediante webhooks, descarga de forma autónoma los PDFs de gastos de tu correo o almacenamiento en la nube y asocia cada factura a su transacción correspondiente.
    • Acción de negocio: Actualiza tu hoja de cálculo mensual de pérdidas y ganancias (P&L) y te alerta si falta alguna factura de soporte de gasto.

    Diseña sistemas que operen, no simples prompts

    El verdadero valor de la IA en 2026 no está en el chat rápido que usas para resolver una duda de código. Está en diseñar agentes de larga duración que se ejecutan de forma de forma persistente e independiente 24/7.

    En el próximo [curso de Agentes IA Autónomos en Producción con Hermes Agent]([ENLACE PENDIENTE]) construimos de principio a fin las plantillas bases y repositorios del Operador de Comunidad y el Agente DevOps de Auto-Sanación.

    Si quieres debatir con otros ingenieros senior sobre cómo desplegar estos flujos operativos en tus propios proyectos, te espero en Dominicode Labs.

    Preguntas Frecuentes (FAQ)

    ¿Por qué usar Hermes Agent para construir estos sistemas?

    Hermes Agent (desarrollado por Nous Research) destaca por su arquitectura diseñada para tareas de largo recorrido. A diferencia de las llamadas a API simples, cuenta con persistencia de memoria SQLite local, soporte nativo de sandboxes de Docker para seguridad y un bucle de auto-mejora que permite que el agente genere sus propias capacidades sobre la marcha.

    ¿Qué nivel de seguridad tienen estos agentes en producción?

    El nivel de seguridad depende del diseño. Al utilizar Docker Sandboxes en Hermes, limitamos la ejecución de código generado por el LLM a contenedores cerrados y efímeros sin red, evitando que un script malicioso pueda borrar datos o comprometer tu servidor principal.

    ¿Se pueden conectar estos agentes a herramientas como Notion o Slack?

    Sí, gracias al Model Context Protocol (MCP). MCP proporciona un estándar abierto que permite conectar de forma directa e inmediata tu agente a Notion, Slack, GitHub, Postgres o Gmail simplemente añadiendo un archivo de configuración JSON.

    ¿Cómo puedo empezar a construir mi primer agente DevOps?

    Puedes empezar por automatizar lecturas de logs. Configura tu agente para que lea las respuestas de un endpoint de health check de tu aplicación y use integraciones de mensajería (Telegram o Slack) para alertarte con datos consolidados cuando detecte respuestas de error 500.

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

  • El Agentic Harness: Por qué un LLM por sí solo no es un producto

    El Agentic Harness: Por qué un LLM por sí solo no es un producto

    Cuando ves la demostración de un brazo robótico industrial realizando una tarea de precisión milimétrica, te quedas maravillado con la tecnología. Sin embargo, ninguna fábrica en su sano juicio dejaría que ese brazo operase de forma autónoma en su línea de montaje si solo consistiera en el motor mecánico.

    Necesita sensores de proximidad, sistemas de parada de emergencia, un software de control de límites y un operario humano supervisando la consola.

    El brazo aporta la fuerza y el movimiento bruto; pero la seguridad, consistencia y utilidad real de la operación dependen del soporte que lo rodea.

    En la inteligencia artificial moderna ocurre exactamente lo mismo. Un modelo de lenguaje (como Claude 3.5 Sonnet o GPT-4o) por sí solo es como ese brazo sin sensores. Para que solucione problemas reales en tu empresa, necesitas envolverlo en un Agentic Harness (Arnés Agéntico).

    Hoy te quiero explicar en qué consiste este concepto arquitectónico y por qué el diseño del arnés es lo que realmente convierte a la IA en un producto de negocio viable.

    El modelo es solo la "inteligencia"

    Existe una falsa creencia de que para automatizar un proceso basta con comprar tokens de API del modelo más grande de la nube y empezar a enviarle instrucciones conversacionales.

    Los LLMs son motores de predicción de texto extraordinarios, pero sufren de carencias críticas que les impiden operar en producción de forma directa:

    1. Carecen de estado: No recuerdan lo que pasó hace cinco minutos a menos que les reenvíes todo el historial (lo que satura el contexto y encarece la consulta).
    2. No controlan su ejecución: Pueden proponer una consulta SQL brillante, pero no tienen la capacidad física de conectarse a tu base de datos para ejecutarla y leer los resultados.
    3. Alucinan bajo presión: Si una herramienta externa les devuelve un error inesperado, el modelo suele inventar un parche absurdo en lugar de detenerse y pedir ayuda.

    Aquí es donde entra el Agentic Harness. El arnés es la infraestructura de software que envuelve al modelo para convertirlo en un agente autónomo, seguro y con memoria persistente.

    Las 4 patas de un Agentic Harness de Producción

    Para que tu arnés agéntico sea robusto y scalables, debe estructurar cuatro capas de soporte bien definidas alrededor de la API del LLM:

    ┌────────────────────────────────────────────────────────┐
│                    AGENTIC HARNESS                     │
├───────────────┬────────────────┬───────────────┬───────┤
│ Orquestación  │  Persistencia  │  Sandboxing   │ Evals │
│ y Flujo (Loop)│   y Memoria    │ de Ejecución  │   y   │
│               │ (SQLite/FTS5)  │    (Docker)   │ Control│
└───────────────┴────────────────┴───────────────┴───────┘
                                ▲
                                │ (Inferencia)
                     [ API de Inferencia LLM ]

    1. Orquestación y Control (El Bucle de Decisiones)

    Es el motor lógico que gestiona el ciclo de vida del agente. Se encarga de parsear las peticiones del usuario, construir el prompt de entrada estructurado, llamar al modelo y mapear las respuestas de este hacia herramientas ejecutables. Si la llamada de la herramienta devuelve un error, el loop se encarga de re-intentarlo o alterar el plan de forma autónoma.

    2. Persistencia y Memoria (El Almacén de Estado)

    Evita la amnesia del agente. El arnés debe persistir el estado de la conversación y las variables en una base de datos local (como SQLite con soporte WAL). Si el servidor se apaga o el contenedor de Railway se actualiza por Git-Ops, el agente puede recuperar su memoria y reanudar el flujo en el punto exacto donde se quedó.

    3. Sandboxing de Ejecución (La Seguridad Física)

    Un arnés seguro nunca permite que la IA ejecute código de forma directa en el servidor principal. Como vimos en nuestro post sobre Docker Sandboxing en producción, el aislamiento es la clave. El arnés debe levantar contenedores efímeros cerrados de Docker para que el agente pruebe sus scripts de diagnóstico o compile programas sin poner en riesgo la estabilidad del VPS.

    4. Gobernanza y Evals (El Control Humano)

    El arnés define las fronteras éticas y operativas. Registra logs estructurados para auditorías, escanea prompts entrantes contra inyecciones y, lo más importante, implementa sistemas de autorización (Human-in-the-loop). Si el agente quiere realizar una acción crítica (como eliminar datos o transferir fondos), el arnés congela la ejecución y solicita confirmación al administrador por Telegram.

    Hermes Agent: Un Arnés Agéntico Open-Source

    El framework de Hermes Agent de Nous Research es un excelente ejemplo de un Agentic Harness de producción. No es un modelo de IA; es el andamiaje técnico que te proporciona la persistencia en SQLite, el aislamiento en Docker sandboxes y la interfaz de MCP listos para usar de forma nativa.

    Entender la IA como un sistema completo y no como una simple consulta a una API es la base que enseñamos en el curso de Construye con IA para desarrollar productos robustos. Además, es la arquitectura de infraestructura que implementamos de principio a fin en el nuevo curso de Agentes IA Autónomos en Producción con Hermes Agent.

    Conclusión: Deja de comprar modelos, diseña tu arnés

    Los modelos de lenguaje seguirán bajando de precio y haciéndose más inteligentes cada mes. Son un commodity. El verdadero valor y la propiedad intelectual de tu negocio radican en el diseño de tu Agentic Harness. Al construir un arnés modular, seguro y persistente, garantizas que cualquier modelo (local o en la nube) pueda operar con consistencia para resolver las tareas operativas de tu empresa.

    Si estás estructurando el arnés agéntico para tu negocio y quieres discutir decisiones de arquitectura o seguridad con otros desarrolladores senior de nuestra comunidad, te espero en Dominicode Labs.

    Todo esto descansa sobre una distinción que conviene no dar por sabida: la definición operativa de agente de IA, la que se puede verificar mirando tu código en vez de la etiqueta del producto.

    Preguntas Frecuentes (FAQ)

    ¿Cuál es la diferencia entre LangChain y un Agentic Harness completo?

    ¿Cuál es la diferencia entre LangChain y un Agentic Harness completo? LangChain o LlamaIndex son librerías de software y componentes que te ayudan a estructurar flujos de datos e integraciones. Un Agentic Harness es el sistema en ejecución completo en producción (la arquitectura de servidores, bases de datos de estado, sandboxes aislados de Docker y gateways de mensajería) que aloja y opera al agente de forma continua.

    ¿Por qué la base de datos de persistencia es crítica en el arnés?

    Porque las APIs de inferencia en la nube no guardan historial de conversación real; son totalmente stateless. Sin una base de datos local sólida en el arnés que registre el estado de las sesiones y variables ante cualquier reinicio de servidor, tu agente sufrirá de amnesia agéntica, perdiendo el hilo de su tarea en curso.

    ¿Se pueden integrar políticas de seguridad en el arnés?

    Sí, de hecho es el lugar ideal para hacerlo. Al centralizar el control de ejecución en el arnés, puedes añadir filtros de censura de salida, restringir accesos a carpetas mediante permisos del sistema de archivos y bloquear comandos de consola peligrosos mediante aprobaciones manuales del usuario.

    ¿El arnés agéntico depende de un modelo específico?

    No. Un arnés bien diseñado debe estar totalmente desacoplado del backend de inferencia. Al utilizar APIs compatibles con la interfaz de OpenAI o Anthropic, puedes conectar tu arnés a un servidor local de oMLX en Mac, a Ollama en local, o a modelos propietarios en la nube (como Claude 3.5 o GPT-4) sin reescribir la lógica operativa de tu sistema.

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

  • Qué es un agente de IA (y qué no): guía para subir de nivel

    Qué es un agente de IA (y qué no): guía para subir de nivel

    Hace tres semanas un suscriptor me pasó el repositorio de su primer agente. Orgulloso, y con motivos: cuatrocientas líneas limpias, herramientas declaradas, tool calling funcionando.

    Le hice una sola pregunta. ¿Cuántas veces llama al modelo cuando lo ejecutas?

    Siempre tres. Las mismas tres, en el mismo orden, pasara lo que pasara.

    Eso no era un agente. Era un pipeline con tres llamadas a un LLM dentro. Y funcionaba perfectamente, que es lo que vuelve incómoda la conversación. Porque la respuesta habitual a qué es un agente de IA —"un sistema autónomo que usa herramientas para cumplir un objetivo"— describe igual de bien su script que Claude Code.

    Y no son la misma categoría de software.

    La diferencia no es semántica: decide qué tienes que instrumentar antes de dejarlo suelto y qué ocurre el día que se equivoca a las tres de la mañana.

    Aquí va la definición operativa que uso: un test que aplicas a tu código en dos minutos, la anatomía real, los grados de autonomía y —lo más importante— cuándo no deberías montar un agente.

    Resumen rápido

    • Un agente de IA es un sistema donde el modelo decide el flujo de control: qué acción viene después y cuántas. No lo define la autonomía ni el uso de herramientas.
    • El test: si el número de llamadas al modelo es fijo y puedes dibujar el camino antes de ejecutar, es un workflow con un LLM dentro. Y suele ser la opción correcta.
    • La anatomía real son cinco piezas: objetivo, política de decisión, herramientas, contexto y verificador con criterio de parada. La quinta es la que casi nadie monta.
    • Un límite de iteraciones no es un criterio de parada. Es un timeout.
    • Cruzar la línea es binario; lo que hay al otro lado, no. Hay grados de autonomía, y cada grado exige instrumentación distinta. Los incidentes suelen ser un grado 3 con instrumentación de grado 1.
    • No son agentes: un chatbot con herramientas, un pipeline determinista con un nodo de IA, un RAG clásico.

    Qué es un agente de IA: la definición que sí se puede verificar

    Un agente de IA es un sistema en el que el modelo decide el flujo de control: qué acción se ejecuta a continuación, con qué argumentos y cuándo parar. No lo define la autonomía ni el uso de herramientas, sino quién elige el siguiente paso.

    No es el que usa herramientas. No es el que parece inteligente. Es el que decide qué pasa después.

    La definición de marketing —"autónomo", "usa herramientas", "cumple objetivos"— es inútil precisamente porque no excluye nada: bajo ese paraguas cabe un cron con un prompt dentro.

    Anthropic lo formuló bien en Building effective agents (diciembre de 2024): los workflows son "sistemas donde los LLM y las herramientas se orquestan mediante caminos de código predefinidos"; los agentes, "sistemas donde los LLM dirigen dinámicamente sus propios procesos y su uso de herramientas, manteniendo el control sobre cómo realizan las tareas".

    Traducido a algo que puedas usar hoy: el diagrama de flujo de un workflow existe antes de ejecutarlo. El de un agente no existe hasta que termina.

    Si puedes dibujar en una pizarra todo lo que va a pasar, no has construido un agente. Has construido un programa que llama a un modelo. Que, insisto, suele ser mejor decisión.

    El test: ¿agente o workflow con un LLM dentro?

    Tres preguntas. Se contestan mirando tu código, no leyendo documentación.

    1. ¿El número de llamadas al modelo es fijo? Si siempre son tres, es un workflow.
    2. ¿La salida de una herramienta cambia cuál se llama después? Si el orden lo escribiste tú, es un workflow.
    3. ¿Hay un bucle del que el modelo puede decidir no salir? Si no hay bucle, no hay agente.

    Abre el archivo, busca la llamada al modelo y mira qué tiene alrededor. Esto es un workflow:

    // Workflow: el camino está escrito. Siempre estos tres pasos, en este orden.
const intencion = await modelo.clasificar(email)
const resumen = await modelo.resumir(email)
const respuesta = await modelo.redactar(intencion, resumen)

await enviar(respuesta)

    Y esto es un agente:

    // Agente: el modelo elige la siguiente acción con lo que acaba de observar.
const mensajes: Mensaje[] = [{ role: 'user', content: objetivo }]
let pasos = 0

while (pasos++ < LIMITE) { // LIMITE es un timeout, no un criterio de parada
  const decision = await modelo.responder({ mensajes, tools })

  if (decision.tipo === 'final') break // ojo: aquí para el modelo, no un verificador

  const observacion = await ejecutar(decision.tool, decision.args)
  mensajes.push(decision, observacion) // lo observado entra en la siguiente decisión
}

    Toda la diferencia está en una palabra: while. En el primero, un await va detrás de otro y el orden lo pusiste tú. En el segundo hay un bucle, y dentro del bucle el que elige es el modelo.

    Fíjate en los dos comentarios que he dejado en el segundo bloque, porque ese ejemplo todavía está incompleto a propósito: para cuando el modelo dice que ha terminado, y eso no es un criterio de parada. Volvemos a ello en la anatomía.

    Si en tu repositorio no aparece ese bucle —ni explícito, ni dentro de la librería que uses—, no tienes un agente. Y si el while solo reintenta la misma llamada cuando falla la red, tampoco: eso es un retry.

    Ese bucle tiene nombre propio, fases y modos de fallo documentados: lo desmonté pieza a pieza en Agentic loop: el mecanismo detrás de los agentes de IA.

    La anatomía real: cinco piezas, y casi nadie monta la quinta

    Un agente de IA se compone de cinco piezas: objetivo, política de decisión, herramientas, contexto y verificador con criterio de parada. Las cuatro primeras salen en cualquier tutorial. La quinta es la que separa una demo de un sistema.

    Pieza Qué es Qué pasa si falta
    Objetivo El resultado esperado, no la instrucción Optimiza para parecer útil, no para terminar
    Política de decisión El modelo eligiendo la siguiente acción No hay agente: hay script
    Herramientas La superficie de acción sobre el mundo real Razona precioso y no cambia nada
    Contexto Lo que sabe en cada iteración Repite trabajo hecho y se contradice
    Verificador y criterio de parada La señal que dice si el trabajo está bien Para cuando cree que ha acabado

    Estas cinco son las piezas del agente. El andamiaje que lo envuelve —registro de herramientas, guardrails, gestión de contexto— es otra capa distinta, y la desglosé en qué es un agent harness.

    Las herramientas son donde más gente se pasa de frenada: doce tools disponibles, descripciones ambiguas y un modelo eligiendo mal. No es fallo del modelo, es fallo de diseño, y lo desarrollé en cómo evitar que los agentes elijan mal sus herramientas.

    El contexto arruina ejecuciones largas en silencio. Qué recuerda entre iteraciones, qué recuerda entre sesiones y qué debe olvidar es arquitectura, no implementación: las cuatro capas del modelo CoALA están en implementación de memoria en agentes de IA.

    Y llegamos a la quinta, que es donde está el problema de verdad.

    Un límite de iteraciones no es un criterio de parada

    Casi todo el mundo cree que tiene verificador porque ha escrito esto:

    while (pasos < 10) { /* ... */ }

    Eso es un timeout. Dice cuándo dejar de gastar dinero. No dice nada sobre si el trabajo está bien hecho.

    El criterio de parada es un comando o una función que responde sí o no sin que intervenga tu criterio. Los tests en verde. El typecheck limpio. Un eval puntuado contra casos conocidos. Un schema que valida la salida.

    Y aquí se resuelve la tensión que quizá te haya chirriado antes: dije que el modelo decide cuándo parar, y ahora digo que el criterio tiene que ser externo. Las dos cosas. El modelo propone que ha terminado; el verificador confirma o lo devuelve al bucle. Un agente que se autoevalúa no tiene criterio de parada: tiene una opinión.

    La diferencia se nota el día que el agente sale del bucle en la iteración 4 y te devuelve algo roto. Salió porque el modelo dijo "listo", y el modelo dijo "listo" porque no había nada delante que le llevara la contraria.

    Un agente sin verificador no es autónomo. Es no supervisado, que es otra cosa. Montar esa señal es lo que separa una demo de un sistema, y está en evaluaciones automatizadas para agentes de IA.

    El verificador tiene un hermano que se olvida igual de rápido: el perímetro. Contenedor aislado, rama nueva, credenciales de solo lectura. Nunca ejecución de código generado sobre el servidor real. Cuanta más autonomía das, más estrecho tiene que ser el perímetro, no al revés.

    Los grados de autonomía: cuánto decide el modelo

    El test de arriba te dice si has cruzado la línea. No te dice cuánto la has cruzado, y eso es exactamente lo que decide qué tienes que montar debajo. Hay cinco grados, del 0 al 4, y cada uno exige una instrumentación distinta.

    La escala que viene es mía, no un estándar de la industria. La uso para decidir qué instrumentación exige cada salto antes de darlo. Si te sirve, róbala; si no, calibra la tuya y quédate con la última columna.

    Grado Lo decide tu código Lo decide el modelo Ejemplo típico Mínimo que exige
    Grado 0 El flujo y la ejecución completa El texto que devuelve Chat, autocompletado Nada. El bucle eres tú
    Grado 1 Qué acciones existen y cuándo se ejecutan Cuál encaja en este caso Tool calling de un salto, routing Validación de argumentos
    Grado 2 El catálogo y el permiso de cada acción El orden y cuántas hacen falta Agente con aprobación por acción Un humano revisando cada acción antes de ejecutarla, no el resumen final
    Grado 3 El perímetro y el criterio de parada El plan completo dentro del perímetro Un agente arreglando un test en CI Verificador automático, sandbox y trazas
    Grado 4 Solo el perímetro El plan y sus propias herramientas Self-improving loop Todo lo anterior más evals de regresión

    La línea del test está entre el grado 1 y el grado 2. Por debajo, el orden lo escribiste tú: workflow. Del grado 2 hacia arriba, el orden lo decide el modelo, y ahí empieza el agente. Ser agente es sí o no. Cuánta cuerda le das, no.

    Mira solo la última columna. Es la única que importa de verdad.

    Subir de grado no es cambiar de modelo ni instalar un framework con la palabra "agent" en el nombre. Es tener montado lo que ese grado exige antes de subir.

    El incidente típico no lo provoca un agente malo. Lo provoca un grado 3 corriendo con instrumentación de grado 1: sin trazas para reconstruir qué decidió, sin sandbox y sin señal automática de si aquello estaba bien. Qué capturar de cada ejecución para poder auditarla está en cómo monitorear agentes de IA en producción.

    El grado 4 es el techo actual y el más malinterpretado. Un agente que escribe sus propias herramientas al detectar una tarea que no sabe hacer no es magia: es un bucle que compila, testea en aislamiento y solo incorpora la habilidad si los tests pasan. Lo tienes entero en Self-Improving Loop.

    Una vez sabes que has cruzado la línea, la pregunta útil ya no es "¿esto es un agente?". Es "¿en qué grado corre y qué he puesto debajo?"

    Qué no es un agente, aunque lo llamen así

    Un chatbot con herramientas. Buscar en la web y devolverte el resultado sigue siendo un salto único. La prueba es si puede reintentar por su cuenta a partir de lo que acaba de observar. Si no puede, es un chat con herramientas conectadas.

    Un pipeline determinista con un nodo de IA. Un flujo de n8n, Zapier o Make con una caja que dice "AI" es un workflow: el camino está dibujado en el canvas y el modelo rellena huecos. Cuando un paso falla, el flujo se rompe; no reformula la estrategia.

    Un RAG clásico. Recuperar, inyectar en el prompt, responder. Camino fijo, una llamada. Se vuelve agéntico solo cuando el modelo decide si vuelve a buscar, con qué query y cuándo parar. Ese "decide" es toda la diferencia.

    Y una que se ha puesto de moda: más agentes no es más agente. Cinco LLM encadenados suelen ser un workflow caro con pérdida de contexto en cada salto. Cuándo compensa y cuándo es autolesión lo analicé en cuándo usar multi-agente sin orquestador.

    Ninguna de las cuatro es peor que un agente. Suelen ser mejores: más baratas, más rápidas y depurables. Cuando un workflow falla, sabes en qué paso.

    Cuándo NO deberías montar un agente

    Para que compense tienen que darse tres condiciones. Las tres. No dos de tres.

    Que exista una señal automática de si el trabajo está bien. Si el único verificador eres tú leyendo el resultado, no has delegado el bucle: lo has movido a tu bandeja de entrada.

    Que el camino no sea siempre el mismo. Esta es la que más se ignora. Si el flujo es idéntico en el 95% de las ejecuciones, estás pagando a un modelo por redescubrir cada vez un orden que ya conoces. Escríbelo en código. Anthropic, en el artículo que cité arriba, recomienda buscar siempre la solución más simple posible y añade que eso "puede significar no construir sistemas agénticos en absoluto".

    Y si tu duda de fondo es cuál de tus tareas merece un agente y cuál no, esa clasificación —tarea por tarea— está en cómo clasificar tareas de desarrollo para delegarlas a la IA y, con los números de coste al lado, en IA generativa vs IA agéntica.

    Que el error sea reversible dentro del perímetro. Migraciones sobre datos de producción, borrados, despliegues sin rollback, correos a clientes reales. Ahí no se sube a grado 3: ahí el modelo propone y tú apruebas, que es para lo que existe el grado 2.

    Falla una de las tres y la respuesta correcta es un workflow. No es una derrota: es ingeniería.

    La ruta: por dónde empezar y cómo subir de nivel

    Con esto claro, aprender agentes deja de ser una lista de herramientas y pasa a ser una progresión de grados.

    Etapa 1 — Usa un agente antes de construir uno (grados 0-1)

    Trabaja unas semanas con un harness ya hecho —Claude Code, Codex CLI, el que prefieras— sobre tu repositorio real. No para aprender la herramienta: para ver de primera mano dónde decide mal y qué información le faltaba cuando lo hizo. Eso es lo que después no sabrás diseñar si nunca lo has sufrido.

    Y haz dos cosas desde el primer día, porque cambian el resultado más que el modelo que elijas.

    Escribe el contrato: un CLAUDE.md en la raíz convierte al agente de invitado que improvisa en ejecutor con reglas explícitas, y cómo redactarlo está en CLAUDE.md: el contrato entre tú y el agente.

    Y especifica antes de dejarle editar, porque un agente al que le pides que programe a ciegas rellena con invención todo lo que no escribiste. La metodología está en Spec-Driven Development: evita el caos de la IA, y completa, con plantillas y flujo de trabajo, en el libro de Spec-Driven Development.

    Etapa 2 — Construye uno pequeño de verdad (grado 2)

    No un framework: un bucle. Un objetivo, dos herramientas, argumentos validados y un criterio de parada que no sea un contador. Doscientas líneas enseñan más que cualquier tutorial, porque ves dónde se rompe.

    Valida los argumentos con un schema desde la primera línea: la frontera entre el texto probabilístico del modelo y tus tipos tiene que ser explícita, y es lo que enseño en el curso de Zod. El stack mínimo completo —SDK, Zod y un bucle explícito— está en construye un agente de IA en TypeScript.

    Cuando quieras que esas herramientas dejen de estar acopladas a tu código y las consuma cualquier cliente compatible, entra MCP: el recorrido completo, servidor y agente incluidos, está en cómo construir un agente de IA y su MCP server paso a paso.

    Si prefieres hacer este salto acompañado y llegar de la idea a un producto funcionando, es el camino del curso Construye con IA.

    Etapa 3 — Sube al grado 3 con la instrumentación por delante

    Aquí se separa el proyecto de fin de semana del sistema que corre solo. Ya sabes qué exige el grado 3, así que la pregunta no es cuáles son las piezas: es en qué orden se montan. Va este, y el orden importa.

    Primero el sandbox. Es la única que te protege del peor día, y es la más barata de todas: un contenedor y una rama nueva. Montarla la última es como ponerse el cinturón al llegar.

    Después las trazas. Sin ellas no puedes depurar nada de lo que viene después, porque no sabrás qué decidió el agente ni con qué información.

    Luego el verificador. Ahora sí puedes construirlo, porque las trazas te enseñan en qué se equivoca de verdad y contra qué merece la pena verificar.

    Y por último los evals. Son el verificador aplicado a un conjunto de casos conocidos, así que llegan cuando ya tienes uno.

    La memoria persistente no está en esa lista a propósito: es una optimización de coste y de continuidad, no una condición de seguridad. Se monta cuando el agente ya corre bien, no antes. Ese error de orden —memoria elegante y cero trazas— lo he visto más veces de las que me gustaría, y es también el que describo en loop engineering.

    Y cuando quieras montar esto como disciplina profesional y no como proyecto suelto, el roadmap de carrera está en qué es un Agentic Engineer y cómo convertirte en uno.

    Lo único que tienes que hacer hoy

    Abre el repositorio de eso que llamas agente y busca la llamada al modelo.

    Si alrededor no hay un bucle donde la salida de una herramienta cambia la siguiente decisión, tienes un workflow. Deja de intentar convertirlo en agente y hazlo mejor workflow: será más barato y no te despertará de madrugada.

    Si sí lo hay, contesta la segunda pregunta: ¿qué señal automática le dice que ha terminado? Si la respuesta es un número de iteraciones, acabas de encontrar el trabajo de esta semana. Y es el que más te va a rentar.

    Si quieres el esqueleto ya montado para no empezar de cero —bucle, herramientas y criterio de parada—, lo he empaquetado gratis en el Hermes Agent Kit.

    Y si prefieres discutir arquitecturas concretas con gente que ya tiene agentes corriendo en producción, te espero en Dominicode Labs.

    Preguntas frecuentes

    ¿Qué es un agente de IA exactamente?

    Un agente de IA es un sistema en el que el modelo decide el flujo de control: qué acción se ejecuta a continuación, con qué argumentos y cuándo detenerse. No lo define la autonomía ni el uso de herramientas, sino quién elige el siguiente paso. Si el orden de las acciones está escrito en tu código, tienes un workflow con un LLM dentro. Si ese orden se decide en tiempo de ejecución a partir de lo que el sistema acaba de observar, tienes un agente.

    ¿Cuál es la diferencia entre un agente de IA y un workflow con un LLM?

    El diagrama de flujo. El de un workflow existe antes de ejecutarlo, porque los caminos están predefinidos en código; el de un agente no existe hasta que la ejecución termina. Se comprueba con dos señales: si el número de llamadas al modelo es fijo, es un workflow; si la salida de una herramienta puede cambiar cuál se llama después, es un agente. El workflow no es una versión inferior: es más barato, más rápido y más fácil de depurar.

    ¿Un chatbot con herramientas es un agente de IA?

    No mientras no cierre el bucle. Un chatbot que busca en la web y te devuelve el resultado ejecuta un salto único: no comprueba si lo que obtuvo resuelve el objetivo ni cambia de estrategia cuando no lo resuelve. La prueba está en el código, no en la interfaz: si no existe una iteración en la que la observación de una herramienta determine cuál se llama después, tienes un chat con herramientas conectadas.

    ¿ChatGPT o Claude son agentes de IA?

    Por sí solos no: son modelos servidos tras una interfaz de chat, y ahí el bucle lo cierras tú al leer la respuesta y escribir la siguiente instrucción. Se convierten en la política de decisión de un agente cuando los envuelves en un sistema que ejecuta sus llamadas a herramientas y le devuelve el resultado para que decida el siguiente paso: eso es lo que hacen Claude Code o Codex CLI. El agente no es el modelo; es el modelo más el bucle, las herramientas y el criterio de parada.

    ¿Qué ejemplos reales de agentes de IA hay hoy?

    Los más maduros en 2026 son los agentes de programación que corren sobre un repositorio: Claude Code, Codex CLI de OpenAI, Cursor en modo agente y Gemini CLI. Todos comparten la misma estructura: un bucle que lee ficheros, ejecuta comandos, observa la salida y decide la siguiente acción, con los tests como criterio de parada. Fuera del código, los casos que funcionan son los que tienen verificación automática: triaje de incidencias, migraciones de datos validadas contra un schema y control de calidad de contenido.

    ¿Necesito LangChain o un framework de agentes para construir el mío?

    No. El núcleo de un agente son unas doscientas líneas: un bucle, un catálogo de herramientas con argumentos validados, el historial de observaciones y un criterio de parada. Escribirlo a mano una vez enseña más que LangChain, Mastra o el Vercel AI SDK juntos, porque ves exactamente dónde se rompe. El framework empieza a compensar después: cuando necesitas persistencia entre ejecuciones, orquestación de varios procesos o trazabilidad estándar.

    ¿Por qué un límite de iteraciones no sirve como criterio de parada?

    Porque es un timeout: evita que el agente gaste tokens sin fin, pero no dice nada sobre la calidad del resultado. El criterio de parada es una señal externa al modelo que responde sí o no sobre si el objetivo está cumplido: tests en verde, typecheck limpio, un schema que valida la salida o un eval puntuado. Sin esa señal, el agente termina cuando cree que ha terminado, y esa creencia no se puede auditar.

    ¿Cuándo no conviene usar un agente de IA?

    Cuando falla alguna de estas tres condiciones. Que exista una señal automática capaz de decir si el trabajo está bien hecho sin que lo revises tú. Que el camino no sea siempre el mismo, porque si el flujo es idéntico en casi todas las ejecuciones estás pagando por redescubrir un orden que ya conoces. Y que el error sea reversible: sobre datos de producción, borrados o despliegues sin rollback, el modelo propone y tú apruebas.

    ¿Es lo mismo un agente de IA que un sistema multi-agente?

    No, y encadenar varios modelos no hace el sistema "más agéntico". Un sistema multi-agente reparte el trabajo entre varias instancias con roles distintos, y cada salto pierde contexto, suma latencia y multiplica el coste. Muchas veces lo que se ha modelado como un segundo agente debería haber sido una herramienta del primero. Empieza con un solo agente y varias herramientas.

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

  • n8n local en Docker: Automatiza tu negocio gratis

    n8n local en Docker: Automatiza tu negocio gratis

    El año pasado, una pequeña automatización de mi negocio que enviaba facturas automáticas y registraba nuevos alumnos en Notion empezó a recibir más tráfico de lo habitual. A las pocas horas, Zapier me envió una alerta: me había pasado del límite de tareas y mi tarifa mensual iba a subir de $20 a $120 USD.

    ¿$120 al mes por mover texto de una API a otra?

    Apagué la cuenta de inmediato. Como desarrollador, pagar suscripciones abusivas en la nube por correr tareas en segundo plano que puedo alojar yo mismo va en contra de mis principios.

    Hoy te quiero explicar cómo montar n8n local en Docker, permitiéndote automatizar todas las operaciones de tu negocio, integrar APIs y conectar modelos de IA de forma 100% gratuita y sin límites de ejecución.

    Por qué n8n en local supera a Zapier o Make

    Zapier y Make son herramientas fantásticas para perfiles no técnicos, pero para un programador, sus límites de uso son una cárcel. n8n es una alternativa de código abierto y flujo visual que te da el control absoluto:

    1. Sin límites de ejecuciones: Puedes correr 100,000 flujos de trabajo al día. Tu único límite es la memoria y CPU de tu máquina o servidor.
    2. Integración con código real: n8n te permite escribir nodos en JavaScript o Python directamente en el flujo para manipular datos complejos sin lidiar con limitaciones del editor visual.
    3. Privacidad total: Si manejas datos sensibles de tus clientes o APIs de producción, la información nunca sale de tu servidor local.

    La plantilla docker-compose.yml para n8n local

    La forma más sólida y limpia de correr n8n de manera ininterrumpida en tu ordenador o en un VPS es mediante Docker Compose. Mapearemos los datos del flujo de trabajo a un volumen local para garantizar que no pierdas tus credenciales ni tus integraciones al reiniciar el contenedor.

    Crea un archivo llamado docker-compose.yml en tu máquina:

    version: '3.8'

services:
  n8n:
    image: docker.n8n.io/n8nio/n8n:latest
    container_name: n8n_local
    restart: unless-stopped
    ports:
      - "5678:5678"
    environment:
      - N8N_HOST=localhost
      - N8N_PORT=5678
      - N8N_PROTOCOL=http
      - NODE_ENV=production
      - WEBHOOK_URL=http://localhost:5678/
    volumes:
      # Persistencia de credenciales y flujos de n8n
      - n8n_data:/home/node/.n8n

volumes:
  n8n_data:
    driver: local

    Cómo arrancar y acceder:

    1. Abre tu terminal en la carpeta del archivo YAML.
    2. Levanta el servicio con: docker compose up -d.
    3. Abre tu navegador en: http://localhost:5678.

    Listo. Tienes un entorno de automatización profesional con más de 400 integraciones nativas corriendo de forma local en tu máquina.

    Cómo recibir Webhooks en local usando Túneles Seguros

    Uno de los principales problemas de correr n8n de forma local es que las APIs externas (como Stripe o MailerLite) necesitan enviar datos a una URL pública cada vez que ocurre un evento (un Webhook).

    Si tu n8n está en localhost, Stripe no podrá enviarle nada.

    Para solucionar esto sin tener que desplegar n8n en un servidor en la nube de inmediato, puedes usar túneles seguros como ngrok o localtonel.

    Por ejemplo, con una sola línea en tu consola local puedes exponer el puerto de n8n al mundo:

    npx localtunnel --port 5678

    Esto te devolverá una URL pública temporal (ej. https://random-subdomain.localtunnel.me). Copia esa URL, configúrala en la variable WEBHOOK_URL de tu archivo .env de n8n y utilízala para registrar los webhooks en tus herramientas externas. Todo el tráfico externo llegará a tu n8n local de forma instantánea.

    Este enfoque de optimización de costes y uso de herramientas locales para automatizar procesos de negocio es uno de los pilares que tratamos en el curso de Construye con IA para construir bucles agénticos y automatizaciones eficientes.

    Conclusión: Sé dueño de tu infraestructura

    No regales tu dinero a plataformas cloud por mover JSONs sencillos entre APIs. Al aprender a auto-albergar n8n con Docker, rompes los límites artificiales de tareas y puedes diseñar automatizaciones complejas de leads, reportes y triggers de bases de datos de forma 100% gratuita.

    Si quieres aprender a integrar n8n local con tus bases de datos de producción y ver flujos reales de automatización de negocio, te espero en Dominicode Labs.

    Preguntas Frecuentes (FAQ)

    ¿n8n local es realmente gratis para uso personal?

    Sí. n8n tiene una licencia fair-code. Es 100% gratuito para uso personal y para automatizar las operaciones internas de tu propia empresa. Solo requiere pago de licencia si pretendes revender n8n como un servicio SaaS a terceros.

    ¿Cómo guardo mis flujos de n8n para no perderlos?

    Al mapear el volumen - n8n_data:/home/node/.n8n en tu configuración de Docker Compose, toda la información de flujos, variables y claves de API se almacena de forma persistente en tu máquina local. Aunque detengas o actualices el contenedor, no perderás nada.

    ¿Se pueden ejecutar scripts de JavaScript o Python en n8n local?

    Sí, n8n cuenta con nodos de ejecución de código nativos. En su versión local en Docker, puedes escribir y testear scripts complejos utilizando librerías de Node.js o Python para manipular los datos entrantes de tus integraciones.

    ¿Cómo migrar mis flujos locales a un VPS en la nube?

    Solo debes copiar tu archivo docker-compose.yml a tu VPS, levantar el servicio y utilizar la herramienta interna de n8n para importar/exportar tus flujos en formato JSON de forma directa y sin perder configuraciones.

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

  • Guía: Cómo desplegar Hermes Agent en tu propio VPS con Docker

    Guía: Cómo desplegar Hermes Agent en tu propio VPS con Docker

    Ayer me escribió un alumno de Dominicode. Estaba entusiasmado probando agentes autónomos de IA, pero los tenía corriendo localmente en su portátil. El problema era obvio: cada vez que cerraba la tapa para irse a dormir, su bot de soporte en Telegram se apagaba por completo.

    Un agente autónomo a tiempo parcial no es un agente autónomo; es un script de oficina con horario comercial.

    Para que un agente de IA trabaje por ti, monitoree tus servidores y atienda a tus clientes las 24 horas del día, necesita vivir en la nube. Y la forma más barata, segura y escalable de hacerlo es desplegar Hermes Agent en un VPS.

    Hoy te quiero enseñar la guía paso a paso para desplegar este framework en tu propio servidor VPS usando Docker Compose y garantizando que tu agente tenga memoria persistente ante cualquier reinicio.

    ¿Por qué elegir un VPS en lugar de plataformas Serverless?

    Las plataformas serverless o FaaS (como AWS Lambda o Vercel Functions) son excelentes para APIs tradicionales, pero fallan al hospedar agentes de IA de largo recorrido por dos motivos:

    1. Limitación de tiempo de ejecución: Un agente autónomo puede tardar varios minutos en razonar, ejecutar código de diagnóstico en bucle y responder. Las funciones Serverless suelen expirar a los pocos segundos.
    2. Falta de persistencia local: Los agentes necesitan una base de datos de memoria (SQLite/vectorial) y una carpeta de habilidades locales (Skills). Las arquitecturas efímeras borran estos archivos al apagarse.

    Un VPS (de proveedores como Hetzner, DigitalOcean o Linode) te da control absoluto del hardware, un runtime continuo sin límites de tiempo y almacenamiento en disco persistente por una fracción del costo.

    La configuración de producción: docker-compose.yml

    Para desplegar a Hermes 24/7 de forma aislada y segura, utilizaremos Docker Compose. Mapearemos el almacenamiento del agente a volúmenes del sistema anfitrión para blindar su memoria SQLite y sus habilidades autogeneradas contra caídas.

    Crea un archivo llamado docker-compose.yml en la carpeta de tu proyecto en el VPS:

    version: '3.8'

services:
  hermes:
    image: nousresearch/hermes-agent:latest
    container_name: hermes_agent_prod
    restart: unless-stopped
    environment:
      - NODE_ENV=production
      - OPENROUTER_API_KEY=${OPENROUTER_API_KEY}
      - TELEGRAM_BOT_TOKEN=${TELEGRAM_BOT_TOKEN}
      - TELEGRAM_ADMIN_CHAT_ID=${TELEGRAM_ADMIN_CHAT_ID}
      - NOTION_API_KEY=${NOTION_API_KEY}
    volumes:
      # Persistencia de la base de datos de memoria SQLite local
      - hermes_data:/app/data
      # Habilidades/Skills autogeneradas por el agente
      - ./skills:/app/skills
      # Acceso seguro a Docker para el sandbox de diagnóstico
      - /var/run/docker.sock:/var/run/docker.sock
    ports:
      - "3000:3000"
    deploy:
      resources:
        limits:
          cpus: '1.0'
          memory: 1G

volumes:
  hermes_data:
    driver: local

    Explicación técnica de los volúmenes mapeados:

    • hermes_data:/app/data: Aquí es donde Hermes guarda su base de datos de memoria SQLite. Si no la persistes en disco, tu agente olvidará las conversaciones previas con los usuarios cada vez que actualices el contenedor.
    • ./skills:/app/skills: Esta carpeta almacena los scripts que el agente auto-programa cuando aprende una nueva habilidad a través del Self-Improving Loop. Al mapearla, las nuevas herramientas persisten en tu VPS.
    • /var/run/docker.sock:/var/run/docker.sock: Permite al agente arrancar contenedores Docker efímeros de forma aislada para realizar diagnósticos y testear scripts sin comprometer la seguridad del VPS principal. Como vimos en nuestro post anterior, esto es clave para implementar un Docker Sandbox seguro en producción.

    Guía de Despliegue en 4 Pasos

    Una vez configurado tu VPS con Docker y Docker Compose instalados, el despliegue se reduce a cuatro comandos de terminal:

    Paso 1: Configurar las variables de entorno

    Crea un archivo .env en la misma carpeta que tu docker-compose.yml e introduce tus claves de API privadas:

    OPENROUTER_API_KEY=tu_clave_de_openrouter
TELEGRAM_BOT_TOKEN=tu_token_de_telegram
TELEGRAM_ADMIN_CHAT_ID=tu_id_de_chat
NOTION_API_KEY=tu_token_de_notion

    Paso 2: Crear el directorio de Skills

    Asegúrate de que la carpeta local para las habilidades del agente existe en el sistema de archivos:

    mkdir -p skills

    Paso 3: Levantar el contenedor en segundo plano

    Ejecuta el comando para descargar e inicializar el agente en modo demonio (-d):

    docker compose up -d

    Paso 4: Monitorear la inicialización

    Verifica que el agente se ha conectado correctamente a tus canales de mensajería leyendo los logs en tiempo real:

    docker compose logs -f hermes

    Si has configurado correctamente las variables, verás un log indicando que el gateway de Telegram está activo y listo para recibir preguntas de tus usuarios.

    Este es el proceso exacto que seguimos al construir integraciones seguras en el curso de Construye con IA para automatizar flujos comerciales, y que extendemos al despliegue Git-Ops en Railway en el nuevo [curso de Agentes IA Autónomos en Producción con Hermes Agent]([ENLACE PENDIENTE]).

    Conclusión: Pon tu agente a trabajar 24/7

    Configurar tu agente en local es genial para desarrollar la primera tarde. Pero para automatizar tu marketing, calificar prospectos o mantener tu servidor monitoreado, el agente debe estar activo de forma ininterrumpida. Un VPS de 5 dólares al mes y Docker es todo lo que necesitas para lograrlo.

    Si quieres debatir sobre configuraciones avanzadas de seguridad en servidores de producción y cómo optimizar la persistencia de tus agentes, te espero en Dominicode Labs.

    Preguntas Frecuentes (FAQ)

    ¿Qué requisitos mínimos de VPS se necesitan para Hermes Agent?

    Se recomienda un VPS con al menos 1 vCPU y 1GB o 2GB de memoria RAM. Dado que el procesamiento del modelo de lenguaje se realiza mediante APIs en la nube (como OpenRouter o Anthropic), el VPS del agente solo necesita recursos para ejecutar la lógica de control y levantar sandboxes de Docker ligeros.

    ¿Cómo puedo asegurar que la base de datos de memoria no se corrompa en el VPS?

    Docker gestiona los volúmenes locales de forma segura. Al usar la directiva restart: unless-stopped, el demonio de Docker se encargará de levantar al agente ante cualquier caída del servidor o reinicio programado del VPS, manteniendo la base de datos SQLite a salvo.

    ¿Por qué se mapea el socket de Docker (/var/run/docker.sock)?

    El socket de Docker permite al contenedor de Hermes comunicarse con el motor de Docker del VPS. Esto es necesario para que el agente pueda iniciar contenedores hijos aislados (sandboxes) para ejecutar y verificar scripts generados por IA de forma totalmente segura.

    ¿Puedo desplegar Hermes Agent con Git-Ops en lugar de Docker Compose manual?

    Sí. Puedes vincular tu repositorio de GitHub a herramientas como Portainer en tu VPS o utilizar plataformas de nube como Railway que realizan despliegues automatizados basados en ramas de Git, configurando los mismos volúmenes y variables de entorno detallados en esta guía.

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

  • Loop Engineering: La evolución definitiva del desarrollo con IA

    Loop Engineering: La evolución definitiva del desarrollo con IA

    En 2021 instalé la primera beta de GitHub Copilot. Recuerdo la sensación de pulsar la tecla Tab y ver cómo el editor completaba una línea de código entera o sugería una función trivial. En aquel momento, parecía magia negra.

    Hoy, esa magia me parece prehistórica.

    El autocompletado de código y los asistentes de chat interactivos han dejado de ser el estado del arte. El desarrollo de software ha entrado en una fase más profunda: la era de Loop Engineering.

    Hoy te quiero explicar el viaje evolutivo que nos ha traído hasta aquí y por qué diseñar bucles de ejecución autónomos es la habilidad definitiva que diferenciará a los desarrolladores senior en los próximos años. En mi post anterior vimos cómo implementar este bucle agéntico de auto-aprendizaje con Hermes Agent, pero hoy nos enfocaremos en la filosofía de desarrollo.

    La Curva Evolutiva del Código con IA

    Para entender dónde estamos hoy, debemos analizar las cuatro iteraciones que ha vivido la inteligencia artificial aplicada a la programación:

    Iteración 1: El Tabulador Pasivo (Autocomplete)

    Es la era de GitHub Copilot clásico. La IA actúa como un autocompletado avanzado que predice los siguientes caracteres basándose en el contexto del archivo actual. Tú sigues sentado frente al teclado, picando código línea por línea, y la IA simplemente te ahorra pulsaciones.

    Iteración 2: El Asistente conversacional (Chat)

    La llegada de ChatGPT. Aquí el flujo pasa de la línea al bloque. El desarrollador copia un trozo de código roto, lo pega en una ventana de chat y le pide a la IA que lo arregle o añada tests. La IA devuelve el código corregido y el humano tiene que copiarlo, pegarlo de vuelta y probar si funciona.

    Iteración 3: El Desarrollo Agéntico interactivo (Cursor / Claude Code)

    El software empieza a tomar acción. La IA ya no solo te da texto: tiene herramientas. Puede leer tus archivos locales, realizar búsquedas, proponer planes y escribir código directamente en tu editor. Herramientas como Claude Code o Cursor actúan como un junior a tu lado que ejecuta órdenes en caliente, pero siguen requiriendo que estés frente a la pantalla validando y guiando cada paso.

    Iteración 4: Loop Engineering (Automatización autónoma)

    Aquí el desarrollador deja de programar de forma interactiva. En su lugar, diseña un bucle agéntico (agentic loop) cerrado. El desarrollador define una especificación de entrada y unas reglas de éxito claras.

    El agente ejecuta el plan, corre los tests, lee los errores de compilación, corrige su propio código en bucle y se auto-mejora sin que tú tengas que intervenir. Ese salto —de una IA que solo genera texto a una que actúa y verifica— es la diferencia entre IA generativa e IA agéntica, y es la que decide qué stack montas.

    ¿Por qué Loop Engineering es el fin del "Vibe Coding"?

    El vibe coding (sentarse a tirar prompts a un chat esperando que la IA cree tu app por arte de magia) tiene un límite claro: la complejidad. En proyectos reales, la primera propuesta de la IA casi nunca funciona a la primera. Requiere iteración.

    En el paradigma de Loop Engineering, tu trabajo ya no es guiar a la IA paso a paso. Tu trabajo es estructurar el entorno para que la IA se guíe a sí misma de forma segura:

    1. Definir especificaciones robustas: Antes de escribir una sola línea de código, necesitas definir la arquitectura en un documento claro. Este es el principio que defiendo en mi libro de SDD: Spec-Driven Development para dar a los agentes la directriz exacta de éxito.
    2. Entornos de Sandbox: Crear sandboxes seguros de Docker donde el agente pueda compilar y romper cosas sin peligro.
    3. Evals y Tests automatizados: El bucle necesita saber si ha tenido éxito. Si tus tests están bien diseñados, el agente puede correrlos en bucle hasta que todos pasen a verde.

    El desarrollador como Ingeniero de Bucles

    El futuro de nuestra profesión no es picar código rápido; es diseñar los sistemas que pican código.

    Un Ingeniero de Bucles (Loop Engineer) no le dice a la IA: "escribe esta función". Le dice: "este es el repositorio, este es el bug en producción, estas son las reglas de seguridad y este es el test que debe pasar. Llámame cuando el test esté en verde o si encuentras un bloqueo insalvable".

    Esta transición es exactamente la que aplicamos en el curso de Construye con IA para automatizar procesos de negocio complejos, y la que llevamos a su máximo exponente con herramientas de larga duración en el nuevo [curso de Agentes IA Autónomos en Producción con Hermes Agent]([ENLACE PENDIENTE]).

    Conclusión: Deja de picar código, diseña los bucles

    El autocompletado te hace un 20% más rápido. Un chat te ahorra un 40% del tiempo de investigación. Pero un bucle agéntico autónomo que trabaja en segundo plano te da un apalancamiento infinito.

    Si quieres debatir con otros desarrolladores senior sobre cómo diseñar estos pipelines de automatización y el futuro de nuestra profesión, te espero en Dominicode Labs.

    Preguntas Frecuentes (FAQ)

    ¿Qué es exactamente el Loop Engineering?

    Loop Engineering es la práctica de diseñar, estructurar y optimizar entornos de software cerrados donde los agentes de IA operan en bucles autónomos (planificar → codificar → probar → depurar) para resolver problemas de desarrollo complejos sin supervisión humana constante.

    ¿Cuál es la diferencia entre desarrollo agéntico y Loop Engineering?

    El desarrollo agéntico interactivo (como usar Cursor) requiere la supervisión constante de un humano que lee las propuestas de la IA y aprueba sus cambios paso a paso. Loop Engineering automatiza ese proceso delegando la iteración (las correcciones de compilación y pruebas de bugs) a un bucle de ejecución autónomo en segundo plano.

    ¿Qué rol juegan las especificaciones en el Loop Engineering?

    El agente de IA necesita saber cuándo ha completado la tarea de forma correcta. Un documento de especificaciones técnicas (Spec) bien estructurado actúa como el "contrato de éxito" que el agente utiliza para auto-evaluar sus propuestas de código en cada iteración del bucle.

    ¿Cómo puedo empezar a aplicar Loop Engineering hoy?

    Puedes empezar estructurando tus proyectos bajo el enfoque TDD (Desarrollo Guiado por Pruebas). Si creas tests unitarios claros antes de invocar a tu agente (como Claude Code), puedes configurarlo para que ejecute el comando de pruebas de forma recurrente y no detenga su ejecución hasta que todas las pruebas pasen con éxito.

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