Sans manager, l'essaim DreamTeam a écrit trustcheck pour $5,68 et réussi 13 tests cachés sur 13

DreamTeam est un framework open source en Python (licence MIT) pour un essaim auto-organisé d'agents IA, sans agent manager. Les agents reçoivent un objectif unique, un tableau de tâches commun, un dossier git partagé et la possibilité de s'écrire entre eux. Ils règlent ensuite tout par eux-mêmes.

L'auteur l'a testé sur quatre tâches dont la réponse peut être vérifiée de façon indépendante : trois en mathématiques et une en ingénierie. La plus parlante est la tâche d'ingénierie. Un essaim de 8 agents basé sur le modèle bon marché deepseek-v4.

1-flash a écrit en trois heures environ, pour $5,68, l'outil trustcheck, qui répond à la question « peut-on se fier aux tests ». Il a été évalué par un benchmark caché conçu par Claude : 13 dépôts git piégés, dont la bonne réponse est connue. Une implémentation vide (stub) à la place de l'outil réussit 1 dépôt sur 13, le trustcheck finalisé en réussit 13 sur 13.

Claude s'est connecté à l'essaim via MCP, à la fois comme utilisateur et comme contrôleur externe.

Un tableau à la place du manager

La session démarre avec une seule tâche : « planifier ». Le premier agent libre la prend de façon atomique, ce qui empêche deux agents de se saisir de la même tâche. Le planificateur répartit le travail : d'abord les tâches indépendantes (littérature, environnement, données, expériences d'essai), pour que les autres agents ne restent pas inactifs, puis les tâches dépendantes.

Chaque tâche a un critère de réussite, un exécutant, un relecteur et des dépendances. L'exécutant ne peut pas valider son propre travail : la revue revient à un autre participant, et s'il n'y en a pas, la tâche est confiée à un humain. Si les bras manquent, les agents recrutent des collègues dans un catalogue de rôles, dans la limite d'un plafond fixé.

Quand un outil manque, l'agent l'écrit lui-même sous forme de serveur MCP, et tout l'essaim peut l'utiliser. L'essaim est lui-même un serveur MCP : Claude Code peut donc l'observer, le piloter ou rejoindre l'équipe comme un participant de plus.

Quatre exécutions : de la troisième place à la table mal calculée

Sur le problème d'Erdős du recouvrement minimal (plus l'estimation de la constante est basse, meilleur est le résultat), 4 agents ont obtenu en 1 heure 40 minutes et pour $0,51 un score d'au plus 0,38090966633824946, avec une fonction en escalier de 800 marches. C'est mieux que les résultats de Haugland (0,380927) et d'AlphaEvolve (0,380923), mais moins bien que Hill Sampling (0,38088232) et TTT-Discover (0,380876). Pas de record, donc, mais une troisième place.

Le problème des amplificateurs de sélection demande un graphe sur lequel une mutation favorable se fixe plus souvent que dans une population bien mélangée, et ce simultanément pour les deux règles du processus de Moran, Birth-death et death-Birth. En 2 heures 40 minutes et pour $3,97, 8 agents ont trouvé un amplificateur simultané strict sur 14 sommets, alors que l'exemple connu jusque-là en comptait environ un millier. L'effet est minuscule : amplification pour r compris entre 1 et environ 1,016, et gain ne dépassant pas ~10⁻⁵.

Claude a certifié le résultat pour quatre valeurs de r et a montré par énumération exhaustive qu'il n'existe pas de tel graphe non pondéré pour N ≤ 8. L'auteur n'a comparé la nouveauté qu'à quelques articles de 2024–2026 et ne se présente pas comme le « premier ».

L'exécution la plus instructive concerne le problème de Thomson dans un disque : placer N charges identiques de façon à minimiser l'énergie de répulsion. En un peu plus de quatre heures et pour $3,98, l'essaim a produit des configurations pour les 131 valeurs de N de 20 à 150, et a reproduit quatre records récents avec trois méthodes indépendantes. Pour 57 valeurs de N, son énergie était inférieure à celle de la table d'Amore-Zarate de 10⁻⁹…

10⁻⁶. Mais Claude a affiné les configurations d'origine par la méthode de Newton et a obtenu les mêmes énergies : les points publiés étaient simplement insuffisamment calculés. Au final, sur 128 des 131 valeurs de N, le minimum coïncide avec la table ; pour N = 131–133, celui de l'essaim est supérieur de 0,07–0,08, et aucune valeur n'est inférieure.

La conclusion de l'auteur : l'essaim proclame volontiers un succès sur la seule base d'un écart brut entre deux nombres, et la revue interne vérifie que la tâche est faite, pas que le résultat est correct. Seul un contrôle extérieur protège de ce travers.

Dans l'exécution d'ingénierie, trustcheck réalise des tests de mutation limités au diff, rend un verdict sur chaque test individuel et cherche les falsifications dans l'historique des commits. Le paquet final contient 231 tests qui passent. Les jeux de pièges v2 et v3 ont été ajoutés en cours de route : une correction faite pour l'ancien jeu a un jour provoqué une régression, que seul le nouveau jeu a détectée. Après le deuxième tour ($4,15), sur le jeu neuf v4, le stub a obtenu 2/12 et l'outil 12/12.

Ce qui reste non résolu

Sur les ~1400 tests de DreamTeam lui-même, trustcheck met 13–25 minutes, et son score sur ce code est de 0,60 pour un objectif de 0,7. Lors d'un A/B sur trois bugs historiques de cookiecutter, le skill trustcheck n'a pas aidé : les tests cachés sont passés 29/29 dans les deux bras, et les correctifs erronés ont été détectés 13/13 sans le skill et 12/13 avec, pour un coût de $1,00 contre $0,81. Les deux groupes ont heurté un plafond. On a aussi découvert qu'un agent disposant d'un accès réseau peut télécharger une version de la bibliothèque où le bug est déjà corrigé ; d'où l'ajout d'un mode de session sans internet.

Les exécutions ont aussi révélé d'autres problèmes, que l'auteur a transformés en correctifs : le planificateur rendait le rapport final dépendant de tâches facultatives, l'architecte est resté 30 minutes incapable de sortir de raisonnements tronqués par la limite de sortie, et à la demande « terminez », les agents lançaient encore un calcul « rapide » sur 16 processus. Il existe désormais un mode de clôture sans nouveaux processus en arrière-plan, et la limite de sortie est doublée après une troncature. Leçon pratique pour ceux qui construisent leurs propres agents : les retours utiles apparaissent sur de longues exécutions avec de vraies tâches, pas sur de courtes démos, et un contrôleur indépendant est toujours nécessaire.