Claude Code — the 2026 Method

00Start here

Most Claude Code tutorials — including good ones — teach the early-2026 workflow: write a CLAUDE.md, use plan mode, approve permissions one at a time, clear context between tasks, maybe use a subagent.

That advice is not wrong. It is incomplete in a way that costs most of the leverage. Between March and August 2026, Claude Code stopped being "an AI that edits your files" and became a runtime for fleets of agents. The people who built it changed how they use it accordingly.

Two statements from the Claude Code team anchor the shift:

Boris Cherny, creator and head of Claude Code, June 2026: he stopped using plan mode entirely — "the newer models don't actually need a planning step." His workflow now "looks less like typing prompts and more like managing armies of agents."

reflecting on a year of Claude Code

Cat Wu, head of product for Claude Code: "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."

Everything below follows from those two sentences.

01Audit your own setup first

Before any technique, check what you have. Most people who feel Claude Code is "fine but not transformative" are running it with nothing configured — every session starts from zero and every correction dies when the session ends.

Run these and see what comes back:

claude --version                 # are you actually current?
ls ~/.claude/skills/             # domain knowledge, loaded on demand
ls ~/.claude/agents/             # reusable subagent definitions
ls ~/.claude/commands/           # repeated workflows
ls ~/.claude/workflows/          # saved orchestrations
grep -c hooks ~/.claude/settings.json   # deterministic rules
ls ~/.claude/projects/*/memory/  # auto-memory: what Claude has kept about you
claude mcp list                  # tools beyond the shell (browser, mail, trackers)

02The four shifts

Plan mode → auto mode plus a full brief

The old loop: prompt → Claude plans → you read the plan → you approve → Claude codes → you approve fifteen tool calls. The new loop: you write one complete brief, Claude works, you review the result.

Plan mode still earns its place when you are uncertain about the approach or unfamiliar with the code. But for work where you know what you want, the planning step is now overhead — modern models plan implicitly. Auto mode, a separate classifier that reviews each action and blocks only genuinely risky ones, removes the per-tool prompts.

The corollary is uncomfortable but true: if you find yourself interrupting Claude often, your brief was incomplete, not the model weak.

Prompt engineering → context minimalism

The arc ran: prompt engineering (craft the magic words) → context engineering (stuff the right context in) → context minimalism (give a lean prompt, minimal tools, and a way to fetch context; let the model work out the rest).

Concretely: don't paste six files into your prompt. Say "read src/auth/ and the last twenty commits touching it" and let Claude pull what it needs — ideally through a subagent, so the reading never lands in your context at all.

Correcting in chat → writing rules

Covered above. This is the one that compounds.

One agent → a harness per task

There is now a ladder of orchestration primitives, and picking the right rung is a real skill. That is section 06.

03Verification — the primary lever

The logic is simple. Claude stops when the work looks done. Without a check it can run, "looks done" is the only signal available — and you become the verification loop. Every mistake waits for you to notice it.

Give Claude something that returns pass or fail and the loop closes on its own: Claude does the work, runs the check, reads the result, iterates.

The ladder

Four rungs, in increasing order of setup cost and of how reliably an unattended run finishes correctly:

Rung 4 deserves its own note. The agent that did the work is the worst judge of the work — models carry a self-preferential bias toward their own output. A reviewer in a fresh context sees the diff and your criteria but not the reasoning that produced them, so it evaluates on the merits. That is why /code-review runs in a subagent.

Rewrite your prompts

✗  implement email validation
✓  write validateEmail. test cases: a@b.com true,
   'invalid' false, 'a@.com' false. run the tests after implementing.

✗  make the dashboard look better
✓  [paste screenshot] implement this. take a screenshot of the result,
   compare it to the original, list the differences, fix them.

✗  the build is failing
✓  the build fails with: [paste]. fix it, verify the build succeeds,
   address the root cause — don't suppress the error.

And always: ask for evidence, not assertions. "Show me the test output" beats "confirm it works." Reviewing evidence is faster than re-running the check yourself, and it works for sessions you were not watching.

04Context is the budget

Performance degrades as the context window fills. Everything Claude reads, every command output, every failed attempt lives there. A million-token window does not exempt you — it moves the cliff.

Five tools, each for a different job. Most people know two.

Two rules of thumb

• After two failed corrections on the same issue, clear and start over with a better prompt incorporating what you learned. A clean session with a good prompt beats a long session full of failed approaches, every time.
• Prefer rewinding to correcting in chat. Correcting leaves the wrong approach in context, where it keeps influencing the model. Rewinding deletes it. To keep the lesson, summarise from that point before rewinding.

CLAUDE.md discipline

Your CLAUDE.md loads on every single session. That makes it precious real estate, and the most common failure is bloat: if it is too long, Claude ignores half of it because the important rules get lost in the noise.

The test for every line: "would removing this cause Claude to make a mistake?" If not, cut it.

Diagnostics. If Claude keeps violating a rule you wrote, the file is too long. If Claude asks questions the file answers, the phrasing is ambiguous. IMPORTANT works — but only on one line; emphasise everything and nothing stands out.

05How to write a prompt now

Delegation means full task context in turn one: goal, constraints, acceptance criteria. Think hard once rather than iterating fast.

GOAL        what "done" looks like, in one sentence
CONTEXT     which files; what pattern to follow
            ("look at HotDogWidget.php — follow that pattern")
CONSTRAINTS what must not change; what is out of scope;
            libraries you will and will not accept
VERIFY      the exact command or check that proves it works

Let Claude interview you

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

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

Then clear the context and execute the spec in a fresh session. Clean context, written reference. Time spent making the spec precise pays off far more than time spent watching the implementation.

Three more techniques

• Challenge the output. "Grill me on these changes." "Prove this works — show me the diff and the test output." Don't accept the first solution.
• Ask codebase questions like you would ask a senior engineer. "How does logging work?" "Why does this call foo() instead of bar() on line 333?" No special prompting needed — this is the best onboarding tool there is for unfamiliar code.
• Use voice. Roughly three times faster than typing for long briefs — and briefs should be long now.

06The parallelism ladder

This is where the leverage lives, and where most tutorials stop. Five rungs, each a different answer to "who holds the plan?"

Worktrees

Cherny calls running three to five git worktrees simultaneously "the single biggest productivity unlock." Each is an isolated checkout with its own session, so edits never collide.

claude --worktree oauth-migration          # isolated checkout + session
claude --worktree oauth-migration --tmux   # …in a tmux pane
claude --add-dir ../other-repo             # one session, several repos

Name them, alias them so switching is one keystroke, and give each session a distinct colour so you can tell them apart at a glance.

Agent view

claude agents gives one screen for every session, grouped Needs input / Working / Completed. This is your control plane once more than two things are running. Rename sessions religiously — or set a hook to do it — or the list becomes unreadable.

Subagents — the cheapest, most underused

Just append "use subagents" to a hard prompt. Two canonical uses: research ("investigate how our auth handles token refresh, and whether we have existing OAuth utilities to reuse") and adversarial verification. They read forty files in their context and hand you back a paragraph.

Fork or fresh — decide deliberately. Since 2.1.232 a subagent forks by default: it inherits the whole conversation and the prompt cache, so it starts already knowing what you have discussed. That is right for "go finish the thing we just designed." It is exactly wrong for review — a fork inherits your reasoning and its bias. For verification, name a fresh agent type (Explore, code-reviewer, one of your own) or say "in a fresh context, seeing only the diff."

Sessions talk to each other. Type @ in the prompt to mention another running session; ListAgents and SendMessage do the same from inside a turn, across worktrees, machines and Remote Control. The canonical use: the session that owns the shared interface finishes, then tells the three sessions waiting on it — instead of you relaying.

---
name: security-reviewer
description: Reviews code for security vulnerabilities
tools: Read, Grep, Glob, Bash
model: opus
---
You are a senior security engineer. Review for injection (SQL, XSS,
command), authN/authZ flaws, secrets in code, insecure data handling.
Provide specific line references and suggested fixes.

Dynamic workflows — the big one

A dynamic workflow is a JavaScript script that orchestrates subagents at scale. Claude writes the script; a runtime executes it in the background while your session stays responsive.

The critical difference from everything above: 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. That is what makes hundreds of agents possible.

use a workflow to audit every route handler under src/routes/ for
missing auth checks, and adversarially verify each finding

ultracode: <task>        # keyword trigger, single turn
/effort ultracode        # xhigh + automatic workflows, whole session
/deep-research <question> # bundled: fans out, cross-checks, cites
/workflows               # watch · p pause · x stop · s save as command

Workflows exist because they fix three specific failure modes of a single agent:

1. Agentic laziness — partial progress, declares done early.
2. Self-preferential bias — the model likes its own work; a separate verifier does not.
3. Goal drift — detail lost through summarisation; isolated agents hold focused goals.

Six patterns Claude composes from: classify-and-act, fan-out-and-synthesize, adversarial verification, generate-and-filter, tournament (pairwise comparison beats absolute scoring when ranking many items), and loop-until-done.

They are token-hungry. Save them for the biggest jobs, not twenty-line tweaks. Test on one directory before running on a whole repo. You can budget directly in the prompt ("use 10k tokens").

Agent teams

Experimental and off by default. The one case where teams beat everything else is adversarial debate:

Users report the app exits after one message instead of staying
connected. 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 from anchoring — once one theory is explored, everything after bends toward it. Independent investigators actively trying to falsify each other produce a surviving theory far more likely to be the real cause. Start with three to five.

07Making it permanent

Memory — the one most people have never opened

Claude keeps a per-project memory directory (~/.claude/projects/<project>/memory/): one fact per file with a short frontmatter, and a MEMORY.md index that is loaded into every session. Four kinds — user (who you are), feedback (corrections you gave, with the why), project (goals and constraints not derivable from the code) and reference (URLs, tickets, dashboards). Claude writes them on its own; /remember forces one.

The allocation test, extended: if it is in git, it is not a memory. If it is a convention, it is CLAUDE.md. If it is something Claude could only learn by working with you, it is a memory. "George prefers evidence over assertions" is a memory. "Run tests with make check" is not.

Read the index every month or so. Stale memories are worse than none — a pointer to a file you renamed in June will be followed in September. Delete freely; it is a directory of markdown, nothing more.

Sessions are permanent too

claude --continue            # pick up the most recent session here
claude --resume              # choose from this directory's sessions
claude remote-control --continue   # …and drive it from your phone

A session you name is a session you can find. Name them by outcome ("oauth-migration-tests-green"), not by topic — the agent view sorts by state, and the name should tell you what "done" meant.

Skills

The rule of thumb from the team: if you do something more than once a day, make it a skill or a 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 the GitHub issue: $ARGUMENTS.
1. gh issue view    2. search the codebase   3. implement the fix
4. write+run tests  5. lint and typecheck    6. commit  7. open a PR

Now /fix-issue 1234 works. disable-model-invocation: true means Claude will not fire it on its own — right for anything with side effects.

Hooks

Hooks are deterministic; CLAUDE.md is advisory. Anything you truly cannot tolerate being skipped belongs in a hook.

You do not have to 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."

08Models and effort — where to spend

The single most expensive habit of advanced users is running the strongest model at the highest effort for everything, including grep. Spend judgement on judgement; spend nothing on reading.

/model                 # switch the main session
/effort low|medium|high|xhigh|max   # reasoning budget per turn
/effort ultracode      # xhigh + workflows by default, whole session
/fast                  # Opus at faster output — not a smaller model
/advisor fable         # a stronger model consulted on the hard turns
/usage                 # what is actually driving your limits — by skill, plugin, MCP, subagent

Effort is per-agent, not per-session. In a subagent definition or a workflow call, effort: low on the stage that reads files and effort: max on the stage that judges them is the difference between a workflow you can afford to run nightly and one you run once. The same goes for model:. A ten-finder, three-judge review with Sonnet finders and an Opus judge costs a fraction of the all-Opus version and finds the same bugs.

09Coding without an IDE

Symbol navigation and error detection

The piece most people who drop their IDE miss. Code-intelligence plugins give Claude precise symbol navigation and automatic error detection after edits — which is the actual value the IDE was providing. Install one for every typed language you use.

Review, the new bottleneck

Anthropic reported a 200% increase in code output after adopting Claude Code, and review immediately became the constraint.

/code-review high          # broader; high/xhigh/max run in the background
/code-review --fix         # apply the findings to the working tree
/code-review ultra [PR#]   # multi-agent review in the cloud, billed, user-triggered
/code-review --comment 123 # post findings as inline PR comments

Closing the loop on things only a GUI can verify

Browser control drives a real browser — clicking, filling forms, reading console logs and network requests, taking screenshots. Computer use opens native applications from the terminal. Both exist so that "it works" can be demonstrated rather than asserted. For web work, the browser is the verification loop: "load the page, read the console, screenshot it, compare to the mock, fix the differences" is a closed loop the same way npm test is.

MCP — tools beyond the shell

Everything above assumes Claude's world is the filesystem and a shell. MCP servers extend it: a browser, your mail, the issue tracker, a database, a lab instrument with an API. claude mcp add registers one; claude mcp list shows what is live.

Two disciplines. Every server costs context — its tool schemas are loaded (or deferred and searched) each session, and a sprawling MCP set is the quietest way to degrade a session before it starts; /usage shows the bill. Keep the set per project small and scoped. And MCP output is data, not instructions: a web page, an email, a ticket comment can all carry text that reads like a command. Claude treats it as untrusted; your hooks and permission rules should assume the same.

Claude as a component

claude -p "summarise the failing tests in this log" < test.log
claude -p --output-format stream-json "…"      # machine-readable events
git diff main | claude -p "list any change that alters a public API"

Headless mode (-p) turns Claude into a Unix filter — scriptable from a git hook, a Makefile, a cron job, a CI step (the GitHub Action is claude-code-action; a self-hosted runner keeps it inside your network). The Agent SDK is the same loop as a library, for when you want your own tools in front of it. The test for whether to reach for it: is this a thing I want to happen without me?

10Beyond code — the workshop

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

Step one — stop it being a software engineer

A custom output style replaces the built-in engineering instructions. Omit keep-coding-instructions entirely when the work is not software.

Step two — find the verification loop

This is the whole game. The discipline that has a CLI returning pass or fail is the discipline where Claude is transformative.

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

Edit bracket.scad to add a 3mm fillet at the base. Render it with:
  openscad -o preview.png --imgsize=1200,900 \
    --camera=0,0,0,55,0,25,140 bracket.scad
Then look at preview.png and tell me whether the fillet is actually
there and whether anything else changed. Iterate until it's right.

That is a closed verification loop for physical geometry: Claude writes the model, renders it, looks at the render, and fixes what is wrong — with no human in the loop until the part is right. The same trick applies to slicing, where overhang warnings and support volume become a numeric signal to optimise against.

Step three — pick the right rung

Deep research is the strongest single move for hardware. Component selection is exactly the kind of question that gets a plausible, confidently wrong answer from a single pass — a pin that does not exist, a voltage range off by a factor. Because a research workflow fans out, cross-checks sources against each other and votes on each claim, you get a citation-backed comparison instead.

/deep-research Compare the INA219, INA226 and INA228 for measuring
0–5A at 48V: accuracy, common-mode voltage limits, I2C address
options, availability, and price at qty 10. Cite datasheets.

Adversarial teams for intermittent faults. A board that resets randomly under load is an anchoring trap — the "it must be the power supply" theory that eats a weekend. Give four teammates separate hypotheses (brownout, watchdog, heap fragmentation, RF), hand them the logs, and tell them to disprove each other.

Step four — write the domain knowledge down

Every hardware discipline has conventions Claude cannot guess: your net naming, your module patterns and tolerances, your printers' real measured shrinkage, the strapping-pin gotchas of the microcontroller you actually use. Each becomes a skill, written once.

The most quietly valuable is an inventory of what is on the bench. "Design a driver circuit" produces a very different — and far more useful — answer when Claude knows what is in the parts drawers.

11Planning and learning

The same machinery — a brief, a verification loop, a place where knowledge persists — applies when the output is a plan or an understanding rather than a file. The failure mode is also the same: Claude does the thinking, you nod, nothing persists.

Planning

• Interview, then spec, then clear. The interview prompt above is a planning tool first. Its output is a document; the chat that produced it is disposable. Never plan in a session you intend to execute in.
• The plan lives outside Claude. A markdown vault (Obsidian, a docs/ tree, anything) is a better memory than any chat — Claude reads and writes it natively, it is greppable, and it survives every /clear. Point CLAUDE.md at it and say "search the wiki before investigating; log decisions to the project page." Rediscovering your own setup is the most common waste in a long project.
• Decisions get a line, not a paragraph. "Chose INA226 over INA219: 16-bit, 36V common mode, on hand" is what future-you needs. Ask for the log entry in that form.
• Mockups are cheaper than opinions. /design produces a multi-artboard canvas you can edit by hand; Artifacts produce a live page that updates in place. A front panel, a wiring diagram, a project roadmap with a link you can open on your phone — one prompt each.
• Standing reviews run without you. A /schedule routine — "every Monday, read the project log and list the open loops" — is a planning habit that does not depend on remembering to have it.

Learning

The verification loop for learning is you being tested. An explanation you read is not a check; a question you answer is. So the prompts invert: Claude's job is to make you produce the artifact.

Teach me <topic>. One concept at a time. After each, ask me a
question that I can only answer if I understood it. Don't move on
until I get it right, and don't give me the answer — give me a
smaller question.

I'm going to explain <topic> back to you. Find the holes and the
places where my model is subtly wrong. Don't be polite about it.

Give me a problem that exercises <concept>, with a way to check my
answer. I'll do it; you check. Do not solve it.

• Tutor mode is an output style. One that says "never write the solution; ask a smaller question instead" removes the temptation to let Claude do the exercise. Switch styles when you switch from learning to building.
• /deep-research is the survey; the session is the seminar. Fan out for the landscape and citations, then read the result in a fresh session and argue with it.
• /btw keeps learning from polluting building. "Why does this lifetime need 'static?" mid-task is exactly what it is for — answered, never entering history.
• Build the smallest thing that exercises it. A ten-line program with a check is worth more than a chapter. Claude writes the check; you write the ten lines.
• What you learned goes in the vault, in your words. A page you wrote is a page you will find and trust. A chat transcript is neither.

12Away from the keyboard

Most of the hobby work — and the longest software runs — happen when you are not in front of the terminal. The tooling for that is newer than the rest of this page and under-used.

The pattern that ties them together is the one from section 03: give the unattended run a way to know it is done. A /loop without a condition is noise; a /loop with "stop when the serial log shows BOOT OK three times in a row" is an instrument.

13Tools on the PATH

An agent is exactly as capable as the command-line tools it can call. Claude cannot make a PDF, OCR a datasheet, or run DRC by wanting to — it needs a binary on the PATH that does it and returns an exit code. Installing the right twenty tools is the cheapest upgrade on this page.

Three selection rules. Prefer tools with a non-interactive mode (--batch, --headless, -p) — an agent cannot answer a TUI prompt. Prefer machine-readable output (--json, exit codes) over pretty output — it is the difference between a check and a report. Prefer one tool that does a thing well over a GUI app with a CLI bolted on.

Documents — markdown in, anything out

pandoc report.md -o report.docx --reference-doc=house.docx
pandoc report.md -o report.pdf --pdf-engine=typst
pandoc spec.docx -t gfm -o spec.md          # read what a colleague sent
soffice --headless --convert-to pdf --outdir out/ deck.pptx
pdftotext -layout -f 12 -l 15 datasheet.pdf - | head -200

Search, data and shaping

Code quality — the hooks need something to call

Images and media — so Claude can look

The bench

14The starter kit

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

Register the hook in ~/.claude/settings.json:

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

15What to do, in order

This week — thirty minutes

• Create the directories that are missing: ~/.claude/skills, agents, commands.
• Ask Claude to write you one hook: "write a PostToolUse hook that formats files after every edit in this project."
• Run /deep-research on a real question you have. This is the fastest way to feel the difference.
• Next time you correct Claude, stop and ask: should this be a rule instead? Then write it.
• Open MEMORY.md and read what Claude thinks it knows about you. Delete what is wrong.
• brew install pandoc typst ripgrep fd jq — then list them in CLAUDE.md.

Next week

• On your next multi-file task, add use a workflow to the prompt and watch it run.
• Set up two or three worktrees and run parallel sessions.
• Turn your most-repeated prompt into a skill.
• Add a Stop hook that runs your test suite.
• Run /usage after a heavy day and move one fan-out stage to Sonnet.
• Start claude rc before the next bench session and send it a photo.

The month after

• Try /goal on something substantial and walk away.
• Try an agent team on a debugging problem where you are genuinely stuck.
• Run one hard session at /effort ultracode.
• Write the domain skills for whatever you build that is not software.
• Write a tutor output style and learn one thing with it, end to end, without letting Claude solve the exercise.
• Put one /schedule routine on a weekly review and see whether you read it.

16Anti-patterns

The one-paragraph version

Give Claude a way to check its own work — that is worth two to three times on quality and it is the whole ballgame. Write one complete brief up front instead of steering turn by turn. Guard your 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 try to hold it — move the plan into a harness: worktrees for independent work, subagents for research and review, workflows for anything that fans out. Spend the strong model on judgement and the cheap one on reading. None of this is specific to code — any domain with a directory of files and a command that returns pass or fail works the same way, and so does planning and learning, once the thing being verified is a document or your own understanding.