# Notes from Practical Claude Code Use

https://ryanklein.dev/notebook/practical-claude-code-use
Published 2026-08-01 · Updated 2026-08-25

Practical notes on using Claude Code day to day: plan in small cycles, keep context clean, and leave room for the model's judgment. Revised as I go.

This is what I've learned working with Claude Code in practice, and I'm sharing it
here. I'll keep this updated as I go.

## 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 <kbd>Shift</kbd> + <kbd>Tab</kbd> 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](https://youtu.be/qyPCVqFUyDo?si=TM2JYTcGKCujUFlu&t=415).

## 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.
