Claude Code Quality: Review and Measure What It Produces

The quality of code Claude Code produces is not fixed. It depends on how well the task was specified, how much relevant context Claude Code had, and how rigorously the output is reviewed. A weak task description produces a technically correct but wrong solution. A strong description with clear acceptance criteria and a careful review gives you output you can trust.

Quality judgment belongs with a person, not with Claude Code itself. Record the acceptance criteria before the session starts in a tool like fenbs, and the review step is faster and more consistent across sessions.

What does quality mean for AI-generated code?

Quality in code from any source covers three things: correctness, readability, and maintainability. For AI-generated code, a fourth concern appears: scope. Claude Code can produce code that is correct and readable but that also changes things you did not ask it to change. A quality review checks all four.

• Correctness: does the code do what the task description said it should do? Does it handle the named edge cases?
• Readability: would a teammate understand this code without the session transcript? Does it follow the project's conventions?
• Maintainability: does it introduce new dependencies, unusual patterns, or structural choices that make future changes harder?
• Scope: does the diff stay within the files and behavior the task specified? Any change outside the stated scope needs a deliberate decision, not an automatic acceptance.

How do you check that the code does what you asked?

Start by reading the diff, not the description. Claude Code's summary of its own changes can be accurate, but it can also omit a side effect or describe intent rather than effect. The diff shows exactly what changed.

Compare the changed behavior against the acceptance criteria you wrote before the session. If the criteria say "the function returns an empty list when the input is nil" then test that case explicitly, do not infer it from a passing test suite. The test suite covers the cases that exist in the test files; it does not know about the cases you named in the task.

How do you use tests to measure output quality?

Ask Claude Code to run the existing test suite after every change and report the result. A failing test is the clearest quality signal you have. If all tests pass, check whether the changed behavior is actually covered; Claude Code can modify code in a way that makes all existing tests pass while the new behavior you asked for is not tested at all.

For important changes, write a targeted test for the new behavior before asking Claude Code to implement it. This is a lightweight form of test-driven development that also serves as an unambiguous specification. When the test passes, the implementation is at least correct on that criterion.

How do you spot repeated defect patterns?

A single mistake is a correction. The same mistake across multiple sessions is a signal about the task instructions, the project context, or the acceptance criteria. Common patterns to watch for include:

• Missing null or empty-input handling. If Claude Code repeatedly forgets to handle nil, add an explicit rule to CLAUDE.md or the task template.
• Changes outside the stated scope. If Claude Code repeatedly touches files it should not, name the off-limits files explicitly in every task.
• Incorrect naming conventions. If generated names diverge from project style, add the convention to CLAUDE.md with examples.
• Missing error handling. If exceptions or errors are swallowed, add a rule that every public function must surface errors to the caller.

Each repeated pattern is a candidate for a project rule. Once you write the rule, every future session starts from it rather than discovering the same problem again.

How do you record acceptance decisions?

When you accept a change that involves a tradeoff — choosing one approach over another, accepting a simpler implementation over a more complete one — record the reason. "Accepted the simple approach because the more complete version would require a database migration we cannot do in this sprint" is a decision a future assistant needs to understand, not just the code that resulted from it.

A decision without a reason is just a fact. A decision with a reason is an instruction. The next session can respect the constraint rather than proposing the more complete version again.

How to do this with fenbs

1. Create a free account and add the project you are reviewing Claude Code output on.
2. Write the acceptance criteria in the fenbs task plan before the session starts. Be specific: name the edge cases, the files in scope, and the behavior you are checking.
3. Connect Claude Code to fenbs from Integrations. Ask it to read the task before starting so it knows the criteria.
4. After reviewing a change, record any tradeoffs or constraints as decisions in fenbs. If Claude Code missed something, add a lesson linked to the task.
5. When a repeated defect becomes a rule, add it to Decisions and rules with the reason. The next session reads it first.

fenbs does not run tests or read code. It holds the criteria, decisions, and lessons that make each review faster and more consistent. For understanding how Claude Code behavior compares between reasoning levels, the Claude Code effort guide covers choosing the right level for the task. For reviewing changes in parallel to compare two approaches, the fork guide explains that workflow.