CLAUDE CODE AGENTS: FUNDAMENTALS - Chapter 6, Exercise 3
Why Zero Findings Doesn't Mean Bug-Free
====================================================================================

QUESTION:
A review agent returns zero findings on a piece of code, and the developer
concludes the code is definitely bug-free. Using this chapter's own warning
box, explain what's wrong with that conclusion.

SOLUTION / EXPLANATION:

This chapter's warning box is explicit that zero findings means the review
agent didn't find anything within its own read of the code - it is not
proof that the code has been verified as correct. A review agent has no
special access to guarantee correctness beyond what it can actually
observe; it's reading and reasoning about code the same way a human
reviewer would, and it can only report an issue if it actually recognizes
it as one during that process.

The developer's conclusion treats "no findings" as equivalent to "proven
correct," but a review is described in this chapter as a filter, not an
exhaustive guarantee. Some genuine bugs are inherently harder to spot from
reading code alone - ones that only manifest under specific runtime data,
timing conditions, or external state the review agent has no visibility
into while simply reading the source. A review agent (like a human
reviewer) can miss these, not because it did a poor job, but because
they're the kind of issue code review as a technique isn't well-suited to
catch in the first place - that's what testing (Chapter 7) exists to catch
instead.

So "the review agent found nothing" is accurately described as "no issues
were caught by this particular filter," not "this code has been proven
free of bugs." The correct conclusion is that the review didn't surface a
problem - not that no problem exists.

--------------------------------------------------------------------------
WHY THIS WORKS AS AN ANSWER:
It distinguishes "nothing was caught" from "proven correct" using the
chapter's own filter framing, and explains concretely why some real bugs
(those depending on runtime data or external state) are inherently outside
what a read-through code review can catch, rather than treating the
missed-bug possibility as vague or unexplained.