Cursor CEO Latest Interview: All Programming Will Be Done with AI Within Five Years

With a valuation approaching ten billion and a latest funding round of up to 900 million dollars,Cursor it is undoubtedly the hottest AI product this year. Cursor is not only a tool for AI-assisted programming, but also created the concept of "vibe coding", a programming approach focused on low-code or even zero-code.

Being able to truly make a name for itself on the "wrapper" track, the process is always more arduous than it appears. Before doing the AI programming business, Cursor's founding team had wandered through other, more hard-engineering fields, until they finally realized:Starting a business is too hard; you still have to do something you like.

Cursor CEO Michael Truell appeared on Y Combinator's podcast and shared his experience from two startups. He reiterated that idea that sounds a bit cliché but is always useful:

Never doubt, always believe, until time proves you right.

The following is the interview content, compiled and abridged.

Welcome, Michael. We all know and really like Cursor. You've said that Cursor's goal is to invent a new way of programming, in which you can just describe what you want and then build it. Tell us more about that. Michael Truell: Yes, the company's goal is to replace coding with something better. My three co-founders and I have been programmers for a long time. One thing that attracted us to programming is that you can build things very quickly. But programming requires editing millions of lines of esoteric formal programming languages, and it takes a lot and a lot of work to actually get something easy to describe onto the screen. We believe that in the next 5 to 10 years, it may be possible to invent a new way to build higher-level, more efficient software, and our goal with Cursor is to get there. The way we achieve this is by using AI programming, then continuously evolving it from ordinary programming into something that looks very different.

So some people would say this is what we have today—you describe what you want, and then it appears. Have we reached the place you really want to get to?

We are seeing things really change, with the biggest changes felt in smaller codebases and among a small portion of the software workforce. We have seen people move to higher levels of abstraction above the code.

But I think there is still a long way to go. I think the whole idea of vibe coding or programming won't really work without actually looking at the code and understanding it. If you are dealing with millions of lines of code and dozens or hundreds of people working on something over many years, you cannot avoid thinking about the code.

Our main focus is helping professional programmers, for those who make a living by building software. In these environments. People are increasingly programming with AI. We have seen people use AI to write 40% to 50% of the lines of code generated in Cursor, but this is still a process of reading everything AI generates. So an important gap we need to cross is the product. We will reach a stage where it is no longer just a productivity tool that helps you read, write, and understand code.

There are some startups that clearly start from zero lines of code, so that seems easy. Do you think there is a threshold above which just vibe coding is not enough?

If you intend to keep the code stable for a very long time, then we definitely do not recommend that you use vibe coding.I think when you're a startup of a few people and you're trying to figure out what you're doing, one of the features of development is often that code only exists for a few weeks.

Now, we're at a stage where AI is helping you, right? Either delegating tasks to AI, saying to them: go do this for me, go answer this question.

Programming is sometimes very predictable, when you're just watching someone work alongside, you know, what they're going to be working on for the next 10 minutes, 15 to 20 minutes. So this tab format can play a big role. And this form of delegating to another person's agent can also play a big role.

Once these start to mature, for 25%, 30% of professional development work, you can rely entirely end-to-end on these tools without really paying attention to the specific details. Then the next thing to figure out is how to make these actually work in the real world.

If we're a tool that helps humans turn ideas in their heads into content on the screen, then giving people control over the finest details is always helpful. This is one of the product challenges we face: you should always be able to edit very specific parts of the logic.

I think a useful user interface is to write down the logic of the software. Then you can point to parts of the logic and actually edit them. But if we reach a point where you don't have to pay much attention to code, that written-down version of the software logic has to become higher-level.

We're excited about this: after making agents work, after making the tab format very mature, will AI really change what it means to write and view programming languages?

Is it related to the context window? Once you exceed about 1 million to 2 million tokens, and I even think it was only in the last 100 days that we got a usable 2 million token length, this is a stage. Once your codebase reaches a certain size, you have to use RAG(retrieval-augmented generation), which has incomplete context, and then it can't do what a human programmer can do?

Yes, I think there are many bottlenecks in agents reaching human level. The context window is definitely a problem. If you have 10 million lines of code, that's probably 100 million tokens. You need both a model that can actually ingest that content and make it cost-effective, and then not just a model that can ingest that content into its weights, but also a model that can effectively attend to that context window. This is complex.

I think this is a problem this field needs to solve. And it's not just a codebase problem. It's also a continual learning problem: understanding the organization's context and things that have been tried in the past, and the problem of getting models to truly continually learn certain things. This is a problem that I think this field still doesn't have a good solution for. The institutions training these models lack truly good long-term context data, so I think this will be tricky. But continual learning and long-term contextual knowledge are definitely bottlenecks.

There's an amazing chart online about progress in maximum time length over the past year or two. The amount of time AI can run on a task has gone from a few seconds to—I don't know how these numbers are actually derived, but some people claim that some of the latest models can reach an hour. Of course, there are still problems with different modalities, so to be a software engineer, you need to run code and then handle the output.

So computer use will be important for the future of code: being able to run code, being able to view Datadog logs and interact with those tools that humans use. There are many known problems we will have to face, and many unknown problems we will have to face.

And then one thing I want to point out is that I think it's imprecise to just have a text box to ask the software to change the user interface. So if you care about humans being able to control what's displayed on the screen, you need a different way of interfacing for them to interact.

One potential user interface is the evolution of programming languages, becoming something higher-level. Another might be direct manipulation of the user interface, being able to point at things on the screen and say, oh, change this, or adjust these values yourself.

This seems like a bunch of things that are just emerging, right? The models don't seem to have a clear sense of aesthetics, so maybe this is something that needs human designers to be able to see.

It's interesting to see them improve in terms of aesthetics. Our understanding is that the way you teach these models to do better in aesthetics and so on is not like how you teach humans. It's by collecting a large amount of data and doing reinforcement learning on them. That's how you teach them in this task. This is a task that enough people care about that you can pay for all of this cost, you can go train and incorporate it into the base model.

So, given the future that everyone is building, and you are undoubtedly a leader at the forefront, what do you think will be irreplaceable or similarly fundamental for being a software engineer in the future? Is it aesthetics?

People usually think about this when thinking about the visual aspects of software. I think the non-visual aspects of software also need aesthetics: about how logic works. And right now, proactive programming will sort of figure out how you actually want things to work—such as what product you are truly defining through the logic you write, and the high-level aesthetics of implementation details, that is, how to map it to a physical computer—these are all bundled together.

But right now, a lot of programming is a kind of manual compilation that you are doing, where you know what you want. You really have to spell it out in detail for the computer, because the language you can use to describe things to the computer is normal programming, that is, you know, for loops, if statements, variables, and methods. You have to spell it out in detail.

So I think more and more of that manual compilation step will disappear, and the computer will be able to fill in the gaps and fill in the details. But because our tools are there to help you achieve it, to help you build the taste for what you want, I think it will never disappear.

That makes a lot of sense.There is a saying that good people will help you reach the standard you can see, but truly great, truly masterful people, they can reach a higher standard that you can't even see. And that requires aesthetics.You call this people needing to become logic designers. In terms of intent-driven programming, what does that mean?

As this technology becomes more and more mature, as we get closer and closer to a world where programming can be automated and can replace the way software is built with a better approach, I think there will be many implications.

One is that professional developers will only become more productive. The pace of progress on a thousand-person software project is so slow, while the pace of progress on a hundred-person software project is so fast, it's crazy, and a large part of that comes down to the importance of existing logic, just letting you bring out your best.

As this technology becomes more and more mature, as we get closer to a world where programming can be automated and replaced by better ways of building software, I think there will be many implications. I think one of them is that professional developers will become much more productive.

The pace of progress on a software project with a thousand people, the pace of progress on a software project with a hundred people, and the pace of progress on a truly professional software project are all maddeningly slow, and to a large extent this comes down to the burden of existing logic, which just overwhelms you. When you are in a codebase, you can start from scratch and you can do things very quickly, but when you change something, a bunch of other things break along with it and you need to fix them.

I think one of the implications will be that the next distributed training framework, the next database, or the next visual design tool will be built much faster, and the same goes for the next AI model. If you talk to labs, they are largely bottlenecked by engineering capability. I think all of this will improve substantially.

One of my first jobs was actually working at a biotech company, a company made up of lab scientists. They were developing drugs to treat diseases, and I was the first software engineer they hired. They were generating large numbers of chemical compounds, and then putting them through these biological experiments. Then they needed to read the results to figure out which chemical compounds should be studied further, and doing this required a large amount of internal software development.

It is surprising to look at the existing tools and see how bad they are. And then to think that this company, for which software is not a core competency, has to go out and do this crazy, laborious thing—hire a real software engineering team and train them, and have them do internal product development—it is simply insane. For this type of company, there will be many more options available to them.

Changing topics, I want to hear the early story of Cursor. You met your co-founders Sule, Arvid, and Aman at MIT, and the company was founded in 2022. What brought you together, and when did you realize this was a team that could build something truly ambitious together?

I think we had a lot of youthful naivety, which at the time may have been unfounded. From the beginning we were quite ambitious. Cursor actually came out of an ambitious idea exercise by the four of us. You know, we all started programming at a young age, and then some of our early engineering projects were actually related to AI. One of us worked on improving the data efficiency of robot reinforcement learning, which is teaching robots to learn new tasks very quickly. That was one of our early AI projects.

Another person worked on building a competitor to Google, using neural networks to try to quickly build an amazing web search engine. Others did academic work in AI, but in 2021 there were two moments that really excited us and made us want to build a company focused on AI.

One of them was using the first truly useful AI products, where AI was truly at the core. GitHub Copilot was honestly the moment that made us really feel that we could now make something very useful with AI, and that we should not go work in a lab to do these things. Instead, it was time for these things to enter the real world.

The other thing that really excited us was seeing research from OpenAI and elsewhere showing that there are these very predictable natural laws, indicating that if you scale up the data and scale up the amount of compute invested in these models, they get better.

We wanted to pick an area of knowledge work and then work on what that knowledge work would look like as AI became more mature. We were very interested in the shape of a company that builds products for that area of knowledge work. First, as the underlying technology becomes more mature, you can evolve the shape of doing that thing. Second, even then, it's clear you might need more than scaling language models to GPT level; one way to continue advancing the underlying machine learning progress is to get product data.

We actually didn't know much about mechanical engineering. We spent some time researching a co-pilot for computer design. So we were training 3D autocomplete models to help people who are doing 3D modeling of the parts they want to build in software like Solidworks Fusion 360, trying to predict the next change they would make to the geometry. This is an interesting problem. It's a problem academia has been researching. It's actually also a problem DeepMind researched a little.

None of these are large language models.

You can do it entirely in 3D, or you could say it's a direction we researched for a while, which is turning it into a language problem, where you turn the steps someone takes in a CAD system into method calls. Quite complex, but we researched it for a while.

There are a few reasons for this. One is that we really weren't as excited about mechanical engineering as we were about programming. We're all programmers. Another is that I think the science and technology at the time wasn't ready for 3D, like pretrained models weren't good enough for this yet. There wasn't a lot of data. There are orders of magnitude less CAD model data on the internet than code. So it was hard to make a useful model, or at the time it was hard to make a useful model for that domain.

Would you sit with people who use CAD or machinists or the like?

That's what we did. We did a lot of user interviews, and I think we could have done better. I think, in youthful naivety, we were running every day, counting tasks by the hour every week, and looking back at the time we spent on this, I think it would have been better to do it earlier. Or go work at a company that employs mechanical engineers for three weeks; I think that's very valuable and can replace some of what similar hundreds of user interviews would do.

I guess besides that, you were also training your own models to do this, using reinforcement learning, which is very useful. At the same time, learning how to spin up large clusters to actually train these models.

Yes, we didn't know that at the time. But yes, some of the things we did there ended up being useful to us. It did a lot of behavior cloning, less RL, but in finding good examples of what humans did and then training AI to do those things. Training large language models with tens of billions of parameters wasn't something many people were doing at the time, and honestly, even now not that many people train large language models and machine learning models with more than 10 billion parameters.

So the state of infrastructure was very, very early. We were doing things like 4k Megatron LM or Microsoft, stripping out internals, deploying things for training, and even on the inference side, during that period, we ran a few things at scale. Now at Curosr, we do more than 500 million model calls per day through our own inference, and understand some of the lessons from doing inference at that time, and the training at that time was definitely very useful for the Curosr experience.

So one thing I think was both very brave and very far-sighted was that at some point you stopped and said: 'Actually, we don't know enough about CAD, we need to take a different path.'

Did it start with training a CAD model? Was the initial path something like: seeing that the large model labs had already mastered scaling, and that CAD was a field you could go deep into, so you went in that direction? And then you realized that what you actually needed to do was something else. So what was the real trigger that made you pivot to where you are now?

This wasn't a whim. We're programmers ourselves, and we were inspired by products like Copilot and the early Codex papers. I also remember that at the time, to convince investors to back our somewhat crazy CAD idea, we did one thing: we calculated roughly how much it would cost to train Codex, the first code model. By our rough estimate, it would only take about ninety thousand or a hundred thousand dollars. That number really surprised the investors at the time, and in some way helped us raise enough money to push the CAD project forward—because that project had to start training models right away.

We had actually always been paying attention to the programming direction, and we had always been excited about how AI would change programming. But at the time we still had some reservations about throwing ourselves into that field, because many people were already doing it, Copilot itself was very strong, and dozens of other companies were doing similar things.

We later decided to set aside the CAD project—that direction was relatively independent, but scientifically it wasn't going smoothly, and we ourselves gradually lost interest in that field. What really brought us back to the programming direction was our own interest, and the confidence that kept us going came from two sides:

First, we saw that over the past nine months or so, other people's progress in this field seemed not as fast as we had imagined; second, we thought seriously: if we really believe our own judgment, then within five years, all programming will be done through these models, and the nature of programming will be completely changed. To get there, many key leaps are still needed, both at the product level and the model level, and the ceiling of this direction is simply too high.

At the same time, we also observed that some existing players don't seem to truly aspire to realize a 'completely different way of programming'; their ambition isn't at that level, and they lack the execution ability to really achieve that goal.

The first experience taught us that building a company is hard, so you might as well do what you're truly excited about. At that time, we began to work on the company's future.

It sounds like your judgment at the time was especially far-sighted. About a year ago,Sam Altman also sat in this chair and said something similar: if you're betting that models won't get smarter, that's a bad bet. You should always believe that models will get smarter over the next 12, 18, 24 months—and reality has indeed increasingly confirmed this.

And it sounds like you had already made this bet a full 12 months before he said that.

Yes, at the time we had a saying internally called 'follow the line'—meaning always move along that curve of progress and plan for where it's heading.

This idea can actually be traced back to the "scaling laws": as long as you stay on this path, these models will keep getting better, stronger, and smarter. We believe this curve will not stop, so product design and roadmap planning must always align with it, preparing in advance for the leaps in models.

Peter ThielThere is a classic question: "What do you believe that nobody else believes?" And you believed this at the time—and it turned out you were right. And precisely because of that, you were able to get to where the "puck is going to be."

Yes, I think that was one of our advantages at the time. Although these views have now become very mainstream, back then—say, in 2022—it was truly a crazy and pivotal turning point.

At the beginning of that year, almost no one was really talking about AI. GPT-3 was released the previous year, and Copilot was just in testing at the time (2021), and probably only officially launched in 2022. Only after that did it gradually start to attract attention. We still clearly remember a series of product releases at the time, such as InstructGPT, which made GPT-3 a bit more usable through instruction fine-tuning; in the summer there was DALL·E, and that release very intuitively moved some people who had not previously paid attention to this field and got them to start taking AI's development seriously.

Next came PaLM and Stable Diffusion, and then RLHF (reinforcement learning from human feedback) and the emergence of GPT-3.5. The capability improvements of these models were very fast, yet they were not accompanied by a sharp rise in training costs, which was very noteworthy.

There are rumors that from GPT-3 to ChatGPT (that is, the breakout point everyone really paid attention to), training costs increased by only about 1%. That is crazy. And what drove this huge leap was instruction tuning, RLHF, and some other detailed adjustments.

Do you remember whether there were any specific product features or roadmap decisions that were made based on the premise that you believed models would not only become smarter, but become very, very smart? Did these decisions later really become the key to letting you "win the game"?

Because you also mentioned earlier that there were actually still a dozen very good companies in this field doing similar things at the time—but in the end you moved ahead. Was that related to your betting early on on leap-style model evolution and making different product roadmaps accordingly?

One less obvious product decision we made at the time was not to build a browser extension, but instead to build an editor from scratch. At the time, this choice was not intuitive to many people, and was even a bit contrary to expectations.

But the logic behind it actually came from our radical vision of the future—we believed that all programming would eventually be done through these models, and that the whole shape of programming would be completely different. To achieve that form, you have to have complete control over the user interface (UI), and cannot be limited by off-the-shelf platforms or interfaces. So from the very beginning we decided to build our own editing environment, rather than attaching ourselves to someone else's system.

It is 2025, and I think we have actually only just stepped into the prelude to the "Intelligence Age." It is truly a thorough revolution. Personally, what excites you most and what are you most looking forward to now?

I think in the next ten years, everyone's "creativity" will be greatly amplified—those who have always been active on the front lines of creation will become more powerful, and more people who previously had no chance to get hands-on will also find it within reach.