Comment Cursor améliore son agent d’AI : des guardrails au contexte dynamique

Cursor a publié une étude approfondie sur le développement et l'amélioration continue de son agent d'IA pour le codage. La principale conclusion: un seul modèle de langage puissant ne suffit pas. Même les modèles les plus avancés ont besoin d'un bon "harness" — un système de prompts, d'outils, de gestion du contexte et de métriques d'évaluation. L'article ne discute pas seulement des résultats, mais de la méthodologie: comment Cursor teste les hypothèses, mesure la qualité et adapte l'architecture aux nouvelles capacités des modèles.

Évolution de la Fenêtre de Contexte

Quand Cursor développait son premier agent de codage à la fin de 2024, les modèles de langage n'étaient pas encore très bons pour choisir indépendamment ce qu'il fallait inclure dans le contexte. Alors, l'équipe a passé des mois à développer des guardrails — des restrictions et des règles strictes qui guidaient l'agent dans la bonne direction. L'ancienne approche ressemblait à ceci:

• Après chaque modification, fournissait à l'agent les erreurs du linter et les avertissements du type-checker
• Réécrivait les demandes de fichiers si l'agent demandait trop peu de lignes de code
• Limitait le nombre d'outils que l'agent pouvait appeler en un seul cycle
• Fournissait beaucoup de contexte statique — structure des dossiers, fragments de code et versions compressées des fichiers

C'était primitif, mais ça fonctionnait. Le modèle était faible et avait besoin de guidance. Mais avec la croissance rapide des capacités des modèles, Cursor a progressivement abandonné les guardrails. L'approche moderne est complètement différente: l'agent reçoit un contexte statique minimal — principalement seulement les informations du système d'exploitation, le statut git, les fichiers actuels et récemment consultés. Tout le reste, l'agent le demande dynamiquement, selon les besoins. Il recherche indépendamment les fichiers nécessaires dans la base de code, demande la documentation et analyse les erreurs en temps réel. C'est ce que signifie qu'un modèle mûrisse.

Comment la Qualité Réelle Est Mesurée

Déterminer si une amélioration fonctionne vraiment est une tâche non triviale pour un produit. Cursor utilise une approche à deux niveaux, combinant des tests synthétiques et des données réelles d'utilisateurs. Au premier niveau se trouvent les benchmarks publics (comme CursorBench), qui fournissent un aperçu rapide de la qualité et permettent des comparaisons dans le temps. Mais même les bons benchmarks ne reflètent que grossièrement l'utilisation réelle. Un agent peut réussir parfaitement un test en conditions de laboratoire mais échouer au travail réel. Donc, au deuxième niveau, Cursor exécute des tests A/B sur des utilisateurs réels, comparant plusieurs variantes du harness simultanément. C'est ici que les métriques qui importent vraiment émergent:

• Latency — avec quelle rapidité l'agent fournit la première réponse
• Token efficiency — combien de tokens ont été dépensés par demande
• Tool call count — combien de fois il a appelé des outils
• Cache hit rate — à quelle fréquence il a réutilisé le contexte en cache

Mais la métrique la plus importante est Keep Rate. C'est la proportion de code qui reste dans la base de code une semaine, un mois après l'accomplissement de la tâche. Si les utilisateurs refont fréquemment le code généré ou sont obligés de corriger manuellement les erreurs — Keep Rate diminue. Cela signale: l'agent n'a pas réussi.

Ce Que Cela Signifie

L'approche de Cursor révèle une vérité importante: la qualité d'un agent d'IA dépend non seulement du modèle, mais de l'architecture autour de lui. Les guardrails rigides aident les modèles faibles, mais les gèlent. Le contexte dynamique déverrouille le potentiel des meilleurs modèles, leur permettant d'explorer indépendamment le problème. La conclusion principale: ne attendez pas le modèle parfait. Consacrez du temps à l'architecture du harness et à la capacité de tester rapidement les hypothèses. Parce que la qualité de l'agent n'est pas déterminée par la vitesse de réponse ou le volume de tokens — elle est déterminée par le fait que la sortie de son travail reste dans le code au fil du temps.