Cursor a remis en question les benchmarks publics d’AI pour le code avec cinq graphiques

Le 11 mars 2026, Cursor a publié une explication de la façon dont il compare les modèles dans son produit et a inopinément porté un coup à toute l'industrie des benchmarks d'IA pour le code. Au lieu d'un énième tableau des leaders, l'entreprise a montré pourquoi les pourcentages familiers de tâches résolues décrivent de plus en plus mal la valeur réelle pour les développeurs.

Pourquoi les Graphiques Importent

La première conclusion de Cursor est très pratique : un modèle de programmation ne peut pas être évalué uniquement par la proportion de tâches résolues. L'entreprise a montré un graphique où deux métriques se tenaient côte à côte—la correctness de la réponse et le nombre médian de tokens pour compléter. Pour l'utilisateur, ce n'est pas une abstraction. Les tokens se transforment en latence, coût et sensation du travail. Si un modèle résout légèrement plus de tâches mais dépense plusieurs fois plus de tokens, il peut perdre en tant que produit. Les benchmarks publics cachent généralement ce compromis et ne laissent qu'un joli pourcentage dans le tableau.

Le deuxième coup a porté sur l'idée même d'un test « stable ». CursorBench est compilé à partir de vraies sessions via le système Cursor Blame, qui lie le code commité aux requêtes d'agents. Selon Cursor, de la première version à CursorBench-3, l'étendue des tâches a approximativement doublé en volume de code et en nombre moyen de fichiers. Cela signifie que les développeurs demandent déjà à l'IA non seulement de corriger des petits bugs, mais de traiter des tâches plus longues dispersées dans le projet. Sur ce fond, les ensembles figés comme SWE-bench vieillissent de plus en plus vite, même si leurs résultats sont formellement reproductibles.

Cinq Points Faibles

Si vous regroupez les conclusions des cinq graphiques dans un cadre, le résultat n'est pas une publicité pour un benchmark interne, mais une critique de tout le système actuel d'évaluation des modèles de code. Cursor dit effectivement : l'industrie s'est habituée à mesurer ce qui est commode de compter, pas ce que les développeurs ressentent vraiment dans l'éditeur, le terminal et la longue session de travail.

• Un classement par métrique unique cache les compromis entre la qualité, la vitesse et le coût de la réponse.
• Un ensemble figé de tâches devient obsolète tandis que les vraies requêtes aux agents deviennent plus longues et plus complexes.
• Les issues longues avec des patches courts testent le suivi des instructions, pas la compréhension d'une intention vague.
• Les résultats convergents parmi les meilleurs modèles n'aident pas à choisir un outil pour la production.
• Les scores hors ligne signifient peu s'ils ne correspondent pas à la façon dont le modèle se comporte dans un vrai produit.

Comment Fonctionne CursorBench

L'approche de Cursor diffère non seulement dans l'ensemble des tâches, mais dans ce qui compte comme une bonne évaluation. Dans les benchmarks publics, un développeur reçoit souvent une longue description d'un bug et fait un correctif court et précis. Dans CursorBench, le tableau est inversé : les descriptions sont plus courtes, mais les solutions sont plus longues. C'est plus proche du vrai travail, quand une personne écrit quelque chose comme « corrige la connexion » ou « refactorise le pipeline » à un agent, et ensuite le modèle doit comprendre le contexte du référentiel, choisir une stratégie et apporter des changements significatifs dans plusieurs fichiers. Cela teste donc non seulement la précision, mais aussi la capacité à développer l'intention.

Cela mène à un autre effet important : CursorBench sépare mieux les résultats des modèles en frontière. Là où les tests publics commencent à montrer des scores presque identiques et placent même des modèles plus faibles aux côtés de plus forts, l'ensemble interne de Cursor préserve les différences qui correspondent à l'expérience utilisateur. L'entreprise complète l'évaluation hors ligne par des expériences en ligne contrôlées sur le trafic réel et regarde non pas un seul nombre, mais un ensemble de signaux—la qualité du résultat, le comportement de l'agent et l'utilité pour le développeur. Si un évaluateur hors ligne considère une réponse comme correcte, mais que l'utilisateur trouve plus difficile de travailler avec, une telle dégradation émerge quand même.

Ce que Cela Signifie

L'histoire importe non seulement pour les utilisateurs de Cursor. Elle montre que le marché des agents de code est entré dans une phase où les tableaux de leaders synthétiques ne sont plus un guide fiable, surtout pour choisir entre les meilleurs modèles. La prochaine vague de concurrence ne sera pas pour le score de benchmark le plus bruyant, mais pour l'équilibre entre la qualité, la vitesse, le coût et la confiance avec laquelle l'agent gère des tâches d'ingénierie réelles, imparfaitement formulées.