Working with Claude

This is what I’ve learned working with Claude in practice, and I’m sharing it here. I still have a lot to learn, and I’ll keep this updated as I do.

Plan a lot and work in small cycles

Start by planning at a broad level, then refine the plan until you and Claude are on the same page. It’s much easier to refine a plan than it is to fix code or content.

Scope each cycle to one small feature. A small feature needs a small amount of context, and a small context keeps Claude focused on the thing in front of it. Plan it, execute, make small tweaks, repeat.

Planning is where the time goes. About ninety percent of mine is spent there. The other ten percent is guiding the execution and tweaking.

Tip: run /model opusplan, then Shift + Tab to switch into plan mode. Opus does the planning and Sonnet executes it, so each model does what it does best.

Content is the source of truth

Content is the work itself: code, documentation, an article. Context is what you add around it to help Claude, like instructions and the reasoning behind decisions you’ve already made. If it can be read in the content, it belongs there, not in context.

Give Claude a prompt and it finds what it needs on its own, pulling in only the parts that actually have to change. Anything you duplicate into context is extra weight it carries whether it needed it or not. So keep context to the what and the why, never the how, and don’t over-prescribe: leave room and Claude comes back with things you wouldn’t have thought to ask for.

Tend your persistent context

Context is less visible than content, but it matters just as much. CLAUDE.md is the clearest example: Claude Code reads it every session, and it won’t stay clean on its own. Claude adds to it over time, and some of what it adds is inaccurate or only briefly true, then gets treated as fact from then on. One small flaw in frequently loaded context produces the same issue over and over, and it adds up.

Use Claude to find it. When it does something you didn’t intend, ask where that came from, then clean up whatever it points at. You can go further and have Claude assess your whole context, not just the one bad turn.

Or skip the tending. Boris Cherny, who built Claude Code, just suggests deleting it every six months.

Build a workflow, then coach Claude into it

Your workflow is the shape the work moves through, not the work itself. Get that right once, and everything you make afterward moves through it faster.

Mine has three levels: plan slowly, work fast without stopping to check in, then publish only when I say so. Set it up well and Claude stays fast on almost everything, while you stay in control of the few moments that actually matter. Write it into your persistent context once, and Claude works inside it every session after.

Keep a place for ideas and to-dos

When an idea comes up mid-task, it needs somewhere to go that isn’t content and isn’t context: a scratch folder works. Claude can help manage that space, but don’t let it pull from there on its own. Left to itself, it files ideas in more permanent places and starts treating them as rules to enforce.

Delete a note once the idea has made it into the content. Anything left behind was only ever relevant at the time, and it eventually becomes wrong.

Friction is a signal

Sometimes Claude just isn’t getting the work done. You’re repeating yourself, or fine-tuning more than the work should need. Nothing is failing outright, which is what makes it hard to name. It’s something you sense more than measure.

It’s usually one of two things: scope crept in while you weren’t looking, or the problem is harder than the model can execute on. Bump the model, or cut the scope down to a smaller bite of work. Most of the time it’s the scope.

Turn Claude into an adversary

Once you’ve spent real time on something, tell Claude to spin up an agent whose only job is to adversarially evaluate it and find the gaps.

That gets you a genuinely fresh perspective, not just another answer from the same conversation or context.

Professionalism scales now

Testing. Edge case handling. Polish. The work that separates something professional from something that merely works has always lost the priority fight against features, because it doesn’t move anything a user can see.

It loses less now. When the cost of that work drops far enough, the standard you can hold everything to goes up. Not more features faster. A higher floor under everything you ship.

What I’m exploring

Agent orchestration and looping. I want to get more out of agents working on my behalf, automated and asynchronous, not sitting in one linear session watching every step. I don’t have a feel yet for when to split work across agents, or how to loop them well so they keep going without me.

Remote control. Right now I’m at my computer every time I work. I want to manage the whole workflow from my phone, by voice, kicking things off and checking in without sitting down.

The advisor pattern. Letting a model reach out to an advisor model when it needs one, rather than pushing through alone or waiting for me to notice it’s stuck. It’s a real tool and I want to get good at knowing when to wire it up.

Tuning the effort dial. Model choice and reasoning effort are two separate levers. Reaching for a bigger model isn’t always the answer when a cheaper one stumbles. Sometimes it’s the same model thinking harder. I don’t have a feel yet for which to reach for when.