Knowing when to restart the conversation

Sessions decay

A conversation that has been running for three hours contains every failed attempt, every stale error, every abandoned idea. All of it is in the context, competing for attention with the part that matters, and the model has no way to know which parts you have written off.

The symptoms are recognisable once you know them:

• It reintroduces something you rejected an hour ago.
• It refers to a file that was deleted or renamed during the session.
• Answers get longer and less specific.
• It starts rewriting things you did not mention.
• It contradicts a decision made earlier in the same conversation.

None of those mean the model has become worse. They mean the context has filled up with debris.

The handover

Before closing a session, spend one turn on this:

Before I start a new session: write a handover.
- What we were trying to do
- What is now working and how it was verified
- What is not working, with the exact error
- Every file we changed
- Decisions I made that are not obvious from the code
- What you would try next, and what you already ruled out

Paste the result into the new session with the current error. You keep the useful state and drop the wreckage.

Save that handover in the repository too: notes/state.md, committed. It is more useful than it sounds, because you will restart this project after a two-week gap and that file is the fastest way back in.

Restart before things get bad

The better habit is not restarting when it breaks. It is restarting when a feature is finished, at a clean commit, before the next one begins.

A fresh session with a written spec and a clean tree is fast and precise. A three-hour session carried into a new feature starts with a handicap and never catches up.

Rewind rather than persuade

Most tools let you edit an earlier message and branch from there. This is underused and it is better than arguing.

If the model went in the wrong direction at message four, do not spend messages five through twelve correcting it. Go back to four, rewrite the request with the constraint you now know you needed, and the eight bad messages never happened. The context is smaller and cleaner as a result.

Two failed attempts, then stop

The rule from the earlier lesson deserves restating here with its reason. After two failed fixes for the same problem, the context now contains two wrong theories, and the third attempt is being built on top of them. Continuing produces a distinctive pattern: increasingly large changes, decreasing confidence, and eventually a suggestion to reinstall everything.

Stop. Revert to the last working commit. Start a new session with a clean statement of the problem and the reproduction. It nearly always works on the first attempt, which is worth noticing: nothing about the problem changed, only the context it was being thought about in.

The same failure with a different model

Switching models sometimes helps, and it is worth knowing why: not because one is smarter, but because the second one arrives without the first one’s committed theory. A fresh session with the same model usually gets most of that benefit.

Do not conclude much from one comparison. Model A succeeding where model B failed, once, on one problem, is a sample of one, and the ordering matters: the second attempt always has the advantage of your better-stated problem.

What to keep between sessions

Three things carry over, and they should live in files rather than in a chat window:

The rules file, which every session reads automatically. The specification and acceptance checks for the feature in progress. The state note, describing where you are.

Everything else is disposable. A conversation is a working surface, not a record, and treating it as a record is how people lose an afternoon’s decisions when a tab closes.