What you will be able to do
- Sequence Claude-assisted development as explore, plan, implement, commit, and review the plan before anything changes
- Turn vague requests into requests that include a check Claude can run, and recognise verification loops
- Judge Claude's output beyond whether it works, using user testing and the five discernment lenses
- Iterate in small, measurable steps so a regression can be traced to the change that caused it
1.Plan before Claude changes anything
When it is time to build, Anthropic's guidance for Claude Code describes four phases. First Claude explores the existing material until it understands the current setup. Next it plans: it works out what needs to change and writes a plan. Then it implements that plan, writes tests and fixes any failures. Last, the change is committed with a clear description.
The planning phase is where you keep control. In Plan mode, Claude explores and proposes a plan without editing your files, so you review the approach before anything changes. This is the cheapest point to catch a misunderstanding. Correcting a plan takes one message. Unpicking a finished build that went in the wrong direction takes much longer.
Checkpoint 1 of 6· Put it in order
Put the phases of a Claude-assisted build in the order the best-practices guide recommends.
- 1.Explore: Claude reads the relevant material and learns how things work now
- 2.Implement: Claude builds from the plan, writes tests and fixes failures
- 3.Commit: the change is recorded with a descriptive message
- 4.Plan: Claude identifies what needs to change and writes a plan
Exploring and planning come before any edits, so a person can review the plan before anything changes. Implementation follows the approved plan, and the commit records the result.
“Plan before editing to review changes before they touch disk”Source: code.claude.com
2.Give Claude a check it can run
The definition of done you wrote at design time pays off here. Most weak requests to Claude are missing a check. Anthropic's best-practices guide shows the same tasks written with and without a verification criterion:
| Strategy | Before | After |
|---|---|---|
| Provide verification criteria | implement a function that validates email addresses | write a validateEmail function, with example test cases, then run the tests after implementing |
| Verify UI changes visually | make the dashboard look better | implement this design from a screenshot, screenshot the result, compare, list differences and fix them |
| Address root causes, not symptoms | the build is failing | paste the error, fix it, verify the build succeeds, and do not suppress the error |
In every row, the improved request asks Claude to run the check and keep working until it passes, all in the same message. Anthropic calls this a verification loop: Claude checks its own work and attempts to fix whatever fails. Any check you find yourself doing by hand over and over is a candidate for one of these loops. For higher stakes, use a second opinion: a fresh model tries to refute the result, so the agent that did the work is not also the one grading it.
Checkpoint 2 of 6· Check yourself
A team keeps asking Claude to "make the weekly status report better" and gets inconsistent results. Which change to the request will help most?
The most effective requests include a verification criterion and ask Claude to run the check and iterate in the same message.
“In one prompt: ask Claude to run the check and iterate in the same message”Source: code.claude.com
Checkpoint 3 of 6· Exam question
A project lead is demonstrating a new Claude-assisted reporting workflow to executives who could fund its wider use. What should the demonstration make clear alongside the benefits?
Correct answer: C — Where the workflow still needs a person to check the output, and the kinds of error it can produce.
- A. Design effort is a cost already incurred and tells executives nothing about whether the workflow is dependable. It answers a question about the team rather than about the decision being funded.
- B. A tool comparison explains how the team arrived here, which may be of passing interest. It does not tell executives what they will be relying on or where it can go wrong.
- C. Correct. Honest communication of capability and limitation is what makes the funding decision sound: executives need to know which checks remain human and what kinds of error to expect, or they will plan for a level of automation the workflow does not deliver.
- D. Showing the instructions is transparent about the mechanics but not about the risk. Executives are not well placed to infer failure modes from wording, and detail here can create false reassurance.
3.Judge the result, not just whether it runs
Passing its checks does not make a result good. The AI Fluency course for builders warns that Claude's default output is often technically complete but misses the point. AI also has predictable blind spots: concurrency, security, and anything that only breaks at scale. The course gives five lenses for judging AI-generated work: correctness, quality, fit, experience and responsibility.
The most revealing test is a real user. Hand your build to someone playing the user, and do not explain it or help them. Watch where they get confused, what they ignore, and what they wanted that you never built.
Now compare the two signals. If the tests pass and the user is happy, you are on track. If the tests pass but the user is unhappy, the build is not at fault. You described the wrong intent. Go back up the Description Chain to the link that broke, whether that is the requirement or the spec, before you ask Claude for another version.
Checkpoint 4 of 6· Check yourself
A Claude-built intake form passes every acceptance test, but pilot users keep abandoning it halfway. What does this most likely tell you?
Passing tests combined with unhappy users points to a description failure. The tests measured the wrong intent, so the fix starts upstream of the code.
“A passing test with an unhappy user means you described the wrong intent.”Source: academy.claude.com
Sources5
4.Iterate in small, measurable steps
Iteration means changing something, checking whether it helped, and keeping or reverting it. That only works if each change is small enough to evaluate on its own. Anthropic's workflow guidance says to make changes in small, testable increments and to verify each one. It also says to fix root causes rather than suppress symptoms.
The same discipline applies to prompts and to Claude-assisted processes. Anthropic's classification cookbook lists two practices that matter once a system is in use. Regression detection makes sure a prompt change has not quietly hurt accuracy. Version control tracks performance over time as the system evolves. Put these together with the acceptance statements from your design phase and you get a working rhythm. Make one change. Measure it against the same criteria as before. Record the result. Then decide.
If several changes ship together and quality drops, there is no way to tell which change caused the drop. And if the original criteria were never written down, there is nothing to compare the new version against.
Checkpoint 5 of 6· Check yourself
A team wants to make three improvements to its Claude-assisted proposal process: a new prompt, a new template and an extra review step. What is the soundest way to roll them out?
Small, testable increments let you attribute any improvement or regression to a specific change. Shipping changes together hides which one caused the effect.
“Do refactoring in small, testable increments”Source: code.claude.com
Checkpoint 6 of 6· Exam question
In a pilot of a new Claude-assisted briefing arrangement, three of eight testers report that the output is "not quite right" but say nothing more specific. What should the pilot's owner do first?
Correct answer: B — Ask the three testers for specific examples, with what the output said and what it should have said.
- A. Rewriting on a hunch changes the arrangement without knowing what is wrong. If the guess misses, the pilot now has two versions and still no diagnosis, and the testers' original complaint remains unexplained.
- B. Correct. "Not quite right" is not actionable, and the cheapest way to make it actionable is to ask for cases. A concrete pair of what was produced and what was wanted turns vague dissatisfaction into a specific gap the instructions can address.
- C. Learning from the satisfied testers may eventually help, but it assumes the difference lies in how the tool was used rather than in the briefings themselves. It also leaves the three unresolved complaints uninvestigated.
- D. Direct observation is thorough but slow, and pausing the pilot stops the flow of evidence just when it is needed. Asking for examples costs an email and usually locates the problem immediately.
Exam traps
Each one states something that sounds right. Open it to see what is actually true.
1.If every acceptance test passes, the solution is done.Why is that wrong?
Tests only check the intent you described. If users are unhappy even though the tests pass, the description was wrong and you need to revisit it upstream.
Covered in Judge the result, not just whether it runs
2.Bundling several fixes into one revision is the fastest way to improve a Claude-assisted process.Why is that wrong?
Changes should go in as small, testable increments so that any regression can be traced to the change that caused it.
Covered in Iterate in small, measurable steps
Sources
Every claim above is drawn from one of these pages, quoted as it was written on the date shown.
- 1.
“Plan: Claude explores and proposes a plan without editing your source files”
↩︎ Plan before Claude changes anything - 2.https://code.claude.com/docs/en/common-workflowsOfficial docs
“Plan before editing to review changes before they touch disk”
↩︎ Plan before Claude changes anything“Do refactoring in small, testable increments”
↩︎ Iterate in small, measurable steps“Do refactoring in small, testable increments”
↩︎ Exam trap 2 - 3.https://code.claude.com/docs/en/best-practicesOfficial docs
“has a fresh model try to refute the result”
↩︎ Give Claude a check it can run“In one prompt: ask Claude to run the check and iterate in the same message”
↩︎ Checkpoint - 4.
“a verification loop is an iterative process where Claude checks and attempts to fix the work.”
↩︎ Give Claude a check it can run“Anything you keep having to enforce by hand as a manual check qualifies for capture as a loop.”
↩︎ Give Claude a check it can run - 5.
“Code that runs can still fail. The default AI output is technically complete but often misses the point.”
↩︎ Judge the result, not just whether it runs“Evaluate AI-generated work across five lenses: correctness, quality, fit, experience, and responsibility”
↩︎ Judge the result, not just whether it runs“Watch where they get confused, what they ignore, and what they wanted that you never built.”
↩︎ Judge the result, not just whether it runs - 6.
“Regression detection: Ensuring prompt changes don't accidentally hurt accuracy”
↩︎ Iterate in small, measurable steps“Version control: Tracking prompt performance over time as your system evolves”
↩︎ Iterate in small, measurable steps
Also cited
- https://academy.claude.com/courses/ai-fluency-for-builders/description-building-great-thingsOfficial docs
“A passing test with an unhappy user means you described the wrong intent.”
↩︎ Exam trap 1“A passing test with an unhappy user means you described the wrong intent.”
↩︎ Checkpoint