The a16z Show - Michael Truell: How Cursor Builds at the Speed of AI

Episode Date: November 10, 2025

When four MIT grads decided to build a code editor while everyone else was building AI agents, they created the fastest-growing developer tool ever built. Cursor CEO Michael Truell joins a16z’s Martin Casado to discuss the deliberate constraints that led to breakthroughs: why they rejected the "democratization" narrative to focus on power users, how their 2-day work trials test for agency over credentials, and the strategic decision to own the editor when conventional wisdom said it was impossible. Resources:Follow Michael on X: https://x.com/mntruell Stay Updated: If you enjoyed this episode, be sure to like, subscribe, and share with your friends!Find a16z on X: https://x.com/a16zFind a16z on LinkedIn: https://www.linkedin.com/company/a16zListen to the a16z Podcast on Spotify: https://open.spotify.com/show/5bC65RDvs3oxnLyqqvkUYXListen to the a16z Podcast on Apple Podcasts: https://podcasts.apple.com/us/podcast/a16z-podcast/id842818711Follow our host: https://x.com/eriktorenbergPlease note that 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; and is not directed at any investors or potential investors in any a16z fund. a16z and its affiliates may maintain investments in the companies discussed. For more details please see a16z.com/disclosures. Stay Updated:Find a16z on YouTube: YouTubeFind a16z on XFind a16z on LinkedInListen to the a16z Show on SpotifyListen to the a16z Show on Apple PodcastsFollow our host: https://twitter.com/eriktorenberg Please note that 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; and is not directed at any investors or potential investors in any a16z fund. a16z and its affiliates may maintain investments in the companies discussed. For more details please see a16z.com/disclosures. Hosted by Simplecast, an AdsWizz company. See pcm.adswizz.com for information about our collection and use of personal data for advertising.

We are in a market that's had a iPod moment, and it's going to have an iPhone moment. And I think that they're 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, like the AI coding provider for them.

Today, you'll hear from Michael Truel, CEO 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 beat science fiction in 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 Oroboros 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. Yeah. Appreciate it. He very, very rarely does these things I had to beg. So I really appreciate you coming up. No, I wouldn't miss this.

Yeah. Okay, so as everybody knows, Michael's CEO of Cursor, it's one of the fastest growing company, certainly we've ever seen. It's everywhere. It's crazy. You have to hire Oursors. operates through that. So actually what I want to do is dig into, not the typical kind of founder journey, what brought you here that'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, okay. 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 co-pilot, 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 with 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 sleep be 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 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 in the elephant problem where we would hop on calls with Mackeys 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 a 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, et cetera. And one of my theories, like, 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, hey, do you think this is a legit view on it? And then the second question is, like, 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. If you get to this point, like the success to this point, I mean, there was just such an updraft. Yes. So going back to when we were working on the CAD stuff, the Cold Star problem in that space was much harder than in our space, where to get started on helping people be more

productive in building mechee 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 her, like open-source 3D models that had transfer. If you took the existing text-based LMs and you tried to get the LMs 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 MECEs 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 modeling work. lot of data scraping work. And we were high, 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 and 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 high-flued in 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 Cursar, 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 IDEE 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 CLA 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 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 data. Build a new idea, yeah, 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. 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 lover 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 he didn't remember it, but I remember 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're like, listen, we've taken down one of the big clouds because like they can't handle our scale. And there was this actually relatively minor service disruption. And then you guys fix 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, this is cursor's down. So like definitely it was like to a point where people don't know. 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 there are some of the largest platforms. I mean, there's nowhere to go. Yeah. Yeah, that anecdote is lost within the...

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 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 drop boxes within Cursor where, you know, early on, within Cursor, there's kind of like a search engine for the AI. And, you know, 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, stressing the systems that you rely on. But, yeah, very quickly we were getting to 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, these, 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, decisions, maybe financing decisions to handle the growth under the hood. And that was more of just a, and I think it's something we're still learning, you know, 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 now a whole side of the scale. There's a whole new scale problem there and making decisions there.

Do you think that this converges on heterogeneous dependency on third parties? Or do you think it converges on largely you're running your own infrastructure? Or have you not gotten that? for the underlying model inference. Yeah, yeah, yeah, yeah. No, no, no, no, just infrastructure in general.

Like 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 have, we're on AWSGCV and Azure for cell for web stuff. We use Planet Scale 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 CoreDNS going down. Then there was a whole series of DB stories where some of 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 switch to AWS service, which claims 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 Planet Scale has been amazing there, where we went from Limitless to Planet Scale. Sam, are you here? Thank you very much, Sam.

We appreciate it. All this developers, for Sam But yeah for us I think multiple of riders multiple varieties 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 bug bot you did CLI you're doing infrastructure improvements to what extent

is the decision to do this is 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 what to expend R&D 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 the for many of our customers, like the AI coding provider for them. And so far, that's really focused on this wedge in, which is 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,

And so we think that that presents both a big strategic opportunity. It's also just like necessary to have the best editor thing as to also have this compliment that's, you know, helping teams review and collaborate a little bit more. And so we're intentional about it. It's been, we're still, I think, learning how to do it well, like how to give projects like that air cover, how to do cross-sell where 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 enabling the sales team. I will say there, 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 very, very complex. Yeah, and a lot we're still learning there, but, you know, 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. I try to like reserve a part of my evening and weekends to help you to talk to and recruit people. 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. 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 of what works and maybe what doesn't work? Yeah.

Have your board members do lots of calls until they cry uncle. Prepare them. Yeah. Just take advantage of their time. Yeah, yeah. 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 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 office, and they work on a project. And it's very free form.

It's not like you have this whiteboard interview and then that whiteboard interview, your 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 of an, you know, a frozen older version of the code base with the devax 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, the test for orthogonal things to the normal coding style interviews that we ask before people get on site. Where you're seeing, you know, can they go end to end in the code base? Like, 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 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 on site 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 people? We did initially. So, yeah. To hire our first reps. Yeah.

So to hire our first reps, we would give them, we're like, here are our inbound leads. That's awesome. You have a quota. 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 teachers how we should do sales. But then it started to get more structured. Okay. Awesome. Great. So listen, I think this wave in general has changing a lot of orthodoxy on how you build companies.

I mean, 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, is M&A. Like you've been very, very good at doing these kind of tuck-ins for a 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 would be great to hear how 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. Yeah. 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, you know, are kind of normal when people

do them, but a lot of things like flying across the world to the person. Oh, yeah. 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 in the team.

That happened. So yeah, we've really tried to get the most talented people possible. And I think that sometimes, you know, 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 GM-type structures within the company and add-on, complementary 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 co-pilot, GitHub co-pilot, which was Tab 9. And was also a researcher at OpenAI, had done a bunch of work with John, thinking machines, and Jacobs, Jacob's fantastic. And he was working on, you know, we were working on auto-complete models.

He was working on auto-complete models. The stuff, the technology we were doing is very complimentary and just really built a relationship, stayed close over many months. And it was really us like approaching him and being kind of aggressive. All right. So I have to wrap it up now, but I want to ask you one more question. Sure. Okay. So this actually came from one of your candidates. I just thought it was such a clever way to phrase it. And he's like, you know what, cursor is disrupting software. And 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 Oroboros somehow you know, ushering in your own disruption.

And I thought it was nicely philosophical. So I love any thoughts you had. 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, cursors do narrative. Like, if cursor's so good, then someone could. No, this is someone I was super excited to.

It was a very philosophical person. It was super excited to join. And it was like, basically, listen, if you're focused on building the disruption, but. you know, 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, you know, anywhere from dozens to tens of thousands, sense of people. It's just, it's really easy to 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, key challenges facing the company in the future and we 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 going to have an iPhone moment and another iPhone moment. And I think that there have been a couple of those so far. I think that they're definitely more in the future. And we've tried to build a company to be a place that can continually build those things.

Because if we don't, you know, 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 Microsoft to really compete in a big way. But yeah, definitely, definitely a challenge. Awesome. Great. Well, thank you so much.

Please give them the mic. Michael Hand. We're coming at Dennis. Thank you so much for coming. Thanks for your leadership. Thanks for listening to this episode of the A16Z podcast. If you like 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 Podcast, and Spotify. Follow us on X at A16Z and subscribe to our Substack at A16Z.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, and is not directed at any investors or potential investors in any A16Z fund. Please note that A16Z and its affiliates may also maintain investments in the companies discussed in this podcast. For more details, including a link to our investments, please see A16Z.com forward slash disclosures.