Creé un orquestador de agentes después de quemar mi presupuesto semanal de Claude Code
Por qué dejé de confiar en los prompts bien escritos
Tiempo estimado de lectura: 4 min
La gota que colmó el vaso fue una auditoría en la empresa. El área de tecnología necesitaba levantar la moral, y moral en la práctica significaba código probado, varios proyectos, plazos ajustados, confianza alta. Hice lo que hace todo el mundo: le tiré una tarea gigante a Claude Code y confié en el prompt bien escrito.
No funcionó. Aprendí un par de cosas en el proceso.
1 - No importa cuánto refines el prompt, el agente tiende a alucinar a medida que la cantidad de trabajo aumenta. 2 - La orquestación automática no te da control humano: todo termina delimitado por la IA, no por vos. 3 - Claude Code, aunque satisfactorio, es caro, y el agente siempre va a terminar antes de concluir una tarea gigantesca, aunque sea solo para pedir que continúe. 4 - Escribir tests en código legacy es tan simple como demorado. 5 - Gestionar múltiples prompts en paralelo te genera un agotamiento mental que te desvía de la tarea. 6 - Hasta la más simple de las LLMs devuelve resultados increíbles en tareas pequeñas de alcance cerrado.
El número personal: antes me quemaba el presupuesto semanal de la suscripción. Hoy gasto unos cinco reales para generar tests de un proyecto de más de 200 archivos.
El problema nunca fue el modelo. Fue la falta de método. De ahí nació huu.
Qué es huu
huu (Humans Underwrite Undertakings, "humanos suscriben emprendimientos") es un orquestador de agentes donde el método es tuyo y la inteligencia es del modelo. Escribes un pipeline en JSON listando los pasos y los archivos; se convierte en N agentes paralelos, uno por archivo, cada uno en un git worktree aislado, fusionados en cada etapa con git merge --no-ff en orden fijo, todo dentro de Docker para que el agente nunca vea tus credenciales.
El foco es auditoría, generación de pruebas y extracción de conocimiento. Feature nueva, "arregla ese bug", no es lo suyo. En el GIF del repo se puede ver una ejecución real: 55 minutos generando una suite de pruebas (100% de cobertura de línea en esa ejecución, sin garantía de que la tuya repita el número).
Instalación
Necesitas Node.js 20+, git y Docker. Docker es obligatorio, no opcional: huu solo corre dentro de un contenedor, así que tus credenciales de shell quedan afuera. Y una OPENROUTER_API_KEY, que es por donde entran los modelos. Probé todo aquí con la versión 5.2.0 de npm.
export OPENROUTER_API_KEY=sk-or-... # clave de openrouter.ai/keys
npm install -g huu-pipe # instala el CLI global
huu # abre la web UI y re-ejecuta en el contenedor
El huu levanta la interfaz en http://localhost:4888 y ya materializa los pipelines por defecto en ./pipelines/. Si prefieres terminal, huu --cli.
En la práctica: tarea gigante se convierte en N tareas pequeñas
El modo común de hacer esto es abrir Claude Code y decirle: "escribe tests para todo el proyecto". Yo lo hice. Muchas veces. El agente empieza bien en los primeros archivos, y entonces el contexto se degrada, alucina a medida que el trabajo aumenta y siempre termina antes de concluir, aunque sea solo para pedir que siga.
El modo huu es otro. El pipeline huu Test Suite primero hace un reconocimiento que descubre solo los archivos que vale la pena testear, sin que tú le digas nada. Luego un step con scope per-file hace el fan-out:
// pipelines/meu.pipeline.json
{
"name": "Escribe tests para $file",
"prompt": "Escribe tests unitarios para $file siguiendo huu-tests.md.",
"files": [],
"scope": "per-file"
}
Mismo prompt para todos, solo cambia $file. Treinta agentes en paralelo, cada uno con una misión única de alcance cerrado. Al final, un juez corre la suite y devuelve para retrabajo si no pasa.
Funciona por una razón simple: cada agente recibe una tarea pequeña de alcance cerrado, que es exactamente donde hasta la más simple de las LLMs entrega resultados increíbles.
Cuándo usarlo (y cuándo no)
La regla práctica es una sola frase: si cada paso requiere una decisión de diseño abierta, no es trabajo para huu; si el método es conocido y solo falta ejecutarlo con rigor, es justo su trabajo.
Sirve para auditoría, generación de tests, extracción de conocimiento, migración mecánica en masa. Tipo migrar 40 tests de Mocha a Vitest: el prompt es idéntico en los 40 archivos, solo cambia el $file. No sirve para "arregla este bug" o "construye esta feature". El trabajo abierto pide un agente interactivo, y armar un pipeline para eso es overhead puro.
El impacto concreto: hoy gasto unos cinco reales para testear un proyecto de 200 archivos. Antes, me quemaba todo el presupuesto semanal de Claude Code.
Cuidados
Antes de lanzarte a usarlo en producción crítica, algunas salvedades honestas.
huu es un proyecto joven, esencialmente de un solo autor, con desarrollo fuertemente asistido por IA. Tiene más de 1.100 tests en Vitest, pero no tiene CI automatizado: correr typecheck y tests antes del commit es convención del contribuidor, no un gate. Evalúalo como evaluarías cualquier herramienta nueva de una sola persona.
Determinístico es el método, no el resultado. Dos runs del mismo pipeline dan diffs diferentes, y el conflicto de merge cae en un resolvedor LLM, por construcción. Y la cobertura de línea solo prueba que el código se ejecutó, no que las aserciones atraparían un bug: trata el 100% como punto de partida, no como prueba.
Por último, Docker es obligatorio (las antiguas flags --no-docker y --yolo fueron removidas), y el costo de los pasos de merge y judge todavía no entra en el total reportado.
La invitación
El próximo paso es simple: instala y corre el huu Test Suite en un proyecto tuyo, o abre http://localhost:4888/simulation para ver todo funcionando sin clave y sin costo. Cero riesgo.
Pero, honestamente, lo que en verdad quería dejar es la reflexión: repiensa cómo usamos la IA en el día a día, porque esto se está poniendo caro. Usa la herramienta que quieras. La tesis es que el método sea tuyo, la inteligencia sea del modelo.
Si ayuda, una estrella en github.com/frederico-kluser/huu es bienvenida, y pipelines nuevos e issues también. Y manda este post a tu equipo en Slack o WhatsApp, sobre todo a quien controla el presupuesto.