Fondateur de Cursor : À l'ère post-code, le « goût » deviendra de plus en plus précieux
TechFlow SélectionTechFlow Sélection
Fondateur de Cursor : À l'ère post-code, le « goût » deviendra de plus en plus précieux
L'objectif de Cursor est de créer une toute nouvelle manière de programmer.
Dédié à des analyses Web3 approfondiesAuteur : Xin
En tant que l'un des produits à la croissance la plus rapide de l'histoire, Cursor a atteint un chiffre d'affaires annuel récurrent (ARR) de 100 millions de dollars seulement 20 mois après son lancement. Deux ans plus tard, il a dépassé les 300 millions de dollars de ARR, continuant à transformer la manière dont les ingénieurs et les équipes produits développent des logiciels. Au début 2025, Cursor comptait plus de 360 000 utilisateurs payants.
Michael Truell est cofondateur et PDG d'Anysphere, la société mère de Cursor. Il a fondé Anysphere avec trois camarades du MIT et a lancé Cursor en seulement trois mois. Michael Truell accorde très rarement des interviews podcast ; auparavant, il n'était apparu que sur le Lex Fridman Podcast. Dans cet épisode, il partage ses prévisions sur l'ère « post-code », les expériences contre-intuitives vécues lors du développement de Cursor, ainsi que sa vision de l'avenir des ingénieurs.
Cet épisode provient du podcast de Lenny. Voici la transcription complète.
- L’objectif de Cursor est de créer une nouvelle façon de programmer : À l'avenir, les gens verront davantage du pseudo-code proche des phrases anglaises. Les individus auront un contrôle total sur tous les détails logiciels, avec la capacité de modifier et itérer extrêmement rapidement.
- Le « goût » (taste) deviendra de plus en plus précieux : Le cœur du « goût » réside dans une claire compréhension de « ce qu’il faut construire ».
- Les meilleurs utilisateurs d’IA sont techniquement conservateurs : Ils excellent à limiter avec précision et rigueur la portée des tâches confiées à l’IA.
- L’étape centrale du recrutement chez Cursor est une évaluation de deux jours : Ces projets sont simulés mais permettent aux candidats de produire de véritables résultats en deux jours. Cela sert non seulement à évaluer la compatibilité professionnelle, mais joue également un rôle crucial dans l'attraction des talents. Pour les jeunes entreprises, l'équipe elle-même est souvent le seul levier capable de motiver quelqu’un à les rejoindre.
Le principal problème de la programmation par chatbot est le manque de précision
Lenny : Nous avons déjà parlé de ce qui pourrait arriver à l'ère post-code. Comment vois-tu l'évolution future de Cursor ? Comment la technologie passera-t-elle du code traditionnel à d'autres formes ?
Michael Truell :L’objectif de Cursor est de créer une toute nouvelle façon de programmer, une méthode radicalement différente de construction de logiciels. Vous décrivez simplement votre intention à l'ordinateur de la manière la plus concise possible, définissant vous-même comment le logiciel doit fonctionner et apparaître.
Avec la maturité croissante des technologies actuelles, nous pensons pouvoir inaugurer une nouvelle méthode de création logicielle, plus avancée, efficace et facile à utiliser que ce qu'elle est aujourd'hui. Ce processus sera très différent de la manière actuelle d'écrire des logiciels.
Je souhaite le comparer à plusieurs visions dominantes de la forme future des logiciels, dont certaines populaires que nous ne partageons pas.
L'une pense que la construction logicielle restera très similaire à aujourd'hui, principalement basée sur des langages de programmation formels comme TypeScript, Go, C ou Rust, via l'édition de texte. Une autre suppose que vous n'avez qu'à entrer des instructions dans un chatbot pour qu'il crée le logiciel pour vous, puis le modifie à tout moment. Ce style chatbot ressemble à une conversation avec votre département technique.
Nous pensons que ces deux visions ont des problèmes.
Le principal problème de la programmation par chatbot est le manque de précision. Si vous voulez que les gens contrôlent totalement l'apparence et les fonctionnalités d'un logiciel, vous devez fournir des moyens plus précis d'indiquer les modifications souhaitées, plutôt que de dire à un robot dans une fenêtre de chat « change cette partie de mon application », pour finir par tout supprimer.
D'autre part, l'idée que tout reste inchangé est aussi fausse, car la technologie ne cessera de devenir plus puissante.Dans le monde « post-code » que nous imaginons, l'expression de la logique logicielle ressemblera davantage à l'anglais.
Vous pouvez l'imaginer sous une forme plus normalisée, évoluant vers du pseudo-code. Vous pourrez écrire la logique logicielle, l'éditer à un niveau élevé et la parcourir facilement. Ce ne seront plus des millions de lignes obscures, incompréhensibles. Au contraire, cela sera plus clair, plus facile à comprendre et à localiser. Nous travaillons à faire évoluer les structures symboliques complexes et le code vers des formes plus lisibles et modifiables par les humains.
À l’ère post-code, le goût aura de plus en plus de valeur
Lenny : C’est profond. Je veux m'assurer que tout le monde comprenne bien ton point de vue. Le changement que tu imagines est que les gens ne verront plus jamais de code ni n'auront besoin de penser en JavaScript ou Python. À la place, ils utiliseront une forme d'expression plus abstraite, du pseudo-code proche des phrases anglaises.
Michael Truell : Nous pensons qu’il évoluera vers ce stade. Nous croyons que cela nécessitera la participation et l’impulsion des ingénieurs experts actuels. À l'avenir, l'humain restera au volant, en position de contrôle.
Les personnes garderont un fort contrôle sur tous les détails logiciels et ne renonceront pas facilement à ce contrôle. Elles auront aussi la capacité de modifier et itérer extrêmement rapidement. À l'avenir, on ne dépendra plus d'ingénierie lente, effectuée en arrière-plan, prenant des semaines pour se concrétiser.
Lenny : Cela soulève une question : pour les ingénieurs actuels, ou ceux envisageant de devenir ingénieurs, designers ou chefs de produit, quelles compétences deviendront de plus en plus précieuses à l’ère « post-code » ?
Michael Truell : Je pense que le « goût » (taste) deviendra de plus en plus précieux. Quand les gens parlent de goût dans le domaine logiciel, ils pensent souvent à l'esthétique : animations fluides, couleurs, interface utilisateur (UI), expérience utilisateur (UX), etc.
L’esthétique est très importante pour un produit. Mais comme mentionné précédemment, je pense que l’autre moitié cruciale réside dans la logique du produit et son fonctionnement.
Nous disposons de nombreux outils pour concevoir l’esthétique, mais le code reste encore la meilleure expression de la logique logicielle. Vous pouvez utiliser Figma pour montrer l’apparence ou esquisser grossièrement dans des notes. Mais seule une maquette réellement utilisable rend la logique clairement visible.
À l'avenir, les ingénieurs ressembleront de plus en plus à des « concepteurs logiques ». Ils devront exprimer précisément leurs intentions, passant du « comment faire » en coulisses au haut niveau du « quoi faire » et du « qu’est-ce que c’est ». Cela signifie que le « goût » deviendra plus important dans le développement logiciel.
Pour l'instant, nous ne sommes pas encore arrivés là dans l'ingénierie logicielle. Internet regorge de mèmes amusants et provocateurs reflétant une dépendance excessive à l'IA dans le développement, entraînant des défauts évidents et des problèmes fonctionnels.
Mais je crois que les futurs ingénieurs logiciels n'auront pas besoin d'accorder autant d'attention qu'aujourd'hui aux détails techniques. Nous passerons progressivement d'une rigueur méticuleuse à un accent accru sur le « goût ».
Lenny : Cela me fait penser au « vibe coding ». Est-ce similaire à ce mode de programmation où l’on ne se soucie plus des détails, mais suit plutôt l’intuition ?
Michael Truell : Je pense qu’il y a un lien. Le « vibe coding » dont les gens parlent actuellement décrit selon moi un mode de création controversé : générer massivement du code sans vraiment en comprendre les détails. Ce mode pose de nombreux problèmes. Sans comprendre les détails sous-jacents, vous finirez vite par créer quelque chose de trop volumineux et difficile à modifier.
En réalité, ce qui nous intéresse, c’est :comment une personne peut-elle parfaitement contrôler tous les détails sans pleinement comprendre le code sous-jacent. Cette solution est étroitement liée au « vibe coding ».
Nous manquons encore de la capacité à laisser le « goût » dominer véritablement la construction logicielle. Un problème du « vibe coding » ou de modes similaires est que, bien que vous puissiez créer quelque chose, beaucoup de décisions maladroites sont prises par l’IA, et vous ne pouvez pas les contrôler complètement.
Lenny : Tu as mentionné le « goût ». Que signifie exactement ce terme ?
Michael Truell : Avoir une idée claire de « ce qu’il faut construire ». Cette idée devrait aussi être de plus en plus facile à traduire : voilà ce que vous voulez créer, voilà à quoi cela ressemble, voilà comment cela fonctionne.
Contrairement à aujourd’hui, où vous avez une idée produit avec votre équipe, puis avez besoin d’une couche de traduction, faisant d’immenses efforts pour la convertir en un format que l’ordinateur peut comprendre et exécuter.
Le « goût » n’a pas grand-chose à voir avec l’interface utilisateur. Peut-être que le mot « goût » n’est pas parfait, mais son essence est une bonne compréhension de « ce qu’il faut construire ».
La naissance de Cursor découle de l’exploration d’une question
Lenny : Je voudrais revenir aux origines de Cursor. Beaucoup d’auditeurs ignorent probablement comment il est né. Vous construisez l’un des produits à la croissance la plus rapide de l’histoire. Cursor transforme profondément la manière dont les gens créent des produits, voire bouleverse tout un secteur. Par où tout cela a-t-il commencé ? Quels ont été les moments marquants du développement initial ?
Michael Truell : La naissance de Cursor découle de notre exploration d’une question, et dans une large mesure, de notre réflexion sur la manière dont l’IA évoluera au cours des dix prochaines années. Deux moments clés ont marqué cela.
Le premier fut le test bêta initial de Copilot. Ce fut notre première rencontre avec un produit IA utile, apportant une aide concrète, pas juste une démo tape-à-l’œil. Copilot est devenu l’un des outils de développement les plus précieux que nous ayons jamais utilisés, ce qui nous a beaucoup enthousiasmés.
L’autre fut la publication par OpenAI et d’autres entreprises d’une série d’articles sur la mise à l’échelle des modèles. Ces études montrent que même sans idées révolutionnaires, en augmentant simplement la taille des modèles et la quantité de données d’entraînement, les capacités de l’IA deviennent de plus en plus fortes. Fin 2021 et début 2022, nous avons acquis une grande confiance dans l’avenir des produits IA, sachant que cette technologie était destinée à mûrir.
Quand nous regardons autour de nous, nous constatons que beaucoup parlent de la création de modèles, mais peu s’immergent profondément dans un domaine spécifique du travail intellectuel pour réfléchir à la manière dont il progressera grâce à l’avancement de l’IA.
Cela nous a amenés à nous demander : lorsque cette technologie mûrira, comment ce domaine spécifique changera-t-il ? Quelle sera la forme finale du travail ? Comment les outils que nous utilisons évolueront-ils ? À quel niveau les modèles doivent-ils atteindre pour soutenir ces changements ? Une fois que la mise à l’échelle et l’entraînement préalable des modèles ne pourront plus progresser, comment continuerons-nous à repousser les limites de la technologie ?
Cursor a commis une erreur initiale : nous avons d’abord choisi un domaine peu concurrentiel mais assez ennuyeux. Personne ne s’intéressait à ce genre de domaines ennuyeux.
Tout le monde pensait que la programmation était populaire et intéressante, mais nous pensions qu’il y avait déjà trop de monde.
Pendant quatre mois, nous avons en fait travaillé sur un projet complètement différent — automatiser et améliorer l’ingénierie mécanique, en créant des outils pour les ingénieurs mécaniques.
Mais nous avons rencontré des problèmes dès le départ : ni moi ni mes cofondateurs ne sommes ingénieurs mécaniques. Bien que certains amis soient dans ce domaine, nous étions extrêmement étrangers à ce milieu, presque comme des aveugles touchant un éléphant. Par exemple, comment appliquer réellement les modèles existants à l’ingénierie mécanique ? Notre conclusion alors était qu’il fallait développer nos propres modèles depuis zéro. C’était très délicat, car il existe presque aucune donnée publique sur les modèles 3D des outils et pièces ainsi que leurs étapes de construction, et il était aussi difficile d’obtenir ces modèles auprès de sources possédant ces ressources.
Mais finalement, nous avons pris conscience que nous n’étions pas passionnés par l’ingénierie mécanique, ce n’était pas quelque chose auquel nous voulions consacrer notre vie.
En revanche, en observant le domaine de la programmation, malgré un certain temps écoulé, il n’avait pas changé significativement. Ceux qui y travaillaient semblaient déconnectés de nos idées, manquant d’ambition et de vision sur l’avenir et la manière dont l’IA redessinerait tout. Ce constat nous a poussés à emprunter la voie de la création de Cursor.
Lenny : J’aime beaucoup ce conseil, comme aller vers des industries apparemment ennuyeuses parce qu’elles sont peu concurrentielles et offrent des opportunités, ce qui fonctionne parfois. Mais j’aime encore plus une autre approche — oser viser les domaines les plus populaires et convoités, comme la programmation IA et le développement d’applications, ce qui s’est également révélé efficace.
Vous sentiez que les outils existants manquaient d’ambition ou de potentiel, qu’il restait beaucoup à faire. Je pense que c’est une révélation très précieuse. Même si un domaine semble déjà trop tardif, avec des produits comme GitHub Copilot déjà présents, si vous trouvez que les solutions existantes manquent d’ambition, ne répondent pas à vos standards ou présentent des défauts méthodologiques, d’immenses opportunités subsistent. Est-ce bien cela ?
Michael Truell : Tout à fait d’accord. Pour réaliser des progrès révolutionnaires, il faut trouver des choses concrètes à faire.L’attrait de l’IA réside justement dans le fait que, y compris dans la programmation IA, d’immenses espaces inconnus persistent.
Le plafond est très haut dans de nombreux domaines. En regardant autour, même en prenant l’outil le meilleur de n’importe quel domaine, d’énormes travaux restent à accomplir dans les prochaines années. Posséder un tel espace vaste et un plafond si élevé est assez unique dans le développement logiciel, du moins pour l’IA.
Cursor a toujours insisté sur le Dogfooding dès le départ
Lenny : Revenons à la question des environnements de développement intégrés (IDE). Vous avez plusieurs orientations différentes, d’autres entreprises essaient aussi.
L’une consiste à construire un IDE pour ingénieurs et y intégrer des capacités IA. Une autre est le modèle complet d’agent IA, comme Devin. Et la troisième consiste à se concentrer sur la création d’un modèle excellent en codage, visant à développer le meilleur modèle de codage.
Qu’est-ce qui vous a finalement convaincus que l’IDE était la meilleure voie ?
Michael Truell : Ceux qui se concentrent uniquement sur le développement de modèles dès le départ, ou tentent d’automatiser entièrement la programmation, cherchent à construire quelque chose de fondamentalement différent de nous.
Nous nous concentrons davantage sur le fait de garantir que les utilisateurs puissent contrôler toutes les décisions prises par leurs outils. Eux, en revanche, imaginent davantage un avenir où l’IA accomplit tout le processus, voire prend toutes les décisions.
D’un côté, notre choix inclut un élément d’intérêt personnel. D’un autre côté, nous essayons toujours d’adopter une perspective très réaliste du niveau technologique actuel. Nous sommes extrêmement enthousiastes face au potentiel de l’IA pour les décennies à venir, mais parfois, les gens, voyant l’IA briller dans un domaine, ont tendance à anthropomorphiser ces modèles, pensant qu’ils sont plus intelligents que les humains ici, donc sûrement excellents ailleurs aussi.
Mais ces modèles ont d’énormes problèmes. Notre développement produit insiste dès le départ sur le « Dogfooding » (utilisation interne de ses propres produits) : nous utilisons quotidiennement Cursor, et nous ne voulons jamais publier une fonctionnalité inutile pour nous-mêmes.
Être nous-mêmes utilisateurs finaux nous donne une perception réaliste du niveau technologique actuel. Nous pensons qu’il est crucial que l’humain reste au « volant », l’IA ne pouvant pas tout gérer.
Personnellement, nous voulons aussi donner ce contrôle aux utilisateurs. Ainsi, nous ne sommes pas juste une entreprise de modèles, et nous évitons l’approche de développement de produits bout-en-bout qui prive les gens de leur contrôle.
Quant à notre choix de construire un IDE plutôt qu’un plugin pour des environnements de programmation existants, c’est parce que nous sommes convaincus que la programmation se fera via ces modèles, et que les méthodes de programmation changeront énormément dans les prochaines années. L’extensibilité des environnements de programmation actuels est tellement limitée que, si vous pensez que l’interface utilisateur et les modes de programmation vont changer radicalement, vous devez avoir un contrôle total sur l’ensemble de l’application.
Lenny : Je sais que vous travaillez actuellement sur un IDE, peut-être est-ce votre parti pris, ce que vous pensez être la direction future. Mais je me demande, pensez-vous qu’à l’avenir, une grande partie du travail sera effectuée par des ingénieurs IA dans des outils comme Slack ? Cette approche serait-elle un jour intégrée à Cursor ?
Michael Truell : Je pense que l’état idéal est de pouvoir basculer facilement entre ces options. Parfois, vous voudrez laisser l’IA fonctionner indépendamment pendant un moment ; parfois, vous voudrez extraire le travail de l’IA et collaborer efficacement avec elle. Parfois, peut-être la relancer en autonomie.
Je pense qu’il vous faut un environnement unifié où ces formes avant-plan et arrière-plan fonctionnent bien. Pour le fonctionnement en arrière-plan, les tâches de programmation particulièrement adaptées sont celles où les exigences peuvent être précisées avec très peu d’indications et les critères de réussite clairement définis. Corriger un bug en est un bon exemple, mais ce n’est absolument pas tout le travail de programmation.
L’essence de l’IDE changera radicalement avec le temps. Nous choisissons de construire notre propre éditeur précisément parce qu’il continuera d’évoluer. Cette évolution inclut la possibilité de prendre en charge des tâches provenant de différentes interfaces, comme Slack ou les systèmes de suivi des problèmes ; l’écran de verre que vous fixez quotidiennement changera lui aussi radicalement. Actuellement, nous voyons l’IDE comme l’endroit où l’on construit des logiciels.
Les utilisateurs les plus performants de l’IA sont techniquement conservateurs
Lenny : Je pense que lorsque les gens discutent des agents et de ces ingénieurs IA, ils ne réalisent pas suffisamment que nous deviendrons largement des « chefs de projet », supervisant de nombreux subordonnés encore peu intelligents, devant passer beaucoup de temps à réviser, approuver et préciser les besoins. Qu’en penses-tu ? Existe-t-il des moyens de simplifier ce processus ?
Car cela semble vraiment difficile. Toute personne ayant dirigé une grande équipe sait bien cela : « Ces subordonnés reviennent constamment vers moi avec des travaux de qualité inégale, c’est épuisant. »
Michael Truell : Oui, peut-être finirons-nous par devoir avoir des communications individuelles avec chacun de ces agents.
Nous observons que les utilisateurs les plus performants de l’IA sont techniquement conservateurs. Je pense vraiment que les utilisateurs actuellement les plus performants dépendent fortement de fonctions comme notre « prédiction de l’édition suivante (Next Edit Prediction) ». Dans leur flux de programmation habituel, notre IA prédit intelligemment la prochaine action à effectuer. Ils excellent aussi à limiter strictement la portée des tâches confiées à l’IA, en les rendant plus petites et plus précises.
Compte tenu du coût en temps passé à réviser le code, la collaboration avec un agent comporte deux modes principaux. L’un consiste à passer beaucoup de temps au départ pour détailler les instructions, laisser l’IA travailler seule, puis réviser ses résultats. Une fois la révision terminée, la tâche est achevée.
L’autre consiste à découper la tâche en morceaux plus fins. Spécifier une petite partie à la fois, laisser l’IA la terminer, puis réviser ; donner ensuite une instruction supplémentaire, laisser l’IA continuer, puis réviser à nouveau. C’est comme implémenter une fonction de complétion automatique tout au long du processus.
Néanmoins, nous observons fréquemment que les utilisateurs les plus habiles avec ces outils ont encore tendance à décomposer les tâches et à les garder gérables.
Lenny : C’est rare. Je voudrais revenir à votre première construction de Cursor. Quand avez-vous réalisé qu’il était prêt ? Quand avez-vous senti qu’il était temps de le publier pour voir ce qui allait se passer ?
Michael Truell : Au début du développement de Cursor, nous craignions de passer trop de temps à développer sans jamais le publier. La version initiale de Cursor a été entièrement fabriquée à la main par nous-mêmes. Aujourd’hui, nous utilisons VS Code comme base, tout comme de nombreux navigateurs utilisent Chromium comme noyau.
Mais ce n’était pas le cas au début. Nous avons développé le prototype de Cursor depuis zéro, ce qui a représenté un travail considérable. Nous avons dû développer nous-mêmes de nombreuses fonctionnalités nécessaires à un éditeur de code moderne, comme le support de plusieurs langages de programmation, la navigation entre le code, le suivi des erreurs, etc. De plus, nous avions besoin d’une ligne de commande intégrée, ainsi que la capacité de se connecter à un serveur distant pour visualiser et exécuter le code.
Nous avons développé à une vitesse fulgurante, construisant entièrement notre propre éditeur depuis zéro, tout en développant simultanément le composant IA. Environ cinq semaines plus tard, nous commencions déjà à utiliser entièrement notre propre éditeur, abandonnant complètement nos anciens éditeurs pour adopter activement le nouvel outil. Quand nous avons jugé qu’il atteignait un certain niveau d’utilité, nous l’avons donné à d’autres pour essai, menant un bref test bêta.
Du premier ligne de code à la sortie publique, Cursor n’a pris qu’environ trois mois. Notre objectif était de livrer le produit aux utilisateurs le plus rapidement possible et d’itérer rapidement grâce aux retours du public.
À notre surprise, nous pensions initialement que cet outil n’attirerait que quelques centaines d’utilisateurs pendant longtemps, mais dès le début, un grand nombre d’utilisateurs sont arrivés, apportant de nombreux retours. Les premiers retours utilisateurs étaient extrêmement précieux ; ce sont eux qui nous ont poussés à abandonner la version construite depuis zéro pour passer à un développement basé sur VS Code. Depuis lors, nous continuons à optimiser le produit dans un environnement public.
Produit lancé en trois mois, ARR atteint 100 millions de dollars en un an
Lenny : J’apprécie beaucoup ta modestie face à vos réalisations. À ma connaissance, vous avez fait passer votre ARR de 0 à 100 millions de dollars en environ un à un an et demi, ce qui est assurément un exploit historique.
Quels sont selon toi les éléments clés du succès ? Tu as mentionné l’auto-utilisation comme l’un d’eux. Mais le fait de sortir un produit en trois mois est incroyable. Quel est le secret derrière cela ?
Michael Truell : La première version, celle terminée en trois mois, n’était pas parfaite. Nous avons donc toujours eu un sentiment constant d’urgence, sentant qu’il y avait encore beaucoup à améliorer.
Notre objectif ultime est de créer véritablement un nouveau paradigme de programmation, capable d’automatiser une grande partie du travail de codage que nous connaissons aujourd’hui. Quel que soit le progrès accompli par Cursor, nous sentons que nous sommes encore loin de cet objectif final, et qu’il reste toujours beaucoup à faire.
Souvent, nous n’avons pas trop insisté sur l’effet du lancement initial, mais nous nous sommes davantage concentrés sur l’évolution continue du produit, nous efforçant de l’améliorer et de le perfectionner constamment.
Lenny : Après ces trois mois, y a-t-il eu un point de basculement qui a fait décoller tout ?
Michael Truell : Honnêtement, la croissance initiale semblait assez lente, peut-être parce que nous étions un peu impatients. Mais en termes de vitesse globale de croissance, elle nous a constamment surpris.
Je pense que ce qui nous a le plus surpris, c’est que cette croissance a maintenu une tendance exponentielle stable, avec une croissance continue chaque mois, bien que la sortie de nouvelles versions ou d’autres facteurs puissent parfois l’accélérer.
Bien sûr, cette croissance exponentielle semblait très lente au début, la base étant effectivement très faible, donc elle n’a pas vraiment semblé exploser immédiatement.
Lenny : Cela ressemble à l’exemple de « construis-le, et ils viendront ». Vous avez simplement créé un outil que vous aimiez, une fois publié, les autres l’ont aimé aussi, et cela s’est propagé par le bouche-à-oreille.
Michael Truell : Oui, c’est à peu près ça. Notre équipe a concentré la majorité de ses efforts sur le produit lui-même, sans se laisser distraire par d’autres choses. Bien sûr, nous avons aussi passé du temps sur d’autres choses importantes, comme constituer l’équipe, alterner les responsabilités du support client, etc.
Cependant, pour de nombreuses tâches courantes que les startups investissent au début, nous avons « laissé le problème de côté », surtout en matière de vente et de marketing.
Nous avons concentré nos efforts sur le perfectionnement du produit, en créant d’abord un produit que notre équipe aime, puis en itérant selon les retours d’une partie des utilisateurs clés. Cela peut sembler simple, mais en réalité, c’est difficile à bien faire.
Il existe de nombreuses directions à explorer, de nombreuses routes de produit différentes. L’un des défis est de rester concentré, de choisir stratégiquement les fonctionnalités clés à construire et de définir leurs priorités.
Un autre défi est que le domaine dans lequel nous nous situons représente lui-même un nouveau modèle de développement de produit :nous sommes à mi-chemin entre une entreprise logicielle traditionnelle et une entreprise de modèles de base.
Nous développons un produit pour des millions d'utilisateurs, ce qui exige un travail d'excellence au niveau produit. Mais une autre dimension cruciale de la qualité du produit réside dans l'approfondissement continu de la recherche scientifique et du développement de modèles, en optimisant constamment les modèles eux-mêmes dans des scénarios clés. Équilibrer ces deux aspects reste toujours un défi.
La chose la plus contre-intuitive : ne pas prévoir de développer nos propres modèles
Lenny : Jusqu’à présent, en construisant Cursor et en développant des produits IA, quelle est selon toi la chose la plus contre-intuitive ?
Michael Truell : Pour moi, le plus contre-intuitif est que nous n’ayons absolument pas prévu de développer nos propres modèles au départ. Quand nous sommes entrés dans ce domaine, certaines entreprises avaient déjà commencé par se concentrer sur l’entraînement de modèles. Nous avions calculé les coûts et ressources nécessaires pour entraîner GPT-4, et savions clairement que ce n’était pas quelque chose que nous pouvions nous permettre.
Il existe déjà de nombreux modèles excellents sur le marché. Pourquoi se fatiguer à reproduire ce que d’autres ont déjà fait ? Surtout en matière d’entraînement préalable (pre-training), qui consiste à faire apprendre à un réseau neuronal ignorant de tout l’ensemble d’Internet. Nous n’avions donc aucune intention initiale d’emprunter cette voie. Dès le départ, nous savions clairement que les modèles existants pourraient faire beaucoup de choses qu’ils ne font pas encore, faute d’outils appropriés construits pour eux. Néanmoins, nous avons investi énormément dans le développement de modèles.
Parce que chaque « moment magique » que vous ressentez en utilisant Cursor provient en partie de nos modèles personnalisés. Ce processus a été progressif. Nous avons d’abord essayé d’entraîner notre propre modèle sur un cas d’usage, car aucun modèle de base dominant n’était adapté, et cela a réussi. Puis nous avons étendu cette approche à un autre cas d’usage, avec aussi du succès, et ainsi de suite.
Un point clé dans ce type de développement de modèles est de choisir précisément l’objectif, sans refaire ce qui existe déjà. Nous n’intervenons pas dans les domaines où les grands modèles de base excellent déjà, mais nous concentrons sur leurs points faibles et réfléchissons à la manière de les combler.
Lenny : Beaucoup de gens sont surpris quand ils apprennent que vous avez vos propres modèles. Car quand les gens parlent de Cursor et d’autres produits dans ce domaine, ils disent souvent qu’ils sont des « coques GPT », pensant qu’ils ne sont que des outils construits au-dessus de modèles comme ChatGPT ou Sonnet. Mais tu mentionnes que vous avez en réalité vos propres modèles. Peux-tu parler de la pile technique derrière cela ?
Michael Truell : Nous utilisons effectivement les principaux modèles de base dans de nombreux scénarios.
Pour les expériences clés offertes par Cursor aux utilisateurs, nous dépendons davantage de nos modèles internes, notamment pour les cas d’usage où les modèles de base sont trop coûteux ou lents. Un exemple est la complétion automatique.
Pour ceux qui n’écrivent pas de code, cela peut être difficile à comprendre. Écrire du code est un travail unique. Parfois, tout ce que vous allez faire dans les 5, 10, 20 minutes, voire une demi-heure, peut être anticipé en observant simplement ce que vous faites actuellement.
En comparaison avec l’écriture, beaucoup connaissent la fonction de complétion automatique de Gmail, ou les suggestions de complétion lors de l’écriture de SMS ou d’e-mails. Mais ces fonctions ont des limites. Car à partir du contenu écrit, il est souvent difficile de déduire ce que vous allez écrire ensuite.
Mais quand on écrit du code, en modifiant une partie du dépôt, on a souvent besoin de modifier simultanément d'autres parties du dépôt, et ces modifications nécessaires sont très évidentes.
Une des fonctionnalités centrales de Cursor est cette version améliorée de complétion automatique. Elle peut prédire une série d’opérations à venir, traversant plusieurs fichiers et différentes positions au sein des fichiers.
Pour que le modèle excelle dans ce scénario, il doit être suffisamment rapide pour fournir un résultat de complétion en moins de 300 millisecondes. Le coût est aussi un facteur important : à chaque frappe, nous déclenchons des milliers d’inférences, mettant constamment à jour la prédiction de votre prochaine action.
Cela implique aussi un défi technique très particulier : nous avons besoin que le modèle soit capable non seulement de compléter le prochain token comme un texte séquentiel classique, mais de bien compléter une série de diffs (modifications de code), c’est-à-dire de prédire, à partir des modifications déjà effectuées dans le dépôt, les ajouts ou suppressions probables à venir.
Nous avons spécifiquement entraîné un modèle pour cette tâche, avec un grand succès. Cette partie est entièrement développée en interne, sans jamais appeler aucun modèle de base. Nous n’avons pas étiqueté ou commercialisé cette technologie, mais elle est au cœur de Cursor.
Un autre scénario où nous utilisons nos modèles internes est d’améliorer les performances des grands modèles comme Sonnet, Gemini ou GPT, notamment en entrée et en sortie.
En entrée, notre modèle recherche dans tout le dépôt de code pour identifier les parties pertinentes à montrer à ces grands modèles. Vous pouvez l’imaginer comme un « mini moteur de recherche Google » spécialisé dans la recherche de contenu pertinent dans un dépôt de code.
En sortie, nous traitons les suggestions de modification données par les grands modèles, utilisant nos modèles spécialement entraînés pour compléter et affiner les détails. Par exemple, la conception logique de haut niveau est réalisée par des modèles plus avancés, qui dépensent quelques tokens pour donner une orientation générale. D’autres modèles plus petits, plus spécialisés et extrêmement rapides, combinés à certaines techniques d’optimisation du raisonnement, transforment ces suggestions de modification de haut niveau en transformations complètes et exécutables du code.
Cette approche améliore considérablement la qualité de l’exécution des tâches spécialisées et accélère grandement la réactivité. Pour nous, la rapidité est également un indicateur clé de la qualité de notre produit.
Lenny : C’est très intéressant. Récemment, j’ai interviewé Kevin Weil, le CPO (Chief Product Officer) d’OpenAI, dans mon podcast. Il appelle cela un ensemble de modèles (Ensemble of models).
Ils utilisent aussi chaque modèle pour ses fonctions où il excelle. Utiliser des modèles moins chers présente un avantage considérable en termes de coût. Vos modèles que vous entraînez vous-mêmes, sont-ils basés sur des modèles open source comme LLaMA ?
Michael Truell : Nous sommes très pragmatiques à ce sujet, nous ne voulons pas réinventer la roue. Nous partons donc des meilleurs modèles pré-entraînés disponibles
Bienvenue dans la communauté officielle TechFlow
Groupe Telegram :https://t.me/TechFlowDaily
Compte Twitter officiel :https://x.com/TechFlowPost
Compte Twitter anglais :https://x.com/BlockFlow_News
