--:-- Host (Martin Casado): Welcome to the a16z Podcast, I'm your host Martin Casado. Today, we're in a market that's had an iPod moment, and 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 that API providers really knew what to make of us, these four 20-somethings, and their thing now comprises 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.
--:-- [Music transitions]
--:-- Host (Martin Casado): We discuss why Focus beats 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 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. Yeah, appreciate it. He very, very rarely does these things I had to beg. So I really appreciate you coming up. No, wouldn't miss it. 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.
--:-- Host (Martin Casado): 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.
--:-- Host (Martin Casado): 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.
--:-- Host (Martin Casado): 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, 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, yeah, 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.
--:-- Host (Martin Casado): 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 Mac E's and ask them what they do during their days. And 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 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.
--:-- Host (Martin Casado): 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 was 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 why 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.
--:-- Host (Martin Casado): 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. Oh, course, yeah, yeah, yeah.
--:-- Host (Martin Casado): To get to this point, I mean 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 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 representation steward, like 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.
--:-- Host (Martin Casado): And so much of our time spent working on the cat 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.
--:-- Host (Martin Casado): 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 highfalutin product ideas of very different changes in people's workflows. And we just tried to get something out as fast as possible.
--:-- Host (Martin Casado): And I remember at the time, the 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 VS 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.
--:-- Host (Martin Casado): 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 it just, you know, you're getting pull 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 it. You're going to debate endlessly these core strategic questions of, do you build an editor or an extension? Do you do anything on the model side of things? And other, the initial product. Build a new idea.
--:-- Host (Martin Casado): 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.
--:-- Host (Martin Casado): 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 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.
--:-- Host (Martin Casado): 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.
--:-- Host (Martin Casado): 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 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 years. Of the many, of the many, yeah. Back in the day.
--:-- Guest (Michael Truel): 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, 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, 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.
--:-- Guest (Michael Truel): 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 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, we're running a very, very large Kubernetes cluster, larger than many other companies.
--:-- Guest (Michael Truel): And then trying to figure that out on the fly with five total people at the company and 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.
--:-- Guest (Michael Truel): 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, 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.
--:-- Guest (Michael Truel): 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 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?
--:-- Guest (Michael Truel): For the underlying model inference? 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, backend, things like that? 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 on AWS GCP 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.
--:-- Guest (Michael Truel): 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 switch 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.
--:-- Host (Martin Casado): 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 kind of where to expand R&D resources given everything that you're dealing with.
--:-- Guest (Michael Truel): 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.
--:-- Guest (Michael Truel): 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 is to also have this complement that's, you know, helping teams review and collaborate a little bit more. And so we're intentional about it.
--:-- Guest (Michael Truel): 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 growth engineering PLG, show them the button side of thing, and then enabling the sales team. I will say there are many founders underappreciate 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.
--:-- Host (Martin Casado): Okay, then I'd like to shift towards talent. So I think you have one of the more rigorous and thoughtful hiring processes I've ever seen. I try to reserve a part of my evening and weekends to help you talk to and recruit people and before I hop on every one of these calls I get this incredibly well thought out here's where it is, here's what we've done. I just think there's so much behind this process so if you wouldn't mind can you just walk through how you think about recruiting and how you run your process and what you found out what works and maybe what doesn't work.
--:-- Guest (Michael Truel): Yeah, have your board members do lots of calls until they cry uncle. Prepare them all. 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 lead code style thing, a normal interview loop. That's what we did.
--:-- Guest (Michael Truel): 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 try 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, and your two days are packed. It's here's a desk, here's a laptop, here's three projects you could work on, here's a frozen version of an, a frozen older version of the code base with the devX setup, just go do it.
--:-- Guest (Michael Truel): And then you, this functions, this has kind of two functions. So one function is, I think it's a really great test that tests 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. You know, what would they build if left in a vacuum without a team?
--:-- Guest (Michael Truel): 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 that gives us a sense of would we want to be around you? Do you want to be around us? One of the benefits, 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.
--:-- Host (Martin Casado): Okay, awesome. So listen, I think this wave in general is changing a lot of orthodoxy on how you build companies. I mean, it's a new super cycle, like we're questioning everything. You're definitely on the forefront of that. I mean, you've got relatively, I would say, junior folks running very large orgs and it's working out incredibly well. Another thing that you're doing, I would say almost to 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.
--:-- Host (Martin Casado): Clearly a lot of private companies acquire companies, but you've done a great job about that. Would you be open to sharing how you think about this? 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?
--:-- Guest (Michael Truel): 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 early on, as part of us growing the initial 10 people on the team, we did crazy recruiting stunts like 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.
--:-- Guest (Michael Truel): 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, 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.
--:-- Host (Martin Casado): 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.
--:-- Host (Martin Casado): And it was really us 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, 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, which we all agree. I mean, this whole AI wave is disrupting software. And he said, but cursor's written in software. So to what extent is this Ouroboros somehow ushering in your own disruption? I thought it was nicely philosophical.
--:-- Guest (Michael Truel): Yeah. Wait, and so it's still like, cursors do narrative. Like if cursor's so good, then someone could... No, this is someone who 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, you know, the foundation of the product is what's being disrupted, what does that actually mean?
--:-- Guest (Michael Truel): Um 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 in a professional setting 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.
--:-- Guest (Michael Truel): 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.
--:-- Guest (Michael Truel): 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 a challenge.
--:-- Host (Martin Casado): 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 at A16Z and subscribe to our Substack at a16z.substack.com. Thanks again for listening, and I'll see you in the next episode.
