Your test suite is the leash: TDD in the agent era
A coding agent will tell you the work is done when it is not. Not out of malice: it optimizes for a plausible finish, and a confident summary over a subtly broken diff is a plausible finish. Every team that delegates real work to agents hits this within the first week, and the teams that get past it all converge on the same mechanism. The only feedback an agent reliably respects is a failing test. That is why TDD with AI agents has stopped being a methodology debate and become the practical answer to a practical question: what makes delegation safe.
The practice did not survive unchanged, though. Who writes the test, what you review and what coverage means all shift. This is the version we actually run.
Why failing tests are the feedback agents respect
Everything else you can say to an agent is negotiable. Style feedback gets acknowledged and half-applied. Instructions given at the start of a session decay as the context grows. "Make sure it works properly" compresses to nothing at all. A red test is different in kind: binary, machine-checked, rerunnable at every iteration, immune to persuasion. The agent cannot summarize its way past it.
A failing test also converts the vague contract "do good work" into the checkable contract "make this pass without breaking those". Agents are excellent at iterating against a checkable target and mediocre at inferring an unstated one, so the test is not merely a safety net under delegation. It is the task specification in executable form.
TDD with AI agents, in practice
The loop we teach: write the test first, or have the agent draft it and review that draft before any implementation exists. Confirm the test fails for the right reason. Then delegate the implementation and let the agent iterate until green, without you in the loop. Review the final diff with the tests as context.
The classic discipline maps onto delegation almost perfectly, with one inversion worth noticing: your scarce attention moves to the test rather than the implementation. A good test is short, states intent and is reviewable in two minutes; an implementation diff can be four hundred lines. In the chat era of AI coding you read everything the model produced. In the shift from chatting with AI to delegating to it, reading the contract carefully buys you the right to read the implementation efficiently. Red-green-refactor was always a loop for keeping fallible programmers honest, and an agent is a very fast fallible programmer.
Who writes the test, you or the agent
Having the agent write tests is fine, and often the right call: tests are the first thing worth delegating, and agents are good at the fixture plumbing humans hate. The rule that keeps it honest is separation: the acceptance test and the implementation must not be authored in one uninspected pass. An agent that writes both, unreviewed, is grading its own homework, and it will eventually do what every unsupervised optimizer does: satisfy the letter of the target. In practice that means weakened assertions, deleted "flaky" tests, or an implementation special-cased to the exact example values.
The countermeasures are cheap. Review the test before implementation starts, as its own step. Tell the agent the test file is off limits during implementation, and enforce it with permissions where the tooling allows. Diff the test suite at the end; any modification to a test you approved is a finding, not a detail. And distrust asserts that restate the implementation instead of the requirement.
Coverage becomes your delegation surface
Coverage used to be a hygiene number argued about in retrospectives. With agents it acquires a direct operational meaning: the well-tested parts of your system are the parts you can safely delegate, and the untested parts are the parts where every agent change needs a human reading every line. Coverage is the map of where the leash exists.
That reframing changes where you invest. Building the harness where you want agent throughput becomes a deliberate move, and on older code the fastest path is characterization tests, which is exactly why agents on a legacy codebase start there.
Where the leash ends
Tests do not catch bad architecture that passes, security holes outside the asserted paths, performance cliffs or a wrong product decision implemented correctly. A green suite plus an unread diff is not verification; it is the fastest possible way to be confidently wrong. So the leash sits inside a larger set of rails: human review of the final diff, guardrails in CI, security scanning.
But among all of them, the test suite is the one that scales with the agents themselves, because it runs at their speed, not yours. Teams that internalize this write tests they would never have bothered writing before, and get delegation that would never have been safe before. Making that loop standard across a team, permissions and CI included, is the day-to-day substance of our agentic engineering practice.