The Shift in AI Programming

The AI programming field is undergoing a profound paradigm shift, with the rise of Cursor serving as a powerful testament to this trend. From the reflections of its founder, we gain insight into how AI programming tools are reshaping development processes and the key to continuously creating exceptional products that stand out in competition.

Cursor, built by AnySphere co-founder and CEO Michael Truell, is not only one of the fastest-growing AI programming products currently but also an early form of the future “post-code era.”

With a current team of 60, Cursor achieved an annual recurring revenue of $100 million just 20 months after its launch, growing to $300 million within two years, making it one of the fastest-growing development tools in history. This achievement is supported not only by enhanced code generation capabilities but also by a complete restructuring and redefinition of the software development process.

Michael, a technical person with a decade of experience in AI, majored in mathematics and computer science at MIT and later worked in research engineering at Google. He has a deep understanding of both AI technology pathways and business history.

In a conversation with overseas tech blogger Lenny, he clearly depicted a future that differs from mainstream assumptions: code will not be completely replaced, but it will no longer be the primary output of humans. People will express their ideas about software functions and behaviors in a manner close to natural language, while the system will be responsible for converting these intentions into executable program logic.

He pointed out that the mainstream views on the future of AI programming have two misconceptions. One is that development methods will largely remain the same, continuing to rely on languages like TypeScript, Go, and Rust to build programs; the other believes that the entire development process can be completed merely through conversations with chatbots.

Multiple Development Approaches Coexisting

When discussing the starting point of Cursor, Michael reflected on two key moments:

The first was their initial exposure to the internal testing version of GitHub Copilot. This was their first experience with a truly practical AI development tool that not only was not a gimmick but also significantly improved work efficiency.

The second moment was their study of a series of Scaling Law papers published by OpenAI and other research institutions. These papers made them realize that even without new algorithms, as long as they continued to expand model parameters and data scale, AI would continue to evolve.

By the end of 2021 and early 2022, they firmly concluded that the era of AI products had truly arrived. However, unlike most entrepreneurs who focused on “building large models,” Michael and his team attempted to think in reverse from the perspective of knowledge work, considering how various specific work scenarios would evolve under AI enhancement.

At that time, they chose a seemingly niche direction—mechanical engineering. They believed this field had less competition and a clear problem space, so they began automating CAD tools. However, they soon found themselves lacking sufficient passion for mechanical engineering and data corpus, making development very challenging.

Ultimately, they decided to return to the area they were most familiar with: programming. Although there were already products like Copilot and CodeWhisperer in the market, they believed no one had truly pushed the vision to its limits. Despite being one of the hottest and most competitive areas, they still judged that the “ceiling” was high enough to support a breakthrough product company. They abandoned the strategy of “avoiding hot zones” and chose the route of “digging deep in hot zones.”

One of Cursor’s core decisions was not to create a plugin but to build a complete IDE. They believed that the existing IDE and editor architectures could not adapt to future development methods and human-computer interaction logic.

“We want to have control over the entire interface and redefine the interaction interface between developers and systems.” This was not only to achieve a more natural control granularity but also to build a system base that could truly support the next generation of programming paradigms.

Michael also believes that future development methods will coexist in multiple forms. Sometimes AI acts as an assistant, completing tasks in Slack or issue trackers; sometimes it is an IDE front-end interaction; it may also run a process in the background while iterating control in the foreground. These are not contradictory, as long as users can flexibly switch between full automation and manual control, it is a qualified system.

Regarding the current industry trend of “agent fever,” he expressed a reserved attitude. Completely delegating tasks to AI could turn developers into “engineering managers” who must constantly review, approve, and modify outputs from a group of “very dumb interns.” “We do not believe in that path. The most effective way is to break tasks down into multiple steps, allowing AI to complete them step by step while humans maintain dominance.”

Cursor’s early versions were developed entirely from scratch, without relying on any existing editors. Initially, they spent just five weeks building a usable prototype and quickly replaced their original development tools. The entire process of writing code from scratch to launch took only three months. The unexpectedly positive user feedback after the release prompted them to iterate quickly, ultimately finding a balance between performance, experience, and development speed, and then restructured based on the VS Code framework.

However, in Michael’s view, true success is not about the speed of the initial version but about the continuous optimization that follows. He admits, “The initial version in the first three months was actually not very usable; the key is that we maintained a paranoid improvement rhythm.” This continuous optimization rhythm ultimately formed a very stable growth trajectory for Cursor. Although there was no obvious feeling of “takeoff” in the early stages, the cumulative effect of the exponential curve eventually exploded after multiple iterations.

Running in the Right Direction Every Day

Although Cursor’s explosion seems to stem from a key feature or product decision, Michael Truell states that the real secret is quite simple: “Run in the right direction every day.”

This sounds ordinary, but it is extremely difficult to sustain. Every decision and every iteration detail is based on the user’s perspective, constantly getting closer to actual scenarios, continuously simplifying and optimizing. They never rely on one-time hits but firmly believe that product value must withstand the test of continuous use and real feedback.

In line with this philosophy is the technical path choice behind Cursor. Michael mentioned that the team initially had no intention of training their own models when building Cursor. In his view, there were already sufficiently powerful open-source and commercial base models at that time, and investing computing power, funds, and manpower to build new models from scratch was not only costly but also deviated from their true focus: building useful tools and solving specific problems.

However, as the product evolved, they gradually realized that existing base models, while powerful, could not meet the key scenarios in Cursor. Most of these models were trained for general dialogue, question-answering, or text tasks, lacking a native understanding of issues like “multi-file structured code editing.”

Thus, they began internal attempts to develop their own models. Initially, it was for a specific function with high latency requirements, where the existing model calls were not feasible; after trying to train their own, they found the results exceeded expectations. From then on, self-developed models gradually became a core component of Cursor, supporting key functionalities and becoming an important direction for team recruitment.

A key feature of Cursor is its prediction of “next editing actions.” This is difficult to achieve in writing but highly feasible in coding scenarios due to the strong contextual coherence of programs—after a developer modifies a function or file, the subsequent operations are often predictable.

Cursor’s model is based on this contextual logic, inferring which files, locations, and structures the user is likely to modify next, providing completion suggestions at nearly imperceptible latency. This is not merely token-level completion but structured code snippet-level prediction, entirely relying on self-developed models trained specifically for this scenario, rather than general base models.

In the reality where model invocation costs are extremely high, such self-developed models can significantly lower the product’s usage threshold. To achieve this, the models must possess two characteristics: fast response and low cost.

Cursor requires that every completion inference must be completed within 300 milliseconds and should not generate excessive resource consumption during long-term continuous use. This rigid constraint necessitated that they control the design and deployment of the models themselves.

In addition to core interaction functions, Cursor’s self-developed models also play another important role—as “orchestrators” to assist in calling large models. For example, when the codebase is large, large models find it difficult to know which files, modules, and contexts to focus on.

Cursor’s models first conduct a search and induction, extracting relevant information from the entire codebase before feeding it to the main model. This is akin to building a specialized “information feeding pipeline” for large models like GPT, Claude, and Gemini, enhancing their performance.

At the output end of the model, these sketch-like code modification suggestions are also processed and rewritten by Cursor’s self-developed models, transforming them into truly executable, structured patches.

This system architecture, where multiple models collaborate and perform their respective roles, is what OpenAI refers to as “model integration.” Michael is not fixated on building models from scratch but pragmatically chooses existing open-source models as a starting point, such as LLaMA.

In certain scenarios, they also collaborate with closed-source vendors to fine-tune model parameters to suit specific tasks. He emphasizes that the important thing is not whether the underlying structure of the model is under their control but whether they can obtain actionable training and customization rights to serve the actual needs of the product.

As the technical system continues to improve, another question gradually emerges: where is Cursor’s moat in such a rapidly evolving race? Michael’s answer is very clear. He does not believe that “product binding” and “contract locking” can build true long-term defenses.

Unlike traditional B2B software, the AI tools market undergoes drastic changes in barriers to entry, with low user trial costs and high acceptance of new tools. He candidly states that this is not a market favorable to traditional giants; rather, it encourages new companies to continuously experiment, iterate quickly, and compete for user choice.

From this perspective, the moat that Cursor can rely on is not model control or data monopoly, but the ability to “continuously build the best products.”

This industry resembles the search engine boom of the 1990s or the early PC industry, where every improvement can yield significant returns, and competitive barriers arise from the “deep inertia” formed by continuous iteration, as well as the superiority of team organizational capabilities and product refinement systems.

Michael presents a core viewpoint: when a market still has a large number of unmet needs and many technical structures that can be optimized, continuous R&D itself is the biggest moat. It does not need to rely on binding users but instead relies on its own continuous evolution to gain cumulative advantages in time and quality.

He emphasizes that this “evolutionary moat” does not exclude competition, nor does it mean that there can only be one winner in the market. However, under the proposition of “building a globally universal software construction platform,” it is indeed possible for a single giant company to emerge.

While multiple products may coexist in the future, if the question is “who can carry out the largest-scale code logic translation task globally,” then ultimately only one company may remain. The reason is not that other companies are not doing well, but that users will naturally tend to use the most universal, stable, and contextually understanding platform. In this field, product quality and evolution speed determine market concentration.

He further points out that one cannot judge this round of technological evolution’s pattern based on the fragmentation experience of the traditional IDE market. In the 2010s, the IDE market “no one made big money” because the capabilities of editors at that time were already close to their limits, and the parts that could be optimized were merely basic functions like syntax highlighting, debugger integration, and quick navigation. However, today, developer tools are at a new paradigm starting point, where the goal is no longer to optimize an editor but to reshape the entire workflow and expression structure of knowledge workers.

The essence of AI programming tools is not to replace code but to enhance human instruction expression capabilities and compress the path from idea to implementation. This represents a much larger market than traditional development tools and a future channel with platform attributes. In this channel, whoever can provide the smoothest, most reliable, and most contextually understanding programming experience will have the opportunity to become synonymous with the next generation of “software construction infrastructure.”

When Lenny mentioned Microsoft Copilot, he also brought up a typical current issue: do the companies that entered the market first possess the ability to continue leading? Michael acknowledged that Copilot was an inspiration for the entire industry, especially when its initial version was released, bringing an unprecedented development interaction method.

However, he believes that Microsoft has not truly maintained its initial momentum, which has both historical reasons and structural challenges. The core team that initially developed Copilot experienced frequent personnel changes, making it difficult to form a unified direction within a large organization, and the product path could easily be diluted by internal struggles and process complexities.

More fundamentally, this market is not friendly to incumbents. It does not rely on integration and binding like enterprise-level CRM or ERP systems, nor does it have the extremely strong “switching costs” that create user stickiness. User choices are entirely based on experience differences, which determines that “product power” rather than “sales ability” will be the decisive factor. In such a dynamic, open, and high-frequency trial-and-error market, the companies that can truly win are those that can iterate their products weekly, improve monthly, and continuously push towards technical limits.

The direction and product rhythm that Cursor currently exhibits are precisely responses formed in this context. It does not rely on “closure” but on the simple, clear, yet extremely difficult mission of “continuously building the best development tool in the world,” attracting developers’ active choices.

How to Use Cursor Correctly?

In building an AI IDE platform for global developers, Michael Truell is most concerned not about the limits of model capabilities but about how users understand and effectively utilize these capabilities.

When asked what advice he would give if he could sit beside every first-time user of Cursor, he did not explain features or operational techniques but emphasized establishing a mindset—an instinctive judgment of what the model “can and cannot do.”

He candidly admitted that the current Cursor product does not do enough to guide users in understanding the boundaries of the model. Without clear prompt tracks and interactive feedback mechanisms, many users tend to fall into two extremes: either placing overly high expectations on the model, trying to solve complex problems with a single prompt; or giving up entirely after an unsatisfactory first result.

His suggested approach is task decomposition, gradually advancing through “small prompts—small generations,” engaging in continuous two-way interaction with AI to achieve more stable and higher-quality results.

Another suggestion is more strategic. He encourages users to “go all out” in side projects without business pressure, attempting to push AI capabilities to the limit.

Without affecting mainline work, through a whole set of experimental projects, they can feel how much the model can truly accomplish and where the boundaries of failure lie. This kind of “wrestling-style exploration” can help developers build a more accurate intuition and make them more confident when facing formal projects in the future.

As model versions continue to update, such as the rollout of GPT-4.0 or Claude, this judgment also needs to be updated accordingly. He hopes that future Cursor products can incorporate a guiding mechanism, allowing users to understand the model’s “temperament” and boundaries without having to explore each time. But for now, this remains a skill that users need to accumulate subjectively.

Regarding another frequently asked question—whether such tools are more suitable for junior engineers or senior engineers—Michael provided precise classification descriptions.

He pointed out that junior developers often tend to “completely rely on AI,” trying to use it to complete the entire development process; while senior engineers may underestimate AI due to their rich experience, failing to fully explore its potential. The former’s problem is “too much reliance,” while the latter’s issue is “too little exploration.”

He also emphasized that certain senior technical teams within companies, especially architect-level talents focused on Developer Experience, are actually the most actively embracing this type of tool. They understand system complexity and care about tool efficiency, thus often achieving the best results in AI programming scenarios.

In his view, the ideal user profile is neither beginners nor seasoned veterans with rigid processes but those “experienced yet not rigid” mid-level engineers—who possess system understanding while remaining curious and open to new methods.

How to Build a World-Class Team?

When asked what advice he would give to himself if he could return to the year Cursor was founded, Michael chose a non-technical answer—recruitment. He repeatedly emphasized that “finding the right people” is the second most important task after the product itself.

Especially in the early stages, building a world-class engineering and research team is not only a guarantee of product quality but also a decisive factor in organizational focus, rhythm, and culture. The talent he seeks must possess technical curiosity, a willingness to experiment, and the ability to maintain calm judgment in a restless environment.

He recalled that Cursor had taken many wrong turns in the recruitment process. Initially, they placed too much emphasis on “high-profile resumes,” leaning towards hiring young people from prestigious schools with standard success paths. However, they eventually realized that the truly suitable talents often do not fit these traditional templates. Instead, those with slightly later career stages, highly matching experience, and mature technical judgment turned out to be the key driving forces for the team.

In the recruitment process, they gradually established a set of effective methods. The core is a two-day “work test” system. Candidates need to spend time with the team and complete a task closely resembling a real project within a specified time.

This process may seem cumbersome, but in practice, it is not only scalable but also significantly enhances the accuracy of team judgment. It assesses candidates’ coding abilities, tests collaboration and communication skills, thinking styles, and hands-on abilities, and even helps candidates determine whether they are willing to work with this team long-term.

The “collaborative interview” mechanism gradually evolved into a part of Cursor’s team culture. They view the recruitment process as a two-way selection rather than a one-way evaluation. When the company is not widely recognized in the market and the product is not yet mature, the team itself is the most important attraction.

He admitted that many early employees joined due to one or even multiple collaborative experiences rather than judgments based on salary or valuation. Today, this system is still retained and applied to every new candidate. Cursor’s team size currently remains around 60, which is considered streamlined among many SaaS companies.

Michael pointed out that they intentionally maintained this lean configuration, especially being restrained in the expansion of non-technical positions. He acknowledged that they will definitely expand the team in the future to enhance customer support and operational capabilities, but for now, they still operate as a highly engineering, research, and design-driven company.

When discussing how to maintain focus in the rapidly changing AI industry release rhythm, Michael does not rely on complex organizational systems.

He believes the foundation of organizational culture lies in recruitment itself. If they can hire rational, focused individuals who are not swayed by hot emotional trends, the team will naturally possess a good sense of rhythm. He admits that Cursor still has room for improvement, but overall, they have achieved good results in guiding a culture that “only focuses on producing excellent products.”

Many companies attempt to solve problems through processes and organizational design, which can actually be avoided in advance by “finding the right people.” Their development process is extremely simple, and its establishment is due to the members of the team generally possessing self-discipline and a spirit of collaboration. He particularly emphasizes a common psychological trait: immunity to external noise.

This immunity is not inherently present but gradually formed through long-term industry experience. As early as 2021 and 2022, the Cursor team was already exploring AI programming. At that time, GPT-3 had not yet released the Instruct version, and DALL·E and Stable Diffusion had not yet been made public; the entire generative AI industry was still in its technical infancy.

They experienced the explosion of image generation, the popularization of dialogue models, the release of GPT-4, the evolution of multimodal architectures, and the rise of video generation… but among these seemingly lively technological trends, very few have had a substantial impact on the product.

This ability to distinguish between “structural innovation” and “surface noise” has become an important psychological foundation for maintaining focus. He likens this approach to the evolution of the deep learning research community over the past decade: although countless new papers are published each year, the true advancements in AI come from a few elegant and fundamental structural breakthroughs.

Looking back at the entire technological paradigm shift, Michael believes that the current development of AI is at a profoundly pivotal moment.

The outside world often falls into two extremes: some believe the AI revolution is about to arrive, almost overnight overturning everything; while others see it as hype, a bubble, and not worth mentioning. His judgment is that AI will become a more profound paradigm shift than personal computing, but this process will be a continuous evolution over multiple decades.

This evolution does not rely on any one system or technological route but consists of independent solutions to numerous segmented problems. Some are scientific issues, such as how models can understand more data types, run faster, and learn more efficiently; some are interaction issues, such as how humans can collaborate with AI, how to define boundaries of authority, and how to establish trust mechanisms; and some are application issues, such as how models can truly change real workflows and provide controllable outputs in uncertainty.

In this evolution, he believes a class of key enterprises will emerge—AI tool companies focused on specific knowledge work scenarios. These companies will deeply integrate foundational models, may also independently develop core modules, while constructing the most suitable human-computer collaboration experience. They will not merely be “model callers” but will refine technology and product structures to the extreme, thus growing into a new generation of platform enterprises. Such companies will not only enhance user efficiency but may also become the main driving force behind the evolution of AI technology.

Michael hopes that Cursor can become one of these companies, and he also looks forward to seeing a batch of equally focused, solid, and technically deep AI entrepreneurs emerge in more knowledge work fields such as design, law, and marketing. The future does not belong to speculators but to those who truly deconstruct problems, reshape tools, and understand the relationship between people and technology.

He also pointed out that 2025 will be crucial for Cursor for two reasons: first, to create the best product in the industry, and second, to promote it on a large scale. He describes the current state as a “land grab”: the vast majority of people in the market have not yet been exposed to such tools or are still using slow-updating alternatives. Therefore, they are increasing investments in market, sales, and customer support while continuously seeking excellent talents who can push the product boundaries from a technical level.

When discussing the impact of AI on engineering positions, Michael’s response is quite calm. He does not believe engineers will be quickly replaced; on the contrary, he believes engineers will be more important than ever in an AI-driven future.

In the short term, programming methods will undergo tremendous changes, but it is hard to imagine that software development will suddenly become a process where “just input the requirements, and the system completes everything automatically.” AI can indeed liberate humans from low-level tedious implementations, but core decisions regarding direction, intent, and structural design must still be controlled by professional developers.

This judgment also means that as software construction efficiency increases significantly, the demand side’s elasticity will be thoroughly released. In other words, software itself will become increasingly easier to build, costs will drop significantly, ultimately leading to an expansion of the entire market scale. More problems can be modeled, more processes can be systematized, and more organizations will attempt to customize their internal tools rather than accept generic solutions.

He illustrates this point with a personal experience. In a biotech company he participated in during his early years, the team urgently needed to build a tool system that adapted to internal processes, but the market solutions were not a match, and the efficiency of self-development was very limited, resulting in most of the demands being shelved.

Such scenarios remain common across various industries, indicating that the barriers to software development are still high. If one day making software becomes as simple as moving files or editing slides, what will be released is a whole new era of applications.

Finally, he emphasizes that AI will not reduce the number of engineers but will change the structure of engineering positions. Those who are good at collaborating with AI, who can understand system logic, and who possess product intuition will play a greater role in the new generation of work systems.