Équipes d'agents à 155$ au lieu de 510$ : Cohere a trouvé où déléguer rentable

Les agents ont déménagé en production

Au cours de la dernière année, les équipes d'agents programmeurs sont sorties du statut de démonstrations intéressantes pour devenir de vrais projets industriels. Seize agents Claude ont écrit un compilateur C de 100 000 lignes de code, capable de compiler le noyau Linux, en dépensant environ 2 000 sessions et 20 000$ d'API. L'équipe de Cursor a lancé des centaines d'agents qui ont co-écrit un navigateur web de plus d'un million de lignes de code en une semaine. Le projet Bun a migré sa base de code de Zig vers Rust en 11 jours, en utilisant 64 agents Claude travaillant en parallèle.

Chacun de ces projets a produit du code fonctionnel, mais ils différaient dans leur mode d'organisation : le compilateur a été assemblé par des agents égaux sans orchestrateur, saisissant les tâches via des fichiers de verrouillage (lock-files) ; Cursor a appliqué une hiérarchie — des planificateurs décomposaient récursivement le travail en sous-tâches pour des centaines d'exécutants ; Bun a attribué des rôles fixes : un implémenteur, deux relecteurs critiques et un correcteur pour chaque tâche.

Comparer ces projets ne dirait rien sur les décisions qui ont réellement pesé et sur leur coût. Factory a publié une étude de son propre système à trois rôles (orchestrateur → implémenteur → validateur en boucle) : sur une tâche unique (restauration de la bibliothèque GDAL), son équipe a doublé le résultat d'un agent seul, mais pour 14 fois le coût et 13 fois le temps.

Où déléguer compte plus que combien d'agents

Cohere a construit un banc d'essai contrôlé basé sur mini-SWE-agent : chaque agent travaille via une interface bash dans un espace de travail commun, le leader distribue les tâches via l'outil delegate_agent, les exécutants ne voient que leur sous-tâche. Cinq variables ont été étudiées :

1. Où le leader utilise les exécutants : un prompt minimal se contente d'ordonner de gérer l'équipe ; un prompt structuré (P-I-V) ajoute des étapes explicites — planification, implémentation, vérification. 2. Comment le leader attend : synchrone (attend que tous rapportent) ou asynchrone (continue de travailler lui-même, en vérifiant les mises à jour à la demande). 3. Quels modèles pour quels rôles : équipes homogènes (tous sur Sol) contre hétérogènes (leader sur Sol, exécutants sur Luna). 4. Taille de l'équipe : le leader décide lui-même du nombre d'exécutants nécessaires, ou la taille est fixée à 2, 4, 8, 16. 5. Communication : via le leader (par défaut) ou directement entre agents.

Les tests ont été menés sur le benchmark ProgramBench — 200 programmes, des utilitaires (jq, ripgrep) aux systèmes complexes (SQLite, FFmpeg, l'interpréteur PHP). L'agent ne voit que le binaire fonctionnel et la documentation du programme original, il doit comprendre le comportement par ingénierie inverse et écrire une nouvelle implémentation. L'évaluation se fait au pourcentage de tests de comportement réussis.

La planification rapporte 2× plus

Une équipe solide d'agents Sol a dépassé un seul agent de 9,7 points (61,8% contre 52,1%), mais à un coût 4 à 7 fois supérieur. Un leader asynchrone économise du temps : avec un prompt PIV, il termine 19,5% plus vite pour un résultat identique.

La découverte principale : quand le leader déléguait uniquement la planification (des agents Luna explorent le programme, déterminent le comportement, esquissent un plan), il a atteint 63,6% de justesse pour 249$. C'est exactement la moitié des 510$ dépensés par une équipe déléguant les trois étapes, pour une perte de seulement 0,4 point (63,2% contre 63,6%). L'implémentation et la vérification ont donné sensiblement moins — 58 à 71% avec les mêmes 16 agents.

La raison tient à la conception de ProgramBench : le programme cible est une boîte noire, dont le comportement doit être découvert par des tests. Les exécutants-planificateurs sondent en parallèle différentes parties de l'interface, le leader rassemble les rapports et écrit le code lui-même. C'est ce parallélisme qui offre le meilleur retour sur investissement.

Sur l'exemple de l'utilitaire dsq : un seul agent avec prompt PIV atteignait 60%, l'équipe déléguant uniquement la planification — 76 à 79%, et chacune de ses six exécutions a dépassé chaque exécution en solo. Déléguer l'implémentation ou la vérification dans les mêmes conditions a donné 58 à 71%.

Le benchmark secondaire Commit0-Lite (16 bibliothèques Python avec implémentation supprimée, mais documentation et tests complets) a confirmé ce résultat : quand la spécification est donnée explicitement, l'étape de planification reste critique.