How to brief Claude Code
like an engineer.
Most disappointing Claude Code output traces back to a thin brief and a rubber-stamped diff, not a weak model. Here's the structure that gets you a scoped, reviewable change instead of a confident guess.
The five rules of a good Claude Code brief
Briefing Claude Code well is the same discipline as briefing a contractor or a new teammate, just written down instead of assumed. Five things separate a brief that produces a mergeable diff from one that produces a plausible-looking guess.
State the outcome, not the implementation
Not "refactor this function" but "this endpoint needs to handle 10x current load without changing the public API". Claude Code works towards an outcome far better than it works towards a vague instruction; the implementation follows once the goal is clear.
Give it the constraints a teammate would need
Coding standards, the test command, what's off-limits (a shared library, a migration already in flight), and any performance or security constraints. Every constraint you leave out becomes a guess Claude has to make on your behalf, and guesses are where regressions come from.
Point it at the actual code, not a description of it
Claude Code works from the real repo, the real error message, the real stack trace, not your summary of what's wrong. A pasted description loses the details that matter; access to the actual files doesn't.
Ask for a plan before you ask for a diff
For anything non-trivial, have it lay out the approach first: which files change, what the risk is, whether tests need updating. Reviewing a plan is far cheaper than reviewing, and possibly reverting, a large diff that took the wrong approach.
Review it like a junior engineer's PR, not a rubber stamp
Claude Code can produce a confident, wrong diff as easily as a correct one. Read the diff, run the tests, and ask "what would break this" before merging, that habit is the difference between shipping fast and shipping fast, then spending a day debugging.
Want to see this method run against a real bug, start to finish? Read a full session walkthrough, or if you don't code day-to-day, see what a non-developer can produce with it.
Coaching designed
to end.
Reading the method is one thing; having someone check your first diffs against your actual repo is another. Three promises, in writing, if you bring it to a session:
Independence Guarantee
On the Deep Dive Programme you'll be working independently inside six sessions, or we'll keep going: up to two further sessions free.
24-Hour Match
Tell us what you do; we'll match you with the right specialist within 24 hours. Guaranteed.
Things people
usually ask.
Partly, but the bigger lever is context and process, not phrasing. Pointing Claude Code at the real repo, giving it the real constraints, and reviewing its plan before its diff fixes more problems than any clever prompt template.
You need to be able to read and evaluate a diff. This is aimed at developers and technical leads; if you don’t code day-to-day but want to understand what Claude Code can do for your team, see Claude Code for non-developers.
The defaults work fine for small tasks; this is about the habits that make the difference between roughly-right and production-ready output on anything bigger, the same gap the METR study found between believed and measured speed gains.
This guide covers the method. Boffin Hub’s Claude Code coaching applies it live to your real repo and real tickets, with someone watching your first sessions, which is where most people get unstuck faster than reading alone.