Cursor publie les résultats d’une expérience longue : un système d’agents travaillant en parallèle pour reconstruire SQLite de zéro en Rust, en partant uniquement de la documentation. L’architecture a deux rôles : des agents planificateurs avec les modèles les plus coûteux qui décomposent l’objectif en sous-tâches, et des agents exécuteurs avec des modèles économiques qui les implémentent.

Le chiffre qui compte concerne le coût. Changer quels modèles font quels travaux ne change pas la qualité du résultat final, mais modifie les coûts de façon drastique. Un modèle puissant qui planifie et un modèle économique qui exécute produisent le même output qu’un modèle puissant qui fait tout, à une fraction du prix.

Cursor attribue le gain à l’efficacité du contexte plus qu’au parallélisme brut. Le planificateur n’écrit jamais de code, donc son contexte reste libre des détails de bas niveau. L’exécuteur ne planifie jamais, donc consacre tout son contexte à un seul morceau. La forme du système grandit pour s’adapter au problème, comme une organisation qui se divise en unités quand les coûts de coordination surpassent la valeur du travail direct.

Nous suivions ce fil. Le 12 juillet, nous racontions comment GPT-5.6 Sol Ultra avait utilisé 64 sous-agents en parallèle pour une démonstration mathématique vérifiée. Le post de Cursor porte le même principe sur le terrain du logiciel et lui donne un cadre économique : quel modèle assigner à quel rôle, et combien ça coûte.

Cursor est honnête sur les limites. Le premier swarm avait construit un navigateur « loin d’un logiciel affiné ». SQLite de zéro reste aussi une preuve de concept, pas un produit prêt.

En détail

D’où ça vient.

En début d’année, Cursor avait lancé un premier swarm avec un objectif ambitieux : construire un navigateur web de zéro. L’expérience avait réussi comme preuve de concept, mais le résultat était un logiciel brut, pas affiné. L’approche était délibérément empirique : partir d’une toile blanche et améliorer par essais jusqu’à trouver quelque chose de stable.

Le nouveau travail revient sur une tâche que l’ancien swarm avait échouée : reconstruire SQLite en Rust à partir de la seule documentation. Même tâche, mêmes modèles, même budget temps. Ils mesurent combien de la suite de tests officielle (mise de côté, non vue pendant le développement) chaque système surpasse.

Les chiffres.

Avec Grok 4.5, le nouveau swarm atteint 80% de la suite de tests en quatre heures. L’ancien swarm devait être arrêté avant la deuxième heure parce qu’il « spiralait ». Cursor rapporte que chaque configuration de modèles testée avec le nouveau système a surpassé l’ancien.

Sur le front de la vitesse d’exécution, Cursor a construit un système de contrôle de version de zéro. L’ancien pic était environ 1 000 commits par heure avec Git. Le nouveau système atteint 1 000 commits par seconde. Le VCS est là où les conflits deviennent visibles, et certains mécanismes de coordination sont implémentés directement dedans.

Pourquoi le contexte importe plus que le parallélisme.

La thèse centrale est que le gain vient de l’efficacité du contexte, pas du fait de s’exécuter en parallèle. Quand un seul agent affronte une tâche entière, il doit garder en tête l’objectif global, la position actuelle dans l’arbre de travail et les détails de bas niveau. Après un moment, il perd le fil : soit il se concentre sur le morceau et oublie le tableau d’ensemble, soit il garde le tableau et se débrouille plus mal sur le morceau.

Dans le swarm, le planificateur n’implémente jamais. Son contexte reste propre. L’exécuteur ne planifie jamais. Son contexte est tout pour un morceau étroit. La forme du système grandit pour s’adapter au problème, au lieu d’imposer une topologie fixe.

Cursor cite Ronald Coase : les organisations se stratifient en unités avec des frontières parce que les coûts de coordination croissent plus vite que le travail. Le swarm fait la même chose avec les agents.

Où ça casse.

À 1 000 commits par seconde, apparaissent des modes de défaillance que les équipes humaines ne rencontrent pas.

Le premier est le split-brain : deux planificateurs, ignorants l’un de l’autre, implémentent le même concept de deux façons différentes dans différentes parties du code. Cursor le résout avec du prompting : les planificateurs prennent les décisions de design seuls et doivent garantir que deux sous-arbres ne décident pas la même question.

Le second est le conflit entre planificateurs : deux planificateurs qui se connaissent se battent avec des modifications back-and-forth sur les mêmes fichiers. L’outil de fusion ne résout pas un désaccord, il résout juste du texte. Cursor fait enregistrer les décisions dans des documents de conception partagés.

Ce qui manque.

Le post est honnête sur les limites : le swarm qui construit SQLite reste une preuve de concept, pas un logiciel prêt. La « nouvelle économie des modèles » est décrite dans les résultats (mix différents, coûts différents, qualité similaire) mais les chiffres de coût spécifiques ne sont pas publiés en détail. Pour qui construit des agents, la direction est claire (planificateur puissant + exécuteur économique), mais le calibrage exact reste à faire sur son propre cas.

Ceci confirme un fil qui traverse les dernières semaines : l’orchestration importe plus que le modèle. Aujourd’hui trois papers convergents disaient la même chose avec des données de production. Le 12 juillet, GPT-5.6 Sol Ultra montrait 64 sous-agents parallèles pour les mathématiques. Maintenant Cursor apporte la preuve empirique sur le code.