I’ve been a TDD practitioner for years. Red, green, refactor — the rhythm is almost meditative once you internalize it. So when AI coding tools started writing entire test suites in seconds, I had a genuine identity crisis. If the machine can write both the tests and the code, what’s the point of TDD? Is the discipline dead?

I spent a month finding out. Here’s what I learned.

The Traditional TDD Loop (and Why It Works)

For the uninitiated, TDD follows a tight cycle:

1. Red — Write a failing test that describes the behavior you want.
2. Green — Write the minimum code to make that test pass.
3. Refactor — Clean up the code while keeping the tests green.

The magic isn’t really in the tests themselves. It’s in the thinking. Writing a test first forces you to articulate what you actually want before you start building. It’s a design tool disguised as a testing practice. The test is a specification, a contract you write with yourself.

That distinction matters a lot when AI enters the picture.

How AI Changes the Loop

With tools like Claude Code and the latest generation of AI coding assistants, the TDD loop can collapse into something like this:

1. You describe a feature in natural language.
2. AI writes the tests.
3. AI writes the code to pass those tests.
4. You review both.

On paper, this is faster. In practice, it introduces a subtle but serious problem: the AI is testing what it thinks the code should do, not what you want the code to do.

When I let an AI generate both tests and implementation for a payment processing module, it produced clean code with 95% coverage. Looked great. But it had silently made an assumption about how partial refunds should work that was the exact opposite of our business logic. The tests passed because the tests were written to match the (wrong) implementation. The safety net had a hole in it, and the hole was invisible.

This is the core tension. TDD works because the human intent comes first. When AI writes both sides, intent gets lost.

What Actually Works Well

That said, AI is genuinely excellent at certain parts of the TDD workflow. After a month of experimenting, here’s where it shines:

Test scaffolding. Writing boilerplate test setup — mocks, fixtures, describe blocks, beforeEach hooks — is tedious. AI handles this instantly. I’d estimate it saves me 30-40% of the mechanical work in a typical test file.

Edge cases. This surprised me. When I write a test for a function, I tend to think about the happy path and maybe one or two failure modes. AI consistently suggests edge cases I wouldn’t have considered: empty strings, negative numbers, Unicode characters, concurrent access patterns. It’s like having a QA engineer looking over your shoulder. If you’re curious about the mechanics, I wrote about AI test generation in more detail.

Test readability. AI-generated tests tend to be well-structured and consistently named. My hand-written tests are… less consistent, especially at 4pm on a Friday.

Regression tests for existing code. When you’re adding tests to a legacy codebase (not TDD, but adjacent), AI is phenomenal. Point it at a function, and it’ll generate a comprehensive test suite in seconds. I’ve been using Ollama for local test generation on proprietary code where I don’t want anything leaving my machine, and it works surprisingly well.

What Doesn’t Work

AI testing AI-written code is circular reasoning. I keep coming back to this. If the same model writes the test and the implementation, the test validates the model’s assumptions, not your requirements. You end up with high coverage and false confidence.

AI doesn’t understand your domain. It can write a technically correct test for a calculateDiscount() function, but it doesn’t know that your business gives 15% off for orders over $200 except during Q4 when it’s 20% unless the customer is wholesale. Domain logic lives in your head (or your product spec), not in the training data.

Flaky test generation. AI-generated tests sometimes rely on implementation details rather than behavior. They test how something works instead of what it does. This makes them brittle — a refactor breaks the tests even though the behavior hasn’t changed. Classic testing anti-pattern, and AI falls into it regularly.

Over-testing. AI will happily generate 40 tests for a simple utility function. More tests isn’t always better. Every test is maintenance burden. You need tests that earn their keep.

The Hybrid Approach (What I Actually Do Now)

After a month of experimentation, I settled on a workflow that keeps the best parts of TDD and the best parts of AI assistance. I call it “human intent, machine labor.”

Here’s how it works:

Step 1: I write the test intent. Not the full test — just a comment or a skeleton describing what I want to verify. Something like:

// TEST: calculateShipping returns free shipping for orders over $75
// TEST: calculateShipping throws for negative amounts
// TEST: calculateShipping applies express multiplier of 2.5x
// TEST: calculateShipping rounds to nearest cent

Step 2: AI generates the test code. I feed those intents to the AI and let it flesh out the actual test implementations. It handles the assertions, the setup, the mocking. I review to make sure it captured my intent correctly.

Step 3: I run the tests. They fail. This is the red phase, and it’s critical. If the tests pass before I’ve written the implementation, something is wrong.

Step 4: I write the implementation. Not the AI — me. This is where the design thinking happens. The tests constrain my solution, and I make the deliberate choices about architecture and trade-offs.

Step 5: AI helps with refactoring. Once the tests are green, I’ll sometimes ask AI to suggest refactors. But the tests are my safety net, and I wrote the intent behind them, so I trust them.

The key insight: the human controls the “what” and the AI handles the “how.” I decide what the code should do. AI helps me express that as tests. I decide how to implement it. AI helps me clean it up.

A Practical Workflow Example

Here’s a real session from last week. I was building a rate limiter middleware:

1. I wrote five test descriptions in plain English covering the core behaviors (allow under limit, block over limit, reset after window, per-key tracking, custom error response).
2. AI generated the full test file — about 80 lines of well-structured Jest tests. I tweaked one assertion where it assumed a 429 status code but our API uses a custom error envelope.
3. Tests failed. Good.
4. I implemented the rate limiter. Took about 20 minutes. The tests caught two bugs during development — an off-by-one in the window calculation and a missing await.
5. AI suggested extracting the storage layer into an interface for testability. Good call. Tests stayed green.

Total time: about 45 minutes for a solid, tested rate limiter. Without AI, the test writing alone would have taken 15-20 minutes. Without TDD, I’d have shipped those two bugs.

The Verdict

TDD with AI isn’t dead — it’s different. The discipline of thinking about behavior before implementation is more important than ever, precisely because AI makes it so easy to skip that step. If you let AI drive the whole loop, you get fast code with shallow tests. If you keep human intent in the driver’s seat and let AI handle the mechanical parts, you get the speed benefits without sacrificing the design benefits.

My honest take: pure TDD purists will hate this. The cycle isn’t as clean. But software development has never been about purity — it’s about shipping reliable code. And this hybrid approach ships reliable code faster than either TDD or AI alone.

Try it for a week. Write your test intents by hand. Let AI generate the test code. Write the implementation yourself. See if it clicks.

I think it will.