Añadir un plugin es una respuesta válida cuando resuelve una necesidad concreta, está bien mantenido y no introduce complejidad innecesaria. El problema aparece cuando WordPress empieza a crecer por acumulación: una extensión para esto, otra para aquello, una tercera para conectar sistemas y una cuarta para corregir el comportamiento de las anteriores.
Al principio parece eficiente. Con el tiempo, esa lógica suele traducirse en incompatibilidades, tiempos de carga peores, pantallas de administración confusas y miedo a actualizar. La cuestión no es demonizar los plugins, sino reconocer cuándo el proyecto ya no debería depender de ellos para sostener lógica crítica del negocio.
Señales de que el límite ya ha llegado
Hay algunas pistas bastante claras. Por ejemplo: cuando un cambio pequeño obliga a revisar varios plugins a la vez; cuando una integración importante depende de hacks o campos escondidos; cuando cada actualización genera incertidumbre; o cuando nadie del equipo puede explicar con seguridad dónde vive cada regla funcional.
También es una señal de que la administración se vuelve opaca. Si quienes editan contenidos encuentran campos duplicados, procesos inconsistentes o pasos manuales que no entienden, probablemente el problema no es de formación, sino de arquitectura.
En ese escenario, lo sensato suele ser plantear desarrollo WordPress a medida. No porque “lo custom” sea mejor por definición, sino porque ciertas reglas del negocio merecen vivir en código propio, con alcance delimitado, pruebas razonables y una lógica que el equipo pueda mantener con criterio.
Qué suele llevarse a medida
Normalmente conviene customizar aquello que forma parte del producto o del flujo principal: integraciones con ERP o CRM, automatizaciones, modelos de datos específicos, áreas privadas, buscadores especializados, reglas de publicación, conectores API o paneles internos simplificados. Son piezas donde la configuración genérica se queda corta o genera demasiadas excepciones.
Esto permite reducir la dependencia de opciones ocultas y reacciones en cadena. En vez de adaptar el negocio a un plugin, se adapta el desarrollo a la necesidad real. El resultado no tiene por qué ser más complejo; a menudo es más claro, porque cada responsabilidad queda mejor delimitada.
No se trata de rehacerlo todo
Pasar a medida no siempre implica sustituir toda la base existente. Muchas veces basta con identificar qué piezas pueden seguir siendo estándar y cuáles conviene aislar en una capa propia. Lo importante es decidirlo con una visión de conjunto, no solo reaccionando a incidencias.
La mejor pregunta, por tanto, no es cuántos plugins tiene la web, sino si la arquitectura sigue siendo comprensible, mantenible y segura. Cuando la respuesta empieza a ser no, añadir otro plugin rara vez arregla el problema. Lo habitual es que simplemente lo esconda durante un tiempo más.
La administración también debe simplificarse
Cuando se apuesta por una capa a medida, una parte del valor aparece en el backend. Menos campos irrelevantes, procesos más claros, validaciones coherentes y pantallas pensadas para el uso diario reducen errores y dependencia. Es decir, el desarrollo a medida no solo mejora el código; también puede mejorar mucho la experiencia del equipo que trabaja dentro de WordPress todos los días.
Hace unos días se estrenó The Story of VS Code, un documental que cuenta la historia de Visual Studio Code directamente desde las personas que participaron en su desarrollo. Como me gustan este tipo de documentales sobre la historia del software, decidí verlo y encontré varias cosas que no conocía.
Visual Studio Code es uno de esos programas que hoy parecen haber existido desde siempre. En pocos años pasó de ser un nuevo editor creado por Microsoft, bastante criticado por utilizar tecnologías web para una aplicación de escritorio, a convertirse prácticamente en un estándar dentro de la industria.
Al final no parece que les haya ido tan mal.
¿De dónde salió Visual Studio Code?
Una de las cosas interesantes del documental es que VS Code no comenzó realmente como un editor de escritorio. El proyecto tiene sus raíces en un equipo de Microsoft en Zurich que trabajaba en herramientas de desarrollo para el navegador. De ahí aparecieron proyectos como Monaco, que eventualmente evolucionaron hasta convertirse en Visual Studio Code.
Para construirlo utilizaron tecnologías web sobre Electron. Actualmente esto no resulta demasiado extraño, pero hace diez años utilizar HTML, CSS y JavaScript para crear una aplicación de escritorio generaba bastante discusión, principalmente por el consumo de recursos comparado con aplicaciones nativas.
Otra cosa que me sorprendió fue descubrir que el proyecto era desarrollado por programadores distribuidos en diferentes partes del mundo. Siempre había imaginado que proyectos de este tamaño dentro de Microsoft se construían principalmente entre personas de una misma oficina o región.
El documental además está contado por los propios protagonistas del proyecto, explicando las decisiones que fueron tomando hasta que aquel editor bastante polémico terminó convirtiéndose en uno de los más utilizados de la industria.
Interfaz de Visual Studio Code
Microsoft estaba apostando bastante por la web
Algo que me llamó especialmente la atención fue ver cuántas tecnologías relacionadas estaba desarrollando Microsoft durante esa época. Por un lado estaba Monaco y todo el trabajo alrededor de herramientas de desarrollo para la web. Al mismo tiempo estaban creando TypeScript, que eventualmente tendría una relación bastante cercana con VS Code.
También apareció el Language Server Protocol, mejor conocido como LSP. El cual permite que un editor se comunique mediante un protocolo estándar con un servidor que entiende determinado lenguaje de programación. De esta forma funcionalidades como autocompletado, navegación entre definiciones o detección de errores no tienen que implementarse nuevamente para cada editor.
Como usuario de Neovim esto me parece particularmente interesante porque actualmente utilizo LSP todos los días, aunque prácticamente no utilice VS Code. Es un buen ejemplo de una tecnología nacida alrededor de un producto de Microsoft que terminó beneficiando a todo el ecosistema.
De VS Code a los editores con IA
Otra decisión importante fue publicar buena parte del proyecto como open source. Con el tiempo VS Code no solamente consiguió un enorme ecosistema de extensiones, sino que su código terminó sirviendo como base para construir otros editores.
Esto se vuelve especialmente interesante actualmente con la inteligencia artificial.Varios de los nuevos editores orientados a programación con IA son forks o están construidos sobre tecnologías provenientes de VS Code. En lugar de desarrollar un editor completamente desde cero, pueden utilizar una base que lleva más de una década evolucionando.
El documental habla precisamente de esta nueva etapa y de cómo VS Code terminó convirtiéndose no solamente en un editor, sino prácticamente en infraestructura para otras herramientas de desarrollo.
Me parece curioso que algunos de los productos que ahora intentan competir contra VS Code existan precisamente gracias al trabajo que Microsoft hizo con el proyecto.
¿Utilizo Visual Studio Code?
Curiosamente, casi no. Desde hace bastante tiempo mi editor principal es Neovim y sigo prefiriéndolo para mi trabajo diario. Me gusta trabajar cerca de la terminal y tener un entorno configurado exactamente como quiero. Sin embargo, en diferentes trabajos me ha tocado utilizar Visual Studio Code y realmente no me parece un mal editor.
Funciona en prácticamente cualquier plataforma, tiene un ecosistema enorme de extensiones y para alguien que simplemente quiere instalar un editor y comenzar a programar resulta bastante cómodo. Además, tengo que reconocer que es de las pocas tecnologías de Microsoft que me parece que están realmente bien hechas.
No significa que vaya a abandonar Neovim mañana, pero puedo entender perfectamente por qué terminó siendo tan popular.
¿Vale la pena ver The Story of VS Code?
Si eres programador y utilizas Visual Studio Code diariamente, te recomiendo ver el documental. Cuenta cómo comenzó el proyecto, por qué decidieron utilizar tecnologías web, quiénes estuvieron involucrados y cómo aparecieron tecnologías como Monaco, TypeScript y LSP alrededor de todo este ecosistema.
También resulta interesante ver cómo un editor que inicialmente recibió bastantes críticas terminó afectando para bien la forma en que desarrollamos software y sirviendo de base para una nueva generación de herramientas.
Incluso si no utilizas VS Code, probablemente utilizas alguna tecnología que fue influenciada por este proyecto.
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
¿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.
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.
Si has leído mi blog desde hace tiempo, sabrás que una de las cosas que me gusta compartir es música geek, especialmente cuando combina tecnología, software libre y un poco de humor. También habrás notado que SUSE aparece con bastante frecuencia en esta categoría, porque probablemente sea una de las empresas de tecnología que más se han divertido creando parodias musicales sobre Linux y el mundo open source.
Revisando algunos de esos videos, me encontré con uno que todavía no había compartido por aquí: SUSE Now Hallelujah, una parodia publicada por SUSE en 2018 basada en la canción Faith de Stevie Wonder y Ariana Grande, perteneciente a la banda sonora de la película Sing. Y, como suele pasar con los videos musicales de SUSE, no se limitaron a cambiar algunas palabras de la canción original. Crearon todo un videoclip, con músicos, cantantes, coreografía y, por supuesto, bastante color verde.
¿De qué se trata SUSE Now Hallelujah?
La protagonista de la canción es prácticamente la mascota de SUSE: el famoso camaleón verde. A partir de allí, la letra comienza a incorporar diversas características y tecnologías relacionadas con SUSE y Linux.
Entre las referencias aparecen conceptos como centros de datos, uptime, infraestructura, almacenamiento, contenedores, escalabilidad y live patching, todo mientras el camaleón baila y demuestra por qué, aparentemente, es el rey del open source.
Si trabajas administrando servidores o tienes experiencia con Linux en entornos empresariales, seguramente reconocerás muchas de estas referencias. Por ejemplo, el live patching permite aplicar determinados parches al kernel sin tener que reiniciar completamente el sistema, lo cual es especialmente importante cuando estás administrando servicios que deben permanecer disponibles durante largos períodos de tiempo.
Pero tampoco hace falta conocer todos estos conceptos para disfrutar el video. La canción funciona simplemente por lo absurda y divertida que resulta la idea de convertir características de una distribución Linux empresarial en una canción alegre y pegadiza.
SUSE y su extraña tradición musical
Una de las cosas que siempre me ha parecido curiosa de SUSE es que, durante años, ha utilizado la música y el humor como parte de su cultura. No es precisamente lo primero que imaginas cuando piensas en una empresa dedicada a Linux empresarial, servidores e infraestructura.
SUSE Now Hallelujah sigue exactamente ese espíritu: tomar algo que normalmente podría parecer extremadamente técnico y convertirlo en una pequeña celebración de la cultura geek y del software libre.
Así que si utilizas Linux, administras servidores, trabajas en tecnología o simplemente disfrutas este tipo de rarezas de Internet, te recomiendo ver el video.
Y cuidado, porque después de escucharlo unas cuantas veces, probablemente termines con el “I’m going green, Hallelujah, I’m SUSE now” dando vueltas en tu cabeza.
SUSE Now Hallelujah - A SUSE Music Parody
Finalmente, si te gusta este tipo de videos, recuerda revisar la categoría de Música Geek del blog, donde durante años he recopilado canciones, parodias y otras rarezas musicales creadas especialmente para geeks.
