Ingeniería agéntica

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

conf

Cada 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

sh

Un 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

text

Los 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.

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.

© 2026 - Ryware.