Open the Hood: Why Almost Every AI Code Editor Is Secretly the Same Editor

If you went looking for an AI code editor this year, you probably came back dizzy. Cursor. Windsurf. Google’s Antigravity. IBM’s Bob. A new one seems to launch every few weeks, each with its own logo, its own pitch, its own army of fans insisting it is the only real choice. It feels like walking into a phone shop where every box promises something completely different.

I want to let you in on the secret that makes all of this suddenly simple. If you pop the hood on almost every one of these editors, you find the exact same engine sitting inside. Once you know that, you stop seeing a dozen mysterious rivals and start seeing one familiar thing, dressed in different clothes. Let me show you the engine, and then show you what actually makes them different, because the real differences are more interesting than the marketing.

The shared secret: it is all VS Code

Here is the engine. Microsoft makes a free, open-source code editor called Visual Studio Code, or VS Code for short. It is, by a huge margin, the most popular code editor in the world. Crucially, it is open source, which means anyone is allowed to take its entire codebase, make a copy, and build their own thing on top of it. That copy is called a fork.

And that is exactly what happened. Cursor is a fork of VS Code. Google’s Antigravity is a fork of VS Code. IBM’s Bob is built on VS Code. Even the tools that are not full forks, like Windsurf, plug into VS Code and editors like it. The familiar editor you already know is hiding inside nearly all of them.

The family tree. One open-source editor at the root, many descendants. The solid lines are full forks (they copied VS Code and changed it). The dashed line is the plugin approach (it adds itself into VS Code without forking). Different relationships, same ancestor.

This is not a dirty secret, by the way. It is a smart, normal thing to do. Building a great code editor from scratch takes years: the syntax highlighting, the file explorer, the extensions, the git integration, the thousand tiny things you never think about until they are missing. Why rebuild all of that when an excellent, free, battle-tested version already exists? You take VS Code, you keep all the parts developers already love, and you spend your energy on the one part that is actually new: the AI.

So what is actually different?

If the editor underneath is the same, then the differences must live somewhere else. They do, in two places that are bolted on top.

the brain (the new part)an AI model + how the tool uses it

the wiring (the clever part)how the AI reaches your files, terminal, browser

the body (the shared part)VS Code: editing, files, extensions, git

The three layers of basically every AI editor. The bottom is shared by almost all of them. The middle and top are where each tool makes its bets, and where all the personality lives. When people argue about which editor is best, they are really arguing about the top two layers.

Think of it like cars. Underneath, a huge number of cars share the same chassis and engine block from the same supplier. What you actually feel as a driver is the steering, the seats, how much the car does for you versus how much you do yourself. AI editors are the same. The chassis is VS Code. The driving experience is the AI layer. And the single biggest difference between them is one question: how much is the AI allowed to drive?

The one idea that explains all of them: how much does the AI drive?

This is the heart of it, so let me build it carefully. Every AI editor sits somewhere on a spectrum, from “the AI quietly suggests, you do everything” all the way to “you describe a goal and the AI goes off and does it.” Drag the slider below and watch the style of help change.

AI suggestsAI assistsAI drives

The autonomy spectrum. This single dial is the most useful way to tell AI editors apart. It is not about which is "best." It is about how much control you want to hand over, which depends entirely on what you are doing.

Notice the trade as you slide right: you gain power and speed, but you give up fine control, and you have to trust more. Slide left and it flips: less power, but you see and shape everything. There is no universally correct spot on this dial. The right answer changes by the hour depending on whether you are carefully fixing a payment bug or quickly scaffolding a throwaway prototype.

Where each editor sits, and why

Now the fun part. With that one dial in mind, the whole confusing landscape lines up neatly. Each tool picked a philosophy and built around it.

Editor	Built on	Its bet
Cursor	VS Code fork	Polished, fast, AI baked deep into the editor. Strong predictive edits plus an agent when you want it. A smooth all-rounder.
Windsurf	plugin, not a fork	Works inside many editors instead of being one. The bet: meet developers where they already are, across 40-plus tools.
Antigravity	VS Code fork	Agent first. A control room to spawn and watch multiple agents, which produce visible plans and screenshots so you can check their reasoning.
IBM Bob	built on VS Code	Aimed at big companies and old codebases: legacy modernization, compliance, structured plan-code-review modes for serious enterprise work.

Same body, different bets. Some chase polish, some chase reach, some chase autonomy, some chase the enterprise. None of them reinvented the editor, because they did not need to. They competed on the layers that matter.

Look at how little of each tool is actually new. The vast majority of every one of these editors is just VS Code that someone else already built. The thin slice on top, the AI brain and its wiring, is the entire battleground.

Illustrative, not exact percentages. The grey is the editor everyone shares. The accent slice is the genuinely new part each company built. When you pick an editor, you are mostly choosing that thin accent slice, plus a philosophy about how much it should drive.

Why fork at all? And why did Windsurf not?

You might wonder: if VS Code already supports extensions, why copy the whole thing instead of just writing a plugin? It comes down to how deep you want to reach.

A plugin lives in a guest room. It can do a lot, but the house has rules, and some doors are locked. When a company forks VS Code, they own the whole house. They can wire the AI into the deepest parts of the editor, the parts a plugin is never allowed to touch, which lets them build smoother, more powerful features. That is why Cursor and Antigravity forked: they wanted those locked rooms.

Windsurf made the opposite bet on purpose. By staying a plugin, it gives up those locked rooms, but in exchange it can live inside dozens of different editors, not just one. Less depth, much more reach. Neither choice is wrong. They are answers to different questions, and seeing the trade-off is the whole point.

What this means for you

So here is the payoff, the thing I hope you carry away. The next time a new AI editor launches with a slick video and bold claims, you will not feel lost. You will quietly ask three questions, and they will tell you almost everything.

First: is it built on VS Code? Almost certainly yes, which means the editing experience will feel familiar and you are really evaluating the AI, not the editor. Second: where does it sit on the autonomy dial, from gentle suggestions to a fully driving agent? That tells you how it will feel to use day to day. Third: what is its bet, polish, reach, autonomy, or the enterprise? That tells you who it is really for.

The flood of new editors stops being intimidating once you realise they are variations on a theme you already understand. Same engine, different drivers. You are not choosing between a dozen alien spaceships. You are choosing how much you want the AI to take the wheel, in an editor you already know how to drive.