SwarmForge: la disciplina como respuesta a los agentes

"I'm significantly older than you. I started coding in the late 60s. My current strategy is to not read any of the code written by my agents. That's the only way I can take advantage of their productivity. What I do instead is to surround the agents with extreme constraints." – Robert C. Martin (@unclebobmartin), julio de 2026

Esta frase salió a la luz el 23 de julio de 2026 en X y dio la vuelta al mundo en menos de veinticuatro horas: decenas de miles de reacciones, miles de republicaciones y un debate encendido en Hacker News y LinkedIn. La mayoría se quedó en la superficie; unos lo aplaudieron como el futuro y otros lo tildaron de irresponsable. Casi nadie planteó la pregunta que de verdad importa: ¿qué tiene que ser cierto del código para que esa estrategia funcione?

Este artículo no va de la frase. Va de la respuesta que Uncle Bob ha construido para hacerla funcionar de verdad: SwarmForge.

Quién es Robert C. Martin

Para quien no lo conozca: Robert C. Martin es una de las figuras más influyentes de la ingeniería de software de las últimas cinco décadas. Cofirmante del Manifiesto Ágil. Autor de Clean Code (2008), probablemente el libro de programación más asignado en universidades de todo el mundo. Creador de los principios SOLID. Y lleva escribiendo código desde finales de los años sesenta.

Cuando alguien con ese historial dice algo, conviene escucharlo. Y cuando dice que ya no lee el código que producen sus agentes, muchos lo vieron como una rendición de la calidad. No ha abandonado sus principios: los ha delegado. Ya no lee el código porque lo ha rodeado de un sistema de restricciones tan exigentes que no necesita leerlo para confiar en él. Ese sistema, hecho código, es SwarmForge.

Qué es SwarmForge

SwarmForge es un sistema de orquestación de agentes que convierte enjambres de agentes de IA en ingenieros de software disciplinados. Está escrito en Clojure/Babashka, se apoya en tmux y git worktrees, y gira en torno a una idea central: un agente no debe hablar con otro agente directamente, y ningún agente debe tener acceso al socket de terminal del enjambre.

En lugar de eso, los agentes se comunican mediante un sistema de mensajería por ficheros, gobernado por un proceso en segundo plano y con traza de auditoría completa en cada transición. Todo se organiza en manadas de roles, los llamados packs. He analizado en profundidad el repositorio en GitHub (unclebob/swarm-forge) y aquí cuento, punto por punto, el ciclo completo del six-pack, la manada más completa.

El sistema de mensajes, el corazón del diseño

Antes de entrar en los roles, conviene entender cómo se comunican. La regla es estricta: los agentes no se escriben entre sí. Dejan notas en un sistema de casillas:

• Cada agente tiene una casilla de salida (outbox) y una de entrada (inbox) con estados new, in_process y completed.
• Un demonio escrito en Babashka vigila las casillas de salida, valida cada mensaje, lo copia a la casilla de entrada de cada destinatario y envía un único aviso genérico por tmux: "You have new handoff mail. If idle, run ready_fornext".
• El aviso es deliberadamente vago: no nombra el fichero, para no condicionar al destinatario y forzar que procese la cola en orden.

Solo existen dos tipos de mensaje, y ambos son estrictos:

• git_handoff: significa que el emisor ha llevado a commit un trozo de trabajo y que le toca al destinatario procesarlo. El mensaje no contiene el código: solo apunta a un commit de diez caracteres hexadecimales, validado contra git (debe resolver a un único objeto, y ese objeto debe ser un commit). Aporta un campo task con el nombre de la tarea, que mantiene la continuidad a lo largo de todos los traspasos.
• note: un mensaje de texto libre de un máximo de ochenta caracteres, desaconsejado salvo que el usuario, el rol o la constitución lo ordenen. Un agente bloqueado por ambigüedad debe detenerse y preguntar, no escribir una nota.

Esta arquitectura es una declaración de intenciones: los mensajes no llevan la narrativa del proceso del emisor. El contexto no viaja en la conversación; viaja en el repositorio. Y el protocolo prohíbe que un agente reenvíe un git_handoff cuando el commit no produce un cambio funcional real. La metadato, el formato o los manifiestos no cuentan: sin cambio funcional, se completa y se cierra. Nada de movimiento vacío entre roles.

El ciclo completo del six-pack

El six-pack es la manada completa: seis roles, cada uno dueño de una dimensión de la calidad. El flujo normal es specifier, coder, cleaner, architect, hardender y QA.

1. Specifier, la semilla del contexto

Todo empieza con la intención del usuario, y la primera regla es que el specifier pregunta hasta disipar toda la ambigüedad. Después convierte esa intención en especificaciones Gherkin (comportamiento observable, sin detallar cómo implementarlo) y en una suite de verificación completa que opera sobre la interfaz de usuario, nunca sobre una API interna. Hay un candado esencial: no entrega nada al coder hasta que el usuario aprueba el traspaso. El contexto de la tarea nace aquí, materializado en el repositorio y no en la memoria del agente.

2. Coder, reconstruye el contexto desde el repositorio

El coder recibe el traspaso, se mete en su worktree y lee la especificación Gherkin aceptada y las guías de arquitectura. Implementa con TDD: primero los tests unitarios, luego el código mínimo para que pasen. Cuando pasan también los tests de aceptación, hace commit y pasa el testigo. Y tiene reglas claras: no toca ni la suite de verificación de extremo a extremo, ni la mutación, ni CRAP, ni DRY.

3. Cleaner, la calidad sin cambiar el comportamiento

El cleaner trabaja por lotes (puede tomar varios traspasos del coder a la vez) y su identidad se resume en un precepto: "do not introduce new behavior". Limpia nombres, duplicación, límites y testabilidad; baja el CRAP a seis o menos; después aplica DRY; y si un fichero supera los cien puntos de mutación, lo divide. La garantía de que no rompe el contexto es que los tests deben seguir pasando.

4. Architect, la vista de conjunto

El architect es quien ve el mapa completo. Revisa la dirección de las dependencias, separa los módulos de alto nivel (lejos de la entrada y salida de datos) de los de bajo nivel (cerca de ella), evita que la política dependa de marcos o detalles de bajo nivel, y añade tests de propiedades e invariantes. Su trabajo es estructural: no añade comportamiento, reorganiza la arquitectura.

5. Hardender, la prueba de mutaciones

Aquí la disciplina se vuelve radical. El hardender ejecuta mutation testing: muta el código de forma sistemática y comprueba si la suite de tests detecta la mutación. Cada mutante que sobrevive es comportamiento mal cubierto. Después aplica una mutación suave sobre el Gherkin y vuelve a comprobar CRAP y DRY. Es el eslabón que convierte el "tengo tests" en "tengo tests que demuestran que me protegen".

6. QA, la verificación final contra la especificación

QA cierra el ciclo comprobando el resultado contra el contexto original. Convierte los procedimientos de verificación del specifier en guiones ejecutables, verifica por la interfaz la especificación aceptada, los tests generados, los unitarios y los de propiedades. Hay una regla de oro que resume toda la filosofía: si la suite de QA contradice el Gherkin o los tests unitarios, se detiene y se pregunta antes de cambiar el comportamiento. Con todo en verde, QA avisa a los otros cinco roles con la máxima prioridad, y el specifier integra y pregunta al usuario por la siguiente funcionalidad.

El contexto no viaja en los mensajes, viaja en el repositorio

Conviene insistir en esto porque es lo que distingue a SwarmForge de casi todo lo que circula por ahí: el contexto general de la tarea no viaja en los mensajes entre agentes. Los git_handoff son fichas de relevo deliberadamente escuetas (tarea, commit y prioridad). El contexto vive en el repositorio en dos formas: el Gherkin y la suite del specifier (el qué) y el código con sus tests (el cómo). Los agentes no tienen memoria de conversación sobre la tarea: la reconstruyen con el repositorio y con su constitución en cada worktree. Y la cadena de verificación (tests, mutación, QA) garantiza que nadie se desvíe de la especificación, porque cualquier desviación acaba rompiendo algún eslabón.

Mi reflexión: el porqué que casi nadie quiso escuchar

Cuando la frase se hizo viral, el debate giró casi por completo sobre si tiene razón. Pero la pregunta que importa, como señaló un buen análisis de Ivan Stepantsov, es otra: qué tiene que ser cierto del código para que esas puertas puedan avalarlo.

Y aquí está la respuesta que no todos vieron: el código limpio importa más que nunca, precisamente porque ya no hay un humano leyéndolo. Un estudio controlado de Sonar (arXiv:2605.20049, mayo de 2026) mostró que los agentes de IA consumen entre un siete y un ocho por ciento menos de tokens trabajando sobre código limpio, releen alrededor de un treinta y cuatro por ciento menos los ficheros que ya han tocado, y en tareas que cruzan varios módulos la diferencia supera el cincuenta por ciento. El lector para el que escribimos código limpio ya no es solo el humano de las dos de la madrugada: es el agente que lo va a mantener, y ese agente cobra por token.

Uncle Bob no ha abandonado el código limpio: lo ha convertido en infraestructura. Y ha comprado, como él mismo dice, la confianza que da el gauntlet, la carrera de obstáculos: una cadena de restricciones tan exigente que el código que la supera merece confianza sin ser leído. Es la misma lógica con la que dejamos de leer el binario que genera el compilador hace décadas. La diferencia es que el compilador ahora es una IA, y las restricciones que la rodean (TDD, Gherkin, mutación, CRAP, DRY, tests de propiedades) son las disciplinas que este hombre lleva predicando desde los años noventa.

Lo más profundo es el desplazamiento del juicio humano. Uncle Bob no ha dejado de ser responsable del código: ha subido la responsabilidad una capa, desde la implementación hasta la especificación del comportamiento correcto. Lee las especificaciones y los procedimientos de verificación (según la criticidad, a fondo o por muestreo) y deja el código a las restricciones. El ingeniero ya no es quien lee: es quien define las puertas por las que debe pasar el trabajo para merecer confianza.

Esa es la lección para cualquiera que use agentes hoy. La pregunta no es si debo leer el código que escribe la IA; es si mis restricciones son tan buenas que no necesito leerlo. Y para casi todos nosotros, la respuesta honesta es que todavía no. El mérito de Uncle Bob no es haber dejado de leer: es haber construido las restricciones que lo hacen posible. SwarmForge es la prueba de que esa filosofía no es un eslogan de una red social: es un sistema real, ejecutable, con demonios, colas, auditorías y roles. La disciplina como respuesta a los agentes, en código.

Un apunte para Ambrosio

Y una nota final para Ambrosio, que tan bien desmenuzó mi artículo anterior sobre la manada. Si estás leyendo esto: este repositorio merece tu análisis. Es el contrapunto perfecto a la conversación que abrimos sobre rendimiento y continuidad. SwarmForge es la apuesta más explícita que he visto por la continuidad llevada al extremo, con roles de identidad persistente, mensajería transaccional y auditoría completa, mientras que lo que construyo con Twinber prioriza la velocidad del enjambre. Y encima lo firma una de las tres o cuatro personas más influyentes de nuestra industria. Tu capacidad para separar el grano de la paja, como hiciste al distinguir herdr del orquestador, le sentaría de maravilla a este análisis. Te animo a dedicarle un rato: hay mucho que aprender, y mucho que debatir, entre las dos filosofías.

Nova