Engineering Lessons from Building Cursor: From VSCode Fork to $500M ARR

Cursor is the fastest-growing AI code editor on the planet right now. It's built by four friends — Sualeh Asif, Arvid Lunnemark, Aman Sanger, and Michael Truell — who met while studying at MIT. They founded a company called Anysphere back in 2022, and here's the number that made everyone pay attention: two years after launch, Cursor crossed five hundred million dollars in annual revenue. That's very likely the fastest any developer tools company has ever hit that milestone.

Now, the team has been unusually open about the engineering behind it — folks like Pragmatic Engineer and ByteByteGo have gone deep on this. So today I want to distill the lessons that actually transfer to your own work. And the theme running through all of them is the same: it's not about which model they picked. It's about the clarity of their tradeoffs.

Let's start with the decision that made everything else possible: forking VSCode.

When Cursor got started, they had a fork in the road. They could build a VSCode extension — the normal, sane, low-risk path — or they could fork the entire editor and own the whole thing. They chose to fork. And their reasoning is really clean.

The problem with the extension route is limits. Extensions live inside a sandbox. You can't reach in and redesign how text selection works. You can't insert truly inline ghost text the way you want. You can't change what happens when a user switches files. The editor gives you a fixed set of hooks, and whatever's outside those hooks is simply off the table. So if your whole product idea is to make the editor AI-native down to its bones, an extension caps how far you can go.

But — and this is the honest part — building an editor from scratch is brutal. A stable code editor quietly solves thousands of hard problems. Unicode handling. Syntax highlighting. Talking to language servers. Rendering fonts correctly across Mac, Windows, and Linux. If you rebuild all of that yourself, you'll burn years before you've written a single line of anything AI-related.

So forking was the middle path. Their conclusion was basically: our value is not in building a stable editor — that's a solved problem — our value is in changing how developers actually program. Forking lets you stand on top of VSCode's stability and pour every ounce of your engineering energy into the AI layer.

And that phrase — "changing how developers program" — is worth sitting with, because it's the real design philosophy. Cursor isn't trying to be fancier autocomplete. It's trying to redefine the relationship between an engineer and their code. You describe intent; the AI fills in the implementation details. You set the direction and you verify the result; the AI iterates. And context stops being just your chat history — it becomes a tool you actively manage.

Okay, let's talk about the feature everyone recognizes: Tab prediction. That's the ghost text that appears as you type, guessing your next edit. And the engineering story here is almost entirely about one thing — latency.

Here's the requirement. The prediction has to land in tens of milliseconds. Not hundreds — tens. Because the moment that ghost text shows up with any lag you can feel, it breaks your typing rhythm. It creates this little cognitive stutter where you're waiting on the tool instead of flowing through your code. So speed here isn't a nice-to-have. It's the whole experience.

And that creates a genuine tension, because there's a tradeoff between how much context you send and how good the prediction is. Send the model more of your surrounding code, and the suggestion gets smarter — but gathering and transmitting all that context takes time. Send too little, and you get fast but irrelevant garbage. So this becomes a dial they're constantly tuning: enough context to be useful, never so much that latency blows the budget.

Picture the actual flow. You type a character. Cursor grabs your local context and checks its latency budget — basically asking, "how much time do I have right now?" If there's room, it sends a richer context; if things are tight, it sends a stripped-down version. Either way, that goes to a small model trained specifically for Tab prediction — not some giant general-purpose model, but a dedicated one tuned for the sweet spot between accuracy and raw inference speed. The ghost text renders. And then one of two things happens: you hit Tab and the code drops in, or you just keep typing and the prediction quietly vanishes. That whole loop has to feel instant.

Now for the most complex piece of the puzzle: Agent Mode. This used to be called Composer, and it's the part that can go off and execute multi-step tasks for you — searching, reading files, running commands. The production lessons here are the juiciest.

Lesson number one, and this is a big one: tool calls have to be trained into the model, not just prompted into it. Early on, the team tried the obvious thing — writing prompts that explain to the model how to use its tools. And it kind of worked for short tasks. But for long-running work, prompting alone just wasn't reliable enough. Think about an operation like search-and-replace: one small mistake and the whole edit is broken. The model needs to have genuinely internalized when to reach for a tool and how to use it. So the fix was training on trajectory data — showing the model, over and over, the correct sequence of tool calls for all kinds of coding situations, until that behavior was baked in rather than bolted on.

Lesson number two: pipelines have a ceiling. Early Cursor ran a fixed sequence — analyze, then plan, then execute, then verify. Clean, predictable, and totally fine for simple tasks. But the moment a task needed the strategy to shift mid-flight, that rigid pipeline hit a wall. And the takeaway is subtle: it's not that pipelines are bad. It's that knowing when you've hit the ceiling matters more than trying to pick the perfect architecture on day one.

Lesson number three ties everything back together: speed is a product feature, not just a performance metric. Not every step needs the biggest, smartest frontier model. So Cursor routes. Simple steps go to a small, fast model with low latency. Complex planning goes to a large, accurate model. By sending all the little stuff to fast models, Cursor's overall responsiveness became an actual competitive advantage — something users feel — rather than a number in a dashboard.

So how does this stack up against the alternatives? Compared to GitHub Copilot and Cline — that's the VS Code extension — the biggest difference is architecture. Cursor is a full fork; the other two are extensions living inside VS Code. On completions, Cursor runs its own custom-trained model, Copilot leans on the GPT-4 family, and Cline depends on whatever external API you point it at. All three have some form of agent mode now, but Cursor's is built in-house and native. And the deepest split is customization: because Cursor owns the whole editor, it can change things at the UI level that an extension simply cannot reach. Copilot and Cline are both bounded by the API surface they're given.

So when is Cursor the right call, and when is it not? It fits beautifully if you want deep AI integration as your everyday environment, if you need an agent to run multi-step tasks, and if you're latency-sensitive enough that you want Tab prediction to feel instant. But it might not be your tool if you depend heavily on a specific VS Code extension ecosystem — some extensions behave differently on the fork — or if you're in an enterprise with strict "code never leaves the device" policies, in which case you'll want to carefully check their privacy mode. And honestly, if all you need is basic autocomplete with no agent, it might be more than you need.

Let me leave you with the three things that really stick.

First: user experience drove architecture, not the other way around. They forked the editor specifically so they could control latency — the product requirement came first, and the engineering decision followed from it.

Second: speed is a feature you can ship. Routing steps by complexity — fast models for simple work, big models for hard thinking — turned responsiveness into something users actively love.

And third, the one that matters most: user trust is the only terminal metric. Offline benchmarks are useful signals, sure, but the real evaluation is whether people keep coming back. One bad agent edit — one moment where the tool quietly breaks your code — can end the relationship for good. Zero to five hundred million in two years wasn't just good models. It was a deep understanding of how engineers actually write code, and what it takes to make AI feel like a collaborator you can trust, instead of a gamble you're taking.