Comment fonctionne Cursor, l’IDE IA

• Comprendre le fonctionnement interne d’outils de code IA comme Cursor, Windsurf et Copilot permet d’améliorer la productivité et d’obtenir des performances plus cohérentes dans des bases de code complexes
• Beaucoup de personnes ne comprennent pas les limites d’un IDE IA et le traitent comme un outil traditionnel, puis rencontrent des problèmes de performance
• Cet article explique le fonctionnement interne de Cursor, son prompt système, ainsi que les méthodes d’optimisation pour le code et les règles Cursor

Du LLM à l’agent de code

Grands modèles de langage (LLM)

• Un LLM fonctionne fondamentalement en prédisant le mot suivant
• Lorsqu’on lui fournit un prompt, le LLM génère une réponse sous forme d’autocomplétion
  • Les premiers LLM basés sur un décodeur (par ex. GPT-2) nécessitaient la rédaction de prompts spécifiques pour obtenir le résultat souhaité
  • Le prompt engineering est une technique qui consiste à « tromper » le modèle pour l’amener à produire la réponse voulue
• L’introduction de l’instruction tuning a amélioré la facilité d’utilisation
  • Des commandes comme « Rédige une PR qui refactorise la méthode Foo » peuvent être exécutées directement
  • En réalité, il s’agit d’une version étendue du processus d’autocomplétion
• L’appel d’outils (tool calling) a ensuite été ajouté
  • Le modèle peut alors effectuer des actions comme lire des fichiers, en écrire ou exécuter des commandes
  • Exemple : read_file('index.py') → le client fournit le contenu du fichier → le modèle poursuit la tâche

Code orienté agent

Les IDE IA comme Cursor sont construits avec une structure de wrapper complexe :

• Fork de VSCode → point de départ sur une base open source
• Ajout d’une interface de chat et sélection d’un LLM adapté (par ex. Sonnet 3.7)
• Implémentation d’outils pour l’agent de code
  • read_file(full_path: str)
  • write_file(full_path: str, content: str)
  • run_command(command: str)
• Optimisation des prompts
  • Ajout d’instructions comme « tu es un codeur expert » ou « n’essaie pas de deviner, utilise les outils »
    → Le simple fait d’implémenter ces étapes permet déjà au système de fonctionner, mais peut provoquer des erreurs de syntaxe, des hallucinations et un manque de cohérence

Stratégies d’optimisation et conseils pour le code orienté agent

• Pour créer un bon IDE IA, il faut comprendre les tâches que le LLM exécute bien et concevoir soigneusement les prompts et les outils en fonction de ses limites.
  • Il est efficace de simplifier les tâches principales et d’utiliser de plus petits modèles pour les sous-tâches
  • Distribuer les tâches complexes permet d’améliorer les performances et la cohérence

• Ajout du contexte utilisateur (usage de @file)

  • L’utilisateur sait souvent déjà quels fichiers ou quel contexte sont pertinents
  • Ajout de la syntaxe @file → inclusion du contenu d’un fichier ou d’un dossier entier pour fournir du contexte
  • Conseil : l’usage actif de @folder/@file est fortement recommandé → un contexte clair améliore la vitesse de réponse et la précision

• Optimisation de la recherche dans le code

  • La recherche dans le code peut être complexe, en particulier la recherche sémantique (par ex. « où se trouve le code d’authentification »)
  • Indexer la base de code dans un Vectorstore → lors de la recherche, le LLM filtre et rerange automatiquement les résultats
  • Conseil : les commentaires de code et la documentation sont importants → ils améliorent les performances du modèle d’embedding
    • Ajouter en haut des fichiers une description de leur objectif, de leur signification et du moment où ils doivent être modifiés

• Optimisation de l’écriture des fichiers

  • Écrire du code parfait est difficile et coûteux
  • Au lieu de réécrire le fichier entier, générer un Semantic Diff → seuls les fragments modifiés sont fournis
  • Un modèle d’application distinct écrit ensuite réellement le fichier à partir de ce diff sémantique → correction des erreurs de syntaxe
  • Conseil : on ne peut pas envoyer directement des instructions de prompt au modèle d’application → fournir le fichier complet renforce le contrôle
  • Conseil : le modèle d’application peut devenir lent et sujet aux erreurs lors de l’édition de gros fichiers → garder les fichiers sous 500 LoC
  • Conseil : le retour du linter est un signal extrêmement important → l’adoption d’un linter solide est indispensable
    • On peut aussi exploiter les retours fournis par la compilation et les langages typés
  • Conseil : utiliser des noms de fichiers uniques → préférer foo-page.js, bar-page.js, etc. à page.js
    • Fournir le chemin complet du fichier dans la documentation → suppression de l’ambiguïté pour l’outil d’édition

• Utiliser des modèles spécialisés pour les agents

  • Il est recommandé d’utiliser des modèles spécialisés pour les agents plutôt que des modèles génériques d’écriture de code
  • C’est l’une des raisons pour lesquelles les modèles d’Anthropic obtiennent d’excellents résultats dans des IDE comme Cursor
  • Conseil : ne choisissez pas seulement un modèle bon pour écrire du code, mais un modèle optimisé pour un IDE orienté agent
    • Les performances des modèles peuvent être consultées dans le classement WebDev Arena

• Utiliser des outils d’auto-correction (stratégie avancée)

  • apply_and_check_tool → exécution d’un linter coûteux + collecte des logs console et de captures d’écran dans un navigateur headless
  • MCP(Model Context Protocol) → renforce l’autonomie de l’agent et la fourniture de contexte

Analyse détaillée du prompt système de Cursor

• Le prompt le plus récent de Cursor (mars 2025) a été extrait à l’aide d’une technique d’injection de prompt basée sur MCP
  • Les prompt engineers de Cursor ont des compétences remarquables en rédaction de prompts, même comparés à ceux d’autres IDE IA.
  • L’analyse de la structure du prompt peut aider à améliorer les performances de génération de code et la conception de l’architecture agentique

• Principaux éléments du prompt et leur signification

  • Usage de balises comme "<communication>", "<tool_calling>"
    • Mélange de Markdown et de balises XML → lisible pour l’humain et facile à traiter pour le LLM
  • "powered by Claude 3.5 Sonnet"
    • Renforce la cohérence du modèle → évite que le LLM donne de fausses informations sur le modèle en cours d’exécution
  • "the world's best IDE"
    • Empêche le LLM de recommander d’autres produits lorsqu’une erreur survient
  • "we may automatically attach some information…follow the USER's instructions…by the <user_query> tag."
    • Le prompt utilisateur n’est pas transmis directement, mais encapsulé dans une balise spéciale pour éviter les confusions
  • "Refrain from apologizing"
    • Évite les excuses inutiles (pour compenser une tendance du modèle Sonnet)
  • "NEVER refer to tool names when speaking"
    • Ajoute l’instruction de ne pas mentionner les noms des outils → mais le modèle l’ignore parfois en pratique
  • "Before calling each tool, first explain"
    • Exiger une explication d’état avant chaque appel d’outil → amélioration de l’expérience utilisateur
  • "partially satiate the USER's query, but you're not confident, gather more information"
    • Évite les réponses prématurées dues à un excès de confiance → pousse à chercher plus d’informations
  • "NEVER output code to the USER"
    • Interdit de produire directement du code → la génération de code n’est autorisée qu’au travers des outils
  • "If you're building a web app from scratch, give it a beautiful and modern UI"
    • Oriente le modèle vers la création d’une web app attrayante à partir d’un simple prompt (dans un but de démo)
  • "you MUST read the the contents or section of what you're editing before editing it"
    • Oblige à lire le contexte avant modification → meilleur respect du contexte
  • "DO NOT loop more than 3 times on fixing linter errors"
    • Limite le nombre de boucles de correction → évite les boucles infinies
  • "Address the root cause instead of the symptoms."
    • Encourage à corriger la cause racine plutôt que les symptômes du problème
  • "DO NOT hardcode an API key"
    • Instruction de sécurité → évite le hardcoding
  • "codebase_search", "read_file", "grep_search", "file_search", "web_search"
    • Divers outils de recherche fournis pour obtenir le bon contexte avant d’écrire du code
  • Exigence d’une "One sentence explanation…why this command needs to be run…"
    • Renforce la logique lors du traitement des arguments d’outil → application d’une technique d’amélioration de prompt
  • L’outil "reapply" est décrit comme "Calls a smarter model to apply the last edit"
    • Réapplique la dernière modification avec un modèle plus avancé → meilleure qualité des corrections
  • L’outil "edit_file" est décrit comme "represent all unchanged code using the comment of the language you're editing"
    • Le code non modifié est représenté sous forme de commentaires → améliore la précision du modèle d’édition
• Utilisation du prompt caching
  • Le prompt système et les descriptions d’outils restent dans un état statique
  • Il n’existe pas de personnalisation selon la base de code ou l’utilisateur → le prompt caching permet d’améliorer les coûts et la vitesse de traitement

Comment rédiger et utiliser efficacement les règles Cursor

• Il n’existe pas de réponse unique à la rédaction des règles Cursor selon le contexte, mais quelques conseils utiles peuvent être donnés à partir de l’expérience en prompt writing et de la compréhension de la structure interne de Cursor
• Il est important d’écrire les règles non comme de simples instructions, mais comme des guides de type encyclopédique.

• Concepts clés pour la rédaction des règles

  • Le LLM appelle fetch_rules(…) en se basant sur le nom et la description de la liste de règles
  • Les règles ne sont pas ajoutées au prompt système ; elles sont consultées uniquement lorsque nécessaire
  • Une description de style encyclopédique est donc plus efficace qu’un simple impératif

• Ce qu’il faut éviter lors de la rédaction des règles

  • Ne pas définir une identité
    • Éviter des descriptions comme "tu es un expert TypeScript"
    • Le LLM dispose déjà d’une identité dans son prompt intégré → risque de conflit
  • Ne pas essayer d’écraser le prompt système
    • Des injonctions comme "n’ajoute pas de commentaires" ou "pose une question avant d’écrire du code" → peuvent perturber l’usage des outils internes
  • Éviter les instructions négatives
    • Des formulations positives comme "fais ceci" sont plus efficaces pour le LLM que "ne fais pas cela"
    • Exemple d’instruction positive : "Lors de la modification d’un fichier, vérifie tout le contexte avant d’éditer"

• Recommandations pour la rédaction des règles

  • Rédiger des noms et descriptions de règles clairs et intuitifs
    • Les règles doivent pouvoir être appliquées à partir d’un minimum d’informations sur la base de code
    • Il est possible de rédiger des règles redondantes → améliore la précision de la recherche
  • Rédiger les règles dans un style encyclopédique
    • Fournir une explication du contexte et de l’objectif plutôt que des ordres trop précis
    • Si nécessaire, on peut lier des fichiers de code pour renforcer le contexte
  • Utiliser Cursor pour rédiger un premier brouillon des règles
    • Les LLM sont efficaces pour écrire du contexte destiné à d’autres LLM
    • Exemple : "@folder/ crée un fichier Markdown décrivant les chemins de code souvent modifiés et leurs définitions"
  • Éviter de rédiger trop de règles
    • Trop de règles est inefficace et peut indiquer une base de code peu intuitive
    • Une base de code idéale doit permettre à l’agent de travailler avec un minimum de règles

• Exemples de règles efficaces

  • ✅ Commandes de règle :
    • "Lire tout le contexte avant de modifier un fichier"
    • "Lors de la modification du code serveur, vérifier la logique du code d’authentification"
    • "En cas d’erreur, corriger d’abord la cause"
  • ❌ Commandes de règle (à éviter) :
    • "Ne supprime pas les commentaires"
    • "Pose-moi une question avant de modifier"
    • "Ne modifie pas du code inutilement"

• Stratégie essentielle pour la rédaction des règles

  • Les règles doivent être formulées non comme des ordres, mais comme une description de situation
  • Utiliser des noms et descriptions intuitifs → obtenir un maximum de performance avec un minimum de règles
  • Renforcer l’explication du contexte et les liens avec le code plutôt que de multiplier les injonctions précises

Conclusion

• Il est remarquable que Cursor, parti d’un fork de VSCode et reposant sur des prompts open source et des API de modèles publics, ait atteint une valorisation proche de 10 milliards de dollars (environ 13 000 milliards de wons)
  • Cursor est actuellement valorisé à 6x selon le critère du wrapper multiple
• Cursor offre de fortes performances grâce à des prompts optimisés et à un système puissant d’appel d’outils
• Il est peu probable que Cursor développe son propre modèle agentique
  • En revanche, Anthropic a de fortes chances de lancer un produit concurrent basé sur Claude Code et Sonnet

• Points clés

  • Bien configurer la base de code, la documentation et les règles restera une compétence importante
  • Comprendre les stratégies d’optimisation des outils de code IA permet d’améliorer la productivité et la précision
  • Si Cursor ne fonctionne pas correctement, le problème vient probablement de la manière dont il est utilisé

"Si Cursor ne fonctionne pas, il faut revoir sa manière de l’utiliser."

[bluekai17]

Je vais devoir l’essayer.

[ohyecloudy]

Rédiger un brouillon de règles avec Cursor
Les LLM sont doués pour rédiger du contexte pour d'autres LLM

Intéressant. C'est peut-être parce qu'ils boivent la même eau, après tout ?

[linker]

Il y a beaucoup de perspicacité là-dedans. Merci.

[nicewook]

• Analyse détaillée du prompt système de Cursor : c’est impressionnant.
• L’idée qu’Anthropic puisse lancer un IDE IA me donne déjà hâte.