Claude Code line · stop 10 of 16 · 15 min · members
The last twenty percent of a context window is where refactors go wrong. How to plan around it.
Free with an account
Membership is free: an account opens all 86 script pages. The Lab, Studio Canvas and the paid guides need the $99 pass, paid once. Already signed in on this browser? The page opens by itself.
The observation
And the failure is subtle enough that you attribute it to the task.
A long session degrades in a characteristic way. Details established early get contradicted. Files that were discussed get re-read. Suggestions arrive that were already rejected an hour ago.
It reads as the model getting worse, which is not quite it. What is happening is that the relevant information is now competing with a great deal of accumulated material — half of it superseded — and the signal-to-noise ratio has fallen.
The practical consequence is that the most demanding work should not be attempted late in a session, and that ending a session deliberately is a skill rather than an admission.
The rule
Large refactors, multi-file features, subtle debugging — all need room.
Work that spans several files and requires holding relationships in view needs the window to be relatively clear. Started late, it produces changes that are individually reasonable and collectively inconsistent, which is the most expensive kind of wrong.
Late-session work should be bounded and local: a single function, a documentation pass, a specific test, something with a clear edge. These degrade gracefully — a mediocre local change is visible and cheap to fix.
If a structural task appears late, write down what needs doing and start it fresh. The cost of restating context is far lower than the cost of a half-consistent refactor.
Keeping it clean
Three habits that meaningfully extend a useful session.
Read narrowly. Asking for a whole file when you needed one function loads a great deal of irrelevant material that then competes for attention for the rest of the session.
Search rather than browse. Finding the three relevant places is cheaper than reading four files to locate them.
Do not re-establish what is already established. Repeating context that was set an hour ago adds to the pile without adding information.
These are unglamorous and they roughly double the length of a session that stays sharp.
Handover
A deliberate ending costs five minutes and saves half an hour.
Before stopping, write down: what was done, what is in progress, what the next step is, and any decision made that is not visible in the code.
That last item matters most. The code shows what was written; it does not show what was tried and rejected, or why an obvious approach was avoided. Without it, the next session rediscovers the dead end.
Keep this note in the repository rather than in a chat. It is project state, and the next session — or the next person — should find it where the work is.
The signals
They are recognisable and they are usually ignored.
Any of these means the useful part of the session is over. Continuing produces work you will review more carefully than it would have cost to redo.
The instinct is to push on because stopping feels like losing progress. The progress is already saved — it is in the files. What is being lost by continuing is the quality of what comes next.
Planning around it
Hard work early, mechanical work late.
If you know a session degrades, plan for it. Do the architectural thinking, the tricky debugging and the multi-file changes in the first part. Leave documentation, tests, formatting and small isolated fixes for the end.
This is the same discipline as scheduling difficult work for when you are alert. The resource is different and the shape is identical.
Done deliberately, a long session produces good structural work and good mechanical work. Done without thinking about it, it produces good work followed by work you have to check.
1:1 · two hours