a16z Podcast - 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 XFind a16z on LinkedInListen to the a16z Podcast on SpotifyListen to the a16z Podcast 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 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 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, 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 more or 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 meckies 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, 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, A, 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, they were just such an

updraft, yeah, yeah. 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, 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 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 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 fluid in product ideas of 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 Intelli 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 and build a new idea 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 co-pilot

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

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 and says cursor's down. So like definitely it was like to a point where people are noticing. For me, it was kind of a because it's 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. And, but, you know, we're not the most experienced group, if you can't tell, just in terms of years of experience. And so, yeah, very quickly, you know, 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 we're 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 stress. 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 like now a whole you know

side of the scale uh there's there's a whole new scale problem there and making decisions there do you think that this converges on you know heterogeneous dependency on third parties or do you think it converges on largely you're running your own infrastructure or like Have you not gotten that far? For the underlying model inference? Yeah, yeah, yeah. No, no, no, just, 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. And we have, we're on AWSGGV and Azure for sell for web stuff.

We use Planet Scale for databases and I've 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 Cordy DNS 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. 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 a AWS service which claims not let you start 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 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 plant scale sam sam are you here thank you very much sam we appreciate it all this developers For Sam. But, yeah, no, for us, I think multiple varieties, 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 kind of where 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 these. 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 to. 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 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, you know, enabling the sales team. I will say there, 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 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. Like, 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.

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've run 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, yeah. Take advantage for 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 uh we still kind of do that where everyone who gets hired on

the edge team and the design team uh spends two days in 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 uh 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 devs set up. 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, 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. You know, 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 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 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 a little bit more structured where 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 M&A. You've been very, very good at doing these kind of tuck-ins for a two-year-old company, right?

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, you know, 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, know 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, you know, 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 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, would 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 before GitHub co-pilot, which was Tab 9.

and was also a researcher at OpenA.I. I 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 technology we were doing was 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. I have to wrap it up now, but I want to ask you one more question. Sure. Okay, and 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's disrupting software. And which we all agree. I mean, this whole AI way was 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.

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, 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 who's 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 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, key 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 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 there are 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, my hand. We're coming in doing this. 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 Podcasts, 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 Thank you.