Mastering Claude Code: The Agentic Coding Workflow
How Claude Code works under the hood, the workflows Anthropic's own engineers use, and how to extend it with memory files, slash commands and headless automation.
This lesson is original educational writing based on this video by Anthropic (published May 22, 2025). All credit for the original content goes to the creators.
1. What Claude Code actually is
Claude Code started as an internal tool at Anthropic. The team gave a coding model direct access to a terminal, and usage exploded internally — engineers were suddenly delegating real work, not just autocompleting lines. That internal tool became the product: a terminal-based agentic coding assistant.
Two design decisions explain almost everything about how it feels to use:
- It lives in the terminal. That makes it editor-agnostic — it works next to VS Code, JetBrains, Vim, over SSH, or inside CI. The terminal is the one interface every developer already has.
- It is deliberately unopinionated. Claude Code gives you close-to-raw model access with a small set of powerful tools (read/edit files, run shell commands, search), instead of prescribing one workflow. You compose your own workflows on top.
The agentic loop
Everything Claude Code does is one loop repeated until the job is done:
The single most useful mental model from the talk: your job is to engineer that loop, not to micromanage the code. Give Claude better ways to gather context (memory files, search), better tools to act (permissions, MCP), and — most importantly — a way to verify its own work (tests, type checks, screenshots). Tasks with a clear verification signal succeed dramatically more often.
2. Everyday workflows that actually work
These are the workflows Anthropic engineers use daily, roughly in order of how often you’ll reach for them.
Codebase Q&A and onboarding
Use Claude Code as the first thing you open in an unfamiliar repo: “How does auth work in this project?”, “Where are payments processed?”, “What does this stack trace mean?”. At Anthropic this replaced most “ask a teammate” onboarding questions — new engineers’ time-to-first-PR dropped substantially. No setup needed; Claude searches and reads the code itself.
Plan first, then build
For anything non-trivial, don’t ask for code immediately. Ask for a plan, review it, then say “implement step 1”. You catch wrong assumptions when they’re one sentence, not five hundred edited lines.
Test-driven development, supercharged
TDD pairs perfectly with the agentic loop because tests are the verification step:
- Ask Claude to write failing tests from the spec (and tell it not to write the implementation yet).
- Confirm the tests fail.
- Ask Claude to make the tests pass without touching the tests.
- Let it iterate — it runs the tests itself until they’re green.
Course-correct early and often
Press Escape to interrupt the moment you see it going the wrong direction. Double-Escape
jumps back in history so you can edit your previous prompt and steer differently. Stopping a bad
run after ten seconds costs nothing; reviewing a wrong 500-line diff costs a lot.
Think harder when it matters
For genuinely hard problems, ask for extended thinking explicitly. The words
think < think hard < think harder < ultrathink map to increasing thinking budgets. Use
them for architecture decisions and tricky debugging, not routine edits.
Check your understanding
3 questions · your answers are saved in this browser only
-
1. What is the most effective way to improve Claude Code results on a task?
-
2. Why does the talk recommend asking for a plan before asking for code?
-
3. In a TDD workflow with Claude Code, what should you explicitly tell Claude in step one?
3. Memory: CLAUDE.md
Claude Code automatically reads a file called CLAUDE.md from the directory where you launch it
(and parent/child directories). It’s the project’s persistent memory: build commands, code style,
test instructions, architectural quirks, “don’t touch X” warnings.
# CLAUDE.md
## Commands
- Build: npm run build (run from site/)
- Test: python3 pipeline/test_fetch_transcripts.py
## Style
- TypeScript strict, no `any`
- Conventional commits
## Gotchas
- learnings/ is internal source material — never render it on the site
Two habits make this powerful:
- Run
/initonce in a repo and Claude generates a starter CLAUDE.md by exploring the project. - During any session, start a message with
#and Claude saves that note into memory — e.g.# always use pnpm, not npm. Cheap, instant, compounds over time.
There are three levels: CLAUDE.md (checked in, shared with the team), CLAUDE.local.md
(personal, gitignored) and ~/.claude/CLAUDE.md (global, all your projects).
4. Extending and automating
Permissions
By default Claude Code asks before running commands or editing files. Instead of mashing “yes”,
codify what’s always safe in .claude/settings.json:
{
"permissions": {
"allow": ["Bash(npm run build)", "Bash(npm run test:*)", "Edit"]
}
}
Custom slash commands
Any markdown file in .claude/commands/ becomes a reusable prompt. Create
.claude/commands/fix-issue.md:
Find the GitHub issue $ARGUMENTS, understand it, implement a fix,
add a regression test, and prepare a commit message.
Now /fix-issue 1234 runs the whole recipe. Team-shared, version-controlled prompts.
MCP servers
Claude Code is an MCP client: claude mcp add connects external tools — browsers (Puppeteer),
databases, issue trackers — which the agent can then use inside the same loop. (Our
MCP 201 lesson covers how MCP works under the hood.)
Headless mode
claude -p "<prompt>" runs one-shot, non-interactively — Claude Code as a Unix tool:
# Triage a new issue in CI
claude -p "Read issue #$ISSUE_NUMBER and apply labels" --allowedTools "Bash(gh:*)"
# Pipe data through it
cat error.log | claude -p "Summarize the root cause in one paragraph"
That unlocks CI jobs, pre-commit hooks, cron jobs and mass migrations (fan out one headless call per file). For bigger parallel work, run multiple interactive sessions in separate git worktrees so agents don’t trample each other’s changes.
Check your understanding
2 questions · your answers are saved in this browser only
-
1. What does starting a message with “#” do in Claude Code?
-
2. You want Claude to label new GitHub issues automatically in CI. Which feature fits best?
Build it yourself
Follow these exact steps to reproduce it yourself · estimated time: ~20 minutes
Prerequisites
- Node.js 18+ installed
- A Claude subscription (Pro/Max) or an Anthropic API key
- Any code repository to experiment in
Step 1 — Install and start
npm install -g @anthropic-ai/claude-code
cd your-project
claudeOn first run, authenticate with your Anthropic account. You’re now in an interactive session.
Step 2 — Bootstrap project memory
Inside the session:
/initReview the generated CLAUDE.md, trim it, and commit it. Then teach it one thing manually:
# run tests with `npm test -- --watch=false`Step 3 — Try the plan-first workflow
Look at this codebase. I want to add <small feature>.
Make a step-by-step plan first — don't write any code yet.Review the plan, then: Implement step 1 only.
Step 4 — Add a permission rule
Create .claude/settings.json so the test command never needs approval again:
{
"permissions": {
"allow": ["Bash(npm test:*)"]
}
}Step 5 — Create your first slash command
mkdir -p .claude/commands
cat > .claude/commands/explain.md << 'EOF'
Explain how $ARGUMENTS works in this codebase: entry points,
key files (with paths), and one diagram in ASCII.
EOFRestart claude and run /explain authentication.
Step 6 — Go headless
claude -p "List the 3 riskiest files in this repo and why" --output-format textExpected result: a one-shot analysis printed to stdout — proof you can now wire Claude Code
into scripts and CI. If a step fails, check claude --version and that you’re authenticated
(claude interactive works) before debugging further.
Where to go next
- Watch the original talk by Boris Cherny, the creator of Claude Code — the live demos are worth it.
- Continue with Prompting for Agents to understand why the loop works.
- Read the official Claude Code docs for everything this lesson didn’t cover.