Don't Trust Plan Mode Blindly

"Plan mode" is supposed to be the safe button: the agent reads your code, thinks through an approach, writes up a plan, and stops — no files touched until you approve. One tester running a side-by-side comparison found that promise doesn't always hold. On the same prompt, one model's plan mode quietly deleted spacing and started implementing code nobody asked for, while another model asked clarifying questions and touched nothing at all.

Why plan mode isn't a guarantee

"Plan mode" is a UX convention, not a hard technical boundary enforced the same way by every tool. Depending on how a given model or harness implements it, "planning" can mean anything from "text-only, file system untouched" to "mostly just talks, but occasionally slips into acting on a suggestion it's confident about." The label tells you the intent of the mode. It doesn't verify the behavior of a specific model on a specific day.

This matters more as more coding tools ship their own version of plan/read-only modes, each with a slightly different implementation. A guarantee that holds for one model's plan mode in one tool is not automatically transferable to a different model, a different tool, or even a new version of the same model after an update — the finding here is a snapshot of one comparison run, not a permanent verdict on any specific vendor.

What a well-behaved plan mode looks like

In the tester's comparison, the model that respected the boundary produced a plan with three recognizable parts before it stopped and waited:

1. An overview of what it understood the task to be.
2. The current state of the relevant code, so you can confirm it's reading the right thing.
3. A step-by-step implementation guide — the actual plan, laid out for you to review before anything gets written.

It also asked clarifying questions where the request was ambiguous, rather than guessing and running. That's the pattern worth recognizing: outline, then stop, versus outline and keep going anyway. The failure case in the same test wasn't subtle once you knew to look — spacing changes and half-implemented code appeared in the file tree despite the session still being labeled "plan mode."

How to verify a model's plan mode before you trust it

1. Enter plan mode on a low-stakes task first, before you rely on it near anything you care about. Treat every new model — and every major update to a model you already trust — as unverified until you've watched it behave once.
2. Check your diff or file timestamps before approving the plan. If anything changed on disk while the session was supposedly read-only, that tool's plan mode is not read-only for you, regardless of the label.
3. Commit before you hand a less-familiar model anything near your codebase. A tester in the same source material makes this a standing habit, specifically so a surprise edit is one git reset away from undone.
4. Don't generalize a single bad run into "that vendor's plan mode is broken." This was one comparison, one prompt, one point in time. Verify current behavior yourself.

git commit -m "before plan mode"
# enter plan mode, let it think
git status   # anything modified here shouldn't be
git diff     # if this isn't empty, plan mode didn't hold

Pitfalls

• Assuming a mode name describes a hard guarantee. "Plan," "ask," "read-only," "dry-run" — these are UI labels a vendor chose, not certifications. Verify, don't assume.
• Skipping the check because "it's just planning." The entire point of the failure mode described here is that the tool looked like it was just planning while it wasn't.
• Trusting a stale mental model. A model's plan-mode behavior at the time you tested it may not be the same after the next update — re-verify after major version bumps, especially before high-stakes sessions.

Takeaway

Trust, but check the diff. A plan-mode label is a claim, not a proof — one quick git status after every plan-mode session, and a commit checkpoint before you let an unfamiliar model near your codebase, is the whole habit.

Resources

• Route Tasks to the Right Model — Yeda AI Tips #052
• Test Models on Hard Tasks — Yeda AI Tips #054