TDDandBDDAreRunningOutofRoad.

Test-Driven Development, formalized by Kent Beck in the early 2000s, made one bet: write a failing test, write the minimum code to pass it, refactor, repeat. The test isn't proof of correctness so much as a design tool — it forces the person about to write the code to state what "done" means first.

Behavior-Driven Development, which Dan North evolved out of TDD a few years later, made a second bet on top of it: write that test in a shared language — Given/When/Then — so the person who understands the business risk and the person writing the code can read the same sentence and agree it means the same thing.

Both bets share one load-bearing assumption: the test and the code are produced by the same accountable person, roughly in lockstep, with the intent still fresh in their head. For twenty years, that assumption held.

An agent can now produce a full implementation in seconds — far faster than a human can write matching tests by hand. That doesn't just speed up the TDD loop. It removes the constraint the loop depended on: that writing the test and writing the code take comparable effort, by someone equally invested in both.

BDD's other pillar strains the same way. The bottleneck was never whether a human could read Gherkin — it's whether the thing now building the feature understands risk the way someone who lived through last quarter's incident does. Prose scenarios don't transmit that; they just describe an outcome that can be satisfied on the surface.

Test-Driven Agentic Development doesn't patch TDD or BDD — it separates the roles they used to fuse into one person. A human authors a spec: not a single test, a structured statement of behavior and risk. One agent compiles that spec into an executable test suite. A second agent implements against the suite until it passes. And before any of it ships, a gate asks the question TDD and BDD never had to ask on their own, because a trusted human was always the one writing the tests: are these tests actually rigorous, or would they pass against broken code too?

That gate is mutation testing — deliberately break the implementation in small ways and count how many breaks the test suite actually catches. A suite that passes against both the correct code and a dozen broken variants of it was never testing much of anything.

And it isn't a straight line. Implementations fail their own tests and iterate. Test suites fail the mutation gate and get sent back to be strengthened. Reviewed output reveals the spec itself misjudged the risk and gets sent back further still. The diagram below is the real shape — loops included, not the version with all the rework edited out.

None of this removes human judgment from testing — it relocates it. TDD and BDD asked humans to write tests at the granularity of individual assertions. TDAD doesn't need that anymore; it needs humans at the two points an agent structurally can't stand in for.

That's why the model is strong rather than a stopgap: it stops asking humans to do the part machines now do faster — writing boilerplate assertions, implementing well-specified logic — and moves them to the part twenty years of TDD and BDD practice already proved humans are best at, just at a coarser grain than a single test case.

This isn't abstract industry punditry — the spec/gate split above is already how this product is built.