Anyone who uses Claude all day, especially through Claude Code, works at a different level than someone who occasionally has an email written. At that level it is no longer about individual prompts, but about how you set up your work so the model can finish as much as possible on its own. This part collects the approach of the heaviest users, starting with someone who would know.
The tips from the maker of Claude Code
Boris Cherny built Claude Code and uses it heavily himself. A few of his points are broadly useful, well beyond programming.
His most-cited tip is about git worktrees: run several Claude sessions at once, each in its own working directory, so they do not get in each other’s way. He calls it his single biggest productivity unlock. In plain terms: you let three to five tasks run in parallel instead of waiting for one to finish. For anyone with a lot of separate work that does not depend on each other, that is a world of difference.
On top of that: plan first, then execute. Describe the problem fully before you ask the model to build anything. The better you have talked the problem through, the better the execution. He uses voice for this too, dictating most of his instructions instead of typing them, because speaking describes a problem faster and more completely than typing does.
And the verification loops from the previous part show up with him as well, as one of the biggest levers for quality. Give the model a way to check its work and it gets better. That holds for a beginner and a power user alike.
Autonomous workflows: hooks, loop and batch
The more you let the model work on its own, the more you want to lock down what should always happen no matter what. There are a few tools for that.
Hooks are small pieces of fixed logic that run at fixed moments in a task, for example a check that always runs before something is saved. The nice thing is that this is not a guess by the model but a hard rule: it always happens, exactly the way you set it. That way you take the things that deserve no interpretation away from the model and lock them into code.
With a loop command you have the model repeat an operation over a series, and with a batch approach you run the same step over many items at once. For recurring work with a fixed shape that saves a great deal. And a handy small tool: with a side-question command you ask a quick question in passing without interrupting the running task.
Tool use: let it think first
Sonnet 5 reaches for a tool sooner on its own, a browser, a terminal, a search. That is usually good, but on a tricky task you want it to think before it clicks anything.
The way to steer that: have the model start with a thinking step before it calls its first tool. In practice you ask it to make a plan first, or to analyze the situation, and only then to get to work. A model that thinks first and acts second makes fewer wrong intermediate steps than a model that starts clicking right away. It is in line with the broader principle: plan first, then execute.
Sonnet 5 or Opus 4.8?
The question every heavy user asks. The short answer: Sonnet 5 for almost everything, Opus 4.8 for the exceptions.
Opus 4.8 is the heaviest model. It reasons more deeply, but it is slower and more expensive. Sonnet 5 is faster and cheaper, and on hard tasks it now reaches Opus level if you pick the right effort level. That shifts the trade-off. You used to send your hardest work to the expensive model by default. Now you can do much of that on Sonnet 5 at a high effort level, for a fraction of the cost.
Save Opus for the genuinely heavy, critical problems where maximum reasoning depth makes the difference and the higher price and lower speed are worth it. For everyday work, including the demanding kind, Sonnet 5 is the default from here on.
The new tokenizer and your context
Sonnet 5 counts text differently than its predecessor. The same text now costs roughly thirty percent more tokens. That has two consequences you should know.
The first is cost. If you reckon in token prices, the same amount of text now comes out higher than you were used to. Account for that in your budget and do not compare one to one with the old figures.
The second is room. There is a big advantage on the other side: Sonnet 5 has a context window of a million tokens. You can pass in an entire document or a whole codebase at once. Even though the same text costs more tokens, the window is so wide that in practice you have to chop things up far less often. For anyone working with large documents, that room more than offsets the higher count.
The flip side of going this deep
The more you build on this, the more you are tied to it. Worktrees, hooks, a CLAUDE.md that knows how you work: that is comfortable, but it is also a workflow that locks itself around one model from one provider. Switching gets more expensive the deeper you go. Worth knowing, not worth fearing.
Two things I keep an eye on myself. Transparency: if I make something largely with Claude, I say so. This series, for instance, was written with Claude and then checked by me. And the question of where your work runs: for most things the cloud is fine, but as soon as sensitive or confidential data is involved, you weigh whether it should go to an outside service at all or whether a local approach fits better. That belongs to the craft, not as an afterthought but as part of the choice.
Prompt structures for agentic work
Finally, the thread running under all of the above. When you let the model work on its own, your role shifts from someone who steers every step to someone who sets the frame. That frame has a fixed shape that keeps coming back.
You describe the goal fully, you give the context that travels with you through a fixed file, you let the model think and plan before it acts, and you build in a way for it to check its own work. Within that, you give it the room to finish the task. That is the heart of working with an agentic model: do not micromanage, do give a good frame and a good yardstick.
That closes the series. From the first prompt to the autonomous workflow it comes down to the same thing every time: be clear about what you want, give the context that is needed, and give the model a way to check whether it is right. The rest is practice.
Questions, or curious how I use this myself? Read along at sparkone.nl or email me at jeroen@sparkone.nl.