Ce qui suit est une conversation avec les membres fondateurs de l'équipe Cursor : Michael Truell, Sualeh Asif, Arvid Lunnemark et Aman Sanger. Cursor est un éditeur de code basé sur VS Code qui ajoute des fonctionnalités puissantes pour le codage assisté par IA. Il a captivé l'attention et l'enthousiasme des communautés de programmation et d'IA. Je pense que c'est une excellente occasion de plonger en profondeur dans le rôle de l'IA dans la programmation. Il s'agit d'une conversation technique qui dépasse le cadre d'un simple éditeur de code. Il s'agit de l'avenir de la programmation et de l'avenir de la collaboration humain-IA dans la conception et l'ingénierie de systèmes complexes et puissants. C'est le podcast de Lex Fridman. Pour le soutenir, veuillez consulter nos sponsors dans la description. Et maintenant, chers amis, voici Michael, Sualeh, Arvid et Aman.

C'est génial. Nous avons Michael, Aman, Sualeh et Arvid de l'équipe Cursor. Tout d'abord, une grande question : à quoi sert un éditeur de code ?

L'éditeur de code est l'endroit où l'on construit des logiciels. Pendant longtemps, cela a signifié l'endroit où l'on édite le texte d'un langage de programmation formel. Pour les non-programmeurs, un éditeur de code est un traitement de texte perfectionné pour les programmeurs. La raison pour laquelle il est perfectionné est que le code a beaucoup de structure. L'éditeur de code peut faire beaucoup de choses pour vous que les traitements de texte dans le domaine de l'écriture n'ont pas pu faire. Cela inclut tout, de la différenciation visuelle des jetons dans le code pour que vous puissiez le parcourir rapidement, à la possibilité de naviguer dans la base de code comme vous naviguez sur Internet avec des hyperliens. Vous pouvez accéder aux définitions des éléments que vous utilisez et vérifier les erreurs pour détecter les bogues rudimentaires. Traditionnellement, c'est ce qu'un éditeur de code a signifié. Je pense que ce qu'est un éditeur de code changera au cours des 10 prochaines années à mesure que ce que signifie construire un logiciel commencera à paraître différent.

Je pense aussi qu'un éditeur de code devrait simplement être amusant.

Oui, c'est très important. C'est un aspect sous-estimé de la façon dont nous décidons de ce que nous allons construire. Beaucoup de choses que nous construisons et avec lesquelles nous expérimentons sont en fait jetées parce qu'elles ne sont pas amusantes. Une grande partie du plaisir réside dans la rapidité. La rapidité, c'est amusant.

La rapidité, c'est amusant. On devrait en faire un t-shirt.

Fondamentalement, je pense que l'une des choses qui attirent les gens à construire des choses sur ordinateur est cette vitesse d'itération. Dans d'autres disciplines, vous pourriez être limité par les ressources ou la capacité à réunir un grand groupe. Le codage est une chose incroyable où c'est vous et l'ordinateur, et vous pouvez construire des choses vraiment cool rapidement.

Pour les personnes qui ne le savent pas, Cursor est un nouvel éditeur cool qui est un fork de VS Code. Il serait intéressant d'avoir votre explication sur votre propre parcours avec les éditeurs. Je pense que vous étiez tous de grands fans de VS Code avec Copilot. Comment en êtes-vous arrivés à VS Code et comment cela a-t-il mené à votre aventure avec Cursor ?

Je pense que nous étions tous à l'origine des utilisateurs de Vim.

Pur Vim, pas de NeoVim, juste du pur Vim dans un terminal.

Pour moi, c'est vers l'époque de la sortie de Copilot en 2021 que j'ai vraiment voulu l'essayer. Je suis passé à VS Code, le seul éditeur de code dans lequel il était disponible. Même si j'aimais utiliser Vim, l'expérience de Copilot avec VS Code a suffi à me convaincre de changer. C'était le choix par défaut jusqu'à ce que nous commencions à travailler sur Cursor.

Nous devrions peut-être expliquer ce que fait Copilot. C'est une autocomplétion agréable. Lorsque vous commencez à écrire, il suggère plusieurs lignes pour compléter le code. Il y a une expérience amusante là-dedans. Lorsque vous avez une amitié étroite et que votre ami termine vos phrases, vous avez l'impression qu'il vous comprend. Il y a ce sentiment cool de 'il me comprend'. Il y a aussi des frictions quand ce n'est pas le cas. Pour beaucoup de gens, le sentiment d'être compris l'emporte sur les moments où ce n'est pas le cas.

L'un des aspects sous-estimés de GitHub Copilot est que même lorsqu'il se trompe, ce n'est pas si grave car il suffit de taper un autre caractère et peut-être qu'alors il vous comprendra. Ce n'est pas si grave, même quand il a tort.

On peut itérer et le corriger.

L'autre aspect sous-estimé de Copilot était simplement d'être le premier vrai produit d'IA. C'était le premier produit grand public basé sur un modèle de langage.

Donc Copilot a été la première 'killer app' pour les LLM.

Oui, et la version bêta est sortie en 2021.

C'est exact. Quelle est l'histoire de l'origine de Cursor ?

Vers 2020, les articles sur les lois d'échelle sont sortis d'OpenAI. C'était un moment où cela ressemblait à un progrès clair et prévisible pour le domaine. Il semblait que l'on pouvait rendre ces modèles bien meilleurs si l'on disposait de plus de puissance de calcul et de plus de données.

Nous parlerons probablement pendant des heures des lois d'échelle, mais pour résumer, c'est un ensemble d'idées qui disent que plus c'est grand, mieux c'est pour la taille du modèle et la taille des données en apprentissage automatique.

C'est plus grand et meilleur, mais de manière prévisible.

D'accord, c'est un autre sujet. Quoi qu'il en soit.

À cette époque, il y avait beaucoup de conversations conceptuelles sur ce à quoi cela ressemblerait pour les métiers du savoir et comment ils seraient améliorés par cette technologie. Il y a eu quelques moments où les gains théoriques prédits dans cet article ont commencé à sembler concrets. On a eu l'impression d'un moment où l'on pouvait réellement aller faire un travail utile en IA sans avoir de doctorat. Le premier moment a été de jouer avec la version bêta de Copilot ; c'était magique. Le moment suivant où tout s'est mis en place a été d'obtenir un accès anticipé à GPT-4. Fin 2022, nous bricolions avec ce modèle, et le saut de capacités semblait énorme. Auparavant, nous avions travaillé sur des outils spécifiques pour les programmeurs, comme la création d'outils pour les professionnels de la finance travaillant dans un Jupyter Notebook. Le passage à GPT-4 a rendu les gains théoriques concrets. On avait l'impression de pouvoir construire beaucoup plus immédiatement. Si nous étions cohérents, il semblait que toute la programmation allait passer par ces modèles. Cela exigeait un type d'environnement de programmation différent. Nous nous sommes alors lancés dans la construction de cette vision plus large.

Je me souviens distinctement que mon colocataire est un médaillé d'or de l'OMI (Olympiades Internationales de Mathématiques), et il y a une compétition aux États-Unis appelée le Putnam. Aman et Sheng Tong ont fait un pari en juin 2022 sur le fait que d'ici juin ou juillet 2024, un modèle gagnerait une médaille d'or à l'OMI.

L'OMI est l'Olympiade Internationale de Mathématiques.

Arvid et moi y avons aussi participé, donc c'était personnel. Je me souviens avoir pensé que cela n'arriverait tout simplement pas. Même si je croyais au progrès, je pensais qu'Aman délirait. Pour être honnête, j'avais tout à fait tort. C'était peut-être le pari le plus prescient du groupe.

Donc avec les nouveaux résultats de DeepMind, il s'est avéré que vous aviez raison.

C'était techniquement à un point près.

Aman était très enthousiaste à propos de tout cela à l'époque. Aman avait ce t-shirt sur les lois d'échelle avec lequel il se promenait, avec des graphiques et des formules dessus.

Donc vous avez ressenti l'AGI ou vous avez ressenti les lois d'échelle.

Je me souviens d'une conversation avec Michael où je n'avais pas réfléchi profondément aux lois d'échelle. Il a demandé pourquoi le passage à l'échelle n'entraînerait pas des gains massifs de progrès. Je suis passé par les étapes du deuil : colère, déni et enfin acceptation. Je suis optimiste quant au progrès depuis lors. Je nuancerais en disant que cela dépend aussi des domaines où l'on verra des progrès. Les mathématiques sont un excellent domaine car la preuve formelle de théorèmes donne un signal fantastique pour vérifier si une chose est correcte. Cela signifie que quelque chose comme le RL peut très bien fonctionner. On pourrait avoir des systèmes qui sont surhumains en maths et ne pas avoir techniquement d'AGI.

Pouvons-nous en revenir à Cursor ? Qu'est-ce que Cursor ? C'est un fork de VS Code. VS Code est l'un des éditeurs les plus populaires et tout le monde en est tombé amoureux. Il a unifié la communauté des développeurs. Vous regardez les lois d'échelle et l'IA qui devient incroyable, et vous avez décidé qu'il ne suffisait pas d'écrire une extension pour VS Code à cause des limitations. Si l'IA continue de s'améliorer, nous devons repenser la manière dont l'IA fait partie du processus d'édition. Vous avez décidé de forker VS Code et de construire des fonctionnalités incroyables. Comment s'est passée cette décision ? Il y a beaucoup d'extensions qui font de l'IA. Qu'est-ce qui a motivé la décision de forker VS Code ?

La décision de faire un éditeur semblait évidente au vu de ce que nous voulions accomplir. Quand nous avons commencé, l'idée était que ces modèles allaient devenir bien meilleurs, et que cela changerait entièrement la façon de construire des logiciels. Vous aurez des gains de productivité énormes, et l'acte de construire un logiciel changera beaucoup. Vous êtes très limité dans le contrôle que vous avez sur un éditeur de code si vous n'êtes qu'un plugin dans un environnement existant. Nous ne voulions pas être enfermés par ces limitations ; nous voulions construire ce qu'il y a de plus utile.

Eh bien, la question naturelle est que VS Code avec Copilot est un concurrent. Comment gagner ? Est-ce essentiellement la rapidité et la qualité des fonctionnalités ?

Je pense que cet espace est unique. Lors des vagues technologiques précédentes, un événement majeur se produisait et débloquait une nouvelle vague d'entreprises. Aujourd'hui, chaque saut de capacité des modèles débloque une nouvelle vague de fonctionnalités. Dans la programmation assistée par IA, avoir quelques mois ou un an d'avance rend votre produit beaucoup plus utile. Le Cursor de l'année prochaine doit rendre le Cursor d'aujourd'hui obsolète. Microsoft a fait des choses fantastiques, mais je ne pense pas qu'ils soient bien placés pour continuer à innover et à pousser les choses comme une startup peut le faire.

Juste en implémentant rapidement des fonctionnalités.

Et en faisant la recherche et l'expérimentation nécessaires pour repousser les limites.

Je n'y pense pas tant en termes de fonctionnalités qu'en termes de capacités pour les programmeurs. À mesure que des modèles comme O1 sortent, il y aura davantage de modèles de types différents, comme des contextes plus longs ou des modèles plus rapides. Il y a des idées folles que l'on peut essayer et, espérons-le, certaines deviendront utiles. Nous voulons que les gens y aient accès plus tôt. Un fait sous-estimé est que nous le fabriquons pour nous-mêmes. Quand nous avons commencé Cursor, nous ressentions de la frustration car les modèles s'amélioraient mais l'expérience Copilot n'avait pas changé. Le plafond s'élevait, mais ils ne créaient rien de nouveau. Il n'y avait pas de fonctionnalités alpha. Je suis sûr que c'était une excellente affaire, mais cela ne semblait pas innovant. Je veux essayer de nouvelles choses et il n'y avait rien de nouveau pendant un long moment.

C'est intéressant. Je ne sais pas comment exprimer cela, mais comparé à Cursor, Copilot a commencé à sembler stagner.

Je pense que cela aide que nous fassions tout en un. Nous développons l'UX et la façon dont vous interagissez avec le modèle tout en développant la façon dont nous faisons en sorte que le modèle donne de meilleures réponses, la façon dont nous construisons le prompt et la façon dont nous trouvons le contexte. Pour Cursor Tab, nous entraînons également le modèle. Avoir les mêmes personnes travaillant sur toute l'expérience de bout en bout nous aide.

Souvent, la personne qui crée l'interface utilisateur et celle qui entraîne le modèle sont assises à 5 mètres l'une de l'autre.

Souvent, c'est la même personne.

Oui, souvent même la même personne, on peut donc créer des choses qui ne seraient pas possibles si on n'expérimentait pas ensemble.

Et vous utilisez Cursor pour écrire Cursor.

Bien sûr.

Parlons de certaines de ces fonctionnalités. Parlons du tout-puissant 'Tab', l'autocomplétion sous stéroïdes. Comment fonctionne Tab ? Qu'est-ce que Tab ?

Pour résumer, il y a deux choses pour lesquelles Cursor est bon actuellement. L'une est d'être comme un collègue rapide qui peut anticiper et deviner ce que vous allez faire ensuite. C'était le cœur de l'idée derrière une bonne autocomplétion : prédire ce que vous allez faire ensuite. Vous pouvez rendre ce concept encore plus ambitieux en prédisant non seulement des caractères, mais le changement complet suivant, le 'diff' suivant, et l'endroit suivant où vous allez sauter. La deuxième chose pour laquelle Cursor est bon est de vous aider à devancer l'IA et à lui dire quoi faire, en passant des instructions au code. Nous avons beaucoup travaillé pour rendre l'expérience d'édition pour ces choses ergonomique, intelligente et rapide.

Nous voulions vraiment que le modèle puisse éditer du code pour nous. Nous avons fait plusieurs tentatives avant d'avoir un bon modèle capable d'éditer du code pour vous. Une fois le modèle opérationnel, beaucoup d'efforts ont été consacrés à rendre l'inférence rapide pour une bonne expérience. Nous avons commencé à intégrer cette capacité de sauter à différents endroits. Cela vient du sentiment qu'une fois qu'on accepte une modification, l'endroit suivant où aller devrait être évident. Le modèle devrait savoir que le prochain endroit où aller est 18 lignes plus bas. En tant qu'utilisateur de Vim, vous pourriez taper 18jj, mais le modèle devrait simplement le savoir. L'idée était que vous appuyez sur Tab, cela descend de 18 lignes et montre la modification suivante, et vous continuez à appuyer sur Tab. La compétition interne était de savoir combien de fois nous pouvions faire appuyer quelqu'un sur Tab. De manière abstraite, nous pensons au moment où les modifications ont une entropie nulle. Une fois que vous avez exprimé votre intention et que la modification n'apporte aucune nouvelle information, vous devez encore taper des caractères pour que l'ordinateur comprenne ce que vous pensez. Le modèle devrait lire dans vos pensées et tous ces bits d'entropie nulle devraient être réglés par Tab.

Si vous regardez la perte du modèle de langage sur différents domaines, les bits par octet — qui est la perte normalisée par caractère pour le code — sont plus faibles que pour le langage. Cela signifie que de nombreux jetons dans le code sont hyper prévisibles. C'est amplifié quand vous n'essayez pas seulement de compléter automatiquement le code, mais de prédire ce que l'utilisateur va faire ensuite dans son édition. L'objectif de Cursor Tab est d'éliminer les actions à faible entropie à l'intérieur de l'éditeur. Lorsque l'intention est effectivement déterminée, projetons-nous vers l'avant dans le temps.

Quel est le détail technique de la façon de faire la prédiction du prochain curseur ? Ce saut n'est pas intuitif pour les gens.

Je peux donner quelques détails sur la façon de faire fonctionner ces choses. Elles ont une latence incroyablement basse, vous devez donc entraîner de petits modèles sur cette tâche. Ils sont incroyablement gourmands en jetons de pré-remplissage. Ils ont des prompts très longs où ils voient beaucoup de votre code et ils ne génèrent pas réellement tant de jetons que ça. La solution parfaite pour cela est d'utiliser un modèle épars, c'est-à-dire un modèle MoE (mélange d'experts). C'est une percée que nous avons faite et qui a considérablement amélioré les performances sur des contextes longs. L'autre est une variante du décodage spéculatif que nous avons construit, appelée 'modifications spéculatives'. Ce sont deux pièces importantes de ce qui rend le tout de haute qualité et très rapide.

D'accord, MoE, mélange d'experts. L'entrée est énorme, la sortie est petite. Le cache joue-t-il un rôle ?

Le cache joue un rôle énorme car vous gérez de nombreux jetons d'entrée. Si pour chaque frappe de touche vous deviez relancer le modèle sur tous ces jetons, vous dégraderiez considérablement la latence et satureriez vos GPU. Vous devez concevoir les prompts pour qu'ils soient sensibles au cache. Vous devez réutiliser le cache KV entre les requêtes afin de dépenser moins de travail et moins de calcul.

Quelles sont les choses que Tab est censé pouvoir faire à court terme ? Générer du code, remplir des espaces vides, éditer du code sur plusieurs lignes et sauter à différents endroits dans le même fichier ?

J'espère sauter vers différents fichiers aussi. Si vous faites une modification dans un fichier et que vous devez aller dans un autre pour terminer votre pensée, il devrait également aller dans le second fichier.

La généralisation complète est la prédiction de la prochaine action. Parfois, vous devez exécuter une commande dans le terminal et il devrait suggérer la commande en fonction du code que vous avez écrit. Parfois, il suggère quelque chose, mais il est difficile pour vous de savoir si c'est correct parce que vous avez besoin de plus d'informations. Vous pourriez avoir besoin de connaître une définition de type pour vérifier si c'est correct. Il devrait vous emmener à la définition, puis vous ramener pour que vous ayez les connaissances requises pour accepter la complétion.

Fournir la connaissance à l'humain.

Oui.

Je viens de faire la connaissance d'un gars nommé Primeagen qui a une configuration SSH où l'on peut commander du café via SSH.

Ah oui, on a fait ça.

Alors le modèle peut-il faire ça, vous fournir de la caféine ?

C'est le cadre général.

Le moment magique serait celui où la programmation devient prévisible. Parfois, les cinq prochaines minutes de ce que vous allez faire sont prévisibles à partir de ce que vous avez fait récemment. Pouvons-nous arriver à un monde où ces cinq prochaines minutes se produisent soit par votre désengagement, soit en voyant les prochaines étapes et en validant simplement de grands changements ?

Je devrais mentionner que l'une des choses cool de Cursor est l'interface de diff. Le modèle suggère des modifications avec du rouge et du vert. Dans la fenêtre de chat, vous pouvez appliquer et accepter le diff. Pouvez-vous nous parler de cette direction ?

Nous avons quatre ou cinq types différents de diffs. Nous avons optimisé le diff pour l'autocomplétion afin qu'il ait une interface différente de celle utilisée pour réviser de grands blocs de code. Nous essayons d'optimiser un autre diff pour le cas où vous travaillez sur plusieurs fichiers. À un haut niveau, la différence est que pour l'autocomplétion, il doit être très rapide à lire. Dans toutes les situations, cela doit être rapide, mais dans l'autocomplétion, vous êtes vraiment concentré sur une seule zone et les humains ne peuvent pas regarder trop d'endroits différents à la fois.

Vous parlez de l'aspect interface.

Côté interface, nous avons une boîte sur le côté. Nous avons fait plusieurs tentatives pour que cela fonctionne. D'abord, nous avons essayé des lignes bleues barrées comme dans Google Docs, montrant une ligne à travers le code à supprimer. C'était super distrayant. Ensuite, nous avons essayé différentes suppressions et des surbrillances rouges. L'itération suivante consistait à maintenir la touche Option enfoncée sur un Mac. Cela mettrait en évidence une région de code en bleu pour montrer qu'une suggestion pourrait arriver. Cela signalait que l'IA avait une suggestion ; si vous mainteniez Option, vous la voyiez, et si vous la relâchiez, vous revoyiez votre code d'origine.

C'est plutôt sympa, mais il faut savoir qu'il faut maintenir la touche Option. Je ne suis pas un utilisateur de Mac, mais je comprends.

Ce n'est pas intuitif, c'est là le problème clé. Il y a de fortes chances que ce ne soit pas la version finale.

Je suis enthousiaste à l'idée d'apporter des améliorations dans ce domaine. Nous appelons cela le problème de vérification. Ces diffs sont excellents pour de petites modifications, mais pour de grandes modifications ou sur plusieurs fichiers, il est prohibitif de les réviser. Nous avons quelques idées. L'une d'elles est que certaines parties des diffs sont importantes et contiennent beaucoup d'informations, tandis que d'autres sont simplement à faible entropie. On peut mettre en évidence les éléments importants et griser le reste. Ou un modèle pourrait regarder le diff, voir un bogue probable, le marquer d'un soulignement ondulé rouge et vous dire de réviser cette partie du diff. Les idées dans cette veine sont passionnantes.

Vous essayez de guider le programmeur humain à travers tout ce qu'il doit lire et rien de plus, de manière optimale.

Oui, et vous voulez un modèle intelligent pour le faire. Actuellement, les algorithmes de diff sont juste des algorithmes normaux sans intelligence. Peu importe qu'il s'agisse de telle ou telle chose. Vous voulez qu'un modèle gère cela.

La question générale est que ces modèles vont devenir beaucoup plus intelligents. À mesure qu'ils deviendront plus intelligents, les changements qu'ils proposeront seront beaucoup plus importants. À mesure que les changements s'accentuent, les humains doivent faire davantage de travail de vérification. Vous devez les aider. Je ne veux pas passer tout mon temps à réviser du code.

Pouvez-vous en dire plus sur le diff multi-fichiers ?

GitHub essaie de résoudre ce problème avec la revue de code où vous examinez plusieurs diffs à travers les fichiers. Mais on peut faire bien mieux que la revue de code. La revue de code est souvent pénible parce qu'on passe du temps à essayer de comprendre du code inconnu et cela ne détecte même pas beaucoup de bogues. Vous pouvez améliorer considérablement cette expérience en utilisant des modèles de langage, par exemple en vous orientant vers les régions qui comptent vraiment. Si le code est produit par un modèle de langage, l'expérience peut être conçue entièrement autour du réviseur pour la rendre amusante et productive. Essayer naïvement de faire ressembler ces choses à une revue de code est un problème ; on peut être plus créatif et repousser les limites du possible.

Une idée est que l'ordre compte. Généralement, quand vous révisez une PR (Pull Request), vous avez une liste de fichiers et vous les examinez de haut en bas. Mais vous voulez d'abord comprendre certaines parties de manière logique. Vous ne voulez pas avoir à deviner cela par vous-même ; vous voulez qu'un modèle vous guide.

L'étape de création va-t-elle se faire davantage en langage naturel qu'en écriture réelle ?

Je pense que parfois oui. Il n'en sera pas ainsi pour toute la programmation. Si je fais de la programmation en binôme et que je pilote, je pourrais dire 'hé, implémente cette fonction', et ça marche. Parfois, c'est ennuyeux d'expliquer ce que je veux, alors je prends le clavier et j'écris un exemple. C'est le moyen le plus simple de communiquer. C'est également vrai pour l'IA. Parfois, le moyen le plus simple de communiquer est de montrer un exemple et ensuite elle fait la même chose partout ailleurs. Si vous créez un site Web, le moyen le plus simple de montrer à l'IA ce que vous voulez pourrait être de faire glisser ou de dessiner des éléments. Finalement, nous pourrions en arriver aux interfaces cerveau-machine. Le langage naturel aura sa place, mais ce ne sera pas le mode principal de programmation pour la plupart des gens, la plupart du temps.

Je ressens l'AGI avec cet éditeur. Parlez-moi des trucs de ML (apprentissage automatique) qui font que ça marche.

Cursor fonctionne via cet ensemble de modèles personnalisés entraînés aux côtés de modèles frontières qui sont fantastiques pour le raisonnement. Cursor Tab est un excellent exemple où l'on peut spécialiser un modèle pour qu'il soit meilleur que les modèles frontières sur les tâches que nous fixons. L'autre domaine nécessitant des modèles personnalisés est 'Apply'. Les modèles frontières sont bons pour esquisser des plans, mais créer des diffs précis est difficile pour eux. Ils se trompent sur des choses comme le comptage des numéros de lignes dans de gros fichiers. Pour pallier cela, nous laissons le modèle esquisser un bloc de code brut et nous entraînons un modèle pour appliquer ce changement au fichier.

Donc 'Apply' est l'étape où le modèle regarde votre code, donne une suggestion, et l'étape de combinaison des deux n'est pas triviale.

Ce n'est pas un algorithme déterministe.

Les copies superficielles de 'Apply' ailleurs échouent souvent parce qu'elles tentent une correspondance déterministe et échouent au moins 40 % du temps, ce qui entraîne une expérience terrible. 'Apply' vous permet d'utiliser moins de jetons avec des modèles intelligents. Générer tous ces jetons est coûteux en termes de latence et de coût. Vous pouvez donner une esquisse brute et ensuite demander à de petits modèles de l'implémenter car c'est une tâche plus facile. Ce régime va perdurer où des modèles plus intelligents font la planification et l'implémentation est gérée par des modèles moins intelligents. Peut-être que O1 ou des modèles plus performants donneront un plan de haut niveau qui sera appliqué de manière récursive par Sonnet, puis par le modèle 'Apply'.

Parlons de la façon de le rendre rapide. La rapidité, c'est bien.

Comment le rendre rapide ?

Une grande composante est constituée par les 'modifications spéculatives', une variante du décodage spéculatif. Dans le décodage spéculatif, on tire parti du fait que le traitement de plusieurs jetons à la fois est plus rapide que la génération d'un jeton à la fois. C'est pourquoi le nombre de jetons par seconde pour les jetons de prompt est beaucoup plus rapide que pour les jetons générés. Au lieu d'utiliser un petit modèle pour prédire des jetons provisoires qu'un modèle plus grand vérifierait, avec les modifications de code, we have a strong prior on what the existing code will look like: exactly the same code. You can feed chunks of the original code back into the model, and it will agree most of the time. You can process all those lines in parallel until the model predicts text that differs from the ground truth. It will then generate those tokens, and then we decide to start the chunk speculation again. This feels like a much faster version of the model rewriting the code. The stream comes in much faster.

Pendant que le flux arrive, vous pouvez commencer à réviser le code avant qu'il ne soit terminé, il n'y a donc pas d'écran de chargement.

L'humain peut donc commencer à lire avant que la chose ne soit terminée.

La spéculation est une idée courante de nos jours, non seulement dans les modèles de langage mais aussi dans les processeurs et les bases de données.

Quel LLM est le meilleur pour le codage ? GPT ou Claude ? Je suis sûr que la réponse est nuancée car chaque partie implique un modèle différent.

Il n'y a pas de modèle qui domine les autres de manière absolue dans des catégories comme la vitesse, l'édition de code, le contexte long et les capacités de codage. Pour l'instant, le meilleur dans l'ensemble est Sonnet. O1 est vraiment intéressant et bon en raisonnement, mais il ne comprend pas votre intention brute aussi bien que Sonnet. Un grief que j'ai avec d'autres modèles frontières est qu'ils sont performants sur les benchmarks par rapport à tout ce qui se trouve au milieu. Quand on les pousse hors de cette distribution, Sonnet s'en sort le mieux pour maintenir sa capacité.

Quelle est la différence entre l'expérience de programmation normale et ce que les benchmarks représentent ? Où les benchmarks échouent-ils ?

C'est un détail critique et difficile. Le vrai codage n'est pas du codage de type entretien d'embauche. Les humains utilisent un anglais approximatif ou disent 'fais ce que j'ai fait avant'. Vous voulez comprendre l'humain et faire ce qu'il veut. Les problèmes d'entretien sont bien spécifiés et s'appuient sur des spécifications, tandis que les demandes humaines sont moins précises.

Parfois, on a besoin de plus d'informations pour vérifier si une suggestion est correcte, comme connaître une définition de type. Il devrait vous emmener à la définition puis vous ramener pour que vous ayez la connaissance requise pour accepter la complétion.

Fournir la connaissance à l'humain.

Oui.

C'est exact.

Ouais.

Pouvez-vous intégrer la commande de café via SSH ?

On a fait ça.

Alors le modèle peut-il vous nourrir et vous fournir de la caféine ?

Ouais.

C'est le cadre général.

Le moment magique serait celui où les cinq prochaines minutes de ce que vous allez faire sont prévisibles. Pouvez-vous arriver à un monde où ces cinq prochaines minutes se produisent soit par votre désengagement, soit en validant par Tab de grands changements à mesure que vous voyez les étapes suivantes ?

Une chose remarquable à propos de Cursor est l'interface de diff. Le modèle suggère des changements en rouge et vert, et vous pouvez les appliquer et les accepter dans la fenêtre de chat. Pouvez-vous nous en parler ?

Nous avons plusieurs types de diffs. Nous avons optimisé le diff pour l'autocomplétion avec une interface différente de celle utilisée pour réviser de gros blocs de code. Nous essayons d'optimiser un autre diff pour les fichiers multiples. Dans l'autocomplétion, vous êtes concentré sur une zone et ne pouvez pas regarder trop d'endroits à la fois.

Vous parlez de l'aspect interface.

Côté interface, il y a actuellement une boîte. Nous avons fait plusieurs tentatives pour cela. D'abord, nous avons essayé des lignes bleues barrées comme dans Google Docs ; c'était super distrayant. Ensuite, nous avons essayé des suppressions et des surbrillances rouges. L'itération suivante a consisté à maintenir la touche Option sur un Mac pour mettre en évidence une région de code en bleu, signalant que l'IA avait une suggestion. Maintenir Option affichait la nouvelle suggestion, et la relâcher affichait votre code d'origine.

C'est bien, mais il faut savoir qu'il faut maintenir la touche Option.

Ouais.

Je ne suis pas un utilisateur de Mac, mais je comprends.

Ce n'est pas intuitif, c'est le point clé.

Et ce n'est probablement pas la version finale.

Je suis enthousiaste à l'idée d'apporter des améliorations dans ce domaine. Nous appelons cela le problème de vérification. Ces diffs sont excellents pour de petites modifications, mais pour des modifications importantes ou multi-fichiers, il est prohibitif de les réviser. Une idée que nous avons est de mettre en évidence les parties importantes du diff et de griser les sections à faible entropie. Ou de demander à un modèle de regarder le diff, d'y voir un bogue probable et de le marquer d'un soulignement ondulé rouge pour révision. Les idées dans cette veine sont passionnantes.

Vous essayez de guider le programmeur à travers tout ce qu'il doit lire et rien de plus, de manière optimale.

Oui, et vous voulez un modèle intelligent pour le faire. Actuellement, les algorithmes de diff sont juste des algorithmes normaux sans intelligence. Vous voulez qu'un modèle fasse la différence entre les types de changements.

La question générale est qu'à mesure que les modèles deviennent plus intelligents, les changements qu'ils proposent seront beaucoup plus importants. Les humains devront faire plus de travail de vérification. Vous devez les aider pour qu'ils ne passent pas tout leur temps à réviser du code.

Pouvez-vous en dire plus sur les diffs multi-fichiers ?

GitHub essaie de résoudre ce problème avec la revue de code sur plusieurs fichiers. Mais on peut faire bien mieux. La revue de code peut être pénible parce qu'on passe du temps à comprendre du code inconnu et elle ne détecte pas beaucoup de bogues. On peut améliorer cette expérience de revue en utilisant des modèles de langage pour vous orienter vers les régions qui comptent. Si le code est produit par un modèle de langage, l'expérience de revue peut être conçue entièrement autour du réviseur pour la rendre amusante et productive. Essayer naïvement de faire ressembler ces choses à une revue de code est un problème ; on peut être plus créatif et repousser les limites.

L'ordre compte. Généralement, vous révisez les fichiers de haut en bas, mais vous voulez d'abord comprendre le flux logique. Vous voulez qu'un modèle vous guide à travers tout ça.

L'objectif de la création est-il d'être davantage en langage naturel qu'en écriture réelle ?

Je ne pense pas que toute la programmation se fera en langage naturel. Si je fais du pair programming et que je pilote, je pourrais dire 'implémente cette fonction', et ça marche. D'autres fois, c'est ennuyeux d'expliquer ce que je veux, alors je prends le clavier et je montre un exemple. C'est également vrai pour l'IA. Pour un site Web, le moyen le plus simple de montrer à l'IA ce que vous voulez pourrait être de déplacer des éléments ou de dessiner des choses. Finalement, nous pourrions en arriver à des interfaces cerveau-machine. Le langage naturel aura une place, mais ce ne sera pas le mode principal de programmation pour la plupart des gens, la plupart du temps.

Je ressens l'AGI avec cet éditeur. Parlez-moi des trucs de ML qui font que tout cela fonctionne.

Cursor fonctionne via un ensemble de modèles personnalisés entraînés aux côtés de modèles frontières. Cursor Tab est un modèle spécialisé qui est plus performant que les modèles frontières sur nos tâches. Des modèles personnalisés sont également nécessaires pour 'Apply'. Les modèles frontières sont doués pour esquisser des plans, mais créer des diffs est difficile pour eux. Ils se trompent sur des choses comme le comptage des lignes dans de gros fichiers. Nous laissons le modèle esquisser un bloc de code brut et nous entraînons un modèle pour appliquer ce changement au fichier.

Donc 'Apply' est l'endroit où le modèle regarde votre code, donne une suggestion, et l'étape de combinaison des deux n'est pas triviale.

Ce n'est pas un algorithme déterministe.

Les copies superficielles de 'Apply' ailleurs échouent souvent parce qu'elles tentent une correspondance déterministe et échouent au moins 40 % du temps, ce qui entraîne une expérience terrible. Ce régime de modèles plus intelligents va perdurer. 'Apply' vous permet d'utiliser moins de jetons avec les modèles les plus intelligents. Vous pouvez donner une esquisse brute et demander à de petits modèles de l'implémenter. Les modèles plus intelligents s'occupent de la planification tandis que l'implémentation est gérée par des modèles moins intelligents. Peut-être que O1 donnera un plan de haut niveau qui sera appliqué récursivement par Sonnet puis par le modèle 'Apply'.

Nous devrions parler de la façon de le rendre rapide.

Ouais.

La rapidité, c'est bien.

Comment le rendre rapide ?

Une composante majeure de la vitesse est constituée par les 'modifications spéculatives', une variante du décodage spéculatif. Dans le décodage spéculatif, on tire parti du fait que le traitement de plusieurs jetons à la fois est plus rapide que la génération d'un jeton à la fois. C'est pourquoi les jetons de prompt sont beaucoup plus rapides que les jetons générés. Le décodage spéculatif standard utilise un petit modèle pour prédire des jetons provisoires pour vérification. Avec les modifications de code, nous avons un a priori fort sur ce à quoi ressemblera le code existant : exactement le même code. Vous pouvez réinjecter des morceaux du code original dans le modèle, et il sera d'accord la plupart du temps. Vous pouvez traiter toutes ces lignes en parallèle jusqu'à ce que vous atteigniez un point de désaccord où le modèle prédit un texte différent. Cela ressemble à une version beaucoup plus rapide du modèle réécrivant le code. Le flux arrive beaucoup plus vite.

L'avantage est que pendant le flux, vous pouvez commencer à réviser le code avant qu'il ne soit terminé, il n'y a donc pas de gros écran de chargement.

L'humain peut commencer à lire avant que la chose ne soit terminée.

La spéculation est une idée courante de nos jours, non seulement dans les modèles de langage mais aussi dans les processeurs et les bases de données.

Quel LLM est le meilleur pour le codage ? GPT ou Claude ? Je suis sûr que la réponse est nuancée car chaque partie implique un modèle différent.

Aucun modèle ne domine les autres dans toutes les catégories comme la vitesse, l'édition de code et le contexte long. Pour l'instant, le meilleur dans l'ensemble est Sonnet. O1 est intéressant et bon en raisonnement et pour les problèmes d'entretien, mais il ne comprend pas votre intention brute aussi bien que Sonnet. D'autres modèles frontières sont performants sur les benchmarks par rapport à tout ce qui se trouve au milieu, mais Sonnet maintient mieux cette même capacité lorsqu'il est poussé hors de sa distribution.

Quelle est la différence entre l'expérience de programmation normale et ce que les benchmarks représentent ? Où les benchmarks échouent-ils ?

C'est un détail d'une importance critique. Le vrai codage n'est pas du codage de type entretien d'embauche. Les humains utilisent un anglais approximatif ou disent 'fais ce que j'ai fait avant'. Vous voulez comprendre l'humain et faire ce qu'il veut. Les problèmes d'entretien sont bien spécifiés et s'appuient sur des spécifications, tandis que les demandes humaines sont moins précises.

La question du benchmark est compliquée par l'écart entre les benchmarks et la programmation désordonnée du monde réel. Les benchmarks publics font souvent l'objet d'une optimisation excessive ('hill-climbing') et sont contaminés dans les données d'entraînement. Par exemple, les modèles peuvent résoudre des problèmes SWE-bench en hallucinant des chemins de fichiers qu'ils ont vus lors de l'entraînement sans avoir besoin du contexte de la base de code. L'aspect public de ces choses est délicat.

Ils pourraient être entraînés sur des problèmes réels ou des pull requests. Bien que les laboratoires essaient de décontaminer, ils n'omettent pas les dépôts populaires comme SymPy de l'entraînement juste pour obtenir de vrais scores d'évaluation.

Étant donné l'absence de bons benchmarks, les entreprises utilisent des béquilles comme le retour humain qualitatif pour évaluer les progrès. En interne, nous évaluons qualitativement ces modèles et nous nous appuyons là-dessus en plus des évaluations privées.

Le ressenti ('vibe').

Le test du ressenti humain.

Essentiellement.

C'est ce que je fais, en lisant les forums en ligne où les gens disent des choses comme 'Claude est devenu plus bête'. Je me demande si c'est le problème du modèle ou le mien.

Il existe une théorie selon laquelle les performances de Claude varient selon qu'il fonctionne sur AWS Bedrock ou sur les propres GPU d'Anthropic, en raison de puces et d'une quantification différentes.

J'interviewe des gens avec des théories du complot, donc je suis content que vous en ayez parlé.

Ce n'est pas tant une théorie du complot qu'une réalité des systèmes construits par l'homme et des puces qui sont désordonnés. Les bogues sont difficiles à éviter.

Quel est le rôle d'un bon prompt ? Un humain devrait-il faire quelque chose pour maximiser le succès ? Vous avez appelé cela la conception de prompt ('prompt design').

Cela dépend du modèle. Les modèles de l'année dernière étaient sensibles aux prompts et avaient de petites fenêtres de contexte. Décider quoi mettre dans un espace limité est un problème. Même avec un contexte long, remplir toute la fenêtre est plus lent et peut embrouiller les modèles. Nous avons un système interne appelé 'pre-prompt' pour aider à cela. C'est similaire à la création d'un site Web qui doit fonctionner sur mobile ou sur ordinateur avec des informations dynamiques. Nous nous inspirons de l'approche déclarative de React utilisant JSX pour déclarer la priorité et l'index Z pour les composants du prompt. Notre moteur de rendu ajuste ensuite tout sur la page. Cela facilite le débogage car on peut modifier le rendu et le tester par rapport aux données brutes des anciens prompts.

Donc vous faites littéralement des prompts avec JSX.

Oui.

Cela ressemble à React. Nous avons un composant de fichier qui donne la priorité à la ligne où se trouve le curseur, car c'est la plus importante. Le moteur de rendu calcule le nombre de lignes qui peuvent tenir et se centre autour de ce point.

C'est incroyable.

Vous pouvez utiliser la recherche ('retrieval'), les plongements ('embeddings') et les scores de reclassement ('re-ranking') pour ajouter des priorités à ces composants.

Les humains devraient-ils aussi essayer d'utiliser JSX dans leurs prompts, ou devraient-ils rester vagues et désordonnés ?

Notre objectif est que vous fassiez ce qui est naturel, et c'est notre travail de récupérer les éléments pertinents pour que cela fonctionne.

C'est l'idée de laisser la personne être paresseuse.

Oui.

Mais j'ai l'impression qu'on est en droit d'en demander plus aux programmeurs. Les humains sont paresseux, mais il y a une tension entre être paresseuse et être articulé dans la profondeur de la pensée transmise.

Lorsqu'une requête manque d'intention, le modèle peut demander des éclaircissements ou montrer plusieurs générations possibles et laisser l'utilisateur choisir.

Est-il difficile pour le modèle de choisir de répondre au lieu de générer ? Comment gérez-vous l'incertitude ?

Nous avons récemment ajouté une fonctionnalité pour suggérer des fichiers que vous pourriez ajouter. Pendant que vous tapez, nous pouvons deviner ce dont vous avez besoin et suggérer des fichiers pertinents. Nous vous montrons des fichiers à ajouter ou à éditer, comme suggérer à la fois le client et le serveur si vous créez une API. Cela aide à résoudre une partie de l'incertitude avant même d'appuyer sur Entrée.

À quel point utilisez-vous des approches agentiques ?

Les agents sont cool et représentent une étape vers l'AGI, mais ils ne sont pas encore super utiles. Nous nous en rapprochons. J'adorerais un agent pour des tâches bien spécifiées, comme corriger un bogue où le copier-coller ne fonctionne pas dans notre entrée de chat. Je veux dire 'corrige ça' et qu'un agent s'en aille, le fasse, et me laisse le réviser un jour plus tard.

Vous voulez dire qu'il trouve le bon fichier.

Il trouve les fichiers, reproduit le bogue, le corrige et le vérifie. Je ne pense pas que les agents prendront le contrôle de toute la programmation parce qu'une grande partie de la valeur réside dans l'itération. On ne sait souvent pas ce qu'on veut avant d'en voir une version initiale. On veut un système qui donne une version instantanée sur laquelle on peut itérer rapidement.

Qu'en est-il de Replit Agent qui configure des environnements de développement et déploie des applications ?

Ce serait cool pour certains types de programmation.

Est-ce dans le périmètre de Cursor ?

Nous n'y travaillons pas activement, mais nous voulons faciliter la vie du programmeur. Certaines choses sont fastidieuses et vous voulez les déléguer à un agent. Vous pourriez avoir un agent en arrière-plan travaillant sur un backend pendant que vous travaillez sur le frontend d'une PR.

La plupart des aspects de Cursor semblent rapides. 'Apply' est la chose la plus lente.

C'est un point douloureux sur lequel nous travaillons.

Si quelque chose qui prend quelques secondes semble lent, cela signifie que tout le reste est très rapide. Y a-t-il des détails techniques sur la façon dont vous rendez le chat et les diffs rapides ?

Une stratégie est le pré-chargement du cache ('cache warming'). À mesure que l'utilisateur tape, nous pouvons prédire quel contexte il utilisera et pré-charger le cache avec le contenu du fichier. Lorsqu'il appuie sur Entrée, il y a peu de jetons à calculer avant de commencer la génération, ce qui réduit le temps jusqu'au premier jeton.

Pouvez-vous expliquer comment fonctionne le cache KV ?

Les Transformers utilisent l'attention pour regarder les jetons précédents. L'attention implique des clés ('keys') et des valeurs ('values'), qui sont des représentations internes des jetons. Normalement, un modèle doit faire une passe avant à travers tout le modèle pour chaque jeton, ce qui est lent. Si vous stockez ces clés et ces valeurs dans le GPU, vous n'avez pas besoin de re-traiter les jetons précédents. Vous ne faites la passe avant que pour le nouveau jeton et réutilisez le cache existant.

Existe-t-il une mise en cache de plus haut niveau qui pourrait aider ?

Pour Cursor Tab, nous pouvons prédire à l'avance comme si l'utilisateur acceptait une suggestion et déclencher une autre requête. Cette spéculation signifie que lorsqu'il appuie sur Tab, la suivante attend immédiatement. C'est rapide malgré l'absence de changement dans la vitesse de génération du modèle.

Si vous réduisez la taille du cache KV, vous pouvez spéculer davantage. Si vous prédisez 10 choses, il y a plus de chances que l'une d'elles soit correcte. Nous utilisons le RL pour prédire quelles suggestions sont les plus acceptables pour un humain. Vous pouvez donner une récompense aux choses que les humains aiment et punir ce qu'ils n'aimeront pas, entraînant le modèle à produire de meilleures suggestions.

Aman peut entrer plus dans les détails.

Techniquement, vous pouvez utiliser un modèle plus petit si vous utilisez le RL pour obtenir les mêmes performances qu'un plus grand. Concernant la réduction de la taille du cache KV, les gens sont passés de l'attention multi-têtes à des schémas plus efficaces comme l'attention par requête de groupe ou multi-requête. Cela aide à générer des jetons plus rapidement avec des tailles de lots plus importantes.

C'est important pour générer des jetons. Lors de la génération, vous êtes limité par la bande passante mémoire — la rapidité avec laquelle vous pouvez lire les clés et les valeurs du cache. L'attention multi-requête préserve les têtes de requête mais réduit les têtes de clé-valeur à une seule. La requête groupée les réduit mais moins agressivement. Les deux réduisent la taille du cache KV.

Et il y a MLA.

L'attention multi-latente transforme les clés et les valeurs en un seul vecteur latent qui est étendu au moment de l'inférence.

MLA vient de DeepSeek. L'idée est de conserver un vecteur partagé pour toutes les clés et valeurs et des vecteurs plus petits pour chaque jeton comme réduction de rang faible. On peut ré-étendre le vecteur latent bien plus efficacement.

Il y a une richesse à avoir des clés et des valeurs séparées appariées par paires plutôt que de les compresser en une seule.

Tout cela a trait au fait d'être limité par la mémoire.

Ouais.

Comment cela se traduit-il dans l'expérience utilisateur ?

On peut agrandir le cache parce qu'il y a moins d'espace alloué au cache KV. On obtient plus de succès de cache, ce qui réduit le temps jusqu'au premier jeton. De plus, on ne voit pas de ralentissement dans la génération de jetons lors du traitement de plusieurs requêtes.

Cela permet également d'agrandir votre prompt.

C'est sûr.

On peut augmenter la taille des lots ou la taille des prompts sans dégrader la latence.

Quelle est l'idée derrière le Shadow Workspace ?

Nous voulons qu'un calcul en arrière-plan aide les utilisateurs sur un horizon temporel plus long que la simple prédiction des prochaines lignes. En le faisant en arrière-plan, on peut consacrer plus de puissance de calcul. Un 'shadow workspace' (espace de travail fantôme) permet au modèle d'itérer et d'obtenir des retours du serveur de langage, qui vous informe sur les erreurs de type et la structure du code. Les serveurs de langage sont des extensions qui s'interfacent via un protocole avec VS Code.

Pour le linting ?

Pour le linting, l'accès aux définitions et l'affichage des types.

Il fait aussi la vérification de type ?

Oui, ce qui est nécessaire pour travailler sur de gros projets.

Comment est-ce utilisé à l'intérieur de Cursor ?

Nous montrons ces informations aux modèles d'IA d'une manière qui n'affecte pas l'utilisateur. Nous lançons une fenêtre Cursor cachée où les agents d'IA peuvent modifier le code, obtenir des retours des linters et itérer.

Tout faire tourner en arrière-plan.

Peut-être même exécuter le code.

C'est l'objectif. Il doit refléter l'environnement local de l'utilisateur. Sous Linux, on peut cloner le système de fichiers, mais sous Mac et Windows, c'est plus difficile.

Une idée est de maintenir un verrou sur la sauvegarde. Le modèle opère dans le shadow workspace en mémoire, et vous ne reprenez le verrou que si vous essayez d'exécuter du code ou de sauvegarder simultanément.

C'est un avenir passionnant que de laisser l'agent accomplir des tâches localement pendant que l'on revient observer le résultat.

Pour des changements plus importants qui prennent plus de temps, on voudra faire cela dans un environnement distant isolé qui reproduit l'environnement de l'utilisateur.

Quels agents voulez-vous pour le codage ? Recherche de bogues ? Nouvelles fonctionnalités ?

Je pense à l'automatisation de tâches comme le montage vidéo ou la mise en ligne sur YouTube via le code. Pour le codage, je pense à la recherche de bogues, y compris les bogues logiques et 'spirituels'.

Directions d'implémentation.

Misons tout sur la recherche de bogues.

Les modèles sont étonnamment mauvais pour trouver des bogues quand ils sont sollicités naïvement. Ils sont mal calibrés.

Même les modèles les plus intelligents.

Même O1.

Avez-vous une intuition du pourquoi ?

Ils sont le reflet du pré-entraînement. La génération de code et les questions-réponses existent en quantités massives sur GitHub et Stack Overflow, mais détecter de vrais bogues et proposer des correctifs est rare en ligne. Il faut un petit 'coup de pouce' pour que les modèles se généralisent à la détection de bogues.

Ils comprennent le code, mais susciter la détection de ce qui est 'louche' est difficile. Les humains sont calibrés sur les bogues qui importent. Un ingénieur senior sait si un bogue va faire tomber un serveur. Si un modèle devient agaçant pendant une expérience, c'est mal. Si vous écrivez une base de données, vous devez être paranoïaque. Obtenir ce calibrage est difficile.

Ouais.

Il est difficile pour les humains de comprendre quelle ligne de code est importante. Votre site Web dit que si le code peut faire beaucoup de dégâts, il faut ajouter un commentaire en majuscules.

Répété 10 fois.

C'est profond. Les ingénieurs passent à autre chose et oublient comment une seule fonction pourrait faire couler le Titanic.

Les modèles accorderont plus d'attention à ces commentaires et seront plus susceptibles de trouver des bogues dans ces régions.

Étiqueter le code par potentiel de dommages est une bonne pratique.

Certaines personnes pensent que c'est esthétiquement laid, mais c'est utile pour les modèles et cela prévient l'erreur humaine.

Les gens survolent souvent les docstrings ; vous devez signaler le danger pour qu'il ne passe pas inaperçu.

Il faut se voir rappeler les dommages potentiels.

Jusqu'à ce que nous ayons une vérification formelle pour tout, et que des preuves puissent confirmer que vous n'avez pas introduit de bogue.

À quoi ressemblerait cet avenir ?

Les gens n'écriront plus de tests. Le modèle suggérera une spécification, vous la réviserez, et un modèle intelligent calculera une preuve que l'implémentation suit la spécification.

Si l'intention est difficile à spécifier, il sera difficile de prouver qu'elle correspond à votre intention. La spécification est-elle difficile à générer ?

Peut-on réellement faire de la vérification formelle ? Comment savoir si la spécification correspond à votre intention ?

La spécification serait formelle.

Certaines choses ne sont pas facilement spécifiables dans un langage formel.

Peut-être que la vérification formelle n'est pas tout ce dont on a besoin.

Cela pourrait remplacer quelque chose comme les tests unitaires.

On peut faire évoluer les langages de spécification pour capturer davantage. Je pense que c'est passionnant.

Parlez-vous de bases de code entières ?

Les bases de code entières sont plus difficiles mais devraient être possibles. On peut vérifier formellement du code C à travers le compilateur jusqu'au matériel. Les grandes bases de code sont des systèmes multicouches, et si l'on peut décomposer et vérifier chaque partie, cela devrait fonctionner.

Comment gérez-vous les dépendances externes comme l'API Stripe ?

Stripe écrirait une spécification pour l'API.

Comment faites-vous pour une dépendance à un modèle de langage ?

On pourrait peut-être encore prouver cela.

Prouver quoi à propos des modèles de langage ?

Qu'un modèle de langage est aligné ou qu'il donne la bonne réponse. C'est le rêve.

Si c'est possible, cela aide à garantir que le code n'a pas de bogues et que l'IA ne détruit pas la civilisation. Si les modèles ont du mal à trouver des bogues, quel est l'espoir ?

Il devrait d'abord aider avec les bogues stupides comme les erreurs de type 'off-by-one' ou les décalages de commentaires. Finalement, il devrait détecter des bogues plus complexes.

Une bonne recherche de bogues est nécessaire pour que l'IA fasse plus de programmation. Vous devez vérifier le code de l'IA.

Il est plus facile d'introduire un bogue que d'en trouver un. On peut entraîner un modèle à introduire des bogues, puis entraîner un modèle inverse à les trouver en utilisant ces données synthétiques.

On peut donner aux modèles l'accès aux traces et aux débogueurs. Il existe différents formats : un modèle spécialisé rapide en arrière-plan, ou l'utilisation d'une tonne de calcul pour un problème spécifique en dépensant 50 $ pour le résoudre.

Je paierais une somme importante pour qu'un modèle trouve un bogue ou génère du code que j'apprécie. Cursor a généré des fonctions parfaites pour l'API YouTube récemment, et j'ai eu envie d'un bouton 'pourboire' pour envoyer 5 $ et un signal fort de bon travail. Est-ce quelque chose auquel vous pensez ?

C'est une idée controversée. J'adorerais que vous payiez 1 $ pour accepter une correction de bogue. L'inquiétude est que les gens fassent du copier-coller ou que l'introduction d'argent rende la chose moins amusante. Il serait peut-être plus logique d'avoir un forfait mensuel.

Une composante de pourboire pourrait être acceptable.

Les gens le font déjà en partageant des exemples fantastiques avec leurs amis.

Si nous pouvons vérifier qu'un bogue est corrigé via LSP ou en exécutant le code, un système de prime n'aurait pas besoin de reposer sur la confiance.

Quel est le degré d'interaction entre le terminal et le code ? Pouvez-vous faire une boucle où il exécute le code et suggère des changements s'il y a une erreur ?

Vous pouvez utiliser le contexte du terminal dans le chat et Command-K. Nous n'avons pas encore la partie boucle, mais c'est logique. Cela pourrait se passer au premier plan ou en arrière-plan.

L'arrière-plan est cool, mais comment protéger les bases de données d'être modifiées ?

On peut ajouter des branches à un journal de modifications ('write-ahead log') de base de données. Des entreprises de bases de données comme Turso vont ajouter le branchement, et les agents d'IA feront des tests par rapport à ces branches.

Il serait intéressant de pouvoir brancher le système de fichiers.

Tout a besoin de branchement.

Si on branche tout, c'est un multivers.

Il existe des algorithmes intelligents pour s'assurer de ne pas consommer trop d'espace ou de CPU.

Pourquoi avez-vous choisi AWS pour l'infrastructure ?

AWS est vraiment bon et vous savez que ça fonctionnera, même si la configuration est un enfer.

Pourquoi l'interface est-elle horrible ?

Parce qu'elle est tellement bonne qu'elle n'a pas besoin d'une meilleure interface.

La nature du vainqueur.

Exactement. S'il y a un problème, c'est probablement le vôtre.

Quels sont les défis du passage à l'échelle ?

Le passage à l'échelle est un voyage intéressant. On rencontre des problèmes avec la mise en cache et les bases de données à mesure qu'on grandit. Nous en sommes à un stade où nous avons des dépassements d'entiers sur les tables. Notre système de recherche pour l'indexation des bases de code a été délicat à mettre à l'échelle.

Il est difficile de prédire où les systèmes lâchent quand on passe à l'échelle. Nous découpons le code en morceaux ('chunking'), nous en faisons des plongements ('embeddings') et nous stockons ces plongements dans une base de données sans stocker le code lui-même. Un défi est de s'assurer que l'index local correspond à l'état du serveur. Nous gardons des hachages pour chaque fichier et dossier de manière récursive. Nous réconcilions le hachage racine du projet. S'il ne correspond pas, nous regardons les enfants jusqu'à trouver le désaccord. Pour la plupart des gens, les hachages correspondent.

Une réconciliation hiérarchique des hachages.

Oui, un arbre de Merkle.

C'est cool que vous deviez réfléchir à ces problèmes.

Le passage à l'échelle est devenu difficile car certains clients ont des bases de code massives. Construire la chose simple est facile, mais passer à l'échelle pour de nombreuses entreprises est un problème complexe.

L'intégration du code par plongement est le goulot d'étranglement en termes de coût. On ne veut pas ré-intégrer le même code pour chaque personne d'une entreprise. Nous avons un cache sur les vecteurs calculés à partir du hachage d'un morceau. Quand la n-ième personne d'une entreprise intègre sa base de code, c'est très rapide. Nous ne stockons pas de code sur nos serveurs, seulement des vecteurs.

Quel est l'avantage d'indexer la base de code ?

On peut trouver où quelque chose se passe dans une grande base de code en utilisant une mémoire floue. Quand vous posez une question au chat avec le contexte de la base de code, il trouve souvent le bon endroit.

À l'avenir, la recherche sera encore plus puissante. Le plafond est bien plus élevé que ce que les gens pensent.

Avez-vous envisagé de faire les plongements localement ?

Nous y avons pensé, mais c'est difficile. La plupart de nos utilisateurs sont sur des machines Windows qui ne sont pas très puissantes. Les modèles locaux ne fonctionnent réellement que sur les ordinateurs les plus récents. À mesure que les modèles grossissent, il devient encore plus difficile de le faire localement.

Ce n'est pas seulement un problème pour les ordinateurs faibles. Il est difficile de traiter les bases de code des grandes entreprises, même sur les MacBook Pro les plus costauds. Vous auriez une expérience horrible.

La recherche des plus proches voisins sur une base de code massive consomme de la mémoire et du CPU. La modélisation s'oriente vers les MOE qui sont limités par la bande passante mémoire, mais ces modèles sont plus gros et ne tiendront pas sur un seul nœud. Les gens voudront toujours les modèles les plus intelligents et performants, qui sont difficiles à faire tourner localement.

Vous voulez Sonnet et O1.

J'aime la façon dont vous me vendez le truc.

Il existe une alternative aux modèles locaux : le chiffrement homomorphe. On chiffre l'entrée localement, le serveur fait tourner les modèles sur les données chiffrées sans les voir, et on déchiffre la réponse. C'est encore au stade de la recherche, mais ce serait percutant. De plus en plus d'informations mondiales passeront par des acteurs centralisés, ce qui crée un risque de surveillance. J'ai bon espoir que nous puissions résoudre cela.

L'apprentissage automatique préservant la vie privée est un défi pour tous les logiciels. Nous comptons sur le cloud pour les fonctionnalités, mais cela signifie que les données sont centralisées et pourraient être infiltrées.

Anthropic a une politique de mise à l'échelle responsable, mais à mesure que nous arrivons à des modèles puissants, la sécurité nécessitera de surveiller les prompts. Il serait horrible que toutes les informations du monde soient surveillées aussi lourdement. C'est trop centralisé.

Pourquoi est-ce différent des fournisseurs de cloud ?

Il s'agit de données personnelles que vous n'auriez jamais mises en ligne. Les acteurs centralisés voient le texte en clair de tout.

Est-il difficile de déterminer automatiquement le contexte ?

C'est délicat. Nous pourrons faire mieux à l'avenir.

Il y a des compromis. Inclure plus de contexte rend les modèles plus lents et plus coûteux.

Les modèles s'embrouillent aussi s'il y a trop d'informations dans le prompt. La précision et la pertinence doivent être élevées.

Nous faisons un peu de contexte automatique maintenant et voulons l'améliorer avec une meilleure recherche, des modèles de plongement et des reclasseurs.

Le domaine est aux prises avec la façon de faire comprendre à un modèle de langage un nouveau corpus d'informations.

Peut-on rendre les fenêtres de contexte infinies et faire en sorte que le modèle y prête attention ? Peut-on ensuite mettre en cache ce contexte ?

Il y a des idées sur l'apprentissage des informations dans les poids du modèle via le réglage fin ('fine-tuning'). Cela pourrait fournir un type de compréhension différent de l'apprentissage en contexte.

Le débat reste ouvert, mais nous sommes enthousiasmés par de meilleurs systèmes de recherche sélectionnant les parties les plus pertinentes d'une base de code.

VS Code est public, donc les modèles frontières ont vu tout le code lors du pré-entraînement.

Ils ont été affinés pour répondre à des questions sur le code, donc ils font un travail correct avec les questions sur VS Code.

Et si vous entraîniez spécifiquement un modèle après coup pour comprendre une base de code ?

C'est une question de recherche ouverte. Voulez-vous que le modèle fasse la recherche en interne, ou séparer la recherche du modèle frontière ?

On voudra entraîner un bon modèle open-source pour être le chercheur qui fournit le contexte aux modèles plus grands.

Pouvez-vous en dire plus sur le post-entraînement d'un modèle pour comprendre une base de code ? Est-ce une direction de données synthétiques ?

Il existe de nombreuses façons possibles ; il s'agit d'être empirique.

Une chose naïve est le pré-entraînement continu qui inclut les données du dépôt.

Dans l'affinage par instructions, on injecterait des questions sur le code de ce dépôt.

On pourrait utiliser des données synthétiques où le modèle propose des questions pour des morceaux de code afin de débloquer sa capacité à répondre aux questions sur cette base de code.

Quel est le rôle des systèmes de calcul au moment du test comme OpenAI O1 dans la programmation ?

Le calcul au moment du test ('test-time compute') est intéressant. L'augmentation de la taille des données et des modèles a amélioré les performances, mais nous atteignons un mur de données.

Augmenter le calcul au moment du test accroît les FLOP au moment de l'inférence pour obtenir des améliorations de performance correspondantes.

On pourrait utiliser un modèle de même taille et le faire tourner plus longtemps pour obtenir la qualité d'un modèle beaucoup plus grand.

Certains problèmes nécessitent une intelligence massive mais ne représentent qu'une petite fraction des requêtes.

Entraîner un modèle massif pour des requêtes peu fréquentes est un gaspillage. Au lieu de cela, on a un modèle qui gère la plupart des requêtes et qui tourne plus longtemps pour ceux qui veulent une intelligence maximale.

Comment déterminez-vous dynamiquement quel modèle utiliser ?

C'est un problème de recherche ouvert. Nous avons des implémentations initiales pour Cursor Tab.

Passer de GPT-4o-mini à O1 est délicat. On ne sait pas quel niveau d'intelligence est nécessaire pour déterminer si une chose est trop difficile.

Le calcul au moment du test apporte-t-il les gains les plus importants ?

Le calcul au moment du test nécessite une stratégie d'entraînement spécifique. Personne en dehors des grands laboratoires ne sait exactement comment cela fonctionne.

Peut-être qu'ils font une recherche arborescente utilisant des modèles de récompense de processus.

Je le placerais dans le post-entraînement, mais le calcul dépensé pour le temps de test pourrait un jour éclipser le pré-entraînement.

Donc on ne sait pas comment fonctionne O1.

C'est amusant de spéculer.

Si vous deviez construire un modèle concurrent, que feriez-vous ?

Il faut entraîner un modèle de récompense de processus ('process reward model').

Les modèles de récompense de résultat attribuent une note à un résultat final.

Les modèles de récompense de processus notent la chaîne de pensée. OpenAI a utilisé des étiqueteurs humains pour noter des centaines de milliers de chaînes de pensée.

Les gens utilisent des modèles de récompense de processus pour choisir parmi un ensemble d'échantillons.

On échantillonne les sorties et on utilise le modèle de récompense pour choisir la meilleure.

Si on peut noter chaque étape de la chaîne de pensée, on peut faire une recherche arborescente et explorer plusieurs branches.

Quand la qualité de la branche est corrélée à la qualité du résultat.

Le défi est d'entraîner ces modèles de récompense de manière automatisée.

Je n'ai rien vu qui fonctionne vraiment bien pour l'utilisation de modèles de récompense de processus pour la recherche arborescente dans le code.

OpenAI cache la chaîne de pensée pour éviter la manipulation et la distillation. Qu'en pensez-vous ?

C'est spéculatif, mais ils pourraient vouloir rendre difficile la distillation des capacités.

Voir les étapes faciliterait la réplication de la technologie.

On pourrait s'entraîner là-dessus.

Certaines API ont supprimé l'accès aux probabilités logarithmiques, probablement pour la même raison.

Les probabilités logarithmiques donnent plus d'informations pour distiller les capacités dans des modèles que vous contrôlez.

Nous apprenons encore à utiliser O1.

Nous l'avons rendu disponible dans Cursor, mais il ne fait pas encore partie de l'expérience par défaut.

Nous n'avons pas trouvé de moyen de l'intégrer qui nous donne envie d'y recourir à chaque instant.

Cela pourrait faciliter l'exécution d'agents en arrière-plan.

Nous découvrons encore les cas d'utilisation.

Il présente des limitations importantes, comme l'absence de streaming, ce qui est pénible pour superviser la sortie.

On a l'impression d'être aux prémices du calcul au moment du test.

GitHub Copilot intègre O1. Cela signifie-t-il que Cursor est fini ?

Est-il temps de fermer Cursor ?

Le plafond ici est incroyablement élevé. Le meilleur produit dans quatre ans sera bien plus utile que le meilleur produit d'aujourd'hui.

Si vous arrêtez d'innover sur le produit, vous perdrez.

Les startups peuvent gagner en construisant quelque chose de meilleur.

Tout revient au moteur de modélisation et à l'expérience d'édition.

La valeur de Cursor vient des modèles personnalisés et d'une UX réfléchie.

Parlez-moi de votre taxonomie des données synthétiques.

Ah oui.

Expliquez.

Il existe trois types de données synthétiques. Le premier est la distillation : faire en sorte qu'un modèle produise des jetons pour entraîner un modèle moins performant.

Cela ne créera pas un modèle plus performant, mais cela distille les capacités dans un modèle plus petit et spécifique à une tâche.

Le deuxième est lorsqu'une direction d'un problème est plus facile que l'inverse, comme la détection de bogues.

On peut demander à un modèle d'introduire des bogues dans le code, puis entraîner un modèle à les détecter.

Le troisième est la production de texte qui peut être vérifié facilement.

C'est courant pour les maths et le code avec des problèmes de type LeetCode où l'on a des tests.

Si quelque chose passe les tests, c'est que le problème est résolu. On entraîne le modèle sur les sorties qui ont réussi.

Les vérificateurs parfaits sont difficiles à réaliser pour des tâches ouvertes ou à long horizon.

Cette troisième catégorie nécessite d'avoir un vérificateur.

La vérification est optimale lorsqu'on utilise des tests ou des systèmes formels.

Contrôle de qualité manuel.

Cette catégorie entraîne des gains massifs.

Qu'en est-il de RLHF par rapport à RLAIF ?

Le RLHF, c'est quand un modèle de récompense est entraîné à partir de retours humains.

Le RLAIF repose sur le fait que la vérification est plus facile que la génération.

Si un modèle a plus de facilité à vérifier une solution qu'à la générer, on peut obtenir une boucle récursive.

Nous utilisons un mélange de RLAIF et de RLHF pour Cursor Tab.

Le modèle réussit à choisir la meilleure de deux générations, aligné par l'intervention humaine.

Le classement est-il bien plus facile que la génération ?

Il devrait l'être si l'on croit que P n'est pas égal à NP.

Peut-être que la même chose prouvera que P est égal à NP.

Ce serait cool.

Médaille Fields.

Qui en reçoit le crédit ?

Quand une IA obtiendra-t-elle la médaille Fields ?

La spécialité d'Aman.

Prix Nobel ou médaille Fields en premier ?

Médaille Fields.

Zéro.

C'est un système isolé.

Nous ne savons pas à quel point nous sommes proches de résoudre ces problèmes difficiles.

Donc la médaille Fields en premier.

Je pense que c'est plus probable. Les problèmes mathématiques difficiles comme l'hypothèse de Riemann sont juste vraiment complexes.

On ne sait pas à quoi ressemble le chemin vers une solution.

C'est un système isolé pour lequel on peut s'entraîner.

On pourrait obtenir une médaille Fields avant l'AGI.

Peut-être en 2028 ou 2030 ?

D'accord. Parlons des lois d'échelle.

Que sont-elles et vers quoi se dirige-t-on ?

L'article d'OpenAI était légèrement erroné concernant les programmes de taux d'apprentissage. Chinchilla en a montré une version plus correcte.

Les gens optimisent maintenant pour le travail étant donné un budget d'inférence.

Il y a plus de dimensions à ces courbes que le calcul, les paramètres et les données.

Le calcul d'inférence et la longueur du contexte sont des dimensions. Les SSM sont plus rapides sur les contextes longs.

Cela vaut la peine de dépenser 10 fois plus de calcul pour l'entraînement si l'on se soucie du budget d'inférence.

Donc plus c'est grand, mieux c'est ?

Plus c'est grand, mieux c'est pour l'intelligence brute.

Je suis optimiste quant à la distillation.

Les modèles Llama ont sur-entraîné des modèles 7B. Gemma a minimisé la divergence KL avec la version 27B.

La distillation donne plus de signal à partir des données et aide à surmonter le mur des données.

Plus petit signifie plus rapide.

La distillation permet d'obtenir plus de signal par jeton pour un modèle plus petit.

Comment alloueriez-vous dix mille milliards de dollars pour améliorer l'intelligence ?

Il y a des secrets pour l'entraînement que je ne connais pas.

Je les gaspillerais.

Si vous aviez le savoir-faire.

On essaierait d'obtenir autant de puissance de calcul que possible pour acheter des GPU.

Sommes-nous limités par le calcul ou par les idées ?

Je crois que nous sommes limités par les idées.

Si vous avez du calcul, vous pouvez faire des expériences.

Je le ferais, mais nous sommes limités par nos idées et notre ingénierie.

Il faut de l'ingénierie pour saturer les performances des GPU.

On prend les fruits à portée de main et on passe à l'échelle.

Rien ne sert d'expérimenter si le passage à l'échelle fonctionne.

Nous pensons que de nouvelles idées sont nécessaires pour l'AGI.

Il est difficile pour les laboratoires de consacrer de l'ingénierie à l'exploration de nouvelles idées.

Comment la programmation change-t-elle au cours des dix prochaines années ?

Nous sommes enthousiasmés par un avenir où le programmeur a le contrôle.

Certains pensent qu'on parlera simplement à son ordinateur comme à un département d'ingénierie.

Cela ne nous emballe pas car on abandonne le contrôle et il est plus difficile d'être spécifique.

L'ingénierie implique des micro-décisions et des compromis.

Nous voulons que les humains soient aux commandes.

On pourrait contrôler le niveau d'abstraction, comme éditer du pseudo-code qui modifie le code formel.

De haut en bas de la pile.

Ces principes de contrôle et de vitesse sont importants.

La compétence de programmation va-t-elle changer ?

C'est une période passionnante pour construire des logiciels. Programmer aujourd'hui est bien plus amusant qu'en 2012.

Les idées créatives seront amplifiées, et il y aura moins d'édition de texte répétitive.

Je suis ravi de pouvoir effectuer de grandes migrations rapidement.

Je préfère entrer dans le code et m'y atteler directement.

Le design se fera-t-il en langage naturel ?

Les meilleurs programmeurs sont ceux qui adorent absolument programmer.

Cette personne adore Cursor Tab.

Quand vous appuyez sur Tab, vous injectez votre intention.

La communication avec l'ordinateur gagne en bande passante.

Votre manifeste dit que vous construisez l'ingénieur du futur.

Merci d'avoir discuté aujourd'hui.

Merci.

Merci de nous avoir reçus.

Merci d'avoir écouté cette conversation.