I have a question about Plan Mode. When I click Build, the agent appears to continue using the existing context during implementation. That works for small plans, but not for longer discussions where half of the context window has already been consumed by analyzing pros and cons.
Wouldn’t it be preferable to offer an option to start the implementation with a fresh context? In other words: generate plans that are fully self-contained and detailed enough for a new agent to execute them without relying on prior conversation, and always spin up a clean agent for the actual implementation — similar to how sub-agents work in Claude Code.
You can reference the plan in new session with @ tag? But are the details comprehensive enough, that feels like is up to the model what comes there and probably not compared to the old context.
Whether the plans are comprehensive enough to implement without additional context depends on how the agent generates them by default. There is obviously a system prompt involved that I cannot influence, and at the moment the plans are not truly self-contained. The UI also encourages users to click Build, which reuses the same context. So Cursor appears to recommend using the same context for both planning and implementation.
This differs from most advice I have seen in blogs and forums, and also from my own experience with Claude Code. I am trying to understand the rationale behind this design.
The “plan” generated is never, as far as I’ve seen, an actual plan that can be followed. It’s just a markdown dump of some internal structuring and planning the agent does. The original request and your corrections in the original context are required for the plan to make any sense at all. Until the agents will generate a self-contained plan document from your request, this can clearly never be the case.
I ask Cursor to update the plan so it is standalone and has enough context. I say “Can you add background details we have discussed and information you have found that is relevant to the plan. I am going to share it with my principal developer and I want them to be able to hit the ground running without having to research everything we have just explored.”. I then take the plan into a new session to get a clear context for the build phase. It seems to work reasonably well for me.
This is how I use planning too, or how I intend to despite codegen’s best efforts. We work on a plan for a system, refine the plan, break it up into steps, and start on a multi-day journey of implementation against the plan and refinement of future steps as lessons are learned. The biggest frustration these days (outside of the recent shift everyone made to store these files outside of the repo) is that the AI really wants to put a lot of implementation into this plan, basically guessing at what the code is going to look like and filling the plan document with detail that is irrelevant as soon as the first actual line of code is written.
Being able to actually do architecture exploration with an agent and then committing the actual document (as we have forever with design documents of various flavors) gives us something that is explicitly intended to be acted upon without outside context.
But also why is the button titled “build”? You don’t “build” plans, you “execute” them. It’s kinda scary to push new UI elements in Cursor because you never know what’s going to be a destructive action where the agent gleefully goes on and deletes work that you’ve spent a bunch of time on. (Obvs. source control is usually the answer here but the default behavior of making plans ephemeral makes that less actionable advice.)
@CrunchyBuddy agree - I recently experimented with AWS Kiro - and they have spec driven development as a first class citizen in the design and implementation. It is cool to break the planning down to three formal docs : requirements → design → tasks (but Kiro still has lots of bugs like Cursor did a year or so back). The downside of this model is often in design you realize that a requirement was ambiguous (or missing) and so you end up trying to have the agent update both docs. It can get messy - I think I shoudl be disciplined and ditch the design doc if I change requirements. But good thing is it does not jump from a conversation + plan → build in one. I think there is more Cursor could learn from the AWS Kiro thinking. That said for mid size code changes / refactors plan mode is a great middle ground.
I should clarify here – when someone says they’re going to “build a plan,” it means they’re going to create the plan for action. That’s what initially confused me since I thought that we had been building the plan, what was the button for? I pressed it and it started executing the plan but I honestly believed that I needed to press that button to make it take what we’d laid out and actually build, you know, some other plan that Cursor could work from. (I.e. I was in “planning mode” and we’d been “planning” so I don’t feel like it was a stretch to think “oh, so Cursor now needs to actually build create this plan we’ve been discussing?”)