Test-driven development with AI agents

Of all the ways to make an AI agent reliable, test-driven development is the one I'd reach for first. It takes an agent's biggest weakness — producing plausible code that might be wrong — and removes it, by giving the agent a target it can check itself against, before you ever look.

Here's how TDD works with an agent, why it fits the agentic loop so naturally, and the one prerequisite without which it falls apart.

Why TDD fits agents so well

Test-driven development means writing the test before the code: state what "correct" looks like as a runnable test, watch it fail, then write just enough code to make it pass. Humans have done it for decades to catch regressions early and keep intent honest.

It fits agents even better than it fits humans, for one reason: an agent loves an unambiguous target. Given a failing test, the agent has a crisp, machine-checkable definition of done — and it can run the test itself, see red, fix, see green, all inside its loop. No guessing whether it's finished. The test says so. The teams getting the most reliable results treat TDD as the default discipline for exactly this reason.

Red-green-refactor at machine speed

The classic TDD cycle is red-green-refactor: write a failing test (red), make it pass (green), then clean up the code without breaking the test (refactor). An agent runs this loop the same way a disciplined developer does — just faster.

1. Red. The test exists and fails, because the feature isn't built.
2. Green. The agent writes the minimum code to pass it, running the test until it's green.
3. Refactor. The agent tidies the implementation, re-running the test to confirm nothing broke.

Stuart Leo

A test the agent can run turns "I think this is done" into "this is done, here's the green run." That's the whole value.

The agent does the tedious part — the many small runs — at machine speed, while the test holds the line on what correct means.

Test infrastructure is the prerequisite

Here's the catch, and it's the thing that makes or breaks agentic TDD: it only works if your project can already run tests.

If there's no test runner configured, no existing test patterns to copy, and no CI to validate against, the agent has nothing to optimise toward — and the loop collapses into the same hopeful guessing TDD was meant to fix. This is why the most successful agentic setups invest in test infrastructure first, before turning agents loose. Test infrastructure isn't overhead here. It's the signal the whole approach runs on.

If your project has no tests, the first high-value agentic task is to set up the runner and write a few real tests — and from then on, TDD is available to everything else.

Tests as acceptance criteria the agent self-checks

This connects directly to acceptance criteria. A test is an acceptance criterion in its strongest form — one the agent can run without you. "The form rejects an empty email" as prose is a criterion. The same thing as a passing test is a criterion the agent verifies itself, every loop, with zero ambiguity.

So writing the test first isn't a separate discipline from briefing well. It's the sharpest version of it: you're handing the agent its finish line in executable form.

Where it fits the cascade

In practice, the test belongs in the brief. When you scope a unit of work, include the tests (or the criteria they encode) as part of what "done" means. The agent builds against them and reports the green run as proof. When the work is finished, your session brief records what's verified — and "the suite passes" is the most honest line you can write in it.

A test the agent can run is the clearest target you can give it — and the cheapest way to stop regressions before they ship.

Start here: learn to write acceptance criteria, read the field note on a refactor tests saved, or read the method.