Cursor's goal is to create a brand new way of programming.

Author: Xin

As one of the fastest-growing products in history, Cursor reached a $100 million ARR just 20 months after its launch. In the following two years, it broke through $300 million ARR and continues to lead the transformation of how engineers and product teams develop software. By early 2025, Cursor had over 360,000 paying users.

Michael Truell is the co-founder and CEO of Anysphere, the parent company of Cursor. He founded Anysphere with three MIT classmates and launched Cursor in three months. Michael Truell rarely accepts podcast interviews, having only appeared on the Lex Fridman Podcast before. In this episode, he discusses his predictions for the "After Code" era, the counterintuitive experiences during the development of Cursor, and his views on future trends for engineers.

This content is from Lenny's Podcast, and here is the full compilation.

- Cursor's goal is to create a brand new way of programming: In the future, people will see pseudocode that is closer to English sentence structure. Individuals will have strong control over various details of software, with the ability to modify and iterate very quickly.

- "Taste" will become increasingly valuable: The core of "taste" is having a clear understanding of "what should be built."

- The best users of AI are very conservative in their technical applications: They are very good at limiting the scope of tasks they hand over to AI to be smaller and more specific.

- The core of Cursor's interview process is a two-day assessment: These assessment projects are simulated but can lead candidates to produce real work results in two days. This is not only a test of "whether they are willing to work with you" but is also very important for attracting candidates. In the early days, the only thing that could attract people to join was often a team they felt was worth fighting for together.

The main problem with chatbot-style programming is the lack of precision

Lenny: We previously discussed what will happen in the After Code era. How do you see the future development direction of Cursor? How will technology shift from traditional code to other forms?

Michael Truell: Cursor's goal is to create a brand new way of programming, a unique way of building software. You only need to describe your intentions to the computer in the simplest way, defining how the software should work and how it should present itself.

With the continuous maturation of today's technology, we believe we can pioneer a new method of software construction that will be higher, more efficient, and easier to use than the current level. This process will be very different from how software is written today.

I want to compare this with several mainstream views on the future of software forms, some of which we do not quite agree with.

One view is that future software construction will still be very similar to today, primarily relying on text editing using formal programming languages like TypeScript, Go, C, and Rust. Another view is that you only need to input commands into a chatbot to help you build software and modify it at any time. This chatbot style is like having a conversation with your engineering department.

We believe both visions have problems.

The main issue with chatbot-style programming is the lack of precision. If you want people to have complete control over the appearance and functionality of software, you need to provide a more precise way to instruct them to make the desired modifications, rather than saying in a chat box to a robot, "change this part of my app," and then everything gets deleted.

On the other hand, the worldview that believes nothing will change is also incorrect, as technology will only become more powerful. In the "After Code" world we envision, the expression of software logic will be closer to English.

You can imagine it existing in a more standardized form, evolving towards pseudocode. You will be able to write the logic of the software, edit it at a higher level, and easily browse it. It will not be obscure code consisting of millions of lines that is difficult to understand. Instead, it will be clearer, easier to understand, and easier to locate. We are working to evolve complex symbols and code structures into forms that are easier for people to read and edit.

In the After Code era, taste will become increasingly valuable

Lenny: This is profound, and I want to ensure everyone understands your point. The transformation you envision is that people will no longer see code and will not need to think in terms of JavaScript or Python. Instead, it will be a more abstract form of expression, closer to English sentence structure in pseudocode.

Michael Truell: We believe it will eventually develop to that stage. We believe achieving this stage requires the involvement and promotion of existing professional engineers. In the future, people will still be in the driver's seat as the leaders.

Individuals will have strong control over various details of software and will not easily relinquish that control. People will also have the ability to modify and iterate very quickly. The future will not rely on slow engineering processes that happen in the background and take weeks to complete.

Lenny: This raises a question: for current engineers or those considering becoming engineers, designers, or product managers, what skills do you think will become increasingly valuable in the "After Code era"?

Michael Truell: I believe "taste" will become increasingly valuable. When people talk about taste in the software field, they often think of visual effects, smooth animations, color schemes, UI, UX, and so on.

Visuals are very important for products. But as mentioned earlier, I believe the other important half lies in the product's logic and operation.

We have many tools to design visuals, but code remains the best expression of the software's operational logic. You can use Figma to showcase effects or roughly sketch in notes. But only when you have a truly usable prototype can the logic be clearly presented.

Future engineers will increasingly resemble "logic designers." They will need to express intentions precisely, shifting from the behind-the-scenes "how to implement" to the higher-level "what to implement" and "what it is," which means "taste" will become more important in software development.

We are not yet at that point in software engineering. There are many interesting and thought-provoking anecdotes circulating online that reflect people's over-reliance on AI development, leading to software with obvious flaws and functional issues.

But I believe that future software engineers will not need to focus so much on detail control as they do now; we will gradually shift from meticulousness to a greater emphasis on "taste."

Lenny: This reminds me of vibe coding. Is it similar to what you describe as programming without having to think too much about the details, but rather going with the flow?

Michael Truell: I think there is a connection. The vibe coding people are currently discussing, in my view, describes a controversial creative mode where a lot of code is generated without truly understanding its details. This mode can lead to many problems. If you do not understand the underlying details, you will quickly find that what you create becomes too large and difficult to modify.

What we are actually interested in is: how people can still perfectly control all details without fully understanding the underlying code. This solution is closely related to vibe coding.

We currently lack the ability to let "taste" truly dominate software construction. One problem with vibe coding or similar modes is that while you can create something, much of it is based on clumsy decisions made by AI, and you cannot fully control it.

Lenny: You mentioned "taste." What does that specifically refer to?

Michael Truell: Having a clear idea of "what should be built." This idea can also be increasingly easily translated; it is the software you want to create, how it looks, and how it operates.

Unlike now, where you and your team have a product concept but need a translation layer, requiring a lot of effort and labor to convert it into a format that computers can understand and execute.

"Taste" has little to do with UI. Perhaps the term "taste" is not entirely appropriate, but its core is having the correct understanding of "what should be built."

The birth of Cursor stems from the exploration of a question

Lenny: I want to revisit the origin of Cursor; many listeners may not know how it came to be. You are building one of the fastest-growing products in history. Cursor is profoundly changing the way people build products and even transforming the entire industry. How did all this begin? What memorable moments were there in the early development process?

Michael Truell: The birth of Cursor originated from our exploration of a question, and to a large extent, our thoughts on how AI will improve over the next decade. There were two key moments.

The first was when we first used the beta version of Copilot. This was our first encounter with a practical AI product that could genuinely help, rather than being a flashy demo. Copilot is one of the most valuable development tools we have used to date, and it excited us.

The second was when companies like OpenAI released a series of papers on model scaling. These studies showed that even without disruptive new ideas, simply by scaling up the model and increasing the amount of training data, AI's capabilities would become stronger. By the end of 2021 and the beginning of 2022, we were very confident about the prospects of AI products; this technology is destined to mature in the future.

As we looked around, we found that while many people were talking about how to build models, few were truly delving into a specific knowledge work domain to think about how this field would progress with the advancement of AI technology.

This made us wonder: as this technology matures, what changes will occur in these specific fields in the future? What will the final form of work look like? How will the tools we use to accomplish work evolve? What level does the model need to reach to support these changes in work forms? Once model scaling and pre-training can no longer enhance capabilities, how do we continue to push the boundaries of technological capability?

The initial mistake Cursor made was that we chose a field that was less competitive and rather dull. No one would pay attention to such a boring field.

At that time, everyone thought programming was hot and interesting, but we felt that many people were already doing it.

For the first four months, we were actually working on a completely different project—helping mechanical engineering achieve automation and enhancement, building tools for mechanical engineers.

But we encountered a problem right from the start: neither my co-founders nor I are mechanical engineers. Although we have friends in the field, we are extremely unfamiliar with it; we could say we were "blind men touching an elephant." For example, how could we truly apply existing models to mechanical engineering? Our conclusion at the time was that we had to develop our own models from scratch. This approach was very tricky because there was almost no publicly available data online about various tools and parts' 3D models and their construction steps, and it was equally difficult to obtain models from channels that had these resources.

But eventually, we came to our senses and realized that we were not very interested in mechanical engineering; it was not something we wanted to dedicate our lives to.

Looking back at the programming field, despite a considerable amount of time having passed, there had not been significant changes. Those working in this field seemed disconnected from our ideas; they lacked sufficient ambition and foresight regarding future development directions and how AI would reshape everything. It was these realizations that led us down the path of building Cursor.

Lenny: I really like the advice to pursue seemingly boring industries because there is less competition and opportunities exist; sometimes this indeed works. But I prefer another line of thought—boldly chasing the hottest and most popular fields, such as AI programming and application development, which has proven to be viable as well.

You feel that existing tools lack sufficient ambition or potential, and that there is more to be done. I think this is a very valuable insight. Even if a field seems too late, with products like GitHub Copilot already existing, if you find that the ambition of existing solutions is not large enough to meet your standards or that there are flaws in their methods, there are still huge opportunities hidden within. Is that correct?

Michael Truell: Absolutely agree. To achieve breakthrough progress, we need to find specific things we can do. The allure of AI lies in the fact that, including AI programming, there are still vast unknowns in many areas.

Many fields have a very high ceiling. Looking around, even for the best tools in any given field, there is still a lot of work to be done in the coming years. Having such a vast space and such a high ceiling is quite unique in software development, at least for AI.

Cursor emphasized Dogfooding from the very beginning

Lenny: Let's return to the IDE (Integrated Development Environment) issue. You have several different routes, and other companies are also trying.

One is to build an IDE aimed at engineers and integrate AI capabilities within it. Another is a complete AI Agent model, like products such as Devin. There is also a focus on building a model that excels at coding, dedicated to creating the best coding model.

What made you ultimately decide that IDE was the best route?

Michael Truell: Those who have only focused on developing models from the very beginning or trying to achieve end-to-end automated programming are trying to build something that is fundamentally different from what we are doing.

We are more focused on ensuring that people can maintain control over all the decisions made in the tools they build. In contrast, they are more envisioning a future where AI completes the entire process, even taking responsibility for all decisions.

So on one hand, our choice includes an interest-driven component. On the other hand, we always strive to view the current technological level from a very realistic perspective. We are incredibly excited about the potential for AI to develop over the next few decades, but sometimes people tend to anthropomorphize these models when they see AI performing well in a certain field, believing that it will also excel in another field.

But these models have significant issues. From the very beginning, our product development emphasized "Dogfooding," and we use Cursor extensively every day, never wanting to release any features that are useless to us.

We are the end users of the product, which gives us a realistic understanding of the current technological level. We believe it is crucial to have people in the "driver's seat"; AI cannot take care of everything.

For personal reasons, we also want to empower users with this control. This way, we are not just a model company, and we move away from the end-to-end product development mindset that deprives people of control.

As for why we chose to build an IDE instead of developing a plugin for existing programming environments, it is because we firmly believe that programming will be conducted through these models, and the way programming is done will undergo significant changes in the coming years. The scalability of existing programming environments is so limited that if you believe the UI and programming paradigms will undergo disruptive changes, you must have comprehensive control over the entire application.

Lenny: I know you are currently working on an IDE, and perhaps this is your bias, as you believe this is the future direction. But I am curious, do you think a large part of the work in the future will be done by AI engineers helping you in tools like Slack? Will this approach one day be incorporated into Cursor?

Michael Truell: I think the ideal situation is that you can easily switch between these things. Sometimes, you might want AI to run independently for a while; other times, you might want to pull out the results of AI's work and collaborate efficiently with it. Sometimes you might let it run autonomously again.

I believe you need a unified environment where both backend and frontend forms can operate well. For backend operations, programming tasks that can be precisely specified with minimal instructions and correct standards are particularly suitable. Fixing bugs is a great example, but it is certainly not all of programming.

The essence of the IDE will fundamentally change over time. The reason we chose to build our own editor is that it will continue to evolve. This evolution includes your ability to take over tasks from different interfaces, such as Slack and issue tracking systems; the glass screen you stare at daily will also undergo significant changes. We currently view the IDE as a place to build software.

The most successful users of AI are actually quite conservative in their technical applications

Lenny: I think one point that people do not fully realize when discussing Agents and these AI engineers is that we will largely become "engineering managers," managing many subordinates who are not that smart, and you have to spend a lot of time reviewing, approving, and specifying requirements. What are your thoughts on this issue? Is there any way to simplify this process?

Because it sounds really difficult; anyone who has managed a large team knows this well—"These subordinates always come back to me with work of varying quality, which is so exhausting."

Michael Truell: Yes, maybe in the end, we will have to communicate one-on-one with all these Agents.

We have observed that the most successful users of AI are actually quite conservative in their technical applications. I do believe that the currently most successful users rely heavily on features like our "Next Edit Prediction." In their regular programming workflow, our AI intelligently predicts the next action to be taken. They are also very good at limiting the scope of tasks they hand over to AI to be more specific and smaller.

Considering the time cost you spend reviewing code, there are mainly two modes of collaboration with Agents. One is that you can spend a lot of time upfront detailing the requirements, letting AI work independently, and then reviewing the results of AI's work. Once you finish the review, the entire task is complete.

The other is that you can break the task down into smaller parts. Each time, you specify just a small portion for AI to complete, then review; further give instructions for AI to continue, and then review again. This achieves a sort of autocomplete functionality throughout the process.

However, we often observe that the users who excel at using these tools still tend to break down tasks and maintain task manageability.

Lenny: That's rare. I want to return to when you first built Cursor. When did you realize it was ready? When did you feel it was time to release it and see what would happen?

Michael Truell: When we first started building Cursor, we were very worried about spending too long on development and not being able to release it to the outside world. The initial version of Cursor was completely "handcrafted" from scratch. Now we use VS Code as a foundation, just as many browsers use Chromium as their core.

But it wasn't like that at the beginning; we developed the prototype of Cursor from scratch, which involved a lot of work. We had to develop many features required by modern code editors ourselves, such as support for multiple programming languages, navigation between codes, error tracking, etc. Additionally, we needed to have a built-in command line and the ability to connect to remote servers to view and run code.

We developed rapidly at lightning speed, building our own editor completely from scratch while simultaneously developing the AI component. About five weeks later, we had started using our own editor entirely, completely discarding the previous editor and diving into the practice of the new tool. When we felt it reached a certain level of practicality, we handed it over to others for trial, conducting a very brief beta test.

From writing the first line of code to officially releasing to the public, Cursor took only about three months. Our goal was to get the product into users' hands as quickly as possible and iterate rapidly based on public feedback.

To our surprise, we initially thought this tool would attract only a few hundred users for a long time, but a large number of users flooded in from the very beginning, providing a lot of feedback. The initial user feedback was extremely valuable, and it was this feedback that prompted us to decide to abandon the version built from scratch and instead develop based on VS Code. Since then, we have been continuously optimizing the product in a public environment.

Launching the product in three months and achieving $100 million ARR in one year

Lenny: I appreciate your modesty regarding your achievements. As far as I know, you increased your ARR from $0 to $100 million in about a year to a year and a half, which is undoubtedly a historic achievement.

What do you think are the key elements of success? You just mentioned using your own product as one of them. But it’s incredible that you were able to launch the product in just three months. What is the secret behind this?

Michael Truell: The first version, the one completed in three months, was not perfect. So we have always had a sense of continuous urgency, feeling that there are still many areas where we can do better.

Our ultimate goal is to truly create a new programming paradigm that can automate a large amount of coding work we are familiar with today. No matter how much progress Cursor has made so far, we feel we are still far from that ultimate goal, and there is always much work to be done.

Many times, we have not overly obsessed with the initial release effect but have focused more on the continuous evolution of the product, committed to constantly improving and refining this tool.

Lenny: After those three months, was there a turning point that made everything take off?

Michael Truell: To be honest, the initial growth felt quite slow, perhaps because we were a bit impatient ourselves. But in terms of overall growth rate, it has consistently surprised us.

I think the most unexpected part is that this growth has actually maintained a stable exponential trend, with continuous growth every month, although new version releases or other factors sometimes accelerate this process.

Of course, this exponential growth felt quite slow in the early stages, and the base was indeed very low, so it didn't really show a dramatic surge at first.

Lenny: It sounds like an example of "build it, and they will come." You just created a tool you liked, and once it was released, everyone else liked it too, leading to word-of-mouth.

Michael Truell: Yes, that's pretty much it. Our team focused most of our energy on the product itself, without getting distracted by other things. Of course, we also spent time on many other important tasks, like building the team and rotating responsibilities for user support.

However, for many routine tasks that startups often invest energy in during the early stages, we "put the issues aside," especially in sales and marketing.

We focused our energy on refining the product, first creating something that our team liked, and then iterating based on feedback from a core group of users. It may sound simple, but it is not easy to do well.

There are many directions to explore and many different product paths. One of the challenges is maintaining focus, strategically choosing the key features to build, and determining priorities.

Another challenge is that the field we are in represents a brand new product development model: we are positioned between a traditional software company and a foundational model company.

We are developing products for millions of users, which requires us to achieve excellence at the product level. But another important dimension of product quality lies in continuously deepening scientific research and model development, constantly optimizing the models themselves in key scenarios. Balancing these two aspects is always challenging.

The most counterintuitive thing was not anticipating developing our own models

Lenny: So far, what do you think has been the most counterintuitive aspect of building Cursor and developing AI products?

Michael Truell: For me, the most counterintuitive point was that we initially had no idea we would develop our own models. When we first entered this field, there were already companies focused on model training from the start. We had calculated the costs and resources required to train GPT-4 and knew very well that this was not something we could do.

There are already many excellent models on the market; why go to great lengths to replicate what others have already done? Especially in terms of pre-training, which requires a neural network that knows nothing about anything to learn from the entire internet. Therefore, we initially had no intention of going down this path. From the beginning, we were clear that there were many things existing models could do that had not yet been realized due to a lack of suitable tools built for these models. Yet, we still invested a lot of energy into model development.

Because every "magical moment" you experience while using Cursor stems from our custom models. This process is gradual. We initially tried training our own model on a use case because it was not well suited for any mainstream foundational model, and it was quite successful. We then extended this approach to another use case, which also went well, and we continued to push forward.

A key point in this type of model development is to precisely select targets and avoid reinventing the wheel. We do not touch areas where top foundational models have already performed very well, but focus on their weaknesses and think about how to fill those gaps.

Lenny: Many people are surprised to hear that you have your own models. Because when people talk about Cursor and other products in this field, they often refer to them as "GPT shells," thinking they are just tools built on top of models like ChatGPT or Sonnet. But you mentioned that you actually have your own models. Can you talk about the technology stack behind this?

Michael Truell: We do use the most mainstream foundational models in various scenarios.

In the key aspects of providing the Cursor experience to users, we rely more on our self-developed models, especially for use cases that foundational models cannot handle due to cost or speed. One example is autocomplete.

This may be hard for non-coders to understand. Writing code is a unique task. Sometimes, the work you will do in the next 5 minutes, 10 minutes, 20 minutes, or even half an hour can be completely predicted by observing your current actions.

Compared to writing, many people may be familiar with Gmail's autocomplete feature and the various autocomplete suggestions that appear when editing texts like messages and emails. But these functions have limited utility. Because it is often difficult to infer what you will write next based solely on what has already been written.

However, when writing code, if you modify one part of the codebase, you often need to synchronize changes to other parts of the codebase, and these necessary modifications are quite obvious.

One of the core features of Cursor is this enhanced autocomplete. It can predict a series of actions you will take next across multiple files and different locations within files.

For the model to perform well in this scenario, its speed must be fast enough to ensure that it provides autocomplete results within 300 milliseconds. Cost is also an important factor, as each keystroke triggers thousands of inferences, constantly updating predictions about your next action.

This also involves a very special technical challenge: we need the model not only to complete the next token as it would for ordinary text sequences but to excel at completing a series of diffs (code changes), predicting the possible additions, deletions, and modifications based on changes that have already occurred in the codebase.

We specifically trained a model for this task, which has been very effective. This part is entirely self-developed, and we have never called on any foundational models. We have not branded or labeled this technology, but it is core to Cursor.

Another scenario where we use our self-developed models is to enhance the performance of large models like Sonnet, Gemini, or GPT, especially in terms of output and input.

In the input phase, our model searches the entire codebase to identify relevant parts to present to these large models. You can think of it as a "mini Google search" specifically designed to find relevant content in the codebase.

In the output phase, we process the modification suggestions provided by these large models, using our specially trained model to supplement and refine the details. For example, higher-level logical designs are completed by more advanced models, which will spend some tokens to provide overall direction. Other smaller, more specialized, and faster models will combine some inference optimization techniques to transform these high-level modification suggestions into complete, executable code transformations.

This approach significantly improves the quality of specialized task completion and greatly accelerates response speed. For us, speed is also a key metric for evaluating our product.

Lenny: That's very interesting. I recently interviewed OpenAI's CPO, Kevin Weil, on a podcast, and he referred to this as an ensemble of models.

They also leverage the strengths of each model. Using cheaper models can be very advantageous in terms of cost. Are the models you trained based on open-source models like LLaMA?

Michael Truell: We are very pragmatic in this regard and do not want to reinvent the wheel. Therefore, we start with the best pre-trained models available on the market, usually open-source, and sometimes collaborate with large models that do not open their weights to the outside world. We are not too concerned about whether we can directly read or linearly search the weight matrices that determine output results; we care more about the ability to train and post-train the models.

The ceiling for AI products is like personal computers and search engines in the last century

Lenny: Many AI entrepreneurs and investors are pondering a question: where are the moats and defenses for AI? Custom models seem to be a way to establish a moat. In a situation where competitors are constantly trying to innovate and take your market share, how do you acquire long-term defensive capabilities?

Michael Truell: I do believe there are some traditional methods to establish user inertia and moats. But ultimately, we must continuously strive to build the best products. I firmly believe that the ceiling for AI is very high, and no matter what barriers you build, they can always be surpassed.

This market is somewhat different from the traditional software market or enterprise market of the past. A comparable example to this market is the search engine boom from the late 1990s to the early 2000s. Another is the development of personal computers and microcomputers from the 1980s to the 1990s.

The ceiling for AI products is very high, and products iterate quickly. You can continuously gain huge outputs from the incremental value of a smart person's work every hour and the incremental value of every dollar spent on R&D. This state can last a long time. You will never run out of new features to develop.

Especially in the search field, increasing distribution channels also helps improve products because you can continuously iterate algorithms and models based on user data and feedback. I believe these dynamic changes also exist in the industry we are in.

For us, this may be a somewhat helpless reality. But for the world as a whole, it is an exciting truth. Many leading products will emerge in the future, and there are still many meaningful features waiting to be created.

We are far from the vision of five to ten years from now; what we need to do is keep the innovation engine running at high speed.

Lenny: It sounds more like establishing a "consumer-style" moat. Continuously providing the best product so that users want to keep using it, rather than binding employees to use it through contracts like Salesforce.

Michael Truell: Yes. I think the key is that if the field you are in quickly runs out of valuable things to do, the situation is indeed not optimistic. But if, in this field, significant funding and the efforts of outstanding talent can continuously produce value, then you can enjoy the economies of scale in R&D, delve into technology in the right direction, and build moats.

This does indeed carry a certain consumer-oriented trend. But at the core of it all is building the best product.

Lenny: Do you think the future will be a "winner-takes-all" market, or will many differentiated products emerge?

Michael Truell: I think this market is very large. You mentioned the situation with IDEs earlier. Some people, when researching this field, look back at the IDE market over the past decade and then ask, "Who can actually make money by making editors?" In the past, everyone had their own preferred configurations. Only one company has achieved commercial profitability by creating an excellent editor, but its scale is also quite limited.

Some people conclude that the future will also follow this pattern. However, I believe this perspective overlooks one thing: the potential for building editors for programmers was limited in the 2010s.

The company that made money from editors primarily focused on simplifying codebase navigation, error checking, and providing useful debugging tools. While these features are valuable, I believe there is a tremendous opportunity in building tools for programmers and, more broadly, for knowledge workers across various fields.

The real challenge we face is how to automate a large number of tedious transactional and knowledge-based tasks. This is essential for achieving more reliable and efficient productivity improvements across all knowledge work domains.

I believe the market we are in is very large, far exceeding past perceptions of the developer tools market. In the future, a variety of solutions will emerge, and there may be an industry leader. It could be us, but that remains to be seen. This company will create a universal tool capable of assisting in the development of most software in the world, which will be a large enterprise with significant impact. At the same time, there will also be products focused on specific niche markets or particular stages of the software development lifecycle.

Ultimately, programming itself may shift from being written in traditional formal programming languages to a higher level, and these high-level tools will become the primary objects of user purchase and use. I believe there will be a dominant player in AI programming that will develop into an extremely large enterprise.

Lenny: Interestingly, Microsoft was at the center of this transformation before, with great products and strong distribution channels. You mentioned that Copilot made you realize the immense potential in this field, but it seems it hasn't fully captured the market. In fact, it seems somewhat behind. What do you think the reason is?

Michael Truell: I believe there are specific historical and structural reasons why Copilot has not fully met expectations.

From a structural perspective, Microsoft's Copilot project has provided us with great inspiration. They have done many remarkable things, and we are also many Microsoft users.

However, I think this market is not very friendly to mature enterprises. Markets that are friendly to them are often those with limited innovation space, where commercialization can happen quickly, and profits can be made through bundled product sales.

In such markets, the ROI differences between different products are not significant. The value of purchasing independent innovative solutions is limited, while bundled products are more attractive.

Another type of market that is particularly favorable to mature enterprises is: users are highly dependent on your tools from the very beginning, and the switching costs are very high.

But in our field, users can easily try different tools and choose which product suits them best based on their judgment. This situation is not very favorable for large companies; instead, it is more friendly to those with the most innovative products.

As for the specific historical reasons, from what I understand, most of the team members who were involved in the development of the first version of Copilot later went on to do other things at different companies. Coordinating among all relevant departments and personnel to create a product is indeed challenging.

Senior engineers have low expectations, while entry-level engineers have high expectations

Lenny: If you could sit next to every new user using Cursor for the first time and whisper a few suggestions to help them use Cursor better, what would you say?

Michael Truell: I think we need to address a problem at the product level right now.

Many users who successfully use Cursor have a certain "taste" for the model's capabilities. These users understand what tasks Cursor can accomplish and know what level of instructions to provide. They can grasp the quality and limitations of the model, as well as what it can and cannot do.

In the existing product, we have not done a good job of user education in this regard, nor have we provided clear usage guidelines.

To cultivate this "taste," I have two suggestions.

First, do not give the model all the tasks at once. You will either be greatly disappointed with the output or accept it entirely. Instead, I would break the tasks into smaller pieces. You can spend the same amount of time to achieve the final result, but do it step by step. Clearly define a small number of tasks at a time, obtain partial results, and repeat this process, rather than trying to write a long, convoluted instruction. This approach is likely to lead to disaster.

Second, it’s best to try it out on side projects first, rather than directly using it for important work. I would encourage developers who are accustomed to existing development processes to have more experiences of failure and to try to push the limits of the model.

They can leverage AI as much as possible in a relatively safe environment, such as in side projects. Many times, we find that some people have not given AI a fair chance and underestimate its capabilities.

By adopting a task decomposition approach and actively exploring the boundaries of the model, trying to push the limits in a safe environment, you may be surprised to find that AI does not make mistakes as you expected in some scenarios.

Lenny: My understanding is that you need to cultivate an intuition to understand the model's capability boundaries, what it can advance an idea to, rather than just acting on your instructions. And every time a new model is released, like when GPT-4 came out, you need to rebuild this intuition?

Michael Truell: That is indeed the case. Over the past few years, this feeling may not have been as strong as when people first encountered large models. But this is indeed a pain point we hope to address better for users in the future, to lighten their burden. However, each model has slightly different quirks and personalities.

Lenny: People have been discussing whether tools like Cursor help entry-level engineers more or senior engineers more. Do they enable senior engineers to be ten times more efficient, or do they help entry-level engineers become more like senior engineers? Who do you think benefits the most from using Cursor right now?

Michael Truell: I believe both types of engineers can gain tremendous benefits, and it is hard to say which group benefits more.

They may fall into different "anti-patterns." Entry-level engineers sometimes rely too much on AI, letting it do everything. However, we currently do not have the conditions to use AI end-to-end in professional tools, collaborating with dozens or even hundreds of people in a long-term maintained codebase.

As for senior engineers, while not everyone is like this, the adoption of these tools in companies is often hindered by some extremely senior individuals, such as those in developer experience teams. They are usually responsible for developing tools to enhance the productivity of other engineers within the organization.

We have also seen some very cutting-edge attempts, with some senior engineers leading the way, embracing and utilizing this technology as much as possible. On average, senior engineers tend to underestimate the help AI can provide them and are inclined to stick to existing workflows.

It is difficult to determine which group benefits more. I believe both types of engineers will encounter their own "anti-patterns," but they can both gain significant benefits from using such tools.

Lenny: That makes complete sense, like the two ends of a spectrum, one with expectations too high and the other with expectations too low. Just like the fable of the three bears.

Cursor Recruitment Core is a two-day assessment

Lenny: Before founding Cursor, what did you wish you had known? If you could go back to the early days of Cursor and give some advice to the Michael of that time, what would you tell him?

Michael Truell: The difficulty lies in the fact that many valuable experiences are implicit and hard to articulate. Unfortunately, in certain areas of human endeavor, you really need to fail personally to learn the lesson, or you need to learn from the best in that field.

We have a deep understanding of this in recruitment. In fact, we are extremely patient when it comes to hiring. For us, whether for personal vision or company strategy, having a world-class team of engineers and researchers to refine Cursor is crucial.

Since we need to build a lot of new things, we want to find those who possess both curiosity and a spirit of experimentation. We also look for those who are pragmatic, moderately cautious, and straightforward. As the company and business scale continue to expand, various noise will increase, making it especially important to maintain a clear mind.

Beyond the product, finding the right people to join the company may be our top priority, and that is why we have not expanded the team for a long time. Many people say that hiring too quickly can lead to problems, but I believe we were too slow in our initial hiring process; we could have done better.

The recruitment method we ultimately used has been very effective for us, focusing on finding what we consider to be world-class talent, sometimes even taking several years to recruit.

We have accumulated valuable experience in many areas, such as how to assess ideal candidates, who can truly integrate into the team, what excellence standards are, and how to communicate and spark interest in those who are not actively looking for jobs. We have indeed spent a lot of time learning to do these things well.

The four post-00s co-founders of Anysphere are Aman Sanger, Arvid Lunnemark, Sualeh Asif, and Michael Truell.

Lenny: What experiences can you share for companies currently hiring? What did you miss, and what did you learn?

Michael Truell: At first, we were too inclined to look for talent that fit the profile of prestigious school backgrounds, especially those young people who excelled in well-known academic environments.

We were fortunate to find some outstanding individuals early on. They were already very experienced in the workplace but were still willing to work on this project together.

When we first started hiring, we placed too much emphasis on interest and experience. While we have hired many excellent and talented young people, they are not the same as a senior lineup that has just stepped off the main stage.

We have also upgraded our interview process. We have a set of specially customized interview questions. The core part is to have candidates come to the company for two days to work on a two-day assessment project with us. This method has proven to be very effective, and we are continuously optimizing it.

We are also constantly learning about candidates' interests, providing attractive conditions, and initiating conversations to introduce job opportunities even when they are not actively seeking employment.

Lenny: Do you have any favorite interview questions?

Michael Truell: I initially thought this two-day work assessment would not apply to many people, but it has shown unexpectedly enduring vitality. It allows candidates to be involved from start to finish, just like completing a real project.

These projects are fixed, but they allow you to see real work results in just two days. Moreover, this won't take up a lot of the team's time; you can spread out the half-day or full-day on-site interview time over these two days, giving candidates ample time to complete the project. This actually makes it easier to scale.

The two-day project is also a test of "whether you want to work with this person." After all, you will be spending two days together, including having a few meals together.

Initially, we did not anticipate that this assessment would continue, but it has now become a valuable part of our hiring process. This is also very important for attracting candidates, especially in the early stages of the company when the product has not yet been widely used and its quality is not mature enough. The only thing that often attracts people to join is a team they feel is special and worth fighting for together.

The two days give candidates a chance to understand us, and even allow them to believe they want to join us. The effect of this assessment has far exceeded expectations. It is not strictly a set of interview questions but more like a forward-looking interview model.

Lenny: Is this ultimate interview question where you give them a task, like building a certain feature in our codebase, collaborating with the team to code and release it?

Michael Truell: That's pretty much it. We don't use IP, nor do we directly integrate the project results into the product line; it's a simulated project. Typically, we arrange a real two-day mini-task in our codebase, where they will independently complete end-to-end work, although there are collaborative elements as well.

We are a company that places great emphasis on offline collaboration, so in almost all cases, they will be sitting in the office with us to complete the project.

Lenny: You mentioned that this interview method has continued; how large is your team now?

Michael Truell: We have about 60 people.

Lenny: Given your influence, that size is really not large; I thought it would be much bigger. I guess the majority are engineers.

Michael Truell: One of our most important tasks moving forward is to build a larger and more excellent team to continuously optimize the product and improve customer service quality. So we do not plan to maintain such a small scale for the long term.

One reason for our smaller team size is that the proportion of engineers, researchers, and designers within the company is very high. Many software companies, when they have about 40 engineers, often exceed 100 people in total due to a lot of operational work, and these companies typically rely heavily on sales from the start, which requires a lot of manpower.

From the very beginning, we adopted an extremely streamlined, product-centric model. Now, we serve numerous market customers and continue to expand on that basis. However, we still have a lot of work to do in the future.

Lenny: The AI field is undergoing tremendous changes, with new developments every day and many newsletters telling you what is happening in AI daily. As the manager of a hot, core company, how do you stay focused? How do you help your team work undistracted and deeply engaged in the product without being sidetracked by these endless new things?

Michael Truell: I think hiring is key. The focus is on whether you can hire the right people with the right attitude. I believe we are doing well in this regard, though we could perhaps do even better.

This is also a topic we discuss more within the company; hiring people with the right personality is very important. They should not be overly concerned with external validation but focus more on creating excellent products, delivering high-quality work, and generally maintaining a calm demeanor without extreme emotional fluctuations.

Hiring can help us tackle many challenges, and this is a consensus throughout the company. Any organization needs processes, hierarchies, and various systems, but for any organizational tool introduced into the company to achieve its intended effect, it can largely be accomplished by hiring people with the corresponding traits.

One example is that we operate well in engineering without too many processes. I believe we need to add some processes. But because the company is small, as long as we hire truly outstanding talent, there is no need to set up too many processes.

First, we need to hire calm and composed individuals. Second, we need to communicate thoroughly. Third, we need to lead by example.

From 2021 to 2022, we have been focusing on AI work. We have witnessed significant changes in various technologies and ideas. If you could go back to the end of 2021 or the beginning of 2022, when GPT-3 existed but InstructGPT did not, and DALL-E and Stable Diffusion had not yet appeared.

The birth of all these image technologies, the emergence of InstructGPT, the release of GPT-4, and the influx of various new models, different technologies, modalities, and video-related technologies. Only a very few of these have had an impact on our business. We have built a certain immunity to know which advancements are truly important to us.

Even with a lot of discussions, only a few things are genuinely important. The AI field over the past decade has reflected this, with academia publishing a vast number of papers on deep learning and AI. But what is astonishing is that many advancements in AI stem from some very simple, elegant, and timeless ideas. The vast majority of proposed ideas have neither stood the test of time nor made a significant impact. The current dynamics are somewhat similar to the development of deep learning as a field.

The demand for engineers will only continue to grow

Lenny: What misconceptions still exist about the direction of AI development and how it will change the world? Or what aspects are not fully understood?

Michael Truell: People still have somewhat extreme views, either thinking everything will happen very quickly or believing it is all hype and exaggeration.

We are in the midst of a technological transformation that will have far-reaching implications, surpassing the internet and any technological change we have seen since the advent of computers. But this transformation will take time; it will be a process that lasts for decades, with many different teams playing important roles in driving its development.

To achieve a future where computers can take on more and more of our work, we need to solve all these independent technical challenges continuously.

Some of these are scientific challenges, such as making models understand different types of data, becoming faster, cheaper, smarter, better suited to the modalities we care about, and taking action in the real world.

There are also issues concerning human-computer collaboration, thinking about what people should see, control, and how to interact with these technologies on computers. I believe this will take decades, with a lot of exciting work to be done.

I think a certain type of team will be especially important. This is not self-promotion, but these companies need to focus on automating specific knowledge work areas, building underlying technologies for that field, and integrating the best third-party technologies. Sometimes they also need to develop their own products and experiences.

The importance of these teams lies not only in the value they provide to users but also in the fact that as they scale, they will play a key role in driving technological advancement. The most successful teams will have the ability to build large enterprises, and I look forward to seeing more similar companies emerge in other fields.

Lenny: I know you are looking for people who are interested in "I want to work here and build this kind of product." What kind of people are you currently looking for? Specifically, which positions are you recruiting for? Which positions do you hope to fill as soon as possible? If someone is interested, what information do they need to know?

Michael Truell: There is so much for our team to accomplish, but many things have not yet been done. We have a lot to do, and if you feel like we are not currently recruiting for a specific position, it might be better to reach out to us first. Perhaps you can bring us new ideas and help us realize gaps we haven't noticed.

I think the two most important things this year are to build the best product in this field and to grow. We are in a phase of capturing market share, and currently, almost everyone globally either has not used our similar tools or is using slower-developing products from others. Driving the growth of Cursor is an important goal.

We are always looking for excellent engineers, designers, and researchers, and we are also looking for other talents.

Lenny: There is a saying that AI will replace engineers to complete all coding. But this contrasts sharply with reality, as everyone is still hiring engineers like crazy, including companies developing foundational models. Do you think there will be a turning point where the demand for engineers starts to slow down?

I know this is a big question; do you think all companies will increasingly need engineers? Or do you think at some stage, there will be a lot of Cursor instances running to handle development work?

Michael Truell: We have always believed this is a long and complex process that will not happen overnight, directly achieving a state where you just need to give instructions, and AI can completely replace the engineering department.

We very much hope to promote a smooth evolution in the way programming is done, always keeping humans in the lead. Even in the final state, it remains crucial to empower people with control over everything, and it requires professionals to decide the appropriate form of software. So I believe engineers are indispensable; they will be able to do more.

The demand for software is persistent. This is not a new thing, but think about it: building those seemingly simple and easy-to-define things often incurs costs and manpower consumption that are beyond imagination. At least from an outsider's perspective, these things should not be difficult to accomplish, but in reality, they are quite challenging to do well. If you can reduce development costs and manpower input by another order of magnitude, you can achieve more new possibilities on computers and develop countless new tools.

I have deep experience with this. I once worked at a biotechnology company, responsible for developing internal tools for it. At that time, the tools available on the market had a terrible experience and completely failed to meet the company's needs. The demand for the internal tools I could build far exceeded my personal development capacity.

The physical performance of computers has long been strong enough; they should allow us to move or build anything we want at will, but in reality, there are too many obstacles. The demand for software far exceeds current development capabilities because developing a simple productivity software can cost as much as making a blockbuster movie. Therefore, in the distant future, the demand for engineers will only continue to grow.

Lenny: Is there anything we haven't mentioned that you would like to add? Any wisdom you would like to leave for the audience?

Michael Truell: We have been thinking about how to build a team that can both create new things and continuously improve products. If we want to succeed, IDEs must undergo significant changes. Their future form must also be very different.

If you look at the companies we admire, you will certainly see examples of those that have continuously led multiple technological leaps and pushed the industry frontier, but such companies are very few.

On one hand, we need to think about related issues in our daily work, reflecting from first principles. It is also important to study past successful cases in depth, which is something we often think about.

Lenny: I noticed you have many books behind you, one of which is about the history of an old computer company that has been influential in many ways, but I have never heard of it. This resonates with me because many innovative thoughts often stem from a review of history and the study of past successes and failures.

If someone wants to contact you or apply for a position, how should they find relevant information online? You mentioned there might be some positions they haven't realized exist; where should they go to learn about them? How can the audience help you?

Michael Truell: If anyone is interested in these positions, they can find our products and contact information at cursor.com.

Lenny: Great. Michael, thank you very much for being here today.

免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。