The debate about whether coding agents should follow test-driven development is being argued on a codebase most of our clients do not have.
We modernize ColdFusion and Rails estates for a living. The starting condition is almost always the same: little or no automated test coverage before an agent touches the code. So when the question gets framed as TDD versus no TDD, it skips the step that actually decides the outcome on a legacy system.
What the experiment actually tested
Birgitta Böckeler ran a small evaluation of prompting an agent to follow TDD inside its own loop: write a failing test, then the implementation, one step at a time. Across her batches there was no clear quality gain from TDD, and more than once the non-TDD runs scored higher on design and test quality. The reason she and her reviewers landed on is worth sitting with. The non-TDD runs designed the whole thing up front, data types, edge cases, contracts, before writing code. TDD pushed the agent into many locally minimal decisions that rarely got revisited, so the design settled on whatever shape the first test happened to lock in.
Read it in full. But note the setup: every task was greenfield, small, and purely business logic. That is not the system we get handed.
Our starting line is the opposite
You cannot test-drive code that already exists. A fifteen-year-old ColdFusion app or an aging Rails monolith is already doing something, and real users depend on that something, including the behavior nobody documented and the bug two customers now rely on. Point an agent at that with instructions to TDD a change and you get tests written against an implementation the agent just read. They prove the code does what it does, not what it should.
The first move is not TDD. It is characterization tests: tests that pin down what the existing code actually does right now, correct or not, so you have a net before you change anything.
Characterization tests before TDD, not instead of it
The sequence we run on a low-coverage estate:
Pin the current behavior first. Have the agent write characterization tests around the code you are about to touch. These are not aspirational. They record the present behavior so a regression becomes visible the moment it appears.
Read the pinned behavior before you trust it. A characterization test can enshrine a bug. That is fine as a safety net and dangerous as a spec. A human confirms which pinned behaviors are intended before any of them become the definition of correct.
Then drive the change. With a net in place, writing a failing test for the new behavior earns its keep, because now the red step means something. It fails against real, verified existing behavior, not against the agent's own fresh guess.
Böckeler's point about red-green in the loop holds here. A test going red only proves something if someone checks why. When the agent writes the test and confirms its own failure, you have learned the agent ran it, not that it failed for the right reason. On a legacy estate the characterization layer is what gives that red step a fixed reference to fail against.
The meta-lesson
Being specific about how you want a model to work is usually a losing game. The durable move is to invest in the thing that lets you check the outcome. On a greenfield toy problem that can be a mutation score. On an inherited estate it is a characterization suite, because without it neither the agent nor you know what the code was supposed to do before the change.
The teams that get burned are the ones that adopt an agent's testing ritual and skip the part that does not fit their codebase. The question is not whether your agent should do TDD. It is whether anything in your repo defines correct before the agent starts editing.
If you are pointing agents at a legacy estate, that is the work we scope first.