How Anthropic
Uses Claude Code

Give It A Way To Check Itself

Close The Loop

This is the big one, the principle the whole best-practices guide is built around. Claude stops when the work looks done. If there's no check it can run, "looks done" is the only signal it has, and you become the thing that catches every mistake.

So give it something that returns a clear pass or fail: a test suite, a build, a linter, or a screenshot to compare against a design. Now the loop closes on its own. Claude does the work, runs the check, reads the result, and keeps fixing until it actually passes. As Anthropic puts it, the goal is the difference between a session you have to babysit and one you can walk away from.

Instead of "write a function that validates emails," do this

Write a validateEmail function. Example test cases: user@example.com is
true, "invalid" is false, user@.com is false. Write the tests, run them
after implementing, and keep fixing until they all pass. Show me the test
output as proof, don't just tell me it works.

Explore, Then Plan, Then Code

Pour Your Effort Into The Plan

Letting Claude jump straight to coding is how you get a beautiful solution to the wrong problem. The team’s fix: press Shift+Tab to cycle into plan mode first. In plan mode Claude reads files and answers questions without changing anything, then writes you a real implementation plan.

Pour your effort into that plan, and Claude can practically one-shot the build. And the moment something goes sideways, don’t patch it mid-stream, go back and re-plan. Their own rule of thumb: if you could describe the change in one sentence (a typo, a renamed variable), skip planning and just ask. Planning earns its keep when the change touches multiple files or you’re unsure of the approach.

In plan mode, start with exploration

Read the relevant files and understand how this works. Then write a
detailed plan for [what you want]: what files change, the order of steps,
and anything risky. Don't write any code yet, just the plan.

Tip inside the tip: press Ctrl+G to open that plan in your text editor and tighten it before Claude runs.

Turn Mistakes Into Memory

It Writes Its Own Rules

Claude reads a file called CLAUDE.md at the start of every session. It’s persistent memory for your project. So any time Claude gets something wrong, don’t just fix it for this session, tell it to remember.

Say: "update your memory so you never make that mistake again." It writes the rule into CLAUDE.md itself, and every future session starts already knowing it. Your setup literally gets smarter the more you use it. One catch from their guide: keep that file lean. A bloated CLAUDE.md makes Claude ignore half of it, so prune rules that aren’t earning their place.

After any mistake, paste this

That wasn't what I wanted. Update your memory (CLAUDE.md) with a short,
clear rule so you never make this mistake again. Keep it to one line.

Fast path: start a message with # and Claude files whatever you type straight into memory.

Push It

The First Solution Is Rarely The Best

Claude will hand you a working answer fast, but working is not the same as best. The team treats the first version as a draft and pushes. Two phrases that consistently raise the bar:

Prove to me this actually works. Show me the evidence.

Knowing what you know now, scrap this and build the more sophisticated
version you'd build if you were starting fresh.

When you ask Claude to critique or one-up its own work, it raises its own standard. Even a vague nudge like "what would you improve about this?" surfaces things you’d never have thought to ask. The trick is to stop accepting the first thing it gives you.

/simplify

Ship Something Tighter

After you’ve made changes, type /simplify. It runs agents that review your work for cleanup, quality, and efficiency in a single pass, so you ship something leaner instead of the first messy draft.

Pair it with its sibling, /code-review, which spins up a fresh reviewer to hunt for actual bugs in your latest changes. One pass for quality, one for correctness. Two commands, dramatically tighter output.

/simplify

/code-review

Use Subagents

Split The Work, Keep The Thread Clean

For anything big, just add "use subagents" to your request. Claude splits the job across helpers that each work in their own separate window, then report back only the answer. Your main conversation stays clean instead of drowning in everything they read along the way.

This isn’t theoretical. Anthropic’s Growth Marketing team uses two specialized subagents to generate hundreds of new ads in minutes instead of hours. Subagents are also the team’s favorite trick for research, one digs through the codebase or the data while your main thread stays focused.

Use subagents to investigate this and report back. Have one dig into
[part A] and another into [part B], then summarize the findings so my main
thread stays clean.

/loop and /schedule

Recurring Work Handles Itself

Some work repeats. Don’t do it by hand. Use /loop to rerun a task on a schedule on your own machine, or /schedule to run it in the cloud so it keeps working even with your laptop closed.

This is exactly how Anthropic engineers prototype: they set up autonomous loops where Claude writes code, runs the tests, and iterates on its own, then they come back and review the 80%-done result. The recurring stuff just handles itself in the background.

/schedule every morning, pull yesterday's numbers, build my standard
report in the usual format, and leave it ready for me to review.

/voice

You Talk ~3x Faster Than You Type

Anthropic shipped voice straight into Claude Code, and the reason is simple: you speak about three times faster than you type, and your instructions come out more detailed and natural when you say them out loud. A 50-word prompt that takes a minute to type takes under 20 seconds to say.

Turn it on with /voice, hold the spacebar, and just describe what you want. You can even talk and type at the same time, dictating the big picture while pasting in exact file paths or variable names. Once you try it, going back to typing whole prompts feels slow.

/voice

Bonus 1

Let Claude Interview You

For anything big, don’t write the perfect prompt, let Claude pull it out of you. It asks about edge cases and tradeoffs you hadn’t considered, then writes the spec.

I want to build [brief description]. Interview me in detail before we
start. Ask about technical choices, edge cases, and tradeoffs I might not
have considered. Keep going until we've covered everything, then write a
complete spec to SPEC.md.

Bonus 2

The Writer / Reviewer Split

Have one session build it, then a fresh session review it. A clean context isn’t biased toward code it just wrote, so it catches far more. Same idea as tip 1, scaled up: the builder never grades its own homework.

Bonus 3

Clear Context Between Tasks

The team’s number-one constraint is the context window, performance drops as it fills with old, unrelated stuff. Their fix is dead simple: run /clear between unrelated tasks. A clean session with a sharp prompt beats a long, cluttered one almost every time.