Dirigir workers en segundo plano

Esta guía te muestra cómo llevar una conversación como director en lugar de como worker: la sesión lee y verifica, y los agentes en segundo plano hacen la edición.

Qué cambia cuando escribes /vibe

Dos cosas, y solo la primera la impone la maquinaria:

1. Las herramientas de la propia sesión pasan a solo lectura, más cinco verbos de worker. La única forma en que puede afectar al repo es a través de un worker, y la única forma en que puede saber qué pasó es leyendo los archivos que tocó un worker.
2. Se le indica que verifique leyendo, no creyendo. El informe de un worker es una afirmación sobre lo que hizo, no una prueba de que funcionó.

La primera es la que sostiene todo. Un director que todavía puede usar grep y editar hará el trabajo él mismo bajo presión, que es justo el modo de falla que esto existe para evitar.

/vibe migrate the auth module to the new session API

Los workers empiezan en blanco

Un worker nunca ha visto tu conversación y nunca la verá. El encargo es todo su contexto.

Eso es lo que mantiene barato el patrón —veinte workers que conservaran cada uno el historial del director costarían veinte veces el contexto del director— y también es lo único que hace difícil redactar los encargos. «Ahora haz también el otro» se lee como una instrucción completa para el director y como nada en absoluto para una sesión nueva.

Un buen encargo nombra archivos, comandos y la definición de terminado:

En lib/features/auth/, reemplaza cada llamada a SessionStore.read(key) por SessionStore.get(key). El método nuevo devuelve Future<String?> donde el anterior devolvía String?, así que quienes lo llaman necesitan await. Ejecuta fvm flutter analyze lib/features/auth cuando termines y reporta los errores que no hayas podido corregir.

Los cinco verbos

Verbo	Qué hace
vibe_spawn	Inicia un worker con un encargo. Regresa de inmediato.
vibe_list	Nivel, estado, tiempo transcurrido y último resultado de todos
vibe_send	Un turno de seguimiento para un worker que ya terminó
vibe_wait	Se bloquea hasta que un worker concluye
vibe_kill	Detiene a uno

Lanzar workers es asíncrono por diseño. Un director que se bloquea en cada lanzamiento está ejecutando workers de uno en uno, que es una forma más lenta de hacer lo que ya hacía él mismo. Usa vibe_wait solo cuando de verdad no puedas continuar sin una respuesta específica.

Dos niveles

Nivel	Para
fast	Trabajo mecánico con una especificación clara: ediciones, renombrados, borradores, ejecutar comandos
good	Diseño, criterio o revisar lo que produjo un worker fast

Una forma común es repartir workers fast entre archivos independientes y luego lanzar un worker good que revise lo que hicieron en conjunto.

Verificar

Esta es la parte que decide si el patrón vale algo.

vibe_list
→ w1 [fast] auth-migrate — done (48s): Edited lib/features/auth/session.dart …
  w2 [fast] tests — running (12s)

Luego lee los archivos que nombró. El director tiene read, search, lsp y ast_grep; ese es justamente el motivo de conservarlas. Un director que acepta el informe tal cual es un resumidor del optimismo de otros agentes.

lsp(action: "diagnostics", file: "*") después de una ronda de workers suele ser la comprobación más rápida.

Cuando un worker pierde el hilo

Mátalo y vuelve a redactar el encargo. Un encargo corregido desde cero es más barato que una discusión, y vibe_send solo funciona con un worker que ya terminó su turno.

vibe_kill(worker_id: "w2")
vibe_spawn(brief: "…corrected…", label: "tests", tier: "fast")

Límites

• Ocho workers simultáneos. Un techo de gasto, no un límite técnico: cada uno es una sesión de modelo completa, y un director que reparte veinte ha dejado de seguir lo que hacen todos.
• Ningún worker sobrevive al modo. Cuando termina la ejecución, todos se detienen y la transcripción dice cuántos. Un agente en segundo plano que sigue editando archivos después de que la conversación avanzó es la única falla que esto no puede permitirse.
• Por debajo, los workers son subagentes comunes. El mismo límite de profundidad, la misma política de barandillas, el mismo hijo en el registro de ejecución. Vibe cambia quién los conduce, no lo que pueden hacer, así que las solicitudes de aprobación siguen apareciendo para las llamadas de escritura y ejecución de un worker.

Cuándo no usarlo

El modo vibe es para trabajo que se descompone en encargos independientes. Si el siguiente paso depende de la salida del anterior, lo que describes es un pipeline o una orquestación, y ambos expresan las dependencias como corresponde en lugar de hacer que el director las simule con vibe_wait.

Relacionado

• Ejecutar agentes en paralelo — las otras formas de repartir el trabajo
• Orquestación — cuando el trabajo tiene una forma
• Herramientas de agente integradas — los verbos y sus argumentos