A month ago we wrote about how Cursor sits at the center of our build process: specs in, working features out. Last Wednesday Cursor shipped version 2.0, and it changes the shape of that process more than any release since we adopted it. The editor is no longer the main event. Agents are.
This post covers what actually changed, how we are folding it into Takeoff & Climb on client builds, and where we are keeping our hands on the controls.
What Shipped
Cursor 2.0 landed on 29 October with a long changelog. The pieces that matter for how we build:
- Composer, Cursor's first in-house frontier coding model. Cursor's claim is that it is four times faster than similarly capable models and finishes most turns in under 30 seconds.
- An agent-first interface. The default view is now a list of agents and what they are doing, with the files and the classic IDE layout one click away.
- Up to eight agents in parallel on a single prompt, each working in its own git worktree or on a remote machine so they cannot step on each other.
- A browser tool, now generally available and embedded in the editor, so an agent can open the app it just changed, click around and fix what it finds.
- Sandboxed terminals, on by default on macOS. Commands get read and write access to the workspace and no internet access.
- Plan mode that lets you plan with one model and build with another.
- Team commands and rules pushed from the dashboard to every seat, plus voice input.
Cursor also renamed Background Agents to Cloud Agents and deprecated Notepads. If you kept notes in Notepads, move them now.
Speed Versus Smarts
The interesting decision inside 2.0 is Composer. Cursor built a model optimized for latency rather than for topping benchmarks, and it is honest about that trade. Composer is meant to be the model you use for the fifty small turns that make up a feature, not the model you use to design the feature.
That matches how we already split the work. The thinking happens up front, in the Flight Plan and in a written spec. The implementation is many short, well-defined steps. A model that returns in twenty seconds instead of two minutes changes the rhythm of a working day when you are doing hundreds of those steps.
We have not benchmarked Composer ourselves yet. The 4x figure is Cursor's, measured against models it chose. What we can say after a few days is that for spec-driven implementation on a codebase it already knows, it is fast enough that waiting stops being the bottleneck. Reviewing does.
Eight Agents, One Spec
Here is the part that matters most for client work.
Every Flight Plan produces a phased roadmap. Phase one is usually six to ten features that can be built independently: authentication, the data model, a billing hook, the first screens. Until now we worked through those mostly one at a time, because one editor and one agent meant one feature in flight.
Worktrees change that. A git worktree is a separate checkout of the same repository in its own folder. Cursor 2.0 gives each agent its own worktree, so eight agents can work on eight features without touching each other's files. When one finishes, its branch is ready to review and merge.
In practice we run it like this during Takeoff & Climb:
- Pick the roadmap items for the fortnight and write a spec for each one, the same specs we described in our spec-driven development post.
- Start one agent per spec. Three or four at a time, not eight. More on that below.
- Let each agent build, run the tests and use the browser tool to check its own screens.
- Review each branch as it lands, merge, and repeat.
The fortnightly demo we promise every client now has a natural shape. The features that finished are the demo. The specs that did not are next fortnight's list.
The Browser Tool Closes the Loop
The single most useful change is not speed. It is that the agent can now see what it built.
Before 2.0, an agent would write a component, report success, and we would open the app and find the button rendered off the edge of the screen. Now the agent opens the page in the built-in browser, selects the element, notices the problem and fixes it before it tells us it is done. Cursor calls this iterating. We call it the agent doing its own smoke test.
It does not replace real QA. It does remove a whole category of "did you actually look at it" review comments.
Sandboxed Terminals and Why We Turned Them On
Agents run shell commands. Installing packages, running tests, starting the dev server. That is where the risk lives, and until now our answer was to watch closely.
The sandbox in 2.0 gives an agent's terminal access to the project folder and nothing else, with no network. An agent cannot accidentally push to production, cannot leak an environment file, cannot run a script that reaches out to a server it should not. If a command genuinely needs the network, it asks.
For client work this is close to non-negotiable. We now enable it on every repository and treat any request to leave the sandbox as a review event.
Where We Are Keeping Our Hands on the Controls
A few honest caveats after a week with it.
Eight agents means eight reviews. The bottleneck moves from writing code to reading it. Three or four agents is the number where one engineer can still hold every branch in their head. Beyond that, quality drops because review does.
Agents can disagree. Two agents building against the same data model will make different assumptions unless the spec pins them down. This is an argument for better specs, and for building shared foundations first, alone, before fanning out.
Cursor's "try several models on the same problem" trick costs tokens. It works. It also multiplies your bill by the number of attempts. We use it on the gnarly problems, not on every feature.
Composer is new. We are still deciding which turns it handles well and which need a bigger model. Plan mode makes this easy to tune: plan with the stronger model, build with the faster one.
What This Means for Your Build
If you are a founder, the practical change is that the calendar of a build looks different. A phase that was eight sequential weeks can become eight parallel branches across two or three fortnights, provided the specs are good enough to keep the agents honest.
That "provided" is doing a lot of work. The tools are getting faster than the thinking. A clear roadmap and precise specs are now worth more, not less, because they are what eight agents execute against.
Ready to Fly the Roadmap in Parallel?
At Dev Force One, the Flight Plan produces the roadmap and the specs, and Cursor 2.0 is how the crew turns them into working software in fortnightly increments.
What that means for you:
- A faster Takeoff & Climb: several roadmap items built at once, not one after another
- A demo every fortnight: agents finish features, we review them, you see them
- Guardrails from day one: sandboxed agents and reviewed branches on every client repository
Ready to see what your roadmap looks like in parallel? Book a Pre-flight call and let's talk about your build.