How Boris Cherny Uses Claude Code: The Boris Plan for Advanced AI Engineering

If you searched for “Boris Cherny how he uses Claude Code,” you are probably not looking for another beginner prompt list.

You want the operating model behind serious Claude Code usage: how the people closest to the tool think about planning, parallel agents, verification, project memory, permissions, hooks, and repeatable engineering workflows.

We did the research across official Claude Code documentation, Boris Cherny interviews, public summaries, and secondary compilations of Boris-attributed tips. The pattern is consistent: advanced Claude Code usage is not about a single perfect prompt. It is about turning AI coding from an interactive assistant into a controlled engineering system.

At Hammer Automation, we call that system The Boris Plan.

To be clear: “The Boris Plan” is our framing, not an official Anthropic term. It is a practical framework distilled from public material around Boris Cherny, the Claude Code team, and the documented Claude Code operating surface. Use it as a blueprint for building agentic software workflows that are fast, inspectable, and safe enough for real teams.

The Boris Plan in one sentence

Give Claude Code a bounded task, an isolated workspace, a strong plan, real verification, durable memory, specialized agents, automation hooks, and explicit permission boundaries.

That sentence is the difference between casual AI coding and an engineering-grade AI workflow.

Most teams still use Claude Code like this:

1. Open one session.
2. Ask for a change.
3. Watch it edit.
4. Manually inspect the result.
5. Correct mistakes in chat.
6. Repeat the same corrections next week.

The Boris Plan replaces that with a compounding loop:

1. Define the outcome.
2. Explore before editing.
3. Approve a plan.
4. Execute in an isolated workspace.
5. Verify against reality.
6. Review with a separate lens.
7. Promote repeated lessons into CLAUDE.md, slash commands, skills, hooks, subagents, and policies.

That is where advanced Claude Code users start to separate from everyone else.

1. Run Claude Code as an operating system, not a chat window

The first shift is conceptual.

A beginner sees Claude Code as a coding chatbot with terminal access. An advanced user sees it as a programmable execution layer for engineering work.

Boris-attributed interviews and summaries repeatedly point to a more systematic style: multiple Claude Code sessions, isolated workspaces, plan-first execution, heavy verification, shared project memory, and tool access to the systems where truth lives. Official Claude Code docs reinforce the same primitives: worktrees, memory, hooks, subagents, skills, permissions, and best-practice loops.

The lesson is not “let AI write more code.” The lesson is “design the environment in which AI work happens.”

For an advanced team, Claude Code should know:

• where the repo conventions live
• which commands prove a change works
• which files are sensitive
• when to stop and ask
• how to inspect failures
• how to preserve lessons for future sessions
• what systems hold customer, CI, observability, and product truth

If your Claude Code session depends entirely on what one engineer remembers to paste into a prompt, you do not have an AI engineering system. You have an expensive autocomplete with a long context window.

2. Use worktrees to create parallel engineering lanes

The most visible “how Boris uses Claude Code” pattern is parallelism.

Boris is often described as running multiple Claude Code sessions at once. Earlier versions of that workflow used separate checkouts; the official Claude Code documentation now points users toward git worktrees as the cleaner way to run parallel sessions without edit collisions.

This matters because one Claude Code session should not carry every role, assumption, and failure path.

A serious worktree setup might look like this:

• Implementation lane: build the feature in a dedicated worktree.
• Reviewer lane: inspect the same area skeptically without inheriting the implementer’s assumptions.
• Test lane: focus only on fixtures, regressions, edge cases, and failure reproduction.
• Alternative lane: explore a competing implementation before the team commits.
• Documentation lane: update migration notes, release notes, or PR context.

That is not “five chats.” It is a temporary engineering team with separate working directories and narrow missions.

The value is not just speed. It is cognitive isolation. The reviewer should not be contaminated by the implementer’s first solution. The test writer should not be trying to preserve the author’s pride. The migration investigator should not flood the main session with noisy file reads.

Boris Plan move: stop asking one session to be architect, implementer, tester, reviewer, release manager, and historian. Split the work into lanes.

3. Make Plan Mode the control surface

A recurring Boris-attributed theme is planning. The public summaries are blunt: when the plan is good, Claude Code can often execute surprisingly large changes with less steering. The official Claude Code best-practice guidance says the same thing in more procedural language: explore first, plan, then code.

Plan Mode is not process theater. It is the moment where you prevent expensive drift.

Use Plan Mode when:

• the task touches multiple files
• the architecture is uncertain
• the change affects auth, billing, permissions, data access, migrations, or customer-facing behavior
• the repo area is unfamiliar
• test strategy matters
• failure would be expensive to unwind

A strong planning prompt is specific about exploration, risk, and proof:

Explore the auth/session flow first. Do not edit yet.
Then write a plan for adding rate limits to login attempts.
Include likely files, architectural constraints, security risks, tests to add,
and the exact verification commands you will run.
Call out ambiguities before implementation.

Then interrogate the plan before allowing edits:

Review your plan as a skeptical staff engineer.
What assumptions could be wrong?
What is the smallest safe implementation?
What would prove this works?
What should remain explicitly out of scope?

Most Claude Code failures start before the first edit. The model optimizes toward the task you framed, the files it inspected, and the success criteria you made visible. If those are weak, the implementation will be weak even when the code looks polished.

Boris Plan move: require a plan that names files, risks, tests, verification commands, and open questions before the agent writes code.

4. Treat verification as the quality multiplier

This is the strongest overlap between Boris-attributed advice and official Claude Code guidance.

Official docs emphasize verification as one of the highest-leverage practices for Claude Code. A fan compilation of Boris’s public tips says his top recommendation is to give Claude a way to verify its work, with a claimed two-to-three-times improvement in final quality. Treat the multiplier as anecdotal, not a benchmark. The mechanism, however, is fundamental: Claude Code needs feedback from reality.

Verification can be:

• a narrow unit test
• a typecheck
• a lint command
• a local build
• an integration test
• a browser inspection
• a simulator run
• a log query
• a Sentry issue reproduction
• a BigQuery or analytics check
• a screenshot comparison
• a CI run
• a second Claude Code review of the diff

The key instruction is not “write high-quality code.” The key instruction is:

Do not stop after editing.
Run the narrowest relevant verification command.
If it fails, diagnose root cause, fix it, and rerun.
When it passes, run one broader check and summarize remaining risk.

For frontend work, give Claude Code access to browser inspection or screenshots. For backend work, give it tests, logs, and reproduction data. For data work, give it queries and expected outputs. For workflow automation, give it dry-run paths and rollback checks.

A Claude Code workflow without verification is just text generation with side effects.

Boris Plan move: make tests, logs, browsers, and CI part of the agent loop, not a human afterthought.

5. Convert CLAUDE.md into compounding engineering memory

One of the most valuable Boris-style patterns is aggressive maintenance of project memory.

Public-post compilations describe the Claude Code team using a shared CLAUDE.md and updating it when Claude repeats a mistake. Official Claude Code memory docs formalize the same idea: CLAUDE.md is where repo-specific context, commands, and conventions can live.

This is where teams either compound or stagnate.

A weak team corrects Claude Code in chat:

Do not use enums here. We prefer string literal unions.

A stronger team turns the correction into memory:

Fix this, then update CLAUDE.md so future TypeScript changes in this repo
avoid enums and prefer string literal unions unless there is an explicit reason.

Good CLAUDE.md content includes:

• exact build, test, lint, and typecheck commands
• repo-specific conventions the model cannot infer reliably
• architectural boundaries
• “never touch this directly; use that wrapper” rules
• common traps
• migration etiquette
• branch and PR expectations
• domain vocabulary
• security and privacy constraints

Bad CLAUDE.md content includes:

• generic advice like “write clean code”
• long tutorials
• stale onboarding prose
• file-by-file summaries Claude can read itself
• rules that change constantly
• vague preferences with no operational consequence

The standard should be simple: if the instruction would change the agent’s next action, it belongs. If it merely sounds wise, cut it.

Boris Plan move: every repeated correction must become durable infrastructure: CLAUDE.md, a command, a skill, a hook, or a policy.

6. Promote repeated prompts into slash commands, skills, and hooks

If an engineer types the same Claude Code instruction twice a week, the team should ask whether it belongs in the operating surface.

Boris-attributed public tips emphasize slash commands for repeated loops. Official docs describe slash commands, skills, hooks, settings, subagents, and permissions as the mechanisms that move Claude Code beyond ad hoc prompting.

Use each primitive deliberately:

• Slash commands for operator-triggered workflows.
• Skills for task-specific procedures and context loaded on demand.
• Hooks for deterministic lifecycle automation around tool calls and session events.
• Subagents for specialized work with separate context.
• Settings and permissions for safe defaults and repeatable boundaries.

Useful slash commands for advanced teams:

/fix-ci
Inspect failing CI, reproduce locally if possible, patch the root cause,
rerun checks, and summarize residual risk.

/security-review
Review the current diff for auth, permissions, secrets, data exposure,
unsafe shell behavior, dependency risk, and external network writes.

/release-check
Run changelog, version, tests, build, smoke checks, and PR summary.
Stop if any release gate is ambiguous.

/customer-bug
Read the bug report, gather logs/Sentry/customer context, identify likely files,
propose a plan, and wait before editing.

Hooks are where the system becomes harder to misuse. A PostToolUse hook can format after edits. A Stop hook can block premature completion until verification runs. A permission hook can prevent destructive commands or external writes. A notification hook can alert humans when a long-running agent finishes.

Boris Plan move: your best prompt should not remain a prompt. Turn it into shared workflow machinery.

7. Use subagents to protect the main context

Subagents are not simply “more Claude.” They are context isolation.

Official Claude Code docs describe subagents as specialized assistants with their own context windows. That matters because advanced work gets noisy fast: codebase exploration, failing tests, logs, review debates, dependency traces, and migration analysis can pollute the main session.

Use subagents when:

• exploration requires reading many files
• review should be independent from implementation
• security needs a separate lens
• test output will be noisy
• migration work can be split by module
• documentation can proceed independently
• a second opinion would reduce risk

A high-performing pattern:

1. Main session owns the goal and plan.
2. Research subagent maps the code path.
3. Main session approves and implements.
4. Reviewer subagent critiques the diff.
5. Test subagent expands edge cases and runs verification.
6. Main session reconciles the feedback and prepares the PR.

This is especially important for senior engineers. Your bottleneck is no longer “can the model write code?” It is “can the system keep the right context in the right place?”

Boris Plan move: delegate noisy or adversarial thinking out of the main thread.

8. Design permissions as acceleration, not friction

Advanced Claude Code users move faster partly because the agent is not blocked every thirty seconds.

But the answer is not always --dangerously-skip-permissions.

The safer pattern is to pre-approve low-risk operations and hard-gate high-risk operations. Boris-attributed tips mention using /permissions and shared settings to reduce unnecessary interruptions. Official docs support the broader model through settings, permission scopes, sandboxing, hooks, and managed policies.

Allow freely:

• narrow test commands
• typecheck and lint
• formatters
• local builds
• harmless file reads
• branch-local fixture updates
• non-destructive search commands

Require approval for:

• production deploys
• database migrations
• auth, billing, or permission changes
• destructive shell commands
• force pushes
• external writes
• customer data access
• secrets and credentials

This is where companies often fail. They either make Claude Code too weak to be useful or too powerful to be trusted.

The advanced setup is a fast lane with guardrails: let the agent run safe loops quickly, but make dangerous actions explicit, reviewable, and rare.

Boris Plan move: permissions are not prompts to click through. They are workflow architecture.

9. Connect Claude Code to the systems where truth lives

Claude Code becomes dramatically more useful when it can inspect the same operational context humans use.

Boris-attributed workflows mention systems like Slack, BigQuery, Sentry, browser tooling, MCP integrations, and logs. The lesson is not to connect everything. The lesson is to connect the systems that close the loop.

High-value integrations include:

• GitHub: pull requests, reviews, CI, issues, changelogs
• Sentry and logs: real errors, stack traces, deploy correlation
• Slack: bug reports, customer context, internal decisions
• BigQuery and analytics: product behavior, impact, regression checks
• Browser tooling: visual and interactive frontend verification
• MCP servers: controlled access to internal tools and data

A weak bug-fix prompt says:

Users say checkout is broken. Please fix it.

A stronger Boris Plan prompt says:

Use the linked Slack thread, Sentry issue, recent deploy diff, and checkout logs
to identify the likely root cause. Do not edit until you have a plan and a
verification path. After the fix, prove the failing case passes and summarize
remaining risk.

Agents do better when they can see reality. They do worse when humans compress reality into a vague paragraph.

Boris Plan move: connect Claude Code to truth systems, but expose them through controlled tools and explicit permissions.

10. Choose models by steering cost, not sticker price

One secondary compilation of Boris’s public posts says he preferred stronger models with higher thinking effort for serious Claude Code work because they require less steering and use tools better.

This claim is date-sensitive. Model names, latency, pricing, and defaults change. The durable principle is more important: do not optimize only for cost per response. Optimize for cost per finished, verified task.

Use stronger reasoning when:

• architecture is unclear
• debugging requires multiple hypotheses
• the codebase is unfamiliar
• migrations cross boundaries
• security risk is high
• tool use is multi-step
• a wrong first path would be expensive

Use faster or cheaper settings for:

• mechanical edits
• formatting
• summaries
• narrow docs updates
• small test additions
• low-risk refactors with strong tests

For advanced teams, the expensive part is often not the model token. It is the senior engineer steering, reviewing, correcting, and cleaning up after weak execution.

Boris Plan move: choose the model and effort level based on failure cost, verification depth, and expected steering burden.

The Boris Plan implementation checklist

Use this checklist when turning Claude Code from a personal tool into a team workflow.

Before work starts

• Define a bounded outcome.
• Choose the right model and effort level.
• Create a fresh session or isolated worktree.
• Load relevant repo memory from CLAUDE.md.
• Identify sensitive areas: auth, billing, data, permissions, migrations.
• Decide which commands are pre-approved and which require human approval.

During planning

• Require exploration before edits.
• Ask for likely files, risks, assumptions, and out-of-scope items.
• Ask for exact verification commands.
• Challenge the plan as a skeptical staff engineer.
• Split noisy research or adversarial review into subagents.

During implementation

• Keep the session focused on the approved plan.
• Avoid mixing unrelated refactors into the diff.
• Run narrow verification after the first complete change.
• Fix failures from root cause, not by suppressing symptoms.
• Use a second session or subagent for review.

Before merge

• Run one broader verification pass.
• Summarize the diff, tests, risks, and rollback considerations.
• Update docs or migration notes.
• Convert repeated feedback into CLAUDE.md, a slash command, skill, hook, or permission rule.
• Capture any follow-up work explicitly instead of hiding it in chat history.

This is the operational loop that compounds. The first task may take longer because you are building the rails. The tenth similar task should need less human steering, fewer repeated corrections, and a cleaner audit trail.

Where Hammer Automation fits

Most companies do not fail with Claude Code because their engineers lack prompt tricks. They fail because the workflow remains informal.

The same senior engineer keeps remembering the test command. The same reviewer keeps catching the same architectural mistake. The same release checklist lives in someone’s head. The same production-risky command appears as a one-off approval prompt. The same customer bug investigation starts from scratch every time.

That is exactly the kind of system Hammer Automation helps design.

We help teams turn ad hoc AI coding into repeatable, permissioned workflows:

• CLAUDE.md memory that actually changes agent behavior
• slash commands for common engineering loops
• subagent patterns for research, review, testing, and documentation
• hook design for formatting, verification, notifications, and guardrails
• MCP integrations for the systems where truth lives
• permission models that unblock safe work and gate dangerous work
• workflow audits for advanced Claude Code adoption

The goal is not to make developers passive. The goal is to give senior engineers leverage: better plans, faster feedback, fewer repeated corrections, and AI work that can be reviewed like engineering rather than guessed at like magic.

If your team already uses Claude Code and wants to move from impressive demos to dependable delivery, the next step is not a bigger prompt library.

It is operational design.

Source reliability notes

We preserved the source trail because this topic attracts a lot of recycled advice.

• Highest reliability: official Anthropic and Claude Code docs. These are the best references for supported features and current mechanics: Best practices, Worktrees, Subagents, Hooks, Memory / CLAUDE.md, /goal.
• Strong but interpretive: Boris-attributed interviews and editorial summaries. Useful for understanding how Boris Cherny and the Claude Code team think about the tool, but still mediated by interview format and editorial framing: Lenny’s Podcast episode page, Every / AI & I with Cat Wu and Boris Cherny, The Pragmatic Engineer interview summary.
• Useful secondary index: How Boris Uses Claude Code collects Boris-attributed public tips and is helpful for discovery, but individual claims should be treated as compiled notes unless checked against original posts.
• Additional secondary context: Developing.dev Boris Cherny interview summary.

Where this article references official Claude Code functionality, rely on the Anthropic docs. Where it references Boris-style personal workflow claims, treat them as attributed practitioner signals. Where it introduces The Boris Plan, treat it as Hammer Automation’s framework for applying those signals in a production engineering environment.