SwarmForge: lo que acierta el enjambre de agentes de Uncle Bob
SwarmForge ejecuta varios agentes de programación con IA en ventanas de tmux, cada uno en su propio worktree de git y con exactamente un rol de ingeniería. El tooling es deliberadamente aburrido. Lo interesante es el organigrama que codifica.
Qué es SwarmForge en realidad
SwarmForge es un armazón de shell y Babashka sobre tres primitivas que la mayoría de los equipos ya tiene: ventanas de tmux, worktrees de git y archivos de prompt. Cada ventana ejecuta un agente en un rol contra su propio worktree bajo .worktrees/, de modo que dos agentes nunca se pelean por el mismo directorio de trabajo. El comportamiento viene de texto plano en swarmforge/roles/<role>.prompt, apoyado sobre una constitution.prompt compartida y sus artículos. Los agentes no escriben en la terminal de los demás: encolan traspasos validados a través de .swarmforge/handoffs/, y la carga útil es o una abreviatura de commit de diez caracteres o una nota de ochenta caracteres como máximo. Los backends se eligen por rol, así que una sesión puede mezclar Claude, Codex, Copilot y Grok.
La rama main es documental. Los enjambres ejecutables viven en las ramas two-pack, four-pack y six-pack: se descarga la rama con la forma que se quiere y se lanza ./swarm. Los requisitos son zsh, git, tmux, Babashka y una CLI de agente configurada.
Tres formas de enjambre
Cada rama es una respuesta distinta a cuánto proceso merece una tarea. El flujo es un anillo, no una cola: el trabajo vuelve a pasar.
two-pack
coder → cleaner → coder
Un coder que trabaja test-first y un cleaner que hace limpieza, revisión de CRAP y DRY, y correcciones de arquitectura. El bucle útil más pequeño: escribirlo y entregárselo a alguien que no le tenga apego.
four-pack
specifier → coder → refactorer → architect → specifier
Las especificaciones de aceptación en Gherkin entran al principio. Un refactorer limpia sin cambiar el comportamiento y sube la cobertura, y un architect revisa la estructura y la dirección de las dependencias antes de que el anillo vuelva a la especificación.
six-pack
specifier → coder → cleaner → architect → hardener → QA
Añade una pasada de endurecimiento que muta el código para encontrar puntos ciegos, y un rol de QA que ejecuta verificación real. Es la forma que trata la calidad como preocupaciones separadas en lugar de como la buena voluntad de un solo agente.
Un agente, una disciplina
Los roles son el argumento. Cada uno es un trabajo que normalmente se comprime en la misma persona, en la misma hora y bajo la misma fecha límite.
specifier
Escribe especificaciones de aceptación en Gherkin y procedimientos de QA. Nada entra al enjambre como una frase vaga, que es el modo de fallo del que la mayoría de los flujos con agentes nunca se recupera.
coder
Implementa test-first. Es el prompt del rol, y no una página de normas que nadie lee, lo que convierte el TDD en el comportamiento por defecto de esa ventana.
cleaner
Limpieza local, cobertura, revisión de CRAP y DRY. El nombrado y la duplicación reciben una pasada dedicada en lugar de un comentario de revisión que nadie llega a aplicar.
architect
Estructura de módulos, fronteras, dirección de dependencias. El único rol al que se le permite preocuparse por la forma del conjunto en lugar del ticket que tiene delante.
rol de endurecimiento
Endurecimiento por mutación: perturbar el código y averiguar dónde está ciega la suite. Una comprobación negativa, colocada deliberadamente después de que el código ya esté limpio.
QA
Scripts de verificación ejecutables y notificaciones. La verificación es algo que se ejecuta e informa, no la sensación de que el cambio se veía bien.
Cómo funciona la coordinación
Tres archivos y tres scripts sostienen todo el protocolo. Ese es justamente el punto: la topología es dato y la disciplina es texto.
La topología cabe en un archivo de configuración
confCada línea declara una ventana de tmux: qué rol, qué backend de agente, qué worktree y si recibe trabajo por tarea o por lotes.
# swarmforge/swarmforge.conf
# window <role> <agent> <worktree> [task|batch] [extra-cli-args...]
window coordinator codex master
window coder codex coder
window architect codex architect Los traspasos se validan, no se conversan
shUn agente encola un traspaso saliente, el rol siguiente acepta trabajo cuando está libre, y cerrar el elemento actual es un acto explícito. La carga útil es un commit o una nota muy corta, así que el significado tiene que viajar en el código.
# queue work for the next role: a commit, or a note of <= 80 chars
./swarm_handoff.sh coder 4f2a9c1b0d "boundary rule now specified"
# on the receiving side
./ready_for_next.sh # accept the next item or batch
./done_with_current.sh # close it out and free the window El estándar vive en el árbol de prompts
textLos artículos compartidos contienen las reglas de ingeniería, las reglas de traspaso y el flujo de trabajo; en los artículos locales un proyecto las sobrescribe. Los prompts de rol van encima. Tu estándar de código pasa a ser una entrada del trabajo en lugar de un documento sobre el trabajo.
swarmforge/
swarmforge.conf
constitution.prompt
constitution/articles/
engineering.prompt
handoffs.prompt
workflow.prompt
project.prompt
local-engineering.prompt
local-workflow.prompt
roles/
<role>.prompt Qué tomar prestado aunque nunca lo ejecutes
Dale a cada pasada un nombre y un único trabajo
- - Separa especificación, implementación, limpieza, estructura y verificación en pasadas distintas con instrucciones distintas
- - Deja de pedir a un agente, o a una persona, que sostenga las cinco preocupaciones a la vez
- - Nombra la pasada en el pull request para que quien revise sepa qué preguntas ya están respondidas
Aísla el espacio de trabajo, no solo la rama
- - Un worktree de git por rol elimina toda la clase de fallos en que dos agentes editan el mismo archivo a la vez
- - El aislamiento hace legible el trabajo en paralelo: cada rol tiene un árbol que se puede inspeccionar por separado
- - El mismo truco sirve para una persona que ejecuta varios agentes en local, sin enjambre alguno
Haz los traspasos estrechos y validados
- - Una referencia de commit más una línea corta obliga a que la intención esté en el código y en el mensaje
- - La validación en la frontera del traspaso detecta una petición mal formada antes de que el rol siguiente gaste una ejecución en ella
- - Los traspasos estrechos son auditables: se puede reconstruir quién pasó qué y cuándo
Mantén el estándar donde ocurre el trabajo
- - Las reglas de ingeniería escritas como artículos de prompt se leen en cada tarea, al contrario que una página de wiki
- - Separa las reglas compartidas de las sobrescrituras locales para que la excepción de un equipo no se convierta en la regla de todos
- - Versiona las reglas con el código y revisa sus cambios como código
Dónde están las reservas honestas
El anillo cuesta lo que cuesta
Seis roles revisándose entre sí implican varias ejecuciones de agente por cambio. En tareas pequeñas el bucle two-pack suele ser la opción racional; el six-pack es para trabajo cuyos defectos serían caros.
Ochenta caracteres son una tubería estrecha
La carga útil mínima del traspaso es una disciplina: el commit tiene que explicarse solo. También significa que el entendimiento compartido del enjambre vive por completo en las especificaciones y el código. Si tu base de código no se explica ya, el enjambre no lo va a arreglar por ti.
Los roles son prompts, no garantías
Un prompt que dice usar TDD es un empujón fuerte, no un mecanismo de cumplimiento. Lo que de verdad aguanta es ejecutable: la corrida de tests, la de mutación, el script de QA. Mantenlos en CI, no solo en el enjambre.
Alguien sigue firmando
La salida del enjambre es una propuesta de cambio, no una decisión de release. La responsabilidad no se reparte entre ventanas de tmux, y el trabajo de quien revisa se vuelve más duro, no más fácil, cuando sube el volumen de código plausible.
El flujo de trabajo es la aportación
Quita tmux, Babashka y la instalación por tarball y SwarmForge es una afirmación sobre la ingeniería de software: las disciplinas que mantienen el código habitable son separables, y cada una merece su propio turno con sus propias instrucciones. Eso ya era cierto antes de los agentes, y justamente por eso se transfiere.
Léelo como una implementación de referencia más que como una plataforma. Adopta la descomposición en roles, el aislamiento por worktree y el traspaso validado, y obtendrás casi todo el valor, ya haga el trabajo seis agentes, dos personas o una de cada.
Artículos de ingeniería relacionados
El rol de endurecimiento y el rol cleaner apuntan a prácticas que conviene entender por separado.
Las pruebas de mutación son negativas. Las de TDD, positivas.
Una ejecución de mutación solo informa de lo que una suite no detecta, mientras una prueba de TDD afirma lo que el sistema debe hacer. Cómo usar cada una en consecuencia.
La métrica CRAP: complejidad y cobertura en un número
Cómo la fórmula CRAP combina complejidad con cobertura, qué exige cada puntuación y cómo usarla como barrera sin abrir una épica de limpieza.
Preguntas frecuentes
¿Qué hace falta para ejecutar SwarmForge?
zsh, git, tmux y Babashka, más una CLI de agente configurada como Claude, Codex, Copilot o Grok. No hay servicio en la nube ni capa de orquestación que levantar: el enjambre son ventanas de tmux que puedes mirar, con un worktree por rol en disco.
¿Con qué rama debería empezar un equipo?
two-pack. Dos roles bastan para notar si la disciplina de traspaso encaja con tu trabajo, y el coste de un anillo completo de seis roles es difícil de justificar antes de saberlo.
¿Un enjambre de agentes elimina la necesidad de QA?
No. Traslada la QA a un rol con nombre y scripts ejecutables, lo que es mejor que dejarla implícita, pero la verificación sigue teniendo que escribirla alguien que entienda qué le debe el producto a sus usuarios.
¿Es orquestación lista para producción?
Trátalo como una referencia de flujo de trabajo más que como una plataforma gestionada. El valor duradero está en la descomposición de las preocupaciones de ingeniería y en el protocolo de traspaso estrecho, y ambos se pueden adoptar sin los scripts de shell.