Lessons from Building Cursor

2026-07-04 · source · source ↗ · raw capture · wiki page

Interview on ByteByteGo with a Cursor team member (Speaker B, joined by interviewers A and C). Covers Composer 1.5 model training, RL infrastructure at scale, context window solutions, cloud agents, and what "coding got solved" actually means.

Summary

Model-Building as Product-Building

Cursor trains its own models (Composer 1.5, positioned "somewhere between Sonnet 4.5 and Opus 4.5 in capability") because certain capabilities must be "built into the model" — they can't be prompted into existence. Semantic search across large codebases is the prime example: an RL-trained model finds what it needs in 1–3 queries rather than tens of greps. Recursive subagents and self-summarization are similarly only learnable through RL, not prompting. The model has to experience millions of sandbox sessions to internalize effective tool use patterns.

RL Infrastructure Is a New Kind of Hard

Running RL training at Cursor's scale requires "millions of sandboxes" and "100 million plus of CPU compute per year." This scale forces in-house orchestration — "you can't actually buy the infrastructure from anyone." Long-running agents (minutes to days) break traditional RPC assumptions. The speaker points to Temporal and Restate as workflow engines suited to this paradigm, but notes that deployments for 12-hour-running agents are uniquely difficult.

Context Windows Are Solved Through RL

Instead of trying to prompt the model to produce good summaries, RL "forces the model to produce" summaries that are genuinely useful to its future self. The model also learns to dump old conversations to files and grep them later. "You don't need a trick" — the incentive structure of RL solves the framing problem naturally. The model learns what information its future self will actually need, because RL rewards correctness on downstream tasks.

Cloud Agents Need a Step Change, Not UI Tweaks

Cloud agents today are "a worse version of the local agent" — slower to boot, harder to review diffs. The speaker argues that to grow cloud agent compute from ~1% to ~90% requires a step change, not incremental improvements: "small tweaks never really get you factors of 1000." The key insight is that the model must test its own code and prove correctness. "It should feel like the model wrote the code and it should be the model's responsibility to figure out if it's correct or incorrect."

The Devex Problem for AI

Models "silently degrade" when services aren't started in the right order — unlike humans, they don't complain. The speaker predicts "companies in the future will have some devex teams" that document boot-up procedures specifically for AI agents. This is a new category of infrastructure: runbooks not for onboarding humans, but for making environments legible to models.

Model Routing Is a UX Problem

Cursor avoids routing because "a lot of people get very confused." The ideal: "you just press enter, you forget about it" — like Google. The speaker sees routing as a temporary crutch, not a permanent architecture.

"Coding Got Solved in Six Months"

Presented as "a boring fact about the world, not an inflammatory claim." Between March/April and December of some recent year, "the best engineers I know are not writing code by hand anymore." The next capability jump: engineers adopting a "managerial instinct" — becoming more like managers overseeing agents than coders typing syntax. The speaker predicts "one to two capability jumps" every half year.

The Browser Experiment

The speaker describes watching a model build a functional browser over three days with "three or four thousand commits" — and realizing "for the first time I was thinking, I can't do this." This led to the vision of "self driving code base": allocate a budget, and the codebase manages security, tech debt, bugs, and features autonomously.

Advice for Engineers

"If your code base will stay for many years, review every line of code. If your code base is for a weekend, who cares?" The nuance: review rigor scales with expected lifetime. But also: the speaker claims most engineers "actually enjoy coding more now" because "boring aspects like debugging for hours" have diminished.

Pithy Quotes

Tools, Practices, and Methodologies

Unanswered Questions and Omissions