Test-First With Claude: Make Silent Failures Impossible
TL;DR
An agent with no target writes code that looks right and quietly breaks on real inputs - and you find out by hand later. Flip the order: write the test first. Define what 'working' means as a failing test, let Claude write only enough to turn it green, then keep the suite so nothing new breaks what already worked. Correctness becomes provable instead of hopeful.
Why agent code fails quietly
When you ask an agent to build a feature, it optimizes for something that looks complete. Without a definition of correct, 'looks complete' is the whole goal - so it produces plausible code that passes a glance and fails on the input you did not mention. Writing the test first replaces 'looks right' with 'provably does the job'.
The loop
- 1Describe the behavior as a test that fails right now - the inputs and the exact expected output. This is you defining 'working' before any code exists.
- 2Ask Claude to write only enough code to make that test pass. No extra features, no gold-plating.
- 3Run the test. Green means the behavior is proven, not assumed. Red means you caught the failure now, not in production.
- 4Keep the test in the suite. Every future change has to keep it green, so new work cannot silently break old work.
A prompt that sets it up
textBefore writing any implementation, write a failing test that defines
'done' for this feature: the inputs, the expected output, and one edge
case I am likely to forget. Show me the test and let me confirm it.
Then write only the minimum code needed to make it pass. Do not add
anything the test does not require.Where it pays off most
- Anything with edge cases - parsing, money, dates, empty inputs. The test forces them out into the open.
- Code you will change again. The suite becomes a guardrail so the next change cannot regress the last one.
- Work you are handing to an agent to run less supervised. The tests are how you trust the output without reading every line.
This is the same discipline behind an anti-hallucination stack: do not trust a confident first draft, make it prove itself against something you defined. Tests are the cheapest, most local version of that check.
Common questions
Is writing tests first not slower?
It feels slower for five minutes and is faster by the end. Defining the target up front stops the agent from guessing wrong and stops you from hand-debugging plausible-looking code later. The time you spend on the test you save on the hunt.
Can Claude write the tests too?
Yes, but you confirm them first. Let it draft the test from your description, then check that it actually captures 'done' - including the edge case you care about - before it writes any implementation. You own the definition of correct; it does the typing.
What if I do not know how to write tests?
You describe the behavior in plain English - these inputs should produce this output - and let Claude turn that into a test in your language. The skill you need is knowing what 'working' means, not the test syntax.
How is this different from just reviewing the output?
Review catches what you happen to notice. A test catches the exact behavior every time it runs, forever. Review is judgment; tests are the checks that must never be skipped. You want both, but the test is what makes it provable.
Want the test-first guide with the exact prompts?
Get the other 2 in the anti-hallucination stack, plus 5,000+ builders - $9/mo, cancel anytime.
Join the Club