There’s always something fascinating about taboos, especially in the way they make you feel: that light sense of rage they produce in you, as if they were touching an open nerve.

Of course, this is also part of why taboos, or “rage bait” as kool-kids call it today, have so much viral potential on social media.

Every time I spot one in the wild, my mind goes back to this amazing Paul Graham essay: What You Can’t Say.

There’s a quote in there that describes this feeling perfectly, but also hints at what is useful about it, and why I think taboos deserve a bit more attention:

“The statements that make people mad are the ones they worry might be believed.”

I think there’s something very powerful in that.

When an idea produces an unusually strong emotional reaction, especially one that feels disproportionate to the idea itself, it’s often worth asking why.

To me, “unit tests are dead” feels exactly like one of those.

What makes this one a taboo is that it feels like we are attacking this ever-present software engineering practice, but in reality most software was produced without what we now think of as modern automated unit testing.

This practice only became mainstream in the late ’90s, with the rise of xUnit-style frameworks popularised by people like Kent Beck and Erich Gamma, and even Google only started adopting it systematically around 2005–2006.

The old argument

Now, the argument against it is also not so novel. Versions of this have been debated manymanymany times before AI, and the argument usually goes something like this:

“Unit tests are QA theatre, because Integration, E2E, and behavioural tests do a better job assuring quality closer to how users actually experience it, therefore unit tests are superseded and should be removed.”

What makes this argument particularly poisonous, with or without AI, is that it is kinda true.

You can test many of those same behaviours through integration or E2E tests, but never as cheaply as unit tests can.

I’d argue that if you push this far enough, you’ve essentially reinvented more expensive and flaky unit tests from first principles.

Also, the real value of unit tests is not merely catching bugs.

Their biggest benefit is that they create a cheap, fast, local feedback loop around our assumptions, and give us confidence that those assumptions still hold as the code changes.

This is also why I think unit testing, and TDD for that matter, has always been a bit misunderstood.

First, we tend to focus way too much on the QA aspect, neglecting the rest. Unit tests are also:

executable specification

documentation

design feedback

infrastructure for change

Second, we think of unit tests mostly in the framing of the London School, while in reality a lot of what people dislike about unit testing is really implementation-tight, overly-mocked testing. Unit testing done well shouldn’t mock much, except at the architectural boundaries.

You can read more about the philosophical differences between the London and Detroit School of unit testing in an amazing article by Martin Fowler: Mocks Aren’t Stubs

Has AI changed this?

Now back to the actual question: has AI fundamentally changed how we write software enough to destroy the premise of unit tests and render them useless?

I don’t believe so.

While it’s evident to anyone that AI has completely changed the economics of producing code, I don’t believe AI has yet changed the part of software development that made unit tests valuable in the first place.

Of course, I’m super excited to see smart people advocate for the opposite direction: [Nate Berkopec@nateberkopecI agree with @thorstenball, I think unit tests are dead in the water.

The ones the models write are terrible, at best just doubling total LOC.

Inverting the testing approach - heavy e2e/black box/golden master, reaching for lower levels only if necessary, works better for me12:44 AM · Sep 23, 2026 · 245K Views91 Replies · 31 Reposts · 924 Likes](https://x.com/nateberkopec/status/2102559606232985729)

I do believe that first-principles thinking, reinventing the wheel, and challenging legacy assumptions is what drives innovation, and we should continue to do so.

I truly hope one day I’ll be able to run find . -name '*.test.ts' | xargs rm on all my projects.

Just not today, maybe.

Thanks for reading! Subscribe for free to receive new posts and support my work.