The Developer's Compass: Why TDD is the Only Way to Survive the AI Gold Rush

I’ve spent most of my career arguing that if you aren’t testing, you aren’t actually engineering; you’re just hoping. For years, I’ve stood on stages telling anyone who’d listen that “flakiness isn’t from your test framework” and that “you wouldn’t test a car once it’s fully assembled, so why do that to your app?”

But now, we’ve hit a weird inflection point. We are in the era of Generative AI, where code is being vomited out of LLMs at a velocity we’ve never seen. Everyone is talking about “vibe coding,” the idea that you can just describe a feature, watch the screen fill with syntax, and if it looks okay, you ship it.

I’m here to tell you that this approach is a recipe for disaster. In fact, I’d argue that Test-Driven Development (TDD) is more critical now than it was twenty years ago.

The Illusion of Productivity Link to heading

The trap of AI coding is the “illusion of the finish line.” When you ask an AI agent to build a feature, it gives you 200 lines of code in three seconds. It looks perfect. It uses the latest libraries. It even includes comments. But does it actually do what the business needs? Does it handle the weird edge case where a user submits a null byte in a search string?

If you write the code first (or let the AI do it), you are immediately biased. You’ll write tests that confirm what the code does, not what the code should do. This is the classic “testing the implementation, not the behavior” mistake, and AI makes it ten times easier to fall into.

Setting the Guardrails: AI as the Implementation Detail Link to heading

In my view, the developer’s role has shifted. We aren’t the ones typing out every semicolon anymore. We are the Technical Directors.

The workflow I’m advocating for is simple but disciplined:

  • Define the contract: You understand how the code is going to be used. You know the API. You know the consumer.
  • Write the tests (or have AI generate them from your spec): You put the guardrails in place. These tests are your “Source of Truth.”
  • The “Hands-Off” Implementation: You point the AI agent at the failing tests and say: “Write the implementation to make these pass. Do not change the tests.”

This is the ultimate “trust but verify” model. By keeping the tests immutable, you force the AI to solve the puzzle you actually set, rather than letting it move the goalposts to fit whatever hallucination it’s currently having. If the AI produces code that passes your tests but feels like spaghetti, you can refactor it, again, with the absolute confidence that your original tests will catch any regression.

The Power of the Plan Link to heading

One of the most significant shifts in the last year has been the rise of AI coding agents with planning features. In the old days, TDD was a conversation between you and your compiler. Now, it’s a three-way conversation between you, the AI, and the architecture. Tools like Cursor or Aider now offer a “Plan Mode,” and if you aren’t using it, you’re missing out on the best part of the modern stack.

Planning allows the agent to think before it types. Instead of just throwing code at the wall, the agent generates a step-by-step checklist:

  • “I will first modify the database schema to include the user_id.”
  • “Then I will create the validation logic in the middleware.”
  • “Finally, I will update the controller to return a 403 if the ID is missing.”

When you combine this with TDD, you get something magical. You review the plan to ensure the agent understands the intent. You check that the plan includes running your pre-written tests at every step. This “agentic” approach turns a “black box” code generator into a predictable, logical colleague.

Why Intent Trumps Syntax Link to heading

The reality is that AI is very good at syntax but occasionally mediocre at intent. It doesn’t know that your company’s payment logic has a weird legacy requirement because of a bank in Latvia, unless you write a test for it.

When we hand-coded everything, the “thinking” happened while we struggled with the syntax. Now that the syntax is free, we have to move the “thinking” up the chain. TDD is the mechanism for that thinking. It forces you to define what “done” looks like before the AI starts burning tokens.

The Shift in Expertise Link to heading

I’ve always said that engineering is about managing complexity. AI doesn’t reduce complexity; it just hides it under a layer of generated text. If you don’t have a suite of tests to verify that complexity, you’re building a house on sand.

As developers, our value is no longer in how fast we can type for loops. Our value is in our ability to design systems, understand requirements, and, most importantly, verify correctness. TDD isn’t a chore; it’s the only way to stay in control of the AI. It’s the difference between being a professional engineer and being someone who just hopes the AI got it right.

So, the next time you open a prompt, don’t ask it to “write a login page.” Ask it to “write the tests for a login page that handles expired tokens and SQL injection.” Once those tests are red, then, and only then, let the AI go to work.