Un enjambre de DreamTeam sin gestor escribió trustcheck por $5,68 y superó 13 de 13 pruebas ocultas

DreamTeam es un framework open source en Python (licencia MIT) para un enjambre autoorganizado de agentes de IA, sin agente gestor. A los agentes se les da un único objetivo, un tablero de tareas común, una carpeta git compartida y la posibilidad de escribirse entre ellos; a partir de ahí lo resuelven todo por su cuenta. El autor lo probó con cuatro tareas cuya respuesta se puede verificar de forma independiente: tres matemáticas y una de ingeniería.

La más reveladora es la de ingeniería: un enjambre de 8 agentes con el modelo barato deepseek-v4.1-flash escribió en unas tres horas y por $5,68 la herramienta trustcheck, que responde a la pregunta «¿se puede confiar en los tests?» La evaluó un benchmark oculto de Claude: 13 repositorios git con trampas y una respuesta correcta conocida.

Un stub vacío en lugar de la herramienta pasa 1 de 13; el trustcheck terminado, 13 de 13. Claude se conectó al enjambre por MCP como usuario y como verificador externo.

Un tablero en lugar de un gestor

La sesión arranca con una única tarea: «planificar». La toma de forma atómica el primer agente libre, de modo que dos agentes no pueden recibir la misma tarea. El planificador reparte el trabajo: primero las tareas independientes (literatura, entorno, datos, experimentos de prueba), para que el resto no se quede parado, y después las dependientes. Cada tarea tiene un criterio de éxito, un ejecutor, un revisor y dependencias. El ejecutor no puede dar por buena su propia obra: la revisión la hace otro participante y, si no lo hay, la tarea pasa a una persona. Si faltan manos, los agentes contratan colegas del catálogo de roles dentro de un límite.

Cuando falta una herramienta, el propio agente la escribe como servidor MCP y todo el enjambre la usa. El enjambre en sí también es un servidor MCP, así que Claude Code puede observarlo, dirigirlo o incorporarse al equipo como un participante más.

Cuatro ejecuciones: del tercer puesto a una tabla mal calculada

En el problema de Erdős del solapamiento mínimo (cuanto menor es la estimación de la constante, mejor), 4 agentes lograron en 1 hora y 40 minutos, por $0,51, una estimación no superior a 0,38090966633824946 con una función escalonada de 800 escalones. Es mejor que los resultados de Haugland (0,380927) y AlphaEvolve (0,380923), pero peor que Hill Sampling (0,38088232) y TTT-Discover (0,380876). No hay récord: hay un tercer puesto.

En el problema de los amplificadores de selección se busca un grafo en el que una mutación beneficiosa se fije con más frecuencia que en una población mezclada, y además con las dos reglas del proceso de Moran a la vez: Birth-death y death-Birth. 8 agentes encontraron en 2 horas y 40 minutos, por $3,97, un amplificador simultáneo estricto de 14 vértices, mientras que el ejemplo conocido hasta entonces tenía en torno a mil. El efecto es minúsculo: amplificación con r de 1 a aproximadamente 1,016 y una ganancia no superior a ~10⁻⁵.

Claude certificó el resultado con cuatro valores de r y demostró por búsqueda exhaustiva que no existe un grafo no ponderado así con N ≤ 8. El autor contrastó la novedad solo con unos pocos artículos de 2024–2026 y no se presenta como «el primero».

La ejecución más instructiva fue el problema de Thomson en el disco: colocar N cargas idénticas de modo que la energía de repulsión sea mínima. En poco más de cuatro horas y por $3,98, el enjambre produjo configuraciones para los 131 valores de N de 20 a 150 y reprodujo cuatro récords recientes con tres métodos independientes. En 57 valores de N, su energía resultó inferior a la de la tabla de Amore-Zarate en 10⁻⁹…

10⁻⁶. Pero Claude refinó las configuraciones originales con el método de Newton y obtuvo las mismas energías: los puntos publicados simplemente estaban insuficientemente calculados. Al final, en 128 de los 131 valores de N el mínimo coincidió con la tabla; en N = 131–133 el del enjambre es 0,07–0,08 superior, y en ninguno es inferior.

La conclusión del autor: el enjambre proclama el éxito con alegría a partir de una diferencia numérica en bruto, y la revisión interna comprueba que la tarea esté hecha, pero no que el resultado sea correcto. Solo protege la verificación externa.

En la ejecución de ingeniería, trustcheck hace pruebas de mutación dentro del diff, emite veredictos sobre cada test y busca manipulaciones en el historial de commits. El paquete final contiene 231 tests que pasan. Los conjuntos de trampas v2 y v3 se fueron añadiendo sobre la marcha: una vez, un arreglo para el conjunto anterior provocó una regresión y solo la detectó el nuevo. Tras la segunda ronda ($4,15), en el conjunto nuevo v4 el stub obtuvo 2/12 y la herramienta, 12/12.

Lo que sigue sin resolverse

Con unos ~1400 tests del propio DreamTeam, trustcheck tarda de 13 a 25 minutos, y su puntuación sobre ese código es 0,60 con un objetivo de 0,7. En un A/B con tres bugs históricos de cookiecutter, el skill trustcheck no ayudó: los tests ocultos pasaron 29/29 en ambos brazos, y las correcciones erróneas se detectaron 13/13 sin skill y 12/13 con skill, a un coste de $1,00 frente a $0,81. Ambos grupos chocaron con el techo. De paso se descubrió que un agente con acceso a la red puede descargar una versión de la biblioteca en la que el bug ya está corregido, por lo que se añadió un modo de sesión sin internet.

Las ejecuciones sacaron a la luz otros problemas que el autor convirtió en correcciones: el planificador hacía depender el informe final de tareas opcionales, el arquitecto pasó 30 minutos sin poder salir de un razonamiento cortado por el límite de salida y, ante la petición de «terminar», los agentes lanzaban un cálculo «rápido» más con 16 procesos. Ahora existe un modo de cierre sin nuevos procesos en segundo plano, y el límite de salida se duplica tras un corte. La lección práctica para quienes construyen sus propios agentes: la retroalimentación útil aparece en ejecuciones largas con tareas reales, no en demos cortas, y siempre hace falta un verificador independiente.