Test-Driven Development with Coding Agents
Use tests as the contract: write or generate failing tests first, let the agent make them pass, and keep agent changes honest.
A coding agent can write a hundred lines of plausible code in less time than it takes you to read the first ten. Plausible isn't the same as correct, though, and the faster code arrives, the more you need a cheap, objective way to tell the difference. Tests are that way.
You've already seen tests used as a definition of done in Writing Tasks an Agent Can Actually Finish, and every step of a good plan in Plan First, Then Execute came with a check. This lesson turns that idea into a complete workflow. You'll learn the red-green loop adapted for agents, who should write the tests (and when), how to stop an agent from quietly bending tests to fit its code, and when test-first is the wrong tool. By the end you'll be able to hand an agent a contract and get back code that provably honors it.
Why tests and agents fit together
Test-driven development (TDD) is a way of working where you write a failing test for a behavior first, then write just enough code to make it pass, then clean up. Its rhythm is often called red, green, refactor: red when the new test fails, green when it passes, refactor while it stays green.
For human developers, TDD has always been a discipline with a cost: writing tests first feels slow. With an agent, the economics flip.
- The agent does the slow part. Writing test boilerplate and iterating until it passes is exactly the tedious work agents are good at.
- The agent can check itself. A test is feedback the agent can run inside its loop, over and over, without you. As the landscape lesson put it, the loop plus real feedback is the whole trick.
- Tests are a spec you can read in minutes. Reviewing twenty lines of test cases is far faster than reviewing two hundred lines of implementation. If the tests say the right thing and pass honestly, most of your review is done.
- They outlive the session. The agent forgets everything tomorrow. The tests remember what "correct" meant, and catch the next session if it breaks it.
The key shift is where your attention goes. In agent TDD, you spend your judgment on the tests and let the agent spend its effort on the code.