Truell, Michael & Asif, Sualeh & Lunnemark, Arvid & Sanger, Aman
▶ Watch on YouTubeCore ideas
The Cursor team traces their path from Vim purists to building an AI-native code editor: the 2021 GitHub Copilot beta and, later, early access to GPT-4 in late 2022 convinced them that programming was about to be transformed so fundamentally that a mere plugin architecture (bolted onto VS Code, as Copilot was) would be too limiting. They forked VS Code specifically to gain full control over the editing experience, reasoning that co-locating the people who build the UX with the people who train the underlying models (often the same person) lets them iterate on both simultaneously in ways a plugin-based competitor structurally cannot — and they frame their edge over Microsoft not as a permanent moat but as a continuous need to make "the Cursor of today look obsolete" a year from now, since every new model capability unlocks a fresh wave of possible features.
Much of the conversation details Cursor Tab, their enhanced autocomplete: rather than just completing the current line, it aims for "next action prediction" — jumping the cursor to the next relevant edit location (potentially across files), suggesting terminal commands, or navigating you to a type definition you need to verify a suggestion, all framed around eliminating "zero entropy" keystrokes (characters that convey no new information once intent is established). Technically this relies on small, fast models tuned for extremely long prompts with short outputs (making sparse/MoE architectures a good fit), heavy KV-cache reuse and cache-warming as the user types, and "speculative edits" — a variant of speculative decoding that exploits the fact that most of the original code will be echoed unchanged, letting chunks be processed in parallel until the model diverges from the ground truth. The team discusses several generations of diff-UI experiments (crossed-out lines, option-key-to-preview, colored boxes) as an unsolved "verification problem": as models generate larger changes, humans need help knowing which parts of a diff actually matter, ideas include graying out low-information regions or having a model flag likely-bug lines, and reordering multi-file diffs so review follows logical dependency rather than alphabetical file order.
On model selection, they describe an ensemble approach: frontier models (Sonnet, favored for balancing capability with real-world instruction-following beyond benchmarks; o1, strong at hard reasoning but not streaming and less attuned to "rough intent") are paired with custom-trained smaller models for specific jobs like Cursor Tab and "Apply" (converting a sketched code change into an actual diff, which turns out to be surprisingly non-deterministic and hard even for frontier models — failing roughly 40% of the time with naive approaches). They're skeptical of public coding benchmarks like SWE-Bench, both because messy real-world prompting ("half-broken English," implicit context, "do what I did before") differs sharply from well-specified interview-style problems, and because popular benchmarks are often contaminated in pretraining data; as a result they lean heavily on internal qualitative "vibe checks" from real usage.
A recurring theme is bug-finding as a still-unsolved frontier: even frontier models are "incredibly poorly calibrated" at spotting real bugs when simply prompted to do so, which the team attributes to pretraining data being dominated by code generation and Q&A rather than the much rarer task of bug detection — a generalization gap rather than a comprehension gap, since the models clearly encode "sketchiness" internally but can't act on it reliably, especially since real bug severity requires cultural/institutional judgment (a staff engineer's memory of what "took the server down last time"). Their mitigation strategies include synthetic data (training a model to introduce bugs, then reversing that model to detect them) and giving models access to runtime information (linters, traces, debuggers) rather than asking them to spot bugs from static code alone; Arvid also floats a longer-term vision of formal verification largely replacing unit tests, where models generate a natural-language spec you review while a separate reasoning model proves the implementation matches it — though the group debates whether such specs can capture true intent, and how to handle external dependencies like third-party APIs or even other models as verified components.
On infrastructure, they describe using Merkle-tree-based hierarchical hash reconciliation to keep a client's local code index in sync with a server-side vector database without constant heavy network/database traffic, and a vector cache keyed on chunk hashes so embedding costs aren't repeated across many users/branches of the same codebase (no raw code is stored server-side, only vectors). They explain why local/on-device embeddings aren't currently viable — most users are on underpowered Windows machines, and even a senior engineer at a large company would struggle to embed a massive codebase locally — while noting genuine unease about the centralization risk of routing "the world's information" through one or two AI providers, floating homomorphic encryption for inference as a speculative but appealing long-term mitigation, distinct from (and more worrying than) existing cloud-provider centralization because AI systems invite people to share far more sensitive data than they'd ever have put in the cloud otherwise.
Looking at broader ML trends, they discuss the "Shadow Workspace" (a hidden, unsaved copy of the user's environment where AI agents can get real compiler/linter/type-checker feedback in the background without disturbing the user, eventually extending to actually running code), a taxonomy of synthetic data (distillation from larger models; asymmetric generation-easier-than-verification tasks like bug injection; and "verify-then-train" loops for domains with strong verifiers like formal math or unit-testable code, which they see as most likely to produce large capability gains), and RLHF versus RLAIF (the latter viable specifically when verification is meaningfully easier than generation, which is often true, echoing the P-vs-NP intuition that checking a proof is far easier than finding one). On agents, they're enthusiastic in principle (well-specified, self-contained bugs are an ideal target) but skeptical that agents will subsume most of programming, since much of programming's value lies in fast iteration on an initially under-specified goal — you often don't know exactly what you want until you see a first version. They close with a philosophy of "human in the driver's seat": rather than chat-box software specification (which they think discards too many of the countless micro-decisions that constitute real engineering judgment), they envision future programming as manipulating a codebase at variable levels of abstraction (e.g., editable pseudocode that compiles down to real code) while preserving direct control — arguing this will make programming more fun, not less skilled, by stripping out boilerplate and "low entropy" busywork so programmers can focus on taste, design trade-offs, and rapid iteration (illustrated by a five-day AsyncLocalStorage-to-context-object migration they hope future tooling could compress to about ten minutes).
Excerpts
On why they forked VS Code rather than building a plugin:
“When we started working on the editor, the idea was these models are going to get much better, their capabilities are going to improve and it's going to entirely change how you build software... So you're very limited in the control you have over a code editor if you're a plugin to an existing coding environment, and we didn't want to get locked in by those limitations.”
On why current models struggle so much with bug-finding despite understanding code well:
“These models are really strong reflection of the pre-training distribution... The things that we use these things for, the frontier models that they're quite good at, are really code generation and question answering... when you try to push one of these things that really don't exist very much online... the brittleness kind of shows. And bug detection is another great example.”
On their vision for the future of programming, resisting a purely conversational/agentic model:
“We think you'll really want the human in the driver's seat dictating these decisions... one weird idea for what that could look like, is it could look like you can control the level of abstraction you view a code base at... you keep the inflow text editing component of programming, you keep the control... You can even go down into the code, you can go at higher levels of abstraction, while also giving you these big productivity gains.”