Cursor a reconstruit SQLite avec un essaim d’agents, et les modèles bon marché ont fait l’essentiel
Avec pour seule ressource le manuel de 835 pages, le nouvel essaim d’agents de Cursor a écrit un clone fonctionnel de SQLite en Rust. Répartir le travail entre un planificateur coûteux et des exécutants bon marché a fait passer la facture de 10 565 à 1 339 dollars à qualité égale.
Cursor a soumis son essaim d’agents à un test particulièrement pur : reconstruire SQLite, le moteur de base de données présent dans presque tous les téléphones et navigateurs, en Rust, avec pour seule ressource le manuel de 835 pages. Aucun code source, aucune suite de tests existante, aucun accès à Internet. L’évaluation utilisait sqllogictest, des millions de requêtes SQL aux réponses connues dont les agents ignoraient l’existence. Toutes les configurations du nouveau système ont fini par obtenir 100 %.
Le changement est simple. Les agents ont deux rôles. Les planificateurs, animés par de coûteux modèles de pointe, décomposent l’objectif en tâches toujours plus petites. Les exécutants, sur des modèles plus rapides et moins chers, les réalisent. Les premiers n’écrivent jamais de code, les seconds ne planifient jamais. Cursor présente cela comme la correction d’un problème de contexte : un agent unique doit garder en tête l’objectif global et la sous-tâche actuelle, raison pour laquelle les longues exécutions dérivent. Les résultats sont déséquilibrés. L’ancien essaim a produit 68 000 commits en deux heures, environ soixante-dix fois plus que le nouveau, en grande partie inutiles : plus de 70 000 conflits de fusion contre moins de 1 000. L’ancien système exigeait 64 305 lignes de moteur, le nouveau 9 908.
Le coût rend l’expérience intéressante au-delà des agents de programmation. Exécuter tout le travail sur GPT-5.5 a coûté 10 565 dollars. Le partager entre Opus 4.8 comme planificateur et Composer 2.5 de Cursor comme exécutant a coûté 1 339 dollars, pour des résultats comparables ou meilleurs. Les exécutants ont consommé au moins 69 % des tokens à chaque fois, souvent bien davantage, mais leurs modèles bon marché n’étaient pas la source principale de la facture. Dans l’hybride Opus, le planificateur produisait peu de tokens mais deux tiers du coût. Conclusion de Cursor : seuls quelques moments d’une grande tâche nécessitent une intelligence de pointe, surtout la décomposition et les décisions de conception. Une fois l’ambiguïté levée, des modèles moins chers suivent le plan. Réserve légitime : la qualité du planificateur restait déterminante. Fable 5 utilisait moins de tokens de planification, mais laissait ses exécutants en consommer beaucoup plus, pour un coût total supérieur.
Ce que cela signifie pour vous : Si vous débutez avec l’IA, l’idée utile n’a rien à voir avec SQLite. « Quel modèle utiliser ? » est souvent la mauvaise question ; la bonne réponse est plutôt « un modèle intelligent pour planifier, un modèle bon marché pour exécuter ». Vous pouvez le faire manuellement : demandez à un modèle coûteux un plan clair, puis confiez chaque étape à un moins cher. Si vous construisez professionnellement des agents, Cursor a publié le code d’une exécution sous le nom minisqlite sur GitHub ; la séparation planificateur-exécutant est la partie à reprendre. Gardez toutefois les pieds sur terre : une étude de 2025 a révélé que 68 % des agents réellement déployés en entreprise n’accomplissent pas plus de dix étapes avant l’intervention d’un humain. Les essaims de laboratoire et les agents en production restent très différents.
Sources
Les robots manquent de données d’entraînement, alors une start-up enregistre des ondes cérébrales
Dans un entrepôt de San Leandro, Encord paie des personnes pour jouer au Jenga avec des casques qui suivent leurs yeux et leur activité cérébrale. Le pari : le goulet d’étranglement de l’IA robotique n’est pas la conception des modèles, mais des données qu’il faut fabriquer plutôt qu’aspirer.
