Estos días trabajo en varios proyectos a la vez y casi todo el código lo escriben agentes de IA. Lo que hace que eso funcione no es un solo modelo, sino el flujo que hay alrededor: una terminal que mantiene vivas las sesiones, un harness como Claude Code, skills con mis reglas y git worktrees para que los agentes no se pisen.

En este artículo te resumo ese flujo tal como lo muestro en el video, mientras creo desde cero una plataforma de cursos al estilo Udemy. La idea no es terminar el proyecto, sino que veas los comandos y herramientas que uso a diario para que puedas mejorar tu propio entorno.

Herdr: el lugar donde corren mis agentes

El primer programa es Herdr. Su web lo define como "el runtime donde corren los agentes de programación": un multiplexor de terminal pensado para agentes, open source (Apache 2.0), escrito en Rust y disponible para macOS, Linux y Windows (este último en beta) (herdr.dev, repositorio).

Lo que más uso de Herdr:

  • Sesiones que no se mueren. Puedes cerrar la ventana de la terminal y el servidor de Herdr sigue corriendo con todos tus agentes; al volver a abrirlo, están ahí (quick start).
  • Máquinas locales y remotas en el mismo lugar. Puedes tener sesiones en tu computador y en un servidor por SSH, algo muy útil si trabajas con un entorno en la nube (documentación).
  • Mouse o teclado. Funciona con clic, arrastrar y dividir paneles, y también con atajos con prefijo al estilo tmux (ctrl+b).
  • Estado de cada agente. Marca cada panel como trabajando, bloqueado o inactivo, y puede avisarte con notificaciones o sonidos cuando un agente termina o necesita algo (configuración).

Orca y tmux

Hay dos alternativas que vale la pena conocer. Orca, de Stably AI, es open source (MIT) y tiene interfaz gráfica: editor con explorador de archivos, terminales y agentes en paralelo, cada uno en su propio worktree (onorca.dev, repositorio). Si te gusta trabajar con ventanas y botones, está muy bien.

La otra es tmux (repositorio oficial), el multiplexor de toda la vida: múltiples sesiones, paneles divididos y atajos. Herdr hace lo mismo, pero enfocado en agentes. Yo me quedo con Herdr porque es muy ligero: al final es una terminal.

Claude Code, Codex y Hermes en el mismo lugar

Herdr no reemplaza a tu harness: lo que hace es juntarlos. En el mismo workspace puedo tener Claude Code, Codex u Hermes Agent (el agente de Nous Research, que suelo usar conectado a una instancia remota) y saltar de uno a otro. Así aprovechas todas tus suscripciones desde una sola terminal.

Crear el proyecto: alias, status line y permisos

Un consejo antes de pedir nada: ten un solo lugar donde vivan tus proyectos y muévete ahí desde la terminal antes de lanzar Claude Code, en lugar de pedirle al agente que cree la carpeta.

En mi caso uso un alias (cl) que lanza Claude Code saltándose los permisos, y una status line personalizada que muestra el directorio, el modelo, cuánto llevo de la ventana de contexto y cuánta cuota me queda (status line).

Sobre los permisos: Claude Code tiene varios modos (por defecto, aceptar ediciones, plan, auto, entre otros) y se alternan con Shift+Tab (modos de permisos). Yo casi siempre trabajo sin pedir permisos, pero no a ciegas: leo lo que va a hacer, sobre todo cuando la característica es complicada. Si prefieres ir más seguro, el modo auto revisa cada acción con un clasificador.

Modo plan antes de escribir código

El prompt de la demo es sencillo: "crea una plataforma de venta de cursos, los cursos son videos con capítulos, al estilo de Udemy". Si sabes de código, conviene darle el stack (por ejemplo Next.js para el frontend, Hono para el backend y PostgreSQL).

Pero sobre todo, si estás haciendo vibe coding, no empieces pidiendo que lo construya: cambia al modo plan. En ese modo Claude Code no puede escribir nada hasta que apruebes el plan; primero analiza lo que quieres, te hace preguntas (modelo de negocio, dónde alojar los videos, extras como reseñas o certificados) y te devuelve un resumen.

Ese resumen hay que leerlo. Ahí puedes ver si eligió una versión antigua de una biblioteca, un ORM que no quieres o una librería de componentes que prefieres cambiar. Aunque no lo entiendas todo, con el tiempo te vas acostumbrando a esos términos.

Mis skills de Claude Code

Al planificar, Claude Code cargó dos de mis skills. Las skills personales viven en ~/.claude/skills/<nombre>/SKILL.md (documentación) y no tienen nada de mágico: son guías en Markdown con mis preferencias.

Por ejemplo, tengo una con mi forma de construir apps (validaciones, correos transaccionales, subida de archivos, modo oscuro, autenticación con recuperación de contraseña), otra que le recuerda que en local uso Docker y que revise si un puerto ya está ocupado, otra para hacer commits sin repetir instrucciones y otra de revisión de código que lanza varias revisiones (tests, mantenibilidad, duplicación, consistencia). Todas empiezan por fx para encontrarlas rápido.

Si trabajas mucho con un framework, este es el lugar para poner tus reglas.

El grado de esfuerzo del modelo

Si pagas una suscripción, mi recomendación es subir el esfuerzo del modelo antes de planificar. Con /effort puedes elegir entre low, medium, high, xhigh y max; en Opus 5.5 el valor por defecto es medium (configuración del modelo).

Yo uso xhigh. En el video comento que en su propio benchmark rinde mejor que max, y el matiz es este: según la system card de Opus 5.5, xhigh saca 66,4 % en Terminal-Bench 4.0 frente a 64,8 % de max, una diferencia que Anthropic considera dentro del ruido; en otros benchmarks max queda algo por encima. Lo interesante es que xhigh logra un rendimiento similar a max con un 41–51 % menos de tokens de salida (system card).

Existe además ultracode, que no es "más esfuerzo" sino un modo en el que Claude arma workflows que orquestan muchos subagentes (workflows). Para planificar no hace falta.

Testear con el navegador: Claude in Chrome y Playwright CLI

Cuando el agente termina de implementar, muchas veces intenta probarlo. Claude tiene su extensión Claude in Chrome, que usa tu navegador con tu sesión iniciada (documentación), pero para testear prefiero Playwright CLI, la herramienta oficial de Microsoft pensada para agentes (repositorio).

Por defecto corre sin ventana; con --headed ves el navegador. Lo mejor es que puedes lanzar varias sesiones independientes a la vez, algo muy útil si trabajas en varios proyectos en paralelo. En la demo probó por su cuenta el reproductor, la cuenta, los paneles de administración y el login, y al final me dio un reporte. Ya no reviso cada pantalla a mano: reviso a mano solo lo vital, como el proceso de compra.

Diseño: Impeccable y la skill design

Para el diseño mucha gente usa Impeccable, de Paul Bakaus, una skill con un vocabulario de diseño y comandos como polish o audit (impeccable.style, repositorio). Últimamente me funciona mejor la skill design que ya viene con Claude Code: genera opciones de interfaz como un artifact, una página HTML en una URL privada de claude.ai que puedes revisar, editar y compartir (artifacts).

Lo que hago es pedir varias opciones, quitar las que no me gustan y pedir que combine partes ("pasa el hero de la opción A a la C"). Cuando estoy conforme, le digo que implemente esa.

Lo que Claude Code tiene además del chat

Muchos creen que todos los agentes de terminal son iguales porque a simple vista solo "pides y ya". Claude Code tiene varias cosas que uso a diario (comandos, modo interactivo):

  • /btw: una pregunta lateral ("¿en qué puerto corre Next.js?") que no interrumpe la tarea ni entra al historial.
  • Tareas en segundo plano: los procesos que lanza (la API, el frontend) se pueden ver y detener con /tasks.
  • Mensajes en cola: si escribes mientras trabaja, el mensaje se encola; con Ctrl+Enter se envía de inmediato.
  • Subagentes: puedes pedirle "lanza un subagente que documente la arquitectura" o "crea otro que añada Swagger al backend" y trabajan en segundo plano mientras sigues con lo tuyo (subagentes). Consumen más tokens, pero si las tareas no se tocan entre sí, avanzan en paralelo.

Varios agentes en el mismo proyecto: git worktrees

El problema aparece cuando quieres que varias funciones que tocan los mismos archivos avancen a la vez. En la demo abrí una sesión para el login con Google y otra para el de GitHub: si las dos editan el mismo código, en algún punto chocan, y un agente borra lo que avanzó el otro.

La solución es pedir un worktree: una copia del proyecto en su propia rama donde el agente trabaja aislado. Claude Code lo soporta con el flag --worktree o creando uno durante la sesión (worktrees). En la demo, cada login (Google, GitHub y Microsoft) avanzó en su worktree y, como Herdr me deja renombrar cada terminal, saltar entre ellos es cuestión de escribir el nombre. Si quieres el detalle, tengo un video dedicado a git worktrees.

Ramas main y dev

Con agentes, las ramas importan más que cuando escribíamos todo a mano, porque los cambios son grandes y rápidos. Mi regla: main es producción (el código revisado que usan tus usuarios), dev es donde trabajas cada día, y los worktrees son las funciones en paralelo. Al terminar, fusiónalos y bórralos para no acumular una lista enorme de worktrees.

Cuando se acaba la cuota

Uso el plan Max de Claude y aun así a veces se agota; entonces cambio a Codex. También pago OpenCode y Command Code, dos harness para usar modelos abiertos. Escriben código bastante bien, pero en mi experiencia van más lentos y manejan peor los procesos en segundo plano: a veces no los inician bien y tengo que volver a pedirlo. No es culpa del modelo, sino del harness.

Harness + modelo

Para dejarlo claro: Claude Code, Codex u OpenCode son el harness; Opus o GPT son el modelo. Si sumas un buen modelo y un buen harness, avanzas mucho más rápido.

Entre los modelos abiertos, GLM 5.3 está muy arriba. Hace poco Anthropic publicó un análisis donde dice que, al igual que Claude Mythos Preview, GLM 5.3 tiene capacidades fuertes para construir exploits de ciberseguridad de forma autónoma (50 de 410 intentos frente a 56 de Mythos Preview en su benchmark) (Anthropic). El artículo es sobre ciberseguridad, pero da una idea de lo cerca que están algunos modelos abiertos.

Y sobre el orquestador: uso Herdr, pero Orca también es muy bueno si prefieres algo más gráfico. Pronto haré un video comparando los dos.

Desplegar y monitorear

Para desplegar:

  • Railway si quieres una nube sencilla: tiene CLI y skills para agentes, así que el agente puede desplegar solo (agent skills).
  • Cloudflare para landing pages y sitios estáticos: su CLI, Wrangler, también tiene skill (skills de Cloudflare).
  • Azure o Google Cloud cuando el proyecto es más grande o necesitas sus servicios (Maps, Drive, Calendar).

Y cuando el proyecto ya es real, monitorea cómo lo usan tus usuarios y qué se rompe: PostHog para analítica de producto y Sentry para errores.

Fusionar y comunicar sesiones

Para cerrar la demo le pedí a una sesión que fusionara todos los worktrees en dev. Con /rename le puse nombre a cada sesión (academia-main y academia-dev) y le pedí a la de dev que, al terminar, le enviara un mensaje a la de main con lo implementado. Claude Code permite mensajes entre sesiones (documentación), y la que recibe el mensaje, en modo auto, te pide aprobarlo antes de actuar. Así no tienes que estar esperando a que una terminal termine para pasarle la información a otra.

En la demo, la sesión que fusionó todo también abrió el navegador para probar cada login. Fallaron porque no le había pasado las claves de Google, GitHub ni Microsoft, y aquí entra la última pieza: si tienes conectados los CLI de tus servicios, el agente las consigue solo, y donde no hay CLI, con la extensión de Claude para Chrome o con computer use puede entrar al panel del servicio a buscarlas. Eso da para otro video, pero vale la pena investigarlo para completar tus automatizaciones.

Conclusión

Me quedo con tres ideas:

  • La terminal es el centro: con Herdr mantienes vivas las sesiones de todos tus agentes, locales o remotas, y saltas entre ellas en segundos.
  • Planifica antes de construir: modo plan, buen esfuerzo del modelo y tus skills hacen que el agente acierte a la primera.
  • Paraleliza sin romper el repo: subagentes para tareas independientes y worktrees para las que tocan los mismos archivos, con main y dev bien separados.

El proyecto de la demo está en GitHub por si quieres continuarlo o usarlo de base.

¿Qué herramientas usas tú para trabajar con varios agentes? Cuéntamelo en los comentarios del video.

Fuentes