CLAUDE CODE AGENTS: FUNDAMENTALS - Chapter 5, Exercise 3
Why "Feature Complete and Working" Still Needs Checking
====================================================================================

QUESTION:
A coding agent's final report says the requested feature is complete and
working. Explain what you should still do before accepting that, and why
this matters more for a coding agent than it might for some other agent
types.

SOLUTION / EXPLANATION:

Chapter 3 established that an agent's final report describes what it
believes it did, not a guarantee that the work is correct - and this
chapter applies that principle directly to coding agents, stating that
implementation work is exactly the kind of consequential task that
deserves real verification rather than accepting a confident-sounding
summary.

What you should still do: review the actual diff of what changed, confirm
it genuinely matches what was requested (not just that something plausible
was implemented), and check that nothing outside the requested scope was
quietly touched along the way - directly following this chapter's own
guidance under "Reviewing What a Coding Agent Hands Back."

This matters more for a coding agent specifically because of what its
report is actually claiming. A teaching agent's report describes an
explanation - if it's slightly off, the cost is a slightly less useful
explanation, easily corrected by asking a follow-up question. A coding
agent's report describes an actual CHANGE made to a real codebase - if the
report is wrong (the feature isn't really complete, an edge case was
missed, or something unrelated was altered), that mistake is now sitting in
the code itself, potentially affecting other work built on top of it later,
not just a conversational answer that fades once the topic moves on. The
stakes of an inaccurate report are simply higher when the report is
describing a change to working software rather than an explanation of a
concept.

So the review step isn't extra caution specific to any one agent being
untrustworthy - it's the same "trust but verify" principle from Chapter 3,
applied with extra weight here because a coding agent's output is a real,
lasting change rather than a one-off answer.

--------------------------------------------------------------------------
WHY THIS WORKS AS AN ANSWER:
It names the specific verification step (reviewing the actual diff against
the request and checking scope), and explains concretely why the same
"trust but verify" principle carries more weight for a coding agent than a
teaching agent - the lasting, structural nature of a code change versus a
conversational explanation - rather than treating all agent reports as
equally risky.