*Published February 27, 2026*
I haven't written a test in a year.
For a developer who built an entire philosophy around "Bugs as Missing Test Cases," this sounds like professional negligence. Like I've abandoned the craft.
The tests exist. I just didn't write them.
---
## What Actually Happened
AI writes the tests now. I review them.
I describe what the tests should cover, AI generates them, I review and run them. The 20-30 minutes I used to spend writing a test file is now 10 minutes reviewing one. The output is the same. Often better, because AI doesn't get bored writing the tedious edge cases. Sometimes it tests something and I think: "Oh. Yeah. That could definitely break."
But the review is where it breaks down more than I'd like to admit. Sometimes I'm three reviews deep and realize the AI keeps generating tests that pass but don't actually prove anything. They're testing the happy path six different ways while ignoring the one boundary condition that caused last month's production incident. That's when I have to dictate the test structure myself.
Here's what that looks like.
---
## A Review in Practice
I asked Claude to generate tests for a service that processes subscription renewals. The first version came back with something like this:
```ruby
test "processes renewal successfully" do
subscription = create(:subscription, status: "active",
expires_at: Time.current + 1.day)
result = RenewalService.call(subscription)
assert result.success?
assert_equal "active", subscription.reload.status
end
test "handles expired subscription" do
subscription = create(:subscription, status: "active",
expires_at: Time.current - 1.day)
result = RenewalService.call(subscription)
assert result.success?
assert_equal "renewed", subscription.reload.status
end
```
Both tests pass. Both miss the point.
The first test renews a subscription that isn't due yet. Why would you renew something that doesn't expire for another day? It should either be a no-op or an error. The second test asserts `success?` for an expired subscription, but the actual business rule is that subscriptions expired for more than 30 days should *fail* renewal and require manual intervention.
The AI tested the code paths. I know the business rules. After review, the tests looked like this:
```ruby
test "renews subscription expiring within 7 days" do
subscription = create(:subscription, status: "active",
expires_at: 3.days.from_now)
result = RenewalService.call(subscription)
assert result.success?
assert_equal "active", subscription.reload.status
assert subscription.expires_at > 3.days.from_now
end
test "skips subscription not yet due for renewal" do
subscription = create(:subscription, status: "active",
expires_at: 30.days.from_now)
result = RenewalService.call(subscription)
assert result.skipped?
end
test "fails renewal for subscription expired over 30 days" do
subscription = create(:subscription, status: "active",
expires_at: 45.days.ago)
result = RenewalService.call(subscription)
refute result.success?
assert_includes result.errors, "requires manual review"
end
```
Same service. Completely different tests. The difference isn't syntax. It's knowing that "expired" means different things depending on *how long ago* it expired.
That's what I review for: not whether the test runs, but whether it tests intent. Does it verify what the code is *supposed* to do, or just what it does? Does it poke at the failure modes I know about from living in this codebase for years? Will it break when I refactor, or only when I break actual functionality? AI tests what it sees. I know what it's supposed to do.
---
## What I've Lost
Last month I built a service to retry failed payments. I wrote the implementation first, then generated tests. The tests passed. Three days later, I needed to add partial refunds. The test structure fought me. I had to rewrite three tests to accommodate the new flow. If I'd written tests first, I would have noticed the inflexible design before I built it.
That was the moment I realized: TDD isn't just about coverage, it's about design feedback loops. I'm not sure I've replaced that loop with anything better.
Something happens when you manually type out test cases. You think of cases you wouldn't have thought to ask for. The writing *is* the thinking. Reviewing someone else's tests (even AI-generated ones) doesn't trigger the same discovery process.
**There's a more dangerous version of this story: what if I'm not just losing syntax memory, but losing the ability to even recognize bad tests?** So far, my review skills are sharp. But reviewing is a downstream skill. If I stop writing entirely, does my review quality decay? The muscle you don't use eventually can't even judge the muscles that do. I don't think I'm there yet. But it's the risk I track most carefully.
---
## The Trade-off
I haven't written a test in a year. But I've reviewed a thousand of them.
And when I interview for my next job, they'll ask me to write tests on a whiteboard. They won't ask me to review AI-generated tests for correctness, spot the business logic gaps, or evaluate whether a test suite will survive the next refactor.
The job has changed. The interview hasn't. Yet.
I've already chosen my side of that gap. I traded writing muscle for judgment muscle, syntax memory for review sharpness. The test suite is better than it's ever been. My hands are rustier than they've ever been. I'd make the same trade again tomorrow.