The advice you keep hearing
If you've asked around about getting better output from a coding agent, someone has told you to instruct it to follow test-driven development: write a failing test, then the minimum code to pass it, then refactor, repeat. It sounds like exactly the kind of discipline an agent needs. It's also nearly impossible to verify from the outside - you see a pull request with tests attached, not the order in which anything was actually written.
So the advice mostly gets repeated on faith. One recent piece of work tried to check it.
What was actually tested
Birgitta Böckeler, a Distinguished Engineer and AI-assisted delivery expert, ran an exploratory comparison (Martin Fowler's site, August 2026) of three ways TDD can appear in AI-assisted coding:
1. A human writes the tests, AI implements against them. 2. AI writes a failing test, a human reviews it, then AI implements. 3. The agent does the whole loop itself: write a failing test, then the implementation, then check it goes green, one test at a time.
The third pattern - full TDD delegated entirely to the agent - is, in her account, by far the most common way people try to use TDD with coding agents today. That's also the one her evaluation focused on.
The setup: three greenfield business-logic tasks (small, medium, larger), generated with Claude's help and deliberately made idiosyncratic so solutions wouldn't just converge on something memorised from training data. Sonnet 4.6 generated the solutions, both with and without TDD instructions, all with a required 80% code coverage target. A separate agent judged how well each "TDD" run had followed the workflow, allowing Böckeler to interpret the results in light of how closely each run actually followed TDD. Then Opus 4.8 - blind to which solutions were TDD and which weren't - compared solution and test quality against a rubric it constructed itself, and mutation testing scores were compared too.
Böckeler is explicit that this is a small, informal exploration, not a controlled study: a handful of batches, small greenfield tasks, Sonnet 4.6 generating the solutions, Opus 4.8 judging them, and quality judged largely by another AI model's own rubric.
What the source reports finding
According to the article:
- Across the small and medium tasks, the two non-TDD solutions were ranked #1 and #2 by Opus, with the two TDD solutions ranked #3 and #4. The author calls this "a bit of a pattern" rather than a uniform result.
- Only once - after the TDD prompt was strengthened with an explicit refactor-and-design-review step - did a TDD solution rank first. In that same batch, the other TDD run, using the identical prompt, ranked last.
- On the larger task, a TDD run landed in the middle of the ranking, while the two non-TDD runs took both the best and the worst spot.
- Mutation testing scores showed no meaningful difference between TDD and non-TDD solutions.
- Böckeler's own hypothesis, informed by having Opus review the session traces: the non-TDD and "tests-first-but-not-strict-TDD" runs tended to work out the full design - architecture, data types, edge cases, contracts - before writing any code or tests. The strict TDD instruction, by contrast, pushed the agent to work through the problem one test at a time, and that seemed to work against building that fuller picture up front, correlating with weaker data models and less complete edge-case coverage in the TDD runs.
That last point is offered as a hypothesis from a small sample, not a proven mechanism. It's worth treating it that way.
What this doesn't tell you
Before changing anything, be clear about what wasn't tested. This used Sonnet 4.6 to generate the solutions and Opus 4.8 to judge them, small greenfield tasks with no existing codebase to integrate against, and no runs that followed TDD with full discipline throughout - all sessions showed some breakdown of the workflow, such as writing implementation ahead of the test or skipping the red step. It also says nothing about TDD's value for the two other patterns Böckeler describes, where a human is writing or reviewing the tests rather than the agent doing the whole loop unsupervised. And it says nothing about larger, longer-running increments on an existing codebase, which is where a different set of pressures apply.
The practical consequence
If your reason for telling an agent to "do TDD" is a belief that the ritual itself - red, green, refactor, repeated by the agent alone - produces better-designed code, this exploration gives you a specific reason to question that. On this evidence, instructing the agent to work incrementally, test-first, and entirely unsupervised may cost you the fuller upfront thinking about data shapes and edge cases that a design pass would otherwise produce - without a compensating gain in test or mutation quality.
That's consistent with what PDAID asks you to do anyway: work out Purpose, Behaviour, Clarifications, and Context & Constraints before the agent starts the Build phase, rather than delegating that thinking to whatever emerges from writing one test at a time. The Behaviour Definition Template is exactly the place to capture the data model, edge cases and contracts up front - which is the design step this study suggests the strict TDD loop can end up skipping.
None of this means testing matters less. It means the order of operations matters, and "make the agent follow TDD end to end" is not automatically a substitute for deciding what the code should do before you ask for it. Once you've defined behaviour and constraints, your Test & Correct work should still verify the result against them - the question here is only whether forcing a test-first ritual inside the agent's own loop is what gets you there, and on this evidence it isn't obviously better than the alternative of designing first and testing the outcome afterwards.
If you want to try instructing an agent toward TDD yourself, this piece of work is a reasonable reminder to check the transcript, not just the tests it produces at the end - Böckeler's own evaluation only worked because she checked whether the agent had actually followed the workflow it was told to.