Claude Code plan mode isn’t a full plan

Cursor says most of its new features now start with its coding agent writing a plan. We sometimes start there too: when something looks small, one of us opens Claude Code, turns on plan mode and starts planning it.

Then it turns out not to be small, and we realize it needs a real plan. So we move the work into Grove, plan it properly there, and go back to the coding agent after that.

Plan mode isn’t the problem. The problem is treating its plan as the plan for your product.

What does Claude Code plan mode actually plan?

The build. The agent reads your code and proposes how to make the change: the architecture, the components to use, the order of the pull requests.

It’s one mode among several. Ask a coding agent to just build the feature and it plans the same way, only out of sight.

What it plans far less is the what and the why. It stops to ask only when a gap is obvious. Everywhere else it picks an answer and keeps going, because it’s built to move fast.

The plan is also single player. It’s written for a developer, in technical terms, and saved on one person’s machine. For a technical plan, that’s fine. For a product, it isn’t.

Why can’t a coding agent decide what to build?

Because the decisions aren’t in your code.

Anthropic’s own guide to Claude Code makes the point: the agent can find most of what’s in your repo, but not “a decision your team made in a meeting.” A new feature is mostly decisions like that: who it’s for, what they can do once it ships, the rules at the edges, and what’s out of scope. Before the build, nobody has made them yet, so there’s nothing for the agent to find.

So it fills each gap with the most likely answer. Andrej Karpathy, who named vibe coding, described it as forgetting “that the code even exists.” Wing it in a coding agent and you forget the product decisions exist too. That costs you twice:

• A generic product. The most likely answer is the average of every product the model has seen. You get that average, not your product.
• Rework. The people who should make those decisions first see them in the pull request. If they’d have decided differently, the work gets redone.

Developers already feel the second one: in Stack Overflow’s 2025 survey, 66% named AI output that’s “almost right, but not quite” their biggest frustration. An assumed product decision is the same, one level up.

We paid for this in August. The coding agent made up the rule for the New, Fix, Rework and Removal chips on our pull request rows: the first verb of a generated sentence decided it. It was the obvious, cheap rule, not the right one, and replacing it took a project of its own and eight more days.

It isn’t always that small, and you can’t get around it by vibe coding a prototype and passing it off as the plan. This summer we handed our developers a prototype of a new navigation and said “just build this.” It took more than a hundred pull requests to make the decisions we’d skipped. More in Why we started Grove and Prototypes are for learning, not for building.

What happens when a small change starts in Claude Code?

In September I asked Claude Code to drop a list from Grove’s Queue page and give it a nicer empty state. It looked like an afternoon’s work.

Then I pulled on a string. The list needed a home on the Work tab, then views people could shape, then a switch between your work and everyone’s, then saved views. Each step looked small.

Two hours in, I saw I was redesigning where everyone finds their work, one prompt at a time. So I stopped and planned it whole, for product and UX, in a Grove project.

The next day I built it in Claude Code. Grove gives the agent the plan and tells it to ask, not guess, where the plan is open. Before writing code, it raised seven questions, each a product decision it would have made for me. On two, I’d have gone the other way.

If it had guessed, every customer would have lost the Your work list on the Queue straight away, while the rest of the redesign was still behind a flag.

I answered all seven in 11 minutes, and every answer went into the plan, not the chat. By the next morning, eight pull requests had been code reviewed by a developer, approved, and merged.

That’s the split we want. People settle the what and the why, in a plan everyone can read. Then the agent plans the how, and it’s very good at it.

How should you use plan mode in a coding agent?

Plan the what and the why first, and agree it with whoever needs to weigh in. Then let your coding agent plan the how. Anthropic’s own guide says much the same: have Claude interview you until it could write the spec, then build from the spec in a fresh session.

1. Plan the what and the why. Who it’s for, what they can do once it ships, the rules at the edges, and what’s out of scope. My PRD template for coding agents has the template we use.
2. Agree it with the people who have to agree, before the build, not in the pull request.
3. Then hand it to plan mode. Point the agent at the plan and let it plan the how. When it asks a product question, the answer goes into the plan, so the next session reads it too.

One thing to try

Next time something looks small, write down three things before you open a coding agent: who it’s for, what they can do once it ships, and what’s out of scope. Then show it to whoever else has a say. If it takes more than a few lines, or they’d change it, it isn’t small. Plan it first.

You can do this in a doc. Or Grove does it with you: it plans the what and the why with your team, and your developers’ coding agents read that plan and ask instead of guessing.