Pod Insights Y Combinator Podcast Cursor CEO: Going Beyond Code, Superintelligent AI Agents And Why Taste Still Matters About this episode Michael Truell, co-founder and CEO of Anysphere, the company behind Cursor, joins Garry to talk about building one of the fastest-growing startups of all time—and why he's betting on a future beyond code. He walks through the early insights that led his team to leave a promising AI-powered CAD project and instead chase a bigger dream: reinventing how software is written. From years of false starts and rewrites to Cursor's breakthrough moment, Michael explains what it takes to build a tool that could eventually replace programming as we know it. He also reflects on their first 10 hires, why taste still matters and how the decade ahead will unlock a new kind of creativity for builders everywhere.
Transcript 0:00 Speaker 00 For us, the end goal is to replace coding with something much better. I think that this is going to be a decade where just your ability to build will be so magnified. If you keep pushing the frontier faster than other people, you can get really big gains occurring to you. Building a company is hard, and so you may as well work on the thing that you're really excited about. And so, yeah, we set off to work on the future of code.
0:24 Speaker 01 Welcome back to another episode of How to Build the Future. Today, I'm joined by Michael Truell, co-founder and CEO of AnySphere, the company behind Cursor, the AI coding platform we all know and love. They recently hit a $9 billion valuation and are one of the fastest-growing startups of all time, reaching $100 million ARR just 20 months after launching. Michael, thanks for joining us.
0:50 Speaker 00 Thank you for having me. Excited to be here.
0:52 Speaker 01 You've said the goal of Cursor is to actually invent a new type of programming where you can just describe what you want and it gets built. Talk to me about that.
1:02 Speaker 00 Yeah, the goal with the company is to replace coding with something that's much better. Me and my three co-founders, we've been programmers for a long time. More than anything, that's what we are. The thing that attracted us to coding is that you get to build things really quickly. To do things that are sort of simple to describe, coding requires editing millions of lines of kind of esoteric, formal programming languages, requires doing lots and lots of labor to actually make things show up on the screen that are kind of simple to describe. We think that over the next five to 10 years, it will be possible to invent a new way to build software that's higher level and more productive. That's just to still down to defining how you want the software to work and how you want the software to look. And so, our goal with Cursor is to get there. And our path to getting there is to, at any given point in time,
1:46 Speaker 00 always be the best way to code with AI and then evolve that process, evolve it away from normal programming to something that looks very different.
1:54 Speaker 01 So some people would say that is what we have today. You sort of describe what you want and out it comes. What would you say to that? Like, are we there yet? You know, what are the steps to where you really want to go?
2:05 Speaker 00 We're seeing the first signs of things really changing. I think you guys are probably on the forefront of it with YC. Because I think that in smaller code bases with smaller groups of people working on a piece of software, that's where you feel the change the most. Already there, we see people kind of stepping up above the code to a higher level of abstraction and just asking essentially agents and AIs to make all the changes for them. In the professional world, I think there's still a ways to go. I think that the whole idea of kind of vibe coding or coding without really looking at the code and understanding it, it doesn't really work. There are lots of end order effects. You know, if you're dealing with millions of lines of code and dozens or hundreds of people working on something over the course of many years, right now, you can't really just avoid thinking about the code.
2:48 Speaker 00 Our primary focus is to help professional programmers, to help people who build software for a living. In those environments, people are more and more using AI to code. You know, on average, we see about people using, you know, having AI write 40%, 50% of the lines of code produced within Cursor. But it's still a process of, you know, reading everything that comes out of the AI. And so an important chasm for us to cross as a product will be getting to a place where, you know, we become less of a productivity tool that's helping you look at, read, write, understand code, and where the artifact kind of changes. And I think for professional developers, there's still a ways to go there.
3:21 Speaker 01 In your head, do you think of it as like different tiers? There's sort of, obviously startups are starting out with zero lines of code. So that's very easy. Is there a point that you're tracking right now where, oh, well, that's when, you know, just vibe coding it stops working and that's when things sort of become real?
3:39 Speaker 00 The vibe coding style of things is definitely not something that we recommend if you're going to have the code stay around for a really long time. I think that one of the things that characterizes software development when you're a two, three person, four person startup and you're kind of moving around and trying to figure out what you're doing is often the code is only going to be around for, for weeks. Right now, we're in this phase where.
3:58 Speaker 00 AI is kind of operating as a helper for you, right? So kind of like the main ways in which people are using AI to code. They're either delegating tasks to an AI and they're saying, go do this thing for me. Go answer this question for me. Or they have an AI looking over their shoulder and taking over the keyboard every once in a while. That's kind of the tab form factor. And I think that the game in the next six months to a year is to make both of those, an order of magnitude more useful. Coding sometimes is incredibly predictable when you're just looking over someone's shoulder, the next 10, 15, 20 minutes of their work. And so the tab form factor can go very far. And then the agent form factor of delegating to another human can go very far, too. And then I think that once those start to get mature and you know, for 25, 30% of professional development, you can just entirely lean on those end to end without really looking at things.
4:44 Speaker 00 Then there will be all of these other things to figure out about how you make that work in the real world. One way in which you can view LLMs is they're, you interface with them like a human, like a helper. Another way in which you can view LLMs is they're kind of an advanced compiler or interpreter technology. It's going to be always helpful if we are a tool to help a human go from an idea in their head to something on the screen to give people control over the finest details, right? That's one of the product challenges we have in front of us is you should always be able to move something a few pixels over. You should always be able to edit something very specific about the logic. I think one useful UI always to have there is to have written down the logic of the software. And you can point at various bits of the logic and actually edit them. But if we were to get to a place where you don't have to pay attention to the code as much,
5:30 Speaker 00 that written down version of the logic of the software is going to have to get a higher level. And so, yeah, we're excited about, you know, after you get agents working, after you get kind of the tab form factor very mature, does AI actually evolve what it means to be writing and looking at a programming language?
5:44 Speaker 01 Is it a context window thing? It sort of makes sense that, well, once you get past about a million to 2 million tokens, only even in, I feel like the last 100 days, did we get usable 2 million token length. Is that naturally one of the places where, once your code base reaches a certain size, you got to use rag, it has incomplete context, and then it just can't do what a human coder could do?
6:08 Speaker 00 Yeah, I think that there are a bunch of bottlenecks to agents being human level. I think one is context window side of things is definitely an issue where, you know, if you have 10 million lines of code, that's, you know, maybe 100 million tokens. And both having a model that can actually ingest that, having it be cost effective, and then not just having a model that can physically ingest that into its weights, but also one that actually pays attention effectively to that context window is tricky. And I think that that's something that the field needs to grapple with. And it's not just a code based thing there. It's also just a continual learning problem of, you know, knowing the context of the organization and things that have been tried in the past and who your coworkers are. And that problem of having, you know, a model really continually learn something,
6:51 Speaker 00 kind of something that the field, I think, still doesn't really have a great solution to. Like, it has always been suspected that it will be, or for a lot of people suspected you just make the context window infinite and that ends up working out. I think that there's a dearth of really good, long context data available to the institutions that are training these models. And so I think that that will be tricky. But continual learning and long context is definitely a bottleneck to being superhuman. It's kind of related, but being able to do tasks over very long time horizons and continue making forward progress. Going around on the internet, there's this amazing chart of progress in the last year or two on the max length of time an AI can make forward progress on a task. And it's gone up from, you know, seconds to, I think, I don't know the details of how these numbers are actually gotten,
7:34 Speaker 00 but I think someone's claiming some of the latest models, it's like an hour. Then there are problems with different modalities. So to be a software engineer, you kind of need to run the code and then play with the output. If you didn't, you would be way superhuman, that would be insane. But so computer using is kind of, is going to be important for the future of code. Being able to run the code, being able to look at data dog logs and interface with with those tools that humans use. There are a lot of known devils that we will have to face and then a lot of unknown devils that we will have to face in, you know, the task of making coding agents superhuman. And then, you know, one thing I will note, kind of harkening back to a last response, is that even if you had Something you could talk to that was human level at coding, or faster and better than a human at coding. You know, it's sort of the skill of an entire engineering department.
8:16 Speaker 00 I think that the UI of just having a text box asking for a change of the software is imprecise. And so even in the limit, if you care about humans being able to control what shows up on the screen, you will need a different way for them to interface. And so one potential UI there is, you know, an evolution of programming languages to be something that's higher level. Another is maybe direct manipulation of the UI, right? Being able to point at things on the screen and say, oh, change this, or actually kind of fiddling with the values yourself.
8:39 Speaker 01 Yeah, I mean, that seems like a bunch of things that are kind of just nascent in the wings, right? Like, the models don't seem to have a really clear sense for aesthetics, for instance. And so the idea that maybe this human level designer needs to actually, you know, be able to, they need to be able to see, actually.
8:55 Speaker 00 Yeah, and it's been interesting seeing them improve at the aesthetic side of things. And I think that that's actually like an interesting, specific example about how we've hacked around these continual learning problems. But our understanding is that, you know, the way you teach these models to be better at something like aesthetics is not in the way you would a human. It is by, you know, basically collecting a bunch of data, doing RL on them. And that's like how you've taught it that task. And that's a task that enough people care about that you can pay the cost to do all of that. And you can go and train and have it into sort of baked into the base model. But it's kind of a hack around the continual learning problem.
9:29 Speaker 01 So given this sort of future that everyone's building towards, and you're certainly a leader at the forefront of it, you know, what do you think will be irreplaceable or like sort of the essential pieces of being a software engineer in the future?
9:42 Speaker 00 We think that one thing that will be irreplaceable is taste. So just defining what do you actually want to build? People usually think about this when they're thinking about the visual aspects of software. I think it's also, there's a taste component to the non-visual aspects of software too, about how the logic works. And right now, the act of programming kind of bundles up you figuring out how exactly you want the thing to work, like what product you're really defining with the logic that you're writing, and the kind of high-level taste of the implementation details of how that maps onto a physical computer. But then, right now, a lot of programming is kind of this human compilation that you're doing, where you kind of know what you You could tell it to another human being, but you really have to spell it out for the computer.
10:23 Speaker 00 Because the language that you can, you have to describe things to a computer is for normal programming, just for loops and if statements and variables and methods. And you really have to have to spell it out. And so I think that more and more of that like human compilation step will go away. And computers will be able to kind of fill in the gaps, fill in the details. But since we, you know, are a tool that's helping you make things happen, helping you build things, that kind of taste for what what is actually useful for what you want to build, I don't think will ever go away.
10:51 Speaker 01 That makes sense. I, there's that quote, good people will help you hit, you know, this bar, but the truly great, the truly masterful, they, you know, hit a bar that you can't even see.
11:02 Speaker 00 Yeah.
11:03 Speaker 01 So, and that requires taste.
11:04 Speaker 00 Yeah.
11:05 Speaker 01 You've called it sort of, people need to become logic designers. You know, what does that mean in terms of, you know, intent driven programming?
11:13 Speaker 00 As this tech matures more and more, as we get closer to a world where programming can be automated and can be replaced with a better way of building software. I think there are a bunch of implications. I think one is that, you know, professional devs will just get so much more productive. It's just crazy how slow thousand people's software projects move.
11:32 Speaker 01 Yeah.
11:33 Speaker 00 And a hundred people's software projects move and real kind of professional software projects move. And a lot of that comes down to the the weight of the existing logic, just kind of getting the best of you. When you're in a new codebase, you can start from scratch, you can do things very quickly. When you change something, there's not a bunch of other things that then break that you need to to fix. I think that one of the implications of it will be that, you know, the next distributed training framework or the, you know, the next database or the next visual design tool will just be way faster to build. The next AI model, which, you know, if you talk to the labs, largely they're bottlenecked on engineering capacity. I think all of that will just just improve a ton. I think that, you know, one second order effect too will be many more pieces of niche software will exist. One of my first jobs actually was working for a biotech company.
12:18 Speaker 00 And it was a company staffed by wet lab scientists. They were developing drugs to to cure diseases. And I was the first software engineer hired and they were generating massive amounts. Chemicals and then putting them through these biological experiments and then they needed to read out to kind of figure out which which chemicals to then pursue further. And they needed a ton of just internal software development to do that. And it was amazing, both looking at the existing tools off the shelf, just how bad they were. And then it was crazy to think that this company, for whom software was not their core competency, had to go out and do this crazy laborious thing of hiring a real software engineering team and training them up and having them do internal product development. And for companies like like that company, there will just be many more options available to them.
13:03 Speaker 00 The physics of digital space already are so great, but I think that that's just going to, you know, get turned up many notches into the future. Things that you want to want to happen on computers will then just kind of be able to happen.
13:14 Speaker 01 Switching gears, like I wanted to hear about the early days of Cursor. You met your co-founders, Swale, Arvid and Aman at MIT. And this company started in 2022. What drew you together and when did you realize this was a team that could build something really ambitious together?
13:32 Speaker 00 I think we had a lot of youthful naivete, I think probably unjustified at the time. So from the start, we were we were pretty ambitious. Cursor came out of an ambitious idea exercise, actually. For the four of us, you know, we all found programming fairly young. And then some of our first engineering projects actually had to do with AI. So one of us worked on improving the data efficiency of robotic reinforcement learning. So teaching robots very quickly to learn new tasks. That was one of our early AI projects. You know, another one of us worked on building actually a competitor to Google using using neural networks to try and sort of speed around building an amazing search engine for the web. Others did academic work in AI. But there were two moments in 2021 that
14:18 Speaker 00 got us really excited about building a company that was focused on AI. One of them was using the first useful AI products where AI was really at the center. And GitHub Copilot was honestly the moment where that viscerally, we really felt like now it was possible to make just really useful things with AI. And that we shouldn't go to work in a lab to work on these things, you know, in an academic lab. Instead, it was time for this stuff to come out into the real world. The other thing that got us really excited was seeing research come out of OpenAI and other places that showed there were these very predictable natural laws that showed if you scaled up the data and you scale up the compute that goes into these models, they were just getting better. And so that meant that even if we ran out of ideas for how to make AI better, there were a couple of orders of magnitude of that to still run.
15:00 Speaker 00 From the start, we wanted to pick an area of knowledge work and then work on what that knowledge work became as AI got more mature. We were very interested in the shape of a company where you build a product for that area of knowledge work because that lets you do a couple of things. One, as the underlying tech gets more mature, you can then evolve the form factor of what doing that thing looks like. And then two is even back then, it was clear you were probably going to need more than just scaling up the size of language models to GPTN. And one way to continue carrying forward progress on the underlying machine learning is to get product out of what suggestions do people like? What do they dislike?
15:42 Speaker 00 What are the hard pieces of human work that the AI still can't really access? And you get that if you're the pane of glass where the knowledge work happens. And so initially, we set out to do that for an area of knowledge work. We actually didn't know that well, which was mechanical engineering. And we worked on a co-pilot for computer aided design for a bit. And so we were training 3D autocomplete models. So helping people who are doing 3D modeling of a part that they want to build in something like SolidWorks or Fusion 360 and trying to predict kind of the next changes to the geometry they were going to make. And it's an interesting problem. It's one that academics have worked on. It's actually one that DeepMind's worked on a bit, too.
16:20 Speaker 01 And these were not large language models, per se.
16:22 Speaker 00 You can do it entirely 3D. Or what you can do is one thread that we worked on for a while is turning it into a language problem where you take the steps that someone's doing in a CAD system and you kind of turn it into method calls. So if they're making a circle, you make that a method call. And it's just kind of like a list of method calls. It's not really programming, but it sort of looks like it. The problem is if you're going to do it entirely text based, you're asking the model to do something really tricky, not just predict what the user is going to do next, but also in its mind's eye, simulate the geometry. Because CAD kernels, like the software underlying these CAD applications, they're fairly complicated. And just from seeing the sequence of actions a user took,
17:05 Speaker 00 it's kind of hard to hallucinate what the final thing looks like. It's pretty tricky. But we worked on that for a bit. We, there was a ton of data work to do there, a ton of data scraping, where there's CAD data that exists on the open internet. We needed to get that to make the models better and better. And then we put that aside. And that was for a couple of reasons. One was, we really weren't as excited about mechanical engineering as we were about coding. We were all coders. The other one was, I think that the science back then wasn't yet ready for 3D. It's like, the pre-trained models weren't that good at it. There wasn't a lot of data. There's orders of magnitude less data of CAD models on the internet than code. And so, it's hard to make a useful model, or it was back then hard to make a useful model for that domain.
17:44 Speaker 01 Did you end up going to sit with, I don't know, people who used CAD or machinists and people like that?
17:50 Speaker 00 So we did. We did tons of user interviews. And I think we could have done that even better. And I think that, again, on the maybe youthful naivete, we were operating day to day, week to week, counting tasks by the hours. And looking back on the time we spent on that, I think it would have been better upfront to actually just go work at a company that was employing mechanical engineers for three weeks.
18:13 Speaker 01 Just go undercover.
18:14 Speaker 00 Get a better sense for like the just salt of.
18:16 Speaker 01 Just get a job as a draftsperson.
18:18 Speaker 00 Yes, yes. I think that would have been immensely valuable. And substituting some of the like hundreds of user interviews for that. Yeah.
18:25 Speaker 01 I guess alongside that, you were also getting into training your own models to be able to do this, which were, and using RL. And that was very useful. And also, learning how to spin up, you know, large clusters to actually train these models.
18:38 Speaker 00 Yeah. So in that kind of period of false starts, we didn't know it at the time, but yeah, some of the stuff we did there ended up being useful for us. It was doing a lot of, you know, behavior cloning, less RL. But you were kind of looking at good examples of what humans did and then training the AI to do those things. But yeah, training large language models in the order of tens of billions of parameters was not something a ton of people were doing back then. Even though the kind of end product of the product and models that we were working on at that time wasn't that useful. It was a great dry run of training models at scale. And also doing inference at scale. They're both back then, and honestly, also now, there weren't that many people
19:21 Speaker 00 training 10 billion plus parameter scale large language models, machine learning models. And so the state of the infrastructure was very, very early. And we were doing things like forking Megatron LM or Microsoft DeepSpeed and kind of ripping out the internals and then deploying that for training. Even on the inference side of things, too, there were a couple of, during that period, a couple of things that we ran at scale. Now in Cursor, we do over half a billion model calls per day on our own inference. And some of the experience of doing inference back then and training back then has definitely been immensely useful for the Cursor experience.
19:58 Speaker 01 So one of the things that's, I mean, A, incredibly brave, but also incredibly prescient, was to take a moment and say, actually, we don't know enough about CAD. You know, we need to do something else. Was it a straight beeline from the CAD, training the CAD models? You know, sort of recognizing that scaling laws were holding? And here was a domain that, you know, we could go down. And then you realize, actually, we need to do something else. Like, what was it to actually pivot it to, you know, what it is today?
20:29 Speaker 00 It wasn't a straight beeline. We, I mean, being programmers ourselves and being inspired by products like Copilot and also papers like the early Codex papers. I remember at the time, one of the things we did to justify to investors that they should kind of like invest in our crazy CAD idea is we did the back of the envelope math for what Codex, the first coding model, costed to train. From my memory, it only cost about 90K or 100K by our calculations. That really surprised, surprised investors at the time and was kind of helpful in us getting enough money to pursue the CAD idea, where you had to start training immediately. So we always knew about coding. We were always excited about it. We were always excited about, you know, how AI was going to change coding.
21:12 Speaker 00 We had a little bit of trepidation about going and working on that space because there were so many people already doing it. And we thought Copilot was awesome. And, you know, there were dozens of other companies working on it, too, at the time. When we decided to put aside CAD, which was a little bit of an independent idea, that was sort of the science not really working out, us not really being excited about that domain. The thing that drew us back into coding was our personal interest. And the thing that gave us the confidence then to continue with it was One, seeing the progress that others had made over the course of nine months or whatever it was, felt like it was a little bit slower than it could have been. And then also just sitting down and thinking that if we were being really consistent with our beliefs, in five years, all of coding was going to flow through these models and
21:57 Speaker 00 the active programming was going to entirely change. And there were going to be all these jumps you needed, both at a product level and at a model level to get there. And the ceiling was just so high. And it really didn't seem like the existing players in the space were aiming for a completely different type of coding. It didn't seem like they had that ambition, like they were really set up to execute on that, too. That first experience taught us that building a company is hard, and so you may as well work on the thing that you're really excited about. And so, yeah, we set off to work on the future of coding.
22:26 Speaker 01 It sounds extra prescient in that Sam Altman sat in this chair maybe a year ago and talked about how if you're betting against the models getting smarter, that's bad. You should always bet that the models are going to get a lot smarter. And 12, 18, 24 months later, that's been only more and more true. And then it sounds like you had been taking that bet a full 12 months before even that was said.
22:50 Speaker 00 Yeah, we had a phrase back then, which was follow the line. And you wanted to always be following the line and planning for where the line was. I mean, kind of hearkening back to the scaling loss of like, you know, these things are just going to keep getting better and better and better.
23:03 Speaker 01 The classic Peter Thielism is what do you believe that nobody else believes? And you believe this, and you were so right that that's what allowed you to actually go to where the puck was going to be.
23:14 Speaker 00 Yeah, I think it was one of the things that was helpful. And now, obviously, it's become much more in vogue. But back then, you know, 2022 is this crazy pivotal year where you start at the beginning of the year, no one's really talking about AI. I mean, GPT-3 had happened the year before, Copilot had happened. Copilot was beta 2021, and then maybe GA 2022. And then it started picking up and you know, we still remember all the launches of, you know, instruct GPT, which made GPT three a little bit better. It was fine tuning on instructions. And then, uh, Dali in the summer, I remember that was kind of the visceral moment that convinced a lot of people who weren't focused on the space to be, to pay a bit more attention to it. But then there was, uh, palm and stable diffusion.
23:56 Speaker 00 And then you start to get RLHF, you start to get 3.5 and you have these models getting way better without a big increase in the training costs, which was an interesting development. But it rumored that to go from GPT three, which, you know, had existed for a while and didn't, you know, impress some people, but was certainly not the breakout moment chat GPT was to chat GPT. It's like a 1% increase in the training costs.
24:17 Speaker 01 Oh, my God.
24:18 Speaker 00 It was, you know, from fine tuning on instructions, RLHF, you know, some other details too.
24:22 Speaker 01 Do you remember, are there, were there like specific features or product choices that you made? Because you knew that the, uh, that the models were going to get not just a little bit smarter, but significantly smarter. Did that change specific products or roadmaps that ended up, you know, sort of causing you to win? Cause you mentioned, I mean, there were certainly maybe a dozen other companies that were quite good that, you know, were also in the area.
24:46 Speaker 00 So one of the product decisions that we made early on that was non-obvious, that came from being excited about a bit more of a radical future, was not building an extension and was building an editor. That was, was not obvious to people at the time. And yeah, that came from a place of thinking all of programming is going to flow through these models. It's going to look very different in the future. You're going to need a control UI. It also came too, from interesting anecdotes we knew about. So we knew, we knew a little bit about this, the internal inside baseball of building GitHub Copilot, the first version. The, the whole building GitHub Copilot story, from what I understand and, you know, don't have firsthand knowledge, so some of these details might be wrong, is pretty interesting. Where it started from a very solution and search for a problem place of being interested in just taking GPT three and making it useful for, for cutters.
25:31 Speaker 00 And I think it came from, uh, leadership. It came from the CEO of GitHub at the time. He just said, we need to be doing this. And he kind of sent a tiger team off, figure out.
25:37 Speaker 01 Was it Matt Friedman at the time? Yeah.
25:38 Speaker 00 That, yeah. My understanding is this came from Matt. And I think they spent almost a year wandering in the desert, experimenting with different product ideas. And of course, they had the, these were people really excited about the future of AI. So they thought immediately, can we just automate PR sent in a little before or it's time? And they worked on that for a bit and then decided that was impossible. And they tried all these other wacky product ideas until they just sit on the simple thing of autocomplete. But even after they got autocomplete to work, they needed to make changes at the editor level. They couldn't do it entirely as an extension. They had to go and change things in the mainline VS code and expose different editor APIs to even just show that ghost text. Then there was some, from my understanding, that was actually kind of hard to do organizationally.
26:21 Speaker 00 If you were going to need to change the editor for something as simple as ghost text autocomplete, we knew we were going to have to do it a bunch. And so that was non-obvious and we got a lot of flack for that. And we actually initially started by building our own editor from scratch, obviously using lots of open source technology, but not, you know, basing it off of VS code, kind of like how browsers are based off of Chromium. It was a little bit more akin to building, you know, all the internal rendering of a browser from scratch. And we launched with that and then we, then we switched to basing it off of VS code. But the editor thing was not obvious.
26:50 Speaker 01 So cursor's out. You made a bunch of decisions that turned out to be right. When did you know it was going to work?
26:58 Speaker 00 It took a little bit of time. If you'll remember, there's this initial year, roughly a year in the wilderness of, you know, working on something that was precursor to cursor and the mechanical engineering side of things. And then, you know, there was an initial development period for cursor that was fairly small before we released the first version to the public. I think that it was from lines of code to first public beta release. It was three months. But then there was this year of iterating in public at very small scale, where we had, did not have lightning in the model. And it was growing, but it was, you know, the numbers, numbers were small. Dialing in the product at that point took maybe a year of getting all of the details right. Then it was only after that initial period of cursor being out for nine months to a year
27:42 Speaker 00 of working on the underlying product, building out the team. Also, not just the product side of things, but also starting to get the first versions of custom models behind cursor to power, you know, underneath cursor, that things started to click. And then growth started to pick up. And then yeah, since then, it's been, you know, we sort of have a tiger by the tail.
28:03 Speaker 01 Amazing.
28:03 Speaker 00 And if we are to be successful, there's a lot of things that we need to continue to execute on in the future. I think one of the challenges we have and a lot of other companies in parallel spaces have is just the rate at which we need to build the company, I think, is really fast. And I think rules of thumb around don't grow headcount more than 50% or year over year.
28:22 Speaker 01 Iron loss.
28:23 Speaker 00 Yeah, have to have to be broken, I think.
28:25 Speaker 01 Interesting. Were there like true, sort of true north metrics or things that you and your co-founders were monitoring to figure out? Like, is this working? Was it, you know, week on week retention or open rate? Or how did that influence what you were working on in a given week?
28:41 Speaker 00 So we looked at all of the normal things like retention. For us, the main activity metric we looked at, or the, yeah, the main top line metric we looked at, we looked at revenue. We looked at paid power users measured by, are you using the AI four or five days a week out of seven days a week? And that was the number we were trying to get up. And why was it paid? Well, I think that we're a tool that serves professionals. And I also think that to deliver the tool, it has real costs. And so we care about you graduating to that paid tier. And that's, that's where things are sustainable. Paid power users, that was what we, you know, it wasn't DAUs, MAUs or anything like that. It was, are you using this every single day for your work? That's what we were trying to get up.
29:17 Speaker 01 And then once that was the metric, I guess, did you work backwards from that? It's like, well, we know the segment of people we want to grow. And then what do they want? Or what would prevent people from becoming that?
29:28 Speaker 00 I think that building for yourself doesn't work in a lot of spaces. For us, it did. And I think it was actually clarifying because one of the siren songs involved in building AI products is optimizing for the demo. We were really nervous about optimizing for the demo because with AI, it's, it's easy to kind of take a couple of examples and put together a video where, you know, it looks like you have a revolutionary product. And then I think that there's a long, you know, there's a lot of work between the version that can result in that great looking demo. And then a useful AI product, which means kind of dialing in the, the speed side of things, the reliability side of things, the intelligence side of things, the product experience side of things.
30:10 Speaker 00 For us, the kind of main thing that we really acted on was just, we reload the editor. Our product development process early on, it was very experimental. It was very focused on. Kind of like what we understand Apple to be like very focused on dog fooding and usable demos, like things we could just immediately start using in the editor internally. And then we would look at these metrics to make sure that, you know, week on week, month on month, we are kind of on the right path.
30:33 Speaker 01 So earlier you said, I mean, sometimes you got to break these iron laws around hiring. When did you decide to break it? I mean, was it just the co-founders and a few people until sort of, you know, some revenue goal? How did you think about the gas pedal? Did you like sort of feather it? And then like, once it was clear, like you hit your numbers, like we're pushing, pushing the pedal all the way down.
30:56 Speaker 00 So it was just the co-founders for a long time. And then the co-founders and a few people until we got to the point where things were really kind of dialed in and taking off.
31:04 Speaker 01 Who were some of the first hires? I mean, I assume more engineers, but you know.
31:07 Speaker 00 So we agonized over the first hires. And I think that if you want to go fast on the order of years, actually going slow on the order of, you know, six months is super helpful because if you really nail the first 10 people to come into the company, they will both accelerate you in the future because when, you know, the nth person comes in that's, you know, is thinking about working with you, comes in and hangs out with the team, they'll just be shocked by the talent density and then really excited to work there. And then the other reason they can help you go faster in the future is if someone comes in and they're not a great fit, these people act as an immune system against that, right? And they will be kind of keepers of holding the bar really high. And so we hired very, very, very slowly at the start.
31:48 Speaker 00 We were able to do that also partially because we had such a big founding team and all the co-founders were technical. But yeah, the people we got are fantastic and are really core to the company today. And folks who bled across disciplines where we are this company that needs to be something in between a foundation model lab and a normal software company. And the models and product have to work together under one roof. And so we had fantastic people who were product minded, commercially minded, but had actually trained models at scale.
32:17 Speaker 01 So generalist polymath is really, really great at sort of that first 10 people stage.
32:22 Speaker 00 Yeah, and making, building things quickly. Yeah, and shipping production good quickly.
32:27 Speaker 01 These days, I mean, everyone's sort of trying to figure out how to deal with this. But, you know, simply because the AI tools are so great, it's making it harder at times to even figure out, how do you? Evaluate great engineers. Has that changed over time for you as, you know, literally your own product has become more and more common? Do you select for people who are really great at using the AI tools? Or, you know, is it really just the, you know, let's stick with the classics and, you know, anyone could learn how to use the AI tools?
32:57 Speaker 00 Yeah. So for interviewing, we actually still interview people without allowing them to use AI other than autocomplete for our first technical screens. Programming without AI is still a really great time boxed test for skill and intelligence and kind of the, the things that you would always want someone on your team to, to have as a programmer. But then the other reason is we've hired lots of people who are fantastic programmers who actually have no experience with AI tools. And we don't want to unfairly disadvantage them because these tools are so useful. So we would much rather hire those people and then teach them on the job to, to use these things and also kind of mine the product insights from that beginner's mind of them using the tools for the first time.
33:33 Speaker 01 Cursor is now worth $9 billion. How do you keep the hacker energy alive, you know, as the team scales? And do you still write code?
33:42 Speaker 00 I do, yes. It's something that we think about a lot because I think that cursor in the future will have to look very different from the cursor of today. One, I, I think you can do it by hiring the right people. So the last step of our hiring process is a two day onsite where you come and you just work on a project with us. And so this is after an initial set of technical screens and you're in the office and you're kind of a member of the team and you come to meals with us and, and work on something and you demo it at the end and then we ask you questions. That gets at energy and excitement and passion for the problem space. And usually you're probably not going to be super willing to do that if you're maybe just view it as a job and you're applying to a bunch of, of technology companies at the same time. So I think a big way to do it is by getting passionate people through the hiring process.
34:27 Speaker 00 There are big projects that require a lot of coordination amongst people where you need top down alignment. I think that we always want to be a place that does a good degree of bottoms up experimentation, too. And so we really try and encourage that, both people taking time on the side to do that. And then also explicitly taking teams of engineers, sectioning them off from the rest of the company and kind of just giving them carte blanche to experiment on what they'd like.
34:50 Speaker 01 So one of the things that I think all startups and maybe all businesses right now are even trying to figure out in the face of some of the most impressive and incredible models in the world is what are the moats that are going to actually be durable and usable? How do you think about that?
35:06 Speaker 00 Well, I think that the the market that we're in and that others are in resembles markets that you've seen in the past that actually aren't enterprise software markets. So I think that a lot of enterprise software markets are kind of characterized by, well, there's sort of a low ceiling for the good core value you can deliver in the product. And there's a lot of lock in and the market we're in kind of mirrors search at the end of the 90s. Where the product ceiling is really high, search could get a lot better for a long, long period of time. And, you know, for us, the end goal is to replace coding with something much better and automate coding. And I think that there's a long, long, long way to go on that. One of the things that characterized search, and I think also characterized our market, is distribution is really helpful for making the product better.
35:50 Speaker 00 And so if you have lots of people using your thing, you have an at scale business, you get a sense of where the product's falling over and where it's doing well. And so in search, that's seeing, you know, what are people clicking on, what are they bouncing back from? What was a good search result, what is a bad search result, which then feeds into the R and D and then helps them make a better search engine. For us, it's seeing, you know, where are people accepting things, where are they rejecting things? In the places where they accept things and then they correct it later, what's what's going on there? How could we have been better? I think that that will be a really, really important driver to making the product better and kind of the underlying models better in the future. I think another market to take inspiration from is consumer electronics at the beginning of the 2000s. The thing there was getting the iPod moment right and then the iPhone moment, right?
36:31 Speaker 00 And, you know, I think the chat GPT moment is kind of like the iPod or iPhone moment of our age of if you keep pushing the frontier faster than other people, you can get really big gains occurring to you. And I think that there are a couple more of those that exist in our space. And so it's hard to do, but we're really focused on trying to be the ones to race toward those the fastest.
36:50 Speaker 01 It's 2025. I feel like we're actually even in the opening stages of this age of intelligence. What a revolution, you know, what are you personally most excited about right now?
37:01 Speaker 00 I think that this is going to be a decade where just your ability to build will be so magnified. Both people who already that's their living and that's what they do. But then I think it'll also become accessible for tons more people.
37:16 Speaker 01 What a time to be alive. Thanks for joining me today.
37:20 Speaker 00 Thank you. Thanks for having me.
Previous Fusion Energy Is Tech's Next Big Unlock Next Andrej Karpathy: Software Is Changing (Again) Page updated October 26, 2026 · transcript and summary are machine-generated
