In 2023, GitHub Copilot already had millions of users, Microsoft's distribution muscle, and a two-year head start. Cursor launched anyway — as an API wrapper, not a model company — and within eighteen months had built a product that engineers preferred over Copilot for complex, multi-file work. By 2025, it was valued at $2.5 billion on reported ARR of ~$100M.
This is a case about the build/wrap decision, the product wedge that beats a platform player, and the specific judgment calls Cursor made that GitHub got wrong.
The decision: don't build a model, build a context machine
The founding team at Anysphere made a bet that was obvious in hindsight and non-obvious in 2022: the bottleneck in AI coding tools was not model quality — it was context quality. Copilot knew your current file. It didn't know the rest of your codebase, your recent changes, your conventions, your intent.
Their bet: build the layer that understands your codebase and feeds that context to the model, and the underlying model matters much less than how well you curate what goes into the prompt.
This is a classic "wrap" decision, not a "build" decision. Cursor never trained its own models for the core coding task. It used GPT-4, then GPT-4o, then Claude 3.5 Sonnet, then mixed routing depending on task type — always selecting the best available external model. The proprietary value was the context pipeline: the indexing of your full codebase, the relevance ranking for which files to inject, the codebase-aware autocomplete that understood what you were building.
The PM lesson: wrapping is not a second-class choice. It's first-class when the differentiating value is above the model layer. Cursor's moat was not the model — it was what it fed the model.
What they got right: the TAB behavior
The defining Cursor product decision is what engineers call "Tab." Cursor's autocomplete doesn't just complete the current line — it predicts the next edit, which might be ten lines away. It watches your pattern (you changed a function signature; now it predicts you'll need to update the three call sites), and pressing Tab jumps you to the next predicted edit.
This is a product insight, not a technical one. The key observation: experienced engineers don't think in characters or lines, they think in edit chains. A rename, a refactor, a pattern propagation — these are sequences of related edits across many locations. Copilot completed text. Cursor completed intent.
The eval mechanism that revealed this was also notable. Cursor tracked whether generated code was accepted, deleted, or modified — not whether users said they liked it. Acceptance rate and edit-before-acceptance became their primary quality signals. This is an implicit online eval designed around the actual user behavior, not a thumbs-up.
What GitHub got wrong
GitHub Copilot's original product framing was "AI pair programmer" — an autocomplete layer embedded in VS Code. The framing was accurate but limiting. It positioned Copilot as a text completion tool rather than a coding partner.
Copilot's weaknesses were structural. As a VS Code extension, it was limited in what it could read: the current file, explicitly opened files, and some workspace context. Building deeper codebase indexing required convincing VS Code's extension API to cooperate — architecture that GitHub couldn't change quickly without breaking other extensions.
Cursor built its own editor (a fork of VS Code with the same interface, but with deep codebase indexing built into the foundation rather than bolted on as an extension). This was a significant bet: rebuild a tool engineers use daily, from scratch, when VS Code has near-monopoly adoption. The rationale: the context problem couldn't be solved with an extension. Only an owned editor gave them the surface area to build codebase-aware context at the depth they needed.
The PM lesson: when the product constraint is architectural and your competitor owns the architecture, fork rather than negotiate. This is a two-way door — engineers could switch back to Copilot at any time — but it required Cursor to be good enough to justify the switching cost.
The pricing wedge
Cursor launched at $20/month, the same as Copilot. The differentiation was feature-based, not price-based. This matters because it set the market expectation that AI coding assistance is worth $20-25/month, and the question is which product is better — not who is cheaper.
The product bet was that if the context-quality difference was real and visible in daily use, engineers would pay the same price for the better product. This bet paid off: Cursor's net revenue retention (measuring whether users upgrade their plans and stick around) became a key selling point in the Series B narrative.
The scale surprise
The team's own reporting suggests they were surprised by the speed of growth. Revenue reached $100M ARR in a shorter timeframe than almost any B2B software company in history.
The mechanism: virality through developer word-of-mouth in a market that is both concentrated (most software engineers at any company are in constant communication with each other) and credibility-sensitive (developers distrust marketing and trust peer recommendations). A single senior engineer at a company who switches to Cursor and talks about it in Slack can convert an entire engineering org.
The product implication: in developer tools, the right user to target is not the decision-maker (the engineering manager, the CTO) — it's the influential individual contributor who has the ear of their team. Design the demo for the person who will demo it to their colleagues.
What broke and what was rebuilt
Cursor's codebase indexing, in its early versions, was slow and occasionally incorrect — suggesting code from outdated versions of files, or making context retrievals that confused the model. These retrieval quality issues produced hallucinated function signatures and incorrect API calls.
The response was instructive: rather than hiding the retrieval (as many AI tools do), Cursor made the codebase context partially visible to the user. You can see which files were included in the model's context window. This transparency turned a reliability limitation into a trust feature — users who understand why the model made an error can correct it rather than attributing it to random AI unreliability.
PM takeaway
Three decisions made Cursor:
First: they correctly identified that the moat in AI coding tools was above the model layer (context curation), not in the model itself. This let them stay asset-light on ML while investing heavily in the product layer.
Second: they were willing to pay the architectural tax (building their own editor) rather than accepting the constraint of a plugin model. Most teams choose the faster path. Cursor chose the more defensible one.
Third: they designed their eval system around what engineers actually do (accept, modify, or delete suggestions) rather than what engineers say (thumbs up/down). This gave them a higher-fidelity signal and faster iteration cycles.
The question for any product competing with a platform player is: what does the platform architecture prevent them from building? That's your wedge. Cursor's wedge was the deep codebase indexing that a VS Code extension couldn't do. Find the architectural constraint in your domain and build the fork.