TDD Has Been Declared Dead Every Year Since 2005. It Keeps Coming Back.
The discipline of writing the test first keeps reasserting itself because it enforces something most developers skip: defining the contract before writing the code.
TDD has been declared dead approximately once a year since 2005.
The arguments cycle predictably. It slows you down. The tests become brittle. You're testing implementation rather than behavior. AI writes code faster than TDD allows. The tests are wrong anyway.
Every few years someone publishes a "TDD is dead" post that gets widely shared. A counter-wave follows. The debate resolves nothing. TDD persists.
The reason it persists isn't evangelism. It's that the discipline it enforces is genuinely hard to replicate by any other means.
What "Write the Test First" Actually Enforces
The surface argument for TDD is about confidence: you write a test before code so you know when the code is correct. That argument is fine. It's not the interesting one.
The interesting argument is about specification.
When you write a test first, you have to answer a question that most developers defer indefinitely: what should this function do? Not vaguely — specifically. What input does it take? What does it return? What are the edge cases? What happens when it receives bad input?
Writing the test forces you to have an opinion about these questions before writing a single line of implementation. You can't hedge. You can't figure it out as you go. You have to know what "correct" means before you can write code that achieves it.
Most developers skip this step. They write the function, run it, see if it seems to work, ship it. The contract is implicit and stays implicit. When the function breaks later — or when a new engineer has to modify it — the implicit contract has to be reconstructed from the code itself, which is a much harder problem.
TDD externalizes the contract as a test before the ambiguity can solidify.
Why Matt Pocock Packaged It as a Skill
The TDD skill from mattpocock/skills has 27.6K installs. Matt Pocock is the author of Total TypeScript — his skill set is TypeScript-first, precision-focused, aimed at engineers who care about exactness in their type contracts as much as their function contracts.
Packaging TDD as a skill is a bet that the enforcement mechanism matters as much as the knowledge.
Most developers who know about TDD don't practice it consistently. The knowledge is widely available. The free courses, the books, the blog posts — they've been around for twenty years. If knowledge were sufficient, everyone who wanted to practice TDD would be doing it.
The gap is enforcement. TDD discipline requires a consistent practice that kicks in before the urge to write code — and that urge is strong. The reflex is to start implementing. The test-first discipline runs against it.
A skill is one mechanism that could change when the behavior activates. Not willpower applied each time, but a structured workflow that puts test-writing before implementation writing in the sequence of steps. The enforcement is in the process, not the developer's daily resolve.
The AI-Coding Wrinkle
There's a version of "TDD is dead" that's specific to the current moment: AI writes code faster than you can write tests, so TDD creates friction in the loop.
I don't think this argument is right, but it's worth engaging with.
When AI writes code, the contract problem doesn't go away — it gets more important. AI-generated code can appear to work while encoding incorrect assumptions about what the function should do. The test is how you specify your intent to the AI, and the test is how you verify that the generated code actually implements it.
If anything, TDD is more useful in an AI coding workflow because it separates "what should this do" (which you own) from "how should this be implemented" (which the AI can own). Giving the AI a test first is a more precise specification than a natural language description.
27.6K installs for a TDD skill suggests there are developers who've come to the same conclusion — that the discipline doesn't disappear in an AI workflow, it just changes form.
The Constraint That Makes It Work
I've tried to practice TDD by intention alone. It doesn't work consistently. The implementation reflex is too strong.
What works is what the skill enforces: a structural constraint that makes it harder to write implementation code before test code than it is to write the test first. Not harder in a punitive way — harder in the way a checklist makes it harder to skip a step.
TDD keeps coming back because the underlying discipline is genuinely valuable and genuinely hard to maintain without structure. Matt Pocock codifying it as a skill is a bet that the next enforcement mechanism isn't willpower — it's workflow.
I think that bet is right.
Part of the Matt Pocock TypeScript Skills — precision TypeScript practices from the author of Total TypeScript.