Anthropic's own team gave a "Claude Code best practices" talk. It's a good talk. It's also already out of date — not because the advice was wrong, but because half the tool it describes doesn't work that way anymore. (Anthropic's team has also published a written "Best practices for Claude Code" guide, first out in 2025 and updated since — a separate artifact from the talk, and just as fast-moving.)
That's not a knock on the talk. It's the actual shape of the problem. Claude Code ships fast enough that a best-practices guide has a shelf life measured in months, and most of what's published about it — including a lot of "best practices" content on this site — is teaching the single-threaded mental model: one Claude, one conversation, you watching the terminal and pressing enter. That model is gone. The tool underneath it has quietly become something closer to a small team of asynchronous workers you delegate to and check in on, and the features that made that shift are exactly the ones generic listicles skip because they don't fit a "10 tips" format.
Here are the six that actually change how you work, after running this across three different codebases — this site's own build-and-publish pipeline, product work at Jobsolv, and inside GrowthLayer's experiment tooling.
TL;DR
- Rewind (`Esc Esc` / `/rewind`) replaces the reflexive
git stash— but it only tracks Claude's own file edits, not Bash commands, so it is not a git replacement. - Auto mode replaces the all-or-nothing
--dangerously-skip-permissionsflag with a classifier that blocks scope escalation, unrecognized infrastructure, and prompt-injection-driven actions, while letting routine work run unattended. - Background subagents now run in the background by default, so Claude keeps working while they run and is notified when they finish — the shift from "delegate and wait" to "delegate and keep working" is the single biggest productivity change.
- Worktrees give each parallel session its own isolated branch and directory, which is what actually makes running multiple Claudes safe instead of just fast.
- Agent teams / dynamic workflows let you script fan-out and adversarial-verification patterns instead of hand-holding one thread through a checklist.
- A fresh-context reviewer subagent (
/code-reviewor a hand-written prompt) catches what the implementing session is structurally blind to — this is the practice with the best return on five minutes of setup.
| Feature | What it replaces | When it actually matters |
|---|---|---|
| Rewind / checkpoints | Manual git stash, "undo that" prompting | Any risky edit you want to try before committing to it |
| Auto mode | Shift-tab "always allow" | Long unattended runs where you still want a safety net |
| Background subagents | Watching one thread, one task at a time | Research, exploration, or verification you don't need to babysit |
| Worktrees | One directory, one branch, hope nothing collides | Running 2+ sessions on the same repo at once |
| Agent teams / workflows | A single long prompt with a mental checklist | Multi-stage work: review, then verify, then synthesize |
| Adversarial reviewer subagent | Skimming your own diff before committing | Anything you're about to ship unattended |
The failure mode most teams hit first: one thread, one branch, no isolation
The pattern shows up the same way almost every time a team scales past "one engineer, one Claude Code session." Someone kicks off a long-running refactor in the main working directory, then — because the terminal is sitting idle waiting on a slow tool call — opens a second Claude Code session in the same directory to knock out an unrelated fix. Both sessions are now writing to the same files. One of them loses.
The fix isn't "be more careful." It's worktrees — Claude Code can spin up an isolated git checkout per session, so two, three, or four parallel Claudes are editing genuinely separate copies of the repo, each on its own branch, with no collision possible. (This article, for what it's worth, was drafted inside exactly this kind of isolated worktree — it's not a hypothetical.) The desktop app manages this visually now; the CLI does it with the --worktree flag (Claude itself uses a separate internal tool to switch between worktrees mid-session, but that's not something you type). Once you've isolated the workspace, "run four Claudes at once" stops being a party trick and becomes a normal Tuesday.
The judgment call worth making explicitly: worktrees are for genuinely independent work — a bug fix and a feature build that don't touch the same files. If two tasks are going to want to touch the same three files, don't parallelize them; you're just moving the collision from mid-session to merge time.
Rewind fixes the fear of letting Claude try something risky
The old workflow, if you wanted to attempt something aggressive with Claude Code, was: commit first, let it try, git reset --hard if it went sideways. That's a reasonable instinct and also friction that makes people more conservative than they need to be.
Rewind — double-tap Esc, or /rewind — opens a menu that restores conversation, code, or both, to any earlier checkpoint in the session. Every prompt you send creates one automatically. The practical effect: you can tell Claude to try something genuinely risky — a different architecture, a rewrite instead of a patch — with the same confidence you'd have if you'd already committed, because rolling back costs one keystroke instead of a git incantation.
The diagnostic catch that matters here, and the one most people miss until it bites them: checkpoints only track changes made through Claude's own file-editing tools. Anything that happened via a Bash command — a script that touched the filesystem, a database migration Claude ran, a git commit it made on your behalf — is not captured. Rewind is a session-scoped undo for Claude's edits, not a replacement for git, and treating it like one is how you lose work you thought was recoverable.
Auto mode is a real safety net, not a bigger "yes to everything" button
At the time of that Anthropic talk, the state of the art for reducing permission-prompt fatigue was shift-tab "auto-accept edits" — and it wasn't actually all-or-nothing, just narrower than people treated it: it covers file edits and a handful of safe filesystem commands, and still prompts for everything else. The genuine all-or-nothing option was a separate, more drastic bypass-permissions mode — the one meant only for isolated containers, never your host machine.
Auto mode is a different mechanism entirely: a separate classifier model reviews each action before it runs and blocks the categories that actually warrant a human — scope escalation beyond what you asked for, unfamiliar infrastructure, anything that looks like it's responding to instructions smuggled in through file contents rather than you. Routine work — the file edits and test runs you'd have rubber-stamped anyway — proceeds without a prompt.
The methodology call worth making deliberately: match the mode to blast radius, not to how much you trust the model that day. A scoped refactor inside a feature branch, in a worktree that isn't touching production config or secrets, is a reasonable candidate for auto mode. Anything touching deploy config, database migrations against a real dataset, or secret rotation stays on manual approval regardless of how good the last ten runs were — the cost of one bad unattended action there is not symmetric with the time you saved on the other nine.
Background subagents changed the unit of work from "task" to "batch of tasks"
This is the one that actually restructures how a session feels. Subagents can run in the foreground, where your main thread blocks until the sub-task reports back, or in the background, where the work runs asynchronously — you get notified once it's done — and your main thread keeps going in the meantime. As of a mid-2026 release, background became the default behavior rather than an option you had to reach for: Claude now runs a subagent in the foreground only when it needs the result immediately, whereas before it chose per task.
The behavioral shift this produces is the real story. Instead of "ask Claude one thing, wait, ask the next thing," the unit of work becomes a batch: kick off three independent investigations — check how the auth flow handles token refresh, audit a config file for drift, draft a migration plan — and keep working on whatever's in front of you while all three run in parallel. The pattern I've settled on after running this across build-and-publish tooling, product features, and experiment infrastructure: anything that's read-heavy and doesn't need my judgment mid-task is a background-subagent candidate by default, not an exception. The bottleneck was never Claude's throughput. It was always me, single-threaded, waiting on one thing at a time out of habit.
Agent teams turn "review your own work" into infrastructure instead of a courtesy
The most durable piece of advice from that Anthropic talk — and from Anthropic's current documentation — hasn't changed: give Claude a way to verify its own work, and have a subagent — or, for larger reviews, a separate session — check the output in a fresh context before you treat the task as done. What's new is that this pattern is now something you can script and run as standing infrastructure instead of remembering to do it manually every time.
A fresh-context reviewer catches things the implementing session is structurally blind to, because it never generated the plausible-but-wrong version in the first place — it's evaluating the diff cold, against the stated requirements, with no attachment to the reasoning that produced it. Anthropic ships this as a bundled /code-review skill that spins up exactly that: a subagent that only sees the diff and the criteria, not the conversation that led there. For anything with more moving parts — multiple independent findings that each need an adversarial check, or a review that should run across several dimensions in parallel — dynamic workflows let you compose that same pattern (fan out to N reviewers, verify each finding independently, synthesize) as a repeatable script instead of a one-off prompt you have to remember to write again.
The content pipeline behind this very site runs a version of this: generation, then a separate review pass, then a human approval step before anything goes live. The shape generalizes past content — anywhere the cost of a wrong unattended answer is higher than the five minutes it takes to add a second opinion, the second opinion is worth infrastructure, not a reminder.
Where this leaves the "best practices" advice that's still true
None of this replaces the fundamentals — a tight CLAUDE.md, deliberate context management, planning before you let Claude execute. Those hold up regardless of which release you're on, and the token-economics case for disciplined context management hasn't changed with any of these features. What's changed is the ceiling on what "good practice" gets you. A well-managed single session was the best you could do a few months ago. Isolated parallel sessions, unattended runs with a real safety net, and standing adversarial review are the best you can do now, and most teams are still operating like it's still a few months ago.
Bottom line: the tool didn't get incrementally better — it changed shape, from one assistant you prompt to a small team of workers you orchestrate. Rewind removes the fear of trying something risky. Auto mode replaces blind trust with a real filter. Background subagents turn one task at a time into a batch. Worktrees make running several Claudes at once safe instead of just fast. Agent teams turn code review from a courtesy into infrastructure. If you're still running one Claude in one directory and clicking "allow" on every write, you're not doing anything wrong — you're just leaving the newest and highest-leverage half of the tool on the table.
FAQ
Do I need the desktop app to use worktrees, or does the CLI support it too?
Both. The desktop app manages worktrees visually — each parallel session shows up with its own isolated checkout. The CLI does the same thing through the --worktree (-w) flag; it's a bit more manual but works identically underneath. (EnterWorktree is the internal tool Claude itself calls to create or switch into a worktree mid-session — not something you type yourself.)
Is auto mode safe to leave on all the time?
Match it to blast radius rather than treating it as a global setting. It's a reasonable default for scoped work in an isolated branch. It's not a substitute for manual review on anything touching production infrastructure, secrets, or a real database — the classifier reduces risk, it doesn't eliminate it.
Does rewind replace committing to git as I go?
No, and this is the mistake to avoid. Rewind only restores changes made through Claude's own file-editing tools — not anything that happened via a Bash command it ran on your behalf. Keep committing normally; treat rewind as a fast undo for Claude's edits specifically, not a git replacement.
What's the difference between a subagent and a background subagent?
A regular subagent delegates a sub-task and your session waits for the result before continuing. A background subagent runs the same delegation asynchronously — you keep working, and get notified when it's done. The API is similar; the difference is entirely about whether your main thread blocks on it.
Do I need to write a formal workflow script to get the adversarial-review benefit, or is a simple prompt enough?
A simple prompt gets you most of the value: ask a fresh session (or the bundled /code-review skill) to review a diff against your stated requirements before you commit. Reach for a scripted workflow only when you need the pattern to repeat consistently — multiple independent findings each needing their own check, or a review you want to run the same way every time without re-writing the prompt.
Sources: Anthropic — Best practices for Claude Code, Anthropic — Claude Code changelog, fetched 2026-07-15.