Cursor founder: In the post-code era, "taste" will become increasingly valuable
TechFlow Selected TechFlow Selected
Cursor founder: In the post-code era, "taste" will become increasingly valuable
Cursor's goal is to create an entirely new way of programming.
Navigating Web3 tides with focused insightsAuthor: Xin
As one of the fastest-growing products in history, Cursor reached $100 million in ARR just 20 months after launch. Within the following two years, it surpassed $300 million in ARR and continues to lead the transformation in how engineers and product teams build software. As of early 2025, Cursor has over 360,000 paying users.
Michael Truell is co-founder and CEO of Anysphere, Cursor’s parent company. He founded Anysphere with three MIT classmates and launched Cursor within three months. Michael rarely gives podcast interviews—previously appearing only on the Lex Fridman Podcast. In this episode, he shares his predictions about the "post-code era," counterintuitive lessons from building Cursor, and his views on the future evolution of engineering.
This content comes from Lenny's Podcast. Below is the full translated transcript.
- Cursor’s goal is to create a completely new way of programming: In the future, people will work with pseudocode that resembles English sentences more closely. Humans will retain strong control over every detail of software and be able to modify and iterate at incredible speed.
- “Taste” will become increasingly valuable: At its core, “taste” means having clear insight into what should be built.
- The most successful AI users are technically conservative: They excel at narrowing the scope of tasks given to AI, making them smaller and more precise.
- A two-day evaluation is central to Cursor’s hiring process: These projects are simulated but enable candidates to produce real work outcomes over two days. This serves not only as a test of whether we’d want to work together but is also critical for attracting talent. For early-stage companies, the main draw is often simply a team worth building alongside.
The main problem with chatbot-style programming is lack of precision
Lenny: We previously discussed what might happen in the post-code era. How do you envision Cursor’s future direction? How will technology evolve beyond traditional code?
Michael Truell:Cursor aims to create a completely new way of programming—a fundamentally different approach to building software. You simply describe your intent to the computer in the most straightforward way possible, defining exactly how the software should behave and appear.
With today’s advancing technologies, we believe we can pioneer a new method of building software—one that is higher-level, more efficient, and easier to use than current approaches. This process will differ significantly from how software is written today.
I’d like to contrast this vision with several popular perspectives on the future of software—some of which we don’t fully agree with.
One view holds that software development will remain largely unchanged—still relying on formal programming languages like TypeScript, Go, C, or Rust through text editing. Another believes you’ll simply type instructions into a chatbot to build and modify software, treating it like conversing with your engineering team.
We believe both visions have flaws.
The primary issue with chatbot-style programming is lack of precision. If you want people to have complete control over a software’s appearance and functionality, you need more exact ways to specify desired changes—not just saying “change this part of my app” in a chat box and risk having it all deleted.
On the other hand, the belief that nothing will change is also flawed because technology will continue to grow stronger. In our envisioned “post-code” world, the expression of software logic will resemble English more closely.
You can imagine it existing in a more structured form, moving toward pseudocode. You’ll write software logic, edit it at a high level, and navigate it easily. It won’t be millions of lines of obscure, incomprehensible code. Instead, it will be clearer, easier to understand and locate. We’re working to evolve complex symbols and code structures into forms that are easier for humans to read and edit.
In the post-code era, taste will become more valuable
Lenny: That’s profound—I want to make sure everyone grasps your point. The shift you’re imagining is one where people no longer see code or think in terms of JavaScript or Python. Instead, they’ll use a more abstract representation—pseudocode resembling English sentences.
Michael Truell: We believe it will eventually reach that stage. And we believe achieving this requires active involvement and leadership from expert engineers. People will remain firmly in the driver’s seat.
Humans will maintain strong control over every software detail and won’t readily give that up. At the same time, they’ll be able to make modifications and iterations extremely quickly. The future won’t rely on slow backend processes that take weeks to complete.
Lenny: That raises a question: For current engineers—or those considering becoming engineers, designers, or product managers—what skills will become increasingly valuable in this “post-code era”?
Michael Truell: I believe “taste” will become more valuable. When people talk about taste in software, they often think of visual aspects—smooth animations, color schemes, UI, UX, etc.
Visuals are important for products. But as mentioned earlier, I believe the other crucial half lies in product logic and behavior.
We have many tools for designing visuals, but code remains the best medium for expressing how software actually works. You can mock something up in Figma or sketch ideas in notes. But only when you have a functional prototype does the logic truly become clear.
Future engineers will increasingly resemble “logic designers.” They’ll need to precisely express intent, shifting focus from low-level “how to implement” to high-level “what to achieve” and “what it is.” This makes taste increasingly important in software development.
We haven’t fully arrived at that point yet in software engineering. There are many humorous, thought-provoking memes online reflecting issues with over-reliance on AI—software with obvious defects and broken features.
But I believe future software engineers won’t need to obsess over fine-grained details as much as today. We’ll gradually shift from meticulous precision toward greater emphasis on taste.
Lenny: That reminds me of vibe coding. Is that similar to what you’re describing—a way of programming that flows naturally without excessive focus on details?
Michael Truell: I think there’s some connection. What people currently call vibe coding, in my view, describes a controversial creative mode: generating large amounts of code without truly understanding its details. This leads to many problems. Without understanding the underlying mechanics, you quickly end up with systems too large and difficult to modify.
What we’re actually interested in is: How can people maintain perfect control over all details without fully understanding the underlying code? This solution is deeply connected to vibe coding.
We currently lack the ability to let taste fully dominate software construction. One issue with vibe coding or similar modes is that while you can create something, many decisions are awkwardly made by AI, leaving you unable to fully control the outcome.
Lenny: You mentioned “taste.” What specifically do you mean by that?
Michael Truell: Having a clear idea of what should be built. And being able to translate that idea into reality more effortlessly—the software you want to create, how it looks, how it functions.
Unlike today, where you and your team have a product idea but require a translation layer—an exhausting effort—to convert it into a format computers can understand and execute.
Taste isn’t primarily about UI. Maybe “taste” isn’t the perfect word, but its essence is having correct judgment about what should be built.
Cursor was born from exploring a single question
Lenny: Let’s go back to Cursor’s origins—many listeners may not know how it began. You’re building one of the fastest-growing products in history. Cursor is profoundly changing how people build products and even reshaping entire industries. How did it all start? Any memorable moments from the early days?
Michael Truell: Cursor emerged from our exploration of a single question—and largely from thinking about how AI will improve over the next decade. Two key moments stand out.
The first was using Copilot’s beta version. It was our first encounter with a practical AI tool that genuinely helped rather than just showing flashy demos. Copilot became one of the most valuable development tools we’ve ever used—and it excited us greatly.
The second was when companies like OpenAI released a series of papers on model scaling. These showed that even without revolutionary breakthroughs, simply increasing model size and training data would steadily enhance AI capabilities. From late 2021 to early 2022, we grew highly confident in AI’s potential—knowing this technology was destined to mature.
When we looked around, we saw that while many talked about building models, few deeply explored specific knowledge work domains to consider how they’d evolve with advancing AI.
This led us to ask: As the technology matures, how will these specific fields change? What will the final state of work look like? How will our tools evolve? What level must models reach to support such transformations? And once scaling and pre-training plateau, how can we keep pushing technical boundaries?
Cursor’s initial mistake was choosing a field that was under-competitive but dull. No one cared about such boring areas.
Back then, everyone thought programming was hot and exciting—but we felt it was already crowded.
For the first four months, we worked on a completely different project—automating and enhancing mechanical engineering by building tools for mechanical engineers.
But problems arose immediately. My co-founders and I weren’t mechanical engineers. Though we had friends in the field, we were essentially blind—we didn’t know how to apply existing models to mechanical engineering. Our conclusion: We’d need to build our own models from scratch. This was extremely difficult, as there was almost no public 3D model data or assembly steps online, and accessing proprietary resources was equally hard.
Eventually, we realized we weren’t passionate about mechanical engineering—it wasn’t something we wanted to dedicate our lives to.
Looking back at programming, despite significant time passing, little had changed. Those working in the space seemed disconnected from our vision—lacking ambition and foresight about how AI would reshape everything. This realization pushed us toward building Cursor.
Lenny: I love advice like chasing boring industries—less competition, more opportunity. Sometimes it works. But I also love the opposite approach: boldly pursuing the hottest, most competitive spaces like AI programming and app development—and proving it works too.
You felt existing tools lacked ambition or potential, and there was still much to do. I think that’s a powerful insight. Even if a space seems too late—products like GitHub Copilot already exist—if you find existing solutions aren’t ambitious enough, don’t meet your standards, or have methodological flaws, huge opportunities remain. Is that right?
Michael Truell: Absolutely. To achieve breakthrough progress, you need concrete things to work on. The magic of AI lies precisely in the fact that even within AI programming, vast unknown spaces remain.
The ceilings in many fields are incredibly high. Looking ahead, even the best tools in any domain still have enormous work left in the coming years. Such vast space and high ceilings are rare in software—though certainly true for AI.
Cursor emphasized dogfooding from day one
Lenny: Let’s return to IDEs (Integrated Development Environments). You’ve chosen one path among several—others are trying different routes.
One approach builds an engineer-focused IDE and integrates AI capabilities. Another is the full AI Agent model, like Devin. A third focuses solely on building the best coding model.
What made you decide an IDE was the optimal path?
Michael Truell: Those who focused exclusively on models from day one—or tried to automate programming end-to-end—are building something fundamentally different from us.
We prioritize ensuring people retain control over every decision made within the tools they build. In contrast, they envision a future where AI handles the entire process—even making all decisions.
So our choice involves personal interest. But we’ve also always maintained a realistic view of current technological limits. We’re excited about AI’s long-term potential, but sometimes people see AI excel in one area and anthropomorphize it—assuming it must be smarter than humans here, so it will be superior elsewhere too.
But these models have major limitations. Our product development has emphasized “dogfooding” from the start—we use Cursor daily and never release features that aren’t useful to us.
Being end-users ourselves gives us a grounded understanding of current tech capabilities. We believe it’s essential that humans stay in the driver’s seat—AI can’t do everything.
Personally, we also want to empower users with control. This keeps us from being just a model company and avoids the end-to-end product approach that strips people of control.
As for why we chose to build an IDE rather than a plugin for existing environments—it’s because we believe programming will be done through these models, and the way we code will change dramatically in the coming years. Existing environments are too limited in extensibility. If you believe UI and programming paradigms will undergo radical shifts, you must have full control over the entire application.
Lenny: I know you’re focused on IDEs now—perhaps that’s your bias, your vision for the future. But I’m curious: Do you think a large portion of future work will be handled by AI engineers inside tools like Slack? Would such integration ever come to Cursor?
Michael Truell: Ideally, you could seamlessly switch between these modes. Sometimes you might want AI to run independently for a while; other times, pull its output and collaborate efficiently. Then perhaps let it run autonomously again.
I believe you need a unified environment where both background and foreground operations work well. Background execution suits tasks requiring minimal specification and clear success criteria—bug fixing is a great example. But this is absolutely not all of programming.
The essence of IDEs will transform over time. We chose to build our own editor precisely because it will keep evolving. This includes taking over tasks from different interfaces like Slack or issue trackers. Even the glass screen you stare at daily will change dramatically. Right now, we see the IDE as where software gets built.
The most successful AI users are technically conservative
Lenny: I think people discussing Agents and AI engineers often overlook one thing: we’ll largely become “engineering managers” overseeing many not-yet-smart subordinates, spending significant time reviewing, approving, and clarifying requirements. What are your thoughts? Any ways to simplify this?
Because honestly, it sounds exhausting—anyone who’s managed a large team knows: “These subordinates keep bringing me inconsistent-quality work repeatedly—it’s torture.”
Michael Truell: Yeah, maybe eventually we’ll have to do one-on-one meetings with all these Agents.
We’ve observed that the most successful AI users tend to be technically conservative. I do believe the most effective users heavily rely on features like our “Next Edit Prediction.” In their regular workflow, our AI intelligently predicts the next action. They’re also exceptionally skilled at narrowing the scope of tasks assigned to AI—making them smaller and more specific.
Considering the time cost of reviewing code, there are two main collaboration patterns with Agents. One is spending significant upfront time specifying details, letting AI work independently, then reviewing the result. Once reviewed, the task is complete.
The other is breaking tasks into finer pieces—specifying a small part, letting AI complete it, then reviewing; then giving further instructions, repeating the cycle. This is like extending autocomplete throughout the entire process.
Yet we often observe that top users still prefer splitting tasks and keeping them manageable.
Lenny: That’s insightful. Let’s go back to when you first built Cursor. When did you realize it was ready? When did you feel it was time to release and see what happens?
Michael Truell: When we started building Cursor, we worried about spending too long in development before releasing. The initial version was entirely hand-built from scratch. Today we use VS Code as a foundation—similar to how many browsers use Chromium.
But it wasn’t always that way. We initially built Cursor’s prototype from zero, which involved tremendous work. We had to develop many modern code editor features ourselves—multi-language support, code navigation, error tracking, built-in command line, remote server connectivity for viewing and running code.
We moved at lightning speed—building our own editor from scratch while simultaneously developing the AI components. Around five weeks in, we began using our own editor full-time, completely abandoning previous tools and adopting the new one.
Once we felt it reached a certain level of usability, we gave it to others for testing—a very brief beta phase.
From writing the first line of code to public launch, Cursor took approximately three months. Our goal was to get the product into users’ hands as quickly as possible and rapidly iterate based on public feedback.
To our surprise, we expected only hundreds of users to care about this tool for a long time—but from day one, large numbers poured in with abundant feedback. Early user input was invaluable—prompting us to abandon our from-scratch version and instead build on top of VS Code. Since then, we’ve continuously refined the product in the public eye.
Product launched in three months, hit $100M ARR in one year
Lenny: I admire your humility about your achievements. To my knowledge, you grew ARR from zero to $100 million in roughly one to one-and-a-half years—an absolutely historic accomplishment.
What were the key factors behind this success? You mentioned dogfooding as one. But launching a product in three months is astonishing. What’s the secret behind that?
Michael Truell: The first version—completed in three months—wasn’t perfect. So we’ve always had a persistent sense of urgency, feeling there’s still much room for improvement.
Our ultimate goal is to create a truly new programming paradigm—one that automates much of the coding work we know today. No matter Cursor’s current progress, we feel far from that ultimate goal—there’s always more to do.
Often, we didn’t obsess over the initial launch impact but focused instead on continuous evolution—dedicated to improving and refining the tool.
Lenny: After those three months, was there a turning point when growth really took off?
Michael Truell: Honestly, early growth felt quite slow—perhaps due to our own impatience. But overall, the pace continually surprised us.
What surprised us most was that growth maintained a steady exponential trend—growing month after month, though new releases or other factors occasionally accelerated it.
Of course, exponential growth feels slow at first—starting from a tiny base—so it didn’t initially appear explosive.
Lenny: This sounds like the classic “build it and they will come” story. You created a tool you loved, released it, people loved it too, and it spread organically.
Michael Truell: Yes, pretty much. Our team focused nearly all energy on the product itself—without distraction. Of course, we spent time on other important things—like team-building and rotating user support duties.
But on typical early-stage startup tasks, we “just left the problems there”—especially in sales and marketing.
We concentrated on polishing the product—first creating something our team loved, then iterating based on core user feedback. It sounds simple, but doing it well is actually hard.
There are many directions to explore, many product paths. One challenge is staying focused—strategically selecting and prioritizing key features.
Another challenge is that our domain represents a fundamentally new product development model: We sit between a traditional software company and a foundational model company.
We’re building for millions of users, demanding excellence at the product level. But another critical dimension of quality is deepening scientific research and model development—continuously optimizing models for key scenarios. Balancing these two remains challenging.
The most counterintuitive thing: We didn’t expect to build our own models
Lenny: So far, what’s been the most counterintuitive lesson in building Cursor and AI products?
Michael Truell: For me, the most counterintuitive aspect was that we never expected to build our own models at the start. When we entered the space, some companies were already focused on model training. We calculated the cost and resources needed to train something like GPT-4 and knew it was beyond our reach.
There were already many excellent models available. Why reinvent the wheel—especially in pre-training, where you teach a blank neural network the entire internet? So initially, we had no intention of going down this path. We clearly saw that existing models could do much more if paired with better tools. Yet we ended up investing heavily in model development.
Every “magical moment” you experience using Cursor stems partly from our custom models. This evolved gradually. We first trained our own model for a specific use case where mainstream base models performed poorly—and succeeded. We then applied this approach to another use case—with similar success—and kept expanding.
A key principle in this model development is choosing targets wisely—avoiding reinventing wheels. We avoid areas where top base models already excel, focusing instead on their weaknesses and finding ways to address them.
Lenny: Many are surprised to hear you have your own models. When people discuss Cursor and similar products, they often label them “GPT wrappers”—tools built atop models like ChatGPT or Sonnet. But you say you have your own models. Can you share the technical stack behind this?
Michael Truell: We do use leading base models across various scenarios.
However, for key parts of the Cursor experience, we rely more on in-house models—especially where base models fail due to cost or speed. One example is autocomplete.
For non-coders, this might be hard to grasp. Coding is a unique activity. Sometimes, your next 5, 10, 20, or even 30 minutes of work can be predicted just by observing your current actions.
Compared to writing—where many are familiar with Gmail’s autocomplete or text suggestions in messaging and email—these features are limited. Past text alone often can’t predict what comes next.
But in coding, modifying one part of a codebase often requires synchronized changes elsewhere—and those changes are usually obvious.
One of Cursor’s core features is enhanced autocomplete—predicting a sequence of actions across multiple files and positions within files.
For a model to excel here, it must be fast—delivering completions within 300 milliseconds. Cost matters too—we trigger thousands of inferences per keystroke, constantly updating predictions of your next move.
There’s also a unique technical challenge: The model must not only complete the next token like standard text sequences but excel at completing a series of diffs (code changes)—predicting additions and deletions based on prior modifications in the codebase.
We specially trained a model for this task—very effectively. This component is entirely homegrown—never calling any base model. We haven’t branded or labeled this technology, but it’s core to Cursor.
Another use of our in-house models is enhancing large models like Sonnet, Gemini, or GPT—particularly in input and output processing.
On the input side, our model searches the entire codebase to identify relevant sections to show the larger models. Think of it as a “mini Google search” specialized for code.
On the output side, we process modification suggestions from large models, using specially trained models to refine details. High-level logic design is handled by advanced models—they spend tokens to define overall direction. Smaller, specialized, ultra-fast models—combined with reasoning optimizations—then translate these high-level suggestions into complete, executable code changes.
This significantly improves quality for specialized tasks and greatly accelerates response speed. Speed is a critical metric for us.
Lenny: That’s fascinating. I recently interviewed OpenAI’s CPO Kevin Weil on my podcast—he called this an “ensemble of models.”
They similarly leverage each model’s strengths. Using cheaper models offers major cost advantages. Are your in-house models built upon open-source models like LLaMA?
Michael Truell: We’re very pragmatic—no desire to reinvent wheels. So we typically start with the best available pre-trained models—often open-source, sometimes collaborating with large models whose weights aren’t publicly accessible. We don’t particularly care about directly reading or inspecting weight matrices that determine outputs—what matters more is our ability to train and post-train the models.
The ceiling for AI products is like PCs and search engines in the last century
Lenny: Many AI entrepreneurs and investors wonder: Where are AI’s moats and defensibility? Custom models seem like one way to build a moat. In a competitive landscape where rivals constantly innovate and threaten to displace you, how do you establish long-term defense?
Michael Truell: There are indeed traditional ways to create user inertia and moats. But ultimately, we must keep striving to build the best product. I firmly believe AI’s ceiling is extremely high—no matter what barriers you build, they can always be surpassed.
This market differs from traditional software or enterprise markets. A similar historical example is search engines from the late 1990s to early 2000s. Another is personal computers and minicomputers from the 70s–90s.
AI product ceilings are very high, enabling rapid iteration. You can continuously extract massive value from each hour of a smart person’s time and every dollar invested in R&D. This can last a long time. You’ll never run out of new features to build.
Especially in search, expanded distribution also improves the product—because you can continuously refine algorithms and models using user data and feedback. I believe similar dynamics exist in our industry.
For us, this might be a slightly frustrating reality. But for the world, it’s an exciting truth. Many leading products will emerge, and countless meaningful features await creation.
We’re still far from the vision of five to ten years ahead. Our job is to keep the innovation engine running at full speed.
Lenny: This sounds more like building a “consumer-style” moat—consistently delivering the best product so users keep using it—rather than tying employees to Salesforce-like contracts where they’re forced to use it.
Michael Truell: Yes. I think the concern is valid if your field quickly runs out of valuable things to build. But if sustained investment and talent effort keep producing value, you gain R&D scale effects—deepening technology in the right direction and building defenses.
It does lean consumer-oriented. But at its core, it’s about building the best product.
Lenny: Do you foresee a “winner-takes-all” market, or will many differentiated products emerge?
Michael Truell: I believe the market is enormous. You mentioned IDEs earlier. Some analyzing this space look back at the past decade’s IDE market and ask: “Who actually made money building editors?” Everyone had their preferred setup. Only one company successfully commercialized an editor—but its scale was limited.
Some conclude the future will follow this pattern. But I think this overlooks something: In the 2010s, the potential for building programmer editors was inherently limited.
That profitable editor company mainly focused on simplifying code navigation, error checking, and good debugging tools. While valuable, I believe the opportunity to build tools for programmers—and broader knowledge workers—is immense.
The real challenge is automating vast amounts of tedious, routine, and cognitive work. Only then can we achieve reliable, efficient productivity gains across knowledge work domains.
I believe our market size vastly exceeds past perceptions of developer tools. Various solutions will emerge—possibly including a dominant leader. It might be us—but that remains to be seen. Such a company would create a universal tool assisting in building most of the world’s software—becoming an era-defining giant. But there will also be products focused on niche markets or specific stages of the software development lifecycle.
Ultimately, programming itself may shift from traditional formal languages to higher-level abstractions—and these advanced tools will become the primary objects users buy and use. I believe AI programming will have a dominant player that grows into an extremely large company.
Lenny: Interestingly, Microsoft was once at the center of this transformation—possessing great products and strong distribution. You said Copilot made you realize the space’s potential—but it hasn’t fully won the market. In fact, it seems somewhat behind. Why do you think that is?
Michael Truell: I believe Copilot fell short of expectations due to specific historical and structural reasons.
Structurally, Microsoft’s Copilot project provided us with major inspiration. They achieved many impressive things—we’re also users of many Microsoft products.
But I believe this market isn’t particularly friendly to established enterprises. Markets favorable to big companies are often those with limited innovation space—quick to monetize through bundled sales.
In such markets, ROI differences between products aren’t large. Buying standalone innovative solutions offers little advantage—bundled products are more appealing.
Another market favorable to incumbents is one where: Users are highly dependent on your tools from day one, with very high switching costs.
But in our space, users can easily try different tools and choose what fits best. This disadvantages large companies and favors those with the most innovative products.
As for historical reasons, from what I understand, most of the team behind Copilot’s first version later moved on to other projects elsewhere. Coordinating across departments and stakeholders to build a unified product proved difficult.
Senior engineers expect too little, junior engineers expect too much
Lenny: If you could sit beside every new Cursor user during their first experience and whisper a few tips to help them use Cursor better, what would you say?
Michael Truell: I think we currently face a product-level challenge.
Many users who succeed with Cursor already possess a certain “taste” for model capabilities. They understand what tasks Cursor can handle and what level of instruction it needs. They grasp the model’s quality, limitations, and what it can and cannot do.
In our current product, we haven’t done well in user education—even lacking clear usage guidelines.
To develop this “taste,” I have two suggestions.
First, don’t assign the entire task to the model at once. You’ll either be disappointed or accept the output wholesale. Instead, break the task into chunks. You can spend the same total time reaching the final result—but do it step by step. Specify a small task, get partial results, repeat—instead of writing a long, detailed instruction. The latter often leads to disaster.
Second, try it first on side projects—don’t use it for critical work immediately. I encourage developers accustomed to existing workflows to embrace failure and actively push the model’s limits.
Use AI as much as possible in a relatively safe environment—like a side project. Often, we find people haven’t given AI a fair chance and underestimated its capabilities.
By decomposing tasks and actively exploring model boundaries in a safe setting, you might be surprised to discover AI doesn’t fail as often as expected in certain scenarios.
Lenny: My understanding is that you need to develop intuition—understanding the model’s capability boundaries, how far it can advance an idea—not just blindly follow your instructions. And whenever a new model launches—like when GPT-4 came out—you need to rebuild this intuition?
Michael Truell: Exactly. Over recent years, this feeling may not be as intense as during first encounters with large models. But this is precisely a pain point we hope to better solve for users—reducing their burden. Still, every model has slightly different quirks and personalities.
Lenny: There’s ongoing debate: Do tools like Cursor help junior engineers more, or senior engineers? Do they boost senior engineers’ productivity tenfold—or make juniors perform like seniors? Which group benefits most today?
Michael Truell: I believe both groups benefit enormously—it’s hard to say which gains more.
They fall into different “anti-patterns.” Junior engineers sometimes overly rely on AI—letting it do everything. But we currently lack the conditions for professional-grade, end-to-end AI use—collaborating with dozens or hundreds in long-maintained codebases.
As for senior engineers—not all, but adoption in companies is often blocked by extremely senior individuals, like developer experience teams. They typically oversee tooling to boost productivity for other engineers in the organization.
We’ve also seen cutting-edge cases—some senior engineers lead the charge, embracing and leveraging the technology as much as possible. On average, senior engineers tend to underestimate AI’s usefulness and stick to existing workflows.
It’s hard to judge which group benefits more. I believe both encounter distinct anti-patterns—but both gain significant advantages from using such tools.
Lenny: That makes perfect sense—like opposite ends of a spectrum, one with too much expectation, one with too little. Like the Goldilocks tale.
Cursor’s hiring core is a two-day evaluation
Lenny: Before founding Cursor, what did you wish you knew? If you could go back to Cursor’s beginning and give young Michael some advice, what would it be?
Michael Truell: The difficulty is that many valuable lessons are implicit—hard to articulate. Unfortunately, in certain human domains, you must personally fail to learn—or learn from top performers.
We experienced this deeply in hiring. In fact, we’ve been extremely patient in recruitment. For both personal vision and company strategy, having a world-class team of engineers and researchers to refine Cursor is critical.
Because we need to build so many new things, we seek individuals with curiosity and experimental spirit. We also look for realism, moderate caution, and candid communication. As the company and business scale expands, noise increases—maintaining clarity of mind becomes especially important.
Beyond product, finding the right people may be our top priority—which is why we kept the team small for a long time. Many say hiring too fast causes problems—but I believe we hired too slowly at first. We could’ve done better.
The hiring method we eventually adopted works very well—focusing on identifying world-class talent, sometimes spending years recruiting them.
We’ve accumulated valuable experience in areas like judging ideal candidates, cultural fit, standards of excellence, and engaging passive candidates. Learning to do these well took considerable time.
The four founders of Anysphere: Aman Sanger, Arvid Lunnemark, Sualeh Asif, and Michael Truell
Lenny: For companies currently hiring, what lessons can you share? What did you miss, what did you learn?
Michael Truell: Initially, we leaned too heavily toward candidates with elite academic profiles—especially young people with outstanding records in prestigious academic settings.
We were lucky to find exceptional individuals early—already seasoned professionals willing to join us.
At first, we overemphasized interest and experience. While we hired many talented young people, they weren’t the same as a veteran lineup stepping straight onto the main stage.
We’ve upgraded our interview process. We have customized interview questions. The core is inviting candidates to spend two days at the company, completing a two-day evaluation project. This has proven highly effective—and we keep refining it.
We also continuously learn about candidate interests, offer attractive terms, and initiate conversations with those not actively job-seeking—introducing opportunities early.
Lenny: Do you have a favorite interview question?
Michael Truell: I originally thought this two-day work evaluation wouldn’t suit many people—but it’s shown surprising longevity. It lets candidates participate fully—like completing a real project.
The projects are fixed but allow seeing real work output in two days. It doesn’t consume large team blocks—you can spread what was once a half-day or full-day onsite interview across two days, giving candidates ample time. This scales more easily.
The two-day project is also a “would I want to work with this person” test. After all, you spend two days together—including meals.
We didn’t expect this evaluation to persist—but it’s now a valuable part of our hiring. It’s also crucial for attracting candidates—especially early on, when the product wasn’t widely used or mature. Often, the only compelling reason to join was a team that felt special and worth building with.
Two days let candidates get to know us—and potentially convince themselves they want to join. The impact exceeded expectations. It’s less a specific interview question and more a forward-looking interview model.
Lenny: Is this ultimate interview question giving them a task—like building a feature in our codebase, collaborating on coding and shipping it—something like that?
Michael Truell: Pretty much—though we don’t use IP or directly merge project results into our product line. It’s a simulated project. Typically, we assign a real two-day mini-task within our codebase. They complete end-to-end work independently—with collaboration elements.
We’re a company that values in-person collaboration—so in nearly all cases, they sit in the office and work with us.
Lenny: You mentioned this interview method has endured—how large is your team now?
Michael Truell: About 60 people.
Lenny: Given your impact, that’s surprisingly small—I expected much larger. I assume engineers are the largest group.
Michael Truell: One of our top priorities ahead is building a larger, stronger team—to continuously improve the product and enhance customer service. So we don’t plan to stay this small long-term.
Part of the reason our team is small is the exceptionally high ratio of engineers, researchers, and designers internally. Many software companies with ~40 engineers often exceed 100 total employees—due to extensive operations and heavy reliance on sales from day one, requiring significant headcount.
We adopted an extremely lean, product-centric model from the start. Today, we serve many market customers and continue expanding. But we still have much work ahead.
Lenny: The AI field is undergoing massive changes—daily news, newsletters telling you what happened in AI today. Running a hot, central company, how do you stay focused? How do you help your team work deeply on the product without getting distracted by constant novelty?
Michael Truell: I believe hiring is key. It comes down to whether you hire the right people. I think we’ve done well here—maybe can improve further.
It’s also a topic we discuss internally—hiring people with the right temperament. They shouldn’t overly chase external validation but focus on building excellent products, delivering high-quality work, and remaining generally calm and emotionally stable.
Hiring helps us overcome many challenges—it’s a shared belief across the company. Organizations need processes, hierarchies, and systems. But for any organizational tool introduced, much of its intended effect can be achieved simply by hiring people with the right traits.
For example, we function well in engineering with few processes. I think we need to add some. But because we’re small, hiring truly exceptional people reduces the need for excessive processes.
First: Hire calm, composed people. Second: Communicate thoroughly. Third: Lead by example.
From 2021 to 2022, we focused intensely on AI work. We witnessed major shifts in technologies and ideas. If you could go back to late 2021 or early 2022—when GPT-3 existed but InstructGPT didn’t, and DALL-E and Stable Diffusion hadn’t emerged.
All these image technologies, InstructGPT, GPT-4, new models, modalities, video tech—only a few meaningfully impacted our business. We’ve developed immunity—knowing which advances truly matter to us.
Despite widespread discussion, only a few things truly matter. Over the past decade, AI reflected this—academia published countless deep learning and AI papers. But remarkably, many AI advances stemmed from very simple, elegant, enduring ideas. Most proposed ideas neither stood the test of time nor made significant impact. The current dynamic resembles the evolution of deep learning as a field.
Demand for engineers will only grow
Lenny: What misconceptions or underappreciated aspects remain about AI’s trajectory and how it will change the world?
Michael Truell: Views remain overly extreme—either believing everything will happen very fast or dismissing it all as hype and exaggeration.
We’re in the midst of a profoundly transformative technological shift—one more significant than the internet and exceeding any prior technological revolution since the birth of computers. But it will take time—a multi-decade journey where many teams will play vital roles.
To achieve a future where computers shoulder more and more of our work, we must solve numerous independent technical challenges—continuously overcoming them.
Some are scientific—enabling models to understand diverse data types, becoming faster, cheaper, smarter, better aligned with our modalities, and acting effectively in the real world.
Others involve human-computer collaboration—figuring out what people should see, control, and interact with on their computers when using these technologies. I believe this will take decades, with vast exciting work ahead.
I believe a certain type of team will be especially important. Not to boast, but companies focused on automating specific knowledge work domains—building underlying tech, integrating best third-party tools, sometimes developing in-house to deliver optimal product experiences.
Such teams matter not just for user value—but as they scale, they’ll drive technological progress. The most successful will build large enterprises. I look forward to seeing more such companies emerge in other domains.
Lenny: I know you’re hiring people excited by “I want to work here and build these kinds of products.” Who are you looking for now? Specific roles or positions? Which hires are most urgent? What should interested people know?
Michael Truell: We have far more to do than we’re currently doing. If it seems we’re not actively hiring for a particular role, reach out anyway. You might bring new perspectives—revealing gaps we hadn’t noticed.
I believe our two most important goals this year are building the best product in this space and driving growth. We’re in a market-share capture phase—globally, almost everyone either isn’t using our kind of tool or uses slower-moving competitors’ products. Growing Cursor is a key objective.
We’re continuously hiring excellent engineers, designers, and researchers—and also seeking other talents.
Lenny: There’s a narrative that AI will replace engineers and do all coding. But reality contrasts sharply—companies are frantically hiring engineers, including foundational model builders. Do you foresee a turning point where demand for engineers slows?
I know it’s a big question—but do you believe demand for engineers will keep growing across companies? Or do you think at some point, vast numbers of Cursors will run and handle development?
Michael Truell: We’ve always believed this is a long, complex process—no sudden leap to a state where issuing instructions fully replaces engineering teams.
We strongly want to guide programming’s evolution smoothly—with humans always in control. Even in the final state, retaining human oversight over everything remains crucial—professionals must decide software’s proper form. So I believe engineers are indispensable—they’ll be able to accomplish more.
Demand for software is enduring. Nothing new—but imagine building seemingly simple, well-defined things that turn out incredibly costly and labor-intensive. To outsiders, these should be easy—but in practice, they’re hard. If you can reduce development cost and labor by another order of magnitude, entirely new possibilities open on computers—enabling countless new tools.
I know this firsthand. I once worked at a biotech company building internal tools. Available tools were terrible—unable to meet company needs. The demand for internal tools I could build vastly exceeded my individual capacity.
Computers are already physically powerful enough to let us freely move and build anything we want—but reality imposes many barriers. Demand for software far exceeds current development capacity—because building a simple productivity tool can cost as much as producing a blockbuster movie. Therefore, far into the future, demand for engineers will only grow.
Lenny: Anything else we haven’t covered you’d like to add? Any wisdom to leave listeners with?
Michael Truell: We constantly think about how to build a team capable of creating new things while continuously improving the product. To succeed, IDEs must change significantly. Their future form must be very different.
If you study companies we admire, you’ll see rare examples that led multiple technological leaps and continuously pushed industry frontiers.
We need to reflect on such questions daily—from first principles. Studying past successes is also crucial—something we often ponder.
Lenny: I notice many books behind you—one about a legacy computer company historically influential in many ways, though I’d never heard of it. That resonates—because much innovative thinking stems from studying history, learning from past successes and failures.
If someone wants to contact you or apply, where can they find information online? You mentioned potential roles they might not realize exist—where should they look? How can listeners help?
Michael Truell: Anyone interested can find our product and contact info at cursor.com.
Lenny: Great. Michael, thank you so much for joining us today.
Join TechFlow official community to stay tuned
Telegram:https://t.me/TechFlowDaily
X (Twitter):https://x.com/TechFlowPost
X (Twitter) EN:https://x.com/BlockFlow_News
