The rise of Cursor: The $300M ARR AI tool that engineers can’t stop using | Michael Truell

Our goal with cursor is to invent a new type of programming, a very different way to build software. So a world kind of after code. I think that more and more being an engineer will start to feel like being a logic designer and really it will be about specifying your intent for how exactly you want everything to work. What is the most

counterintuitive thing you've learned so far about building cursor? We definitely didn't expect to be doing any of our own model development. And at this point, every magic moment in Kurser involves a custom model in some way. What's something that you wish you knew before you got into this role? Many people you hear hired too fast. I think we actually

hired too slow to begin with. You guys went from $0 to 100 million ARR in a year and a half, which is historic. Was there an inflection point where things just started to really take off? The growth has been fairly just consistent on an exponential. An exponential to begin with feels fairly slow and the numbers are really low and it didn't really feel off to the races to begin with. What do you think is the secret to your success? I think it's been Today my guest is Michael Tru. Michael

is co-founder and CEO of Any Sphere, the company behind Cursor. If you've been living under rock and haven't heard of Cursor, it is the leading AI code editor and is at the very forefront of changing how engineers and product teams build software. It's also one of the fastest growing products of all time, hitting 100 million ARR just 20 months after launching and then 300 million ARR just 2 years since launch. Michael's been working on AI for 10 years. He studied computer science and math at MIT, did AI research at MIT and Google, and is a student of tech and business history. As you'll soon see, Michael thinks deeply about where things are heading, and what the future of building software looks like. We chat about the origin story of

Cursor, his prediction of what happens after code, his biggest counterintuitive lessons from building Cursor, where he sees things going for software engineers, and so much more. Michael does not do many podcasts. The only other podcast he's ever done is Lex Freedman. So, it was a true honor to have Michael on. If you enjoy this

podcast, don't forget to subscribe and follow it in your favorite podcasting app or YouTube. Also, if you become an annual subscriber of my newsletter, you get a year free of Perplexity, Linear, Superhuman, Notion, and Granola. Check it out at lenny'snewsletter.com and click bundle. With that, I bring you

Michael Troll. This episode is brought to you by EPO. EPO is a next generation AB testing and feature management platform built by alums of Airbnb and Snowflake for modern growth teams. Companies like Twitch, Miro, ClickUp, and DraftKings rely on EPO to power their experiments. Experimentation is increasingly essential for driving growth and for understanding the performance of new features. And EPO helps you increase experimentation velocity while unlocking rigorous deep analysis in a way that no other commercial tool does. When I was at

Airbnb, one of the things that I loved most was our experimentation platform where I could set up experiments easily, troubleshoot issues, and analyze performance all on my own. EPO does all that and more with advanced statistical methods that can help you shave weeks off experiment time and accessible UI for diving deeper into performance and out- of-the-box reporting that helps you avoid annoying prolonged analytic cycles. EPO also makes it easy for you to share experiment insights with your team, sparking new ideas for the AB testing flywheel. EPO powers experimentation across every use case, including product growth, machine learning, monetization, and email marketing. Check out EPO at geto.com/lenny and 10x your experiment

velocity. That's get epo.com/lenny. This episode is brought to you by Vanta. When it comes to

ensuring your company has top-notch security practices, things get complicated fast. Now you can assess risk, secure the trust of your customers, and automate compliance for SOCK 2, ISO 27,01, HIPPA, and more with a single platform, Vanta. Vanta's market leading trust management platform helps you continuously monitor compliance alongside reporting and tracking risk. Plus, you can save hours by completing security questionnaires with Vanta AI.

Join thousands of global companies that use Vanta to automate evidence collection, unify risk management, and streamline security reviews. Get $1,000 off Vanta when you go to vanta.com/lenny. That's venta.com/lenny. Michael, thank you so much for being here. Welcome to the

podcast. Thank you. Uh it's great to be here. Thank you for having me. When we were chatting earlier, you had this really interesting phrase, this idea of what comes after code. Talk about that just like the

vision you have of where you think things are going in terms of moving from code to maybe something else. Our our goal with Kerser is to invent sort of a a new type of programming. um a very different way to build software that's kind of just distilled down into you describing the intent to the computer for what you want in the most concise way possible. Uh and really distilled down to you just defining how you think the software should work and how you think it should look. And yeah, with with you know the technology that we we have today and as it matures it uh we think you can get to a place where you can invent a method of building software that's legions higher level and more productive uh in some cases more more accessible too and um that that process will be will be a gradual moving away from you know what building software looks like today. Um and um I you know I

want to contrast it with maybe like the vision of you know what software looks like in the future. Um that you know I think you know a couple visions that are in the popular conscious that we at least um have some disagreement with. Um one is you know there's a group of people who think that um you know software building in the future is going to look very much like it it does today which mostly means text editing formal programming languages like TypeScript and Go and C and Rust. Uh, and then there's another group that kind of thinks like, you know, you're just going to type into a bot and you're going to ask it to build you something and then you're going to ask it to to change something about what you're building. And it's kind of like this, you know, chatbot Slackbot style where you're talking to your engineering department. And we think that there are problems with with both of those visions. I think that on the, you know,

on the the chatbot style end of things, um, and we think it's going to look like weirder than both. Um the problem with the the chatbot style end of things is um that lacks a lot of precision. If you want humans to have completely, you know, complete control over what the software looks like and how it works, you need to let them, you know, gesture at what they want to be changed. Um you know, in a form factor that's more precise than just, you know, change this about my app, you know, kind of in a text box removed from the whole thing.

And then, um you know, the the version of the world where kind of nothing changes, we think we think is is wrong. So we think that the the technology is going to get much much much better. uh and so a world you know kind of after you know after code um I think it looks like a world where you have a representation of the logic of your software that does look more like English right you have kind of written down you can imagine in doctrine form you can imagine in kind of an evolution of programming language towards pseudo code you have written down you know the logic of the software and you can you can edit that at a high level and you can point at that and it won't be kind of the the impenetrable millions of lines of code um it'll instead be something that's like much turser and easier to to navigate. But that world where the kind of crazy hard to understand something that's a little bit more human readable uh human editable uh is one is one that we're working toward.

This is a profound point. I think I I want to make sure people don't miss what you're saying here, which is that what you're envisioning in the next year essentially is kind of when things start to shift is uh people move away from even seeing code think having to think in code in like JavaScript and Python and there's this abstraction that will appear uh essentially pseudo code describing what the code should be doing more in English sentences. Yep. We we think it ends up ends up looking like that. Um, and we're very opinionated that that path goes through kind of existing professional engineers and it looks like this this evolution away from code. Uh, and it definitely looks like the human still being in the driver's seat, right? and the human having both a ton of control over all aspects of the software and not giving that up. And

then also uh the human having the the ability to um make changes very quickly like having a fast duration loop and not just like you know having something in the background that's that's super slow and takes like weeks uh go do all your work for you. This uh begs the question for people that are getting are currently engineers or thinking about becoming engineers or designers or product managers like what skills do you think will be more more and more valuable in this world of the what comes after code? I think taste will be increasingly more valuable and I think often when people think about taste in the realm of software they think about you know visuals or taste over smooth animations and uh you know coloring things UI UX etc on kind of the visual design of things and I think more and more and you know the visual side of things is an important part of defining you know a piece of software but then as mentioned before I think that the other half of defining a piece of software is is the logic of and how the thing works. And we have amazing tools for specking out the visuals of things. And then when you get into the the logic of how a piece of software works really the best representation we have of that is code right now. You can kind of gesture at it with Figma and you can gesture at it with writing down notes. Um but it's you know when you have an actual working prototype and so I think that more and more being being an engineer will start to feel like being a logic designer. And

really it will be about specifying your intent for how exactly you want everything to work. And it will less be about it be more more about the the what and a little bit less about the how um exactly you're going to do things under the hood. Uh and so yeah, I think I think taste will be increasingly important. I think one aspect of software engineering and we're very far from this right now and there are lots of you know uh funny funny memes going around the internet about you know the kind of some of the trials and tribulations people can run into if they trust AI for too many things when it comes to engineering um around you know uh building building apps that uh you know have have glaring glaring deficiencies and and problems and functionality issues but um I think we will get to a place where um you will be able to uh be less careful as a software engineer which right now is an incredibly incredibly important uh skill. Um, and yeah, we'll move a little

bit from carefulness and a little bit more towards taste. And this uh makes me think of vibe coding. Is that kind of what you're describing when you talk about not having to think about the details as much and just kind of going with the flow? I think it's I think it's related. I think that v coding right now

describes um exactly kind of this this state of creation that uh is pretty controversial where you're generating a lot of code and you aren't really understanding the details. That is that is like a a state of creation that then has has lots of problems like you don't really by by not understanding the details under the hood right now. You then very quickly get to a place where you're kind of limited at a certain point where you create something that's big enough that that you can't change.

And so I think some of the some of the you know ideas that we're interested around you know how do you give people uh continued control over all the details um you know when they don't really understand the code like I think that um solutions there um are very relevant to to the people who are buy coding right now I you know I think that uh right now we we kind of we lack the ability to you know let the themakers actually have complete control over the software and so um one of the one of the issues also with you with vibe coding and and letting letting taste really shine through from people is you can create stuff, but a lot of it is the AI making decisions that you are unwieldy and you don't have control over. One more question along these lines. You you throw out this word taste. When you say taste, what are you thinking? I'm thinking having the right idea for for what should be built. And then just it it will become more and more about kind of the effortless translation of here's exactly what you want built. Here's how you want everything to work. Here's how

you want it to look. And then you'll be able to make that um on a computer and it will less be about this kind of translation layer of like you and your team have a picture of what you'd want to build and then you have to really painstakingly labor intensive like lay out that into a format that a computer can then execute and interpret. And so yeah, I think you know less is less on the UI side of things. Maybe taste is a little bit of a misnomer uh but just about having the right idea for for what should be built. Awesome. Okay, I'm

going to come back to these topics, but I want to actually zoom us back out to the beginnings of cursor. Uh, I've never heard the origin story. I don't think many people know how this whole thing started. Basically, you guys are building one of the fastest growing products in the history of the world. It's changing the way people build products. It's changing careers,

professions. It's it's changing so much. How did it all begin? Any memorable moments along the journey of the early days? Carer kind of started as a solution search of a problem. um and uh a little a little bit where it very much came from reflecting on um how AI was going to get better um over the course of the next 10 years. And um there were there were kind of two defining moments.

One was uh being really excited by using the the the first beta version of the Git Co-ilot. Actually this was the first time we had used an AI product that was really really really useful and um was you know actually just useful at all uh and wasn't just a vaporware kind of demo thing and in addition to being an you know the first AI product that we used that was useful G copilo was also one of the most useful if not the most useful dev tool we' ever adopted um and that got us really excited you know another moment that got us really excited was the series of scaling on papers coming out of OpenAI and other places that showed that even if we had no new ideas, AI was going to get better and better just by pulling on simple levers like scaling up the models and also scaling up the the data that was going into the models. And so at the end of 2021, beginning of 2022, this got us excited about how you know AI products were now possible. This technology was going to mature uh into the future. And

it felt like when we looked around there were lots of people talking about making models and there it felt like people weren't really picking an area of knowledge work and thinking about what it was going to look like as AI got better and better and um you know that set us on the the path to like an you know kind of an idea generation exercise. It was like you know how are each these areas of knowledge work uh going to change in the future as this tech gets more mature. Like what is the you know end state of the work going to look like? Um how are the the tools that we use to do that work going to change? Um how are the models going to get you know need to get better to support uh changes in the work? And you know once scaling and pre-training ran out like how are we going to keep pushing forward technological capabilities and the myth step at at the beginning for sure is we actually worked on you know we sort of did this whole grand exercise uh and we decided to work on you know uh an area uh of knowledge work that we thought would be relatively uncompetitive and sleepy and and boring uh and you know no one no one would be looking at it because you know we thought oh coding's great you know coding is totally interchangeable because AI but you people are already doing that. And uh so there was a period of you know four months to begin with where we were actually working on a very different idea which was helping to automate and augment mechanical engineering uh and building tools for mechanical engineers. You know there were problems from the get-go in that we had uh you know me and my co-founders we we weren't mechanical engineers. Um you

know we had friends who were mechanical engineers but uh we were we were very much unfamiliar with the field. So there's a little bit of a blind man in the elephant problem from the get-go. Uh you know there were problems around you know how would you actually take take the models that exist today and make them useful for mechanical engineering. The way we net it out is you need to actually develop your own models from the get- go and the way we did that was uh was tricky and you know there's not a lot of uh data on the internet of of um you know 3D models of uh of different tools and parts and the steps that I took to build build up to those 3D models. uh and then getting them from the sources that that have them is like also a tricky process too. But um eventually what happened was you know we we came to our senses we realized we're not super excited about mechanical engineering it's not the thing we want to dedicate our lives to and we looked around and uh in the area of programming it felt like you know despite you know a decent amount of time ensuing uh not much had changed and it felt like the people that were working on the space maybe had a had a disconnect with us and it felt like they weren't being sufficiently ambitious about um where everything was going to go in the future and how kind of all of software creation was going to blow through these models uh and that's what set us off on the the path to to building Kersia. Okay, so

interesting. Okay, so first of all, I love that there's this this is advice that you often hear of go after boring industry because no one's going to be there and there's opportunity and you know sometimes it works but I love that this journey it's like no actually go after the hottest most uh popular space AI coding app building and it worked out and the way you phrased it just now is you didn't see enough ambition potentially that you thought there was more to be done so it feels like that's an interesting lesson if even if something looks like okay it's too late there's GitHub copilots out there are some other products if you notice that they're just not as ambitious as they could be or as you are or you see almost a flaw in their approach that there's still a big opportunity. Does that resonate? Uh that totally resonates and I think it's um a part of it is you need there to to be like leaprogs that can happen. And

you need there to be things that you can do. And I think the exciting thing about about AI is in a in a bunch of places and I think this is, you know, very much still true of our space and you can talk about how we think about that and how we deal with that. But um, you know, I think that just the ceiling is really high and um, yes, if you if you look around uh, you know, probably even if you you take the best tool in kind of like any of these any of these fields, um, there should be a lot more that needs to be done over the next few years. And so that that space having that space having that you know high ceiling I think is is unique um amongst areas of software at least the degree to which it is it is high with AI. Let's

come back to the ID question. So there's kind of a few routes you could have taken and other companies are doing different routes. So there's building an ID for engineers to work within and adding AI magic to it. There's another

route of just a full AI agentic devon sort of product and then there's just like a model that is very good at coding and focusing on building the best possible coding model. What made you decide and see that the ID path was the best route? The folks who were from the get-go working on just a uh a model were working on end to end uh automation programming. I think uh they were trying to build something very different from us which is we care about giving humans control over all the decisions um in kind of the end tool that they're building and I think those folks were very much thinking of a of a future where kind of you know end the whole thing is done by AI and maybe like the AI is making all the decisions too and so one there was kind of like a personal interest component two I think that always we try to be intense realist about where the technology is today, you know, very very very excited about how AI is going to mature over the course of many decades. But, uh, you know, I think that sometimes people, you know, there's there's an instinct to to see AI do magical things in one area and then kind of anthropomorphize these models and think, you know, it's better than a smart person here and so must be better than a smart person there. But these things have massive issues. And um we uh from the from the very start our our product development process was really about dog fooding and using the tool intensely every day and we we never wanted to ship anything that wasn't wasn't useful to us. And you know we had

the benefit of doing that because we were the end user part of our product. And I think that that instills a realism in you around where the where the tech is right now. And so uh that definitely made us think that we need the humans to be in the driver's seat. The AI cannot

do everything. We're also interested in giving humans that control too for for personal reasons. And so that that gets you away from just you're a model company that also gets you away from just kind of this endto-end stuff with without the human having control. And then the way you get through an IDE versus maybe a plugin to an existing coding environment is uh the belief that you know programming is going to flow through these models and the act of programming is going to change a lot over the course of the next few years and that the extensibility that existing coding environments have is so so so limited. So if you think that the UI is going to change a lot, if you think that the form factor of programming is going to change a lot, you necessarily need to have control over the entire application. I know that you guys today have an IDE and uh and that's probably the bias you have of this is maybe where the future is heading, but I'm just curious, do you think a big part of the future is also going to be AI engineers that are just sitting in Slack and just doing things for you? Is that something that fits into Cursor one day? I think you'll want the ability to move between all of these things fairly effortlessly.

And sometimes I think you will want to have the thing kind of go spin off on its own for a while and then I think you'll want the ability to pull in the AI's work and then work with it very very very quickly, right? And then maybe have it go spin off again. And so these like kind of background versus foreground form factors, I think you want that all to work well in one place. And uh I think the background stuff there's like a segment of programming that it's especially useful for which is type of programming tasks where it's very easy to specify exactly what you want um with you know without much description and exactly what correctness looks like without much description and often that's the bug fixes are kind of like the are are a great example of that but it's definitely not all of programming. So I think that you know

what the IDE is will totally change over time and kind of our approach to you know having our own editor was premised on it's going to have to evolve over time and I think that that will both include you can spin off things from different surface areas like Slack or your issue tracker or whatever it is and I think that will also include like you know the pane of glass that you're staring at is going to change a lot. Um and you know we just mostly think of an ID as the place where you are building software. I think something people don't talk enough about with with talking about agents and all these AI engineers are going to be doing all stuff for you is basically we're all becoming uh engineering managers with a lot of reports that are just like not that not that smart and you have to do a lot of reviewing and approving and specifying.

I guess thoughts on that and is there anything you could do to make that easier? Because that sounds really hard. Like anyone that has a large team, has had a large team being like, "Oh my god, all these uh junior people just checking in with me doing not high quality work over and over." It's just like, "What a life. It's going to suck." Yeah. Maybe eventually one-on- ones with uh so many one-on- ones. Um uh yeah. So the the customers we've seen have uh most success with AI, I think are still fairly conservative about some of the ways in which in which they they use this stuff. And so I do think today that

the most successful customers really lean on things like um you know our next edit prediction where we you know you're coding as normal and predicting the next actions you're going to do. And then they also really lean on like scoping down the stuff that you're going to hand off uh to the bot. And you know there's for a fixed percent of your time spent reviewing code you could um from from an agent um or from an AI overall you could you know there's kind of two patterns one is you could you know spend a bunch of time specifying things up front the AI goes and works and then you then go and review the AI's work and then you're done that's the whole task or you could really chop things up right so you can you know specify a little bit AI write something review specify a little bit AI write something review and that's kind of you know autocompletes all in the way of that spectrum and um still we see uh often the most successful people um using these tools are are are chopping things up right now and keeping things fairly that sounds less less terrible.

I'm I'm glad there's a solution here. I want to go back to you guys building cursor for the first time. What was the point where you realized this is ready? What was kind of a moment of like okay I think this is time to put it out there and see what happens. So when we started building cursor um we were fairly paranoid about spinning for a while without releasing to the world. And so to to begin with too we actually the the first version of kers was was hand rolled. We uh now we we use uh VS code kind of as a base like many browsers use chromium as a base um and had for worked off of that. uh to begin with we we

didn't and built a prototype of cursor from scratch and that involved a lot of work. We had to build our own uh you know there were a lot of things that go into you know a modern code editor uh including um you know support for many different languages and um navigation support for moving amongst the language you know error tracking support for things. there's, you know, things like, you know, an integrated command line, you know, the ability to use like remote servers to uh to, you know, to the ability to connect to remote servers to to view and and run code. And so we kind

of just like went on this blitz of building things incredibly quickly, building kind of our own uh editor from scratch and then also the AI components. And um it was after like a couple of months that we just you know uh it was after maybe five weeks that we were living on the editor full-time and you know had thrown away our previous editor uh and we're we're using new one and then once it got to a point where we found it a bit useful then we put it in other people's hands and had this like very short beta period and then we launched out to the world within uh a couple of months from the first line of code. I I think it was probably probably three months and it was definitely a like you know let's let's just get this out to people and build in public quickly. The thing that took us by

surprise is we thought we would be building for a couple hundred people for a long time and you know from the get- go there there was kind of an immediate crush of interest and a lot of feedback too. Uh and you know that was super helpful. We learned from that and that's actually you know why we switched to being based off of VS Code instead of just you know this headold thing. Uh a lot of that was motivated by kind of the initial user feedback and uh you know and then have been iterating in in public uh from there. I like how you understated uh the the traction that you got. Uh I think you guys went from zero dollars to 100 million ARR in like a year and a half or something like that which is uh historic. What do you think

was the key to this to success of something like this? He's talking about docuing being a big part of it. Like you build it in three months that's insane. Uh what do you think was is the secret to your success? The first version was was not you know the three-month version wasn't very good and so I think it's been you know a sustained paranoia about you know there are all of these ways in which this this thing could get better. You know the end goal is really to uh invent a very new form of programming that involves automating a lot of coding as we know today. And um no matter you

know where we are with cursor it feels like we're very very far away from that end goal. And so there's u there's always a lot to do but I think it's been kind of uh a lot of it hasn't been over rotated on kind of that initial push but instead is like the continued evolution of the tool and just making the tool consistently better. Was there an inflection point after those three months where things just started to really take off? To be honest it felt fairly slow to begin with. Um and you

know maybe maybe comes from some impatience on our part. Um but uh one what I think you know there's the the overall speed of the growth which is um uh you know continues to take us by surprise. I think one of the things that uh has been most surprising too is that the growth has been fairly just consistent on an exponential of just consistent month- over-month growth accelerated at times by um launches on our part and other things. But uh you

know but an exponential to begin with feels feels fairly slow when the the numbers are really low and uh so it didn't it didn't really feel off to the races to begin with. To me this sounds like build it and they will come actually working. You guys just built an awesome product that you loved yourselves as engineers. You put it out.

People just loved it, told everyone about it. it it being essentially all just us you know the the team working on the product and making the product good in lie of you know other things one could spend one's time on you know we we definitely spent time on tons of other things for instance building the team was incredibly important and you know uh doing things like uh you know support rotations very important but some of the normal things that people maybe reach for uh and in building the company early on um we really let those fires ear for a long time especially when it came to things like like sales and marketing and so just working on the product and building a product that you like your team likes and then you know also then adjusting it for some set of users that can kind of sound simple but then you know it's hard to do that well and uh there are a bunch of different directions one could have run in a bunch of different product directions and I think that um you know one of the difficult things you know I think focus and kind of strategically picking the right things to build and prioritizing effectively is tricky I think another thing that's tricky about this um this domain is it's kind of a new form of product building where um it's very intipary in that we are something in between a normal software company uh and then in between a normal software company and then a foundation model company in that um you know uh we want to develop a you know we're developing a product for millions of people and that you know that side of things has to be excellent. But then also one important dimension of product quality is doing more and more on the science and doing more and more on the model side of things uh in places where it makes sense. And so that element of things doing that well too has been tricky but yeah you know the overall thing would note is you know uh maybe you know some of these things sound simple to specify but then like doing them well is is hard and there are rough ways you can run.

I'm excited to have Andrew Luo joining us today. Andrew is CEO of OneKema, one of our longtime podcast sponsors. Welcome Andrew. Thanks for having me, Lenny. Great to be here. So, what is new with One Schema? I know that you work with some of my favorite companies like RAMP and Vanza and Watershed. I heard

you guys launched a new data intake product that automates the hours of manual work that teams spend importing and mapping and integrating CSV and Excel files. Yes. So, we just launched the 2.0 of one schema file feeds. We've rebuilt it from the ground up with AI. We saw so many customers coming to us with teams of data engineers that struggled with the manual work required to clean messy spreadsheets. File feeds 2.0 allows nontechnical teams to automate the process of transforming CSV and Excel files with just a simple prompt. We support all of the trickiest

file integrations, SFTP, S3, and even email. I can tell you that if my team had to build integrations like this, how nice would it be to take this off our road map and instead use something like one schema? Absolutely, Lenny. We've heard so many horror stories of outages from even just a single bad record in transactions, employee files, purchase orders, you name it. Debugging these

issues is often like finding a needle in a haststack. One schema stops any bad data from entering your system and automatically validates your files, generating error reports with the exact issues in all bad files. I know that importing incorrect data can cause all kinds of pain for your customers and quickly lose their trust. Andrew, thank you so much for joining me. If you want to learn more, head on over to onskeema.co. co that's

oneskeema.co. What is the most counterintuitive thing you've learned so far about building cursor building AI products? I I think one thing that's been counterintuitive for us uh hinted at at it a little bit before, but is we we definitely didn't expect to be doing any of our own model development when we started. As mentioned, you know, when we when we got into this, there were companies that were immediately from the get- go going and just focusing on kind of training model from scratch. And we had done the calculation for what it took to to train GP4 and just knew that that was not going to be something we were going to be able to do. And it also felt a little bit like uh focusing one's attention in the wrong area because there are lots of amazing models out there. and why I do all this work to replicate kind of what other players had done especially on the pre-training side of things you know taking a a neural network that knows nothing and then teaching it the whole internet and uh so we thought we were we weren't going to be doing that at all and it seemed clear to us from the start that the the existing models there were lots of things that they could be doing for us that um they weren't doing because you know there wasn't the right tool built for them in fact though we do a ton of model development and internally it's a it's a big um focus for us in the hiring front uh and have assembled a fantastic team there and it's also been a big win on the the product quality side of things for us.

Uh and at this point every magic moment in Kerserv involves a custom model in some way and uh so that that was definitely counterintuitive and and surprising and uh it's it's been a gradual thing where you know there was an initial use case for for training our own model where it really didn't make sense to use any of the biggest foundation models that was incredibly successful kind of moved to another use case that worked really well. uh and has have been going from there. And one of the you know that the helpful things in in doing this sort of model development is is picking your your spots carefully, not trying to reinvent the wheel, not trying to focus on places maybe where the the the best foundation models are are excellent, but instead kind of focusing on their weaknesses and how you can complement them. I think this is going to be surprising to a lot of people hearing that you have your own models. when I you know when people talk about cursor and all the folks in the space they would kind of call them GPT rappers they're just sitting on top of Jad JPT or sonnet and what you're saying is that you have your own models talk about just like the stack behind the scenes yeah of course um so we definitely use uh the biggest genation models you know a bunch of different ways um they're really important components of of bringing the cursor experience to people the the places where we use our own models so sometimes it's to serve a use case that a foundation model wouldn't be able to serve at all for cost or speed reasons. And so one example of that is um uh the autocomplete side of things. And so this

can be a little bit tricky for uh people who don't code to understand. But code is this weird form of work where sometimes really the next 5 10 20 30 minutes of your work is entirely predictable from looking over your shoulder. And I would contrast this with writing. So writing, you know, everyone or lots of people are familiar with, you know, Gmail's autocomplete and kind of the different forms of autocomplete that show up when you're trying to get those text messages or emails or things like that. They can only be so helpful

because often it's just really not clear what you're going to be writing just by looking at what you've written before. But in code, sometimes when you edit a part of a codebase, it just you're going to need to change things and in other other parts of a codebase and it's it's entirely clear how you're going to need to change things. And uh so one core part of cursor is this really souped-up autocomplete experience where you predict like the next set of things you're going to be doing across multiple files across multiple places within a file. And you know making models good at

that use case. One there's this speed component of those models need to be really fast. They need to give you a completion within 300 milliseconds. There's also this cost component of we're running tons and tons and tons of molecules. You know every keystroke we

need to be you know changing our prediction for what you're going to do next. And then it's also this really specialty use case of you need models that are really good not at completing the next token of just like a generic text sequence but are really good at autocompleting a series of diffs um you know looking at what's changed within a codebase and then predicting the next sort of things that are going to change you know both deleted and added and all of that and we we found a ton of success in training models specifically for that task. So that's a place where you know no foundation models are involved. It's kind of our own thing. We don't have a lot of labeling or branding about this in the app but that you know cores of uh you know powers a very core part of cursor and then uh you know another set of places where user models are to to help things like sonnet or gemini or gbt and those sit both on the input of those big models and on the output on the input side of things. Those models are searching throughout a codebase trying to figure out the parts of a codebase to show to one of these big models. Um, you

can kind of think about this as like a mini Google search that's specifically built for finding the, you know, relevant parts of a codebase to show one of these big models. And then on the output side of things, you know, we take the sketches of the changes that these models are suggesting you make with that codebase. And then, you know, we have models that then kind of fill in the details of like, you know, the high level thinking is done by these smartest models. They spend a few tokens on doing that. And then these smaller specialty

incredibly fast models coupled with some inference tracks then take those highle uh changes and turn them actually into full code discs. And so it's been super helpful for um pushing on on quality in places where you need a specialty task. And it's been super helpful for pushing on speed, which is such an important dimension of product quality for us uh too. This is so interesting. I just had Kevin Wheel on the podcast, CPO of OpenAI, and he calls this the ensemble of models. That's the same way they

work. to use the best feature of each one and to your point the cost advantages of using cheaper models. Uh these open these other models are they based on like llama and things like that just open source models that you guys plug into and build on? Yeah. So uh again we try try to be very pragmatic about the places that we're going to do this work and we don't want to reinvent the wheel and so um starting from the the very best um you know uh pre-trained models that exist out there often open source ones you know sometimes in collaboration with these big model providers that that don't share their weights out into the world. Um because the thing we care about less is you know the ability to read read line by line you know the you know the the matrix of weights that then you know go to give you give you a certain output and it's you know we just care about the ability to kind of to to train these things to post train them and so uh by and large by and large yes open source models you know sometimes working with the closed source providers too to tune things. This leads to a a discussion that a lot of AI founders always think about and investors which is moes and defensibility in AI. Uh so it feels like

one is custom models is is a moat in the space. How do you just think about long-term defensibility in the space knowing there's other folks as you said launching constantly trying to take your trying to eat your lunch? I think that you know there are ways to to build in inertia and u you know tra traditional modes but uh I you know I think by and large we're in a space where you know it is incumbent on us uh to continue to try to build the best thing and and and everyone in this industry and I you know I truly just think that the ceiling is so high that kind of no matter what you know entrenchment you build um you be leaprog and I think that this uh resembles markets that are maybe a little bit different from normal software markets, normal enterprise uh markets of the past. You know, I think one that comes to mind is is the market for search engines at the end of 1999 or, you know, at the end of the the '90s and beginning of the 2000s. I think another market that comes to mind that resembles this market in many ways, it's actually just like the development of um the personal computer and mini computers, you know, in the 70s, '8s, 90s. And um I think that yes, you know, in each of those markets, the ceiling was incredibly high. You know, it was possible to switch. You could keep

getting value for like the incremental hour of a smart person's time, the incremental R&D dollar for a really long time. You wouldn't run out of useful things to build. And then you know in in in search in particular not in the computer case having distribution was was helpful for making the product better too in that you could tune the algorithms you could tune the learning based off of the the data and the feedback you're getting from users and I think that you know all of those dynamics exist exist in our market too and so I think that you know maybe the sad sad truth for people like us but then like the amazing truth for the world is I think that there are many leaf frogs that exist uh there's many you know more useful things to We're a long way away from where we can be in, you know, 5 10 years and it's kind of incumbent on us state to keep that engine going. So what I'm hearing is

sounds like a lot more like a consumer sort of mode where it's just be the best thing consistently so that people stick with you versus creating lock in and things like that where they're just for like Salesforce where it's just contracts with the entire company and you have to use this product. Yeah. And I think the the important thing to note is, you know, if you're in a a space where like you kind of run out of useful things to do very quickly, then that's you know, that's not a great situation to be in. But if you're in a place where, you know, big investments and um you know, ha having more and more great people working on the right path can keep giving you value, then you can get kind of these economies of scale of R&D and you can kind of have you know, you know, deeply work on the technology in the right direction and and get to a place where that is defensible. Uh but

yes it is it is you know I think there's there's a consumer-like tenency to it and I really think it's just a you know about building the best thing possible. Do you think in the future there's one winner in this space or do you think it's going to be a world of a number of products like this? I think the market is just so very big. And this is also one thing that um you know, you asked about the IDE thing early on and one thing that I think tripped up some people that were thinking about the space is like they looked at the IDE market of the past 10 years and they said, you know, who's making money off of the editors? Like, you know, there's all these it's this super fragmented space where everyone kind of has their own thing with their own configuration. And you know there's one company that commercially like you know actually makes money off of of making great great editors but like that company is only so big and uh you know then like the conclusion was it was going to look like that in the future. And I think that the thing that people missed was that you know there was only so much you could do building an editor in the 2010s for coders. And you know the the company that made money off of editors was doing things like making it easy to navigate around a codebase and you know doing some some error checking and type checking for things and you know having good debugging tools but like which were all very useful but I think that the the set of things you can build for programmers. I think the set of things

you can build for knowledge workers in many different areas just goes very far and very deep. And I think that really kind of like the the problem in front of all of us is is like the automation of a lot of busy work and knowledge work and really changing all the areas of knowledge work in front of us to be u much highable and more productive. So uh that that was all you know a long-winded way to say I think the market's really really big that we're in. uh I think it's much bigger than people have realized uh than you know the other uh you know building tools for developers in the past and I think that there will be a bunch of different solutions. I think that there will be one company and to be determined if it's going to be us, but I do think that there will be one company that builds the the general tool that builds almost all the world software and that will be a very very generationally big business. But I think that there will be kind of niches you can occupy and doing something for a particular segment of the market or for a very particular part of the software development life cycle. But the general

like programming shifts from just writing formal programming languages to something way higher level. this is the application you you purchase and use to do that. Uh I think that there will be generally one winner there and and it will be a very big business. juicy. Uh along those lines, it's interesting that Microsoft was actually like right at this like at the center of this first with an amazing product. Amazing distribution co-pilot you said was like the thing that got you over the hump of like, wow, there could be something really big here and it doesn't feel like they're winning. Feels like they're

falling behind. What do you think? What What do you think happened there? I think that there are like specific historical reasons why co-pilot might not have lived up or so far have have kind of uh lived up to the expectations that some people had for it. And then I think that there are structural reasons. I think the structural reason is and to be clear you know Microsoft you know in the co-pilot case obviously a big inspiration for our work. Um and in general I you know think they do lots of awesome things and we're users of many Microsoft products.

Um but I think that this is a market that's not super friendly to incumbents in that um you know a market that's friendly to incumbents might be one where there's only so much to do it kind of gets commoditized fairly quickly and you can bundle that in with other products and where the ROI between you know different products is you know quite quite small and you know in that case perhaps it doesn't make sense to buy the innovative solution it makes sense to just kind of buy that thing bundled in with other stuff another market that might be, you know, particularly helpful for incumbents. It is one where there's, you know, from from the get- go, it's just like you have your stuff in one place and it's like really really excruciatingly hard to switch. And, you know, for better, for worse, I think in in our case, you can try out different tools. You can decide which product you think is better. And so, that's not super friendly uh to to in comments and that's more friendly to whoever you think is going to have the most innovative product. And then the specific historical reasons like as I understand them are the group of people that worked on the first version of copilot have by and large gone on to do other things at other places. I think

it's been a little hard to kind of coordinate among all the different departments and parties that might be involved in in making something uh like this. I want to come back to cursor. A question I like to ask everyone that's building a tool like this. If you could sit next to every new user that uses cursor for the first time and just whisper a couple tips in their ear to be more successful, most successful with cursor, what would be like one or two tips? I think right now and we'd want to fix this at a product level. A lot of

being successful with Kerser is kind of having a taste for like what the models can do, both what complexity of a task they can handle and like kind of how much you need to specify, you know, things things to that that model, but like having a a taste for the quality of the model and where its gaps exist and what it can do and what it can't. And um right now we don't do a good job in the product of like you know educating people around that um and maybe giving people some swim lanes giving people some guidelines but so um to develop that taste um would give kind of two two tips. So one is as mentioned before uh I would bias less toward like hey trying to have the model like you know trying in one go to tell the model hey here's exactly what I want you to do then seeing the output and then either being disappointed or accepting the entire thing for an entire big task. Instead what I would do is I would chop things up into bits and you can spend basically you know the same amount of time specifying things overall but chopped up more. So you're specifying a little bit, you're getting a little bit of work, you're specifying a little bit, getting a little bit of work, and you know, not doing as much the like let's write a giant thing telling all exactly what to do. I think that will be a little bit of a recipe for disaster right now. Uh and so biasing toward

chopping things up at the at the same time and it might make sense to do this on a side project and not on your professional work. You know, I would encourage people to especially, you know, developers who are kind of used to existing workflows for building software. You know, I would encourage people to explicitly try to fall on their face and try to discover the limits of uh what these models can do by, you know, being ambitious in like kind of a a safe environment, uh like perhaps a side project and and trying to kind of go hand to use AI to the fullest because, you know, sometimes we do run or a lot of the time we run into people um who haven't given the AI yet a fair shake and are kind of underestimating its abilities. So generally biasing

towards chopping things up and making things smaller but like to discover the limits of what you can do there like explicitly just kind of try to go for broke in a safe environment and you know get get a taste for it. You might be surprised in some of the places where the model doesn't break. What I'm essentially hearing is kind of build a gut feeling of what the model can do and how far it can take an idea versus just kind of guiding it along. And I bet that you need to rebuild this gut every time there's a new model launch like when it's on it I don't know 4.0. I know

comes out you have to kind of do this again. Is that generally right? Yes. Uh it's not you know for the past few years it hasn't been as big as like I think the the first kind of experience people have had with some of these big models but um yeah you know it this is also a problem we would hope to solve much better just for users and take the burn off of them. But yeah each of these things have slightly different quirks and different personalities. kind of

along these lines, something that people are always debating, tools like cursor, are they more helpful to junior engineers or are they more helpful to senior engineers? Do they make senior engineers 10x better? Do they make junior engineers more like senior engineers? Where do you think most of who do you think it benefits most today from cursor? I think across the board u both of these cohorts benefit in big ways. It's a little hard to say on the relative ranking. I will say they fall into different anti patterns. So I would

the junior engineers we see going a little too wholesale relying on AI for everything and we're not yet in a place where you can kind of do that end to end on a professional tool you know working with tens hundreds of other people within a long codebase and then the senior engineers for many folks is not true for all and we actually uh uh often you know one of the ways these tools are adopted is there's developer experience teams within companies often there staffed by incredibly senior, you know, senior people because often those are people who, you know, are building tools to make the rest of the engineers within an organization more productive. And we've seen some very very um, you know, boundary pushing kind of uh uh yeah, like we've seen people who are, you know, on on the the front lines of like really trying to adopt the technology as much as possible there. But by and large I would say on average as a group the senior engineers underrate what AI can do for th

2025-05-10 04:13

Other news