How to Actually Get Senior-Engineer Output from Claude Code

1. Write a real CLAUDE.md before you write another prompt

This is the single biggest lever, and it’s also the one almost everyone skips. CLAUDE.md is a markdown file where you store project-specific instructions, conventions, and context that Claude should know every session. If your project doesn’t have one, Claude is starting from scratch every time you open a terminal, and you’re paying for that ignorance in tokens and bad output.

The fastest way to start: run the /init command in Claude Code. It scans your entire codebase and drops a CLAUDE.md into your project root. That file acts as a persistent summary of your project, including overview, architecture, key workflows, and tech stack.

Then edit it. The auto-generated version is a starting point, not a finish line. Most CLAUDE.md files are packed with stuff Claude can already infer. Learn to document what actually matters: business decisions, team conventions, and the why behind every rule.

And keep it alive. Boris Cherny, the creator of Claude Code, treats CLAUDE.md as a living document. His golden rule: “Anytime we see Claude do something incorrectly, we add it to CLAUDE.md so it doesn’t repeat next time.” The file is checked into git, shared by the whole team, and updated multiple times a week. Every time Claude makes a mistake a senior engineer wouldn’t, that’s a CLAUDE.md entry, not a personal grudge.

2. Live in Plan Mode for the first month

If you take one thing from this guide, take this one. The single biggest mistake people make is letting Claude jump straight into coding without a plan. Boris’s team always starts in Plan Mode.

The mechanics are simple. Activate it by pressing Shift+Tab twice, or use the /plan command (v2.1.0+). Exit with Shift+Tab again. When active, Claude won’t edit files, run commands, or modify anything until you give the green light. On Windows, if Shift+Tab isn’t cycling correctly, use Alt + M instead, or type /plan directly in the prompt.

The reason this matters isn’t safety theater. It’s math. Assume Claude makes the right call 80% of the time on any individual decision. A typical feature involves 20 decision points. The probability of getting all of them right: 0.8²⁰, roughly 1%. Planning collapses those twenty ambiguous decisions into one reviewed spec where you’ve already made the calls.

The trade-off is real but tiny. Plan mode costs you 30 extra seconds of reading per task. The benefit is that you catch the “why is it touching that file?” moment before the file gets touched. For anyone new to Claude Code, that trade is a no-brainer.

When not to use it: skip it for small, clear-scope tasks. If you can describe the diff in one sentence, just do it directly. Renaming a variable, fixing a typo, adding a log line, go direct. Anything that touches three or more files gets Plan Mode, every time.

3. Edit the plan before you approve it

This is the move I see almost nobody making, and it’s free. When Claude shows you the plan, change it before you say yes. You’re the senior engineer in the room. Act like it.

Inside Claude Code, press Ctrl+G to open the plan in your text editor for direct editing before Claude proceeds. Strip the steps that are out of scope. Add the test case Claude forgot. Rename the file it’s about to create to match your conventions. Then send it back.

While you’re in there, paste in a reference. Pasting good existing code alongside a plan request noticeably improves output. Claude works better from a real reference than an abstract description. If you’re building a webhook handler, show it an existing one first. Your codebase already has the patterns you want, so point at them instead of describing them.

4. Demand evidence, not “done”

The most expensive habit in agentic coding is taking Claude’s word for it. The model will tell you the tests pass. Sometimes the tests don’t exist. Sometimes they exist and they’re wrong. Sometimes the feature works and the tests pass and Claude implemented the wrong feature. You have to verify.

Have Claude show evidence rather than asserting success: the test output, the command it ran and what it returned, or a screenshot of the result. Reviewing evidence is faster than re-running the verification yourself, and it works for sessions you weren’t watching.

This goes double for code in stacks you don’t know cold. Claude can write confident, plausible code that’s subtly wrong, especially in frameworks or languages you’re less familiar with. The less you can verify the output yourself, the more scrutiny it deserves.

Cheap habit, huge payoff: when Claude says “done,” your next message is “show me the test output and the command you ran.” Every time. No exceptions.

5. Commit constantly. Treat every session as disposable

This is the unsexy one. Nobody writes a viral thread about git commit -am "wip". But it’s the difference between rolling back a bad decision in five seconds and spending an hour untangling a mixed diff at midnight.

If Claude makes a wrong call mid-session, clean commits are what let you revert without untangling a pile of mixed changes. The corollary: never let a long session be your only record of decisions made. Commit frequently, dump progress to files, treat every session as disposable.

The other reason to commit early and often: long sessions get dumber. A Claude session at 90% context usage isn’t just slower, it’s producing worse outputs. Important instructions get buried. The model starts making mistakes it wouldn’t make with a clean window. When a thread feels like it’s going sideways, the answer isn’t a longer prompt. It’s git commit, /clear, and a fresh session pointed at the file you actually need to change.

6. Use subagents for the reads, your main session for the decisions

This is the upgrade most people sleep on. Define specialized assistants in .claude/agents/ that Claude can delegate to for isolated tasks. Subagents run in their own context with their own set of allowed tools. They’re useful for tasks that read many files or need specialized focus without cluttering your main conversation.

The mental model: your main conversation is the architect. Subagents are the interns you send to read a directory and come back with a one-paragraph summary. When Claude spawns a subagent, it works in its own context window, does its exploration, then reports back a compressed summary. Your main session stays clean.

For really big work, codebase-wide audits, multi-file migrations, anything you’d normally break into a quarter, there’s now a bigger hammer. Dynamic workflows in Claude Code let Claude tackle the most challenging tasks by executing across 10s to 100s of parallel subagents, and checking its work before anything reaches you. Useful, but pricey: dynamic workflows can burn substantially more tokens than a typical Claude Code session, so start on a scoped task to get a feel for usage in your work.

One caution before you go agent-crazy: for most teams, a single well-structured session with clear planning outperforms multiple poorly coordinated agents. Reach for parallel workflows only when the task genuinely benefits from simultaneous independent work. A great plan with one agent beats a mediocre plan with ten, every time.

7. Add MCP servers and hooks, but only the ones you’ll actually use

The MCP and hooks ecosystem is where Claude Code stops being a chatbot and becomes infrastructure. It’s also where developers go to waste a weekend installing thirty things they never invoke.

Start with the boring, high-leverage ones. The MCP servers worth starting with: Playwright for browser testing and UI verification, PostgreSQL/MySQL for direct schema queries, Slack for reading bug reports and thread context, and Figma for design-to-code workflows. Add the GitHub CLI while you’re at it. Install gh (the GitHub CLI) and Claude can interact with GitHub directly: open pull requests, comment on issues, read CI logs, the works.

For things that must happen every time, running the linter after every file edit, blocking writes to a migrations folder, use hooks. Hooks run scripts automatically at specific points in Claude’s workflow. Unlike CLAUDE.md instructions, which are advisory, hooks are deterministic and guarantee the action happens.

And then stop. Be careful not to add too many tools. Each one adds complexity and context to manage, so only keep the ones that really make a difference for your workflow. A handful of well-chosen tools beats a dozen half-used ones. Every MCP server you install eats a sliver of context whether you call it or not. Curate ruthlessly.

A bonus, because it’ll save you the most time: stop trying to one-shot the perfect prompt

The instinct from the ChatGPT era is to craft a single beautiful prompt that does the whole task. Kill that instinct. The newer, faster pattern: short prompt, look at what you got, push it in the direction you want.

The guard phrase matters. Without “don’t implement yet,” Claude skips revision and starts writing code immediately. One developer spent two hours on a 12-step spec and recovered an estimated 6 to 10 hours of implementation time. The upfront investment compounds heavily on larger features.

And describe outcomes, not steps. Boris’s prompting style is surprisingly aggressive. He doesn’t babysit Claude, he challenges it. Notice what he’s not doing: he’s not micromanaging. He’s not writing step-by-step instructions. He describes the outcome he wants and lets Claude figure out the how. “Make the auth flow handle expired tokens without redirecting twice” is a better prompt than fifteen numbered substeps. Save the numbered substeps for the plan it shows you back.

The habit that ties it all together: treat Claude Code like a junior engineer who has read every line of your codebase and remembers nothing about your team. Your job is the structure around it: the CLAUDE.md that teaches it your conventions, the plan that catches its wrong assumptions, the commits that let you throw work away, the evidence that proves it actually worked. The developers shipping real features with this thing aren’t smarter than you. They’ve just stopped expecting the model to do their job, and started doing the one job it can’t: deciding what good looks like, and refusing to ship anything less.