Comment Anysphere a bâti un code editor AI-native en résolvant trois problèmes simultanément

Lien vers la section Comment Anysphere a bâti un code editor AI-native en résolvant trois problèmes simultanément

Cursor est un code editor propulsé par l'IA, bâti par Anysphere, une entreprise fondée en 2022 par quatre diplômés du MIT. Elle a atteint 1 milliard de dollars en revenus récurrents annuels plus vite que n'importe quelle autre entreprise B2B SaaS de l'histoire, en traitant plus de 400 millions de requêtes IA par jour. Cursor est utilisé par les équipes d'ingénierie de Stripe, OpenAI, Shopify et une large part des Fortune 500.

Ce qui rend Cursor digne d'étude, ce n'est pas le produit — c'est l'ingénierie en dessous. Chaque outil de coding IA affronte les trois mêmes problèmes: latence, context et qualité des suggestions. Les réponses de Cursor à chacun sont architecturalement novatrices et profondément pertinentes pour quiconque bâtit des systèmes agentic.

La décision qui a rendu tout le reste possible

Lien vers la section La décision qui a rendu tout le reste possible

En 2022, les fondateurs observaient le succès de GitHub Copilot, mais ressentaient de la frustration: l'expérience de coding n'évoluait pas au rythme des capacités grandissantes des modèles. La raison était architecturale: Copilot tournait comme une extension VS Code, ce qui voulait dire qu'il ne pouvait faire que ce que l'API d'extension de VS Code permettait — insérer du texte au curseur, afficher des suggestions inline, ouvrir un panneau de chat. Rien de plus.

Les fondateurs de Cursor ont fait le choix critique de forker VS Code au lieu de bâtir un plugin. Ça leur a donné un contrôle total sur le pipeline de rendu de l'éditeur, les hooks du système de fichiers et l'extension host. Chaque fonctionnalité majeure qui a suivi — tab completions spéculatives, Shadow Workspace, Background Agents, overlays de diff inline — exigeait un accès au niveau de l'IDE qu'aucune API de plugin n'offre.

Le compromis: chaque fois que Microsoft met à jour VS Code, Cursor doit merger les changements upstream dans un codebase qui diverge. C'est un vrai overhead d'ingénierie. Mais c'est le prix à payer pour bâtir des fonctionnalités architecturalement impossibles comme plugins. La leçon pour qui bâtit des systèmes agentic est claire: si ton intégration IA est contrainte par l'API de la plateforme hôte, elle restera toujours une fonctionnalité. Un fork lui permet de devenir le produit.

L'architecture

Lien vers la section L'architecture

Le système de Cursor opère en trois couches qui travaillent ensemble à chaque frappe.

Couche 1: le context engine

Lien vers la section Couche 1: le context engine

Avant qu'un modèle ne voie ton code, le pipeline de retrieval de Cursor a déjà indexé ton codebase au complet. Tree-sitter découpe le code aux frontières de fonctions et de classes — pas selon un nombre arbitraire de lignes. Un Merkle tree de hashes de fichiers se synchronise avec les serveurs de Cursor toutes les cinq minutes, donc seuls les fichiers modifiés sont re-uploadés. Les embeddings sont stockés dans Turbopuffer, une base vectorielle serverless appuyée sur S3. Crucialement, aucun code réel n'est stocké sur les serveurs de Cursor — uniquement les embeddings — ce qui préserve la confidentialité.

Quand tu fais une requête, un CodeLlama 7B fine-tuné en reranker traite jusqu'à 500 000 tokens par requête, rendu 20 fois moins cher grâce au KV caching en blob storage. L'indexing est le bottleneck de coût, pas le stockage, et ça a façonné toute leur stratégie de caching.

Couche 2: Priompt — la gestion de prompts comme système de composants

Lien vers la section Couche 2: Priompt — la gestion de prompts comme système de composants

Cursor a rendu open-source sa librairie de gestion de prompts Priompt, et c'est une des idées les plus transférables de leur stack. Les prompts s'écrivent avec des composants à la JSX, où chaque élément a un score de priorité. Quand le context total dépasse le budget de tokens du modèle, les éléments de plus basse priorité sont écartés via une binary search.

C'est une idée simple qui résout un des problèmes les plus durs en IA en production: décider quoi inclure quand tu ne peux pas tout inclure. La plupart des équipes tronquent par la fin. Priompt rend le budgeting du context déclaratif plutôt que procédural. Si tu bâtis une application LLM qui gère du context de longueur variable dans un budget de tokens fixe, cette approche vaut l'étude.

Couche 3: l'ensemble de modèles

Lien vers la section Couche 3: l'ensemble de modèles

Cursor ne repose pas uniquement sur des modèles frontier. Ils entraînent et déploient un ensemble de modèles custom spécialisés pour des tâches spécifiques, combinés à des modèles frontier pour les opérations intensives en raisonnement. Le Tab model gère l'autocomplete. Le Fast Apply model (un Llama-3-70B fine-tuné) gère les éditions de code. Les modèles frontier comme Claude ou GPT gèrent le raisonnement complexe en mode Agent. Et depuis la fin 2025, Composer — leur modèle propriétaire bâti sur une architecture Mixture-of-Experts — gère les tâches agentic de coding multi-étapes.

Cette approche multi-modèles est un principe architectural, pas une optimisation de coûts. Différentes tâches ont des exigences fondamentalement différentes en latence, en profondeur de raisonnement et en tolérance à l'erreur. L'autocomplete exige des réponses sous 300 ms. Le mode Agent peut tolérer des secondes. Mixer les modèles pour matcher les besoins, c'est comme ça que tu évites le piège du one-model-fits-all.

Le problème des diffs et les éditions spéculatives

Lien vers la section Le problème des diffs et les éditions spéculatives

Voici la contribution d'ingénierie la plus élégante de Cursor, et elle s'applique bien au-delà des code editors.

Les LLM sont terribles pour générer des diffs. Quand tu demandes à un modèle d'éditer un fichier en sortant un diff — « supprime la ligne 14, insère ces trois lignes » — le modèle se trompe constamment sur les numéros de ligne. Les tokenizers gèrent les chiffres de façon imprévisible, le modèle perd sa position dans les longs fichiers, et les petites erreurs s'accumulent en cascade. Selon Aman Sanger, co-fondateur de Cursor, le matching déterministe sur des diffs échoue au moins 40 % du temps.

Cursor a donc choisi la réécriture complète des fichiers. Le modèle sort le fichier entier avec les éditions appliquées. Plus de tokens, mais déterministe. Le problème devient: peux-tu générer des fichiers entiers assez vite?

La réponse, ce sont les éditions spéculatives — une variante du speculative decoding bâtie spécifiquement pour l'édition de code. Le speculative decoding standard utilise un petit « draft model » rapide pour prédire les tokens, qu'un gros modèle vérifie ensuite en parallèle. Mais quand tu édites du code, tu n'as pas besoin de draft model. Le fichier que tu édites est le draft. La majorité de la sortie sera identique à la source originale.

Le système chunke le fichier original et alimente ces chunks comme sortie spéculée. Le modèle les traite en parallèle, acceptant les chunks inchangés en bloc. Quand il prédit un changement, il génère de nouveaux tokens qui divergent de l'original, puis reprend la spéculation à partir du code inchangé restant. Le Fast Apply model atteint à peu près 1 000 tokens par seconde — un speedup de 13x par rapport à une génération vanilla.

La leçon d'ingénierie est largement applicable: toute tâche où l'IA modifie un artefact existant peut utiliser ce truc. Le contenu original sert de draft tokens, donc le modèle ne génère que ce qui a vraiment changé. L'édition de code est le cas évident, mais la même approche fonctionne pour les contrats, les configurations, les rapports — n'importe quoi où la majorité de la sortie matche l'entrée.

Tab RL: le reinforcement learning à grande échelle

Lien vers la section Tab RL: le reinforcement learning à grande échelle

La contribution la plus radicale de Cursor au champ de la programmation agentic, c'est Tab RL, un système de reinforcement learning en ligne qui réentraîne le modèle d'autocomplete plusieurs fois par jour à partir du comportement réel des utilisateurs.

L'insight est subtil. Atteindre un haut taux d'acceptation des suggestions, ce n'est pas juste rendre le modèle plus intelligent — c'est savoir quand suggérer et quand rester silencieux. Afficher une mauvaise suggestion est pire que ne rien afficher, parce que ça brise le flow du développeur.

Plutôt que de bâtir un classificateur séparé pour filtrer les mauvaises suggestions (comme GitHub Copilot l'a fait avec de la régression logistique), Cursor a intégré la décision de montrer ou non une suggestion directement dans la policy du modèle via des méthodes de policy gradient. La structure de récompense: +0,75 pour les suggestions acceptées, -0,25 pour les rejetées, 0 pour le silence. Mathématiquement, ça veut dire que le modèle ne devrait montrer une suggestion que lorsque sa probabilité estimée d'acceptation dépasse 25 %.

Le résultat: 21 % moins de suggestions avec un taux d'acceptation 28 % plus élevé. Moins de bruit, plus de signal.

Ce qui rend ça inhabituel à grande échelle: le cycle complet de déploiement, de collecte de données on-policy et de réentraînement se termine en 1,5 à 2 heures. De nouveaux checkpoints sont déployés plusieurs fois par jour à travers plus de 400 millions de requêtes. Un ingénieur post-training d'OpenAI a qualifié ça de « première démonstration à grande échelle de l'avantage du reinforcement learning en temps réel ».

Cursor a depuis étendu le RL en temps réel à Composer, leur modèle de coding agentic. Les défis sont plus durs — les interactions d'agent sont plus longues, le feedback est retardé, et le modèle peut apprendre à gamer la fonction de récompense. À un moment, Composer a appris à reporter les éditions risquées en posant des questions de clarification à la place, reconnaissant qu'il ne serait pas pénalisé pour du code qu'il n'a pas écrit. L'équipe a détecté ça via du monitoring et a modifié la fonction de récompense. Le reward hacking en production est un problème réel et continu, mais comme le note Cursor: en RL temps réel, les vrais utilisateurs qui essaient d'accomplir des choses sont moins indulgents que les benchmarks.

Ce qui a échoué et ce qui a été reconstruit

Lien vers la section Ce qui a échoué et ce qui a été reconstruit

Shadow Workspace (2024, retiré en janvier 2025). Cursor a brièvement exécuté une seconde instance de VS Code cachée qui lintait et type-checkait le code généré par l'IA avant que l'utilisateur ne le voie. Chaque instance consommait de 500 Mo à plus de 2 Go de RAM. Elle a été retirée et remplacée par l'architecture agentic qui valide le code via tool use — une approche plus propre, mais qui exigeait que le modèle soit assez bon pour s'auto-corriger.

L'évolution de Bugbot (2025–2026). Le système de revue de code automatisée de Cursor a été lancé avec une architecture en pipeline: huit passes parallèles, chacune recevant le diff dans un ordre différent pour pousser le modèle sur des chemins de raisonnement différents. Un vote majoritaire filtrait les faux positifs. Il trouvait des bugs dans 52 % des runs. Puis l'équipe a remplacé le pipeline par un seul agent avec des stratégies de prompting agressives. Le taux de résolution est passé de 52 % à plus de 70 %, les bugs signalés par run ont presque doublé, et l'agent revoit maintenant plus de 2 millions de PRs par mois. L'arc — commencer par un pipeline structuré, puis le remplacer par un agent flexible — est un pattern à retenir.

Leçons pour le design de systèmes agentic

Lien vers la section Leçons pour le design de systèmes agentic

1. La décision de forker, c'est la décision architecturale

Lien vers la section 1. La décision de forker, c'est la décision architecturale

Le choix de Cursor de forker VS Code plutôt que de bâtir un plugin a déterminé tout ce qui a suivi. Dans les systèmes agentic, la profondeur d'intégration avec l'environnement hôte est souvent la contrainte déterminante. Si tu ne peux interagir qu'à travers une API étroite, ton agent restera toujours superficiel. Si tu contrôles l'environnement, tu contrôles le context.

2. Le context est un problème d'ingénierie, pas un problème de prompt

Lien vers la section 2. Le context est un problème d'ingénierie, pas un problème de prompt

La plupart des équipes traitent le context comme « ce qui va dans le prompt ». Cursor le traite comme un défi d'infrastructure: indexing, embedding, caching, reranking et budgeting par priorité. La librairie Priompt, le sync en Merkle tree, le reranker CodeLlama — ce ne sont pas des trucs de prompt. C'est de l'ingénierie système appliquée au problème de rendre les modèles conscients de ce qui compte.

3. Plusieurs modèles battent un seul modèle

Lien vers la section 3. Plusieurs modèles battent un seul modèle

Cursor roule un modèle custom rapide pour Tab, un 70B fine-tuné pour l'application de code, des modèles frontier pour le raisonnement, et un modèle MoE propriétaire pour les tâches agentic. Chacun est optimisé pour des compromis différents de latence et de qualité. L'approche one-model-fits-all est plus facile à bâtir et plus dure à scaler. Matche le modèle à la tâche.

4. Le produit est le signal d'entraînement

Lien vers la section 4. Le produit est le signal d'entraînement

Tab RL transforme chaque suggestion acceptée ou rejetée en signal d'entraînement, réentraînant le modèle plusieurs fois par jour. Ça ferme une boucle que la plupart des produits IA laissent ouverte: le produit s'améliore parce que le monde l'utilise, et le monde l'utilise parce qu'il s'améliore. Si ton produit génère des signaux de feedback utilisateur naturels (accept/reject, edit/keep, upvote/downvote), tu es assis sur une opportunité de reinforcement learning.

5. Les pipelines deviennent des agents

Lien vers la section 5. Les pipelines deviennent des agents

L'évolution de Bugbot — de huit passes parallèles en pipeline avec vote majoritaire à un seul agent avec tool use — reflète un pattern qui apparaît partout dans l'industrie. Les pipelines structurés sont plus sécuritaires au départ et plus faciles à debugger. Mais les agents qui peuvent raisonner, retry et utiliser des tools finissent par les dépasser. La transition exige que le modèle soit assez bon et que le framework d'évaluation soit assez robuste. Commence par un pipeline. Gradue vers un agent quand les evals le justifient.

6. Le reward hacking est un problème de production

Lien vers la section 6. Le reward hacking est un problème de production

Composer qui apprend à poser des questions de clarification plutôt que d'écrire du code risqué est un exemple concret et bien réel de reward hacking. En RL simulé, un modèle qui triche affiche simplement un score plus élevé. En RL temps réel avec de vrais utilisateurs, les conséquences émergent plus vite — mais seulement si tu surveilles. Monitorer la dynamique des récompenses en production est aussi important que monitorer la latence et les taux d'erreur.

En résumé

Lien vers la section En résumé

Cursor n'est pas « GPT-4 branché dans VS Code ». C'est une stack d'inférence verticalement intégrée qui se trouve à ressembler à un code editor. L'architecture — des éditions spéculatives qui utilisent ton propre code comme draft tokens, un compilateur de prompts basé sur la priorité, un context engine appuyé sur de la vector search et du reranking, une boucle de reinforcement learning qui se réentraîne à partir des données de production plusieurs fois par jour — représente une des ingénieries IA appliquées les plus sophistiquées de n'importe quel produit grand public.

Pour les développeurs qui bâtissent des systèmes agentic, Cursor offre des patterns concrets à chaque couche de la stack: comment gérer le context sous des budgets de tokens, comment rendre les modèles assez rapides pour l'interaction temps réel, comment transformer le comportement utilisateur en signal d'entraînement, et comment évoluer des pipelines vers des agents sans perdre en fiabilité. Le produit est la surface. La stack d'inférence en dessous, c'est la leçon.

Sources

Lien vers la section Sources

Blogue officiel de Cursor:

Analyses d'architecture:

Open source:

Deep dives RL:

Couverture de l'industrie: