Building a Next-Generation AI-Powered Code Editor

cursor · Tech · 2023 · source Agentic: no · promotional bias: low · source-backed · extracted with prompt 0.5.4 (schema v2)

Generated from extraction.json — do not edit by hand. Every claim cites verbatim source evidence; stated means the quote directly asserts the claim, implied means it supports it indirectly.

Problem

Domain: AI-native software development tools

Cursor wanted to build a code editor whose interface and model stack evolved with rapidly improving language models, rather than merely swapping stronger models into a static autocomplete experience.

Constraints:

• frontier models are useful but too slow or expensive for latency-sensitive editor interactions
• standard pretraining data captures committed code but not the edit decisions between commits
• building custom models before product-market fit can waste capital and GPU spend
• the team needed to compete in a crowded developer-tools market against incumbents with distribution and editor ownership
• many product ideas failed before becoming useful enough to ship

Architecture

Cursor built an AI-powered IDE around a hybrid model strategy: frontier model APIs such as Sonnet and reasoning models handle high-level reasoning, while about 10 served custom models handle low-latency and proprietary-data-sensitive features such as Cursor Tab, next-edit prediction, autocomplete, and codebase embeddings. The product loop relies on owning the IDE interface, shipping useful experiments early, collecting real user edit data, and training models on what happens between commits.

Diagram confidence: reconstructed (reconstructed from prose).

flowchart LR
  cursor-ide[Cursor IDE] --> frontier-model-apis[Frontier model APIs]
  cursor-ide --> custom-model-serving[Custom model serving]
  custom-model-serving --> cursor-tab[Cursor Tab]
  custom-model-serving --> codebase-indexing[Codebase indexing]
  cursor-ide --> user-edit-data[User edit data]
  user-edit-data --> custom-model-serving
  cursor-ide --> experimentation-loop[Experimentation loop]
  experimentation-loop --> user-edit-data
  frontier-model-apis --> cursor-ide
  codebase-indexing --> cursor-ide
  cursor-tab --> cursor-ide

Components

Data flow

Developers work inside Cursor's IDE. The product captures codebase context, user edit behavior, and feature usage. Frontier models are called for reasoning-heavy tasks, while custom models trained on Cursor-specific data power next-edit/autocomplete and embedding-based codebase understanding. Product experiments are shipped once useful to the team, observed in real use, and either improved, cut, or folded into the core editor experience.

Why this architecture

Cursor chose a hybrid architecture because model choice depends on product constraints. API-based frontier models are the best tool for many reasoning tasks, but low-latency editor interactions and between-commit edit behavior benefit from custom models trained on Cursor's own usage data. Owning the IDE gave the team the UX surface needed to turn those model capabilities into product features.

Models used: Claude Sonnet · o1 · o3 · DeepSeek R1 · custom Cursor models · custom embedding models

Scale

• Cursor had roughly 30,000 daily active users by January 2024, enough to train next-edit models on real user data.
  “30,000 I want to say daily active users give or take. Yeah. And you know with these users we now had um some data and we could use this to train models to predict your next edit.”transcript, stated
• Cursor technically had around 50 custom models, with about 10 served in production.
  “snap like technically it's like 50 but the ones that are actually served it's probably like 10 10 custom models and then on the frontier use bunch of them or just on the frontier we mainly stick to I think sonnet is the main one and then some people prefer a few other”transcript, stated
• The company reached a $100 million annualized revenue run rate before building a sales team.
  “first dollar of revenue to hund00 million of revenue annualized ARR or run rate. So tell us like how how did that happen? Like what what you guys do? You don't have any sales people, right? We set up a stripe and then you set up people pay and it just boom. I mean, you”transcript, stated
• The product was built and shipped initially by four founders over roughly two to four months of experimentation.
  “it was mainly just the founders and it was four of us and the four of you built the product you shipped the product”transcript, stated

  “it was about two, three, four months of really experimenting, trying different things and then find finding something that fit.”transcript, stated

Alternatives considered (roads not taken)

Swap stronger models into a static Copilot-style autocomplete experience

Rejected because: Cursor believed better models required reimagining the software-building interface, not only improving ghost text.

Spend heavily on GPUs before product-market fit

Rejected because: Cursor's strategy was pragmatic model choice, using APIs when appropriate and training custom models only where data and latency justified it.

Use prompted models for Copilot++/next-edit prediction

Rejected because: Prompted attempts failed until Cursor had enough user data to train custom next-edit models.

Focus narrowly on tests or bug detection

Rejected because: During slow growth, the team considered narrowing scope but continued building the broader editor because they were users of the product and found core features that worked.

Patterns

model-routing (model-architecture)

Cursor routes work between frontier models for reasoning and custom models for low-latency or proprietary-data-sensitive editor features.

latency-optimization (serving)

Cursor trains custom models for editor features where low latency and lower costs matter more than maximum frontier-model capability.

data-quality-loop (training-data)

Cursor uses real user edit behavior, especially what happens between commits, as a training signal unavailable in ordinary GitHub pretraining data.

rag-retrieval (codebase-context)

Cursor uses codebase indexing and custom embedding models so users can ask questions about a whole codebase and retrieve relevant code context.

Tradeoffs

Use APIs and custom models pragmatically

Chose Frontier APIs for many tasks plus custom models where they had data and latency advantages over Owning all model infrastructure from the beginning.

Rationale: Cursor saw API calls as often the best tool, while custom models became worthwhile once the team had usage data and specialized latency needs.

Own the editor interface

Chose A full IDE product over A narrower developer tool or model-only layer.

Rationale: Cursor believed owning the interface gave it an edge in translating model improvements into useful coding workflows.

Train custom models on proprietary edit data

Chose Between-commit user edit data over Relying only on GitHub code snapshots from pretraining.

Rationale: The next-edit task depends on how programmers change code, not only final committed code states.

Keep broad AI-editor ambition during slow growth

Chose Continue iterating on the general-purpose coding IDE over Narrowing to tests, bug detection, or another specialized use case.

Rationale: The team was its own user base and found core features that made the broader product take off.

Gotchas (what bit them)

Better base models do not automatically produce a better programming interface.

Root cause: Copilot's product experience stayed largely the same even as underlying models improved.

Resolution: Cursor owned the IDE interface and experimented with new interaction models such as instructed edits and codebase indexing.

Prompt-only next-edit models failed before the team had enough user data.

Root cause: Next-edit prediction depends on behavior between commits, a distribution not captured by ordinary code pretraining data.

Resolution: After reaching enough usage, Cursor trained custom models on user edit data.

Premature infrastructure spending can outpace product-market fit.

Root cause: AI startups were tempted to spend large funding rounds on GPUs before knowing what product worked.

Resolution: Cursor used APIs where they were the best tool and invested in custom models where specific latency, cost, or data advantages existed.

Many plausible AI coding features do not work on the first several attempts.

Root cause: The product space required discovering UX/model combinations that were useful in practice.

Resolution: Cursor shipped useful half-finished experiments, watched reactions, cut most ideas, and kept improving the ones that worked.

Evaluation

Cursor evaluated product and model decisions through rapid product experiments, internal dogfooding, user reaction after release, and production use of custom models for latency-sensitive features.

Metrics: daily active users · custom models served in production · feature usefulness to the team · growth after feature launches · latency and cost relative to lab-provided frontier models

Outcomes

• Cursor grew from a slow initial launch to rapid growth after Command-K instructed edits and codebase indexing worked.
• The product served roughly 10 custom models in production while keeping Sonnet and other frontier models available.
• Cursor reached a $100 million annualized revenue run rate with a very small team and little early sales motion.
• The company still described itself as only a few percent done, with background AI coworkers and in-flow coding assistance as future directions.

The interview cites about 30,000 daily active users by January 2024, roughly 10 served custom models, and $100 million annualized revenue run rate.