Dominicode

Hoy tengo un invitado que tenía muchas ganas de traer a Dominicode:

Héctor de León 🙌

Y no quiero hacer el típico live de:

¿Qué herramienta de IA utilizas?

Quiero ir un poco más lejos.

Quiero hablar de qué está pasando realmente con nuestra profesión.

¿Seguiremos escribiendo código?

¿Nos convertiremos en supervisores de agentes?

¿Un junior debería aprender primero fundamentos o empezar directamente con IA?

¿Quién revisa todo el código que estamos generando?

Y sobre todo:

¿Qué significa ser programador en 2026?

🔴 Estamos en directo dentro de 2 horas.
19:00 🇪🇸

Te espero en Dominicode.

https://www.youtube.com/live/OCTDJ3lFs9c?si=22m6_3L9kuWfAq_b

EN VIVO con Héctor de León | ¿Qué significa programar en 2026? En este live de Dominicode converso con Héctor de León sobre uno de...

¿Cuántas veces le has pedido a la IA que arregle algo que ella misma rompió la sesión anterior?

Eso no es un problema de modelo. Es un problema de spec.

📖 SDD: Construye con control
👉

Spec Driven Development El método para construir con IA sin perder el control. PRDs, specs y flujos de ejecución para developers que quieren resultados reales.

Hace dos semanas escribí sobre por qué el contexto — no el modelo — es el cuello de botella real de los agentes de IA. Desde entonces he estado grabando un curso sobre Hermes Agent, y hay algo que se me quedó claro trabajando con él a diario: no es una herramienta más. Es una forma distinta de pensar dónde vive un agente. Y esa forma va a ganar.

No es una predicción de hype. Es una observación de patrón.

El patrón que se repite

Todas las herramientas de IA para developers que uso a diario — Claude Code, Cursor, los subagentes de los que hablé en la edición #6 — comparten una limitación estructural: viven dentro de una sesión. Abres el editor, el agente trabaja contigo, cierras el editor, el agente se apaga. Si quieres que siga trabajando mientras duermes, necesitas dejar la laptop prendida y cruzar los dedos.

Hermes Agent no tiene esa limitación porque no está diseñado para vivir en un editor. Está diseñado para vivir en un servidor.

Eso cambia todo lo demás:

Corre sandboxed en Docker, así que puede ejecutar tareas sin que tú estés supervisando cada comando — el aislamiento es lo que hace posible confiarle algo desatendido.

Tiene memoria persistente en capas (no un archivo de contexto que se llena y hay que limpiar a mano). Cuando termina una tarea, lo que aprendió queda escrito — no vive solo en la ventana de contexto de esa sesión.

Se conecta donde tú ya trabajas — no te obliga a abrir una app nueva. Vía MCP puede hablar con herramientas como Notion, y tiene un scheduler tipo cron para tareas que se repiten sin que nadie las dispare a mano.

Ninguna de esas tres cosas es "inteligencia". Es infraestructura. Y la infraestructura es exactamente lo que decide qué herramientas se vuelven parte de un proyecto real y cuáles se quedan en el tab del navegador que abriste una vez para probar.

Por qué "común en proyectos" y no "reemplaza tu editor"

Aquí es donde quiero ser honesto: Hermes Agent no compite con Claude Code o Codex para escribir código. No es su trabajo. Lo que hace bien es todo lo que rodea al código y normalmente nadie automatiza porque no vale la pena abrir una sesión de editor para eso:
Un scheduler que corre una auditoría de dependencias cada lunes sin que tengas que acordarte.

Un proceso que lee tickets nuevos, les añade contexto de tareas parecidas ya resueltas, y los deja listos para que alguien del equipo los tome.

Un agente que monitorea un repo, un competidor, o un canal de soporte 24/7 y solo te avisa cuando hay algo que de verdad requiere tu atención.

Ese tipo de trabajo — continuo, de bajo criterio pero alto volumen, que hoy nadie hace porque "no da tiempo" — es exactamente el hueco que un agente que vive fuera del editor puede llenar. Y es un hueco que existe en casi cualquier equipo de desarrollo, no solo en el mío.

Lo que todavía no está resuelto

Sigue siendo software open source en evolución activa — la imagen de Docker de Hermes se actualiza casi cada semana, lo cual es bueno para quien lo sigue de cerca pero significa que no es "instálalo y olvídate" todavía. Si vas a correr algo que te importa sobre esto, trátalo como tratarías cualquier pieza de infraestructura joven: con actualizaciones controladas, no en automático sin revisar el changelog.

En resumen:

La limitación real de la mayoría de agentes de IA para devs no es la inteligencia del modelo, es que viven y mueren con la sesión del editor

Hermes Agent resuelve eso con tres piezas de infraestructura, no de magia: sandboxing en Docker, memoria persistente en capas, e integración vía MCP/cron con las herramientas donde ya trabajas

No reemplaza a Claude Code o Codex escribiendo código — llena el hueco del trabajo continuo de bajo criterio y alto volumen que hoy nadie automatiza

Sigue siendo joven: trátalo como infraestructura en evolución, con updates controlados

Siguiente paso concreto: si tienes una tarea que repites cada semana sin pensar demasiado — un reporte, una auditoría, un resumen — esa es la candidata perfecta para probar este patrón, con Hermes Agent o con lo que tengas a mano.

La mayoría de los "agentes de IA" que ves hoy son un chat con esteroides.

Le escribes, responde, cierras la pestaña. Si reinicias el servidor, no recuerda nada de lo que pasó.

Eso no es un agente autónomo — es un chatbot con mejor marketing.

La diferencia real está en 3 cosas que casi nadie explica:

1️⃣ No dependen de un bucle síncrono. Corren en background, esperando eventos — un mensaje, una tarea programada, un webhook — sin que nadie tenga que estar frente a la pantalla.

2️⃣ Tienen memoria que persiste de verdad. Sobrevive a un reinicio del servidor porque vive en disco, no en la sesión del chat.

3️⃣ Aprenden solos. Cuando el agente resuelve algo complejo por primera vez, se escribe su propia "skill" — la próxima vez que aparezca algo parecido, ya sabe cómo resolverlo. Nadie tiene que programarla a mano.

Esto no es una promesa de marketing — es la arquitectura real de Hermes Agent, el framework open source de Nous Research que estamos documentando a fondo en Dominicode.

Armamos un kit gratuito con la chuleta de comandos CLI real y la configuración de seguridad (sandbox aislado, reglas de aprobación) para quien quiera desplegar su primer agente de este tipo — todo verificado contra la documentación oficial, nada inventado.

Link en el primer comentario. 👇

El developer que solo implementa va a quedar rezagado.

No porque sea menos inteligente.
Sino porque alguien con el mismo nivel técnico, que además sabe hacer Spec → Build → Deploy → Review con agentes, va a mover 3 veces más rápido.

No es exageración. Lo veo cada semana.

Este jueves 25 de junio hago un webinar gratuito junto a Raymond Coplin (CEO de Perxist Devs, 15+ años construyendo apps empresariales) donde vamos a mostrar en vivo exactamente ese ciclo.

55 minutos. Sin slides de relleno.

→ Por qué quedarte solo en implementación te frena
→ Demo en vivo: un proyecto real pasando por Spec → Implement → Deploy → Review
→ Q&A al final

Es gratuito. Es el 25 de junio a las 18:00 AST.

Si usas IA para codear pero sientes que no tienes un proceso real — este webinar es para ti.

👉

Webinar Gratuito — De programador a product builder Ves el ciclo SDLC AI completo sobre una feature real en 55 minutos. Spec → Implement → Deploy → Review. Gratis, en vivo, sin pitch. Jueves 25 Jun 2026 · 18:00 Rep. Dominicana.

Spec-Driven Development consiste en construir software a partir de una especificación previa.

El vibe coder celebra el lunes. Debuggea el viernes.

Generar código no es saber programar.
Saber dirigir un agente, sí.

Webinar gratuito — 25 de junio.

Webinar Gratuito — De programador a product builder Ves el ciclo SDLC AI completo sobre una feature real en 55 minutos. Spec → Implement → Deploy → Review. Gratis, en vivo, sin pitch. Jueves 25 Jun 2026 · 18:00 Rep. Dominicana.

El 90% de los developers que usan AI tienen el mismo problema.

No es el modelo. No es el prompt.

Es que siguen pensando como operarios cuando ya deberían pensar como directores.

"Vibe coding" es la versión romantizada de improvisar.
Le llaman velocidad. En realidad es deuda.

El 25 de junio — webinar gratuito con Raymond Coplin (Perxist Devs) y yo.
55 minutos. El ciclo SDLC AI completo sobre una feature real.

Webinar Gratuito — De programador a product builder Ves el ciclo SDLC AI completo sobre una feature real en 55 minutos. Spec → Implement → Deploy → Review. Gratis, en vivo, sin pitch. Jueves 25 Jun 2026 · 18:00 Rep. Dominicana.

Claude Opus 4.8 + Workflows: el turbo de tus agentes

Cómo orquestar múltiples subagentes para automatizar trabajo real en minutos

El lunes pasado estaba revisando un PR con 47 archivos modificados.

Abro Claude Code, le digo que lo revise. Lo hace. Pero a mitad del proceso pienso: ¿y si mientras revisa el código también genera la documentación y abre el PR en GitHub?

Eso antes requería tres sesiones separadas. Ahora no.

El problema que todos tenemos como devs

Usamos IA de forma lineal. Pregunta — respuesta. Tarea — resultado. Un modelo, un contexto, una cosa a la vez.

El problema es que el trabajo real no es lineal. Un feature nuevo implica escribir código, actualizar tests, generar documentación, revisar que no rompa nada, abrir el PR y dejarlo listo para revisión humana. Son seis tareas distintas, con dependencias entre ellas.

Hacer eso con un solo agente secuencial es lento. Y además mezcla responsabilidades en un solo contexto que se va degradando con cada mensaje.

La solución no es un agente más inteligente. Es una arquitectura mejor.

Claude Opus 4.8: el modelo que no le tiembla el pulso

Antes de hablar de Workflows, hay que entender con qué modelo los vas a ejecutar.

Claude Opus 4.8 es el modelo más potente de Anthropic en este momento. Está diseñado para tareas que requieren razonamiento profundo: analizar bases de código completas, tomar decisiones con contexto ambiguo, generar código correcto en la primera pasada, coordinar trabajo complejo con múltiples dependencias.

No es el modelo más rápido ni el más barato. Es el que uso cuando el costo de un error es alto o cuando la tarea requiere que alguien realmente "piense" antes de actuar. Para tareas de orquestación donde necesitas que el agente razone bien sobre qué delegar a quién, Opus 4.8 es la elección correcta.

Claude Code Workflows: orquestación real con JS

Los Workflows en Claude Code son scripts JavaScript que coordinan múltiples subagentes. En lugar de un solo agente haciendo todo, defines una arquitectura donde cada agente tiene una responsabilidad clara.

Las primitivas clave son cuatro:

agent() — lanza un subagente con su propio contexto e instrucciones

pipeline() — ejecuta agentes en secuencia

parallel() — ejecuta agentes en paralelo cuando no hay dependencia entre ellos

phase() — agrupa pasos lógicos dentro de un workflow más grande

Ejemplo concreto — workflow que revisa un PR, genera docs y lo abre en GitHub:

import { pipeline, parallel, agent, phase } from "/claude-code";

export default pipeline([
phase("analysis", [
parallel([
agent("code-reviewer", {
model: "claude-opus-4-8",
prompt: `Review changes in ${process.env.PR_BRANCH}.
Focus: bugs, edge cases and breaking changes.`
}),
agent("test-checker", {
model: "claude-opus-4-8",
prompt: `Verify that all changes have tests.
List files without adequate coverage.`
})
])
]),
phase("documentation", [
agent("doc-writer", {
model: "claude-opus-4-8",
prompt: `Generate PR description, changelog entry
and inline comments for critical issues.`
})
]),
phase("publish", [
agent("pr-opener", {
model: "claude-opus-4-8",
prompt: `Open the PR on GitHub. If there are critical issues,
mark it as draft.`
})
])
]);

Este workflow reemplaza 20-30 minutos de trabajo manual por 2-3 minutos de ejecución. Y lo más importante: es reproducible. Cada PR pasa por el mismo proceso, con el mismo estándar.

Por qué esto cambia las reglas para ti como dev

No estamos hablando de un chatbot más sofisticado. Estamos hablando de arquitectura de software aplicada a agentes de IA.

Cuando defines un Workflow, estás separando responsabilidades, gestionando dependencias y ejecutando en paralelo cuando puedes. Son los mismos principios que aplicamos en backend desde hace décadas, ahora aplicados a trabajo cognitivo.

El cambio de paradigma es este: dejas de usar IA como herramienta de productividad personal y empiezas a usarla como infraestructura. Aunque trabajes solo, como yo.

Casos de uso donde ya aplico esto en Dominicode: revisión automática de código antes de cada merge, generación de scripts de video a partir de un brief, pipeline completo de publicación de posts del blog. Todo con Workflows, todo con Opus 4.8 en los nodos críticos.

Lo que debes hacer esta semana

Instala la versión más reciente de Claude Code y revisa la documentación de Workflows. Hay pocos recursos en español todavía.

Identifica una tarea repetitiva de 3+ pasos en tu workflow de desarrollo. Ese es tu primer candidato para automatizar.

Escribe tu primer Workflow con dos agentes en paralelo. No tiene que ser perfecto. Tiene que correr.

Build con IA · por Bezael Pérez · dominicode.com