A team wants to know if their support agent works. They write 20 test cases ("how do I reset my password?", "where is my order?", etc.) and check whether Claude's response "looks right" for each one. All 20 pass. The team declares the agent ready for production.
What's the problem with this test suite?
Why did you pick that answer? Two or three sentences. The act of articulating it is what builds the judgment — not the click that follows.
A test suite is only as valuable as its hardest cases. Twenty easy questions all passing tells you the agent handles the happy path, which was already obvious. The test suite needs to include the cases that should be hard: edge cases (rare-but-real scenarios), adversarial inputs (people trying to break the agent), known-failure cases (things the agent has gotten wrong before), multi-issue requests (testing decomposition), out-of-scope requests (testing graceful refusal). The point of the suite is to find problems before users do — easy cases don't do that.
Doubling the number of "normal" test cases just gives you more confidence on the happy path. Volume in a single direction doesn't replace coverage across directions.
Replacing human checking with an uncalibrated LLM judge means you're now uncertain about both the agent and the judge. An LLM-as-Judge has to be calibrated against human ground truth before it can be trusted as a measurement instrument. Until then, human checking is the more trustworthy signal.
Asking the agent's underlying model to write its own test cases means the test suite shares the same blind spots as the agent. Tests should encode human knowledge of failure modes — exactly what the model doesn't have.