Cursor Team: Future of Programming with AI | Lex Fridman Podcast #447
Cursor team explains forking VS Code to build an AI-native editor that predicts edits, optimizes KV cache, and keeps programmers in control with speed and agency.
Key takeaways
5 points- 1Fork the editor when plugin constraints block rapid AI iteration.
- 2Predict the next edit instead of waiting for prompts.
- 3Specialize small models for Apply, diff, and bug detection tasks.
- 4Shrink KV cache with MQA/GQA/MLA to scale context and batch size.
- 5Replace most tests with AI-generated formal specs verified by reasoning models.
Summary
Cursor is an AI-first code editor forked from VS Code that predicts entire edits and diffs while keeping programmers in the driver's seat.
Core Architecture
- Forked VS Code for deep control after plugins proved too limiting for rapid AI iteration (10:06-20:10).
- Tab feature uses small MoE models and speculative decoding to predict the next change and eliminate low-entropy actions (20:13-30:16).
Model & Interface Techniques
- Ensemble of custom Apply models plus frontier LLMs; speculative edits let humans review before generation finishes (30:18-50:23).
- Preempt JSX system dynamically builds prompts around cursor position to fit context windows (40:21-50:23).
- KV-cache optimizations (MQA, GQA, MLA) and cache warming reduce latency for larger contexts (1:00:33-1:20:41).
Future Direction
- Shift from tests to AI-suggested formal specs verified by reasoning models (1:20:42-1:40:49).
- Emphasis on speed, agency, and taste over full automation or chatbot programming (2:11:04-2:28:53).
Deep read
Executive Summary
The Lex Fridman podcast with the Cursor Team (Michael Truell, Sualeh Asif, Arvid Lunnemark, Aman Sanger) explores Cursor as a forward-leaning fork of VS Code built to accelerate and augment AI-assisted programming. The discussion centers on what a code editor is today, how Cursor aims to redefine the editing experience through advanced AI-driven features (notably Cursor Tab), and how engineering trade-offs—latency, context, and UX—shape the product. A core thread is the move from traditional plugin-based AI capabilities to an integrated, end-to-end AI editing environment that tightly couples model capabilities with user experience, prompting design, and a fast feedback loop.
The team argues that real progress in programming with AI will come from: (1) high-speed, high-agency tools that preserve programmer control; (2) specialized AI systems (MoEs, speculative decoding, and custom models) designed for fast, context-rich code editing and diff generation; (3) a rich UX that guides review and verification, including multi-file diffs and a transparent edit pipeline; (4) background processes (Shadow Workspace) leveraging language servers for verification while preserving a responsive foreground editing experience; and (5) a broader vision where prompts, prompts rendering (via JSX-like design), retrieval, and agentic behaviors enable a more productive developer workflow. They caution against over-reliance on any single model and emphasize human judgment, intent, and high-level design as indispensable to achieving robust, scalable software.
The dialogue also dives into the economics and engineering of scale: caching strategies (KV caches), inference-time compute, model routing, and hardware choices (AWS) for scaling; the role of local versus cloud computation and privacy concerns (including homomorphic encryption as a future possibility); and the use of synthetic data and reinforcement learning (RLHF vs RLAIF) to improve model alignment with coding tasks. They stress that benchmarks alone cannot capture the messy reality of software development, and human feedback (“the vibe”) is essential.
Overall, Cursor’s trajectory is framed as a bold rethinking of the programmer’s toolkit: keep humans in the driver’s seat, push for speed and intelligible AI-assisted interactions, and gradually expand the AI’s role from assisted completion to more autonomous, yet verifiable, in-editor agentic workflows. The practical takeaway is that the future of programming will be defined by how well we align AI capabilities with human design decisions, enabling rapid iteration, safer code editing, and a more delightful, creative coding experience.
00:00:00 Major Topic
Cursor Team: Future of Programming with AI
- This podcast features the Cursor Team (Michael Truell, Sualeh Asif, Arvid Lunnemark, Aman Sanger) discussing Cursor, a code editor forked from VS Code designed to dramatically enhance AI-assisted coding. The conversation spans the role of code editors, the journey from Vim to VS Code, the motivations and decisions behind Cursor, core features like Cursor Tab (the AI-assisted auto-complete and edits), the engineering trade-offs for speed, caching, and UX, and ambitious visions for the future of programming with human-AI collaboration.
"The code editor is largely the place where you build software. And today that’s meant the place where you text edit a formal programming language... a souped up word processor for programmers."
- Speaker: Michael (approx. 00:00)
"Fast is fun."
- Speaker: Group (approx. 00:15)
"There are two things that Cursor is pretty good at right now: looking over your shoulder... and helping you jump ahead of the AI and tell it what to do."
- Speaker: Aman / Arvid (approx. 20:13)
00:04:00 Subtopic: What is a code editor?
- Definition: A code editor is a specialized text editor that adds structure-specific features for programming languages (syntax highlighting, navigation, error checking, definitions, etc.). It’s a fast, graph-aware, and navigable environment for building software.
- Analogy: A code editor is a "souped up word processor" for programmers, with tokens, navigation hyperlinks, and error checking.
- Key insight: The future of code editors may change as software-building practices evolve with AI; editors could become more than editing tools, evolving with AI-assisted planning and editing capabilities.
00:08:00 Subtopic: Cursor origin and journey
- Origin context: Cursor emerges from observing Copilot’s impact and the desire to push beyond simple extensions to a reimagined editing environment.
- History: The team started as Vim users; Copilot on VS Code motivated a shift to that editor, leading toward Cursor.
- Definition: Copilot is an AI-based code completion tool that suggests lines or blocks of code as you type.
- Quote: "Copilot was like the first killer app for LLMs."
- Insight: The team anticipated broader applicability beyond a productized extension, aiming to rethink the entire editing workflow for programmers.
"Copilot is a really nice auto complete... there’s a feeling when it gets you: it feels intimate."
- Speaker: Sualeh / Aman (approx. 12:00)
00:12:00 Subtopic: What is Cursor? Why fork VS Code?
- Core idea: Cursor is a fork of VS Code with a fresh approach to AI-assisted editing; the fork enables more radical experimentation than plugins inside an existing editor.
- Reasoning: Extensions to VS Code have limitations; Cursor wants full control of UX, prompts, context handling, and model integration to push capabilities further.
- Competitive stance: Cursor aims to stay ahead by rapid iteration and deeper integration, not merely feature parity with Copilot.
00:16:00 Subtopic: Two big capabilities of Cursor (Tab and diff interface)
- Tab concept: Cursor Tab predicts user actions, including next edits, next place in the file, or even next file edits. The goal is zero-entropy edits, tabs to advance through edits, and a fast editing loop.
- DIFF interface: Cursor shows model-suggested diffs (red/green blocks) and lets the user apply the suggested changes. There are multiple diff modes depending on context (auto-complete vs multi-file edits).
- UX evolution: Iterations included a side-diff box, then a method where edits could be previewed and toggled with modifier keys, and later a more streamlined approach intended to minimize distraction.
- Vision: The team wants a highly responsive, context-aware diff system that highlights important changes and surfaces potentially buggy regions for review.
"The kernel of the idea behind a good auto complete was predicting what you’re going to do next, but you can make it even more ambitious by predicting the next entire change you’re going to make."
- Speaker: Aman (approx. 20:13)
00:26:00 Subtopic: Technical underpinnings of Cursor Tab
- Key tech: Two important components are (1) Mixture of Experts (MoE) models to handle long context efficiently, (2) speculative edits (a variant of speculative decoding) to accelerate edits by predicting large blocks and validating incrementally.
- Caching: KV cache reuse across requests is crucial to maintain low latency; the system is designed to cache prior prompts and responses to minimize recomputation.
- Detailed terms:
- MoE (Mixture of Experts): a model architecture that routes different inputs to specialized sub-models to handle longer contexts efficiently. - Speculative decoding: running smaller, faster models to draft outputs; larger models verify the drafts. - KV cache: keeps keys and values from previous transformer steps to avoid recomputing attention on past tokens.
- Intuition: The goal is to eliminate low-entropy actions (very predictable edits) and to have the model anticipate the user’s next move with minimal required input.
00:37:00 Subtopic: More on Tab capabilities and future directions
- Near-term goals: Generate code, fill in blank spaces, edit across multiple lines, jump to other files, and possibly control terminal commands.
- Next action prediction: The long-term objective is to enable a human to focus on the high-level intent while the model handles concrete actions, possibly across multiple files.
- Diff quality vs complexity: Differences in diff presentation for small edits vs multi-file edits; ideas include highlighting the important parts and dimming low-entropy sections; potential bug indicators in diffs.
- Role of evaluation: Benchmarks (like SWE-Bench) are not perfect proxies for real-world coding tasks; emphasis on human evaluation (the “vibe”) and qualitative feedback.
00:50:00 Subtopic: Prompt design and Preempt (JSX-based prompts)
- Prompting approach: The team uses a React-like declarative system (JSX) to render prompts and manage what information gets included, prioritized, and displayed to the model.
- Preempt concept: A design that helps adapt the prompt rendering to devices with different context windows and to debug prompts by exposing the raw data used to render prompts.
- Visual prompt design: A component-based prompt that centers around the Cursor line—priorities are assigned (the line with the Cursor is highest priority), then the surrounding lines.
- Retrieval and context: Retrieval, embedding, and re-ranking are used to tailor the prompt content to the current task; the system can render different parts with varying importance to aid the model’s accuracy.
"The Cursor team literally prompts with JSX. It looks like React; there are components; you declare what you want and the system renders it."
- Speaker: Aman (approx. 50:26)
01:05:00 Subtopic: Agents in Cursor and background tasks
- Agents: Cursor views agents as useful but not universally essential yet; potential is significant for background bug fixes, environment provisioning, and project management tasks.
- Replica-like capabilities: The team imagines agents that could configure dev environments, manage dependencies, deploy apps, or fix issues in the background with minimal human intervention.
- Multi-domain application: Beyond coding, agents could automate tasks like video editing, content translation, and YouTube localization.
- Scope and limits: Agents are exciting but not a wholesale replacement for human developers; human oversight and direction remain critical for complex tasks and creative decisions.
01:10:00 Subtopic: Speed, performance, and engineering trade-offs
- Speed strategies: Speculative edits, MOE-based long-context handling, and caching are central to achieving fast responses.
- Four main performance levers discussed: (1) KV-cache optimization, (2) speculative/decode strategies, (3) model selection and routing, (4) data retrieval and prompt rendering efficiency.
- The single most critical UX constraint is latency; even small delays can significantly degrade the user experience in an editing loop.
- The team notes that speed improvements often come with design trade-offs in accuracy or verification; they emphasize maintaining a robust verification flow for the AI’s edits.
"Fast is good. Fast is fun. And when you can be fast, you can iterate more quickly, which is what developers love."
- Speaker: Arvid (approx. 30:00)
01:20:00 Subtopic: Shadow Workspace and background verification
- Shadow Workspace: A separate hidden Cursor window runs background AI processes that can review and modify code without impacting the visible workspace; it can leverage language servers for type checking and go-to-definition in the background.
- Language Server Protocol (LSP): Used to provide type checking, go-to-definition, and references; Cursor uses LSP to supply these signals to the AI while keeping the user’s main workspace clean.
- Linux-specific approach: On Linux, it’s possible to mirror the filesystem and make the AI edits in memory, with a shadow workspace that can later save changes after verification.
- Risks and safety: Editing files directly in a shadow workspace is powerful but requires safeguards to avoid accidental corruption or data loss; a potential approach is to hold a save lock and resolve changes in a controlled manner.
01:25:00 Subtopic: Multi-file diffs and review UX
- Multi-file diffs: The discussion covers presenting diffs across several files with a prioritization scheme to guide reviewers to the most important changes first.
- Review UX critique: Traditional code review can be tedious; Cursor envisions a more intelligent diff review that surfaces the most relevant sections and suggests focused review paths.
- Change prioritization: The human reviewer should be guided through the changes in the order that makes the most logical sense given the code’s dependencies and data flow.
01:30:00 Subtopic: Modeling and system architecture (Sonnet vs o1 vs other models)
- Model lineup: The team compares frontier models like Sonnet and o1, noting that no single model dominates across all criteria (speed, long-context handling, code understanding, etc.). Sonnet is favorable for many coding tasks; o1 excels at reasoning in some contexts but may not match rough intent understanding as well as Sonnet.
- Apply vs Tab interplay: Frontier models can sketch changes (Apply) while Tab handles the editing/execution loop; they emphasize a workflow where high-level planning is done by the frontier model and detailed implementation is refined by specialized models.
- Training vs inference: They discuss the importance of training with task-specific objectives (e.g., code edits and diffs) and the role of speculative inference to speed up responses.
01:40:00 Subtopic: Benchmarks, evaluation, and the reality of coding tasks
- Benchmarks gap: SWE-Bench and other public benchmarks can be contaminated by training data and may not reflect real-world coding tasks where context and user intent vary widely.
- The importance of human feedback: The team relies on qualitative, human-in-the-loop evaluation in addition to private benchmarks; they call this the "vibe" of the system.
- Intent and context gap: Real coding involves messy human goals, multi-step edits, and non-deterministic outcomes; benchmarks often assume well-specified tasks that can mislead progress if over-relied upon.
01:50:00 Subtopic: OpenAI o1 and test-time compute
- o1 focus: Test-time compute is a concept where extra inference time is used to achieve higher-quality results, approximating the performance of a larger model for the majority of queries.
- Model routing: The group discusses dynamic routing between smaller and larger models depending on task difficulty, with ongoing research needed to determine the best heuristics for when to call o1 vs Sonnet vs smaller models.
- The unresolved question: How exactly OpenAI uses chain-of-thought, process reward models, and search strategies remains not fully public; speculation is encouraged but with limited certainty.
"Test-time compute is really interesting... you can run the same size model longer to achieve the performance of a much larger model for the right queries."
- Speaker: Aman (approx. 52:00)
02:00:00 Subtopic: Local vs cloud, privacy, and encryption
- Local inference: Running large models locally is appealing for privacy and latency, but practical constraints (hardware, energy, cost) make it challenging for many users and organizations.
- Privacy concerns: Centralized model providers raise concerns about data privacy and surveillance; the team contemplates homomorphic encryption as a potential way to process encrypted data on the server without exposing raw content.
- Hybrid approaches: A mix of local and cloud processing may occur where lightweight tasks run locally and heavier tasks are performed remotely in controlled environments.
- Embeddings and retrieval: The team reiterates the use of embeddings and vector databases to index code bases for fast, relevant retrieval; the bottleneck lies in embedding bandwidth and storage costs rather than pure compute.
"Homomorphic encryption for language model inference could allow running models on encrypted data so servers never see raw data, addressing privacy concerns."
- Speaker: Aman (approx. 01:40:00)
02:15:00 Subtopic: The future of programming and up/down the abstraction stack
- Abstraction stacking: The team envisions being able to move up and down the abstraction stack—writing at a high level (pseudocode) and having the system translate to concrete code, then drilling back down as needed.
- Human-in-the-loop: The programmer remains in control for critical decisions; AI augments, accelerates, and orchestrates but the human defines intent and makes high-level decisions.
- Skill shift: Programming will remain a valued skill, but the process will be more about rapid exploration, iteration, and high-level design with the AI handling the heavy lifting of boilerplate and micro-implementation details.
02:30:00 Subtopic: Synthesis: synthetic data taxonomy and RL methods
- Three kinds of synthetic data:
1) Distillation: using a strong model to generate outputs that a smaller, task-specific model learns from. 2) Data for bug detection: generating bugs so a model can learn to detect and fix them. 3) Verification-driven data: generating scenarios where outputs can be verified by a separate verifier, enabling training data with known correctness signals.
- RLHF vs RLAIF: Reward models trained on human feedback (RLHF) vs feedback from AI-generated data (RLAIF). The team notes nuanced tradeoffs and suggests mixed approaches depending on verification feasibility.
- Tree search with process rewards: The possibility of using process reward models to guide tree search across multiple reasoning paths to improve long-horizon problem solving, including code and math.
"Verification is best when you know a solution is correct; in practice, you often don’t. So you need good verifiers, tests, or formal proofs to anchor synthetic data."
- Speaker: Aman (approx. 01:50:00)
02:45:00 Subtopic: The future of programming—speed, control, and upskilling
- Final outlook: The Cursor team emphasizes the programmer in the driver’s seat, preferring fast, high-agency tools that enable rapid iteration, high-fidelity control, and direct manipulation of code and system design.
- Two paths for the future: (1) advanced natural-language-like interactions for well-specified tasks, and (2) higher-bandwidth editing where intent is expressed through examples, sketches, and direct manipulation rather than prose alone.
- The human edge: The best programmers will be those who deeply love coding and can leverage AI to push the limits of what’s possible with software engineering.
"We are building the engineer of the future, a human AI programmer that’s an order of magnitude more effective... We’re building software and models to invent at the edge of what’s useful and possible."
- Speaker: The Cursor Team (approx. 02:15:00)
02:55:00 Subtopic: Resources mentioned and wrap-up
- The dialogue references several tools, papers, and platforms including VS Code, Copilot, GPT-4, Long-context models, MoE (Mixture of Experts), Speculative Decoding, LSP (Language Server Protocol), Shadow Workspace, embeddings, vector databases, AWS infrastructure, and various networking and database concepts.
- The team hints at ongoing work and invites readers to follow updates and sponsor messages in the description.
02:58:00 Subtopic: Quick tour of resources and terms to know
- Resources mentioned: VS Code, Copilot, GPT-4, DeepMind scaling-loss papers, IMO (International Math Olympiad), Putnam competition, SWE-Bench benchmark, Sonnet (model), o1 (OpenAI model), MOE, Multi-Query Attention (MQA), MLA (Multi-Latent Attention), Speculative Decoding, Preempt, Shadow Workspace, LSP, TypeScript language server, Rust language server, PlanetScale (branching databases), Merkle trees for hash reconciliation, AWS tools for infrastructure.
- It’s recommended to review these resources to understand Cursor’s approach to AI-assisted programming.
03:10:00 Resources Mentioned (detailed)
- Books/Papers: OpenAI scaling laws (Chinchilla), DeepMind scaling insights, etc.
- Tools/Platforms: VS Code, GitHub Copilot, AWS, PlanetScale, TypeScript language server, Rust language server, Embeddings, Vector databases.
- Concepts: MoE (Mixture of Experts), Speculative decoding, Multi-Query Attention (MQA), Multi-Latent Attention (MLA), Shadow Workspace, LSP, code embeddings, retrieval-augmented generation, tree search, process reward models.
03:20:00 Final reminders
- The Cursor team reiterates the goal of making programming faster, more fun, and more reliable through AI-augmented tooling, while keeping humans in the loop for high-level design and critical decisions.
- There is no single all-encompassing model; progress comes from integrating multiple specialized models, UX engineering, and thoughtful prompts.
Resources Mentioned
- VS Code
- Copilot
- GPT-4
- DeepMind scaling-loss papers
- IMO (International Math Olympiad)
- Putnam competition
- SWE-Bench
- Sonnet (model)
- o1 (OpenAI model)
- MoE (Mixture of Experts)
- Speculative decoding
- Multi-Query Attention (MQA)
- Multi-Latent Attention (MLA)
- Shadow Workspace
- Language Server Protocol (LSP)
- TypeScript language server
- Rust language server
- PlanetScale (branching databases)
- Merkle trees for hash reconciliation
- AWS
- Preempt (prompt rendering system)
- Embeddings / Vector databases
- Retrieval-augmented generation
- Tree search with process rewards
- RLHF / RLAIF
- OpenAI o1
- React/JSX prompt design
- Diffs UX concepts
Action Items
- Develop and refine Cursor Tab’s multi-file diff presentation to better surface critical regions and reduce cognitive load.
- Invest in MoE-based long-context models and optimize speculative edits to maximize latency improvements without sacrificing correctness.
- Implement and iterate on cache-warming strategies so the KV cache is primed before user input completes, reducing latency.
- Advance the Shadow Workspace concept: ensure safe, verifiable background edits via LSP data, and explore sandboxed environments for heavier tasks.
- Experiment with JSX-based prompt rendering and Preempt to optimize prompt data handling across devices with varying context lengths.
- Prioritize user-controlled prompts that preserve human intent while enabling AI to suggest relevant context and files to edit.
- Experiment with background agents for bug discovery and environment provisioning, while maintaining strict safeguards and review workflows.
- Continue exploring privacy-preserving techniques (e.g., homomorphic encryption) for cloud-based inferences and shared codebases.
- Tune model routing policies to selectively use o1 vs Sonnet vs smaller models based on task complexity and latency budgets.
- Develop robust evaluation pipelines that combine benchmark data with human feedback to better reflect real-world coding tasks.
Mental Models
Glossary
- MoE
- Mixture of Experts: a model architecture that routes different inputs to specialized sub-models to handle long contexts efficiently.
- Speculative Decoding
- Generating draft outputs with a smaller model which are then verified and refined by a larger model.
- KV cache
- Key-Value cache used in transformers to store representations of past tokens so that attention calculations don’t redo work.
- LSP
- Language Server Protocol: a standard for providing editor features like type checking, go-to-definition, and references across languages.
- Retrieval-augmented generation
- A method where external context (like code snippets) is retrieved and fed into the model to improve generation quality.
- Shadow Workspace
- A parallel, hidden workspace where AI processes can edit and test code without affecting the user's visible environment.
- Embeddings
- Numerical representations of text or code used to measure similarity and drive retrieval in vector databases.
- Vector database
- A database optimized to store and search high-dimensional embedding vectors for similarity-based retrieval.
Notable Quotes
“The code editor is largely the place where you build software. And today that’s meant the place where you text edit a formal programming language.”
“"Fast is fun."”
“"There are two things that Cursor is pretty good at right now: looking over your shoulder, and jump ahead of the AI and tell it what to do."”
“"Copilot was like the first killer app for LLMs."”
“"We are building the engineer of the future, a human AI programmer that’s an order of magnitude more effective."”
“"There is no model that Pareto dominates others."”
“"Engineering is not just about the spec being fully written out; it’s about tiny micro-decisions and trade-offs."”
“"The future programming will be a balance of natural-language-like interactions and high-precision, low-entropy editing."”
Topics
More from Lex Fridman Podcast
See all




