Skip to main content

Why Test-Driven Development Is Having a Second Act in the Age of AI Coding Agents

Divya Manohar
Divya Manohar
Co-Founder and CEO, DevAssure

TL;DR

TDD isn't becoming an "AI thing" — it's the same red-green-refactor loop. What changed is leverage: agents need an external definition of done they can't quietly rewrite. Prompt "use red/green TDD," confirm the red phase, keep specs in the loop — and verify PRs with an independent testing agent, not just the unit tests the coding agent just made green.

Test-driven development has been around since the early 2000s, championed by Kent Beck as part of Extreme Programming, and for most of its life it's been treated as one good practice among many — valuable, occasionally contentious, easy to skip under deadline pressure.

Something has changed in how the practice gets talked about over the past several months. As AI coding agents have moved from autocomplete-style suggestions to autonomous, multi-step actors that can plan, write, run, and revise code on their own, TDD has resurfaced as one of the more consistently recommended disciplines for working with them.

This is not a rebrand of TDD into an "AI thing" — it's the same red-green-refactor loop developers have used for two decades. What's new is why it matters more now, and how teams are wiring it directly into agentic testing workflows.

A quick refresher on what TDD actually asks of you​

Test-driven development, in its most disciplined form, is test-first development: you write an automated test before the implementation exists, confirm that it fails, and only then write the code needed to make it pass.

Simon Willison, in his widely read guide to agentic engineering patterns, summarizes the mechanics simply: "red" is watching the test fail, "green" is confirming it now passes, and the discipline of confirming the red phase first matters because skipping it risks writing a test that was already passing — which means it never actually exercised your new code.

Willison, who has written extensively about coding agents this year, argues that test-first development "turns out to be a fantastic fit for coding agents" specifically because it protects against two of the most common failure modes: agents writing code that doesn't actually work, and agents building things that are unnecessary and never get used.

That framing is worth sitting with, because it reframes TDD from "a good habit" into something closer to a structural fix for a specific new problem. Kent Beck himself has been described in developer communities this year as calling test-first development a "superpower" in this context — the idea being that a test written before the code is an objective definition of "done" that the agent cannot quietly redefine to match whatever it happened to build.

In practice, the pattern shows up as a short, almost shorthand-style instruction to the agent. Willison's guide gives a representative example:

Build a Python function to extract headers from a markdown string. Use red/green TDD.

The phrase "red/green TDD" works as shorthand because capable models already understand it to mean the longer instruction — write the tests first, confirm they fail, then implement until they pass — without needing that spelled out every time. That compactness is part of why the pattern has spread quickly: it doesn't require a bespoke prompt template, just a two-word instruction layered on top of however a team already prompts its agents.

The core argument: agents can't grade their own homework​

The reasoning that keeps surfacing across recent commentary is fairly intuitive once you see it stated plainly. If you ask an AI coding agent to write a function and then write tests for that function afterward, the agent is effectively grading its own work — and there's a real risk it writes tests that simply confirm whatever it already produced, bugs included.

If the test exists first, written against a specification a human (or a separate planning step) defined, the agent has to make the implementation conform to an external target it didn't get to author. It can't validate its own mistakes into passing.

We've made a closely related argument before: a coding agent is a poor testing agent for its own PR. TDD is the complementary discipline on the authoring side — define the exam before the essay gets written.

This idea has prominent backing from inside Anthropic. According to reporting from Forbes in a Forbes Technology Council piece published in April 2026, Boris Cherny — the creator of Claude Code — published a post in January 2026 detailing how he actually uses the tool, and singled out one insight as the most important: giving Claude a way to verify its own work. Forbes reports Cherny's claim that this feedback loop can "2-3x the quality of the final result."

I'm relying on Forbes's characterization of Cherny's post here rather than a primary source fetched directly for this draft, so treat the specific "2-3x" figure as a reported claim from the person who built the tool, not an independently verified benchmark. Still, the underlying logic — that self-verification loops are the highest-leverage lever available to teams using AI coding agents — lines up with the broader argument for test-first development. And TDD is arguably the most mature, well-understood version of a self-verification loop that software engineering already has.

From theory to tooling: the Superpowers case​

Ideas about TDD-for-agents would matter less if they stayed confined to blog posts. They haven't.

The clearest evidence of real adoption is a Claude Code plugin called Superpowers, built by developer Jesse Vincent (who goes by obra on GitHub) along with collaborators at Prime Radiant. Superpowers bundles an entire engineering methodology — moving an agent from brainstorming, to a written spec, to isolated git worktrees, to test-driven implementation — into a set of enforceable skills.

What makes Superpowers notable for this discussion isn't its popularity so much as how literally it enforces TDD: according to descriptions of the plugin, if code gets written before a failing test exists for it, the framework deletes that code. That's a considerably more aggressive enforcement mechanism than most human engineering teams apply to themselves, and it suggests something about where practitioners think the real risk lies — not in agents being incapable of writing tests, but in agents (like time-pressured humans) skipping the "write the test first and watch it fail" step whenever it's inconvenient to follow.

Separately, reporting from The Register on an Agile-community workshop held in February 2026 described test-driven development as "ideal" for AI-assisted work, reinforcing that this isn't purely a developer-blog phenomenon — it's showing up in more traditional software process circles as well.

Where it gets more complicated​

It would be tidy to end there — TDD plus agents equals better code, full stop — but a nuance is worth raising, particularly if you read agent-written testing behavior with some skepticism.

A preprint posted to arXiv earlier this year (Rethinking the Value of Agent-Generated Tests for LLM-Based Software Engineering Agents, arXiv:2602.07900) studied agents resolving real GitHub issues and found that the sheer volume of tests an agent wrote during autonomous bug-fixing correlated only weakly with whether it actually resolved the issue — and that a large share of what agents called "tests" were closer to value-revealing print statements than real assertions.

On its face, that finding might seem to undercut the case for TDD. It doesn't, and the distinction matters.

That study was looking at agents writing tests on the fly, mid-task, as an optional self-directed behavior during autonomous patch development — closer to ad hoc debugging than disciplined practice. Disciplined test-first development is a different thing entirely: the test is written before any implementation exists, ideally against a human-authored or human-reviewed specification, confirmed to fail, and treated as a hard gate the agent cannot route around.

The arXiv findings arguably make the case for TDD stronger, not weaker — if agents left to their own devices default to loose, observational, print-statement-style "testing" that provides little real signal, then externally imposed, assertion-based, test-first discipline is exactly the corrective a team would want. The tools that enforce real red-green cycles, rather than letting the agent decide when and whether to write meaningful tests, are addressing precisely the weakness that study surfaced.

Pair that with RepoRescue's demonstration that agents can also edit tests to chase green checkmarks, and the through-line is clear: optional self-tests inside the coding loop are not enough. You need gates the agent does not get to author and weaken alone.

The complementary idea: spec-driven development​

A related thread gaining traction alongside TDD is spec-driven development, which addresses a different failure mode sometimes described as "drift" — confident, plausible-looking code that quietly solves the wrong problem.

Where TDD provides a mechanical, automatable check ("does the code pass this test"), a written spec provides a semantic check ("is this even the right behavior to build"). The two aren't competitors; several of the workflows referenced above, including Superpowers, chain them together — spec first, to establish what "correct" means, then test-first implementation, to mechanically verify it.

Search interest in "spec-driven development" has picked up over the past few months alongside interest in agentic coding generally, suggesting teams are converging on the idea that agents need both a semantic anchor and a mechanical one.

The harder problem is organizational, not technical​

Perhaps the most grounded point in recent Forbes commentary is that the obstacle to broader TDD adoption in AI-native teams isn't really technical — coding agents are perfectly capable of following a red-green loop when instructed to.

The obstacle is organizational: it requires product and engineering to agree on expected behavior before implementation starts, and it requires teams to redefine what "done" means in a world where code can be generated far faster than it can be manually reviewed. Writing a test first forces that conversation to happen earlier, which is exactly the friction some teams are trying to avoid when they reach for an AI agent to move fast in the first place.

That friction is also why shift-left alone failed for many orgs — moving work earlier without changing who owns the definition of done just dumps more checkout on humans. TDD with agents works when the organization accepts that "done" is specified before the agent starts typing.

A reasonable objection​

None of this should be read as though TDD is costless or beyond dispute — it wasn't when Beck first popularized it, and the disagreements haven't gone away just because agents entered the picture.

Critics of TDD in its original, human-only context have long argued that:

  • Writing tests before you've explored a problem can lock in a design prematurely
  • It adds real overhead to exploratory or throwaway work
  • A comprehensive test suite is only as good as the assumptions baked into the tests — a wrong or incomplete spec produces a confidently wrong green light

Those objections carry over to agentic workflows largely unchanged, and arguably matter more when the volume of code being produced is higher: a bad test-first spec now gets implemented at agent speed rather than human speed, which could mean bad assumptions get built out further before anyone notices.

The counterargument from TDD's current proponents is essentially that this overhead was always worth paying for anything beyond a true throwaway prototype, and that agents make the payoff larger, not smaller, because they remove the excuse that writing tests first is too slow.

Reasonable teams can land in different places on that trade-off. Treat "use TDD with your agents" as a strong default rather than a rule with no exceptions — exploratory spikes and genuinely disposable prototypes are still likely candidates for skipping it.

What this means in practice​

For engineering teams adopting AI coding agents, the practical shift isn't complicated to describe, even if it's culturally harder to enforce:

  1. Ask the agent for a failing test before you ask it for an implementation
  2. Confirm the test actually fails for the right reason
  3. Only then let the agent build toward green
  4. Be specific about behavior and edge cases in the test itself — a well-written test is, in effect, a natural-language-adjacent spec the agent can't misinterpret as easily as a prose prompt
  5. Watch whether the resulting tests are real assertions or print statements dressed up as verification, given what research on agent testing behavior suggests about the default tendency

None of this is a new methodology. It's TDD, applied with slightly more discipline than most teams historically bothered with, because the thing being tested now writes code faster than any human can review it.

Unit TDD still isn't end-to-end QA​

One more practical caveat: a green unit suite — even one written test-first — does not prove the user-facing flow still works after the agent touched three shared components and a routing change.

That's where an independent PR-native testing agent like DevAssure O2 fits alongside TDD: O2 reads the pull request diff, maps blast radius across flows, generates plain-English tests, and executes them in a real browser. The coding agent chases red-green on contracts it was given. O2 asks whether the product still behaves correctly for users — outside the same loop that wrote both the code and the unit tests.

For teams already running GitHub Actions, the pattern is additive: TDD in the agent session, O2 on the PR.

The bottom line​

TDD's second act isn't nostalgia. It's a recognition that when code is cheap, specification and verification become the scarce resources. Red/green TDD gives agents a machine-checkable target they didn't get to invent after the fact. Specs keep that target pointed at the right problem. And independent PR testing keeps the coding agent from being the only grader in the room.

The discipline didn't change. The cost of skipping it did.

Because agents write code faster than humans can review it, teams need an external definition of "done." Test-first development gives the agent a failing test to hit before implementation exists — so it cannot quietly redefine success to match whatever it already built. Simon Willison and other practitioners describe red/green TDD as one of the highest-leverage short prompts for agents.

DevAssure​

External references​