Software Development
TDD With AI Coding Agents: A Practical Workflow
August 20269 min read
A failing test gives the agent a precise target and an unambiguous pass or fail signal it can check after every change. That removes the ambiguity a prose prompt leaves behind, so the agent iterates toward correct behavior instead of guessing. The test suite doubles as an executable specification and a built-in verification loop.
The Claude Code best-practices guide suggests asking the agent to write tests from expected inputs and outputs, running them to confirm they fail, committing the tests, and then having the agent implement until every test passes. The critical rule is to instruct the agent not to modify the tests to force them green.
You can, but review them before you trust them. When the same agent writes both the tests and the code, they can share the same wrong assumption and pass while the behavior is incorrect. Writing or at least reviewing the tests yourself keeps them an independent check rather than a mirror of the implementation.
Cover the paths where AI code is weakest. According to Skyramp, AI-generated code has markedly higher defect rates in error handling, edge cases, and concurrency, so write those tests before the happy path. Integration seams, where isolated units meet a real database or API, deserve early tests too.
Commit the tests before implementation so they become a frozen contract, and treat any later edit to a committed test as a red flag to review. Watch for weakened assertions, deleted cases, or hardcoded expected values, and read the test diff as carefully as the implementation diff before you merge.
Key Takeaway
Test-driven development gives an AI coding agent something it cannot argue with: a failing test that defines done. Write the tests first, confirm they fail, tell the agent not to touch them, then let it write code until they pass. The tests become an executable spec and a built-in verification loop.
AI coding agents are fast, confident, and occasionally wrong in ways that look right. They will happily hand you code that compiles, reads well, and quietly mishandles the one input you forgot to mention. Test-driven development is the oldest, cheapest defense against exactly that failure mode.
The idea is unchanged from classic TDD, but the payoff is bigger with an agent in the loop. A test suite is a specification the agent cannot talk its way around, and a green run is a signal it can chase on its own. This guide walks through the workflow and where it pays off most.
An agent works best when it has a clear target and a way to check its own progress. A failing test is both at once: it states the expected behavior precisely and gives an unambiguous pass or fail signal after every change.
Compared with a prose prompt, tests remove the ambiguity the agent would otherwise fill with guesses. Three properties make them ideal:
The Claude Code best-practices guide recommends a concrete TDD sequence: ask the agent to write tests from the expected inputs and outputs, run them to confirm they fail, commit the tests, then have the agent implement until every test passes. The key instruction is that the agent must not modify the tests to make them go green.
Start by writing the red test yourself, or have the agent draft it and review it before you trust it. A small, unambiguous example sets the tone:
// invoice.test.ts — write this FIRST, watch it fail
import { describe, it, expect } from "vitest";
import { calcLateFee } from "./invoice";
describe("calcLateFee", () => {
it("charges 1.5% per month on an overdue balance", () => {
expect(calcLateFee(1000, 2)).toBe(30);
});
it("returns 0 when nothing is overdue", () => {
expect(calcLateFee(1000, 0)).toBe(0);
});
});Commit the tests before the agent writes any implementation. A committed test is a frozen contract, and if the agent later weakens it you will see the change in the diff instead of discovering it in production.
Point the agent at the code paths where AI output is weakest, not the happy path it already gets right. According to Skyramp, AI-generated code shows markedly higher defect rates in specific areas, and those areas are where your first tests belong.
TDD only works if the tests stay meaningful. An agent under pressure to make a suite pass will sometimes take the shortcut you did not intend, and a green checkmark hides it.
Watch for the agent editing assertions, deleting awkward cases, or hardcoding the exact value a test expects. Each of these turns a real test into a rubber stamp, so reviewing the test diff is as important as reviewing the implementation.
A passing suite is necessary, not sufficient. An agent can make every test green by weakening the tests, so never accept a green run without reading what changed in the test files themselves. Treat any edit to a committed test as a red flag.
TDD is one stage in a disciplined agent workflow, not the whole thing. It slots naturally between planning and review, and pipelines like Superpowers arrange the stages in exactly that order.
TDD turns an AI agent from a confident guesser into a system that has to prove its work. Write the failing test, freeze it, and make the agent earn the green. It is the same discipline that made TDD valuable for humans, and it matters more, not less, when the code is written by a machine.