Write tests first and let AI fill in the implementation
Test-driven development turns out to be the workflow assistants are best suited to.
Before you start
- A project with a working test runner
- A function you need to write
What you will be able to do
- Use a failing test as the specification you hand to the model
- Cut review time by making correctness mechanical
- Spot the cases where the model changed the test instead of the code
Assistants write plausible code quickly, which moves the bottleneck to review. Reviewing a function you did not write, against a spec that only exists in your head, is slow and unreliable.
Writing the test first fixes both ends of that: the spec becomes explicit, and correctness becomes something you run rather than something you judge.
Write the test, including the awkward cases
Empty input, wrong types, the boundary. These are where generated code fails.
Write the test first, by hand, and put the unpleasant cases in it: empty collections, nulls, the off-by-one boundary, the duplicate.
Generated implementations handle the happy path almost every time and the edges much less reliably. A test that only covers the happy path will pass, and will have verified the easy half.
Hand over the test, not a description
Paste the failing test and the signature. Say nothing about how.
Give the model the test file and the function signature, and ask for an implementation that passes. Do not describe the algorithm — that is the part you are delegating, and describing it tends to produce a worse version of your own idea.
Include the error output too. It is more precise than any prose restatement of what is wrong.
Run it before you read it
Reading first biases you toward accepting code that looks reasonable.
Run the suite immediately. If it fails, hand back the failure verbatim — one or two rounds usually resolves it.
Reading first is a trap: plausible code reads as correct, and you end up reviewing style while the boundary case quietly fails.
- If two rounds do not get it passing, the test is probably ambiguous. Read the test, not the implementation.
Warning Check that the test still says what you meant
The most common failure is a passing suite with a weakened assertion.
Assistants will sometimes make a test pass by editing the test — loosening an assertion, deleting the awkward case, wrapping the call in a try. All of these produce a green run.
Diff the test file before committing, every time. This is the single highest-value habit in the whole workflow.
- Committing on a green suite without diffing the tests. A green suite proves the tests pass, not that they are still the tests you wrote.
The test is the specification and the check. Written first, it makes generated code something you can accept or reject on evidence.
Common questions
Was this guide useful?
89% of readers found this useful
Read next
Use an AI coding assistant without shipping code you did not read
AI assistants are genuinely good at writing code and genuinely bad at knowing when they are wrong. This is the review process that…
Review AI-generated code in ten minutes
Generated code fails in a characteristic pattern — rarely in the logic, often at the edges, the dependencies and the error handlin…
Build your first agent that does one thing reliably
Agent demos look magical and agent deployments mostly fail on the same three things: unbounded loops, unverified tool output, and…
Choose your first AI assistant without overthinking it
Every comparison table lists twenty differences and only three of them change your day. Here is how to pick in ten minutes and get…
