Desarrollo software con 13 agentes de IA. Asi es como se ve realmente

Esta es mi terminal ahora mismo.

13 agentes Claude Code, cada uno en su propio panel de tmux, trabajando en el mismo codebase. No como experimento. No para presumir. Asi es como desarrollo software todos los dias.

El proyecto es Beadbox, un dashboard en tiempo real para monitorear agentes de IA de programacion. Esta construido por la misma flota de agentes que monitorea. Los agentes escriben el codigo, lo prueban, lo revisan, lo empaquetan y lo lanzan. Yo coordino.

Si estas ejecutando mas de dos o tres agentes y te preguntas como rastrear lo que estan haciendo, esto es a lo que he llegado despues de meses de iteracion.

El equipo

Cada agente tiene un archivo CLAUDE.md que define su identidad, lo que posee, lo que no, y como se comunica con otros agentes. No son asistentes genericos de "haz lo que sea". Cada uno tiene un trabajo especifico y limites explicitos.

La palabra clave es limites. eng2 no puede cerrar issues. qa1 no escribe codigo. pmm nunca toca el codigo fuente de la app. Super despacha trabajo pero no implementa. Los limites existen porque sin ellos, los agentes se desvian. "Ayudan" refactorizando codigo que no necesitaba refactorizacion, o cerrando issues que no fueron verificados, o tomando decisiones arquitectonicas para las que no estan calificados.

Cada CLAUDE.md comienza con un parrafo de identidad y una seccion de limites. Aqui hay una version abreviada del de eng2:

## Identity
Engineer for Beadbox. You implement features, fix bugs, and write tests.
You own implementation quality: the code you write is correct, tested,
and matches the spec.

## Boundary with QA
QA validates your work independently. You provide QA with executable
verification steps. If your DONE comment doesn't let QA verify without
reading source code, it's incomplete.

Este patron escala. Cuando empece con 3 agentes, podian compartir un solo prompt general. Con 13, los roles explicitos y los protocolos son la diferencia entre coordinacion y caos.

La capa de coordinacion

Tres herramientas mantienen unida a la flota.

beads es un issue tracker de codigo abierto, nativo de Git, construido exactamente para este flujo de trabajo. Cada tarea es un "bead" con un estado, prioridad, dependencias e hilo de comentarios. Los agentes leen y escriben en la misma base de datos local a traves de un CLI llamado bd.

bd update bb-viet --claim --actor eng2   # eng2 reclama un bug
bd show bb-viet                           # ver la spec completa + comentarios
bd comments add bb-viet --author eng2 "PLAN: ..."  # eng2 publica su plan

gn / gp / ga son herramientas de mensajeria para tmux. gn envia un mensaje al panel de otro agente. gp mira el output reciente de otro agente (sin interrumpirlo). ga pone en cola un mensaje no urgente.

gn -c -w eng2 "[from super] You have work: bb-viet. P2."  # despacho
gp eng2 -n 40                                               # verificar progreso
ga -w super "[from eng2] bb-viet complete. Pushed abc123."  # reportar

Los protocolos de CLAUDE.md definen rutas de escalamiento, formato de comunicacion y criterios de finalizacion. Cada agente sabe: reclamar el bead, comentar tu plan antes de programar, ejecutar tests antes de hacer push, comentar DONE con pasos de verificacion, marcar ready for QA, reportar a super.

Super ejecuta un ciclo de patrullaje cada 5-10 minutos: mira el output de cada agente activo, verifica el estado de los beads, confirma que el pipeline no se ha estancado. Es como una rotacion de guardia en produccion, excepto que los servicios son agentes de IA y los incidentes son "eng2 lleva sospechosamente callado 20 minutos."

Un dia real

Esto es lo que paso realmente un miercoles a finales de febrero de 2026.

9:14 AM - Un usuario de GitHub llamado ericinfins abre Issue #2: no puede conectar Beadbox a su servidor remoto de Dolt. La app solo soporta conexiones locales. Owner lo ve y lo senala a super.

9:30 AM - Super despacha el trabajo. Arch disena un flujo de autenticacion de conexion (toggle de TLS, campos de usuario/contrasena, paso de variables de entorno). PM escribe la spec con criterios de aceptacion. Eng lo toma y comienza a implementar.

Mientras tanto, en paralelo:

PM registra dos bugs descubiertos durante las pruebas de release. Uno es cosmetico: el badge del header muestra "v0.10.0-rc.7" en lugar de "v0.10.0" en builds finales. El otro es especifico de plataforma: la herramienta de automatizacion de capturas de pantalla devuelve una franja en blanco en Macs ARM64 porque Apple Silicon renderiza el WebView de Tauri a traves de composicion Metal, y el backing store esta vacio.

Ops encuentra la causa raiz del bug de capturas. La solucion es elegante: despues de capturar, verificar si la altura de la imagen es sospechosamente pequena (menos de 50px para una ventana que deberia ser de 800px de alto), y recurrir a la captura de pantalla basada en coordenadas.

Growth obtiene datos de PostHog y ejecuta un analisis de correlacion de IP. El hallazgo: los anuncios de Reddit han generado 96 clics y cero usuarios retenidos atribuibles. El trafico del README de GitHub convierte al 15.8%. Este mismo articulo existe gracias a ese analisis.

Eng1, desbloqueado por el diseno del Activity Dashboard de arch, comienza a construir la gestion de estado de filtros cruzados y funciones utilitarias. 687 tests pasando.

QA1 valida la correccion del badge del header: levanta un servidor de pruebas, usa automatizacion de navegador para verificar que el badge se renderiza correctamente, comprueba que 665 tests unitarios pasan, marca PASS.

2:45 PM - Shipper mergea el PR del release candidate, hace push del tag v0.10.0 y dispara el workflow de promocion. CI construye artefactos para las 5 plataformas (macOS ARM, macOS Intel, Linux AppImage, Linux .deb, Windows .exe). Shipper verifica cada artefacto, actualiza las notas de release en ambos repos, redespliega el sitio web y actualiza el cask de Homebrew.

3:12 PM - Owner responde en el Issue #2 de GitHub:

Buenas noticias: v0.10.0 acaba de lanzarse con soporte completo de autenticacion para servidor Dolt. Actualiza y deberias estar desbloqueado.

Bug reportado por la manana. Fix lanzado por la tarde. Y mientras eso sucedia, la siguiente funcionalidad ya se estaba disenando, un bug diferente estaba siendo investigado, los analytics se estaban analizando y QA estaba verificando independientemente otra correccion.

Eso no es porque 13 agentes sean rapidos. Es porque 13 agentes son paralelos.

Lo que sale mal

Esta es la parte que la mayoria de los posts de "mira mi setup con IA" omiten.

Los limites de tasa pegan con alta concurrencia. Cuando 13 agentes estan todos ejecutandose en la misma cuenta de API, quemas tokens rapido. En este dia en particular, super, eng1 y eng2 alcanzaron el techo de limite de tasa simultaneamente. Todos se detienen. Esperas. Es el equivalente en IA de que todos en la oficina intenten usar la impresora al mismo tiempo, excepto que la impresora cobra por pagina y hay un limite de paginas por minuto.

QA rebota trabajo. Esto es por diseno, pero anade ciclos. QA rechazo un build porque el comentario "DONE" del ingeniero no incluia pasos de verificacion. La correccion funcionaba, pero QA no podia confirmarla sin leer el codigo fuente. De vuelta a eng, reescribir el comentario de finalizacion, de vuelta a QA, re-verificar. Veinte minutos para lo que deberian haber sido cinco. El protocolo crea friccion, pero la friccion es estructural. Cada vez que he acortado QA, algo se rompio en produccion.

Las ventanas de contexto se llenan. Los agentes acumulan contexto a lo largo de una sesion. Super tiene un protocolo para enviar una directiva de "guarda tu trabajo" al 65% de uso de contexto. Si pierdes esa ventana, el agente pierde el hilo de lo que estaba haciendo.

Los agentes se atascan. A veces un agente cae en un bucle de errores y simplemente sigue reintentando el mismo comando fallido. El ciclo de patrullaje de super lo detecta, pero solo si verificas con suficiente frecuencia. He perdido 30 minutos con un agente que estaba fallando educadamente en silencio.

La sobrecarga de coordinacion es real. Archivos CLAUDE.md, protocolos de despacho, ciclos de patrullaje, comentarios en beads, reportes de finalizacion. Para un setup de dos agentes, esto es excesivo. Para 13 agentes, es la estructura minima viable. Hay un punto de cruce alrededor de 5 agentes donde la coordinacion informal deja de funcionar y necesitas protocolos explicitos o empiezas a perder el hilo de lo que esta pasando.

Lo que he aprendido

La especializacion supera a la generalizacion. 13 agentes enfocados superan a 3 "full-stack". Cuando qa1 solo valida y nunca escribe codigo, atrapa cosas que eng paso por alto siempre. Cuando arch solo disena y nunca implementa, los disenos son mas limpios porque no hay tentacion de acortar la spec para facilitar la implementacion.

QA independiente no es negociable. QA tiene su propio clon del repo. Prueba el codigo pusheado, no el arbol de trabajo. No confia en el auto-reporte del ingeniero. Suena lento. Atrapa bugs en cada release.

Necesitas visibilidad o la flota se desvie. Con 5+ agentes, no puedes rastrear el estado cambiando entre paneles de tmux y ejecutando bd list en tu cabeza. Necesitas un dashboard que te muestre el arbol de dependencias, que agentes estan trabajando en que y que beads estan bloqueados. Este es el problema que construi Beadbox para resolver.

El ciclo recursivo importa. Los agentes construyen Beadbox. Beadbox monitorea a los agentes. Cuando los agentes producen un bug en Beadbox, la flota lo atrapa a traves del mismo proceso de QA que atrapo todos los demas bugs. La herramienta mejora porque el equipo que mas la usa es el equipo que la construye. Soy consciente de que esto es o brillante o la maquina de Rube Goldberg mas elaborada jamas construida. Las funcionalidades lanzadas sugieren lo primero. Mi factura de tokens sugiere lo segundo.

El stack

Si quieres probar esto tu mismo, esto es lo que necesitas:

• beads: Issue tracker de codigo abierto nativo de Git. Este es el backbone de coordinacion. Cada agente lee y escribe en el.
• Claude Code: El runtime del agente. Cada agente es una sesion de Claude Code en un panel de tmux con su propio archivo de identidad CLAUDE.md.
• tmux + gn/gp/ga: Multiplexor de terminal para ejecutar agentes lado a lado. Las herramientas de mensajeria permiten a los agentes comunicarse sin memoria compartida.
• Beadbox: Dashboard visual en tiempo real que te muestra lo que la flota esta haciendo. Esto es sobre lo que estas leyendo.

No necesitas los 13 agentes para empezar. Dos ingenieros y un agente de QA, coordinados a traves de beads, cambiaran como piensas sobre lo que un solo desarrollador puede lanzar.

Que viene despues

La mayor brecha en el setup actual es responder tres preguntas de un vistazo: que agentes estan activos, idle o atascados? Donde se acumula el trabajo en el pipeline? Y que acaba de pasar, filtrado por el agente o la etapa del pipeline que me interesa?

Ahora mismo eso requiere un loop de patrullaje y muchos comandos gp. Asi que estamos construyendo un dashboard de coordinacion directamente en Beadbox: una franja de estado de agentes en la parte superior, un flujo de pipeline que muestra donde se acumulan los beads, y un feed de eventos con filtros cruzados donde hacer clic en un agente o etapa del pipeline filtra todo lo demas para coincidir. Las tres capas comparten la misma fuente de datos en tiempo real. Las tres se actualizan en vivo.

Los 13 agentes lo estan construyendo ahora mismo. Escribire sobre ello cuando se lance.