Cursor

I used to just let conversations run until Claude started contradicting itself three turns back, which is a great way to debug your own debugging. Then I'd paste the entire mess into a new session and hope it read faster than I type. Spoiler: it didn't, and I'd lose the thread anyway while Claude re-indexed my life story. So now I cap sessions at around 65 percent of the window and write a summary before context gets stale. The summary has to be ruthlessly concrete: what we built, what broke, what the actual code looks like now, what we're trying next. I paste that summary as the first message in the next session instead of pasting twelve turns of my increasingly delirious questions. With Claude Code or Cursor, I just write "---SUMMARY---" in my notes at the midpoint, then force myself to actually write it out. The session ends, I start fresh, paste the summary, and we pick up without me re-explaining why I thought TypeScript generics were optional. The next session stays sharp because the context is distilled, not diluted. The catch is this only works if your summary is actually useful. If you write "continued on the file" and nothing else, you're just making the next session mad at you. Also, some problems genuinely need the full conversation history, especially when you're debugging why someone else's legacy code exists. Summaries help, but they're not magic for gnarly interdependencies.

I used to open Claude Code or Cursor and start typing implementation details immediately. I would write a function signature, change my mind halfway through, delete three files worth of context, and end up in a state where I could not explain what I was trying to build anymore. The session became a series of local corrections that never addressed the original problem. Now I stop before the first keystroke. I write a five line plan in plain text: what files I will touch, what the data flow looks like, where the types will go, and what I expect to break. I paste this into the chat and wait for feedback. This takes maybe ninety seconds to write and thirty seconds for Claude to read. No editing allowed on this turn. The concrete practice is I set a rule: if a message I send contains code, it also contains a plan written first. I use a simple format with one line per concern: purpose, input shape, output shape, where it integrates, known risk. I have caught wrong module boundaries, missing error cases, and approaches that would have required refactoring the type signatures before I changed a single line of actual code. The caveat is that this approach breaks down when you are truly exploring unknown territory. If you do not know what the problem is yet, a written plan is premature. In those cases I still start with the plan, but I make it a hypothesis instead and mark it as provisional. The discipline of writing it down helps anyway, even if everything changes.