Quick summary

• Give Claude a clear goal: Describe the result you want before prescribing every step.
• Set the effort and boundaries: Match the depth to the task, and provide the context and constraints that matter.
• Define a real check: Ask Claude to compare its work with tests, sources, or clear acceptance criteria.
• Keep the multiplier in perspective: Cherny’s two-to-three-times improvement claim is an estimate, not a published benchmark.

The best Claude prompting advice may sound surprisingly ordinary: tell the model what you need, then give it a way to check whether it got there. Boris Cherny, the engineer who created Claude Code, says people can often talk to Claude as they would a coworker instead of writing a rigid script for every task.

That does not mean details no longer matter. It means the useful details are the ones that explain the goal, the boundaries, and what success looks like.

Boris Cherny’s Claude prompting rule

Cherny’s advice boils down to three things: explain what you want done, how much effort the task deserves, and how Claude should verify the result. He shared this guidance in a post about how he uses Claude Code.

For a small task, a natural-language request may be enough. For example: “Summarise this report for a non-technical audience. Keep the key figures accurate and link each claim to the relevant section.” The request gives Claude a goal and a quality bar without dictating every step.

For more complicated work, add the context and constraints that affect the outcome. If you are changing a codebase, that might include the expected behaviour, project conventions, files or systems to avoid, and the checks that should pass. Conversational does not mean vague.

Claude prompting still needs clarity and context

Anthropic’s current prompting guidance also recommends clear, explicit instructions. It advises people to specify output formats and constraints, and to use a structured sequence when order or completeness matters. A simple request can stay simple. A complex task needs enough detail to prevent expensive misunderstandings.

Anthropic’s prompting guide makes the difference concrete. It contrasts “Can you suggest some changes to improve this function?” with “Change this function to improve its performance.” The first asks for advice; the second clearly asks Claude to edit the code. That is a documented example of making the requested action explicit. For a reliable result, you still need a way to check whether the change works.

This is a shift in emphasis, not a reason to throw away prompt craft. Instead of polishing elaborate wording for its own sake, spend effort on the information Claude cannot infer: the audience, the relevant context, what must be preserved, and how you will judge the result.

That distinction also appears in our guide to Claude prompting with a clear finish line. Define the outcome first, then add instructions only where they help Claude reach it.

Boris Cherny’s verification advice in practice

A model can produce a convincing answer and still be wrong. A feedback loop gives it evidence to work with: a failing test, a browser view, a source document, a calculation, or a checklist tied to the task. Claude can use that signal to find a problem, revise the work, and check again.

For coding tasks, verification might mean running the relevant tests and opening the changed page at a mobile viewport. For research, it could mean checking each central claim against primary sources. Anthropic’s Claude Code power-user tips describe domain-specific checks such as commands, test suites, simulators, and browser testing.

A check is only useful when it tests the thing you care about. A unit test that misses an important edge case cannot prove the feature works in that case. A prompt that says “double-check your answer” is weaker than asking the model to compare the answer with specific sources or acceptance criteria.

For a broader look at the same issue, see our article on whether an AI agent can ship code without skipping the hard parts. Passing a check is evidence, but the check itself still needs to represent the real requirement.

Boris Cherny’s claimed improvement: is it proven?

Cherny has said that a verification feedback loop can improve the quality of Claude Code’s final result by “two to three times.” That number is an attributed estimate from his post. The post does not describe a benchmark, study design, sample size, or measurement method, so readers should not treat it as a general performance statistic.

The underlying recommendation is more solid than the multiplier. Tests, source checks, and review against clear requirements are practical ways to catch errors. The size of the benefit depends on the task, the quality of the verification, and whether Claude can act on the feedback.

A Claude prompting pattern you can use

For work where correctness matters, spell out the outcome, relevant constraints, and a concrete check. For example:

Update the signup page so it works well on mobile and preserves the existing design. Follow the project’s conventions. Run the relevant tests and check the page at a mobile viewport. Summarise what changed and report any checks that failed.

For a research task, you could ask Claude to summarise a report, link important claims to their sources, and flag anything the report does not establish. The wording can be natural. The definition of success should be specific.

Define “done,” then verify the result

Cherny’s rule is useful because it redirects attention from magic phrases to the work itself. Give Claude a clear goal, share the context and constraints that matter, and decide how you will know the result is good. Then make the model show its work against that check, and review the evidence when the stakes warrant it.