Claude Code Practice — the 2026 method

What changed

4 shifts

Most tutorials teach the early-2026 workflow: CLAUDE.md, plan mode, per-tool approvals, the occasional subagent. Not wrong — just first gear. Claude Code stopped being “an AI that edits files” and became a runtime for fleets of agents.

Boris Cherny (creator), June 2026: stopped using plan mode entirely — “the newer models don't actually need a planning step.” His work now “looks less like typing prompts and more like managing armies of agents.”

Cat Wu (Head of Product): “The model performs best if you treat it like an engineer you're delegating to, not a pair programmer you're guiding line by line.”

The four shifts

From	To
Plan mode & approve each step	One complete brief + auto mode
Prompt engineering → context engineering	Context minimalism — lean prompt, a way to fetch
Correcting in chat	Writing a rule so it never recurs
One agent, one conversation	A harness sized to the task

The corollary is uncomfortable: if you interrupt Claude often, the brief was incomplete — not the model weak.

Verification — the primary lever

2–3×

Cherny calls this “probably the most important thing to get great results out of Claude Code” — worth an estimated 2–3× on final quality. The official best-practices doc leads with it.

Claude stops when the work looks done. With no check it can run, “looks done” is the only signal — and you become the verification loop, so every mistake waits for you to notice. Give it a pass/fail and the loop closes itself.

The ladder — setup cost vs. unattended reliability

Rung	Mechanism	When
1 In‑prompt	“…then run the tests and fix failures”	Any task, zero setup
2 `/goal`	Fast model re‑checks after every turn; Claude keeps going	Verifiable end state
3 Stop hook	Script blocks the turn ending until the check passes	Must hold every session
4 Adversarial	Fresh agent sees only the diff + criteria, tries to refute	High stakes, long runs

Rung 4 matters because the agent that did the work is the worst judge of it — models carry a self-preferential bias. A reviewer in fresh context never saw the reasoning, so it judges the result on its merits. That's why /code-review runs in a subagent.

Caveat from the docs: a reviewer told to find gaps will find some, even when the work is sound — that's what it was asked to do. Chasing all of them yields over-engineering. Say: “flag only gaps that affect correctness or the stated requirements.”

Rewrite your prompts

✗ implement email validationno check exists ✓ write validateEmail. tests: a@b.com true, 'invalid' false, 'a@.com' false. run them. ✗ make the dashboard look betterunfalsifiable ✓ [screenshot] implement this. screenshot the result, compare, list differences, fix them. ✗ the build is failinginvites symptom-suppression ✓ build fails with: [paste]. fix, verify it succeeds, address the root cause.

Ask for evidence, not assertions. “Show me the test output” beats “confirm it works” — and it works for sessions you weren't watching.

Context is the budget

5 tools

Performance degrades as the window fills. Everything read, every command output, every failed attempt lives there. A 1M window doesn't exempt you — it moves the cliff.

Tool	What it does	Use when
`/clear`	Wipes context entirely	Between unrelated tasks — far more than you do
`/compact`	LLM summary; cheap, fuzzy on detail	Mid-task, running long
`/rewind`	Jump back; restore chat, code, or both	A failed attempt happened
`/btw`	Answer never enters history	Side question mid-task
Subagents	Read in a separate context, report a summary	Any multi-file investigation

Two rules from the team

After two failed corrections, /clear and rewrite the prompt with what you learned. A clean session with a good prompt beats a long one full of dead ends.
Prefer /rewind to correcting in chat. Correcting leaves the wrong approach in context, still influencing the model. Rewinding deletes it. Want the lesson? “Summarize from here” before rewinding.

CLAUDE.md discipline

It loads every session, so it is precious real estate. The failure mode is bloat: too long and Claude ignores half of it because the real rules drown. Test every line: would removing this cause a mistake? If not, cut it.

✓ Include

Commands Claude can't guess
Style rules that differ from defaults
Test runner; how to run one test
Branch / PR conventions
Env quirks, required vars
Non-obvious gotchas

✗ Exclude

Anything derivable from the code
Standard language conventions
API docs — link instead
Anything that changes often
File-by-file descriptions
“Write clean code”

Diagnostics: Claude violates a rule you wrote → the file is too long. Claude asks what the file answers → the phrasing is ambiguous. IMPORTANT works on one line; emphasise everything and nothing stands out. /doctor proposes cuts for a checked-in file.

Allocation rule: broad rules → CLAUDE.md. Sometimes-rules → a skill, loaded on demand, costing nothing until relevant.

The delegation brief

turn 1

Delegation means full task context in turn 1. Think hard once rather than iterating fast.

GOAL what "done" looks like, one line CONTEXT which files; what pattern to follow ("look at HotDogWidget.php") LIMITS what must not change; out of scope; libraries you will and won't accept VERIFY the command that proves it works

Let Claude interview you

For anything large, start minimal and make Claude extract the spec:

I want to build [one line]. Interview me in detail using the AskUserQuestion tool. Ask about implementation, UI/UX, edge cases, concerns and tradeoffs. Don't ask obvious questions - dig into the hard parts I might not have considered. Keep going until we've covered everything, then write SPEC.md.

Then /clear and execute the spec fresh. Clean context, written reference. Precision in the spec pays more than watching the implementation.

Three more

Challenge it. “Grill me on these changes.” “Prove this works — show the diff and test output.” Don't accept the first solution.
Ask like you'd ask a senior engineer. “How does logging work?” “Why foo() not bar() on line 333?” Best onboarding tool there is.
Use voice (/voice, hold spacebar). ~3× faster, and briefs should be long now.

The parallelism ladder

5 rungs

Five primitives. Each is a different answer to “who holds the plan?” Picking the right rung is the real skill.

Rung	Who decides next	Scale	For
Worktrees	You	3–5	Independent features, no collisions
Agent view	You, one screen	Many	Watching / steering background work
Subagents	Claude, turn by turn	A few	Research, verification
Workflows	A script	10s–100s	Migrations, audits, sweeps
Agent teams	A lead agent	A handful	Debate, competing hypotheses

1 · Worktrees

Cherny: running 3–5 git worktrees at once is “the single biggest productivity unlock.”

claude --worktree oauth-migrationisolated checkout, own session claude --worktree x --tmux…in a tmux pane claude --add-dir ../other-repoone session, several repos

Name them, alias them (za, zb, zc), and /color each session so you can tell them apart at a glance.

2 · Agent view

claude agents — every session grouped Needs input / Working / Completed. Your control plane past two parallel things. /rename religiously (or a UserPromptSubmit hook that auto-renames) or the list becomes unreadable.

3 · Subagents — cheapest, most underused

Just append “use subagents” to a hard prompt. They read 40 files in their context and hand back a paragraph. Two canonical uses: research and adversarial verification. Define reusable ones in .claude/agents/.

--- name: security-reviewer description: Reviews code for vulnerabilities tools: Read, Grep, Glob, Bash model: opus --- You are a senior security engineer. Review for injection, authN/authZ flaws, secrets in code, insecure data handling. Cite specific lines.

4 · Dynamic workflows — the big one

A JavaScript script that orchestrates subagents at scale. Claude writes it; a runtime executes it in the background while your session stays responsive. The critical difference: the plan moves out of a context window and into code. Loops, branching and intermediate results live in script variables — your context only ever holds the final answer.

use a workflow to …natural-language trigger ultracode: <task>keyword trigger, one turn /effort ultracodexhigh + workflows, all session /deep-research <q>bundled; cross-checks + votes on claims /workflowswatch · p pause · x stop · s save as command

Workflows exist to fix three single-agent failure modes: agentic laziness (declares done early), self-preferential bias (likes its own work), and goal drift (detail lost through summarisation).

Six patterns Claude composes: classify-and-act · fan-out-and-synthesize · adversarial verification · generate-and-filter · tournament (pairwise beats absolute scoring for ranking) · loop-until-done.

Cost: token-hungry — save them for big jobs. Test on one directory first. Budget in the prompt (“use 10k tokens”); /usage shows spend by skill, subagent, plugin, MCP. Caps: 16 concurrent, 1,000 agents/run.

5 · Agent teams (experimental)

Enable with CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1. The one case where teams beat everything else is adversarial debate:

Spawn 5 teammates to investigate different hypotheses. Have them talk to each other and try to disprove each other's theories, like a scientific debate. Write the consensus to DIAGNOSIS.md.

Sequential investigation suffers anchoring — once one theory is explored, everything after bends toward it. Independent falsifiers mean the surviving theory is far more likely to be the real cause. Start with 3–5.

Also

/batch <instruction> splits a change across 5–30 subagents, each in its own worktree, each opening a PR. /simplify runs parallel quality agents. Type @ to message another running session instead of re-explaining a finding.

Making it permanent

compounding

The single highest-leverage idea on this page: when Claude gets something wrong, write a rule, not a correction. A correction fixes one turn; a rule fixes every future run. Your error rate should trend down over months.

Mechanism	Loads	Enforcement	For
`CLAUDE.md`	Every session	Advisory	Always-applies conventions
Skills	On demand	Advisory	Domain knowledge, workflows
Hooks	Lifecycle events	Deterministic	Zero-exception rules
Output styles	System prompt	Advisory	A different role or format

Skills — the rule of thumb

Anything you do more than once a day becomes a skill or command. Check them into git; they compound and they travel between projects.

.claude/skills/fix-issue/SKILL.md --- name: fix-issue description: Fix a GitHub issue disable-model-invocation: true --- Analyze and fix issue: $ARGUMENTS 1 gh issue view 2 search codebase 3 implement 4 write + run tests 5 lint 6 commit 7 PR

Now /fix-issue 1234 works. disable-model-invocation: true keeps Claude from firing it unprompted — right for anything with side effects.

Hooks — highest-value five

Event	Does
`PostToolUse`	Auto-format after every edit — kills a class of nitpicking
`Stop`	Run the test suite; block the turn ending until it passes
`PostCompact`	Re-inject critical instructions after compression
`UserPromptSubmit`	Auto-rename the session so agent view stays readable
`Notification`	Ping you when a long task finishes or needs input

You don't hand-write these. Ask: “write a hook that runs prettier after every file edit” or “write a hook that blocks writes to the migrations folder.” Browse with /hooks.

Two quick wins: /fewer-permission-prompts scans transcripts and recommends a safe allowlist; /doctor is a full setup checkup that can fix what it finds.

Coding without an IDE

replacements

Symbol navigation & error detection

The piece most ex-IDE users miss. Code-intelligence plugins give Claude precise symbol navigation and automatic error detection after edits — the actual value an IDE provided. Install one per typed language you use: /plugin.

Review — the new bottleneck

Anthropic saw a 200% increase in code output; review immediately became the constraint.

Command	Does
`/code-review`	Correctness bugs in a fresh subagent. `--fix`, `--comment`
`/code-review ultra`	Multi-agent cloud review of branch or PR (billed)
`/simplify`	Quality only: reuse, simplification, efficiency
`/security-review`	Security review of pending changes
`/go`	Composite: verify end-to-end → simplify → PR

Closing the loop on GUI-only things

Chrome drives a real browser — click, fill, read console and network, screenshot; the team reports it is more reliable than Playwright for E2E. Computer use opens native apps from the terminal. /run launches and drives the project's app.

Effort

/effort highsensible default on Opus 5 /effort xhighhard problems, async work /effort maxhardest tasks; current session only /effort ultracodexhigh + automatic workflows

When you're away

claude remote-control drives a local session from phone or claude.ai/code. --teleport moves a session between local and cloud. Routines and cloud sessions run after you close the laptop.

Beyond code — the workshop

electronics · CAD · print

Claude Code is not a coding tool. It is an agent with a shell, a filesystem and a verification loop. Anything with a directory of files and a command that returns pass/fail is native territory.

At Anthropic: lawyers built phone-tree systems, marketers generated hundreds of ad variations, data scientists shipped React apps without knowing JavaScript. None of it is coding. The thread is file access plus a checkable result.

Step 1 — stop it being a software engineer

A custom output style replaces the system prompt's engineering instructions. Omit keep-coding-instructions entirely when the work isn't software.

~/.claude/output-styles/workshop.md --- name: Workshop description: Hardware / fabrication helper --- Priorities: physical safety, then correctness against datasheets, then buildability with the tools on hand. - Cite the datasheet page for any claim. - Never a bare number: units, tolerance, margin. - Ask rather than assume conditions. - Say how to verify it once built.

Step 2 — find the verification loop

This is the whole game. The discipline with a pass/fail CLI is the discipline where Claude is transformative.

Discipline	The check
Arduino / embedded	`arduino-cli compile` · `pio run` · serial monitor
Raspberry Pi	`ssh pi 'systemctl status x; journalctl -u x'`
PCB design	`kicad-cli sch erc` · `kicad-cli pcb drc`
Parametric CAD	`openscad -o preview.png` → Claude looks at it
3D printing	slicer CLI → time, filament, warnings as numbers
Sensors / data	any script that prints numbers

The CAD row is the one people miss. Claude reads images, so geometry gets a closed loop:

Add a 3mm fillet at the base of bracket.scad. Render: openscad -o preview.png --imgsize=1200,900 \ --camera=0,0,0,55,0,25,140 bracket.scad Then look at preview.png: is the fillet there, and did anything else change? Iterate until it's right.

Same trick for slicing: read back layer count, time, filament and slicer warnings. Overhang warnings and support volume become a numeric signal to optimise against.

Step 3 — the right rung

Deep research is the killer app for hardware. Component selection is exactly where a single pass gives a confident, wrong answer about a pin that doesn't exist. Fan-out + cross-check + vote gives you cited datasheet comparisons instead.

/deep-research Compare INA219 / INA226 / INA228 for 0-5A at 48V: accuracy, common-mode limits, I2C addresses, availability, price at qty 10. Cite datasheets.

Adversarial teams for intermittent faults — the “it must be the power supply” anchoring trap that eats weekends. Give 4 teammates brownout / watchdog / heap / RF, the serial logs, and instructions to falsify each other.

Workflows for parametric sweeps — “20 variants across wall thickness 2–5mm, slice each, report mass / time / overhang volume, rank them” is fan-out-and-synthesize exactly.

Step 4 — workshop ergonomics

Tool	Why it matters at the bench
`/voice`	Hands hold the iron, not the keyboard
`remote-control`	Session on the workstation, driven from your phone
Monitor tool	Tails a live serial / print / sensor stream, reacts to events
`/loop 10m`	Poll the printer endpoint; alert on failure
Artifacts	Live shareable BOM, wiring reference, build log
`/dataviz`	Characterisation curves, thermal profiles

Step 5 — skills stop knowledge evaporating

~/.claude/skills/ ├── bench-inventory/ what's actually in the drawers ├── kicad-conventions/ net naming, footprints, DRC rules ├── openscad-house-style/ modules, $fn, tolerances ├── printer-profiles/ nozzles, materials, real shrinkage └── esp32-gotchas/ strapping pins, ADC2/WiFi conflict

bench-inventory is quietly the best of these. “Design a driver circuit” gets a far more useful answer when Claude knows what's in your parts drawers.

Anti-patterns

8

Pattern	Symptom	Fix
Kitchen sink session	Task, tangent, back again	`/clear` between unrelated tasks
Correcting over and over	Third correction, still wrong	After two: `/clear`, better prompt
Over-specified CLAUDE.md	Ignores rules you wrote	Prune; move sometimes-rules to skills
Trust-then-verify gap	Plausible code, broken edges	Can't verify it → don't ship it
Infinite exploration	“Investigate X” eats context	Scope it, or use subagents
Correcting, not ruling	Same mistake forever	Write the rule. This is the one.
Workflows for small jobs	Huge bill, tiny change	Workflows are for big fan-outs
Interrupting constantly	Redirecting every few minutes	The brief was incomplete

The starter kit

download

Four files that turn the ideas above into configuration. Copy them into ~/.claude/ and adapt. Nothing here is specific to one machine.

~/.claude/ ├── output-styles/workshop.md bench-engineer role, not a coder ├── skills/bench-inventory/SKILL.md + inventory.md you fill in ├── hooks/format.sh PostToolUse(Write|Edit) └── settings.json where the hook is registered

Get the files

File	What it is
`workshop.md`	Output style: safety → datasheets → buildability. Drops the coding prompt
`bench-inventory/SKILL.md`	Makes Claude design against parts you actually have
`inventory.md`	The inventory template it reads. Worthless until filled in
`format.sh`	Auto-format hook; dispatches by extension, skips missing formatters

Register the hook

"hooks": { "PostToolUse": [{ "matcher": "Write|Edit", "hooks": [{ "type": "command", "command": "~/.claude/hooks/format.sh", "timeout": 30 }] }] }

The hook silently skips any formatter that isn't installed, so it does nothing until you install one and then starts working with no further config. Test it before trusting it: introduce a formatting error through an edit and check the file comes back corrected.

The inventory file is a template. It is only worth anything once filled in; an empty section means “not recorded”, and the skill tells Claude to ask rather than assume.

The ladder

in order

This week — 30 minutes

Run /deep-research on a real question. Fastest way to feel the difference.
Next time you correct Claude, stop: should this be a rule? Then write it.
Fill in inventory.md with what is actually on your bench.
/config → Output style → Workshop, for a hardware session.

Next week

Add use a workflow to your next multi-file task; watch /workflows.
Set up 2–3 worktrees; alias them.
Turn your most-repeated prompt into a skill.
Add a Stop hook that runs the test suite.

The month after

Try /goal on something substantial — and walk away.
Try an agent team on a debugging problem you're genuinely stuck on.
Run one hard session at /effort ultracode.
Write the second and third workshop skills.

The one-paragraph version

Give Claude a way to check its own work — that is the whole ballgame. Write one complete brief instead of steering turn by turn. Guard context like a budget: /clear often, /rewind past failures, delegate reading to subagents. When Claude gets something wrong, write a rule rather than a correction, so your setup compounds instead of resetting. And when a job is bigger than one conversation can hold, don't hold it — move the plan into a harness. None of this is specific to code.

Claude Code Practice how the people who built it actually use it

▾The Method

The four shifts

The ladder — setup cost vs. unattended reliability

Rewrite your prompts

Two rules from the team

CLAUDE.md discipline

✓ Include

✗ Exclude

Let Claude interview you

Three more

1 · Worktrees

2 · Agent view

3 · Subagents — cheapest, most underused

4 · Dynamic workflows — the big one

5 · Agent teams (experimental)

Also

Skills — the rule of thumb

Hooks — highest-value five

Symbol navigation & error detection

Review — the new bottleneck

Closing the loop on GUI-only things

Effort

When you're away

Step 1 — stop it being a software engineer

Step 2 — find the verification loop

Step 3 — the right rung

Step 4 — workshop ergonomics

Step 5 — skills stop knowledge evaporating

Get the files

Register the hook

This week — 30 minutes

Next week

The month after

The one-paragraph version

▾Move index

In the prompt

Across a session

Second opinion

Reset & reshape

Keep it out of context

CLAUDE.md

Worktrees & sessions

Subagents

Dynamic workflows

Agent teams

The core habit

Skills

Hooks — deterministic

Config & setup

The reframe

Verification loops by discipline

Bench ergonomics

Research & diagnosis

Context traps

Judgement traps