L’essentiel
- Cursor a fait reconstruire une implémentation de SQLite en Rust par un essaim d’agents, à partir du seul manuel de 835 pages, sans code source ni accès à internet.
- Les agents planificateurs tournent sur des modèles de pointe, les agents exécutants sur des modèles rapides et bon marché : les premiers n’écrivent aucune ligne de programme, les seconds ne décident de rien.
- Après quatre heures, les nouvelles configurations obtiennent 73 à 85 % de réussite sur la suite sqllogictest, contre 11 à 77 % pour l’ancienne ; toutes ont fini par valider l’intégralité des tests.
- À mille commits par seconde, Git ne suivait plus : Cursor a écrit son propre système de contrôle de version.
Cursor a posé un manuel de 835 pages devant son essaim d’agents, puis a coupé tout le reste : pas de code source, pas de binaire de référence, pas d’accès à internet. La consigne tenait en une ligne : reconstruire SQLite, le moteur de base de données embarqué le plus déployé au monde, dans le langage Rust.
Aucun modèle n’a mené ce chantier seul. Ce que Cursor met à l’épreuve, c’est une façon de faire travailler ensemble des modèles très inégaux en puissance et en prix.
Deux métiers, deux modèles
L’essaim de Cursor répartit ses agents en deux rôles étanches. Les agents planificateurs, adossés à des modèles de pointe, découpent récursivement un objectif en tâches plus petites. Les agents exécutants tournent sur des modèles plus rapides et nettement moins chers, et se contentent de réaliser ces tâches. L’ensemble forme un arbre de tâches qui se réorganise à mesure que le travail avance.
La règle est absolue : les planificateurs n’écrivent pas une ligne de programme, les exécutants ne planifient rien. Cette étanchéité a des airs de bureaucratie ; c’est pourtant elle qui tient le dispositif debout. Cursor n’est pas seul sur cette piste : Anthropic décrit la même répartition pour son mode Recherche, avec un agent principal sous Claude Opus 4 et des sous-agents Claude Sonnet 4, crédité de 90,2 % de mieux qu’un Opus 4 travaillant seul sur son évaluation interne.
Un agent seul finit par perdre le fil
Cursor explique que cette séparation règle avant tout un problème de contexte. Un agent unique doit parcourir tout l’arbre en gardant simultanément en tête l’objectif global et la micro-tâche du moment. Deux échelles, une seule fenêtre de contexte.
Un traducteur sommé de garder tout un roman en tête pour choisir chaque mot finit toujours par lâcher un bout. Après quelques chapitres, il tient encore le sens général ou la précision locale, rarement les deux. C’est la dérive qu’on observe sur les longues sessions d’agents : le travail reste plausible, il cesse d’être aligné.
Séparer les rôles ne rend pas les modèles plus intelligents : cela leur retire une charge qu’ils n’arrivaient pas à porter.
Mille commits par seconde, et Git lâche
Un essaim précédent, opérant dans le navigateur, plafonnait autour de mille commits par heure sur Git, avec des exécutants, un agent juge et un intégrateur chargé de résoudre les conflits. Cet intégrateur a fini par créer plus de goulots d’étranglement qu’il n’en supprimait.
Le nouveau système atteint mille commits par seconde. À ce régime, l’outillage habituel décroche : Cursor a bâti son propre système de contrôle de version, parce que des agents travaillant à cette cadence produisent des modes de défaillance qu’une équipe humaine ne rencontre jamais.
Le plus révélateur porte un nom, le « split-brain design » : deux planificateurs construisent sans le savoir la même idée, à deux endroits, de deux façons différentes. Prévenus l’un de l’autre, ils font pire encore : ils se bloquent avec des modifications concurrentes.
La parade tient en une discipline documentaire. Les agents consignent leurs décisions dans des documents de conception partagés, et chaque portion de code rattachée à une décision pointe vers son document par une référence vérifiée à la compilation. Un désaccord d’architecture devient une erreur de build, pas un bug découvert trois semaines plus tard.
Le reste suit la même logique. Un agent neutre arbitre les conflits de merge. Les exécutants signalent les fichiers devenus obèses à un agent extérieur qui les redécoupe en modules. Cursor a même dû désinhiber ses agents : entraînés à ne pas toucher au code central quand des humains sont dans la boucle, ils reçoivent ici l’autorisation explicite de casser, de patcher hors de leur périmètre et de laisser le compilateur propager le changement dans tout le système.
Trois relecteurs qui ne voient pas la même chose
Sur la relecture, plusieurs dispositifs ont été comparés. Un premier relecteur reçoit la transcription complète du travail de l’exécutant, un deuxième ne voit que le résultat produit, un troisième uniquement le code existant. Aucun angle ne détecte tout, mais leur combinaison se révèle plus fiable que le meilleur d’entre eux pris isolément.
Autre trouvaille, le « field guide » : un dossier de connaissances entretenu par les agents eux-mêmes, plafonné à un nombre de lignes fixe et distribué à chacun au démarrage. Les paramètres d’un modèle sont figés à la fin de son entraînement, et ce qu’il apprend en cours de route s’évapore avec la session. Écrire quelque part les découvertes surprenantes, c’est offrir des raccourcis aux agents suivants.
Où placer l’intelligence chère
Quatre configurations ont été mises en concurrence : l’ancien essaim entièrement sous GPT-5.5, le même sous Grok 4.5, puis le nouveau dispositif à deux étages, avec Opus 4.8 en planificateur et Composer 2.5 en exécutant, enfin Fable 5 en planificateur avec le même exécutant. Après quatre heures, le nouveau système marque entre 73 et 85 % sur sqllogictest, une suite de tests comportant des millions de requêtes SQL aux réponses connues, contre 11 à 77 % pour l’ancien. L’essaim, précisons-le, ignorait jusqu’à l’existence de ce banc d’essai.
Sur Grok 4.5, l’ancien essaim a produit 68 000 commits en deux heures, un volume sans commune mesure avec celui du nouveau, pour un résultat inférieur. Une architecture d’agents sait fabriquer de l’activité sans fabriquer de progrès.
L’arbitrage se déplace donc vers le haut de l’arbre. Choisir son modèle pèse moins lourd que décider à quel étage on dépense les tokens coûteux, dans la décomposition ou dans l’exécution. Ce que montre Cursor pousse à concentrer le budget sur la décision, et à traiter la production de code comme une commodité.
Une réserve s’impose. SQLite constitue un terrain idéal : sqllogictest tranche mécaniquement le juste du faux, et le compilateur Rust intercepte une part des erreurs avant même l’exécution. Beaucoup de projets métier n’ont ni juge automatique ni typage aussi sévère. Sans rien qui tranche à leur place, ces essaims produiront surtout des erreurs plus vite.
Mon avis
Le détail qui compte dans cette expérience, c’est que Cursor a dû écrire un système de contrôle de version pour tenir ses propres agents. Nos outils de développement ont été conçus pour des humains qui commitent quelques dizaines de fois par jour, et ils deviennent le facteur limitant dès qu’on branche des machines dessus. Les prochains gains de productivité se joueront dans cette plomberie : contrôle de version, mémoire partagée, relecture croisée. C’est un chantier bien moins spectaculaire qu’une sortie de modèle, et il départagera bien plus sûrement les équipes.
