Dans le prolongement de notre article initial sur les problèmes, voici d’autres problèmes qui nous semblent parmi les plus importants pour la prochaine phase de la programmation avec l’IA.

#Prédiction de la prochaine action

Cursor inclut Copilot++, une version plus intelligente de Copilot qui prédit votre prochaine modification. Pouvons-nous pousser cette idée jusqu’à sa limite naturelle ?

Quand vous codez, vous ne faites pas que des modifications à faible entropie. Dans tout l’éditeur, vous effectuez des frappes, des clics, des actions à faible entropie. Pouvons-nous construire un modèle capable de toutes les prédire avec une faible latence ?

Pour commencer, nous avons étendu Copilot++ pour prédire votre prochain emplacement. Combiné avec la prédiction de la prochaine modification, le modèle peut dérouler une séquence de changements à faible entropie :

Nous travaillons sur la prédiction du prochain fichier vers lequel vous allez vous déplacer. De la prochaine commande de terminal que vous allez exécuter. De la prochaine modification, en fonction de vos commandes de terminal précédentes ! Un modèle de prédiction de la prochaine action.

De plus, le modèle doit faire apparaître l’information au moment exact où vous en avez besoin, qu’il s’agisse du bon extrait de code ou de la bonne documentation.

Cursor doit donner l’impression d’être une extension de votre volonté. Au moment où vous imaginez un changement, le modèle de langage ne devrait nécessiter qu’un minimum d’intention pour l’exécuter instantanément.

#Pistes prometteuses

• Recherche fondamentale sur la prédiction d’actions à l’échelle d’une base de code.

• Poursuite du pré-entraînement et du post-entraînement sur des modèles de code d’environ 5–13B de paramètres actifs (pour des prédictions à faible latence limitées par le préremplissage).

• Techniques d’inférence supplémentaires similaires à Speculative Edits

UX astucieuse pour mettre en avant des « actions » de manière non intrusive. (Comment proposer le prochain fichier vers lequel l’utilisateur devrait se rendre ? Ou le prochain emplacement en dehors de la zone actuellement visible à l’écran ?)

#Modifications parfaites

Pouvons-nous augmenter les ressources de calcul pendant l’inférence pour produire des modifications plus importantes et de meilleure qualité ? Comment compenser la latence accrue ?

Il peut être nécessaire d’effectuer la modification en arrière-plan, en lançant une unité de travail que vous pouvez confier à des modèles intelligents.

Nous aurons besoin de modèles avec de fortes capacités d’utilisation d’outils spécifiques à l’édition, d’une compréhension plus intelligente du contexte à l’échelle de la base de code, et d’un raisonnement à long terme amélioré.

Et comment pouvons-nous faire en sorte que la génération de code asynchrone préserve le flux ? Cela peut sembler paradoxal, mais nous pensons que des recherches astucieuses sur les capacités des modèles et l’UX pourraient rendre cela possible.

#Pseudocode halluciné

Les utilisateurs écrivent du pseudocode décrivant la modification souhaitée. Nous pouvons ensuite faire confiance à Cursor pour transformer ce pseudocode en modification complète, en arrière-plan.

#Modifications sur plusieurs fichiers

Cmd-k est déjà fantastique, mais et si vous pouviez demander une modification globale sur l’ensemble de votre codebase ? En particulier, une modification qui s’applique correctement à plusieurs fichiers ?

#Pistes prometteuses

• Augmenter les ressources de calcul utilisées au moment de l’inférence. Nous savons que les modèles de récompense et l’échantillonnage par rejet apporteront des améliorations rapides et simples, mais jusqu’où pouvons-nous aller ?

• Meilleurs modèles de raisonnement (GPT-5, Claude 4, Gemini 2.0)

• Exécuter plusieurs instances de language-server / système de fichiers pour un espace de travail utilisateur donné. Cela nécessitera l’utilisation d’outils par les modèles et la reproduction à distance des environnements d’exécution.

• Entraîner / améliorer les performances des modèles sur les trajectoires d’agents

• Expérimentation UX poussée pour des modifications asynchrones réalisées dans le flux de travail

#Contexte optimal

Il peut y avoir des millions de tokens de documentation, des dizaines de millions de tokens de code source, encore des dizaines de millions de tokens d’historique de commits, tous potentiellement utiles pour résoudre une seule requête.

Sans parler des pixels dans votre interface, des logs en production et en local, des messages dans Slack, etc.

Nous pensons que les meilleurs systèmes de développement utiliseront un mélange de recherche, de récurrence et d’attention à long contexte pour ingérer toutes ces informations.

Nous insistons sur le terme systèmes car, à court terme, cela peut être un ensemble de modèles et d’infrastructures qui forment un moteur de contexte infini pour le code. À long terme, nous nous attendons à ce que ce soit directement intégré dans l’architecture.

Nous sommes particulièrement enthousiastes lorsque nous réfléchissons de manière créative à l’avenir de la recherche. Au-delà des embeddings, quelles sont les meilleures performances possibles étant donné le primitif d’une étape d’indexation coûteuse et d’une étape de requête peu coûteuse (sous-linéaire par rapport à la taille du corpus) ?

Peut-être que cela ressemble à une variante de la mémoire de transformer comme index de recherche différentiable. Ou à quelque chose de complètement différent. C’est une piste de recherche encore peu explorée.

#Contexte multi-hop

Dans ma base de code, je veux calculer un diff entre deux chaînes de caractères. Avec des embeddings, j'obtiens le segment :

function computeDiff(
  firstModel: ITextModel,
  secondModel: ITextModel,
): string {
  //...
}

Pour répondre à la question initiale, je dois déterminer comment créer un ITextModel à partir d'une chaîne de caractères. C'est une question qui nécessite deux étapes pour être résolue.

Les questions et requêtes les plus difficiles dans une base de code requièrent plusieurs étapes. Une recherche basique ne fonctionne que pour une seule étape.

#Pistes prometteuses

• Embeddings et rerankers spécialisés/améliorés pour les bases de code.

• Entraîner des embedders multi-hop : étant donnée une requête et le code pertinent que nous avons trouvé jusqu’ici, déterminer le prochain bloc de code vers lequel effectuer le saut.

• Mécanismes astucieux de mise en cache des préfixes et, éventuellement, masques d’attention personnalisés mieux adaptés aux bases de code.

• Travaux de recherche novateurs sur la recherche à l’échelle d’une base de code.

• Apprendre à un modèle à intégrer une base de code directement dans ses poids, de manière similaire aux transformers utilisés comme index de recherche.

#Détection de bugs et débogage

Les systèmes actuels de détection de bugs peinent à être correctement calibrés et à suffisamment comprendre la base de code.

Les modèles sont assez intelligents pour identifier correctement des bugs, mais sont handicapés par de nombreux faux positifs. Identifier les bugs les plus subtils nécessite une compréhension plus profonde de la base de code. Et un code qui semble bogué peut s’avérer bénin lorsqu’on le replace dans une vue d’ensemble.

Concrètement, cela pourrait se traduire par une bien meilleure expérience de revue de code à l’aide de modèles de langage :

#Détection de bugs dans la revue par IA

L’avantage de la « revue par IA » est que l’utilisateur est plus tolérant face aux faux positifs, puisqu’il demande explicitement une revue. L’inconvénient, c’est que cela suppose un changement de comportement de l’utilisateur.

#Linting par IA

La meilleure façon de détecter les bugs est d’avoir un linter toujours actif qui les détecte en tâche de fond. Il doit utiliser un modèle plus économique et plus rapide que la revue par IA, car nous l’exécuterions plusieurs fois par minute. Il doit également être calibré pour avoir un taux de faux positifs plus faible.

#Un débogage plus intelligent

Plus impressionnant encore que la détection de bugs : le débogage des problèmes difficiles.

Nous devrons aller au-delà de l’analyse statique basée sur des LLM. Par exemple, nous avons créé un package cursor/debug. Lorsqu’il est injecté dans votre code, il enregistre des informations d’exécution.

En tâche de fond, nous pouvons même l’utiliser pour suivre des états supplémentaires de variables (comme pour un débogage par affichage, avec les sorties pertinentes injectées dans le contexte de Cursor).

#Pistes prometteuses

• Curation intelligente de jeux de données (probablement des données synthétiques) et RL sur des modèles de code de pointe pour améliorer la calibration.

• Suivre les informations pertinentes provenant d’autres interfaces (le navigateur ou un terminal non intégré).

• Améliorer les performances des modèles de pointe sur l’utilisation d’outils spécifiques au débogueur et les enchaînements associés.

• Contexte infini et compréhension quasi parfaite de la base de code.

• Étendre la portée de notre bibliothèque cursor/debug pour suivre toutes les informations utiles sur l’état du programme.

Si l’un de ces sujets vous intéresse, contactez-nous à l’adresse hiring@cursor.com.