← Volver al blog

Triaje de tareas bloqueadas en desarrollo paralelo

Triaje de tareas bloqueadas en desarrollo paralelo

Puedes ejecutar 10 agentes de IA de programación en paralelo ahora. Dale a cada uno un issue, apúntalos a una base de datos beads compartida, y déjalos trabajar. Los agentes crean subtareas, reportan bugs que descubren, actualizan estados y cierran issues cuando terminan. Es genuinamente productivo.

Hasta que algo se bloquea.

Cuando un humano se bloquea, dice algo. Postea en Slack, lo señala en el standup, camina hasta el escritorio de alguien. Los agentes no hacen nada de eso. Un agente encuentra una dependencia que no puede resolver, y o bien se detiene silenciosamente o empieza a rodear el problema de formas que crean más problemas. Tres agentes pueden estar atascados en la misma tarea upstream no resuelta y no te enterarás hasta que te preguntes por qué nada se ha entregado en cuatro horas.

Este es el problema de triaje para el desarrollo agéntico. No "cómo hacer mejores standups" sino "cómo ver qué está atascado a través de una flota de trabajadores autónomos que no se quejan." Aquí te contamos lo que hemos aprendido construyendo Beadbox, un dashboard en tiempo real para beads que te muestra exactamente lo que tus agentes están haciendo, en qué están bloqueados, y qué acaba de quedar disponible.

Salta a lo que te importa:

Cómo los agentes crean cadenas de bloqueo

Los agentes generan problemas de dependencia de forma diferente a los equipos humanos. Entender los modos de falla importa porque las respuestas de triaje son diferentes.

Los agentes no modelan dependencias por adelantado. Un arquitecto humano descompone una feature en tareas y piensa en el orden. Un agente de programación recibe una tarea, empieza a trabajar, y descubre a mitad de la implementación que necesita algo que no existe todavía. Puede crear un nuevo issue para esa dependencia. Puede intentar construirla inline y crear un desastre. Puede simplemente parar. Ninguno de estos resultados es visible a menos que estés observando la base de datos de issues.

Los agentes trabajan más rápido de lo que se actualiza el grafo de dependencias. El Agente 3 cierra una tarea que el Agente 7 estaba esperando, pero el Agente 7 no lo sabe porque verificó bloqueos hace 10 minutos. Mientras tanto el Agente 7 sigue ocioso o trabajando en algo de menor prioridad. El desbloqueo ocurrió, pero la información no se propagó.

Dependencias circulares emergen de la descomposición paralela. Cuando múltiples agentes descomponen trabajo simultáneamente, pueden crear ciclos que ningún agente individual ve. El Agente 1 crea la Tarea A que depende de la Tarea B. El Agente 2 crea la Tarea B que depende de la Tarea C. El Agente 3 crea la Tarea C que depende de la Tarea A. Cada dependencia tenía sentido localmente. El ciclo solo es visible desde arriba.

La contención de recursos es invisible. Dos agentes necesitan modificar el mismo archivo, o ambos necesitan el ambiente de staging, o ambos necesitan que la misma librería compartida esté en un estado estable. No hay dependencia declarada porque ningún agente sabe que el otro existe. Ambos se ralentizan y ninguno reporta por qué.

El hilo común: los agentes producen situaciones de bloqueo más rápido de lo que las reportan. El supervisor (tú) necesita herramientas que hagan emerger bloqueos automáticamente, no herramientas que esperen a que alguien levante la mano.

Detección automatizada de dependencias

La solución son datos de dependencia explícitos y consultables creados al momento de la tarea y verificados continuamente. Así se ve con beads, el issue tracker nativo de Git que usamos para nuestra flota de agentes.

Los agentes registran dependencias cuando crean tareas:

# El agente crea una tarea y descubre que necesita una API que no existe
API_TASK=$(bd create \
  --title "Implement /api/v2/orders endpoint" \
  --type task --priority 2 --json | jq -r '.id')

# El agente crea su propia tarea y declara la dependencia
UI_TASK=$(bd create \
  --title "Build order history page" \
  --type task --priority 2 --json | jq -r '.id')

bd dep add "$UI_TASK" "$API_TASK"

Detección de ciclos se ejecuta automáticamente:

bd dep cycles

En un grafo de 5,000 dependencias, esto toma ~70ms. Ejecútalo como un hook post-commit o en un cron de 5 minutos.

Muestra cada tarea bloqueada en un comando:

bd blocked --json | jq -r '.[] |
  "BLOCKED: \(.id) \(.title)\n  waiting on: \(.blocked_by | join(", "))\n  assignee: \(.owner // "unassigned")\n"'

Ahora sabes qué agentes están atascados, en qué están atascados, y qué necesita pasar para desbloquearlos. Esa consulta entera tomó 30ms en una base de datos de 10K issues.

Un workflow de triaje CLI-first

El triaje en un workflow agéntico no es una reunión. Es un script que corre en un loop. El supervisor (humano o agente) mira lo que está atascado y toma una decisión para cada elemento.

El árbol de decisión para cada elemento bloqueado:

  1. Puede otro agente desbloquearlo? Reprioriza la tarea bloqueadora, asigna un agente disponible.
  2. Es la dependencia falsa? Los agentes a veces declaran dependencias excesivamente conservadoras durante la planificación. Si el bloqueo no es real, elimínalo: bd dep remove beads-x7q beads-m2k.
  3. Se puede dividir el trabajo? Haz que el agente bloqueado trabaje las partes que no necesitan la dependencia. Crea una tarea de seguimiento para el resto.
  4. Es un bloqueo externo? Algo que solo un humano puede resolver (API key, decisión de diseño, concesión de acceso). Etiquétalo, anota la resolución esperada, y reasigna el agente a otro trabajo listo.

La opción 2 sucede constantemente con agentes. Modelan dependencias basándose en su comprensión del codebase al momento de la planificación. Una vez que la implementación comienza, la forma real del trabajo revela que la mitad de esas dependencias eran innecesarias.

Visibilidad en tiempo real del trabajo de agentes

Ejecutar un script de triaje cada 30 minutos deja brechas. Cuando los agentes se mueven rápido, mucho pasa entre verificaciones.

Cómo lo hace Beadbox:

La base de datos beads vive en un directorio .beads/ en tu sistema de archivos. Cada bd update, bd create o bd close que un agente ejecuta escribe en ese directorio. Beadbox lo observa con fs.watch() y envía los cambios a la UI vía WebSocket en milisegundos.

El efecto práctico: el Agente 5 ejecuta bd update beads-x7q --status=closed en una terminal. El dashboard de Beadbox inmediatamente muestra esa tarea como cerrada, y cualquier tarea que estaba bloqueada por ella se ilumina como recién disponible. Ves la cascada sin ejecutar ningún comando.

Esto importa porque el trabajo agéntico crea ráfagas. Un agente puede cerrar tres tareas en 90 segundos, cada una desbloqueando trabajo diferente aguas abajo. Un dashboard basado en polling con un intervalo de 30 segundos te mostraría un estado intermedio confuso. La propagación sub-segundo te muestra el cuadro completo mientras sucede.

Evaluando herramientas de triaje para workflows agénticos

Si estás buscando herramientas para gestionar una flota de agentes, los requisitos son diferentes de lo que un equipo humano necesita.

Obligatorio: CLI que los agentes puedan llamar. Si tu issue tracker solo tiene una UI web, los agentes no pueden usarlo. Necesitan ejecutar comandos shell.

Obligatorio: grafo de dependencias consultable. "Bloqueado" como etiqueta de estado es inútil para automatización. Necesitas A depende de B como datos estructurados para que los scripts puedan recorrer el grafo, detectar ciclos, y calcular qué está listo.

Obligatorio: lecturas locales sub-segundo. Cuando los agentes consultan trabajo disponible, el tiempo de respuesta importa. beads retorna resultados de bd ready en 30ms en una base de datos de 10K issues porque todo es local.

Deseable: propagación de cambios en tiempo real. Si los agentes crean y resuelven 50 issues por hora, necesitas ver el estado mientras cambia, no en un intervalo de refresh.

El loop de supervisor

Aquí está el workflow que ejecutamos diariamente, gestionando 10+ agentes de IA en un solo proyecto:

  1. Los agentes declaran dependencias al crear tareas. Cada bd create que tiene un prerrequisito obtiene un bd dep add inmediatamente.

  2. Un agente supervisor ejecuta bd blocked cada 30 minutos. Si algo se bloqueó recientemente, o bien resuelve el bloqueador él mismo o lo señala para el humano.

  3. Beadbox corre en la pantalla del humano. El dashboard muestra el grafo completo de dependencias con tareas bloqueadas resaltadas en tiempo real. La mayoría del tiempo, la automatización maneja los desbloqueos rutinarios. Cuando no puede (dependencia externa, decisión arquitectural, concesión de acceso), el humano ve el problema inmediatamente e interviene.

  4. Las tareas estancadas se señalan agresivamente. Un agente que no ha actualizado su tarea en progreso en 2 horas o bien está atascado o se cayó. El supervisor verifica y o bien empuja al agente, reasigna el trabajo, o investiga.

  5. Las dependencias falsas se podan continuamente. Los agentes sobre-declaran dependencias durante la planificación. Conforme la implementación revela la forma real del trabajo, el supervisor (o los propios agentes) eliminan dependencias que resultaron innecesarias. Un grafo limpio es un grafo útil.

El principio subyacente: los agentes son rápidos pero no tienen autoconciencia. No saben lo que otros agentes están haciendo, no notan cuando los bloqueadores se resuelven, y no se quejan cuando están atascados. El trabajo del supervisor es ser el sistema nervioso que conecta todo eso. Datos estructurados de dependencias, consultados automáticamente y renderizados visualmente, es lo que hace eso posible.

Beadbox es gratuito durante el beta. Te muestra lo que tus agentes están haciendo, qué está bloqueado, y qué acaba de quedar disponible, en tiempo real.

brew tap beadbox/cask && brew install --cask beadbox

Si ya usas beads, Beadbox lee tu directorio .beads/ existente sin paso de importación. Pruébalo.