Inside Cursor：与联合创始人 Sualeh Asif 探讨 AI 编程的未来

You're listening to Gradient Descent, a show about making machine learning work in the real world. And I'm your host, Lukas Biewald. Sualeh Asif is the CPO and co-founder of Cursor, one of the best loved and most exciting and popular AI products out there. It helps you with coding, helps you use LLMs to do coding. I use it all the time and I really love it, and I was just excited to ask him about how he built such a great product. I found his answers super interesting and I hope you enjoy this interview.

All right. Well, thanks so much for taking the time to talk. I guess maybe this is a softball question, but I was really interested in hearing the story of Cursor—how you started it and what the moment was when it really started to take off. Now it's one of the most loved products out there, I think.

Oh, I know. That story comes from when we had been really interested in scaling laws. Back in college, I had gone on and worked on a search-engine-type company with a friend, and there we were really bullish on language models because I felt like language models could really compress all the world's information. There should be this end-to-end index of searching the internet instead of many of the heuristics we've coded in over the years. It felt like that should be the end-to-end way of doing things.

So, scaling laws, doing search engines, and training large models at the time. I think GitHub Copilot was the first really big moment for us. It was fast, and it felt like kind of magic. But then GitHub Copilot did not improve much over the coming year or two. When we saw GPT-4, we thought the ceiling for what was possible for a really, really great product at that moment was really high. Then it was pretty clear that as the models got much better—as scaling laws progressed and models got much better—the products that could be built in the future would have an even higher ceiling.

It was this super-attractive thing to go do. We're all coders at heart, and we wanted to be building things that we used every day. Cursor was originally built for ourselves in many ways, and it was fun seeing that everyone else really liked it.

It was definitely built for ourselves, and we were experimenting. A lot of the early culture of the company was experimenting with various different ways of using the models. Should there be a document that you're typing things out in while the model is coding things? What if you want to do this next-action prediction—you're in a location, and what should the edit be? Maybe the model should be telling you where to go next. You should be able to make edits over your entire repository.

Some of those things have taken a year, a year and a half, and several iterations, and some of them we've continued building on. Now, one of the core parts of the product is this next-action prediction: It predicts your next edit at the cursor location and then where you should be going next. People really, really love that feature. We're working our way toward being able to make any edit you want across the entire repository, codebase-wide.

Obviously, there are hurdles along the way that we'll talk about. Some are easy, and some are still quite difficult. Models also struggle with what exactly the architecture of the repository is. If you ask, “What is the architecture of the repository?” that is really quite difficult because it requires looking at potentially billions of tokens—tens of billions of tokens—and asking what is really going on. You could list the functions, right? But that doesn't really tell you exactly what is going on.

1. Switching from Vim to VS Code and the rise of CoPilot

Well, totally. I want to dive into that as much as you're comfortable sharing, but I guess I wanted to ask you: One of the surprising things that I learned in my background research on you is that I think you guys came from using Vim, not VS Code. Is that right?

All of us were really early users of Vim. We did eventually use VS Code. A couple of us, Aman and Arvid, were probably the last to switch over from Vim to VS Code, and the trigger there was GitHub Copilot.

Oh, I see. So GitHub Copilot actually pulled you over in the end.

I had switched over before, but Arvid only switched over after GitHub Copilot became—this was just a killer feature, right? In some ways, it was a killer feature.

Totally. Why doesn't something like Vim actually have something like what you built? It seems like a lot of smart coders like to use it. Is there something about a graphical interface that lends itself to this kind of structure, coding with an AI?

I think for us, VS Code is, for one, pretty clearly the most loved platform on the internet for coders. It's the de facto default.

We wanted to incrementally evolve it toward a world where you're starting to automate coding. Cursor one year from now should look very different from Cursor today, which means, almost by default, it should not look exactly like VS Code. But in looking very different, we wanted to start from a place where you didn't have a text box to code because coders still want to type characters, right?

You want to be able to edit your entire repository at a higher level. At some point, if you find that there's a change you can quickly execute in 10 keystrokes, we want to let you dive into the details at any point in time. Maybe you're editing some pseudocode representation a year from now, and that's really quick to edit while the model is working for you in the background. But you're writing some kernel and want to go in and toggle some of the indices. It's much easier to do it by hand. Developers will always want this ability to go in and have fine-grained control, unless we truly believe that everything is going away.

Yeah. One thing that strikes me from what you were saying earlier about observing that Copilot was really great, and that there was all this opportunity to work with these AI models, is that a lot of other people thought that at the same time. You had this idea that I think many people had, including a bunch of YC companies and other products that I saw, and it seemed like Cursor emerged as the winning one among these.

It seems like there was great product execution here, which I'm always really interested in. Do you have a sense of what you were doing differently from your competitors that made your product work so well? Was it certain decisions, or was it a process?

2. Why Cursor won among competitors: product philosophy and execution

Why questions are always really hard. I don't know. It's very hard to tell exactly what we did. I think it was a bunch of things. We always tried to push the ball as much as possible. We always wanted to be the most useful product at any moment in time.

At the frontier, it's very easy to overpromise and underdeliver. A lot of what we've tried to do is not ship the agent until we were very confident it was something really useful. We had probably done 3 agent prototypes before that that we didn't ship because some version of the model would just lose track. You could make something that could help you in the short term and really hurt what people think of as a reliable product in the long term. Maybe that is part of it.

But also, I think we've been first to a lot of the inventions that people really like. More recently, the ability to jump to the next location that should be edited is something we've had for closer to 8 months, 10 months, a year. Hopefully we'll release a much more upgraded version of it soon; it'll be quite a bit better. Only recently have other people tried to do that.

We've always tried to think of what's coming and at least have a prototype out as soon as we think it's something really useful.

There's the Tab to Jump feature. There's the Apply feature.

We've done this at scale, too. I think that has benefited us. For example, for our custom Tab model, we do something like 100 million requests a day, and it's quickly growing. I think part of doing it well has been being able to do it reliably for lots and lots and lots of people.

Do you think that any of the data or feedback you have from users is part of your success, or are you making decisions more through your own experience?

3. How user data and feedback loops drive Cursor’s improvements

The data has definitely been enormously useful. I think the feedback loops that people consider obvious are indeed extremely useful. You want to be the company that feeds in an extremely good product that everyone loves, and that definitely helps in making the next version even better.

It helps in small ways. It helps in training models. It helps in understanding how people are using your product, what the most important thing to ship at any moment is, and then in big ways, like training models and improving just the core workflows.

You could, for example, technically speaking, have one loop in the Apply use case: You train your first version of an Apply model that is quite a bit bigger, and then you deploy it for all users. You get lots and lots of data, and then you can distill a slightly smaller model that gets faster, so people use it even more. You then distill an even smaller model, and you can keep compressing the models down because you're generating the data that allows you to do that.

But also, yeah, it's just this feedback loop, and then some of the things get faster. For now, up to, I don't know, a 1,000- or 2,000-line file, Apply feels effectively instant, and that's what we wanted it to feel like. We wanted it to feel like Apply is this deterministic—you know, they figured out some deterministic algorithm to place the blocks—but that's not actually what's happening. It's a model that's actually grouping the entire file, and a lot of the improvements have been about making the model smaller. There are obviously improvements in just making the inference much faster when doing these speculative edits.

4. Iterating on AI agents: what made Cursor hold back and wait

But for something like the agents that you talked about, you had some iterations where it wasn't useful enough to ship. How did you know that it wasn't good enough to ship? How did you think about that?

I didn't use it on a daily basis. I think these things are really quite easy to figure out if you're coding 10 hours a day in Cursor, right? You boot up the editor, you're making the improvements, and you're seeing it on a daily basis. If the developers themselves can't use it every single day, it's probably not something that everyone else will want to use.

I mean, there are obviously corner cases to this thing where we're not the perfect coders. But a thing like an agent is such a general feature that if you're not using it, it's almost certainly not useful.

That actually leads me to another question I had. You and your co-founders have this background in competitive coding, right? Do you think that's an advantage for you? I could imagine that it might put you at the forefront of wanting to be efficient in coding, but I could also imagine that you might have idiosyncrasies in the way that you want to write code that might be different from your general user.

5. Competitive coding background: advantage or challenge?

I think we're not only competitive coders. We did competitive math and coding because that's sort of part of the background. It's always really hard to distinguish what part of your identity is the most important, but many of us had worked at software companies before, Stripe and the like, and we had some idea that production coding was very different from competitive coding, and that people had actually built products.

I think Michael had spent quite a bit of time building these high-performance games, and we had done modeling work. So we had seen quite a wide variety of coding. Bringing it back to whether competitive programming really affects how you do coding on a day-to-day basis: Not really. It was just that I think we knew what engineering was. We were doing day-to-day engineering, and you could see if the agent was helpful.

In this case, it was very clear that, for example, early iterations were not really that useful. It was very slow. One of the most important things that had changed there is the length of the context windows that you can use on every single keystroke, on every single request. When the models started out, you were doing these 4K, 8K context windows, and even if the models slightly supported them, they were not very good at using the large context windows.

Now that the cost curve has gone down for language models, you can do requests on the order of 50,000 or 60,000 tokens reliably, and that has enormously helped. One way to have an intuition here is that the model can't even fit your current file. It would not be very useful, let alone read the rest of your repository, do searches, or handle the many things that you expect a basic agent to be able to do. That wouldn't work if you're at 8K tokens. What can you even fit in there?

One other interesting thing that you guys said in your interview with Lex Fridman is that you kind of wanted the experience of using a code editor to be fun, which I thought was a cool idea—a little bit surprising, right? It seems like such a utilitarian thing.

It reminded me that I remember when I switched in Cursor from my default LLM, from Sonnet to o1. Actually, I think I started coding a little less. I was having a lot less fun because the latency was higher. It took me a little while to realize that, but I actually liked having lower latency, and it made coding a lot more fun. I was like, “You know what? I just need to go back to the LLM where I was enjoying writing code.”

So I do actually kind of relate to what you're saying, but I'm curious how the idea of a fun experience shows up in your utilitarian-feeling application.

6. Making coding fun again: latency, flow, and model choices

I think it just—I mean, there's always this end metric, right? The end metric is how much we are enjoying using a model. It's been very clear that we enjoy using Sonnet more than o1.

And part of it is that there are a few things. One is, I think Sonnet is extremely—it's even at scale, reliably quite fast. I think we want to ship models that are even faster, that are better than Sonnet, that have much longer context windows, and that could make edits reliably over a much larger part of your codebase, for exactly the same reason: It becomes much more fun.

In some sense, it's this hard-to-pin-down feeling, but in some sense you know what really affects it. You'll get bothered if you have to explain to the model again and again what you're doing, or if the model doesn't really understand that you had a recently viewed file open and doesn't see it. That's sort of annoying. It's just straight-up annoying.

So you can turn it into some methodical thing that you can track down. But some of the inventions are just, “Wouldn't it be more fun if blah blah blah happened?” Wouldn't it be more fun if you were coding and, once you started doing a refactor, the model could just—you could tap, tap, tap through the entire thing, like 10 tabs? What would that take?

Once you think, “Oh, 10 tabs would make me feel really, really happy,” you can reverse-engineer the exact thing—the modeling work—that you would have to do. What size of model do you want to train? How much time do you want to spend pretraining, post-training, and RLing the models to be able to consistently produce the same behavior again and again?

Another concrete example is that you could always overtrain the Tab models to be annoying. If you were to only worry about making sure that every single time it does the edit, you would overpredict. Sometimes you really want to—you're writing, again, some kernel, you want to spend some time thinking, and you don't want the Tab model bothering you. That's the thing you would only care about if you're making it fun and enjoyable, as opposed to something that's obviously just always overpredicting.

7. Building Cursor’s infrastructure: from GPUs to indexing billions of files

But this is a pretty subjective experience that you probably couldn't pull from user data. How do you work through that internally? Do you ever have a difference of opinion among yourselves about what's the more fun approach?

Yes. I think some of these decisions are subjective, but if you think them out, they're not always that controversial. At the end of the day, you're trying it out. There's always some intuition where you might over-trigger in some direction, but for the most part, I don't think there's that much argument over whether Sonnet is more fun or o1 is more fun. I mean, Sonnet is arguably better.

Hopefully, there'll be more models that are optimized toward keeping you in the flow. I think you need broadly 2 categories of models. You need the category of models that's RL'ed toward being fast, with super-large context windows, and just making edits across your entire codebase and making you feel like you're breezing through things.

And you want a category of models that's trained to be extremely careful, reviewing every single small thing before making the edit. Maybe you do a bunch of research; they then make the edit in the background for you and come back to you with a PR. In that case, the thing that will be fun is if they're more correct than not. Fast is not the only thing that's fun. It's being correct, or how they write out how they prove to you that they're doing the right thing.

I guess as you build a bigger brand and build trust with users like me, why are you even asking me what model I want to use? I'm aware of the different models, but I would trust you more to know what's going to be fun and useful for me.

I think you're kind of right. Part of building trust is always showing exactly what we're using. I think you're probably correct that we should have a default mode: you should use the default and feel happy. But if you're the kind of person who wants a new mode and wants to perfectly fine-tune every single thing, you should be able to do that. There should be simple defaulting. There should be a release in a week or two that fixes all of this for you.

Here's something I've been wondering about myself quite a bit. Do you think there are best practices for changing the structure of my own codebase, or the way I should code, to make your product work even better? For example, we have one engineer who's been letting the LLM put helpful notes inside the codebase.

One of the things that we've been speculating about—we don't actually have a really correct solution there—is this idea that maybe there should be a README.md in every folder. The idea is that, at any point in time, if you ask for changes around a folder, the model should be able to look up the nearest place where there's an architecture written down, so it can understand the technical side.

The models are much faster at reading tokens than humans, and orders of magnitude faster at ingesting these tokens. Humans have some small things memorized, so there are obviously small differences in how we code: the model is starting from scratch every time. Cursor Tab in our codebase is named CPP, for Copilot++. The model will always need to be reminded that whenever you're searching for something that says Copilot++, or whenever I say “Cursor Tab,” you should actually search for Copilot++.

There are these facts and rules that are quite important. I don't want the default to be that everyone has to change their way of coding. I think the obviously better approach is that we spend all the time and energy we need, and all the compute we need, to really nail down the architecture and figure out all the facts and rules that you have. I don't know if I have any interesting, controversial ideas for how that should be done.

Someone was joking that maybe we should email you 10 rules in the morning, and you'd just say yes or no to the 10 rules. Hopefully, you'd build up a corpus over time. You want a system that allows you to add rules and then prune bad rules. Sometimes, if you just ask the model to look at a PR and give you some rules, it will come up with bad rules, and you need a way of pruning them out. What's the minimal set of rules such that all your PRs become much easier? Does the model need to look at all of the rules? We're still figuring it out, but I think there's something important at the core of this, both in terms of how humans would change and in terms of what we should change to make the defaults much better, because not every single person will change, of course.

For example, do you think smaller file sizes are better because the model can more easily navigate the code hierarchy, or do you think that creates complexity? There's always some trade-off.

The funny joke is that sometimes people will keep adding to the same file until the model can't edit it anymore, and then you just ask the model to refactor that file for you because you're composing the file more and more, in Cursor terminology. It seems pretty clear to me that there is some advantage to the model seeing all the context relevant to the current task in the same file, and also that, for future tasks, it'll be easier if the file is smaller.

8. How Cursor prioritizes compute allocation for indexing

Infrastructure-wise, we will also make it possible for you to sync all of these files to a remote server. We'll have a big enough copy of your codebase at some point. Right now, we're extremely privacy-conscious, which means we try to make sure that we never store any code past the life of your request. Ideally, in the future, we can store at least some part of it in a private way that allows the model to do reliable edits very quickly. It shouldn't have to make these round trips for every single small edit; that feels quite bad.

What else? You were telling me that you run infrastructure. Can you talk about what the interesting infrastructure trade-offs are at Cursor?

We've built lots of different pieces of infrastructure. There's the traditional company infrastructure, but then there's also a lot of other things. The one we've been very public about is our indexing infrastructure, which we've spent a lot of time optimizing and running at quite enormous scales—billions of files per day, kind of infrastructure. For that, we run our own inference. For all the models that embed your files, we run an enormous amount of infrastructure—really large pipelines.

If you're some big company and you have 400,000 or 500,000 files, you want the ability, while the user is coding, to effectively feel like everything is being instantly synced to the server while the model is using the embeddings to search or edit the codebase. Scaling that has been quite a challenge.

There's a broad category of databases being built on top of S3, and we're big believers in this approach. The usual term is separation of storage and compute, or disaggregated storage databases. A classic example of this is that we use Turbopuffer. Turbopuffer stores most of the vectors on an S3 path, and it has a write-ahead log. You write to the write-ahead log, and when there's a compaction process, it compacts the write-ahead log back into the database.

One of the main challenges we've been dealing with in this indexing infrastructure is whether there's a way to support shared codebases. If all the people at Weights & Biases have a really big codebase, hopefully in the future you'll be able to spin up background agents editing your codebase. We want thousands, if not tens of thousands, of clients connecting to that codebase. We don't want 10,000 copies of the Weights & Biases codebase, most of which aren't being utilized.

Can we have a shared trunk, and then every single person can have their own branch off that trunk? That architecture is still something we're working on. It's not exactly easy to do, because how do you easily branch this vector database? At the end of the day, you want to be able to query both the trunk and your section and merge them in a way that you still get the correct top-k chunks. That's not trivial.

So when I fire up Cursor, it's quietly indexing all the files that are in my project?

Yes, exactly. When you fire up Cursor, it quietly indexes every single thing, as long as you allow us to and it's turned on by default. One really popular Cursor use case is that you open a GitHub repo, clone it, and then fire up Cursor in that GitHub repo; now you can quickly ask questions about it. We try our best to make it effectively instant to index these really large codebases. If you clone LLVM, which is 120,000 files, that will take us a bit longer.

9. Running massive ML infrastructure: surprises and scaling lessons

For example, an interesting infrastructure question for the listeners, or whoever is pondering this, is: How should you allocate this token capacity? At any point in time, we have a fixed number of GPUs, which means we have a fixed amount of token capacity. Should you be able to index LLVM or Weights & Biases, which are really large codebases, while there are a bunch of people who have a number of small codebases? Should the number of small codebases always be allowed to go through, and should the large ones be slow? Or should you take a lot of the capacity in the beginning, so everyone else gets a smaller chunk, in the hope that no one gets a really bad experience? That kind of question is still hard to answer.

How do you think about that?

Currently, we try to keep both sides relatively happy. You can boost your capacity, but I'm still looking for better answers. I think there probably is a really good answer to how you make people happy. We haven't spent that much time thinking about it, but hopefully there's a really good answer.

There are no serverless GPUs, right? There's no great serverless option because, at the end of the day, the amount of compute we're spending is still fixed. Cursor indexes—the amount of compute is just the amount of compute to index your codebase, plus the amount of compute for every single other person we're indexing.

In an ideal world, there'd be this phenomenal serverless thing where you could boost up your capacity, and then people could use that capacity and it would get boosted down again, which is what would happen in CPU land. That sort of infrastructure hasn't been built for GPU land. Is indexing the main thing your GPUs are doing, because you're also running lots of models too?

Yeah.

Yeah. We run the Tab model. Indexing is a very small percentage of our compute. Hopefully, we’ll be running much larger models in the future, and they far and away dominate most of the compute cost.

I see. So the model running the Tab model—you said it’s hundreds of millions of calls per day?

The Tab model is hundreds of millions of calls per day. The big models we’re running have thousands of requests going on.

Okay, so without going into detail, you have thousands of requests going on?

And so we’re scaling up these models as fast as we can. They definitely take up far more compute. It also makes sense because they’re larger. One intuition to have is that you’re doing tens of thousands of tokens of inference per keystroke, per person, which is both really cool and also really scary if you’re running the inference. Obviously, caching really helps, but it’s still scarier than running a server.

Have there been any surprises as you’ve scaled up this ML infrastructure? You’ve got to be one of the fastest-scaling ML companies ever. Have there been any pitfalls? What’s that experience been like—smooth?

There have been glitches, but I think the team is really, really talented, and we’ve gotten over them.

Nice. What about—I mean, we’re talking maybe 2 weeks after DeepSeek came out, and that obviously caused investors to change their mind about NVIDIA stock. Did it update your beliefs at all?

It’s really weird to me because I think we were both on the Lex podcast, but even before that, we’d been pretty public about using DeepSeek in many ways. We used to use their 1.5 series models and then switched over to their V2 series models, so it was a big shock personally to me that everyone was going, “Hoo-ha, this is a new thing.” They’d been producing phenomenal work for a while.

Their models—I used to joke that they were one of the 3, 4, or 5 companies you would trust to produce good models, where the numbers wouldn’t feel like they were juiced up. There were certain models that felt like their numbers had been a little bit too juiced up. By “juiced up,” I mean that they were really high for evaluations, but then if you used the model in practice, you would never like using it. It was just very specific to the evaluations.

But DeepSeek felt very honest about things and had been producing really good models. We’ve been running the DeepSeek V2 model for 8 or 10 months now—probably 12 months, something like that—on our own inference, and that’s the model we’ve scaled up to hundreds of millions of calls.

10. Why Cursor chose DeepSeek models early

Interesting. How did you choose it? Was it just the best?

Yeah, it was the best. They had been producing extremely good open-source models. We have our own sort of post-training stack with RL and stuff, but for picking a really well-pretrained base, DeepSeek does a phenomenal, phenomenal job. The data they train on is really good, and the model is both quite knowledgeable and quite smart, while also being quite cheap to run for the Tab model in particular.

In general, I’m really excited about DeepSeek V3. I think DeepSeek V3 is actually a really well-pretrained base, and I suspect it will be very useful for making these custom applications.

11. Where AI agents are heading next

You’ve obviously launched agents, and it’s pretty cool, but it’s also kind of constrained by how many iteration steps the agent will do and things like that. Where do you see agents going in the near term? Obviously, inference is getting a lot cheaper, so it seems like you could go much broader if you wanted to. What are you thinking?

We’re super focused on it. As people have been getting better at doing RL, the models have been getting better at both thinking and being extremely coherent. One of the things we just talked about was coherence: the models have gotten to producing tens of thousands of tokens of output, which they weren’t doing before. I think they would immediately go into delusional mode after a couple thousand tokens, and now they’ve gotten quite a bit more coherent. That comes from doing RL and really good post-training.

I think agents were bottlenecked by that particular aspect of coherence. One of the things that makes the Sonnet experience really magical when using it in an agent is that it’s so coherent over such a long period of time—over tens of tool calls. As the tasks get harder and harder, I suspect you would need to be coherent over hundreds, if not thousands, of tool calls. We’re working on it.

One of the things that we generally come back to is the mission of the company. We want to automate as much of coding as possible while still having the developer in the front seat. In the short term, automating coding involves allowing developers to sit back and let the model code in cases where they want to do that. But in cases where they want to drive the editor to make code changes—for example, you’re doing voice and policies and you want to switch your gRPC thing to some other rustls package—you should just be able to tell the model, “I want to switch my gRPC thing to use rustls instead of something else,” and the model should just get it and be able to make these large-scale, codebase-wide changes.

That requires the model to have some agent-type capabilities, because you’re never going to sit down and write out the exact specification of your codebase. What the agent really helps with is that you don’t have to sit down and explain, “We have a backend written in Rust and Go. Rust hooks up to Go in this way, and for libraries we use this.” The model should just go and figure it out.

My own experience of playing with agents, which is much more limited than yours, is that when they break, debugging is the real challenge. Have you built any systems internally for looking at what the agent is doing? Why did it get into a weird loop? What’s happening? How do you visualize that?

We’re building our own infrastructure for it for now. I suspect there will be phenomenal products in the future that make this much easier.

For now, it’s the same thing with building prompts. We use an internal library called Preempt. The way we built Preempt was well suited to our own needs and the design. I think, for the same reason, we’ll be building our own agent infrastructure in the short term. I suspect that in the long term there will be some phenomenal developer tools that come up to make it much easier to inspect the chains, stop at any point and restart them, and debug them in production when something weird goes wrong. There are all sorts of things you would need to be able to run a production system at scale.

Is agent evaluation more of a vibes-based approach than a set of specific metrics?

Currently, yeah, it’s pretty clearly vibes-based. I suspect it’ll be vibes-based in the short term and become more and more driven by metrics as we get better at shipping these. It’ll become much more operational.

12. Debugging and evaluating complex AI agents

When you look at something like Devin, or these completely automated, no-programmer approaches, do you view that as competitive or interesting? What’s your interest in it?

I’m totally open to it. But in the case where it’s not really useful, kind of boring, and not really that fun, we just wait. We wait until it gets good enough. We keep training the models, and at some point it will get good enough, and then it’ll be really fun to use.

In general, over a 1- to 2-year time frame, I expect that the way people code will change. In the short term, that seems really scary, but I think it’ll be a gradual process and extremely natural to everyone coming in. The change from not having a Copilot to having a Copilot was extremely natural in retrospect. It wasn’t something that was scary to anyone. It was this thing that sort of appeared out of nowhere, and you were like, “Wow, this is phenomenal,” and you just started using it.

13. How coding workflows will change over the next 2–3 years

Then the change from going from the scope palette to this foreground agent interface, where the model makes edits across multiple different files, was also pretty natural. You can say, “I want to switch this to use rustls, and I want to make sure that you always use HTTP/2,” and the model gets it, reads all the files, and makes the changes. You can immediately review the changes very quickly and tell that they’re correct. I don’t think there was any point in the middle where people felt disoriented. Going to background agents will be the same way. All of these things are more gradual than one would expect. In 2020, if you had said, “The way you’ll be coding is that you’ll start talking to the computer and it’ll make changes to random files,” you would have been kind of freaked out.

You'd think, “Oh, it's going to add all these bugs. It's going to be impossible to review. Why the hell am I doing this?” All these things would have seemed scary. And yet, 4 or 5 years into the language-model journey, with products like Copilot and Cursor, things feel quite natural. From 2021 to 2025, where we are now, at no point has making the change felt very disorienting. Maybe in one jump that would have been disorienting, but right now it's not really that disorienting.

Well, it feels like a lot of fun to me. I guess when I connect the dots from 2020 to now, it's gotten better, right? When I look a few years out, I have no idea, but it's hard not to see a world where you wouldn't really be doing anything that looks like programming a few years out, or where more people will be coding and making much more difficult things—things that are considered much more difficult, whether lower-level things or larger projects, even for their side projects.

I think people are usually very conservative with their side projects because they're like, “I probably won't have that much time.” I think people will get much less conservative with these side projects. I'm generally just extremely optimistic in the medium term. Yeah. Yeah, do you feel at all—first of all, don't you think it's a totally different world where everyone can do these monster side projects easily? It seems like software is a very different thing. Even starting a software company seems like it might be hard to have as much of a protected advantage when it's easy to build this stuff.

I can't philosophize over that. I tend not to be scared of people having medium-sized projects. I tend to think of these things as experimentation becoming much more natural. Large changes are usually scary at companies because a large change requires changing so many pieces and takes so much time that you want to plan everything up front. Planning is really hard because you can't foresee what your production system will look like if you do X, Y, Z. Then everything becomes much scarier, you add more meetings, it becomes more formal, and everything just gets worse and worse over time.

I understand it: if you're doing a multiyear database transition, boy, do you want to plan out every single small detail. And then you want to argue over every single small detail. But if you can start prototyping these things really quickly, maybe it becomes less talking and more coding. You have much cleaner, concrete artifacts. If you're in PyTorch and you want to do a small API change in PyTorch, it'll take a year. You probably want to debate the hell out of it. If you're in PyTorch and you know you can have a prototype in 3 days, maybe you should just argue over the prototype now.

Is that how you think Cursor works?

Hopefully, more and more so. Yeah. I mean, there are still things that are scary, but definitely I find myself thinking it's just much better to argue over the prototype. I suspect that change will continue.

Awesome. Well, I guess one final question: if something comes to mind when you think—if you were sort of outside of Cursor and had fresh eyes into this world of AI applications and LLMs working for so many different things—is there something else that excites you that you wish you had time to think about?

14. Dream future projects: AI for reading codebases and papers

Personally, I've always wanted a really good reading experience. I like to spend my free time either reading or even reading codebases. I think it's an underrated aspect of coding: all of us produce these artifacts that we've poured many years of our lives into. Redis—someone has poured their life into Redis, and I really want to go read and understand Redis. What were the hard decisions? What were the easy decisions?

For reading books, papers, and codebases, we haven't discovered the final, optimal AI tool. Hopefully Cursor will contribute to at least reading codebases, but maybe someone makes it easier to read books or papers. I'll be really happy. Reading papers is still quite an arduous process, and I don't love the current PDF viewers. You click something and it jumps to the final thing; it feels a lot more primitive than it should be. Recently, I've been reading papers by just pasting them into one of these chat apps, and things are getting better. In general, it feels like there's a lot of low-hanging fruit in lots of different areas of life.

Okay, I have to ask: what are your top recommended codebases?

Well, as I just mentioned, Redis. Redis is quite good if you haven't read it. It's relatively small, and still it's quite fun. That's probably the one I'd most recommend because it's a thing that's used by everyone, and it's really, really well written. SQLite, for sure, also, if you haven't read SQLite. Again, very well written. It's this coherent document by a very small number of people. Mostly, I recommend software that you use. You should try to read the software that you use.

Some things are harder, but I don't know—if you're a fan of Ghostty, the terminal, maybe you should spend a weekend trying to read Ghostty. Or if you're a fan of PyTorch, maybe you should look into why PyTorch does what it does. I think there's a lot of choices that you can criticize from the outside, and people underappreciate the tremendous amount of work that people on the PyTorch team have put in to make PyTorch really, really easy for you to use. This magical experience, where all the gradients just flow naturally, has taken many tens of thousands of engineering hours. I don't know if it's in the hundreds of thousands or the millions, but it's a lot of engineering hours.

Interesting. Well, thank you so much. I really appreciate your time.

[Music]

Thanks so much for listening to this episode of Gradient Descent. Please stay tuned for future episodes.