Claude Code

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 ship whatever I built first. The vibe coded version would go straight to production, and then I'd spend weeks untangling it because the code was optimized for speed, not clarity. Claude and I would just keep patching things, and eventually I couldn't even remember why certain decisions got made. Then I started treating prototypes like actual disposable prototypes instead of secret first drafts. I build the thing fast with Claude, get it working, understand what I actually need, then I start completely over with a real spec. The second version gets written deliberately with the person who'll maintain it in mind. It's weird but it works. When I start the rewrite I always run `vercel env pull` first to make sure I have the actual production config, then I'm building from a fresh Next.js template and a spec that's just a few sentences about what this needs to do and why. The prototype taught me what the thing should be, and now the real code gets to be what it should look like. The caveat is that this only works if the prototype is actually fast to build. If it takes you two weeks to prototype something, rewriting it from scratch is going to feel ridiculous. This technique is for the stuff where you can throw together a real working version in a day or two, learn what you need to learn, and then do it right.

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.

Running browser tests from the session you are working in means the test run and your own navigation fight over one browser, and you get failures that have nothing to do with the code. Define a dedicated subagent with its own isolated browser server in its frontmatter, and explicitly disallow the parent session's browser tools on it. The subagent then physically cannot reach into your browser, so a full e2e sweep can run while you keep working. Worth doing even solo - the isolation is what makes the runs reproducible.

Test scenarios live as numbered markdown files per feature area, with preconditions and expected results - readable, reviewable, diffable by anyone. The runnable scripts are generated from them, committed so they can be inspected when something fails, and regenerated only when the source scenario actually changed. The rule that makes it hold: any task that changes user-facing behaviour updates the scenario and regenerates its script in the same commit. Stale generated scripts are the single biggest source of noisy full-suite failures, and they are the thing an agent will silently skip unless you make it explicit.