When the person who created Claude Code publishes seven tips on how to use it, the correct response is not to nod along — it's to retest every one against real work, because creator demos are run under demo conditions and your codebase isn't one. That's what I did with Boris Cherny's seven Opus 4.7 tips. One of them corrected something I was actively doing wrong at the API level; the rest sorted cleanly into daily keepers and situational tools. Here's the honest scorecard.
The tip that hooked me was a single sentence: on Opus 4.7, the extended thinking toggle is gone. I paused the video, opened my API console, and confirmed it — the thinking: {"type": "enabled", "budget_tokens": N} parameter I'd been tuning for months returns a 400 error on Opus 4.7. He was right, I was stale, and the other six tips earned a fair hearing. I spent the next four days rebuilding his demo project — a Linear-style tracker with projects, tasks, statuses, priorities, and assignees — and running each technique against it.
Tip 1: Stop fighting the permission cycle — auto mode won
Claude Code's permission modes cycle with Shift+Tab: default → acceptEdits → plan → and, on qualifying plans, auto. Auto mode doesn't just skip prompts — a separate classifier model reviews each action before it runs and blocks anything that escalates beyond your request, targets infrastructure it doesn't recognize as yours, or looks driven by hostile content Claude read. Your permissions.deny and permissions.ask rules still run first; the classifier can't override an explicit ask rule.
Boris was ahead of the curve on this one: as of August 14, 2026, auto mode is the default for new sessions on Pro, Max, and Team plans. The retest sold me anyway. During the tracker build, a long chain of tool calls — schema, migrations, seed data, dev server — ran without a single prompt while I drafted the next spec elsewhere. The difference wasn't code quality; it was where my attention lived.
My caveat stands, though: for client production repos, where an accidental destructive command costs real money, I stay in acceptEdits. The classifier is good; "good" at scale still means occasional misses. Auto mode is for work where git reset is cheap.
Tip 2: Frontload the entire spec
This tip changed my output quality the most, and it's the one I fought hardest. My habit was incremental prompting — schema, then routes, then UI, checking each step. It felt like control. It was actually a leftover reflex from models that couldn't hold a large spec in their heads.
Boris's demo hands Opus 4.7 the whole thing in one prompt: data model, stack, UI structure, and the closer — "don't ask me questions, make sensible defaults and ship it." My retest of the same approach produced a working app in minutes, roughly 85-90% of the way there, with a couple of import-path and styling fixes to finish. More importantly, the integrated pieces actually fit, because the model built each one knowing about all the others.
That's the real lesson: incremental prompting hides information from a model that no longer needs the drip-feed. You're signaling the pieces are independent, so it builds them as if they are — and integration becomes its own bug hunt. My rule now: if the first prompt of a build is under 150 words, I haven't thought hard enough about what I'm asking for. It's the same PRD-first logic I use at project scale in my SaaS MVP workflow, compressed into a single prompt.
Tip 3: Two agents, not one true agent
Boris is surprisingly honest here for someone whose job is Claude Code: he doesn't claim it for everything. His split — Claude Code for deep, production-grade work where architecture matters; OpenCode (the open-source terminal agent that routes to many model providers) for quick prototypes and throwaway tooling — matches my experience running both.
OpenCode's advantage is economic and iterative: point it at a cheap model, pay per token, and don't care about the code quality of something you'll delete Friday. Claude Code's advantage is opinionation: tuned for Anthropic's models, with the hooks system, skills, and plugin ecosystem that compound over months. The tip inside the tip is to stop looking for one agent. Match the tool to whether you'll be maintaining the output at 2 AM in six months.
Tip 4: /recap — the command you didn't know shipped
I'd genuinely missed this one. /recap prints a compact summary of the session so far — what was touched, what ran, where things stand. Claude Code also generates a recap automatically when you come back to a terminal you stepped away from: after a few minutes of the terminal being unfocused, the summary builds in the background so it's ready when you switch back. It's on by default and configurable through /config.
The feature is small; the workflow it unlocks isn't. I habitually kick off long sessions, walk away, and return to cold coffee and five screens of scrollback. /recap replaces three minutes of archaeology with a two-second read. Running multiple parallel sessions — which I do constantly across git worktrees — it becomes the whiteboard you glance at to re-orient per window.
Tip 5: Effort levels are real, and xhigh vs max is a real distinction
I'd assumed "extra high" and "max" effort were marketing gradations of the same thing. They're not. Claude Code exposes five effort levels — low, medium, high, xhigh, max — and the two top tiers trade differently: xhigh is the level you can set and forget across sessions, while max applies to the current session and removes the ceiling on how much work the model will put in.
Boris's assignment rule matched my retest: low/medium for one-file edits and trivial fixes; high for standard feature work; xhigh when architecture matters or the model's first instinct tends to be subtly wrong; max for large frontloaded builds and full-system migrations, where you're handing over a spec and expecting a near-complete result. On my tracker rebuild, the max-effort run needed the least cleanup and took noticeably longer. The cost curve is real — max on everything is how you burn a session budget on trivia. I went deeper on how the tiers behave in my effort levels review.
Tip 6: Notifications, or: stop being a spectator at your own job
The dumbest-simple tip fixed the most workflow. Boris runs task-completion notifications so long jobs don't require staring at a terminal. The mechanism is Claude Code's hooks system: a Stop hook fires when Claude finishes its task, a Notification hook fires when it needs input. Attach any shell command — on macOS, osascript gives you native notifications:
{
"hooks": {
"Stop": [{
"matcher": "",
"hooks": [{
"type": "command",
"command": "osascript -e 'display notification \"Claude finished\" with title \"Claude Code\" sound name \"Glass\"'"
}]
}],
"Notification": [{
"matcher": "permission_prompt",
"hooks": [{
"type": "command",
"command": "osascript -e 'display notification \"Needs your input\" with title \"Claude Code\" sound name \"Ping\"'"
}]
}]
}
}
Two sounds, two states, zero screen-watching. The meta-point is the mental model: if you're watching Claude Code work in real time, you are the bottleneck. Boris pairs this with using the Claude desktop app as a brainstorming surface while Claude Code runs — drafting the next spec so that when the ping lands, the next prompt is ready to fire. I copied that pattern during the retest and the dead time between build phases mostly disappeared.
Tip 7: The thinking toggle is dead — steer with phrasing
The one I got wrong, and the reason this post exists. On Opus 4.6 and earlier, you controlled extended thinking with an explicit budget: thinking: {"type": "enabled", "budget_tokens": N}. On Opus 4.7 that request returns a 400 error. Adaptive thinking — thinking: {"type": "adaptive"} — is now the only thinking-on mode: the model estimates task difficulty and allocates reasoning dynamically. (The same migration also removed non-default temperature, top_p, and top_k — worth checking your API wrappers.)
In Claude Code, you steer it with phrasing. "Think carefully step by step" signals a task worth spending reasoning on; "prioritize responding quickly" signals the opposite. And the nuance that took me a day to internalize: effort and thinking are separate knobs now. Effort is the total resource budget across the task — tool calls, file reads, retries. Thinking is per-step reasoning depth. High effort with quick thinking gives you many fast actions; lower effort with careful thinking gives you few deliberate ones. For frontloaded builds I run max effort plus "think carefully"; for a quick bug fix, xhigh plus "prioritize responding quickly" finishes in a fraction of the time without losing correctness.
The scorecard
Keeping permanently: auto mode for greenfield and personal work; frontloaded specs for anything beyond a one-file edit (the biggest quality jump of the seven); /recap as muscle memory on every session resume; Stop-hook notifications, which I'm embarrassed I didn't set up a year ago; and phrasing-steered adaptive thinking, because there is no toggle to go back to.
Keeping with caveats: max effort, only where the task justifies the cost; the Claude Code/OpenCode split, though the ecosystem gravity means I still reach for Claude Code first most days.
Walking back: nothing, honestly — which surprised me, because I started this retest half-expecting to write the "here's where Boris is wrong" post. Every tip held up under real work. If you want the fuller picture of how he runs his own days, I broke down Boris Cherny's daily Claude Code workflow separately.
The meta-tip underneath all seven: the developers getting the most out of Claude Code stopped acting like they're in a conversation with an AI and started acting like they're directing a small engineering team — parallel sessions, notifications instead of babysitting, specs instead of drip-fed instructions. After 8+ years and 1,500+ projects, that shift is the biggest single productivity change I've made, and it cost nothing but habits.
Pick one tip and run it for a full project before judging it — the frontloaded spec if you build, the Stop hook if you babysit. My 50 Claude Code tips collection continues where Boris's seven leave off, and because frontloading lives or dies on the quality of that first 150-word prompt, the tested versions I work from are in my prompt library.
