Introducción​

Hace unos días instalé Hermes Agent en mi servidor personal, con la idea de tener algo que vigilara mis PRs de GitHub en busca de dependencias desactualizadas sin que yo tuviera que estar pendiente. Lo hice bien: usuario dedicado hermes-bot sin sudo, systemd hardened, toolset de GitHub recortado de 47 herramientas a 9 de solo lectura/reporte, cron cada 5 minutos en vez de un webhook público. Todo el checklist de seguridad que uno espera cuando le das a un agente de IA la capacidad de leer contenido de PRs de terceros y ejecutar código.

Lo que no hardening: cuánto me iba a costar tenerlo corriendo sin supervisión.

Cuatro días después abrí el dashboard de DeepSeek para ver cómo iba el consumo y me encontré con el balance en -$0.01. De $20 cargados, quedaba nada. Y lo peor: el agente no había reportado ni una sola dependencia desactualizada en ese tiempo. Este post es la reconstrucción de qué pasó, con los números reales, no una hipótesis.

Introducción​

Todos conocemos el patrón: el proyecto arranca con un README cuidado, tal vez un par de diagramas, quizás hasta una wiki. Pasan tres sprints, el código cambió por completo, y esa documentación sigue hablando de una arquitectura que ya no existe. Nadie la borra porque "algún día la actualizamos", y nadie la actualiza porque siempre hay algo más urgente. La documentación no muere, simplemente se vuelve mentirosa. Y el equipo de LangChain decidió atacar ese problema con OpenWiki, una CLI que le da a un agente la responsabilidad de escribir y mantener la documentación de tu repositorio.

Introducción​

En un post anterior les conté cómo convertí una HP Pavilion vieja en mi servidor personal, con Docker, Cloudflare Tunnel y un montón de servicios self-hosted corriendo ahí. Hoy les cuento la otra cara de esa historia: qué pasa cuando uno de esos servicios queda expuesto al mundo sin la protección que debería tener, y alguien (o algo, un script automatizado) lo encuentra antes que uno.

Spoiler: terminé con un contenedor de Gitea minando criptomonedas para otra persona, 4743 cuentas de spam, y un fin de semana entero limpiando el desastre. Este post es la bitácora completa del incidente, cómo lo detecté, cómo lo contuve, y lo que armé después para que la próxima vez me entere en minutos y no por accidente.

Introducción​

Llevo ya varios años con tmux como base de mi flujo de trabajo. Prefix, splits, sesiones, un .tmux.conf afinado a fuerza de repetición hasta que los binds quedaron grabados en los dedos más que en la memoria, a tal grado de que cuando estoy en un setup ajeno me siento como un mono. Así que cuando empecé a evaluar herdr, un multiplexor de terminal que se vende como pensado para trabajar con agentes de IA en paralelo, la primera pregunta no fue "¿qué features nuevas trae?" sino "¿me va a doler migrar mis keybindings?"

Introducción​

Es bien sabido que existen muchas maneras de diseñar APIs REST. Cada equipo tiene su estilo, sus convenciones y sus preferencias. Pero hay un patrón que nos alcanza a todos: GET para leer, POST para crear. Y eso está bien, porque es simple y funciona. Pero, como todo en la vida, hay un punto donde la simplicidad se rompe. Y es que cuántas veces no nos hemos topado con la necesidad de hacer una consulta compleja, con filtros avanzados, paginación y ordenamiento, y nos hemos visto obligados a usar POST para algo que claramente es una operación de lectura. Hoy vamos a hablar de eso, y de cómo el IETF finalmente nos dio una solución oficial: el método HTTP QUERY.