The agent wrote 180 lines before lunch. Every test it wrote passes. The rounding rule is still wrong, and review is now four times longer than last year. That’s the TDD problem now. Writing the code got cheap. Figuring out exactly what the code should do didn’t.
What This Looks Like in Practice
Imagine a team of eight developers. They review the output and decide whether it solves the problem. Each person handles five or six tasks in parallel.
DORA 2025 found that 90% of respondents already use AI at work. Faros 2026 shows what delivery looks like after that adoption wave. The problem is that code generation got faster, but the rest of the delivery process didn’t.
In August 2026, NIST released the initial public draft of NIST AI 200-2 (TEVV-Athlon). The comment window runs through 6 October 2026. For an engineering team, the idea is pretty simple: decide what success looks like first, then let the agent do the work. A passing PR is one event. Production incidents per PR are another.
Now Review Is the Bottleneck
The old workflow was pretty straightforward: define the work, write the code, review it, and ship it. Until recently, writing the code took most of the time. A developer sat down and wrote code. This took days. By comparison, code review was cheap and often took only about half an hour per pull request.
Agents can now cut the coding step from days to minutes, while review still moves at human speed.
Once code gets cheap, the work starts backing up in review. Faros AI collected data from over 22,000 developers across more than 4,000 teams over two years. Here’s what that looks like in 2026: median PR review time is up 441%.
The DORA 2025 report makes the same point more cautiously: higher AI adoption is associated with greater delivery instability.
So code isn’t really the bottleneck anymore. The harder part is deciding whether the code is actually right.
A Passing PR Can Still Be Wrong
A real PR makes this easier to see.
A developer gave an agent a task: add discount handling for enterprise clients. The agent returned 180 lines. On the surface, the PR looks clean, and every test the agent wrote for it passes.
What’s wrong here?
The problem is that those tests may just confirm the agent’s own interpretation of the requirement. If that interpretation is wrong, the tests can be wrong too. If the agent misunderstood the rounding rule, the test will encode the wrong behavior and lock that mistake in for years.
We’ve seen this in practice. Kent Beck, the creator of TDD, describes the pattern directly: agents tend to write the answer first and backfill tests around it. Beck encountered agents that deleted a failing test instead of fixing the implementation. The 2025 Stack Overflow Developer Survey found that 66 percent of more than 49,000 respondents said AI outputs often need correction.
Every PR Has Four Jobs
Break the PR into four jobs, and the key distinction becomes clear.
| Part | What it is | Who can write it |
| Specification | What the system should do | human |
| Test | Automated verification of the specification | human or agent |
| Implementation | Code that passes the test | agent |
| Review | Whether this is actually what is needed | human |
Specification and review are really the same decision at two different points. First you decide what “right” looks like. Then you check whether you actually got it. That is why TDD matters again.
TDD Was Expensive. AI Changed the Math.
TDD has been around for decades. Kent Beck described the practice as part of Extreme Programming in the early 2000s, and the most rigorous industrial study was conducted back in 2008.
Nagappan and colleagues studied four teams, three at Microsoft and one at IBM, that transitioned to TDD. The result: pre-release defect density dropped by 40-90% compared with similar projects using conventional development workflows. Teams also reported that development took 15 to 35 percent longer at first.
In practice, that meant spending 15-35% more time up front to avoid 40-90% of those defects later. On paper, the math worked. In practice, teams often skipped it because the cost hit now; the payoff showed up later and was harder to measure.
The TDFlow authors identify the extra time required as the main barrier to broader adoption of TDD.
AI Flipped the Cost Curve
That math has changed.
The 15 to 35 percent overhead came from writing both the test and the implementation by hand.
AI can carry much of the implementation load, leaving developers responsible for defining the test.
TDFlow puts hard numbers behind that shift. Researchers at Carnegie Mellon built TDFlow, a workflow of specialized subagents designed to make a given test suite pass. They compared two modes on SWE-Bench Verified (500 real GitHub tasks):
| Mode | Success rate | Cost per task |
| Tests written by humans | 94.3% | $1.01 |
| Tests generated by agent | 68.0% | $4.12 |
Source: TDFlow
Treat the 94.3% as a harness result under human-written tests, not as a 2026 production ceiling. OpenAI retired SWE-bench Verified as a frontier signal in February 2026 (due to contamination and defective tests), and on 8 July 2026 retracted its later recommendation of SWE-Bench Pro after finding that about 30% of Pro tasks were defective. TDFlow’s comparison still holds: human tests beat agent-written tests on the same suite. Score your own tickets the same way.
The economics get hard to ignore. With tests written by humans, the success rate rises by 26.3 percentage points while cost falls from $4.12 to $1.01 per task. Human-written tests were both cheaper and more successful.
The authors also found that TDFlow solves 93.3 percent of tasks when generated tests accurately reproduce the target behavior.
Take the discount example again. Imagine two tests for the same rule. The first says that 50,000 in revenue should produce a 12 percent discount. Both tests pass with a correct implementation. With a broken implementation, the second can still pass because it never tested the business rule.
Developers still own the business rule.
Getting the agent to pass a test is the easy part — Writing a test worth passing is the hard part.
Three Things Flipped the Economics
Three shifts changed the economics of TDD.
Implementation cost fell off a cliff twice: first from GPT-4 list price in March 2023 to 2025 rates (over 90% down), then again through 2026, for mid-tier and open-weight inference. A day of coding work now costs dollars in tokens. Review and incident costs barely moved. That is the Faros pattern: +441% median time in review.
Second, tests turned out to be a strong steering mechanism. Research by Matthews and Nagappan showed that providing tests alongside a problem description improves task-solving performance. A test gives the agent a hard target, unlike a prose description in a ticket.
Third, the industry started saying it explicitly. In February 2026, Martin Fowler and Thoughtworks hosted a workshop to mark the 25th anniversary of the Agile Manifesto. The report concluded that TDD yields better results with AI agents because it prevents agents from writing tests that validate broken behavior. Kent Beck calls the combination of TDD and agents a superpower.
Where Agents Start Gaming the Loop
Agents Will Take the Shortcut
Give an agent room to game the test, and it often will, making this a systemic pattern rather than an isolated failure. TDFlow reduces this risk by blocking changes to test directories. The Superpowers plugin for Claude Code takes a more aggressive approach: if code was written before a failing test existed, the framework deletes that code.
More Tests Do Not Fix a Bad Target
A February 2026 preprint found that tests the agent writes during implementation were created at similar rates for solved and unsolved SWE-bench Verified tasks. The controlled experiment found statistically similar outcomes across prompts that encouraged more or fewer tests. The failure starts when the agent gets to set its own goalposts.; TDD works the other way around by starting from a known requirement.
The Hard Part Is Setting the Right Target
TDD-Bench Verified scores generated tests on fail-to-pass: the test must fail on old code and pass after the fix. The last widely cited public score was e-Otter++ at 63% F2P in August 2025.
A Green Unit Suite Can Still Miss the System
A green unit test suite proves only that the tested units satisfy their contracts. A green unit suite can still miss what breaks across the stack. when changes span shared components.
Your Bug Tracker Is Full of Failing Tests
On a legacy codebase, start with the bug reports already sitting in your issue tracker.
A bug ticket with reproducible steps is already contains the shape of a failing test, yet teams write this evidence every day, then throw it away after the fix.
The same applies to QA. The test cases already exist, but they usually arrive after the code. Move that work earlier and you change the sequence, not the workload..
Larger teams can take this a step further with mutation testing.
Mutation testing checks whether the tests themselves can catch bugs. A common objection to testing is simple: who tests the tests? You can get an answer in ten minutes..
Go into the discount rule, change the boundary condition, and run the suite. If nothing fails, your tests missed the boundary. The suite is exercising the code without guarding the behavior that matters.. Try this in one area with complex business logic, and you will learn more than line coverage ever tells you. Coverage tells you what ran. Mutation testing tells you what would actually catch a bug..
Next, the same approach scales with tooling. Meta built ACH: it intentionally injects defects into code and generates tests designed to catch them. Engineers accepted 73% of the generated tests.
Meta’s TestGen-LLM applies the same idea at scale by starting with human-written tests and keeping only changes that improve reliability.
Flip the Order on One Ticket
Take one ticket this week and reverse the flow..
- Have a developer write the failing test before the agent touches the code.
- Make sure it goes red for the right reason.
- Commit the test before implementation, so any attempt to remove it shows up in the diff.
- Only then let the agent turn it green.
- Read the diff for scope creep.
Steps 3 and 5 aren’t bureaucracy. That is where scope creep usually sneaks in.
Just as important: don’t use this everywhere. Focus tests on code that will outlive the sprint and require ongoing maintenance. The team has to move “done” upstream. That organizational change is often harder than the technical one.
You may also hear this objection from senior engineers: “So I have to manually do the boring part while the machine gets the interesting part?” The tradeoff is better than it sounds. In the spec kit pilot, senior engineers spent more time on architecture because writing tests forced the hard decisions into the open about system behavior. Before, those decisions hid inside the implementation. Now they show up where the team can challenge them. That leaves senior engineers more time for the decisions that actually need their judgment.
What I’d Trust Today and What I’d Test First
A few things are already hard to argue with.
What is already clear:
- In TDFlow, human-written tests achieved a 94.3 percent success rate, compared with 68.0 percent for agent-generated tests.
- Agents will bypass tests when given the opportunity, so technical constraints are the most reliable way to enforce this.
- Mutation testing can show whether a test suite actually catches meaningful bugs.
If you need help building these workflows, our team specializes in AI development services.
Frequently Asked Questions
-
Does AI make TDD worth it again?
Yes. Historically, TDD added 15 to 35 percent to development time up front because developers had to write both the test and the implementation. AI can now handle much of the implementation work, which changes that cost equation.
-
Can AI write meaningful unit tests?
AI can write tests, but agents do much better when a human defines the expected behavior and decides whether the test actually captures it. When the agent invents the test itself, it can just as easily lock in the wrong behavior.
-
How do we adopt TDD on a legacy codebase?
Begin by turning existing bug reports and reproduction steps into failing tests before writing the fix, then focus on code that matters to the business and changes often. Don’t try to retrofit tests onto the entire codebase at once, and use mutation testing to see whether the new tests actually catch bugs.
