When Cursor launched, the model was simple: fork VS Code, add deep AI integration, ship the result. Windsurf followed with the same approach. So did several smaller editors. The fork was the foundation that made AI-first editing tractable — VS Code’s ecosystem of extensions, language servers, and themes came along for free.
That foundation is becoming a liability. The next generation of AI editors won’t fork VS Code. The reasons are more interesting than they look from the outside.
Why the fork made sense in 2023
In early 2023, building an editor from scratch was a multi-year project before you could even start shipping features. Forking VS Code:
- Gave you a complete editor on day one
- Inherited tens of thousands of extensions
- Brought along the LSP ecosystem
- Came with battle-tested terminal, debugging, and source control integrations
- Had a UI users already knew
You spent your engineering budget on the AI integration, which was the differentiator. The plumbing was already done.
For Cursor specifically, this was the right call. The product-market fit came from “VS Code with much better AI,” and the fork was how you got there in months instead of years.
Why the fork is becoming a problem
Three forces have shifted the calculus:
VS Code’s pace is slow for AI-first features. Microsoft moves at corporate velocity on the editor. AI-first features sometimes need editor primitives that don’t exist in VS Code. Cursor has spent significant engineering time patching around VS Code’s limitations — adding new keybindings the upstream wouldn’t accept, modifying the chat panel beyond what extensions can do, working around extension API limits.
Each patch is debt. When VS Code releases a major update, the fork has to merge it. The accumulated patches make the merges progressively more painful.
The extension model is wrong for AI. VS Code’s extension API was designed for IDE features (linters, debuggers, language servers). AI-first features want different primitives — context provision, model routing, agent tool calls. Adapting AI features to fit the extension API is awkward.
This is why Zed bet on a different extension model entirely. WebAssembly extensions with first-class AI primitives fit the use case better than Node.js extensions retrofitted with AI capabilities.
The maintenance overhead grows. A fork has to maintain compatibility with VS Code’s evolving APIs while adding its own. Cursor’s team has done this well, but the cost compounds. Every VS Code feature is something the fork must consider, even if the fork’s users don’t care about it.
What the post-fork generation looks like
Three patterns are emerging:
Build from scratch with modern primitives. Zed is the leading example. Built in Rust, with a custom rendering engine, custom extension model, custom collaboration. The investment is huge — multiple engineering years before they could ship comparable features to VS Code. The payoff is: when they want a new primitive (collaborative cursors, AI panel, slash commands), they can build it. They don’t have to fight an upstream that didn’t anticipate the use case.
Build on a different open-source base. Some editors are forking JetBrains’ open-source IDE platform instead of VS Code. JetBrains’ platform has different tradeoffs — slower than VS Code, but with deeper hooks for IDE intelligence. For AI-first IDE-shaped features (like agent loops with deep code understanding), this is appealing.
Build the “editor” as a different shape. Cline runs inside VS Code as an extension but the experience isn’t editor-shaped — it’s chat-shaped with file editing as a side effect. Cursor’s chat panel pushes in this direction too. Some teams are skipping the editor entirely and building “AI development environments” that have an editor as one of several panels. The editor is no longer the center.
What VS Code is doing about it
Microsoft isn’t sitting still. GitHub Copilot is increasingly integrated with VS Code in ways extensions can’t replicate. The Copilot Workspace experience is built into the editor, not bolted on via extensions. Microsoft has the advantage of controlling the platform and can build deep integrations that competitors can’t match.
This is the biggest pressure on the fork model. If Microsoft is going to keep adding AI integration that only works in their version of VS Code, the fork’s “VS Code with better AI” pitch loses its edge. The fork has to add features that compete with Microsoft’s own integration.
So far, Cursor has done this well — Composer, Tab, BugBot all add things VS Code’s Copilot doesn’t have. But it’s a treadmill, and Microsoft has more engineers.
What this means for users
For users, the fork-era pattern produced rapid AI editor improvement. The next era will produce different things:
More differentiation. Editors built from scratch will look and feel different from each other in ways VS Code forks couldn’t. Zed already feels different from Cursor in ways that aren’t just AI. The next generation will continue that.
Less interop. VS Code’s extension ecosystem was a massive interop benefit — your extensions worked across forks. As editors diverge from the VS Code base, extensions don’t port. You’ll pick an editor and live in its ecosystem.
More specialization. Editors will optimize for specific workflows. AI-first agent editing is one shape. AI-first review and analysis is another. Code-from-scratch ML and notebook work is another. The “general purpose AI editor” may give way to specialized tools for specific kinds of programming work.
Slower feature parity. When Microsoft ships a Copilot feature, it shows up in VS Code immediately. Forks had to merge it. Editors built from scratch don’t even have that path — they have to rebuild the feature from concept up. The competitive race becomes more uneven.
Where the bets are
If I had to predict which strategies will win in the next few years:
Zed. Built from scratch, first-class AI, faster than VS Code, smaller surface area. The bet pays off if AI-first editing is meaningfully different from traditional editing — and so far it is.
Cursor. The fork bet is paying off now and will keep paying off for a few more years. The risk is the long-term maintenance cost and Microsoft’s increasing pressure on the integration story.
Windsurf. Smaller scale than Cursor; competing on agentic capabilities (Cascade and Flows). The fork is sustainable for now; the question is whether the agentic differentiation holds.
The unannounced editor from a major lab. I’d be surprised if neither Anthropic nor OpenAI has an editor in development. If one ships, the post-fork generation gets another data point.
What I’d build if I were starting today
If I were starting an AI editor in 2026, I would not fork VS Code. The maintenance cost over a 5-year roadmap would dominate the engineering budget. Building on a smaller base — Zed-style from scratch, or on a smaller editor like Helix or Lapce — would be the right tradeoff.
The lost ecosystem matters less than it used to. AI assistance covers a lot of what extensions used to cover. Language support comes from LSPs that are editor-agnostic. The primary thing extensions provided — features the editor’s developers didn’t build — is becoming features the AI provides.
The fork era was a smart shortcut for a specific moment. That moment is closing. The shape of AI editors is changing, and the fork won’t fit the new shape as well as it fit the last one.
