Cursor a lancé ses swarms d’agents sur une vraie tâche : reconstruire SQLite en Rust en utilisant seulement les 835 pages de documentation, sans code source ni internet. Le nouveau système divise les agents en deux rôles : planificateurs avec des modèles frontier qui décomposent le travail, et exécuteurs avec des modèles économiques qui le réalisent. Chaque configuration du nouveau système a atteint 100% de la test suite ; la version précédente plafonait entre 11 et 77%.

Pourquoi cela te concerne : l’architecture compte plus que le modèle isolé, et maintenant il existe un chiffre pour le prouver. La configuration hybride Opus 4.8 comme planificateur et Composer 2.5 comme exécuteur a dépensé 1.339 dollars contre 10.565 de GPT-5.5 utilisé seul, avec le même résultat final (source : The Decoder, 26 juillet 2026). Les exécuteurs consomment entre 69 et 90% des tokens à chaque exécution : c’est là que l’économie se matérialise, parce que tu utilises le modèle coûteux seulement là où le jugement compte, pas là où compte l’effort.

Le principe va au-delà du code. Si tu as une tâche longue avec des étapes répétitives, séparer celui qui décide de celui qui exécute change l’équation coût-qualité. C’est la même direction que trois papers que nous commentions le 20 juillet : l’orchestration l’emporte sur la puissance brute.

En détail

Le test de Cursor est un vrai setup. Les agents reçoivent le manuel SQLite de 835 pages et doivent produire une implémentation en Rust qui passe sqllogictest, une suite avec des millions de requêtes SQL et des réponses connues. Pas de code source, pas de test suite visible, pas d’internet. Quatre configurations en comparaison : GPT-5.5 seul, Grok 4.5 seul, Opus 4.8 comme planificateur avec Composer 2.5 comme exécuteur, et Fable 5 comme planificateur avec Composer 2.5 comme exécuteur.

Après quatre heures, les configurations du nouveau système affichaient entre 73 et 85%, avant d’atteindre toutes 100%. L’ancien système plafonnait au maximum à 77% et dans un cas s’arrêtait à 11%.

Où l’ancien système échouait. La version précédente produisait 68.000 commits en deux heures, environ 70 fois plus que le nouveau système. La plupart était du travail gaspillé : plus de 70.000 conflits de merge accumulés, contre moins de 1.000 dans le nouveau. Le problème principal était le “split-brain” : deux planificateurs construisaient la même idée à des endroits différents, avec des implémentations différentes. Quand les planificateurs se connaissaient, ils se bloquaient mutuellement avec des modifications concurrentes.

Comment ils l’ont résolu. Les agents enregistrent les décisions dans des documents de design partagés. Le code lié à une décision porte une référence vérifiée par le compilateur. Quand des conflits émergent, un agent neutre les résout. Les fichiers trop volumineux sont signalés pour être décomposés en modules plus petits.

Un détail intéressant est le field guide, un dossier de connaissances maintenu par les agents eux-mêmes avec une limite de lignes fixe. Chaque agent en reçoit le contenu au démarrage. Puisque les poids du modèle sont figés, capturer les découvertes surprenantes permet aux agents suivants de prendre des raccourcis. C’est de la mémoire externe, pas de l’entraînement.

Le coût. Les totaux vont de 1.339 dollars de la configuration Opus hybride à 10.565 de GPT-5.5 seul. Les exécuteurs consomment au moins 69% des tokens à chaque exécution, généralement plus de 90%. Les planificateurs coûtent plus cher par token mais en utilisent beaucoup moins. L’économie est claire : dépense où le jugement compte, économise où compte la persévérance.

Une limite de lecture. Les chiffres proviennent de l’implémentation de Cursor sur une seule tâche, même si ambitieuse. SQLite a une spécification excellente et une test suite rigoureuse : des conditions quasi idéales pour un agent. On ne peut pas garantir que le même avantage se maintienne sur des tâches avec des exigences vagues ou une documentation fragmentée. Et le fait que Cursor ait dû construire un système de contrôle de version propriétaire pour gérer 1.000 commits par seconde dit combien cette architecture est liée à une infrastructure spécifique, non reproductible avec un prompt.

Si tu veux comprendre comment appliquer le principe de la séparation entre planification et exécution à tes tâches, la leçon du cours sur comment orchestrer plusieurs agents part de là : rôles clairs au lieu de responsabilités dupliquées.