The idea
A coding agent can inspect a codebase and change files in the same request. That is convenient, but it combines two different jobs: understanding the problem and modifying the system. If its understanding is wrong, you may only notice after it has edited several files.
Plan before code separates those jobs. First, ask the agent to inspect the repository and write an implementation plan. You review that proposal. Only then do you ask it to make the changes.
This is not a claim that planning makes an agent correct. It gives you an earlier, visible checkpoint. You can spot an irrelevant file, an overly broad change, or a missing test while the result is still a proposal rather than a set of edits.
Plain English: Ask the agent to show its intended route before you let it drive the code change.
Some tools support this workflow directly. Claude Code documents plan mode as a mode that reads files and proposes a plan, but does not make edits until the developer approves. Its documentation presents this as a way to review changes before they touch disk. Claude Code documentation
GitHub documents a similar sequence for Copilot cloud agent: research the repository, create and refine a plan, implement changes on a branch, then review the diff. GitHub Docs The precise interface differs by tool. The underlying habit does not: review the approach before requesting the edit.
A useful plan answers concrete questions:
- Which files does the agent think matter?
- What does it believe the current behavior is?
- What small changes does it propose?
- Which assumptions need confirmation?
- Which existing tests or new regression test should check the change?
A ticket tells the agent what outcome you want. A plan explains how it thinks this particular repository can reach that outcome. Those are different artifacts, and reviewing both is valuable.
A small example
Example: A TypeScript web application accepts expired sessions. Start with a narrow request: investigate the session flow, identify the relevant files, explain the likely cause, and propose a small plan. Explicitly say not to edit files yet.
The agent might identify session middleware, token-validation code, and an existing authentication test suite. Its plan might propose changing one expiration check and adding a test for an expired token.
Now review the plan, not just its confidence. Does the identified middleware actually run for the affected route? Does “expired” have the intended meaning in this application? Is the proposed test at the same layer as the bug? If the scope looks wrong, ask for a revised plan. If it looks right, approve implementation of that limited plan.
Afterward, inspect the diff. Confirm that the changed files match the approved plan and that unrelated refactoring did not enter the patch. Run the relevant project checks. GitHub’s documented workflow includes reviewing the diff and iterating before creating a pull request. GitHub Docs
Try it
Set aside five minutes for a low-risk task, such as tightening one validation rule or adding one missing test.
- Ask the agent to investigate only. Request relevant files, current behavior, assumptions, a minimal plan, and checks to run. State that it must not edit yet.
- Compare the plan with your own knowledge of the code. Correct the file list, acceptance criteria, or test idea if needed.
- Approve only the revised, small scope. After implementation, inspect the diff and run the checks the plan named.
This exercise is deliberately small. The goal is to practise separating investigation, approval, implementation, and verification—not to delegate a redesign.
Watch out
A plan is a proposal, not evidence. It can misunderstand requirements, miss hidden dependencies, or name the wrong files. Plan mode also does not prove that the later code is correct, secure, or fully tested.
Do not turn approval into a ritual. Read the plan closely enough to challenge its assumptions. Then review the implementation independently: inspect the diff, run appropriate tests, and assess whether the behavior meets the requirement.
Finally, do not assume every assistant behaves like Claude Code or Copilot cloud agent. Commands, approval boundaries, branch behavior, and availability are tool-specific. Claude Code’s documented plan mode and GitHub’s documented cloud-agent workflow are examples of this pattern, not a universal guarantee. Claude Code documentation GitHub Docs