Nos problèmes · Cursor

Mise à jour : nous avons écrit sur d’autres problèmes.

Une liste non ordonnée de problèmes courts et concrets :

Un meilleur contexte : Il existe de nombreuses sources d’informations dans un éditeur de code : fichiers ouverts, blocs de code sémantiquement similaires, classes reliées symboliquement, sorties de lint, traces d’exécution, historique git, historique de frappe, documentation externe, etc. Nous voulons que le modèle comprenne instantanément ce qui est le plus pertinent pour la question de l’utilisateur, et nous entraînons actuellement un modèle de reranking personnalisé et rapide pour résoudre ce problème. Pour chaque requête, nous rassemblerons 500k tokens provenant de toutes ces sources, et utiliserons notre reranker pour les filtrer jusqu’aux 8k tokens les plus pertinents. C’est à la fois un problème de modèle et, de plus en plus, un problème d’infrastructure.
Un “copilot pour les modifications” : Bien que GitHub Copilot soit extrêmement utile pour éliminer les frappes à faible entropie lors de l’écriture de nouveau code, il ne vous aide pas à économiser ces frappes à faible entropie lorsque vous devez effectuer de petits changements simples sur des blocs de code existants. Pensez à la navigation, la suppression et les frappes nécessaires pour un renommage juste un peu plus compliqué que ce qu’un renommage symbolique via F2 peut faire. Nous aurons besoin d’innovations à la fois en UX (des diffs discrets qui vous sont affichés pendant que vous codez) et côté modèle (le simple prompting ne suffit pas, en raison de problèmes de coût, de latence et de capacité).
Des agents contraints, dans le flux : Pensez au code interpreter d’OpenAI, mais pour l’ingénierie dans de grandes bases de code. Vous indiquez à un agent contraint, en quelques étapes, ce qu’il doit faire, et il recherche, écrit et exécute du code pour vous, tout en vous consultant régulièrement pour obtenir des retours. La première étape pour y parvenir, sur laquelle nous travaillons actuellement, est de créer un agent de ce type qui fonctionne sur des dossiers de quelques centaines de milliers de tokens. Si cela fonctionne, nous le ferons passer à l’échelle pour traiter des bases de code entières.
Détection de bugs : Il y a deux modes ici : (1) en arrière-plan, Cursor analysera toujours passivement vos fichiers pour trouver des bugs potentiels, et (2) lorsque vous êtes en pleine session de débogage, Cursor recherchera activement le bug avec votre aide. Il y a ici beaucoup de collecte de données intéressante à effectuer.
Modifications plus vastes : Cursor devrait être capable de modifier des fichiers entiers, et même des répertoires entiers, pour vous. C’est un défi à la fois de capacités et d’UX. Pour la vitesse, le modèle doit être suffisamment intelligent pour repérer les parties à modifier sans tout réécrire. Pour que l’expérience soit bonne, les changements doivent être affichés sous une forme exploitable, en temps réel.
Passage à l’échelle : Nous avons 1,4 milliard de vecteurs et 150 000 bases de code indexées, au 12 octobre 2023. Cela va probablement être multiplié par 10 d’ici la fin de l’année. Nous avons déjà construit un moteur de synchronisation de bases de code très rapide basé sur un arbre de Merkle en Rust, et nous devrons probablement bientôt construire un système d’indexation personnalisé.

Idées futures :

Distorsion temporelle : prédire et afficher les changements de code inter-fichiers que vous ferez dans les 15 prochaines minutes. Une commande unique pour accepter toutes les insertions/suppressions.
Compréhension : nos modèles devraient comprendre en profondeur tous les concepts de n’importe quelle base de code, dans les poids.
Mode lecteur : rendre la compréhension du code sans effort avec de la documentation à n’importe quel niveau de spécificité et un bot qui vous guide à travers les chemins de code pertinents, en expliquant au besoin.
Mode pseudo-code : éditer une représentation « outline » de votre code et faire appliquer automatiquement les changements au niveau de la source.
Ne plus jamais vous soucier des stack traces : l’IDE devrait simplement les comprendre et corriger automatiquement le code pour vous.

Nous avons essayé de rassembler tous les problèmes auxquels nous pensons en ce moment, mais — et c’est l’une des choses formidables quand on construit un produit que l’on utilise soi-même 12 heures par jour — nous avons constamment de nouvelles idées et changeons nos priorités, donc cela ne doit pas être vu comme une feuille de route définitive. Cela dit, nous espérons que cela donne une idée de la façon dont nous utilisons notre bande passante mentale au quotidien.

Aussi, vous avez lu jusqu’ici, donc il semble probable que vous ayez un certain intérêt pour les problèmes qui nous intéressent :). Si c’est le cas, vous devriez envisager de nous rejoindre ! Voici quelques autres raisons pour lesquelles nous pensons que vous adoreriez travailler avec nous :

Les gens aiment utiliser Cursor. Nous sommes très satisfaits de notre croissance initiale.
Vous travaillerez ici avec des personnes vraiment brillantes. Nous croyons profondément à une forte concentration de talents. Toutes les personnes avec qui vous travaillerez ici seront vraiment, vraiment excellentes.
Le développement assisté par l’IA est un immense marché. Et nous pouvons le conquérir.
C’est fun. C’est très important pour nous ! C’est fun de travailler avec des personnes que vous appréciez, c’est fun de créer un produit où vous appuyez sur Cmd‑Shift‑R et obtenez un retour utilisateur instantané parce que, vous-même, en programmant, êtes l’utilisateur cible, et c’est fun de progresser chaque jour un peu plus vers l’automatisation de toutes les parties ennuyeuses de la programmation.
Nous travaillons dur. Nous nous sentons privilégiés de pouvoir travailler sur ces problèmes, et nous aimons nous y investir pleinement pour les résoudre.

Mise à jour : nous avons écrit sur d’autres problèmes.

Une liste non ordonnée de problèmes courts et concrets :

Un meilleur contexte : Il existe de nombreuses sources d’informations dans un éditeur de code : fichiers ouverts, blocs de code sémantiquement similaires, classes reliées symboliquement, sorties de lint, traces d’exécution, historique git, historique de frappe, documentation externe, etc. Nous voulons que le modèle comprenne instantanément ce qui est le plus pertinent pour la question de l’utilisateur, et nous entraînons actuellement un modèle de reranking personnalisé et rapide pour résoudre ce problème. Pour chaque requête, nous rassemblerons 500k tokens provenant de toutes ces sources, et utiliserons notre reranker pour les filtrer jusqu’aux 8k tokens les plus pertinents. C’est à la fois un problème de modèle et, de plus en plus, un problème d’infrastructure.
Un “copilot pour les modifications” : Bien que GitHub Copilot soit extrêmement utile pour éliminer les frappes à faible entropie lors de l’écriture de nouveau code, il ne vous aide pas à économiser ces frappes à faible entropie lorsque vous devez effectuer de petits changements simples sur des blocs de code existants. Pensez à la navigation, la suppression et les frappes nécessaires pour un renommage juste un peu plus compliqué que ce qu’un renommage symbolique via F2 peut faire. Nous aurons besoin d’innovations à la fois en UX (des diffs discrets qui vous sont affichés pendant que vous codez) et côté modèle (le simple prompting ne suffit pas, en raison de problèmes de coût, de latence et de capacité).
Des agents contraints, dans le flux : Pensez au code interpreter d’OpenAI, mais pour l’ingénierie dans de grandes bases de code. Vous indiquez à un agent contraint, en quelques étapes, ce qu’il doit faire, et il recherche, écrit et exécute du code pour vous, tout en vous consultant régulièrement pour obtenir des retours. La première étape pour y parvenir, sur laquelle nous travaillons actuellement, est de créer un agent de ce type qui fonctionne sur des dossiers de quelques centaines de milliers de tokens. Si cela fonctionne, nous le ferons passer à l’échelle pour traiter des bases de code entières.
Détection de bugs : Il y a deux modes ici : (1) en arrière-plan, Cursor analysera toujours passivement vos fichiers pour trouver des bugs potentiels, et (2) lorsque vous êtes en pleine session de débogage, Cursor recherchera activement le bug avec votre aide. Il y a ici beaucoup de collecte de données intéressante à effectuer.
Modifications plus vastes : Cursor devrait être capable de modifier des fichiers entiers, et même des répertoires entiers, pour vous. C’est un défi à la fois de capacités et d’UX. Pour la vitesse, le modèle doit être suffisamment intelligent pour repérer les parties à modifier sans tout réécrire. Pour que l’expérience soit bonne, les changements doivent être affichés sous une forme exploitable, en temps réel.
Passage à l’échelle : Nous avons 1,4 milliard de vecteurs et 150 000 bases de code indexées, au 12 octobre 2023. Cela va probablement être multiplié par 10 d’ici la fin de l’année. Nous avons déjà construit un moteur de synchronisation de bases de code très rapide basé sur un arbre de Merkle en Rust, et nous devrons probablement bientôt construire un système d’indexation personnalisé.

Idées futures :

Distorsion temporelle : prédire et afficher les changements de code inter-fichiers que vous ferez dans les 15 prochaines minutes. Une commande unique pour accepter toutes les insertions/suppressions.
Compréhension : nos modèles devraient comprendre en profondeur tous les concepts de n’importe quelle base de code, dans les poids.
Mode lecteur : rendre la compréhension du code sans effort avec de la documentation à n’importe quel niveau de spécificité et un bot qui vous guide à travers les chemins de code pertinents, en expliquant au besoin.
Mode pseudo-code : éditer une représentation « outline » de votre code et faire appliquer automatiquement les changements au niveau de la source.
Ne plus jamais vous soucier des stack traces : l’IDE devrait simplement les comprendre et corriger automatiquement le code pour vous.

Les gens aiment utiliser Cursor. Nous sommes très satisfaits de notre croissance initiale.
Vous travaillerez ici avec des personnes vraiment brillantes. Nous croyons profondément à une forte concentration de talents. Toutes les personnes avec qui vous travaillerez ici seront vraiment, vraiment excellentes.
Le développement assisté par l’IA est un immense marché. Et nous pouvons le conquérir.
C’est fun. C’est très important pour nous ! C’est fun de travailler avec des personnes que vous appréciez, c’est fun de créer un produit où vous appuyez sur Cmd‑Shift‑R et obtenez un retour utilisateur instantané parce que, vous-même, en programmant, êtes l’utilisateur cible, et c’est fun de progresser chaque jour un peu plus vers l’automatisation de toutes les parties ennuyeuses de la programmation.
Nous travaillons dur. Nous nous sentons privilégiés de pouvoir travailler sur ces problèmes, et nous aimons nous y investir pleinement pour les résoudre.

Mise à jour : nous avons écrit sur d’autres problèmes.

Une liste non ordonnée de problèmes courts et concrets :

Un meilleur contexte : Il existe de nombreuses sources d’informations dans un éditeur de code : fichiers ouverts, blocs de code sémantiquement similaires, classes reliées symboliquement, sorties de lint, traces d’exécution, historique git, historique de frappe, documentation externe, etc. Nous voulons que le modèle comprenne instantanément ce qui est le plus pertinent pour la question de l’utilisateur, et nous entraînons actuellement un modèle de reranking personnalisé et rapide pour résoudre ce problème. Pour chaque requête, nous rassemblerons 500k tokens provenant de toutes ces sources, et utiliserons notre reranker pour les filtrer jusqu’aux 8k tokens les plus pertinents. C’est à la fois un problème de modèle et, de plus en plus, un problème d’infrastructure.
Un “copilot pour les modifications” : Bien que GitHub Copilot soit extrêmement utile pour éliminer les frappes à faible entropie lors de l’écriture de nouveau code, il ne vous aide pas à économiser ces frappes à faible entropie lorsque vous devez effectuer de petits changements simples sur des blocs de code existants. Pensez à la navigation, la suppression et les frappes nécessaires pour un renommage juste un peu plus compliqué que ce qu’un renommage symbolique via F2 peut faire. Nous aurons besoin d’innovations à la fois en UX (des diffs discrets qui vous sont affichés pendant que vous codez) et côté modèle (le simple prompting ne suffit pas, en raison de problèmes de coût, de latence et de capacité).
Des agents contraints, dans le flux : Pensez au code interpreter d’OpenAI, mais pour l’ingénierie dans de grandes bases de code. Vous indiquez à un agent contraint, en quelques étapes, ce qu’il doit faire, et il recherche, écrit et exécute du code pour vous, tout en vous consultant régulièrement pour obtenir des retours. La première étape pour y parvenir, sur laquelle nous travaillons actuellement, est de créer un agent de ce type qui fonctionne sur des dossiers de quelques centaines de milliers de tokens. Si cela fonctionne, nous le ferons passer à l’échelle pour traiter des bases de code entières.
Détection de bugs : Il y a deux modes ici : (1) en arrière-plan, Cursor analysera toujours passivement vos fichiers pour trouver des bugs potentiels, et (2) lorsque vous êtes en pleine session de débogage, Cursor recherchera activement le bug avec votre aide. Il y a ici beaucoup de collecte de données intéressante à effectuer.
Modifications plus vastes : Cursor devrait être capable de modifier des fichiers entiers, et même des répertoires entiers, pour vous. C’est un défi à la fois de capacités et d’UX. Pour la vitesse, le modèle doit être suffisamment intelligent pour repérer les parties à modifier sans tout réécrire. Pour que l’expérience soit bonne, les changements doivent être affichés sous une forme exploitable, en temps réel.
Passage à l’échelle : Nous avons 1,4 milliard de vecteurs et 150 000 bases de code indexées, au 12 octobre 2023. Cela va probablement être multiplié par 10 d’ici la fin de l’année. Nous avons déjà construit un moteur de synchronisation de bases de code très rapide basé sur un arbre de Merkle en Rust, et nous devrons probablement bientôt construire un système d’indexation personnalisé.

Idées futures :

Distorsion temporelle : prédire et afficher les changements de code inter-fichiers que vous ferez dans les 15 prochaines minutes. Une commande unique pour accepter toutes les insertions/suppressions.
Compréhension : nos modèles devraient comprendre en profondeur tous les concepts de n’importe quelle base de code, dans les poids.
Mode lecteur : rendre la compréhension du code sans effort avec de la documentation à n’importe quel niveau de spécificité et un bot qui vous guide à travers les chemins de code pertinents, en expliquant au besoin.
Mode pseudo-code : éditer une représentation « outline » de votre code et faire appliquer automatiquement les changements au niveau de la source.
Ne plus jamais vous soucier des stack traces : l’IDE devrait simplement les comprendre et corriger automatiquement le code pour vous.

Les gens aiment utiliser Cursor. Nous sommes très satisfaits de notre croissance initiale.
Vous travaillerez ici avec des personnes vraiment brillantes. Nous croyons profondément à une forte concentration de talents. Toutes les personnes avec qui vous travaillerez ici seront vraiment, vraiment excellentes.
Le développement assisté par l’IA est un immense marché. Et nous pouvons le conquérir.
C’est fun. C’est très important pour nous ! C’est fun de travailler avec des personnes que vous appréciez, c’est fun de créer un produit où vous appuyez sur Cmd‑Shift‑R et obtenez un retour utilisateur instantané parce que, vous-même, en programmant, êtes l’utilisateur cible, et c’est fun de progresser chaque jour un peu plus vers l’automatisation de toutes les parties ennuyeuses de la programmation.
Nous travaillons dur. Nous nous sentons privilégiés de pouvoir travailler sur ces problèmes, et nous aimons nous y investir pleinement pour les résoudre.