Use Plan Mode Before Edits Start

Claude Code plan mode has become popular because it gives developers a way to ask for analysis before execution. Instead of immediately editing files or running commands, the agent first maps the work. For serious codebases, that planning step can be the difference between useful delegation and a branch you have to unwind.

Junction brings that idea into a broader control workflow for local AI coding agents. You can start Claude Code or Codex from a browser or phone, monitor the output stream, approve or deny actions, review diffs, and keep the agent running on the machine where the code already lives. Plan mode fits into that loop as the "show me the approach first" step.

This post explains when to use plan mode, how it relates to approvals, and how teams can make it part of Switchboard routes for issue-to-pull-request automation.

What plan mode is for

Plan mode is for work where the shape of the solution matters before the first edit.

Use it when:

• The task touches shared abstractions.
• The implementation may affect auth, billing, data flow, or permissions.
• The issue is underspecified.
• The agent needs to inspect several files before choosing an approach.
• You want to compare options before approving execution.
• The work will become a pull request that reviewers need to understand.

Do not use it as a ritual for every tiny change. If you need a typo fixed in one file, plan mode may add ceremony without reducing risk. If you need a database-facing refactor, it is cheap insurance.

Plan mode is not the same as approval prompts

Approvals usually happen when an agent wants to do something specific: run a command, edit a file, access a tool, or perform an action that requires user confirmation.

Plan mode happens earlier. It asks the agent to reason about the work before it starts making changes.

Claude Code's permission documentation describes plan mode as a mode where Claude can analyze but not modify files or execute commands. That gives the developer a chance to review the proposed approach before allowing edits. In Junction, the same idea is useful because you may be supervising from a phone or browser rather than sitting in front of the terminal.

The difference is simple:

Strong workflows use all three at different moments.

A practical plan-mode prompt

A good planning prompt asks for the implementation shape, risks, and validation steps. It does not ask the agent to solve everything in prose.

Start in plan mode.
 
Investigate why the route settings page sometimes enables automation without a watched status.
Do not edit files yet.
 
Please identify:
- the files you expect to touch
- the likely state or validation bug
- the smallest safe fix
- the tests or typechecks that should run
- anything that needs human confirmation before execution

That prompt gives the agent a job: inspect, map, and report. After the plan is clear, you can approve the execution step, adjust the scope, or stop the run before it writes code.

Why Junction makes plan mode more useful

Plan mode is most useful when you can act on the plan quickly. A terminal-only workflow can work well at a desk, but it is less convenient when you are away from the machine running the agent.

Junction changes the ergonomics:

• The daemon runs on the local machine with the repo.
• The browser or phone is the control surface.
• Agent output streams in real time.
• You can stop or steer a run if the plan is wrong.
• Approval and diff review stay in the same workflow.
• Multiple daemons can keep their own provider auth and model setup.

That means a planning pass does not have to wait until you return to your desk. You can open Junction, review the proposed approach, and decide whether the agent should proceed.

Use route-level plan mode for Switchboard

Manual chats are not the only place plan mode helps. Switchboard route settings can start new runs in plan mode for Claude Code and Codex routes. That is useful when Linear issues become automated agent runs.

For example, a team might configure:

Route-level defaults reduce reliance on individual memory. If a repository is risky, the route can start with planning every time. If a route is intentionally low-risk, the team can keep it direct and rely on tests and review.

This is especially important for 24/7 automation. Switchboard can watch Linear statuses and start issue-to-pull-request work while you are away. Plan mode gives teams a way to require a visible planning step for selected routes instead of letting every issue move straight into edits.

What to look for in the plan

Do not approve a plan just because it sounds confident. Look for specifics.

A useful plan should include:

• File paths or modules the agent expects to inspect or edit.
• The behavior it thinks is wrong.
• The smallest change that would fix it.
• Tests or commands it will run.
• Known risks.
• Explicit assumptions.
• A stopping point if the assumptions are false.

Weak plans usually look like:

• "I will inspect the codebase and fix the issue."
• "I will update the relevant files."
• "I will make improvements and run tests."
• "I will refactor for better maintainability."

Those are not plans. They are intentions. Ask for a sharper plan before letting the run continue.

Plan mode and local-first execution

Junction's local-first architecture matters here. The planning discussion happens through the app, but the agent process still runs through the daemon on your machine. Your repo, worktree, local dependencies, and provider authentication stay where they already live.

That has two practical benefits:

• The plan can refer to the actual local repository state, not a copied sandbox.
• The execution can continue in the same environment after approval.

It also means your local setup still matters. If tests do not run on the daemon machine, plan mode cannot make them run. If the repo is stale, the plan may be stale. Keep the daemon's workspace healthy before asking the agent to do high-value work.

Tradeoffs

Plan mode adds latency. The agent spends time reading and explaining before editing. That is worthwhile for risky changes and wasteful for trivial ones.

Plan mode can also create false confidence. A plan can be coherent and still miss an edge case. It should improve your review, not replace it.

Some work cannot be fully understood without running commands. If the agent is limited to read-only planning, it may need to state what it cannot verify until execution. That is acceptable. A good plan calls out those limits.

Finally, do not let plan mode become a substitute for good issues. If a Linear issue lacks acceptance criteria, ask for clarification or improve the issue before starting automation.

A plan-mode checklist

Before approving execution, confirm:

• The plan names specific files or search targets.
• The plan matches the issue intent.
• The proposed edits are smaller than the problem statement.
• The agent has not proposed unrelated refactors.
• The validation commands are realistic.
• The risks are named.
• You know what diff you expect to see afterward.

After execution, review the code anyway. Plan mode improves the first move; it does not guarantee the final branch.

Where to start

If you already use Junction manually, try plan mode on one medium-risk task: a component fix with tests, a small backend refactor, or a bug where the agent needs to inspect several files. Watch the plan, adjust it, then approve execution only when the path is concrete.

If your team uses Switchboard, enable route-level plan mode on one higher-risk repository route and compare the review quality of the resulting pull requests. Keep the route conservative until the plans are consistently specific.

For related controls, see how to approve AI agent actions safely and how to stop and steer live AI agent runs. To try the workflow from scratch, start with the Junction setup guide.