Cursor Team: Future of Programming with AI

High-Level Overview

Lex Fridman sits down with the four founding members of Cursor, Michael Truell, Sualeh Asif, Arvid Lunnemark, and Aman Sanger, the team behind the AI-first code editor built as a fork of VS Code. Fridman calls it a super technical conversation that is bigger than one editor: it is about the future of programming and of humans and AI building complicated systems together. The team explains why they left the plugin model behind, how features like Cursor Tab, apply, and diffs work under the hood, and the machine-learning and systems tricks (mixture-of-experts models, speculative edits, KV caching, attention variants, Merkle trees) that make the editor feel fast.

From there the discussion widens into agents, background computation, AI bug finding, formal verification, privacy and centralization, synthetic data, RLHF, OpenAI's o1 and test-time compute, scaling laws, and whether AI will win a Fields Medal. The tone is energetic, nerdy, and playful, with four friends finishing each other's thoughts and a shared conviction that programming is about to get a lot more fun. The conversation moves from product design to deep ML and infrastructure details, and ends with a hopeful vision of human programmers staying firmly in the driver's seat.

The Discussion Explores:

• What a code editor is for, why it should be fun and fast, and why the team forked VS Code instead of building a plugin
• Cursor Tab: predicting not just the next characters but the next edit and the next place you will jump
• Custom models, apply, speculative edits, and the caching and attention tricks behind the speed
• Which frontier models are best for coding, why benchmarks mislead, and how Cursor structures prompts
• Agents, the shadow workspace, bug finding, dangerous code, and formal verification
• Scaling the infrastructure, codebase indexing, local models, and the privacy risks of centralized AI
• o1 and test-time compute, synthetic data, RLHF versus RLAIF, and scaling laws
• How programming will change, and why the team believes humans should stay in control

Deep Dive into Main Ideas

What a Code Editor Is, and Why Cursor Exists

The team describes a code editor as a souped-up word processor for programmers that understands code's structure: it colors tokens, lets you navigate a codebase like hyperlinks, and catches basic errors. They expect that to change a lot over the next decade. "I think also a code editor should just be fun," one of them says, and they explain that they often throw out experiments that work but aren't fun, and that much of fun comes from speed. Coding, they note, offers an unusual gift: one person and a computer can build really cool things very quickly.

All four started as Vim users and switched to VS Code in 2021 for GitHub Copilot, which they describe as the first real consumer product built on language models. Copilot felt like a friend finishing your sentences, and even when it was wrong you just typed another character. The origin of Cursor came from OpenAI's 2020 scaling-laws papers, which suggested predictable progress from more compute and data, and then from early access to GPT-4 at the end of 2022, when the jump in capability made it clear that all of programming would flow through these models. Sualeh recalls that Aman bet in June 2022 that AI would win an International Math Olympiad gold medal by mid-2024. Sualeh thought it was delusional; DeepMind's result, one point short, proved Aman nearly right. Aman describes going through the stages of grief, from denial to acceptance, after Michael asked him why scaling wouldn't be all you need.

They forked VS Code rather than writing an extension because they believed models would change how software is built, and a plugin would limit their control. On competing with Microsoft, they argue that in AI programming being even a few months ahead matters enormously: "I think the cursor a year from now will need to make the cursor of today look obsolete." They felt Copilot had gone stale even as models got better, and emphasize that "we're making it for ourselves," with the people designing the interface and those training the models sitting a few feet apart.

Cursor Tab: Eliminating Low-Entropy Keystrokes

Michael describes two things Cursor does well: acting like a fast colleague looking over your shoulder who predicts what you'll do next, and letting you jump ahead by telling the AI what to do. Tab extends autocomplete from predicting characters to predicting your next edit, the next place you'll jump, even a change in another file or a terminal command. Arvid explains the goal as making all the zero-entropy actions, where your intent is already clear but you'd still have to type, happen with a press of Tab. Internally, the competition was how many tabs they could make you press in a row. Aman adds that code has lower loss per byte than natural language, meaning many characters are highly predictable.

Making this work requires tiny, low-latency models that read long prompts but produce few tokens, so the team used a sparse mixture-of-experts model and a technique they call speculative edits. Caching is essential: without reusing the KV cache across keystrokes, they would both destroy latency and overload their GPUs. They also discuss the diff interface, which went through several failed designs, from Google Docs-style strikethroughs to hints revealed by holding the option key, before settling on a box at the side. The deeper challenge is verification: as models propose bigger changes, humans must review more. Aman says "Code review kind of sucks," and suggests models could highlight the important parts of a diff, gray out the boring ones, flag likely bugs, and walk reviewers through changes in logical order. They don't expect natural language to replace code entirely: sometimes it is easier to show an example, or even drag things around, than to explain.

Custom Models, Apply, and Speculative Edits

Cursor runs an ensemble of custom models alongside frontier models. One is apply: frontier models are good at sketching a change but surprisingly bad at producing exact diffs, messing up simple things like counting line numbers in large files. Cursor lets the big model sketch the change and trains a separate model to apply it, which also saves the expensive model's tokens. Simple deterministic matching, they say, fails at least 40% of the time. They imagine a future where smarter models do the planning and cheaper ones handle implementation.

Aman explains speculative edits. Normal speculative decoding uses a small model to draft tokens that a large model verifies, taking advantage of the fact that processing many tokens at once is faster than generating one at a time. For edits, the best draft is the original code itself, so Cursor feeds chunks of existing code back and the model agrees with them in parallel until it reaches the part it wants to change. The result streams much faster and lets people start reviewing before the edit finishes.

On the best coding model, the team says none dominates in every category, but "The one that I'd say right now is just net best is Sonnet." o1 is excellent at interview-style reasoning problems but doesn't grasp rough intent as well. They warn that benchmarks are misleading: real programming involves messy, half-specified instructions, and popular benchmarks like SWE-bench are contaminated in training data, so models can hallucinate the right file paths without seeing the codebase. They lean heavily on qualitative vibe checks and private evals. On theories that Claude has gotten dumber, they note that different chips and numerics, and plain bugs, can matter, because "it's hard to overstate how hard bugs are to avoid."

Prompt Design with Preempt

Arvid explains Preempt, an internal system inspired by React and responsive web design. Prompts are written declaratively like JSX components with priorities, and a renderer fits them into the available context window. For example, the line where your cursor sits gets the highest priority, with priority dropping for lines farther away, and retrieval scores can rank code from elsewhere in the codebase. Separating the raw data from its rendering also makes prompts easy to debug and test against old examples. Users, the team says, shouldn't have to do this; they should write naturally while Cursor retrieves the right context. When intent is unclear, a model could ask a clarifying question, show several options, or, as Cursor now does, suggest relevant files to add based on your history.

Speed: KV Cache, Cache Warming, and Attention Tricks

The team walks through how they make everything fast. Cache warming loads your current file into the KV cache while you're still typing, so there is little to compute when you press enter, reducing time to first token. Aman explains the KV cache: storing the keys and values of previous tokens so the model only needs a forward pass for the newest token. Cursor Tab also speculatively computes the next suggestion as if you had accepted the current one, so it is waiting when you press Tab.

They explain how reinforcement learning exploits the fact that among many samples, one is likely right: Cursor's Tab model is trained to prefer the suggestions humans like most out of many candidates. Aman then covers attention variants that shrink the KV cache, from multi-head to grouped-query and multi-query attention, and DeepSeek's multi-head latent attention, which compresses keys and values into a latent vector. Smaller caches mean more cache hits, bigger prompts, and larger batches without slowing token generation.

Agents, the Shadow Workspace, and Bug Finding

The team thinks agents are really cool but not yet super useful for most tasks. Arvid would love to hand off a well-specified bug, like copy and paste not working in the chat input box, and come back to a verified fix. But most programming is iterative, so they believe you mostly want instant results to react to. Arvid describes the shadow workspace: a hidden instance of Cursor where AI can edit code and get feedback from language servers (type errors, go-to-definition) without touching the user's files. On Linux it could even mirror the file system in memory; on Mac and Windows it is trickier, and one idea is for the AI to hold a lock on saving. Longer tasks may eventually run in remote sandboxes. Fridman adds that for him, agents would also automate his video editing, uploading, and translation work.

The team says frontier models are strikingly bad at bug finding when simply asked, because real bug detection is rare in pre-training data. They also lack calibration about which bugs matter, the cultural knowledge a staff engineer has from seeing sketchy code take down a server. Arvid's practice of labeling dangerous code with comments on every line helps both humans, who forget, and models, which pay more attention. Ideas for training bug finders include having a model introduce plausible bugs into code, then training another model to find them. Fridman suggests tipping or bug bounties; the team finds it a controversial idea internally, worrying money might make the product feel less fun.

Formal Verification and the Limits of Specs

Arvid imagines a future where "I think people will just not write tests anymore." Instead, a model suggests a spec for each function and a reasoning model proves the implementation matches it, possibly scaling to whole codebases, since work already exists on verifying systems down to the hardware. The others push back that intent is often hard to specify formally, and that side effects and external dependencies like a payment API are hard to cover. Arvid even speculates that one might someday prove a language model is aligned, which Fridman notes would span the full range from AI safety to bug finding.

Scaling Infrastructure, Indexing, and Privacy

Sualeh says "AWS is just really really good," and that if something goes wrong, "it's probably your problem." Each extra zero in requests per second has brought new surprises, with overflows in database tables and difficulty scaling the retrieval system. For codebase indexing, Cursor embeds code chunks and stores only vectors, never the code. To keep local and server state in sync without hammering users' Wi-Fi or reading a roughly 20-terabyte database every second, they use a Merkle tree: compare a single root hash and only descend into folders whose hashes differ. Embeddings are cached by chunk hash so teammates on the same codebase don't pay to embed it again.

Why not run things locally? More than 80% of their users are on Windows machines, many not powerful, and even the best MacBook struggles with a big company's codebase or with large mixture-of-experts models. Arvid is hopeful about homomorphic encryption for inference, where the server computes on encrypted data it can't read. He worries that as models become more economically useful, more of the world's information will flow in plaintext through one or two centralized providers, inviting surveillance that starts with good reasons and slides into bad ones. The team adds that people give AI models more personal data than they ever put in the cloud.

Context, Code-Aware Models, and o1

More context makes requests slower and more expensive and can confuse models, so the bar for relevance should be high. Beyond better retrieval, embedding models, and re-rankers, the team is interested in teaching models a codebase directly in their weights, through continued pre-training and synthetic question-answer data about a specific repository. As a hint, they note that models already answer questions about VS Code fairly well because its code was in their training data.

On o1, Aman calls test-time compute a way around the looming data wall: rather than training a huge model for the rare queries that need it, run a smaller model longer on hard problems. Routing queries to the right model is still an open problem. They explain outcome versus process reward models, and speculate that OpenAI hides o1's chain of thought partly to make its capabilities harder to distill, much as some APIs removed log probabilities. They say o1 isn't part of the default Cursor experience yet, in part because it doesn't stream. Asked whether GitHub Copilot adopting o1 means it's time to shut down Cursor, Michael argues the ceiling is so high that the best product in three to four years will be far more useful than today's, and that "if you stop innovating on the product you will you will lose."

Synthetic Data, RLHF, and Scaling Laws

Aman describes three kinds of synthetic data: distillation from a big model into a smaller one; problems that are easier in one direction, like introducing bugs to train bug finders; and generating many outputs that can be easily verified, as with formal math proofs or code that passes tests. The third, he says, is the one most likely to produce massive gains, but perfect verifiers are hard to build for open-ended tasks. On RLHF versus RLAIF, he notes that AI feedback works if verifying is easier than generating, and that Cursor Tab uses a mix, where the model's own judgment needs only 50 to 100 human examples of nudging. The group debates whether AI will win a Fields Medal before a Nobel Prize, with Sualeh betting on the Fields Medal because math is an isolated system with good reward signals.

On scaling laws, Aman says the original OpenAI paper was slightly off because of learning-rate schedules and Chinchilla corrected it, but people now overtrain smaller models for cheaper inference. Other dimensions matter too, like context length, which might favor architectures such as SSMs. He is especially bullish on distillation, as with Gemma learning from a larger model's full output distribution, which may help with the data wall. Asked how to spend 10 trillion dollars, Arvid says "i do believe that we are limited in terms of ideas that we have," while Michael argues engineering talent is the real bottleneck: making it 10 times easier to turn a new architecture idea into efficient GPU code would speed research enormously.

The Future of Programming: Humans in the Driver's Seat

Michael says the team is excited about a future that emphasizes the programmer's speed, agency, and control, not one where you chat with a bot like an engineering department over Slack. Good engineering, he argues, is made of countless micro-decisions and trade-offs, and handing them off loses control. One fuzzy idea is letting programmers move up and down levels of abstraction, for example editing pseudocode and having the changes flow down to real code.

To young people worried about their future, Michael says "I actually think this is a really really exciting time to be building software," with far less boilerplate than a decade ago, and that "people's taste and creative ideas will be magnified." Arvid describes a migration away from async local storage in Node.js that took him and Sualeh five days and could someday take ten minutes by showing a few examples. That would let programmers try things first instead of planning everything at the blackboard. Arvid adds that pressing Tab is really injecting intent, and programming will become higher- and higher-bandwidth communication with the computer. Fridman reads from Cursor's manifesto about a hybrid human-AI engineer who will "iterate at the speed of their judgment," and closes with a programming quip from Reddit: "nothing is as permanent as a temporary solution that works."

Conclusion

This is a rare, detailed look inside one of the most talked-about AI products, and it doubles as a tour of practical AI engineering: custom small models alongside frontier ones, speculative edits and caching for speed, declarative prompt design, Merkle trees for indexing, and the hard, unsolved problems of verification, bug finding, and context. The Cursor team is candid about what doesn't work yet, including agents, o1 integration, and local models, and thoughtful about privacy and centralization. Their central belief is that AI should amplify programmers rather than replace them, removing drudgery so people can move at the speed of their ideas. For developers and anyone curious about where software creation is heading, it is a dense but rewarding listen.

This is a summary of "Cursor Team: Future of Programming with AI" from Lex Fridman Podcast, giving you the GIST so you can decide if you want the REST. Listen to the full episode.