Cursor CEO: Going Beyond Code, Superintelligent AI Agents And Why Taste Still Matters
37:28 Share

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.

Welcome back to another episode of How to Build the Future. Today, I'm joined by Michael Trull, 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. Thank you for having me.

Excited to be here. MARK MANDEL: 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. DAVID BAKAUS: 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 as 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, 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.

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? What are the steps to where you really want to go? 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 Nth order effects. 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. 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. On average, we see about people having AI write 40%, 50% of the lines of code produced within Cursor. But it's still a process of reading everything that comes out of the AI. And so an important chasm for us to cross as a product

we'll be getting to a place where 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 ways to go there. MARK MANDEL: In your head, do you think of it as different tiers? 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 just vibe coding it stops working, and that's when things sort of become real?

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 weeks. Right now, we're in this phase where

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, you know, an order of magnitude more useful.

Coding sometimes is incredibly predictable when you're just looking over someone's shoulder, you know, 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. 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 there, you interface with them like a human, like a helper.

Another way in which you can view LLMs is they're kind of an advance in 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, 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 after you get agents working, after you get the tab form factor very mature, does AI actually evolve what it means to be writing and looking at a programming language? MARK MANDEL: Is it a context window thing? It sort of makes sense that, well, once you get past about a million to two 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? Yeah, I think that there are a bunch of bottlenecks to agents being human level. I think one is context on their side of things is definitely an issue, where if you have 10 million lines of code, that's 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 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 have suspected you just make the context when it's infinite and that ends up working out. I think that there's a dearth of really good long context data that,

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 seconds to, I think,

I don't know the details of how these numbers are actually gotten, 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 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 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, sort of the skill of an entire engineering department, I think that the UI of just having a text box asking for a change to 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'll need a different way for them to interface.

one potential UI there is 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 finish with the values yourself. 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. 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

is not in the way you would a human. It is by basically collecting a bunch of data, doing RL on them. And that's 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 baked into the base model. But it's kind of a hack around the continual learning problem. So given this sort of future that everyone's building towards, and you're certainly a leader at the forefront of it, what do you think

will be irreplaceable or like sort of the essential pieces of being a software engineer in the future? 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 process.

you're doing, where you kind of know what you want, you could tell it to another human being, but you really have to spell it out for the computer. Because the language that 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 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, our tool that's helping you make things happen, helping you build things, that kind of taste for what is actually useful for what you want to build, I don't think will ever go away. That makes sense. 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. Yeah. So, and that requires taste. Yeah. 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? 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 1,000 people's software projects move and 100 people's software projects move and real kind of professional software projects move.

And a lot of that comes down to the weight of the existing logic, just kind of getting the best of you. When you're in a new code base, 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 fix. I think that one of the implications of it will be that the next distributed training framework or the next database or the next visual design tool will just be way faster to build.

the next AI model, which if you talk to the labs, largely they're bottlenecked on engineering capacity. I think all of that will just improve a ton. I think that 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. And it was a company staffed by wet lab scientists. They were developing drugs to cure diseases.

And I was the first software engineer hired. And they were generating massive amounts of chemicals and then putting them through these biological experiments. And then they needed a readout to kind of figure out 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 that company, there will just be many more options available to them. The physics of digital space already are so great, but I think that that's just going to get turned up.

many notches into the future. Things that you want to happen on computers will then just kind of be able to happen. MARK MANDEL: Switching gears, 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? I think we had a lot of youthful naivete, I think probably unjustified at the time. So from the start, we were pretty ambitious. Cursor came out of

an ambitious idea exercise, actually. For the four of us, 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. Another one of us worked on building actually a competitor to Google 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

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

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. 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 GPDN.

And one way to continue carrying forward progress on the underlying machine learning is to get product data of what suggestions do people like, what do they dislike, 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 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. And these were not large language models per se. 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, 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. 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. Did you end up going to sit with, I don't know, people who used CAD or machinists and people like that? 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 data

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. Just go undercover. Get better sense for like the gestalt of mechanical engineers. Just get a job as a drafts person. Yes, yes. And then see exactly what people do. I think that would have been immensely valuable. And substituting some of the like hundreds of user interviews for that. Yeah, yeah.

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 large clusters to actually train these models. 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 behavior cloning, less RL, but you were 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 end product of the products 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 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

you know, some of the experience of doing inference back then and training back then has definitely been immensely useful for the cursor experience. 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 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? It wasn't a straight beeline. We, I mean, it

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 cat 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 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 how AI was going to change coding. 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

And 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 interests. 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. It 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 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 code. 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. 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. The classic Peter Thiel-ism 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. 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, 2022 was 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 we still remember all the launches of InstructGPT, which made GPT-3 a little bit better. It was fine tuning on instructions. And then...

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 pay a bit more attention to it. But then there was Palm and Stable Diffusion, 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 cost, which was an interesting development. But it rumored that to go from GPT-3, which had existed for a while and didn't impress some people, but was certainly not the breakout moment ChachiBT was, to ChachiBT, it was like a 1% increase in the training costs. Oh, my gosh. Because it was from fine-tuning on instructions, RLHF, some other details, too. Do you remember, were there specific features?

features or product choices that you made because you knew 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 causing you to win? Because you mentioned there were certainly maybe a dozen other companies that were quite good that were also in the area. 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 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 to control the UI. It also came too from interesting anecdotes we knew about. So we knew a little bit about the internal inside baseball of building GitHub Copilot, the first version. The whole building GitHub Copilot story, from what I understand, and don't have firsthand knowledge, so some of these details might be wrong, is pretty interesting, where it started from a very solution in search for a problem place of being interested in just taking GPT-3 and making it useful for coders.

And I think it came from 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 tire team off to figure out-- MARK MANDEL: Was it Matt Friedman at the time? Yeah. MATT GAUNT: Yeah. My understanding is this came from Matt. And I think he spent almost a year wandering in the desert, experimenting with different product ideas. And of course, these were people really excited about the future of AI. So they thought immediately, can we just automate PR's intent 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. 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 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 all the internal rendering of a

browser from scratch. And we launched with that, and then we switched to basing it off of the S code. But the editor thing was not obvious. 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? It took a little bit of time. If you'll remember, there's this initial year, roughly a year in the wilderness of working on something that was precursor to cursor,

and the mechanical engineering side of things. And then 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 did not have lightning in the bottle. And it was growing, but the numbers were small. Dialing in the product

At that point, it 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 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 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. 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. All

Iron laws. Yeah, have to be broken, I think. Interesting. Were there like 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? How did that influence what you were working on in a given week?

So we looked at all the normal things like retention. For us, the main activity metric we looked at, or 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 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. 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? 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 easy to kind of take a couple of examples and put together a video where it looks like you have a revolutionary product. And then I think that there's

a long line, 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 speed side of things, the reliability side of things, the intelligence side of things, the product experience side of things. 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 dogfooding 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 were kind of on the right path. 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 some revenue goal? How did you think about the gas pedal? Did you sort of feather it and then once it was clear, you hit your numbers?

pushing the pedal all the way down. 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. Who were some of the first tire? I mean, I see more engineers, but you know, maybe not. So we agonized over the first tires. 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 nailed the first 10 people that 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. 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

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. MARK MANDEL: So generalist polymath is really, really great at sort of that first 10 people stage. BRIAN DORSEY: Yeah, and building things quickly, and shipping production code quickly.

These days, I mean, everyone's sort of trying to figure out how to deal with this, but 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 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 is it really just let's stick with the classics and anyone could learn how to use the AI tools? 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 box test for skill and intelligence and kind of the things that you would always want someone on your team 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 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. 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? 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 cursor of today. One, 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 work on something. Then 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 technology companies at the same time. So I think a big way to do it is by getting passionate people through the hiring process. 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 bottom-top 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. 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 for

How do you think about that? Well, I think that 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 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 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 characterize search, and I think also characterize our market, is distribution is really helpful for making the product better. 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

And so in search, that's seeing 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&D and then helps them make a better search engine. For us, it's seeing 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 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. And I think the chat GBT 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. 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? 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. What a time to be alive. Thanks for joining me today. Thank you. Thanks for having me.