Cursor Replaced 15,000 Lines of Code with 200

There's a particular kind of engineering satisfaction in deleting code. Not the kind where you're removing a bug or cleaning up a mess—the kind where you're removing an entire feature because you found a better way. David Gomes, from the Cursor team, recently experienced this at scale: a pull request that deleted roughly 15,000 lines of code.

The feature being removed? Git worktrees support—a way to let AI agents work in parallel on isolated checkouts of your repository. The replacement? About 200 lines of Markdown.

This isn't a simple optimization story. It's a case study in a fundamental shift happening across AI tooling: replacing deterministic code with probabilistic prompts. And Gomes is refreshingly honest about both why this works and where it falls apart.

What They Actually Deleted

The original worktrees implementation, shipped with Cursor 2.0 in October, was architecturally substantial. It needed code to create and manage worktrees, to feed them into agents as context, to enforce isolation so agents couldn't escape their designated checkouts. There were setup scripts, judging systems to compare different AI models' outputs, harness modifications, cleanup routines for when users spun up hundreds of worktrees and filled their disks.

"We had to make sure that the agents were scoped and isolated and they could not escape the work tree they were working on," Gomes explained. The system physically prevented models from touching files outside their designated areas.

The new approach? Two primitives Cursor already had—skills and sub-agents—plus some carefully crafted natural language instructions. The worktree skill is basically a set of directions telling models how to create worktrees and, crucially, to stay inside them. The "best event" feature (which runs the same task across multiple AI models for comparison) is even simpler: around 40 lines of Markdown instructing a parent agent to spin up sub-agents, give each its own worktree, and synthesize their results.

"It's only around 40 lines of code and it's all marked down. Like it's not even code," Gomes said. "And the previous version of this was maybe 4,000 lines of code."

The Wins Are Real

The benefits go beyond maintenance burden, though that alone matters for a power-user feature that most Cursor customers don't touch. The new implementation actually enables things the old one couldn't.

Users can now switch into a worktree mid-conversation with a slash command, rather than having to configure it upfront. Multi-repo setups—front-end and back-end in separate repositories—now work fine; the agent creates worktrees for each repo and opens separate PRs. The judging experience improved substantially because the parent agent has full context about what each sub-agent did, and can even stitch together pieces from different implementations rather than forcing users to pick one winner.

And perhaps most important for a small team building in a rapidly evolving space: they can iterate on these prompts server-side without requiring users to update their Cursor version. The worktree "skills" are technically implemented as commands, controlled from Cursor's backend specifically for this reason.

The Problem: Trusting Models

Here's where the honesty gets interesting. The biggest issue with the new implementation is that it's—Gomes's term—"vibes based." The old system physically prevented models from working outside their designated worktree. The new system asks them nicely and hopes they remember.

"We're basically saying hey operate on this directory and and and then like you know knock on wood please don't forget about this," Gomes said. "And especially over long sessions it's quite possible that the model will forget where it should be operating."

This manifests differently across models. Haiku, a smaller model, frequently deviates. Composer and Grok do better. But fundamentally, they've traded deterministic constraints for aggressive prompting—and the prompting doesn't always work.

There are other friction points. The feature feels slower because users watch the agent create the worktree in the chat, even though the actual time hasn't changed. Discoverability is worse—the old implementation had a visible dropdown; the new one requires knowing the /worktree command exists.

Cursor's forums reflect mixed reactions. Some users were attached to the old workflow. Not everyone is happy with trading reliability for flexibility.

The Fix: Evals and Reinforcement Learning

Gomes is addressing this the way you'd expect from someone who came to journalism from engineering: systematically. He's building evaluations using Braintrust, running the Cursor CLI headless and scoring whether models stay in their worktrees or stray into primary checkouts. The evals are simple so far—they don't yet simulate the long sessions where models drift—but they're already revealing model-specific patterns.

The longer-term fix is reinforcement learning. Cursor trains its own model, Composer, and Gomes acknowledged that Composer 2 had zero RL tasks involving these worktree prompts. "We didn't have any tasks in all of the many many thousands of tasks that we use for RL actually operating in this type of environment." They're adding them now.

This only improves Cursor's own model, of course. For external models like GPT-4 or Claude, they're sharing feedback with the labs and hoping those teams prioritize similar work.

What This Actually Means

The broader pattern here isn't really about Cursor. It's about a design choice proliferating across AI tooling: moving behavior from code to prompts, from compile-time guarantees to runtime negotiation with language models.

This works when the models are reliable enough and the cost of occasional failure is acceptable. It breaks when the models aren't or the cost isn't. Cursor's worktrees feature sits in an interesting middle ground—it's advanced enough that users probably understand they're working with agents that might drift, but critical enough that drift creates real problems.

Gomes mentioned that Cursor 3.0 will actually take a "small step back" and build a more native, less agent-driven worktrees implementation in the new interface. They're also exploring parallelization primitives that don't use git worktrees at all—something faster, less disk-hungry, and not git-specific.

Which suggests even they recognize that not everything should be prompt-based. Sometimes code is still the right answer. The interesting question is figuring out which is which—and whether that boundary stays fixed or keeps moving as models improve.

Marcus Chen-Ramirez is a senior technology correspondent for Buzzrag.