The Pro Workflow

How Anthropic Developers Actually Work

The developers at Anthropic -- the people who built Claude Code -- use it daily themselves. Their workflow has crystallized into a clear pattern:

Explore --> Plan --> Code --> Commit

1. Explore -- Understand what is there

First, you orient yourself. You have Claude read the relevant files, understand the architecture, and analyze the current state. No code yet, just reading and understanding.

> Read through the files in src/auth/ and explain to me
  how the current authentication works.

2. Plan -- Make a plan

Before a single line of code is written, you create a plan. What needs to change? Which files are affected? What order makes sense?

> Create a plan for how we switch from JWT to session-based
  auth. No changes yet, just the plan.

3. Code -- Implement

Only now is code written. With a clear plan, Claude works much more focused and takes fewer detours.

4. Commit -- Save

After each completed work step: commit. Not at the end of the day, but after each logical unit.

5 Mistakes Everyone Makes

1. The Kitchen-Sink Session

The problem: You start in the morning with a bug, then build a feature, write tests in between, update the docs, and refactor a component -- all in one session.

Why it hurts: After the third topic, the context is so full and mixed up that Claude starts confusing things. It references code from the bug search while working on the feature. The results get progressively worse.

The solution: /clear between every task. Five focused sessions beat one chaotic marathon session.

2. Endlessly Correcting Instead of Starting Over

The problem: Claude made a mistake. You correct it. Claude makes a new mistake. You correct again. After the fifth correction, the code is a patchwork and the context is full of failed attempts.

Why it hurts: Every failed attempt stays in the context. Claude sees all its mistakes and does not get better from that -- it often gets worse because it gets confused between the different versions.

The solution: Rule of thumb: After two failed attempts -- /clear and start completely fresh. Rephrase the prompt, give better instructions, and let Claude approach it with fresh eyes.

3. The CLAUDE.md Novel

The problem: Your CLAUDE.md is 500 lines long, with detailed explanations of every aspect of the project, historical decisions, and philosophy.

Why it hurts: CLAUDE.md is loaded at every startup and burdens the context from the start. 500 lines means thousands of tokens that you never get back.

The solution: Keep CLAUDE.md short and concise. Maximum 100-150 lines. Focus on: build commands, architecture overview, important conventions. Everything else Claude can read from the files themselves when needed. Prune regularly -- remove entries that are no longer relevant.

4. Blind Trust

The problem: You give Claude a task and accept the result without reviewing it. "Claude wrote it, so it must be correct."

Why it hurts: Claude can write convincingly wrong code. Especially with complex logic, edge cases, and API integrations, mistakes are common.

The solution: Trust, but verify.

• Include tests: "Implement the function and write tests for it"
• Screenshots: Take screenshots for UI changes and review them
• Work incrementally: Not "build the entire feature," but step by step

5. "Explore Everything"

The problem: You tell Claude: "Look at the entire project and tell me what could be improved." Claude then reads dozens of files, and your context is immediately full.

Why it hurts: Undirected exploration consumes context without giving you a concrete result. Claude reads files that are irrelevant to your actual task.

The solution: Limit the scope. Instead of "look at everything," try:

> Analyze only the files in src/api/auth/ and identify
  potential security issues.

For project-wide analyses: Use subagents. They have their own context and only deliver the summary to you.

The Optimal Daily Routine

A productive day with Claude Code looks like this:

1. Morning: Start with a fresh session. Briefly review the previous day's status (/resume or Git log)
2. Per task: Explore --> Plan --> Code --> Commit --> /clear
3. When problems arise: Maximum two correction attempts, then /clear and restart
4. In between: /compact when the context gets full but the task is still running
5. Knowledge questions: /btw for anything unrelated to the current task