We are in a market that's had a iPod moment and like it's going to have an iPhone moment.
And I think that there are definitely more in the future.
And we've tried to build a company that can continually build those things.
I don't think the API providers really knew what to make of us.
These four 20 somethings and their thing now comprises like a really high double digit percent of their API revenue.
And now they're going to have to make capacity planning decisions, maybe financing decisions.
I think that there's a big multi-product opportunity in our space, where there's a whole AI coding bundle to be built.
And we want to be, for many of our customers, the AI coding provider for them.
Today you'll hear from Michael Truel, CEO of Cursor, on building the fastest-growing developer tool we've ever seen, from taking down major cloud providers with their scale to becoming double-digit percentages of API providers' revenue, while still just being four 20-somethings.
We discuss why focus beats science fiction and the AI coding wars, how they maintain their infamous two-day work trials, even at 200-plus people, and the strategic art of hunting all the Sonnet tokens in the world.
Plus, the Ouroboros question.
What happens when the tool-disrupting software is itself made of software?
Let's get into it.
Thanks for being here, Michael.
Glad to be here.
He very, very rarely does these things, I had to beg.
So I really appreciate you coming up.
No, wouldn't miss this.
Yeah.
Okay, so as everybody knows, Michael's CEO of Cursor.
It's one of the fastest growing companies certainly we've ever seen.
It's everywhere.
It's crazy.
You have to hire, operate through that.
So actually what I want to do is dig into not the typical kind of founder journey what brought you here?
There'll be a little bit of that, but like, how are you handling the mayhem?
Is that cool?
Sure.
Yeah, no, that sounds great.
Okay, great.
So to start off with, we'll just do a little bit of history.
So I met with a company recently and they came in and they said, we are the 3D of Cursor.
And I said, funny story, because Cursor was once a 3D company.
Is that right?
Yes.
Do you mind talking about kind of a bit of the origin story?
Of course.
So there's a bunch of different ways you could actually peg the start date.
But effectively the way the company got started was my co-founders and I.
We were close colleagues from school and some other places.
And two moments got us really excited about building a company.
One was trying some of the first useful AI products.
And in particular... trying GitHub Copilot, the incumbent in our space.
And the reason this got us excited about starting a company is these products were actually useful.
And this was the first existence proof of we shouldn't be working on AI in a lab.
It's time to actually build systems out in the real world.
And there's real useful things that you could be doing.
The second thing that got us excited was scaling laws too.
We got excited about how it seemed like, even if the field ran out of ideas, the models would get better.
And so this was around 2021, beginning of 2022.
And then Cursor sort of came out of kind of a whiteboard exercise where we were very excited about a cursor for X for many different spaces.
And what does that mean?
We thought at the time that there would be, for a bunch of different verticals of knowledge work, the company that automates that area of knowledge work.
A company for each space.
And that company, it would do a couple of things.
The first thing it would do is it would build the best product for that space.
And it would define what the actual act of that knowledge work looks like as AI matures and gets better.
And then with that product it would win distribution, it would win a big business and it would get resources like data and capital.
And then it would back into being something that looks a little bit more lab-like though not a foundation model lab where it would start to use the data it gets access to to actually work on the underlying models and kind of push the autonomy in the space.
And then that would then in turn push forward the product and change what the best product looks like.
You get this flywheel going.
And so we were really, really, really interested in that.
And we thought that Microsoft would do that for coding.
And we wanted to work on a sleepy, less competitive space.
And we had some colleagues who did mechanical engineering, and we were familiar with CAD systems.
And so there was this initial false start of working on mechanical engineering actually, and working on mech models to help people be more productive within CAD systems, and also building our own sort of CAD system.
So that was how we got started.
It was a bad idea.
The founder market fit was horrible.
There was this blind man and the elephant problem, where we would hop on calls with Mac-ees and ask them what they do during their days.
And we only, we never really had an intuitive sense for it.
I almost wish that, in the kind of six, seven months where we were working on that, we had just gone and been interns at a company to really learn the space.
But eventually eventually, we put that idea aside and kind of came back to the thing that we were really most interested in, which is working on programming.
So I've got this theory.
I would actually like to hear your views on it, on why Cursor did so well early on.
And it's actually pretty banal, which is at the time we were surveying the space and there's a lot of companies and they were doing a lot of different things.
And a lot of it was pretty science fiction.
We're going to create an agent that will be a software engineer.
We're going to create a model using this new technique.
We're going to do all the things.
We're going to rewrite the editor, etc.
And one of my theories early on Cursor did well is you were incredibly focused.
You chose VS Code.
Copilot had matured the market for a few years at the time and it was this narrow focus and just a way way, way better product that did it.
And so two questions, A, do you think this is a legit view on it?
And then the second question is how did you decide to maintain focus when everybody else was doing everything else?
Because it was the time to build the agents or build the model.
Yes, I definitely think that there's a lot of truth to that.
I think that also there's an important asterisk in that the story of this company is still yet to be written, and there's so much more to do too.
To get to this point, the success to this point, there was just such an updraft.
Yes, so going back to when we were working on the CAD stuff, the cold start problem in that space was much harder than in our space, where to get started on helping people be more productive and building mech-y models of stuff that they were going to make in the real world.
None of the out-of-the-box models were good at that stuff.
There was actually no good 3D representations to open source 3D models that had transfer.
If you took the existing text-based LLMs and you tried to get the LLMs to be good at CAD, they weren't really.
And so much of our time spent working on the CAD idea.
In addition to calls with mechies where we didn't really understand what they did in their day job, which was obviously a big problem, it was spent doing a lot of modeling work and a lot of data scraping work.
And we kind of had PTSD from that when we decided to put it aside and work on programming.
And so initially yes, we were super focused, we were super expedient and we did hack on, hack on hack to just get something out into the world as fast as possible and start to get some momentum.
And part of that was we didn't have, we had some funding, but nothing like the seed rounds of today, and we had four co-founders and still we talked about hiring, expanding the team, but i think we were still really fully learning how to do that.
And so yes, the competitive landscape at the time it was Microsoft, it was dozens of startups.
These startups fit into a bunch of different buckets.
There were some that were immediately trying to build big foundation models.
There were some that had highfalutin product ideas of like very different changes in people's workflows.
And we just tried to get something out as fast as possible.
And I remember at the time the like commitment device for us was actually the monthly investor update, which probably no one read at the time.
But It was, I think, from day one deciding to work on Cursor.
It was a couple of weeks to actually have an IDE that we used ourselves.
And initially, we didn't even fork the S code.
We actually built from scratch.
So we built IDE from scratch that we used ourselves as a daily driver.
A couple more weeks to actually get into other people's hands.
And then, in the span of total I think a couple of months, we had launched our first beta out to the internet and immediately it started to get interest from people.
And then that kind of set off the momentum.
Specifically, while the momentum was building, a number of the people in the same space were broadening very quickly.
Like they'd go to CLI very quickly or they would like integrate with IntelliJ or whatever it was, and you decided not to.
Was this like super intentional or was just?
You know you're getting pulled on the right one, like you had enough work to do.
Yeah, the ideas were intentional in that sense.
We kind of just worked all the time.
And so the four co-founders every day would be breakfast, lunch, and dinner.
You're going to talk about.
You're going to debate endlessly these core strategic questions of do you build an editor and an extension?
Do you do anything on the model side of things?
And other, the initial product.
Build a new idea, yeah.
And...
Yeah, I think that we were really, really intentional about wanting to own the surface.
So at the time it's not super controversial now, but at the time people just thought it was very weird to do an editor.
Whether it was a fork or not a fork, they said you can't get people to switch their code editor.
They're too tied to it, which we knew was wrong because we had actually switched the VS Code ecosystem because of Copilot.
We were all like Luddites using command line Vim.
And so we knew that if you built a better mousetrap, you could get people to switch.
The bar would be high.
Okay.
And then yeah, we were very, very intentional about eventually in the future, we want to touch the model side of things.
And there's been a whole story of backing into that.
And that's actually been a really important product lever for us.
But we didn't want to start there.
We wanted to just get something out to the world, not touch any of the modeling stuff.
Awesome.
Okay, so I told you this anecdote and you said you didn't remember it but I remember it very well which is the early days were about scale.
And I've seen a lot of companies over the years.
I've been in the industry for 30 years.
I've never seen scale like this quickly, especially with a small team.
And I remember one night I got a call from you and you were like listen, we've taken down one of the big clouds because they can't handle our scale.
And there was this actually relatively minor service disruption.
And then you guys fixed it actually pretty quick and it was fine.
But apparently in that time or so, Oscar tells me someone showed up at the cursor office and put an iPad on the window and says cursor's down.
So definitely it was to a point where people were noticing.
For me it was kind of a shock because it was kind of this nondescript building that they found out.
So it would be great to hear how you think, and the team thinks, about handling this much scale, especially because, I mean, you're really at the point that you're even stressing the platforms you rely on, even though they're some of the largest platforms.
I mean, there's nowhere to go.
Yeah, that anecdote is lost within the... Of the many, of the many, yeah.
Back in the day.
Yeah, I think that well early on, the way we encountered scale was just it was such a tiny team operating a service that started to to grow very fast.
And my co-founders are great.
But we're not the most experienced group, if you can't tell, just in terms of years of experience.
And so, yeah, very quickly, we had lots of people using the service.
There's ways in which, especially with things like we have our own file sync system, that you can think of it as like there's kind of two or three different sort of mini Dropboxes within Cursor, where early on within Cursor there's kind of like a search engine for the AI.
And it seems like a kind of.
On the surface it doesn't sound like it should be that complex, but it ends up being kind of annoying to build.
And depending on how you build it, definitely can start stressing the systems that you rely on.
But yeah, very quickly we were getting to a scale when it came to just normal boring cloud services stuff.
And so there was a whole story of, you know, we were running a very, very large Kubernetes cluster, larger than many other companies.
And then trying to figure that out on the fly with five total people at the company and having things, you know, having hiccups and troubles with that.
Then we sort of just got a handle of that by making some of the right architecture decisions, growing the team.
Then the next big scaling problem that came up was actually just stressing the API providers.
And that was less a, being very clever technically to get past that scale.
And that was more a relationship thing where, you know, I don't think the API providers really knew what to make of us, because it's, you know, these four 20-somethings and their thing now comprises like a really high double digit percent of their API revenue.
And now they're going to have to make capacity planning decisions.
Maybe financing decisions, to you know, handle the growth under the hood.
And that was more of just a, And I think it's something we're still learning forging relationships with people.
It was also getting very clever about turns out these tokens, these API tokens.
You can get them for the same model for many providers.
There are token resellers that exist out there.
And it's strategically helpful actually to spread it across multiple providers which have committed contracts.
And so we got very good at hunting out all the Sonnet tokens that exist in the world.
And so that was a level of scale that was tricky for us.
I'd say right now we do a decent bit of our own training.
We do some of our own inference.
And so there's, like now, a whole.
You know There's a whole new scale problem there in making decisions there.
Do you think that this converges on heterogeneous dependency on third parties?
Or do you think it converges on largely you running your own infrastructure?
Or have you not gotten that far?
For the underlying model inference?
No, just infrastructure in general.
More and more you're pulling stuff in-house just so that you have control of it.
Just for operating our website, desktop apps, the backend, things like that?
Yeah.
I think we've been pretty multi-cloud from the start.
And so I think we're definitely on a default path to heterogeneous, rely on multiple providers.
We have Databricks, Snowflake.
We're on AWS GCV and Azure for cell, for web stuff.
We use PlanetScale for databases and have had our whole.
You know, one of the scaling the kind of boring cloud services stuff was really reliant on our DB where there was a whole Kubernetes side of things, things like core DNS going down.
Then there was a whole series of DB stories where some of the things we're doing are like pretty DB heavy.
And eventually we got to a point where, well, usually you should just scale the RDS instance.
That works well for a long time.
Eventually you run out of that and then it's like, do you shard the database?
And then we switched to AWS's service, which claims to not let you shard the database.
Turns out, that's wrong.
Not so much, yeah.
You think of these public clouds as they have it all together, but really it's a very small set of customers for the highest level of scale and they're figuring it out on the fly.
And so PlanetScale has been amazing there, where we went from Limitless to PlanetScale.
Sam, are you here?
Thank you very much, Sam.
We appreciate it.
All us developers.
Here for Sam.
But yeah, no for us.
I think multiple providers are great at different things, and so that's our plan.
Just quickly, before we're going towards talent.
So you've had to balance focus, which you're very good at.
Since then, you've done a lot of multi-product stuff, right?
You did BugBot, you did CLI, you're doing infrastructure improvements.
To what extent is the decision to do this pretty organic and just obvious?
And to what extent do you kind of do prioritization in a more deliberate way?
Or maybe just walk through how you think about where to expand RD resources, given everything that you're dealing with.
It's pretty deliberate.
We try to say no to lots of things.
But I do think we're going to need to be a multi-product company going into the future.
I think that there's a big multi-product opportunity in our space, where there's a whole AI coding bundle to be built.
And we kind of want to be, for many of our customers, the AI coding provider for them.
And so far, that's really focused on this wedge, in which is, you know, the surface that you sit in, the pane of glass that you sit in when you're an engineer going about your day.
Building software, which is the editor.
We think that there's still so much more to do there, and that's the main focus.
That's where we spend resources.
We do think that the ways in which work is changing within the editor start to affect how teams work together too.
And so we think that that presents both a big strategic opportunity, it's also just, like, necessary to have the best editor thing, uh, is to also have this compliment that's, you know, helping teams review and collaborate a little bit more.
Um, and so, uh, we're intentional about it.
Uh, it's been, uh, we're, we're still, I think, learning how to, how to do it well.
Um, like how to give projects like that air cover um, how to do cross sell where um, there's really really big cross sell opportunities in our space, both from a like growth engineering PLG showed them the button side of thing and then, you know, enabling the sales team.
Oh, I will say there's like many founders under appreciate how tough it is to go from single product to multi-product when it comes to actually go to market.
I mean, it's, it's very, very complex.
Yeah.
And a lot we're still learning there but you know very, very excited by kind of the early results.
Awesome.
Okay.
I'd like to shift towards talent.
So I think you have one of the more rigorous and thoughtful talent hiring processes I've ever seen.
Like I try to like reserve a part of my evening and weekends to help you uh, to talk to and recruit people, and every and before i hop on every one of these calls, i get this incredibly well thought out like here's where it is, here's what we've done, you know.
I mean, i just think there's so much behind this process.
So if you wouldn't mind, can you just kind of walk through how you think about recruiting and kind of how you run your process and what you found out, what works and maybe what doesn't work?
Yeah, have your board members do lots of calls until they cry uncle.
Prepare their calls.
Take advantage of their time.
Yeah, how have we thought about recruiting?
I think that there are ways in which our process is pretty orthodox.
I think that some of the things that might be unique one is normally, when you're a small company, there's this thing that you do with the first set of engineers, where you basically just have people contract with you and you probably don't do a normal elite code style thing, a normal interview loop.
That's what we did.
It felt the most natural because you're kind of getting to the ground truth of do you work well with the person.
And then usually people stop it after a couple of hires.
We have, and we've tried to kill it many times internally.
I've tried to kill it too.
We still kind of do that where everyone who gets hired on the Eng team and the design team spends two days in the office and they work on a project.
And it's very free form.
It's not like you know.
You have this whiteboard interview and then that whiteboard interview and your days, two days, are packed.
It's here's a desk, here's a laptop, you know, here's three projects you could work on.
Here's a frozen version like of an, you know a frozen older version of the code base with the DevEx setup.
Just go do it.
And then you, this functions, this has kind of two functions.
So one function is I think it's a really great test for orthogonal things to the normal coding style interviews that we ask before people get on site.
Where you're seeing, can they go end-to-end in the code base?
Are they agentic?
Our engine design and product are pretty tightly coupled.
And so we try to hire product engineers who have product sense.
This gives you a sense of that.
What would they build if left in a vacuum without a team?
And so I think it really gives us a lot of signal on the raw technical skills needed to be successful in our environment.
The other thing that it does for us is it also functions as a culture interview, where you have four to six meals with us.
And, you know, that gives us a sense of would we want to be around you?
Do you want to be around us?
If one of the benefits you know, maybe a sub point, third benefit is it really gives the candidate a ton of information about the company and what it's going to be like to show up on the first day.
And I think that that's led to you know, really really really high chance of fit on their end too, if they say yes.
And so that's one of the more unorthodox things we do is we have this two-day onsite and we've clung to it, even though we are over 200 people now.
But you don't do this with like go-to-market or other... We did initially.
So yeah.
What do you do with a sales guy?
Yeah.
So to hire our first reps, we would give them, we're like, here are inbound leads.
That's awesome.
You have a quota.
Yeah.
Yeah.
It was, yeah, it was a little bit more structured where, you know, they would do a demo.
They would do some like mock customer communications.
But we would give them access to the real data and have them dig in.
I think the very, very, very first one we did was literally like the rep came in.
We showed them everything.
We're like, teach us how we should do sales.
But then it started to get more structured.
Okay, awesome.
Great.
So listen, I think this wave in general is changing a lot of orthodoxy. on how you build companies.
I mean, it's just, it's a new super cycle.
Like, you know, we're questioning everything.
You're definitely on the forefront of that.
I mean, you've got you know, relatively I would say, junior folks running very large orgs and it's working out incredibly well.
Another thing that you're doing, I mean, I would say almost to like an extreme amount is M&A.
Like you've been very, very good at doing these kind of tuck-ins for two-year-old company, right?
Like I mean clearly a lot of private companies acquire companies, but you've done a great job about that.
Would you be open to sharing kind of how you think about this?
I mean, like, the adage pre-AI was like, startups should never buy startups.
And it's actually been hugely successful, not just with Curse, but across the board.
And so I think it'd be great to hear how that's worked for you, any lessons learned.
Yeah, I think that so far for us it's been consistent with an approach of do anything possible to get the most talented people.
And so, you know, early on, as part of our...
You know, us growing the initial 10 people on the team, we did crazy recruiting stunts like, you know, flying.
Yeah, some of these are kind of normal when people do them, but a lot of things like flying across the world to the person after they say no.
And then, when they say no, after you fly across the world you make up a dinner with researchers that's happening in SF, that they should totally fly to and come to six months later so that you can reignite the conversation and convert them to be an engineer.
And then they end up being one of the best people on the team.
That happened.
So yeah, we've really tried to get the most talented people possible.
And I think that sometimes, either conveniently or inconveniently, those people are working on companies, and that's where mostly it's come from.
It's come from the talent side of things.
I think increasingly in the future, with the whole suite of products that are possible in our space and with the benefits we think of bundling those together, we're especially interested in, earlier than most companies in their maturity, using M&A as a strategic tool also to start to build out a couple of like GM type structures within the company and add on complimentary products.
And yeah, that's something where you know, for each new product that becomes possible in our space, we might try doing it internally.
We might look to see what the market has to offer.
And if there's really the right fit with the right set of founders, you know we'd love to join up with them.
Yeah, that's a little bit about how we thought about it so far.
The first real M&A we did was SuperMaven.
And so this...
As just one concrete example, this was a team of five people.
It was started by the person who had built GitHub Copilot before GitHub Copilot, which was Tab9 and was also a researcher at OpenAI, had done a bunch of work with John Thinking Machines and Jacob's fantastic
And he was working on We were working on autocomplete models.
He was working on autocomplete models.
The technology we were doing was very complimentary and just really built a relationship stayed close over many months.
It was really us approaching him and being kind of aggressive.
I have to wrap it up now, but I want to ask you one more question.
This actually came from one of your candidates.
I just thought it was such a clever way to phrase it.
He's like, you know what?
Cursors disrupting software. which we all agree.
I mean, this whole AI wave is disrupting software.
And he said, but Cursor is written in software.
So to what extent is this Ouroboros somehow, you know, ushering in your own disruption?
And I thought it was nicely philosophical.
So I love any thoughts you had, because my answer to him was like well, I'd rather be the one disrupting than not.
But, you know, that felt like a very VC thing to say.
Yeah.
Wait, and so it's still like Cursor's doom narrative.
Like if Cursor's so good, then someone could No.
This is something I was super excited to.
It was a very philosophical person, super excited to join.
And it was like basically listen, if you're focused on building the disruption, but the foundation of the product is what's being disrupted, what does that actually mean?
Yeah, I think that maybe two things.
One is, I think, despite the headlines, despite how much demand there is in this market and how much software's changed for the last few years, it's so far away from being automated.
100%.
It's so inefficient building software in a professional setting, especially with anywhere from dozens to tens of thousands of people.
It's just, it's really easy at an executive level to underestimate just how far away we are from the limit of automating software.
So I think that there's a really, really long way to go.
There's a really long, messy middle.
And then, yeah, I think that one of the challenges is challenges facing the company in the future and we've faced in the past is we are going we are in a market that's like you know had a ipod moment and like it's gonna have an iphone moment and another iphone moment and uh i think that there have been a couple of those so far i think that there are definitely more in the future and we've tried to build a company uh to be a place that that can continually build those things yeah because if we don't you know uh uh we're kaput And I think that it's actually, you know, it's a challenge.
It's one of the nice things about the physics of the space too, because I think it's one of the things that makes it pretty tricky for a Microsoft to really compete in a big way.
But yeah, definitely, definitely a challenge.
Awesome.
Great.
Well, thank you so much.
Please give the mic a hand.
Thank you so much for coming.
Thanks for your leadership.
Thanks for listening to this episode of the A16Z podcast.
If you liked this episode, be sure to like comment subscribe, leave us a rating or review and share it with your friends and family.
For more episodes, go to YouTube, Apple Podcasts and Spotify.
Follow us on X and A16Z and subscribe to our sub stack at a16z.substack.com.
Thanks again for listening and I'll see you in the next episode.
As a reminder, the content here is for informational purposes only.
Should not be taken as legal business tax or investment advice or be used to evaluate any investment or security or.
Please see a16zcom forward slash disclosures.
