Le swarm de Cursor a reconstruit SQLite de zéro. Mêmes scores, factures radicalement différentes

Le swarm d'agents de Cursor a implémenté le manuel SQLite de 835 pages en Rust à partir d'une page blanche, sans code source, sans suites de tests, sans binaire et sans internet. Il a été évalué sur sqllogictest, la suite de tests du projet comprenant des millions de requêtes avec réponses connues, et n'a jamais été informé de l'existence de cette suite. Les quatre configurations du harnais repensé ont finalement validé 100 % de celle-ci.

L'expérience compare l'ancien et le nouveau harnais sur la même tâche, avec les mêmes modèles et le même budget de temps. Le nouveau a battu l'ancien dans toutes les configurations. Avec Grok 4.5 dans les deux rôles, il a atteint 80 % en quatre heures, tandis que l'ancien swarm a calé et a été mis en pause avant la fin de sa deuxième heure. Cursor prévient que les tendances comptent plus que les relevés isolés : certains agents obtiennent des scores faibles pendant des heures avant une remontée tardive, d'autres atteignent un pic tôt puis plafonnent.

La taxe de coordination : 70 000 conflits

Les données d'activité ressemblent à de la productivité jusqu'à ce qu'on les mette en regard des résultats. L'ancienne exécution avec Grok 4.5 a réalisé 68 000 commits au cours de ses deux premières heures, soit environ 70 fois le rythme de la nouvelle exécution, et a accumulé plus de 70 000 conflits de fusion, en s'accélérant au lieu de se stabiliser. La nouvelle exécution a enregistré moins d'un millier de conflits en quatre heures. Le fichier le plus contesté de l'ancienne exécution a suscité 7 771 conflits de la part de 1 173 agents différents. Le fichier le plus chaud de la nouvelle exécution en a vu 47.

Le code final montre le même écart. L'ancienne exécution s'étalait sur 54 crates Rust, dont trois paquets SQL distincts, la signature de deux planificateurs construisant silencieusement la même chose dans des recoins différents du codebase. Cursor appelle cela le split-brain. La nouvelle exécution s'est stabilisée sur neuf crates et n'en a plus jamais ajouté. Dans la combinaison Fable 5, l'ancien harnais a eu besoin de 64 305 lignes de code moteur pour passer la suite ; le nouveau l'a fait en 9 908. Dans la combinaison Opus : 19 013 lignes à 97 %, contre 4 645 à 100 %.

Le rythme impose l'ingénierie. Le précédent swarm Browser culminait à près de 1 000 commits par heure sur Git ; le nouveau système culmine à près de 1 000 par seconde sur un système de contrôle de version que Cursor a construit de zéro.

La plupart des correctifs autour de cela relèvent du processus, non de l'intelligence des modèles. Un troisième agent neutre résout les conflits de fusion, comme le ferait une file d'attente de merge humaine. Les workers peuvent signaler les mégafichiers surdimensionnés, bloquant les nouveaux commits jusqu'à ce qu'un autre agent divise le fichier. Les décisions de conception sont consignées dans des documents partagés que le code référence au moment de la compilation ; lorsque deux planificateurs se contredisent, une réconciliation fusionne les documents et les références propagent la résolution en aval. Les agents peuvent même apporter délibérément des changements cassants hors de leur périmètre s'ils laissent un commentaire, et chaque agent qui en subit les contrecoups lit le raisonnement. Un mode de défaillance que Cursor nomme est l'ossification : les agents avaient appris à ne pas toucher au code critique, même lorsqu'il devait changer.

Là où les factures divergent

Le constat économique est celui qui mérite d'être retenu. Chaque répartition de modèles a produit une qualité similaire, affirme Cursor, tandis que les coûts variaient énormément. L'exécution utilisant GPT-5.5 pour les deux rôles a facturé 9 373 $ rien que pour les workers. Une exécution solo avec GPT-5.5 a coûté 1 339 $. À quatre heures, les nouvelles exécutions se situaient entre 73 % et 85 %, les anciennes entre 11 % et 77 %, et chaque nouvelle configuration a finalement abouti à 100 %.

Les workers ont consommé au moins 69 % des tokens dans chaque exécution, plus de 90 % dans la plupart, mais les tokens de planification coûtent plus cher. Dans la combinaison Opus 4.8 et Composer 2.5, Opus a produit une petite fraction des tokens et environ les deux tiers du coût. Le choix du modèle ne détermine pas à lui seul la facture : le planificateur Fable 5 a facturé légèrement moins que le planificateur Opus 4.8 malgré un prix par token environ deux fois plus élevé, car il a utilisé beaucoup moins de tokens de planification. Ensuite, ses workers ont consommé plusieurs fois plus de tokens, et l'exécution a coûté nettement plus cher.

Peu d'étapes d'une tâche de grande ampleur nécessitent une intelligence de pointe : la décomposition initiale, les décisions de conception, certains arbitrages. Une fois qu'un planificateur de premier plan a converti l'ambiguïté en instruction explicite, des modèles moins chers n'ont plus qu'à l'exécuter. Le même instinct apparaît ailleurs dans l'ingénierie des agents. Un système de routage appelé CodeRescue utilise le retour d'exécution pour décider quand un modèle bon marché doit réessayer, atteignant des taux de résolution quasi parfaits pour 35 % du coût d'une escalade systématique.

Voici comment les quatre configurations se comparent, selon Cursor :

La spec devient l'unité de travail

Chaque bond en capacité des modèles a élevé le niveau auquel un ingénieur travaille, soutient Cursor. L'autocomplétion a fait passer les ingénieurs du niveau de la ligne, les premiers modèles à celui des blocs de code, les agents à celui des fichiers et des fonctionnalités. Avec les swarms, l'unité de travail devient la spécification : 835 pages de prose en entrée, une base de données en sortie. La partie rare consistait à énoncer l'intention suffisamment bien. Le swarm commence à ressembler à un compilateur, décomposant un objectif en arbre de tâches et le convertissant pas à pas en travail exécutable. Un compilateur préserve le sens à chaque étape ; le swarm reste probabiliste à chaque étape, et l'essentiel des mécanismes que Cursor décrit existe pour combler cet écart. Ronald Coase reconnaîtrait la forme : les coûts de coordination croissent plus vite que le travail lui-même, si bien que les organisations forment des couches délimitées au lieu de faire dialoguer tout le monde avec tout le monde.

Deux mécanismes se démarquent. Le Field Guide est un dossier appartenant aux agents, dont l'index.md est injecté dans chaque agent au démarrage sous un budget de lignes. Les poids des modèles étant figés, le raisonnement est que les situations inattendues sont précisément ce qui mérite d'être consigné. Cursor a également testé des angles de revue allant du transcript intégral d'un worker à rien d'autre que le codebase, avec des reviewers sur différents modèles, runs d'entraînement et personnalités. Aucun angle seul ne capture tout, mais des angles décorrélés manquent moins de choses, de la même manière que les systèmes de conduite autonome battent les humains en agrégat sans composant parfait.

Une note de bas de page montre à quel point la pile reste fragile. Cursor voulait GPT-5.6 Sol pour sa configuration vedette, mais le nouveau modèle est parti en vrille sur un phrasé littéral et insistant ; il est donc revenu à GPT-5.5 plutôt que d'ajuster un modèle et fausser la comparaison. Les gains du harnais reposent sur un comportement de modèle encore inégal.

Le résultat de l'exécution solo d'Opus 4.8 est public sur github.com/cursor/minisqlite pour qui veut le décortiquer ; Cursor indique qu'il semble excellent au premier regard et n'a pas effectué de revue manuelle plus approfondie. En résumé : le harnais est passé de fonctionnel à peine à fonctionnel de manière fiable, et cette fiabilité a transformé le choix du mix de modèles en décision de coût plutôt qu'en pari sur la qualité.