Have you ever gone through a long coding session complete with testing all of the new features you built, rolled a new version and pushed. Then when requesting a slight adjustment post-commit watched Claude go to town with a full adjustment, release increment and then rolled the code to production?!?!
This is an example of how Claude has adjusted its view on completion during a single session. The potentially destructive action happened despite explicit instructions in the CLAUDE.md disallowing commit/push actions without human consent.
Completion Bias
Let’s back up a little and talk about what completion bias is. I wrote about this topic almost 6 months ago and even today Claude has a problem with overriding explicit instructions when determining its vision of success.
Completion bias is Claude’s pre-determined vision of what a completed project looks like. The more you push Claude to go faster the more corners might be cut along the way.
I’ll be straight up with you when this has happened I fought a brief internal battle about why Claude was allowed to do this. I rationalized that because those short term fixes did fit the mission I was willing to roll with it.
There Were Signs
Have there been times when Claude is like “alright I think we are good!” and you ask “how many failing tests do we have” and Claude is like “oh there are only 3 but that is from a previous session”. You know that isn’t true.
We have a strict no lint, TS or test failures allowed before push. How could this still be happening within the same session? Is it possible that Claude comes up with what completion looks like during the planning phase but adjusts that while iterating with the engineer?
Where This Becomes Problematic
As more potent tools such as MCP’s and autonomous agents come online, the unfettered ability to push to production should be closely guarded.
The stories of entire databases being wiped out by AI tools are still hitting the headlines. Strict adherence to release and migration strategy is vital for a healthy development environment. Using Claude’s native features to enforce these policies makes the most sense.
Choose a permission mode - Claude Code Docs
What Is Plan Mode
Plan mode is a read-only research and discovery mode that can be enabled by using the /plan command or asking Claude directly. Not only is write access to files disallowed but also any bash command. This mode will prevent any access before first presenting a full plan, being granted permission then executing the agreed on plan.
When I first learned about plan mode it seemed natural to use it at the beginning of the software development lifecycle. One of the things I liked most was being given a full plan, changing the plan then having the option to clear context and start working. This is a built in guard against the code first behavior we have all seen so often and a great way to narrow the periphery of completion bias.
For a couple months now I have been using plan mode more often and even multiple times in a single session. Let’s say I am building a new feature or writing a refactor. Starting in plan mode then moving into the coding session is a great way to start.
If Claude starts to work in areas of the code that don’t align with the task or building a feature that no longer makes sense, I stop Claude and go back into plan mode. The action of going back into plan mode is a demarcation point for Claude to understand it is no longer writing code and may need to pivot from the original plan before starting back at the code.
Going back into plan mode is also a great way to divert Claude’s focus from producing code to planning around the product.
Architecting a refactor of existing code is the perfect case for plan mode and Claude excels at the task during execution. I say this because the guardrails around what Claude will need to do from the beginning to end are clearly definable in a brownfield system.
A Contextual Pause
Plan mode forces Claude to output its logic in natural language before it touches the filesystem. This is almost like a more free form of TDD but instead of thinking about tests first we are asking Claude to think about the architecture and the product as if it were a user not a code smith.
There can be token efficacy gains by first using plan mode too. Planning in a read-only state often leads to shorter, more concise execution phases, which can save on token usage.
How Are Context Sources Consumed?
Context sources such as CLAUDE.md and Memory are consumed during the start of a session but are they re-read when using the /plan command in the middle of a long-running session? I asked Claude and the answer is no. So it is possible over the course of a long-running task to continue polluting context and deranging completion bias.
Memories seem to have a higher attention weight in the current architecture.
Does Plan Mode Always Do The Trick?
Even during my most recent major refactor I witnessed Claude pushing code to production despite instructions in CLAUDE.md to require human consent. Going into plan mode does not reset Claude’s expectations for a successfully completed project and does not re-read context resources.
Plan mode did not prevent pushing code to production without human consent.
I felt very hypocritical because I was writing this article at the time! So Claude needed to have better realtime understanding of the sensitive nature of releasing to production and I fixed that by adding a memory.
---
name: Plan approval ≠ approval for downstream state-changing actions
description: After a plan is approved and implementation completes,
each push/commit/deploy is a SEPARATE decision needing its own gate —
completion momentum tries to chain them
type: feedback
---
After a plan-mode plan is approved and I finish implementing it,
I tend to drift into the next "obvious" step (push, commit, deploy)
as if it were part of the same approved task. It isn't. The plan covers
the work the plan describes;
everything downstream is a separate decision tree.
We already had instructions in CLAUDE.md but adding a specific memory about pushing without human approval has safeguarded long-running sessions from pushing without consent.
Memories seem to have a higher attention weight in the current architecture. Use of memories seems much stickier for long-running sessions or tasks involving multiple Claude sessions and I often see Claude recalling memories.
Often the instructions in CLAUDE.md can be sort of given less importance or weight as the conversation length increases. However a specific memory about the push operation can be referenced and loaded mid-session.
Onward And Upward!
How have you been tailoring your use of the modes offered in Claude to change your workflow? Have you had good experiences with plan mode or other techniques? Tell me what you do 🙏. Let’s go build some cool stuff!
Controlling Completion Bias When Using Plan Mode was originally published in Towards AI on Medium, where people are continuing the conversation by highlighting and responding to this story.