TDD with AI & Verification-First Prompts
Writing tests first so the agent has a target, and prompting for proof (run the tests, show the numbers) instead of claims.
Give Claude a check it can run
The single highest-leverage habit in AI-assisted development: give the agent a way to verify its own work — a test suite, a build exit code, a linter, a screenshot comparison. Anthropic's docs put it plainly: it's "the difference between a session you watch and one you walk away from."
Here's why. Without a runnable check, the agent's only completion signal is "looks done" — the code compiles in its head, the logic seems right. Every claim then lands on your desk unverified, which means you become the verification loop: reading diffs, running tests manually, catching regressions. With a runnable check, the agent closes its own loop — write, run, see the failure, fix, re-run — and hands you evidence instead of assertions.
TDD with an agent: state the answers up front
Test-driven development (TDD) — writing the test before the code it tests — fits agents unusually well, because a failing test is exactly the kind of unambiguous target agents excel at closing. The workflow:
- State expected input/output pairs in the prompt, before any implementation:
Implement validateEmail. Expected behavior:
validateEmail("user@example.com") -> true
validateEmail("invalid") -> false
validateEmail("user@.com") -> false
Write failing tests for these first, run them to confirm they fail,
then implement until all tests pass. Run the tests after implementing.
- The agent writes the tests, watches them fail (proving the tests actually test something), implements, and iterates until green.
The input/output pairs do double duty: they're the spec and the verification. Ambiguity about edge cases gets resolved before code exists, when it's cheapest.
Guard against test-gaming
An agent optimizing for "tests pass" will sometimes make tests pass the wrong way — hardcoding expected values, special-casing the test inputs. Prevent it with explicit framing in the prompt:
Implement a solution that works for all valid inputs, not just the
test cases. Tests verify correctness — they don't define the solution.
If a test is incorrect, tell me rather than working around it.
That last sentence matters: it gives the agent a legitimate exit when a test really is wrong, instead of forcing a choice between gaming the test and silently "fixing" it.
Escalate the gate as autonomy grows
How strict your verification gate should be scales with how unattended the agent is:
| Autonomy level | Verification gate |
|---|---|
| You're watching each step | Ask for the check in the same prompt ("run the tests after") |
| Multi-turn task | A goal condition re-checked every turn |
| Walk-away session | A Stop hook — a script that runs when the agent tries to finish and blocks it from ending the turn until the script (e.g. your test suite) passes |
| High-stakes result | A verification subagent: a fresh helper session that tries to refute the result with no memory of how it was produced |
A Stop hook deserves emphasis: it's a shell command wired to the "agent thinks it's done" moment, and it turns "looks done" into "provably done" — the session literally cannot end with failing tests.
Demand evidence, not assertions
Prompt for proof as a habit: the test output, the exact command and its result, the screenshot. "All 47 tests pass — here's the output" is verifiable at a glance; "I've implemented the feature and it works" is not. Reviewing evidence the agent produces is much faster than re-running verification yourself, and it makes lies (or honest mistakes) visible immediately.
Pair it with root-cause framing:
The build fails with [exact error]. Fix it and verify the build
succeeds. Address the root cause — don't suppress the error.
Without that last clause, "make the build pass" can be satisfied by deleting the failing test or silencing the warning. Say what a real fix means.
Verification beyond tests: visual checks
Not everything has a test suite. UI work verifies visually: paste the target design screenshot and prompt:
Implement this design. Then take a screenshot of the result, compare
it to the original, list the differences, and fix them.
The agent iterates — implement, screenshot, diff, adjust — until the rendered result matches the target. Same loop, different check: the point is never the specific tool, it's that the agent has ground truth it can consult without you.
The one-line summary
Before you send a prompt that asks for work, ask yourself: what check will prove this is done, and can the agent run it? If the answer is "none," you've just volunteered to be the test suite.