A bad plan is worse than no plan at all

Fourteen percent of the session is still your job

On 9 June 2026, a product manager asked Cursor to add a tag to 87 backlog items and went into a meeting. The agent spent that hour in a loop: ClickUp search, get task, filter tasks, get custom fields, over and over. It had consumed, in the poster's words, “1.3 billion tokens. To tag tasks.” The billing page tells the rest: “Every other day that month sits between $2 and $25. June 9th: $1,382.59.”

Everybody quotes the first half of the proverb. Fail to plan, plan to fail. In 2026 somebody measured the second half: planning badly is also planning to fail. If you have spent this year generating spec documents, that margin has your name on it.

In June 2026 Anthropic published an analysis of roughly 400,000 Claude Code sessions from about 235,000 people, spanning October 2025 to April 2026. Planning or exploring accounts for 14% of that work. The rest is fixing broken code (26%), writing new code (25%), operating software (17%), prose and analysis (13%), and testing and orchestrating (5%).

Across those sessions, “people make about 70% of the planning decisions but only 20% of the execution decisions.”

Session spent planning

14%

Planning or exploring, across roughly 400,000 sessions from about 235,000 people.

Planning decisions made by the human

70%

The phase where your judgement still moves the outcome.

Execution decisions made by the human

20%

The phase where it mostly does not. Anthropic is measuring its own product.

Read that carefully, because it is easy to inflate. It does not say most of your decisions happen while planning. It says planning is where you are still deciding, and execution is where you have mostly stopped. The rest has been delegated, whether you meant to or not. Anthropic is measuring its own product here, but it remains the largest public dataset on how this work decomposes.

Dex Horthy of HumanLayer put the working heuristic to Gergely Orosz in July 2026: “Find out where an hour spent in planning could save four hours' worth of implementation, in terms of fewer bugs.”

Which plan, and how much

In April 2026 a team published an evaluation of plan compliance in programming agents: 16,991 SWE-agent trajectories, four different LLMs, SWE-bench Verified and SWE-bench Pro, eight plan variations. They call it “the first extensive, systematic analysis of plan compliance in programming agents”.

“Providing the standard plan improves issue resolution, and we observe that periodic plan reminders can mitigate plan violations and improve task success.” Without a plan, agents “fall back on workflows internalized during training, which are often incomplete, overfit, or inconsistently applied”.

From the same abstract: “augmenting a plan with additional task-relevant phases in the early stage can degrade performance, particularly when these phases do not align with the model's internal problem-solving strategy.” Note the conditional. Even relevant additions can hurt, especially where the new phases cut across how the model already prefers to work.

There are three options here, not two. A good plan, no plan, and the thing most teams are shipping: a long plan generated by the same model that will execute it, skimmed by a human in forty seconds, and approved.

Never plan before you have read the code

In March 2026, Orit Shahnovsky and Rotem Dror published a planning framework for web agents that maps agent architectures onto classical search: step-by-step agents behave like breadth-first search, full-plan-in-advance agents like depth-first search. Then they compared the two across 794 human-labelled WebArena trajectories.

The full-plan agent won on precision, hitting 89% element accuracy. The step-by-step agent won the thing you care about, “aligning more closely with human gold trajectories (38% overall success)”. Those are two different yardsticks, and the plan-first agent took the one that matters less. Commit to a full route early, and when reality diverges on step three you spend the remaining steps executing a beautiful plan for a different problem.

This is a web-browsing benchmark rather than a coding one, so treat it as a statement about plan-first architectures generally, not a measurement of your Tuesday. Move the plan later.

The most-upvoted piece of planning advice on Hacker News this half-year is Boris Tane's How I Use Claude Code, from February 2026, which hit 976 points. He makes the agent read the relevant subsystem in depth and write its findings to a research.md he then reviews, before planning is allowed to start. His reason: “If the research is wrong, the plan will be wrong, and the implementation will be wrong.”

The most expensive failure mode, he writes, “is not wrong syntax or bad logic. It's implementations that work in isolation but break the surrounding system.”

The annotation cycle is the actual skill

Research, plan, annotate, implement. Four checkpoints, and a human gets to say no at each one.

Tane's core rule: “never let Claude write code until you've reviewed and approved a written plan.” He opens the generated plan in his editor and writes inline notes into the document: “no — this should be a PATCH, not a PUT”, or “the queue consumer already handles retries, so this retry logic is redundant”. Then he sends the agent back to revise. That cycle “repeats 1 to 6 times”, and every round carries an explicit guard: don't implement yet.

“The markdown file acts as shared mutable state between me and Claude.” A chat log is something you scroll; a plan is something you can point at.

“I want implementation to be boring,” Tane writes. It can be, because the creative work already happened during annotation.

A developer in the same thread itemised an audit-logging feature: “It took maybe 5-10 minutes of wall-time to come up with a good plan, and then ~20-30 min for Claude implement, test, etc.” Counting his own testing and review, “maybe 30-45 minutes of my actual time to add a small feature”, on something that “would've taken me at least a day, maybe two.”

A developer on r/ExperiencedDevs in April 2026, in a 273-upvote post, described the loop that follows: “I generate a spec, then I argue with it, poke holes in it, point out flaws, architect it myself. Once it's workable I implement the skeleton by hand.” As implementation surfaces new flaws, they go back into the document, until “eventually the spec becomes the documentation of the feature itself.”

Plans have a weight limit

The same six months produced a pile of evidence that the spec frameworks got fat.

A 473-point Hacker News thread in March 2026 settled it for one developer, who compared the heavyweight frameworks against a stripped-down alternative and came away “convinced that less is more”: the heavy version “performed well, but took hours instead of minutes”, while “a simple explanation of how to create a PRD followed by a slightly more technical task list performed much better.” Another, in the same thread, dropped the frameworks entirely for plain plan mode: “they burn 10x more tokens, in my experience. I was always hitting the Max plan limits for no discernable benefit in the outcomes I was getting.”

An April 2026 study of token consumption across eight frontier models on SWE-bench Verified found that “runs on the same task can differ by up to 30x in total tokens, and higher token usage does not translate into higher accuracy; instead, accuracy often peaks at intermediate cost and saturates at higher costs.” It measured total spend rather than spec length, so it will not tell you how long your plan should be.

In July 2026 Anthropic reported: “We removed over 80% of Claude Code's system prompt for models like Claude Opus 5.”

The most concrete answer anyone has published on sizing came from a commenter under Tane's post in February 2026, who runs explicit budgets:

• 1,000 lines of spec per 10,000 of codeAnd no single spec file over 300 lines, so each one stays reviewable in one sitting.
• Plans of 100 to 300 linesAcross three to five phases. Long enough to sequence the work, short enough to argue with.
• A 30-line status fileWorking memory that points at the current plan, compacted as the project moves.

Those are somebody's personal numbers, not a finding.

The primitive is the decision, not the plan

The strongest case against all of this does not claim planning is worthless. It claims the approval gate is in the wrong place.

In May 2026, the team behind the Graphcoder agent published Plan mode is a crutch, an information-theoretic argument that treats code generation as entropy reduction and asks where in that process a human should be interrupted. Their verdict: “the limit of plan mode is temporal and structural. It asks too early and too globally, bundling many future decisions into one initial review before the agent knows where communication would be most valuable.” Worse, “plan mode overloads attention by concentrating many decisions into one review”. Their fix is to stop asking permission up front and interrupt the human only where guessing wrong gets expensive. They sell an agent built on that idea, so weigh it accordingly.

Their conclusion: “The primitive is the decision, not the plan.”

An April 2026 r/ExperiencedDevs post inverting the industry advice put it plainly: “it's really hard to think about all the nuances and caveats ahead of time, and its not until I see something start to come together where I realize I need to think about things differently. Any ambiguity and the LLMs fills in with assumptions (or hallucinations).” Their solution is to have the model generate the plan and do the implementation themselves.

Tane does not use plan mode either. “I use my own .md plan files rather than Claude Code's built-in plan mode. The built-in plan mode sucks.” The artifact is load-bearing; the ceremony is not.

Which leaves Graphcoder's point standing, because a markdown plan approved once is also a single global gate. Tane does not approve his once. He reopens it one to six times, each round triggered by something he noticed. That is a decision stream wearing a plan's clothes.

What a plan cannot buy you

Three things planning will not fix: two reported from the field this year, one measured at scale.

It will not fix your review culture. A developer on r/ExperiencedDevs in May 2026 had the full apparatus: “skills written that plan the feature, analyse existing codebase, subagents that guard quality of code, compliance with a spec etc.” They still had to “sift through 3000 lines of code, only to discover, it's all slop.” The constraint was the incentive: “my 500 lines of good code written in 3 days will look worse on paper than 2000 lines of slop written in one day.”

It will not encode context you never wrote down. In a May 2026 post at 181 upvotes, a candidate was rejected from a take-home despite feedback that said “technically strong”: “the architecture choice, while valid, does not align with how our team structures data pipelines.” Their protest: “i was not given the team's patterns. i was given a problem spec and three days.” Your agent is in the same position on every task, and unlike the candidate it will not complain.

And it will not fix the review queue at the other end. LinearB, who sell engineering analytics and should be read accordingly, published an analysis of 8.1 million pull requests across 4,800 teams in May 2026.

LinearB does not say how it classifies a PR as AI-generated, or whether the two piles are comparable in size. PR size alone would explain a lot of that gap.

The proverb was always half a sentence. The other half costs more: a plan you did not think about is worse than the one you never wrote. Read the system before you write anything. Plan second, and stop well short of the length that makes you feel productive. Argue with the draft until it stops being generic, then let the boring part be boring.

Fourteen percent of your session, and the part where you are still the one deciding. Spend it like the other 86% depends on it.