This came up in Chinese AI developer communities this week, from someone logging seven or eight hours a day of vibe coding with Claude Code. The post was practical enough to be worth unpacking for an English audience, because the core problem it describes is one most of us have hit and then blamed on the wrong thing.
Here is the failure mode: you are two hours into a session, the context window is 60% full, and the model starts making changes that contradict decisions it helped you make an hour ago. You spend 40 minutes debugging something that was never broken. You add more instructions. The model apologizes, then does it again slightly differently. You have not written bad prompts. You have not picked the wrong model. You have run out of usable context, and you did not notice until the damage was done.
That is the argument of this piece: the majority of quality degradation in long AI coding sessions is a context management failure, not a model capability failure, and most workflows treat it as the latter.
The One-Shot Principle Is Not About Trust
The original post opens with a recommendation that sounds like it is about trusting the AI: do not immediately patch the code it generates. If there are many errors, rewrite the prompt, roll back with two Escape presses in Claude Code or a git revert, and retry from a clean state.
But this is not about trust. It is about context economics. Every back-and-forth correction you make after a bad generation costs tokens. More importantly, it adds noise to the context window: the model now has to reason over a conversation that includes the wrong version, your correction, its acknowledgment, and the new version. That accumulation degrades subsequent generations in ways that are genuinely hard to attribute. The session that felt fine until it suddenly was not? Often the cause is ten rounds of small patch-and-fix interactions from two hours earlier.
The one-shot discipline forces you to spend your context budget on clean attempts rather than repair work. It is not a confidence game. It is arithmetic.
Plans as Persistent Artifacts, Not Conversation Steps
The original workflow described is worth quoting closely. Before a significant change, the practitioner asks the AI to write a plan into a document. A separate agent reviews that document. A new session then implements it.
The inefficiency this addresses is easy to miss if you have not been burned by it. When a model plans and implements in the same session, the planning tokens are gone by the time implementation is underway. The model is working from its compressed internal representation of what it decided, not from an authoritative external record. When something goes wrong mid-implementation, it is reconstructing intent from context rather than reading a spec.
Writing the plan to a file changes the epistemic situation. The plan is now a fact in the repository, not a memory in the context. A new session can read it cold and implement against it without carrying the exploratory reasoning that produced it. This is a meaningful difference in practice. The implementation session starts with a narrow, high-signal context window instead of a wide, noisy one.
One commenter pushed back: you should not need to manually trigger this, it should be automated in your agent config so the plan-then-review loop happens by default. That is a fair engineering point. But the manual version is still better than no version, and understanding why it works is necessary before you can automate it well.
The 50% Handoff Rule
This is the most concrete operational advice in the original post, and the number matters: when the context window hits roughly 50% capacity, generate a handoff document and start a new session.
The practitioner does not use a fixed template for the handoff. They tell the model directly: I am starting a new session, write down everything the next session needs to know. The instruction is that simple.
Matt Pocock, cited in the comments, reportedly keeps context under 15%. That is aggressive but directionally correct. The degradation curve is not linear. A model at 80% context is not just slightly worse than one at 40%. The forgetting is uneven: recent tokens are weighted more heavily, but the specific decisions made early in the session, the ones that set architectural constraints and variable naming and API shape, are exactly what gets compressed and lost.
The commenter who disagreed, arguing that the original complete session has better coherence than a fresh window, is describing a real effect. There is something lost in a handoff. But that loss is predictable and manageable. The loss from a degraded long context is unpredictable and insidious. You can write a good handoff document. You cannot write a good patch for a model that has quietly started contradicting itself.
Layered Configuration Files Are a Context Budget Decision
The recommendation about claude.md and agent.md files is less obvious than it first appears. The advice to split them by directory, with a frontend config in /frontend/claude.md and a backend config in /backend/claude.md, is not primarily about organization. It is about preventing the model from loading irrelevant instructions into every session.
If your system prompt is 2,000 tokens of mixed frontend and backend context, every backend-only task is burning 1,000 tokens on instructions that cannot help and might confuse. Splitting the files means the model loads backend context when it is working in the backend directory and ignores the rest. Your usable context window for backend work just got 1,000 tokens wider.
This compounds. The original post notes that every practice described, one-shot attempts, written plans, handoff documents, layered configs, is ultimately a context management practice. One-shot generation keeps the window clean. Written plans move reasoning out of context into persistent storage. Handoffs reset the window before degradation compounds. Layered configs reduce the standing overhead on every session. They are different interventions on the same variable.
What This Costs When You Get It Wrong
Let me be specific about the failure mode, because the original post is somewhat abstract on this point.
You are building an API. Early in the session you and the model agree on an error response format: {error: string, code: number}. Two hours later, context at 70%, the model generates a new endpoint that returns {message: string, status: number}. You do not notice immediately. You build three more things that consume that endpoint. An hour later you have a type error you cannot place. You spend time in the wrong files. You eventually find it. The fix is trivial. The search was not.
That is a small example. In a larger session, the model might start ignoring an architectural constraint you established early on, or reintroduce a dependency you explicitly rejected, or use a naming convention that conflicts with one established in a file it has not read recently. Each of these is a context management failure that presents as a model quality failure.
The frustrating part is that the model will agree with you when you point out the mistake. It will not have been confused. It will have simply not had the early decision in active context when it made the later one.
The Practical Checklist
If you are shipping code with these tools daily, here is the distilled version:
- Prefer rolling back and retrying over patching in place. The context cost of repair usually exceeds the cost of regeneration.
- Write plans to files before major changes. Use a separate session or agent to review. Implement from the file, not from memory.
- Watch your context meter. Pick a threshold, 50% is reasonable, 15% is aggressive and probably correct, and generate a handoff document when you hit it.
- Split your config files by the directories they are relevant to. Every token of irrelevant standing context is a token of working context you cannot use.
- When the model starts making decisions that feel off, check when you last reset context before you start interrogating the prompt.
None of this is counterintuitive once you have been burned by the alternative. The question is how many hours you lose before you build the habit.
What threshold do you actually use before starting a fresh session, and have you found a handoff format that reliably preserves the decisions that matter most?
Top comments (0)