Turning a Vague Ask Into a Verifiable One
A junior engineer asks Claude Code: "make the checkout page handle errors better." Claude edits five files, reports that error handling is "more robust now," and the engineer merges it without further review. Two days later, a customer report reveals that a specific payment-decline error now shows a raw stack trace instead of a friendly message.
- Identify exactly what was missing from this workflow that would have caught the regression before merge.
- Rewrite the original prompt so that it gives Claude a way to verify its own work, including at least one concrete acceptance criterion.
- Beyond the prompt, name one process-level safeguard that should have been in place regardless of how the prompt was worded.
1. What was missing:
There was no check Claude could run and no evidence requested from it. "More robust now" is Claude's own assessment of whether the work looks done, which is the only signal available when nothing produces a pass/fail result. Nothing in the interaction forced Claude — or the engineer — to enumerate the actual error cases and confirm each one renders correctly, so a case as basic as "a raw stack trace still leaks in one path" went unnoticed until a real customer hit it.
2. A verifiable rewrite:
"The checkout page should show a friendly message, not a raw error, for these cases: card declined, network timeout, and invalid CVV. Write a test for each case that asserts no stack trace or raw error object reaches the rendered output, implement the handling, and run the tests. Show me the test output." This gives Claude concrete acceptance criteria (three named cases), a way to verify each one (a test asserting on rendered output, not just "handled"), and an instruction to produce evidence rather than an assertion of success.
3. A process-level safeguard:
Independent of prompt wording, a diff like this — user-facing error
handling on a payment flow — should go through a review step before
merge, either a human reviewing git diff, or a fresh-context
verification subagent asked to check the diff against explicit
acceptance criteria ("does every named error case render without
exposing internals?") and report gaps only. The point of both the
verification-target prompt and the review step is the same: don't let
"the agent says it's done" be the only signal that reaches production.
Share this question