AI-Editor Systems & Design

The model only knows what you put in front of it. Everything Cursor does well starts with one quiet, brutal engineering problem: which bytes of a million-line repo go into a few-thousand-token window.

An interviewer who works on the editor will probe this fast, because it's the unglamorous core of the product. A completion that ignores the helper you wrote two files over feels broken even when the model is fine. The model wasn't wrong, it was blind. Context retrieval is the part of the system that decides what it gets to see.

Frame the prompt as a budget you spend deliberately. You have a fixed token window, you want to fill it with the snippets most likely to make the next edit correct and you have milliseconds to decide.

What goes into the contextranked, not dumped

Strong answers name concrete sources and the order you'd try them, not a vague "relevant code." Lead with what's cheapest and most certainly useful, then spend the rest of the budget on retrieval.

Three retrieval strategies and when to combine

Candidates who only say "embeddings" undersell themselves. The honest answer is that each approach fails in a way the others cover, so production systems blend them and re-rank.

Indexing a large repo and keeping it fresh

A repo with hundreds of thousands of files can't be re-embedded on every keystroke. The interview wants to hear that you index incrementally and treat freshness as a first-class problem.

1. 1Initial build. Walk the tree, chunk by syntactic unit (function, class, block) rather than fixed lines so a chunk is a meaningful retrieval target. Embed and store, keyed by a content hash.
2. 2Incremental update. On save or file-watch event, re-chunk only the changed files. The content hash skips re-embedding chunks whose text didn't move.
3. 3Edit-time freshness. Between index updates, the live buffer is the source of truth - read recent edits from the editor, not the stale index, so the model sees what the user just typed.
4. 4Eviction. Drop vectors for deleted files and prune by access recency so the index doesn't grow without bound.

Ranking and truncation when context overflows

The window will overflow on any real repo, so truncation policy is where you show judgment. Don't drop uniformly. Rank by an estimate of marginal usefulness and cut the tail.

• Score each candidate by a blend of retrieval score, structural proximity (is it imported, is it open) and recency of edit.
• Pack greedily down the ranked list until the budget is spent, reserving headroom for the model's output.
• Prefer signatures and types over full bodies for distant code - a function's interface is often enough and costs a fraction of the tokens.
• Always keep the cursor's immediate surroundings and recent edits whole; never let retrieved noise crowd out the one thing you know is relevant.

A completion suggests. An agent acts. The jump from autocomplete to an agent that reads files, runs tools and rewrites five files in one turn is where most of the hard product decisions live.

Cursor builds the surfaces for AI-native workflows - reviewing PRs of AI-generated code, coordinating multi-file edits - so an interviewer will want you to reason about the loop itself, not just the model behind it. The loop is a control system wrapped around a probabilistic core.

The plan, act, observe loop

An agent turn is a cycle, not a single call. It plans an action, takes it, reads what happened and decides whether it's done. Each pass through the loop is one tool call plus its result fed back into context.

1. 1Plan. From the user's request and current context, the model decides the next action - read a file, search or propose an edit. Keep the plan small; over-planning ahead of evidence is where agents drift.
2. 2Act. Execute the tool call. Reading a file, running a search or applying an edit are all just tools the model can invoke, each with a typed result.
3. 3Observe. Feed the result back: file contents, search hits, a compiler error. This grounds the next step in reality instead of the model's guess.
4. 4Verify and decide. Check progress against the goal - did the test pass, did the type-check clear - then loop or stop. A turn that never verifies is the classic confidently-wrong agent.

Streaming edits and the review surface

Multi-file edits raise a UX problem before a systems one: the user has to stay in control of changes they didn't type. The answer is to stream edits into a diff the user reviews, not silently overwrite the buffer.

Guardrails: scope, confirmation, rollback

An agent that can edit anything is a liability. Constrain its blast radiusHow much breaks if a change goes wrong; the scope of potential damage. up front and make every action reversible.

Failure handling

Edits fail in specific, recurring ways and naming them is what separates a careful systems answer from a hopeful one.

Tab prediction has to land before the user's next keystroke. That single constraint - sub-100ms, every keystroke, millions of users - is one of the most common design prompts for this role and it rewards engineers who think in tail latency and unit economics.

Don't jump to a model. Start by sizing the problem out loud, because the numbers dictate the architecture. Every keystroke at millions of users is a torrent of requests, most of which the user will never see - so the cheapest request is the one you never make.

Frame the budget first

The latency levers

Cost control: route by difficulty

At this scale, cost and latency are the same conversation. You can't afford a big model on every keystroke and you don't need one. Most completions are trivial.

1. 1Default to small. Send the overwhelming majority of completions to a fast, cheap model that handles the easy 90%.
2. 2Detect difficulty. Use signals - low model confidence, a complex multi-line context, an explicit larger request - to flag the cases the small model will fumble.
3. 3Escalate selectively. Route only the hard minority to a larger model, accepting its latency where the user expects a beat to think.
4. 4Cache the wins. Memoize completions keyed on context so a repeated situation never pays inference twice.

p50 is a vanity metric; p99 is the product

A great median with a bad tail still feels broken, because the user remembers the stall, not the 200 fast completions before it. Tab prediction has a hard UX cliff: past roughly 100–150ms the suggestion arrives after the user has already typed past it and a late suggestion is worse than none - it's a distraction.

• Set the SLO on the tail (p99), not the median and treat a p99 regression as a product bug, not a perf nicety.
• Shed load gracefully: under pressure, drop to the small model or skip the completion rather than serving it late.
• A timed-out completion should silently no-op; never show a stale suggestion two keystrokes after it was relevant.

You're asking enterprises to send their proprietary source code to a model over the network. The entire product is a trust transaction and privacy is not a compliance checkbox - it's a feature you can lose deals without.

Lead with the default that earns trust: don't train on user code. Then layer the standard protections and be honest about the tradeoffs, because a confident "it's all encrypted" with no nuance reads as someone who hasn't thought about where code actually flows.

The protection layers

Local vs server-side: the central tradeoff

Where computation happens is the real design fork. Server-side gives you latest-generation models and shared indexes; local keeps code on the user's machine but caps capability. The interview wants you to reason about the spectrum, not pick a dogma.

Privacy as a product tier

Frame this as a differentiator, not just a constraint. A privacy mode - no retention, no training, optionally local indexing - is exactly the thing that lets a security-conscious enterprise say yes when a competitor can't give the same guarantee.

• A "privacy mode" that hardens defaults (zero retention, no training, restricted egress) and is contractually verifiable, not just toggled.
• Clear data-flow documentation, since enterprise buyers need to show their own security team exactly where code goes.
• Be ready to position this against Copilot, Windsurf and Claude Code - "who do you trust with the repo" is a real buying axis and an opinion here signals you understand the market.

Cursor runs experiments on millions of users to advance the agent. That sentence is in the job description and it means you'll be asked: how do you actually know one model or prompt is better than another?

The trap is measuring what's easy instead of what matters. Acceptance rate is trivial to log and dangerously misleading on its own. The skill is building a metric stack that catches the gap between "the user clicked accept" and "the code was good."

Metrics for suggestion quality

Offline evals before you risk production

You don't A/B test a change you haven't sanity-checked, because exposing millions of users to a regression is expensive and erodes trust. Gate on offline evals first.

1. 1Build a held-out task set. Real tasks with known-good outcomes - this refactor should compile, this completion should match the accepted ground truth.
2. 2Grade automatically where you can. Compile, type-check and test-pass are deterministic, fast and trustworthy; reserve an LLM-judge for taste a test can't express.
3. 3Set a gate. A candidate has to clear the offline threshold before it earns a live experiment. Regressions die here, cheaply.
4. 4Watch for overfitting. A set you tune against stops measuring; refresh tasks and hold some fully blind.

A/B testing on millions of users

Once a change clears offline, it earns a slice of live traffic. At Cursor's scale the statistics are easy; the discipline is in guardrails and honest readouts.

The model will sometimes invent an API that doesn't exist, call a function with the wrong signature or confidently delete the wrong block. You can't make a probabilistic system deterministic, so you design the system around it being wrong sometimes.

Onsite prompts in this loop have included addressing hallucinations in deployed models, so a vague "we'd improve the prompt" won't survive. Come with a layered playbook that reduces wrong output, catches what slips through and makes the rest cheap to reject.

Three lines of defense

Grounding is the biggest lever

Most code hallucination is the model filling a gap in its context with a plausible guess. Give it the real signature of the function it's calling and the guess has nowhere to go. This is why retrieval (section one) and hallucination control are the same problem viewed from two ends.

• Feed exact symbol definitions and types so the model references reality, not its training-data memory of a similar library.
• Constrain to a structured edit format the system can parse and validate, rejecting anything malformed before it reaches the buffer.
• Prefer tool calls (read the file, search the docs) over the model recalling an API from memory.

Verification: the loop that earns trust

The cheapest, most reliable hallucination filter is the compiler. Code is special among LLM outputs: you can often check it mechanically. Lean on that hard.

1. 1Type-check / compile the proposed edit. A change that doesn't build is wrong, full stop, no model judgment required.
2. 2Run relevant tests where they exist; a passing suite is strong evidence the edit preserved behavior.
3. 3Feed failures back into the agent loop so it fixes its own mistake before the user ever sees it.
4. 4Escalate the unverifiable. When nothing mechanical can check it, mark it uncertain and lean on the review UX rather than pretending it's verified.