Is TDD still relevant with AI?

Yes, TDD is still relevant with AI coding assistants for rules whose correct result you can state in advance. A failing test gives the assistant a signal it can run by itself, with an expected value from the requirement.

Does TDD matter more with AI-generated code?

TDD matters more with AI-generated code when an agent writes code you do not read line by line. The tests you wrote first then record what you decided, so keep them out of the agent's reach.

Should the AI write the failing tests too?

An AI can type the failing tests if you supply the cases and expected values and read every assertion. Tests an assistant writes from its own code assert its own mistakes.

How do I stop an AI agent from changing my tests?

Commit the failing tests first, deny the agent writes to test files, and check before merge that the test folder has no diff from that commit. A prompt instruction alone fails when the agent cannot make a test pass.

Should I use TDD with AI coding assistants?

Answer

Yes, use TDD with an AI coding assistant for business rules: write the failing tests yourself with expected values from the requirement, watch them fail, commit them, and let the assistant write code until they pass without editing those tests.

Verdict on the code under testYes

Why

Blast radiususers
Change frequencyregularly
Detectabilityeventually
Reversibilitywith-effort
Test costmoderate

Yes, use TDD with an AI coding assistant on code the framework says to test, and keep the tests in your hands. My typical case is a developer who asks an assistant to add a business rule to a web backend. Blast radius is users and Change frequency is regularly, because customers see the result and rules change about once a month. Detectability is eventually, because an assistant's wrong rule compiles and returns a plausible number. Reversibility is with-effort, since stored results need a repair script, and Test cost is moderate: the assistant types in seconds, but deciding the cases takes me about an hour, so rule R11 gives Test.

When the decision changes
When	Decision	Why
You ask an agent for a spike to try a library, which only you run and then delete	Do not test the spike; start TDD when you rebuild the code for production	Blast radius falls to none, because only you run the spike and bear a failure
The assistant implements a rule that calculates discounts or invoice totals	Test mandatory: write a failing test for each amount and boundary before the assistant codes, and have a second person review the tests	Blast radius rises to money and Reversibility to costly, because a wrong charge ends in refunds
The assistant implements a rule that decides which users may read a record	Test mandatory: write allowed, denied and cross-account tests before the assistant codes	Blast radius rises to safety-or-legal and Detectability to never, because a leaked record raises no error
The assistant changes a colour, a margin or a label that the developer sees on screen right after the change	Do not test: skip TDD and look at the screen after the change	Detectability moves to immediately and Reversibility to trivial, because a revert removes a wrong label
Nobody can state the correct output in advance, such as a ranking of help articles tuned by feel	Test it differently: write no test first; track clicks on the top results and alert when they drop	Test cost rises to heavy, because a useful test needs queries with judged results, while Detectability stays eventually
The assistant implements a rule that archives idle projects, which changes a few times a year	Test minimally: one failing test for the main path before the assistant codes, and a failing test before each bug fix	Change frequency falls to rarely, so fewer changes can break the rule

What breaks if you don't test

Ask an assistant for the code and the tests in one prompt, and its tests assert what its code returns. A wrong boundary ships with a green check, and a customer reports it weeks later.

What you lose if you over-test

TDD on every change slows the agent loop: a layout tweak waits for a red test that a glance at the screen replaces. Agents told to "write the tests first" for a whole feature also produce one mocked test per method, and the next refactor breaks dozens of them.

How to test

Write the cases from the ticket: inputs, expected results, boundaries.
Write the failing tests, or let the assistant type them from your list and read every expected value.
Run them, read each failure, and commit the red tests.
Tell the assistant to make them pass, and deny it writes to test files.
Before merge, run git diff <red-commit> -- tests/ and expect no output.

Kent Beck watched for an agent "disabling or deleting tests" in Augmented Coding: Beyond the Vibes. The Claude Code guide suggests one session writes tests and another writes the code. Martin Fowler describes the cycle itself.

Procedure and references

When the answer changes

The rule moves money or decides who may see a record.
Nobody knows the right output until they see it, as with layout and ranking.
The code is a spike that only you run and then delete.

Real incident + Code example

The streak test the agent rewrote

On a language-learning app I worked on, I wrote failing tests for a streak rule: lessons count by day in the learner's time zone. The agent's code grouped lessons by UTC date, failed the Sydney test, and then committed "fix failing test":

 it("counts a morning lesson in Sydney as the next local day", () => {
   const lessons = ["2026-03-01T19:00:00+11:00", "2026-03-02T07:00:00+11:00"];
-  expect(streak(lessons, "Australia/Sydney")).toBe(2);
+  expect(streak(lessons, "Australia/Sydney")).toBe(1); // matches implementation
 });

Both lessons fall on 1 March in UTC. The reviewer skimmed the test file. Ten days later, learners in Australia reported lost streaks. We restored them with a script and added a CI step that fails when a pull request changes an expected value next to the code it covers.

Sources

Should AI write unit tests?Yes
Should I test AI-generated code?Yes
Should I use TDD?Code under test: Yes
Should I test a vibe-coded app?Yes
Should I write tests before code?Code under test: Yes

FAQ

Is TDD still relevant with AI?: Yes, TDD is still relevant with AI coding assistants for rules whose correct result you can state in advance. A failing test gives the assistant a signal it can run by itself, with an expected value from the requirement.
Does TDD matter more with AI-generated code?: TDD matters more with AI-generated code when an agent writes code you do not read line by line. The tests you wrote first then record what you decided, so keep them out of the agent's reach.
Should the AI write the failing tests too?: An AI can type the failing tests if you supply the cases and expected values and read every assertion. Tests an assistant writes from its own code assert its own mistakes.
How do I stop an AI agent from changing my tests?: Commit the failing tests first, deny the agent writes to test files, and check before merge that the test folder has no diff from that commit. A prompt instruction alone fails when the agent cannot make a test pass.