Planning Before Coding

The assistant predicts plausible code from whatever is in its context. Plausible is the dangerous kind, because it compiles, it reads cleanly, and it can still solve the wrong problem. Without a plan you agree first, you discover that the approach was wrong only after it has been spread across a dozen files, and by then the wrong idea is load-bearing.

Picture a developer who types "add pagination to the orders endpoint" and lets an agent run. The assistant picks offset pagination, because that pattern appears most often in its training and nothing in the prompt steered it elsewhere. Ten minutes later there is a clean diff across the handler, the query layer, two tests, and the API docs. It looks finished. Only in review does the reason it was wrong surface: this table is append-heavy, so offset pagination skips and repeats rows under concurrent inserts. The fix is cursor-based pagination, a different shape entirely. Now the developer is unwinding a confident, well-formatted diff instead of correcting one sentence in a plan.

That is the expensive way to learn the lesson. The cheap way is to read a plan that says "approach: offset pagination" and reply "use a cursor, the table is append-heavy" before a single file changes. Same correction, a fraction of the cost, and the assistant carries the constraint through the whole implementation instead of fighting it afterward.

The payoff compounds with how much work you hand off at once. In 2026 the agents in Claude Code, Cursor, and GitHub Copilot can run for several minutes, edit across files, and run commands without checking in. The longer that uninterrupted stretch, the more it matters that the direction was right when it started. A plan is the one cheap checkpoint that sits before all of that motion. The mechanism that makes it cheap is that plan mode turns the edit tools off entirely, which the next section breaks down.

Planning before coding is one move with three layers of support in the current tools. The durable idea is simple: separate the moment the assistant proposes from the moment it changes your files, and put your judgment in the gap.

• Plan mode is gated at the tool level. In Claude Code, plan mode is a permission mode where reads run but the edit tools are disabled, so the assistant physically cannot modify your source while planning. Cursor Plan Mode and the GitHub Copilot Plan agent work the same way: read-only exploration first, edits only after you approve.
• The plan is a Markdown artifact you can edit. Cursor writes a Markdown plan with file paths and code references. The Copilot Plan agent saves it to .copilot/plans/plan-{title}.md and keeps the chat in sync when you edit the file by hand. Claude Code lets you open the proposed plan in your editor with Ctrl+G before you proceed.
• Approval routes straight into implementation. When you approve a Claude Code plan you choose how it runs: review each edit manually, accept edits as they come, or hand it to a more autonomous mode. Cursor and Copilot hand the approved plan to the Agent to execute the steps.

Two distinctions decide whether your plan is worth the minute it costs. The first is a real plan versus the task restated. A real plan names the files it will touch, the risks, the edge cases, and the tests, so there is something concrete to be wrong about. "I will add pagination to the orders endpoint" is just the request with a future tense. If you cannot find a sentence to disagree with, the plan is too vague to protect you.

The second is planning a single change versus spec-driven development. For a one-off feature, the in-tool plan mode is enough. When the work is large or shared, GitHub Spec Kit treats the spec and plan as a versioned source of truth rather than disposable scaffolding, with a fixed sequence: /specify the intent, /clarify the gaps, /plan the technical approach, /tasks to break it into small ordered units, then /implement. The same spec drives Copilot, Claude Code, Cursor, and other agents, so the plan outlives the chat session that produced it. With the layers named, the next section walks one plan from request to merged code.

A developer named Maya needs to add pagination to GET /api/orders in a real service. The endpoint currently returns every order in one response, which is starting to time out. She has been bitten before by letting an agent run unplanned, so this time she plans first.

1. State the goal and switch to plan mode. Maya presses Shift+Tab in Claude Code until the status bar shows plan mode, then types the goal: cursor-based pagination on GET /api/orders, keeping the existing offset callers working during a transition.
2. Let it research and ask. Plan mode reads src/api/orders.ts and src/db/orders.ts, then asks one clarifying question: should the cursor encode the created-at timestamp or the order id? Maya answers "the id, it is monotonic here."
3. Read the draft plan. The plan names three files, lists the risk that existing offset callers must keep working, and names four edge cases: empty page, last page, invalid cursor, and a duplicate at the boundary. It proposes adding a new query helper rather than rewriting the existing one.
4. Edit the plan. Maya opens it with Ctrl+G. The plan suggested adding a caching layer "for performance." That is off-scope, so she deletes that step and adds one line: "do not add caching, out of scope for this change."
5. Approve and review each edit. She approves with the review-each-edit option. The agent implements the three files as separate diffs. She reads each one, confirms the offset path is untouched, and accepts.
6. Test the named edge cases and commit small. She runs the test suite, which now includes one case per edge case the plan named. All pass. She commits in two steps, the query helper and the handler, each well under 400 lines so the review stays readable.

The whole detour, the caching layer Maya cut, took one deleted line in a Markdown file instead of a review-time argument about scope. That single edit is the difference between planning and not planning, and it is exactly the kind of thing that goes wrong when the plan is skipped or rubber-stamped, which the next section covers.

Each of these traps feels like you are planning while quietly skipping the part that makes planning work.

• The plan that is the task restated. If the plan names no files, no risks, and no edge cases, approving it gives you nothing to push back on. The fix is to demand specifics in the prompt: "list the files before any code, and call out any assumption you are making." If the assistant cannot, the task is underspecified and that is itself the finding.
• Reading without editing. A plan you skim and approve carries the assistant's wrong assumption straight into the code, with a planning step that gave you false comfort. Treat the plan as a draft to mark up. If you found nothing to change, say why, do not just click approve.
• Approving, then not watching. A sound plan still drifts during a long agent run, especially when the agent hits something the plan did not foresee. Review each edit on risky work, and stop the run the moment a diff stops matching the approach you agreed.
• The plan that scopes up. Like Maya's caching layer, agents tend to propose more than you asked: extra abstraction, a new dependency, a refactor "while we are here." Cut it in the plan, where it costs one line, before it becomes code you have to argue about in review.

Then the genuine edge cases. The plan that should have been a question. Sometimes the right move after reading the plan is to stay in plan mode and ask the assistant to compare two approaches with their trade-offs, rather than approving the first plausible one. Plan mode is read-only, so this costs nothing but a round trip, and it surfaces the choice you were about to make implicitly.

The hallucinated dependency. A 2026 wrinkle worth catching in the plan, not the diff: roughly one in five AI samples references a package that does not exist or is not in your project. If a plan proposes pulling in a library, verify it is real and maintained before you approve, because once it is in the code the import looks as legitimate as any other. Catching it in the plan is one comment; catching it after a failed install or, worse, a typosquatted package, is a security incident. Handling these well gets harder once more than one person relies on the same plan, which is where scale comes in.

A plan you hold in your head works for one change you implement yourself. The moment a teammate has to trust the plan, or the work spans more than one session, the plan has to become a durable artifact rather than a chat message that scrolls away.

This is what spec-driven development is for, and why it moved from a niche idea to a default in 2026. Instead of a throwaway plan, a team lead like Priya runs GitHub Spec Kit so the spec and plan are versioned files in the repo. The sequence is fixed on purpose: /specify captures the what and why, /clarify forces the underspecified parts into the open with structured questions, /plan records the technical approach and stack, /tasks breaks it into small ordered units, and /implement executes them. Because the spec is the source of truth and lives in git, a reviewer can read what was agreed, a second developer can pick up the same plan in Cursor or Copilot, and a later change can diff against the original intent.

Two artifacts make planning survive a team. The first is the checked-in plan or spec, reviewed like code. The second is a habit on the implementation side: keep each commit small. Plan-driven agents can produce a large, internally consistent diff in one run, and a 1,000-line diff overwhelms both a human reviewer and an AI reviewer, which then falls back to flagging style. Teams that keep pull requests near 200 lines and under a 400-line ceiling report roughly 30-40% faster review cycles, because the reviewer can actually hold the change in their head. A good plan that lands as one giant diff has thrown away half its value.

Scale also changes how you record the assistant's role. When a plan-driven change reaches review, note in the pull request description that an agent implemented it, which plan or spec it followed, and what you verified by hand. That turns "the AI wrote it" from a shrug into a traceable decision the next reviewer can check.

The durable principle to keep, whatever the size of the work: separate the moment the assistant proposes from the moment it changes your files, and spend your judgment in that gap. Start with one small thing. On your next multi-file change, switch into plan mode, read the plan, and find one sentence to correct before you approve. That single habit is most of the value.