Cursor CEO: Going Beyond Code, Superintelligent AI Agents (Transcript)

Another way in which you can view LLMs is they’re kind of an advance in compiler or interpreter technology. It’s going to be always helpful if we are a tool to help a human go from an idea in their head to something on the screen to give people control over the finest details. Right.

That’s one of the product challenges we have in front of us is you should always be able to move something a few pixels over. You should always be able to edit something very specific about the logic. I think one useful UI always to have there is to have written down the logic of the software and you can point at various bits of the logic and actually edit them.

But if we were to get to a place where you don’t have to pay attention to the code as much, that written down version of the logic of the software is going to have to get a higher level. And so yeah, we’re excited about after you get agents working, after you get kind of the tab form factor very mature. Does AI actually evolve what it means to be writing and looking at a programming language?

Context Windows and Technical Limitations

GARRY TAN: Is it a context window thing? It sort of makes sense that, well, once you get passed about a million to 2 million tokens, only even in I feel like the last hundred days did we get a usable 2 million token length. Is that naturally one of the places where once your code base reaches a certain size, you know, you got to use RAG, it has incomplete context and then it just can’t do what a human coder could do?

MICHAEL TRUELL: Yeah, I think that there are a bunch of bottlenecks to agents being human level. I think one is context window side of things is definitely an issue where if you have 10 million lines of code, that’s maybe 100 million tokens and both having a model that can actually ingest that and having it be cost effective and then not just having a model that can physically ingest that into its weights, but also one that actually pays attention effectively to that context window is tricky. I think that that’s something that the field needs to grapple with.

And it’s not just a code based thing there. It’s also just a continual learning problem of knowing the context of the organization and things that have been tried in the past and who your co-workers are. And that problem of having a model really continually learn something, kind of something that the field I think still doesn’t really have a great solution to.

It has always been suspected that it will be, or for a lot of people have suspected, you just make the context windows infinite and that ends up working out. I think that there’s a dearth of really good long context data available to the institutions that are training these models. And so I think that that will be tricky. But continual learning and long context is definitely a bottleneck to being superhuman.

It’s kind of related. But being able to do tasks over very long time horizons and continue making forward progress going around on the Internet, there’s this amazing chart of progress in the last year or two on the max length of time an AI can make forward progress on a task. And it’s gone up from seconds to I think, I don’t know the details of how these numbers are actually gotten, but I think someone’s claiming some of the latest models, it’s like an hour.

Then there are problems with different modalities. So to be a software engineer, you kind of need to run the code and then play with the output. If you didn’t, you would be way superhuman. That would be insane. But so computer using is going to be important for the future of code. Being able to run the code, being able to look at Datadog logs and interface with those tools that humans use.

There are a lot of known devils that we will have to face and then a lot of unknown devils that we will have to face in the task of making coding agents superhuman.

And then one thing I will note, hearkening back to a last response, is that even if you had something you could talk to that was human level at coding or faster and better than a human at coding, the skill of an entire engineering department, I think that the UI of just having a text box asking for a change in the software is imprecise.

And so even in the limit, if you care about humans being able to control what shows up on the screen, you will need a different way for them to interface. And so one potential UI there is an evolution of programming languages just be something that’s higher level. Another is maybe direct manipulation of the UI. Right. Being able to point at things on the screen and say, “oh, change this.” Or actually kind of finick with the values yourself.

The Challenge of Aesthetics and Design

GARRY TAN: Yeah, I mean that seems like a bunch of things that are kind of just nascent in the wings. Right. Like the models don’t seem to have a really clear sense for aesthetics, for instance. And so the idea that maybe this human level designer needs to actually, you know, be able to, they need to be able to see actually.

MICHAEL TRUELL: And it’s been interesting seeing them improve at the aesthetic side of things. And I think that that’s actually like an interesting specific example about how we’ve hacked around these continual learning problems.

But our understanding is that the way you teach these models to be better at something like aesthetics is not in the way you would a human. It is by basically collecting a bunch of data, doing RL on them. And that’s how you’ve taught at that task. And that’s a task that enough people care about that you can pay the cost to do all of that and you can go and train and have it baked into the base model. But it’s kind of a hack around the continual learning problem.

The Irreplaceable Element: Taste

GARRY TAN: So given this sort of future that everyone’s building towards, and you’re certainly a leader at the forefront of it, what do you think will be irreplaceable or sort of the essential pieces of being a software engineer in the future?

MICHAEL TRUELL: We think that one thing that will be irreplaceable is taste. So just defining what do you actually want to build? People usually think about this when they’re thinking about the visual aspects of software. I think there’s a taste component to the non-visual aspects of software too about how the logic works.

And right now the act of programming kind of bundles up you figuring out how exactly you want the thing to work, like what product you’re really defining with the logic that you’re writing and the kind of high level taste of the implementation details of how that maps onto a physical computer.

But then right now a lot of programming is kind of this human compilation that you’re doing where you kind of know what you want. You could tell it to another human being, but you really have to spell it out for the computer because the language that you have to describe things to a computer is for normal programming, just for loops and if statements and variables and methods and you really have to spell it out.

And so I think that more and more of that human compilation step will go away and computers will be able to kind of fill in the gaps, fill in the details. But since we are a tool that’s helping you make things happen, helping you build things, that kind of taste for what, what is actually useful for what you want to build, I don’t think will ever go away.

Logic Designers and Intent-Driven Programming

GARRY TAN: That makes sense. There’s that quote, “good people will help you hit this bar. But the truly great, the truly masterful, they hit a bar that you can’t even see.” And that requires taste. You’ve called it sort of people need to become logic designers. What does that mean in terms of intent driven programming?

The Future of Programming and AI Automation

MICHAEL TRUELL: As this tech matures more and more, as we get closer to a world where programming can be automated and can be replaced with a better way of building software, I think there are a bunch of implications. I think one is that professional devs will just get so much more productive. It’s just crazy how slow thousand people software projects move and 100 people software projects move and real kind of professional software projects move.

And a lot of that comes down to the weight of the existing logic just kind of getting the best of you. When you’re in a new code base, you can start from scratch, you can do things very quickly. When you change something, there’s not a bunch of other things that then break that you need to fix. I think that one of the implications of it will be that the next distributed training framework or the next database or the next visual design tool will just be way faster to build the next AI model, which if you talk to the labs largely they’re bottlenecked on engineering capacity. I think all of that will just improve a ton.

I think that one second order effect too will be many more pieces of niche software will exist. One of my first jobs actually was working for a biotech company. And it was a company staffed by wet lab scientists. They were developing drugs to cure diseases and I was the first software engineer hired. And they were generating massive amounts of chemicals and then putting them through these biological experiments. And then they needed a readout to kind of figure out which chemicals to then pursue further. And they needed a ton of just internal software development to do that.

And it was amazing both looking at the existing tools off the shelf, just how bad they were. And then it was crazy to think that this company, for whom software was not their core competency, had to go out and do this crazy laborious thing of hiring a real software engineering team and training them up and having them do internal product development. And for companies like that company, there will just be many more options available to them. The physics of digital space already are so great, but I think that that’s just going to get turned up many notches into the future. Things that you want to happen on computers will then just kind of be able to happen.

The Early Days of Cursor

GARRY TAN: Switching gears I wanted to hear about the early days of Cursor. You met your co founders, Swale, Arvid and Aman at MIT and this company started in 2022. What drew you together and when did you realize this was a team that could build something really ambitious together?

MICHAEL TRUELL: I think we had a lot of youthful naivete, I think probably unjustified at the time. So from the start we were pretty ambitious. Cursor came out of an ambitious idea exercise actually for the four of us. We all found programming fairly young. And then some of our first engineering projects actually had to do with AI. So one of us worked on improving the data efficiency of robotic reinforcement learning. So teaching robots very quickly to learn new tasks, that was one of our early AI projects. Another one of us worked on building actually a competitor to Google, using neural networks to try and sort of speed run building an amazing search engine for the web. Others did academic work in AI.

But there were two moments in 2021 that got us really excited about building a company that was focused on AI. One of them was using the first useful AI products where AI was really at the center. And GitHub Copilot was honestly the moment where that viscerally we really felt like now it was possible to make just really useful things with AI and that we shouldn’t go to work in a lab to work on these things in an academic lab. Instead it was time for this stuff to come out into the real world.

The other thing that got us really excited was seeing research come out of OpenAI and other places that showed there were these very predictable natural laws that showed if you scaled up the data and you scaled up the compute that goes into these models, they were just getting better. And so that meant that even if we ran out of ideas for how to make AI better, there were a couple of orders of magnitude of that to still run.

From the start, we wanted to pick an area of knowledge work and then work on what that knowledge work became. As AI got more mature, we were very interested in the shape of a company where you built a product for that area of knowledge work, because that lets you do a couple of things. One, as the underlying tech gets more mature, you can then evolve the form factor of what doing that thing looks like. And then two is even back then it was clear you were probably going to need more than just scaling up the size of language models to GPT N. And one way to continue carrying forward progress on the underlying machine learning is to get product data of what suggestions do people like, what do they dislike? What are the hard pieces of human work that the AI still can’t really access? And you get that if you’re the pane of glass where the knowledge work happens.

And so initially we set out to do that for an area of knowledge work we actually didn’t know that well, which was mechanical engineering. And we worked on a copilot for Computer Aided Design for a bit. And so we were training 3D autocomplete models. So helping people who are doing 3D modeling of a part that they want to build in something like SolidWorks or Fusion360 and trying to predict kind of the next changes to the geometry that we’re going to make. And it’s an interesting problem. It’s one that academics have worked on. It’s actually one that DeepMind’s worked on a bit too.

GARRY TAN: And these were not large language models per se.

MICHAEL TRUELL: You can do it entirely 3D, or what you can do is one thread that we worked on for a while is turning it into a language problem where you take the steps that someone’s doing in a CAD system and you kind of turn it into method calls. So if they’re making a circle, you make that a method call and it’s just kind of like a list of method calls. It’s not really programming, but it sort of looks like it.

The problem is if you’re going to do it entirely text based, you’re asking the model to do something really tricky. Not just predict what the user is going to do next, but also in its mind’s eye, simulate the geometry. Because CAD kernels like this software underlying these CAD applications, they’re fairly complicated and just from seeing the sequence of actions a user took, it’s kind of hard to hallucinate what the final thing looks like. It’s pretty tricky.

But we worked on that for a bit. There was a ton of data work to do there, a ton of data scraping where there’s CAD data that exists on the open Internet. We needed to get that to make the models better and better. And then we put that aside. And that was for a couple of reasons. One was we really weren’t as excited about mechanical engineering as we were about coding, we were all coders. The other one was, I think the science back then wasn’t yet ready for 3D. The pre trained models weren’t that good at it. There wasn’t a lot of data, there’s orders of magnitude less data of CAD models on the Internet than code. And so it’s hard to make a useful model, or it was back then hard to make a useful model for that domain.

GARRY TAN: Did you end up going to sit with, I don’t know, people who used CAD or machinists and people like that?

MICHAEL TRUELL: So we did, we did tons of user interviews and I think we could have done that even better. And I think that again on the maybe youthful naivete, we were operating day to day, week to week, counting tasks by the hours and looking back on the time we spent on that, I think it would have been better upfront to actually just go work at a company that was employing mechanical engineers for.

GARRY TAN: Three weeks, just go undercover, get a.

MICHAEL TRUELL: Better sense for the gestalt of just.

GARRY TAN: Get a job as a draftsperson and.

MICHAEL TRUELL: Then I think that would have been immensely valuable and substituting some of the like hundreds of user interviews for that.

Learning to Train Large Models

GARRY TAN: Yeah, I guess alongside that you were also getting into training your own models to be able to do this, which were, you know, and using RL and yeah, that was very useful. And also learning how to spin up, you know, large clusters to actually train these models.

MICHAEL TRUELL: Yeah. So in that kind of period of false starts, we didn’t know it at the time, but yeah, some of the stuff we did there ended up being useful for us. It was doing a lot of behavior cloning, less rl, but you were kind of looking at good examples of what humans did and then training the AI to do those things.

But yeah, training large language models in the order of tens of billions of parameters was not something a ton of people were doing back then. Even though the kind of end product of the product and models that we were working on at that time wasn’t that useful. It was a great dry run of training models at scale and also doing inference at scale, both back then and honestly also now there weren’t that many people training 10 billion plus parameter scale, large language models, machine learning models.

And so the state of the infrastructure was very, very early and we were doing things like forking Megatron LM or Microsoft DeepSpeed and kind of ripping out the internals and then deploying that for training. Even on the inference side of things too, there were a couple of, during that period, a couple of things that we ran at scale now in cursor. We do over half a billion model calls per day on our own inference. And some of the experience of doing inference back then and training back then has definitely been immensely useful for the cursor experience.

The Pivot to Coding

GARRY TAN: So one of the things that’s incredibly brave, but also incredibly prescient was to take a moment and say, actually, we don’t know enough about cad, you know, we need to do something else. Was it a straight beeline from training the CAD models, you know, sort of recognizing that scaling laws were holding and here was a domain that, you know, we could go down and then you realize actually we need to do something else? Like what was it to actually pivot it to, you know, what it is today?

MICHAEL TRUELL: It wasn’t a straight line. We, I mean, being programmers ourselves and being inspired by products like Copilot and also papers like the early Codex papers. I remember at the time, one of the things we did to justify to investors that they should kind of like invest in our crazy cat idea is we did the back of the envelope math for what Codex, the first coding model, costed to train. From my memory, it only cost about $90k or $100k by our calculations. That really surprised investors at the time and was kind of helpful in us getting enough money to pursue the CAD idea where you had to start training immediately.

So we always knew about coding. We were always excited about it. We were always excited about how AI was going to change coding. We had a little bit of trepidation about going and working on that space because there were so many people already doing it. And we thought Copilot was awesome and there were dozens of other companies working on it too at the time.

When we decided to put aside cad, which was a little bit of an independent idea, that was the science not really working out, us not really being excited about that domain. The thing that drew us back into coding was our personal interest. And the thing that gave us the confidence then to continue with it was one seeing the progress that others had made over the course of nine months or whatever it was, it felt like it was a little bit slower than it could have been.

And then also just sitting down and thinking that if we were being really consistent with our beliefs, in five years all of coding was going to flow through these models and the act of programming was going to entirely change and there were going to be all these jumps. You needed both at a product level and at a model level to get there. And the ceiling was just so high and it really didn’t seem like the existing players in the space were aiming for a completely different type of coding. It didn’t seem like they had that ambition, like they were really set up to execute on that too.

That first experience taught us that building a company is hard, and so you may as well work on the thing that you’re really excited about. And so, yeah, we set off to work on the future of code.

GARRY TAN: It sounds extra prescient in that Sam Altman sat in this chair maybe a year ago and talked about how if you’re betting against the models getting smarter, that’s bad. You should always bet that the models are going to get a lot smarter. And, you know, 12, 18, 24 months later, that’s been only more and more true. And then it sounds like you had been taking that bet a full 12 months before even that was said.

The Follow the Line Philosophy

MICHAEL TRUELL: Yeah, we had a phrase back then which was “follow the line.” And you wanted to always be following the line and planning for where the line was. I mean, kind of harkening back to the scaling loss of like, these things are just going to keep getting better and better and better.

GARRY TAN: The classic Peter Thielism is, “What do you believe that nobody else believes?” And you believe this, and you were so right that that’s what allowed you to actually go to where the puck was going to be.

The Pivotal Year of 2022

MICHAEL TRUELL: Yeah, I think it was one of the things that was helpful. And now, obviously, it’s become much more in vogue. But back then, 2022 was this crazy, pivotal year where you start at the beginning of the year. No one’s really talking about AI. I mean, GPT-3 had happened the year before Copilot had happened. Copilot was beta 2021, and then maybe GA 2022. And then it started picking up.

And we still remember all the launches of instruct GPT, which made GPT-3 a little bit better. It was fine tuning on instructions. And then DALL-E in the summer, I remember that was kind of the visceral moment that convinced a lot of people who weren’t focused on the space to pay a bit more attention to it. But then there was PaLM and stable diffusion.

And then you start to get RLHF, you start to get 3.5 and you have these models getting way better without a big increase in the training costs, which was an interesting development. But it rumored that to go from GPT-3, which had existed for a while and didn’t impress some people, but was certainly not the breakout moment ChatGPT was to ChatGPT, it was like a 1% increase in the training costs.

GARRY TAN: Oh my God.

MICHAEL TRUELL: It was from fine tuning on instructions. RLHF. You know some other details too.

Product Decisions Based on Future Intelligence

GARRY TAN: Do you remember were there specific features or product choices that you made because you knew that the models were going to get not just a little bit smarter, but significantly smarter? Did that change specific products or roadmaps that ended up sort of causing you to win? Because you mentioned, I mean there were certainly maybe a dozen other companies that were quite good that you know, were also in the area.

MICHAEL TRUELL: So one of the product decisions that we made early on that was non obvious, that came from being excited about a bit more of a radical future was not building an extension and was building an editor that was not obvious to people at the time. And yeah, that came from a place of thinking. All of programming is going to flow through these models. It’s going to look very different in the future. You’re going to need to control the UI.

It also came too from interesting anecdotes we knew about. So we knew a little bit about the internal inside baseball of building GitHub Copilot the first version. The whole building GitHub Copilot story, from what I understand and don’t have firsthand knowledge, so some of these details might be wrong. Is pretty interesting where it started from a very solution in search for a problem place of being interested in just taking GPT-3 and making it useful for coders. And I think it came from leadership. It came from the CEO of GitHub at the time he just said we need to be doing this and he kind of sent a tiger team off.

GARRY TAN: Figure out was it Matt Friedman at the time?

MICHAEL TRUELL: Yeah, my understanding is this came from Matt and I think they spent almost a year wandering in the desert experimenting with different product ideas. And of course they had the. These were people really excited about the future of AI. So they thought immediately, can we just automate PRs intent a little before or it’s time. And they worked on that for a bit and then decided that was impossible. And they tried all these other wacky product ideas until they just sit on the simple thing of autocomplete.

But even after they got autocomplete to work, they needed to make changes at the editor level. They couldn’t do it entirely as an extension. They had to go and change things in the mainline VS Code and expose different editor APIs to even just show that ghost text. Then there was some, from my understanding that was actually kind of hard to do organizationally if you were going to need to change the editor for something as simple as Ghost text autocomplete. We knew we were going to have to do it a bunch and so that was non obvious and we got a lot of flack for that.

And we actually initially started by building our own editor from scratch, obviously using lots of open source technology, but not basing it off of VS Code. Kind of like how browsers are based off of Chromium. It was a little bit more akin to building all the internal rendering of a browser from scratch. And we launched with that and then we switched to basing it off of VS Code. But the editor thing was not obvious.

When Did You Know It Was Going to Work?

GARRY TAN: So Cursor’s out. You made a bunch of decisions that turned out to be right. When did you know it was going to work?

MICHAEL TRUELL: It took a little bit of time. If you’ll remember, there’s this initial year, roughly a year in the wilderness of working on something that was precursor to Cursor and the mechanical engineering side of things. And then there was an initial development period for Cursor that was fairly small. Before we released the first version to the public, I think that it was from lines of code to first public beta release, it was three months.

But then there was this year of iterating in public at very small scale where we did not have lightning in the model and it was growing, but it was, you know, the numbers were small. Dialing in the product at that point took maybe a year of getting all of the details right. Then it was only after that initial period of Cursor being out for nine months to a year of working on the underlying product, building out the team also not just the product side of things, but also starting to get the first versions of custom models behind Cursor to power underneath Cursor that things started to click and then growth started to pick up.

And then, yeah, since then it’s been, you know, we sort of have a tiger by the tail and if we are to be successful, there’s a lot of things that we need to continue to execute on in the future. I think one of the challenges we have and a lot of other companies in parallel spaces have is just the rate at which we need to build. The company I think is really fast and I think rules of thumb around don’t grow headcount more than 50% or year over year. Iron laws, yeah, have to be broken, I think.

True North Metrics

GARRY TAN: Interesting. Were there true north metrics or things that you and your co founders were monitoring to figure out is this working? Was it week on week retention or open rate? How did that influence what you were working on on any given week?

MICHAEL TRUELL: So we looked at all the normal things like retention for us, the main activity metric we looked at or the, yeah, the main top line metric we looked at, we looked at revenue, we looked at paid power users measured by are you using the AI four or five days a week out of seven days a week and that was the number we were trying to get up. And why was it paid? Well, I think that we’re a tool that serves professionals and I also think that to deliver the tool it has real costs and so we care about you graduating to that paid tier and that’s, that’s where things are sustainable. Paid power users, that was what we, you know, it wasn’t DAUs MAUs or anything like that. It was are you using this every single day for your work? That’s what we were trying to get up.

GARRY TAN: And then once that was the metric, I guess. Did you work backwards from that? It’s like, well, we know the segment of people we want to grow and then what do they want or what would prevent people from becoming that?

MICHAEL TRUELL: I think that building for yourself doesn’t work in a lot of spaces. For us it did. And I think it was actually clarifying because one of the siren songs involved in building AI products is optimizing for the demo. We were really nervous about optimizing for the demo because with AI it’s easy to kind of take a couple of examples and put together a video where it looks like you have a revolutionary product.

And then I think that there’s a lot of work between the version that can result in that great looking demo and then a useful AI product, which means kind of dialing in the speed side of things, the reliability side of things, the intelligence side of things, the, the product experience side of things. For us, the kind of main thing that we really acted on was just we reload the editor. Our product development process. Early on it was very experimental. It was very focused on kind of what we understand Apple to be. Very focused on dogfooding and usable demos, things we could just immediately start using in the editor internally. And then we would look at these metrics to make sure that, you know, week on week, month on month, we were kind of on the right path.

Breaking the Iron Laws of Hiring

GARRY TAN: So earlier you said, I mean, sometimes you got to break these iron laws around hiring. When did you decide to break it? I mean, was it just the co founders and a few people until sort of some revenue goal? How did you think about the gas pedal? Did you sort of feather it and then once it was clear, you hit your numbers, we’re pushing the pedal all the way down.

MICHAEL TRUELL: So it was just the co founders for a long time and then the co founders and a few people until we got to the point where things were really kind of dialed in and taking off.

GARRY TAN: Who were some of the first hires? I mean, I assume more engineers, but.

MICHAEL TRUELL: So we agonized over the first hires. And I think that if you want to go fast on the order of years, actually going slow on the order of six months is super helpful because if you really nail the first 10 people that come into the company, they will both accelerate you in the future. Because when the nth person comes in, that is thinking about working with you, comes in and hangs out with the team, they’ll just be shocked by the talent density and then really excited to work there.

And then the other reason they can help you go faster in the future is if someone comes in and they’re not a great fit, these people will act as an immune system against that. Right. And they will be kind of keepers of holding the bar really high. And so we hired very, very, very slowly at the start. We were able to do that also partially because we had such a big founding team and all the co founders were technical.

But yeah, the people we got are fantastic and are really core to the company today. And folks who bled across disciplines. Where we are this company that needs to be something in between a foundation model lab and a normal software company. And the models and product have to work together under one roof. And so we had fantastic people who were product minded, commercially minded, but had actually trained models at scale.

GARRY TAN: So generalist Polymath is really, really great at sort of that first 10 people stage.

MICHAEL TRUELL: Yeah. And making build it. Building things quickly. Yeah, and shipping production code quickly.

Evaluating Engineers in the AI Era

GARRY TAN: These days, I mean, everyone’s sort of trying to figure out how to deal with this, but, you know, simply because the AI tools are so great, it’s making it harder at times to even figure out how do you evaluate great engineers? Has that changed over time for you? As you know, literally your own product has become more and more common. Do you select for people who are really great at using the AI tools, or is it really just, let’s stick with the classics and anyone could learn how to use the AI tools.

MICHAEL TRUELL: So for interviewing, we actually still interview people without allowing them to use AI other than autocomplete for our first technical screens, programming without AI is still a really great time. Boxed test for skill and intelligence and kind of the things that you would always want someone on your team to have as a programmer.

But then the other reason is we’ve hired lots of people who are fantastic programmers who actually have no experience with AI tools and we don’t want to unfairly disadvantage them because these tools are so useful. So we would much rather hire those people and then teach them on the job to use these things and also kind of mine the product insights from that beginner’s mind of them using the tools for the first time.

Maintaining Hacker Energy at Scale

GARRY TAN: Cursor is now worth $9 billion. How do you keep the hacker energy alive as the team scales? And do you still write code?

Maintaining Innovation Culture at Scale

MICHAEL TRUELL: I do, yes. It’s something that we think about a lot because I think that Cursor in the future will have to look very different from the Cursor of today.

One, I think you can do it by hiring the right people. So the last step of our hiring process is a two day on site where you come and you just work on a project with us. And so this is after an initial set of technical screens and you’re in the office and you’re kind of a member of the team and you come to meals with us and work on something and then you demo it at the end and then we ask you questions.

That gets at energy and excitement and passion for the problem space. And usually you’re probably not going to be super willing to do that if you maybe just view it as a job and you’re applying to a bunch of technology companies at the same time. So I think a big way to do it is by getting passionate people through the hiring process.

There are big projects that require a lot of coordination amongst people where you need top down alignment. I think that we always want to be a place that does a good degree of bottoms up experimentation too. And so we really try and encourage that. Both people taking time on the side to do that and then also explicitly taking teams of engineers, sectioning them off from the rest of the company and kind of just giving them carte blanche to experiment on what they’d like.

Building Durable Moats in the AI Era

GARRY TAN: So one of the things that I think all startups and maybe all businesses right now are even trying to figure out in the face of some of the most important, impressive and incredible models in the world, is what are the moats that are going to actually be durable and usable? How do you think about that?

MICHAEL TRUELL: Well, I think that the market that we’re in and that others are in resembles markets that you’ve seen in the past that actually aren’t enterprise software markets. So I think that a lot of enterprise software markets are kind of characterized by well, there’s sort of a low ceiling for the core value you can deliver in the product and there’s a lot of lock in.

And the market we’re in kind of mirrors search. At the end of the 90s where the product ceiling is really high. Search could get a lot better for a long period of time. And for us, the end goal is to replace coding with something much better and automate coding. And I think that there’s a long way to go on that.

One of the things that characterize search and I think also characterize our market is distribution is really helpful for making the product better. And so if you have lots of people using your thing, you have an at scale business, you get a sense of where the product’s falling over and where it’s doing well.

And so in search that’s seeing what are people clicking on, what are they bouncing back from? What was a good search result, what is a bad search result which then feeds into the R and D and then helps them make a better search engine. For us it’s seeing where are people accepting things, where are they rejecting things in the places where they accept things and then they correct it later. What’s going on there? How could we have been better?

I think that that will be a really important driver to making the product better and kind of the underlying models better in the future. I think another market to take inspiration from is consumer electronics. At the beginning of the 2000s, the thing there was getting the iPod moment, right and then the iPhone moment, right?

And I think the ChatGPT moment is kind of like the iPod or iPhone moment of our age of if you keep pushing the frontier faster than other people, you can get really big gains occurring to you. And I think that there are a couple more of those that exist in our space. And so it’s hard to do, but we’re really focused on trying to be the ones to race toward those the fastest.

The Age of Intelligence

GARRY TAN: It’s 2025. I feel like we’re actually even in the opening stages of this age of intelligence. What a revolution. What are you personally most excited about right now?

MICHAEL TRUELL: I think that this is going to be a decade where just your ability to build will be so magnified. Both people who already that’s their living and that’s what they do. But then I think it’ll also become accessible for tons more people.

GARRY TAN: What a time to be alive. Thanks for joining me today.

MICHAEL TRUELL: Thank you. Thanks for having me.

Related Posts

• Full Transcript: Zanny Minton Beddoes Interviews Elon Musk
• Transcript of Daniel Kokotajlo Interview: Diary Of A CEO Podcast
• Transcript: Why a Social Media Ban Won’t Save Teens – Candice Odgers  
• Transcript of Elon Musk Interview: SXSW Live – March 9, 2013
• Digital Afterlife: Who Owns Your Data When You’re Gone? – Suresh Sankaran Srinivasan (Transcript)