Saltar al contenido

Categoría: Desarrollo y Programación

Herdr: el Tmux moderno para trabajar con agentes de IA en paralelo

Durante muchos años he sido usuario de tmux, hasta que, hace unas semanas, al revisar videos en YouTube, descubrí Herdr. Es una de esas herramientas que, después de incorporarla a tu flujo de trabajo, resulta difícil abandonar: permite mantener sesiones activas, dividir la terminal en varios paneles y trabajar con múltiples consolas sin llenar el escritorio de ventanas. Sin embargo, mi manera de desarrollar software ha cambiado bastante con el auge de la inteligencia artificial. En mi nuevo trabajo utilizo varios agentes de programación en paralelo y, al mismo tiempo, necesito mantener activos servidores, procesos de compilación, pruebas y otros servicios relacionados con los proyectos.

Tmux seguía funcionando, por supuesto, pero cada vez me costaba más navegar entre tantas ventanas y paneles. En ocasiones no recordaba dónde había dejado determinado agente, cuál seguía trabajando o cuál estaba esperando que respondiera una pregunta. Terminaba de recorrer las sesiones una por una para comprobar qué estaba ocurriendo.

herdr corriendo codex
herdr corriendo Codex

¿Qué es Herdr?

Herdr es un multiplexor de terminal diseñado específicamente para trabajar con agentes de programación. La forma más sencilla de explicarlo es que se trata de una especie de tmux modernizado y adaptado a la era de la inteligencia artificial.

Al igual que tmux, Herdr permite crear múltiples terminales, dividirlas en paneles y mantener las sesiones en ejecución en segundo plano. Puedes cerrar la ventana de la terminal, volver más tarde y continuar donde estabas, sin detener los agentes ni los procesos activos.

La diferencia es que Herdr no solo ve paneles: también reconoce los agentes que se ejecutan dentro de ellos. Es compatible con herramientas como Claude Code, Codex, OpenCode, GitHub Copilot CLI, Cursor Agent, entre otras. En una barra lateral se muestra si cada agente está trabajando, bloqueado, inactivo o ha terminado su tarea.

Esta pequeña diferencia resuelve uno de los principales problemas que tenía con tmux. Ya no necesito recorrer manualmente todos los paneles para saber qué agente requiere mi atención.

Espacios de trabajo, pestañas y paneles

Una de las características que más me gustaron es la manera en que Herdr organiza las terminales. La herramienta utiliza tres niveles:

  • Los espacios de trabajo permiten separar proyectos.
  • Las pestañas agrupan diferentes tareas dentro de cada proyecto.
  • Los paneles contienen las consolas, los agentes y los servicios que se ejecutan.

Por ejemplo, puedo tener un espacio de trabajo para cada proyecto. Dentro de él creo una pestaña para los agentes, otra para el servidor de desarrollo y otra para las pruebas o los registros. Si necesito observar dos procesos al mismo tiempo, simplemente divido la pestaña en varios paneles.

La barra lateral resume el estado de todos los agentes. De esta forma, puedo ver rápidamente quién continúa trabajando, quién necesita que apruebe una acción y quién ya finalizó. Al seleccionarlo, Herdr me lleva directamente a su panel para revisar el resultado y redactar el siguiente prompt.

Para quienes trabajamos con varios agentes en paralelo, esta vista resulta mucho más práctica que intentar recordar en qué ventana se encuentra cada uno.

Interfaz de Herdr
Ejemplo de la interfaz de Herdr

Una transición sencilla desde tmux

Otra razón por la que comencé a utilizar Herdr es que no tuve que aprender de cero una nueva forma de controlar la terminal. La herramienta conserva el mismo modelo de prefijo de tmux: por defecto se utiliza Ctrl+B Antes de ejecutar una acción.

También incluye varios atajos familiares. Con Ctrl+B y luego c Se crea una nueva pestaña, mientras que Ctrl+B y después n o p Permite avanzar o retroceder entre ellas. Para dividir paneles, navegar por los espacios de trabajo o desconectarse de una sesión, se sigue una lógica muy similar.

Si ya utilizas tmux, la adaptación es bastante rápida. Además, al presionar Ctrl+B y luego ? Puedes consultar todos los atajos disponibles.

Herdr también soporta el mouse por defecto. Es posible seleccionar paneles, pestañas, espacios de trabajo y agentes con un clic, cambiar el tamaño de las divisiones arrastrando sus bordes y abrir menús contextuales con el botón derecho. Aunque normalmente prefiero los atajos de teclado, el mouse resulta cómodo cuando quiero reorganizar rápidamente la interfaz.

Notificaciones cuando un agente necesita atención

Una de las funciones más útiles de Herdr es su sistema de notificaciones. La herramienta puede avisar cuando un agente termina una tarea o cuando necesita que respondamos una pregunta o aprobemos alguna acción. Esto permite dejar varios agentes trabajando y concentrarse en otra actividad sin revisar cada terminal constantemente. Cuando alguno finaliza, recibo el aviso, salto directamente a su panel, reviso lo que hizo y continúo la conversación con un nuevo prompt.

En la práctica, Herdr convierte un conjunto de terminales dispersas en una pequeña central de control para agentes. No ejecuta el trabajo por ellos ni reemplaza herramientas como Codex o Claude Code; simplemente ofrece una forma mucho más clara de organizarlos y supervisarlos.

Herdr funciona dentro de la terminal

Existen otras alternativas para administrar agentes, como cmux, pero muchas de ellas funcionan como aplicaciones independientes o buscan reemplazar la terminal que ya utilizas. Herdr adopta un enfoque diferente. Es una herramienta nativa de consola, desarrollada en Rust, que se ejecuta en la terminal que prefieras. No necesita Electron ni obliga a cambiar Ghostty, Kitty, iTerm2, Alacritty ni a cambiar ningún otro emulador de terminal que ya forme parte de tu entorno.

Para mí, esto es una gran ventaja. Puedo conservar el flujo de trabajo que he utilizado durante años, entrar por SSH cuando lo necesito y seguir trabajando exclusivamente desde la consola.

Una herramienta de código abierto para organizar el nuevo desarrollo con IA

Otro aspecto que me encanta es que Herdr es un proyecto de código abierto, distribuido bajo la licencia Apache 2.0. Esto permite revisar su código, proponer mejoras y contribuir con una herramienta que probablemente resulte cada vez más útil a medida que trabajar con varios agentes se convierta en algo habitual.

Después de muchos años utilizando tmux, no esperaba reemplazarlo fácilmente. Sin embargo, Herdr conserva las ideas que siempre me gustaron de tmux y añade justo lo que necesitaba para mi flujo de trabajo actual: una interfaz más moderna, organización por proyectos, soporte para el mouse, seguimiento del estado de los agentes y notificaciones cuando alguno requiere atención.

Si trabajas con muchas consolas, mantienes varios servicios activos o utilizas diferentes agentes de inteligencia artificial en paralelo, te recomiendo probarlo. En esencia, Herdr es el tmux de siempre, pero preparado para una forma de desarrollar software que apenas hace unos años no existía.

Happy coding!

Deja un comentario

Escribo menos código que nunca: Superpowers y el nuevo desarrollo con IA

Hace unos pocos meses me di cuenta de que cada vez escribía menos código directamente. No porque estuviera desarrollando menos software, sino porque mi forma de trabajar había cambiado por completo. Si antes abría mi editor y comenzaba a implementar una idea casi de inmediato, ahora paso mucho más tiempo entendiendo el problema, diseñando la solución y validando que todo tenga sentido antes de escribir una sola línea a través del uso de Superpowers.

Paradójicamente, eso me ha hecho desarrollar más rápido.

Durante los últimos años hemos visto aparecer herramientas capaces de generar código en cuestión de segundos. Sin embargo, cualquiera que haya trabajado en proyectos reales sabe que generar código y desarrollar software son dos cosas muy distintas. Un programa no solo necesita funcionar; también debe ser mantenible, probado, seguro y fácil de evolucionar.

Gracias al Ing. Ronald Escalona, quien me compartió información sobre las skills de Superpowers, un plugin que incorpora un conjunto de skills especializados para el desarrollo de software. Después de utilizarlo durante un mes, puedo decir que cambió por completo mi forma de trabajar con IA y, curiosamente, también mi forma de programar.

Programador trabajando con las skills de superpowers que sugiere código en pantalla
Gracias al skill de superpowers, ahora tengo un asistente que programa por mi

¿Qué es un plugin y qué es un skill?

Antes de hablar de Superpowers, conviene aclarar dos conceptos:

  • Un plugin es una extensión que añade nuevas capacidades a una aplicación. En este caso, Superpowers amplía las capacidades del modelo de lenguaje incorporando metodologías, procesos y herramientas orientados específicamente al desarrollo de software.
  • Un skill, por otra parte, puede entenderse como una habilidad especializada. No es simplemente un prompt enorme ni un conjunto de instrucciones copiadas y pegadas en cada conversación. Es un flujo de trabajo diseñado para resolver un tipo específico de problema siguiendo buenas prácticas de ingeniería.

La mejor forma de imaginarlo es pensar que, en lugar de conversar con una única inteligencia artificial, estás incorporando a tu equipo a diferentes especialistas: un arquitecto de software, un ingeniero de calidad, un experto en pruebas automatizadas, un revisor de código o un especialista en depuración. Dependiendo del problema que quieras resolver, utilizas el skill más adecuado.

Lo interesante es que estos skills no buscan reemplazar al desarrollador; buscan que la IA trabaje siguiendo un proceso similar al que utilizaría un buen equipo de ingeniería.

Los skills que componen Superpowers

Aunque cada skill puede utilizarse de forma independiente, en conjunto cubren prácticamente todo el ciclo de desarrollo de una funcionalidad.

El proceso suele comenzar con Brainstorming, una skill que ayuda a comprender el problema antes de pensar en la implementación. En lugar de generar código de inmediato, analiza los requisitos, identifica restricciones, plantea preguntas clave y propone distintas alternativas para resolver el problema.

Una vez que existe claridad sobre lo que se quiere construir, Writing Plans transforma esas ideas en un plan de implementación dividido en tareas pequeñas y ordenadas. Este paso resulta especialmente útil cuando se trabaja en funcionalidades grandes o proyectos complejos, ya que evita improvisar durante el desarrollo.

Si el proyecto requiere trabajar de forma aislada, Using Git Worktrees prepara automáticamente un entorno independiente. Aunque esta es una característica nativa de Git, pocas personas la utilizan, y resulta extremadamente útil para desarrollar funcionalidades sin afectar la rama principal del proyecto.

Uno de los skills más interesantes es el Test-Driven Development (TDD). En lugar de escribir primero el código, guía al desarrollador para que siga el ciclo clásico de TDD: crear una prueba, verificar que falle, implementar únicamente el código necesario para hacerla pasar y finalmente refactorizar. Esto convierte las pruebas en una especificación funcional y hace que la IA deje de «adivinar» cómo debería comportarse el sistema.

Cuando las tareas son demasiado grandes, Subagent Driven Development permite dividir el trabajo entre varios agentes especializados. Mientras uno analiza la arquitectura, otro implementa, otro escribe pruebas y otro revisa la documentación. El resultado se parece mucho más al trabajo colaborativo de un equipo que a una conversación tradicional con un modelo de lenguaje.

La fase de depuración también tiene su propio proceso, denominado Systematic Debugging, que evita modificar el código por intuición y propone investigar primero la causa raíz del problema antes de aplicar cualquier corrección.

Después de implementar una funcionalidad, entra en juego Requesting Code Review, encargado de revisar la calidad del código desde distintos puntos de vista, como mantenibilidad, claridad, arquitectura y rendimiento. Si posteriormente surgen comentarios durante una revisión, Receiving Code Review ayuda a analizarlos críticamente y decidir cuáles realmente mejoran el proyecto.

Superpowers también incorpora Fix CI, pensado para diagnosticar problemas en los pipelines de integración continua, especialmente cuando fallan las pruebas o los procesos de GitHub Actions.

Antes de considerar terminada una tarea, aparece Verification Before Completion, cuyo objetivo es comprobar que todo compile correctamente, que las pruebas pasen y que no existan errores conocidos. Finalmente, «Finishing a Development Branch» realiza una última revisión antes de integrar la rama al proyecto principal, verificando que el trabajo esté realmente listo para hacer merge.

Vistos individualmente, parecen herramientas independientes, pero juntos forman una metodología bastante completa para desarrollar software asistido por inteligencia artificial.

Cómo se trabaja con Superpowers

Todo comienza con Brainstorming. Antes de pensar en el código, intento entender el problema, revisar los requisitos y explorar diferentes alternativas. Muchas veces descubro que la primera idea no es necesariamente la mejor.

Cuando la solución está clara, utilizo Writing Plans para dividir el trabajo en pequeñas tareas. Tener un plan evita perder tiempo durante la implementación y hace mucho más sencillo saber qué falta por hacer.

Si la funcionalidad es importante, preparo un entorno aislado utilizando Using Git Worktrees, lo que me permite experimentar sin preocuparme por afectar el estado del proyecto principal.

A partir de ese momento, intento seguir siempre un enfoque basado en Test-Driven Development. Primero escribo las pruebas, luego implemento únicamente el código necesario para que pasen y, finalmente, refactorizo cuando todo funciona correctamente. Si el desarrollo requiere varias partes independientes, Subagent Driven Development permite repartir responsabilidades entre distintos agentes especializados, lo que acelera bastante el proceso.

Cuando inevitablemente aparece algún error, procuro resistir la tentación de modificar el código de inmediato. En lugar de ello, recurro a Systematic Debugging, que obliga a formular hipótesis, buscar evidencia y encontrar la verdadera causa del problema antes de proponer una solución.

Una vez implementada la funcionalidad, solicito una revisión mediante Requesting Code Review, analizo los comentarios utilizando Receiving Code Review y, antes de considerar terminado el trabajo, ejecuto Verification Before Completion para asegurarme de que todo compile correctamente y las pruebas pasen sin inconvenientes. Finalmente, Finishing a Development Branch sirve como una última comprobación antes de integrar la rama al proyecto principal.

Puede parecer un proceso más largo que simplemente pedirle a la IA «implementa esta funcionalidad», pero mi experiencia ha sido exactamente lo contrario. Al existir un proceso ordenado, aparecen menos errores, disminuye el retrabajo y las implementaciones suelen llegar mucho más maduras desde el principio.

Reflexión final

Después de varios meses utilizando este enfoque, tengo una conclusión bastante clara: la inteligencia artificial no está reemplazando al ingeniero de software; está cambiando cuál es su trabajo. Cada vez dedicaremos menos tiempo a escribir código repetitivo y mucho más a comprender problemas, diseñar soluciones, validar resultados y tomar decisiones técnicas. Es un cambio que, lejos de preocuparme, me parece una evolución natural de nuestra profesión.

De hecho, esto me recuerda a mi profesor de Sistemas de Información II cuando en clase dijo que una cosa es la Ingeniería de Software y otra programar. Que al estudiar ingenieria haríamos mas que aquellos que solo saben programar, y eso fue hace como 18 años. Todo un visionario.

Herramientas como Superpowers demuestran que utilizar IA para desarrollar software puede ser cada vez más seguro y confiable cuando existe una metodología que la respalda. Sin embargo, ninguna metodología elimina la necesidad del criterio humano. Comprender el contexto del negocio, decidir qué problema vale la pena resolver, evaluar riesgos y determinar cuándo una solución realmente cumple con los objetivos del proyecto siguen siendo tareas del desarrollador.

La IA seguirá mejorando, escribirá código cada vez más rápido y probablemente resolverá problemas cada vez más complejos. Pero mientras existan decisiones de diseño, arquitectura y negocio que tomar, la experiencia humana seguirá siendo indispensable. Quizás el futuro del desarrollo no consista en escribir más código, sino en construir mejores procesos para colaborar con la inteligencia artificial de forma responsable. Y, sinceramente, creo que ese futuro ya comenzó.

Happy coding!

Deja un comentario

Code for the People: documental sobre la web abierta y WordPress

Navegando por las redes sociales vi que muchas personas anunciaban el lanzamiento de un documental sobre quienes han participado en el desarrollo de la web. Me llamó la atención, ya que hacía mucho tiempo que no se producía un contenido de este tipo, así que decidí darle una oportunidad. El documental se titula Code for the People y está dirigido por Bao Nguen. A lo largo de la obra se presentan las experiencias de varias personas que contribuyeron a democratizar la web, haciéndola más accesible y permitiendo que millones de usuarios pudieran crear y compartir contenido en Internet.

¿Donde puedo ver Code for the People?

Code for the People es un cortometraje de 20 minutos dirigido por Bao Nguyen. El mismo fue subido a Youtube y lo puedes ver . En él se realiza un recorrido por el pasado, el presente y el futuro de la web abierta. Además, plantea una reflexión sobre los desafíos que enfrenta el software de código abierto ante el creciente dominio de los monopolios digitales y el auge de los sistemas de inteligencia artificial de carácter propietario.

A medida que avanza el documental, es fácil notar que muchas de las personas entrevistadas están relacionadas, de una u otra forma, con el proyecto WordPress. Esto no representa ningún inconveniente para la narrativa, aunque, al investigar un poco más, descubrí que el documental fue patrocinado por Automattic. Aun así, ese patrocinio no resulta invasivo ni resta credibilidad al contenido, ya que el enfoque sigue siendo una reflexión sobre la evolución de la web abierta y la importancia del software libre en su desarrollo.

Code for the People | A Film by Bao Nguyen | Full Documentary

Espero que os haya gustado este documental. Aunque está centrado exclusivamente en la comunidad de WordPress, creo que resulta inspirador y muy motivador. Personalmente, me siento identificado con muchas de las personas que aparecen en él, y siempre es interesante conocer cómo ha evolucionado la web abierta a lo largo de los años.

Además, es innegable el papel que desempeñó WordPress al permitir que personas sin conocimientos técnicos pudieran formar parte de la web, facilitándoles la publicación y difusión de su contenido a través de Internet.

Espero que luego de ver Code for the People te animes y participes en ayudar a democratizar la web.

Hack the planet!

Deja un comentario

JS Archive List 6.2.0: actualización de seguridad, limpieza de i18n y más pruebas automatizadas

Hay actualizaciones “cosméticas” y otras de urgencia, con un enfoque en la calidad, porque resuelven problemas que surgen en producción. La versión 6.2.0 de JS Archive List se clasifica en la segunda categoría.

En la sección de changelog de WordPress, el foco está clarísimo: es una actualización de seguridad y viene acompañada de mejoras que, aunque no se vean en el frontend, hacen que el plugin sea más sólido a largo plazo.

JS Archive List de nuevo con una vulnerabilidad

El cambio importante: fix de seguridad en filtros por shortcode

El punto más relevante de esta versión de JS Archive List es que se corrigió una deserialización insegura relacionada con los filtros de categorías del shortcode, pasando a un enfoque de parsing seguro de IDs serializados y rechazando cualquier otro valor, como, por ejemplo, un objeto.

Es decir, si tu sitio usa shortcodes y filtros de categorías, ahora el plugin es mucho más estricto con lo que acepta como entrada. Esto reduce superficies de ataque clásicas en las que “datos con forma rara” terminan ejecutando acciones que nunca debieron ejecutarse.

No es el tipo de cambio que “se nota”, pero es exactamente el tipo de cambio que vale oro.

i18n sin sorpresas: text domain alineado con el slug

Otro detalle que descubrí sin querer es que WordPress espera que el dominio del texto coincida con el slug del plugin. En esta versión se arregló mediante cambios en los archivos de PHP, JS y de traducción.

Esto suele arreglar los típicos “¿por qué esto no se traduce si tengo el .mo?” o las inconsistencias que surgen cuando WordPress intenta cargar el dominio correcto.

Readme de JS Archive List mas claro

También se actualizaron los headers del plugin/readme (requisitos, licencia y license URI), pues ahora son requeridos y durante esta década no los había incluido. Así, el plugin tiene una mejor calidad y cumple con los lineamientos de los plugins que exige WordPress.

Más fácil brindar calidad: docs y setup de PHPUnit

Este es mi lado de profesor universitario hablando: si quieres que un proyecto sea sostenible, haz que sea fácil de probar. La nueva versión 6.2.0 incluye: documentación y script instalador para configurar la suite de pruebas con WordPress y PHPUnit

Esto reduce muchísimo la fricción al añadir pruebas, correrlas en CI y detectar regresiones antes de que algo llegue a producción. Probablemente agregue más pruebas en futuras versiones de JS Archive List.

Codex me ahorró horas

Aquí va mi confesión nerd: parte de esta actualización se benefició mucho de Codex para acelerar el trabajo “invisible”: revisar cambios repetitivos, mantener la consistencia con los estándares de WordPress y, sobre todo, acelerar la incorporación de chequeos de calidad (tests, estructura, convenciones) sin convertirlo en una semana entera de trabajo.

Eso sí, no reemplaza el criterio (eso no se delega), pero sí recorta brutalmente el tiempo entre “tengo que hacerlo” y “listo, quedó fino y revisado”.

Prueba JS Archive List y dime qué tal

Si todavía no lo has probado, este plugin existe para lo mismo que yo quería hace años: un archivo colapsable, limpio y configurable, y hoy, además, con soporte moderno vía el block de Gutenberg.

Pásate por la página del plugin, instálalo, juega con las opciones y, si te sirve, deja una reseña, reporta bugs o sugiere mejoras.

Eso es lo que mantiene vivo el software libre.

Deja un comentario