Tests still do what they’ve always done: catch regressions, enforce correctness, and give you confidence that the code does what it’s supposed to. That hasn’t changed.
What has changed is the amount of code you’re dealing with.
When AI writes code at volume, you can’t read every line. You shouldn’t have to. Tests become the layer that lets you verify output without parsing the implementation. They’re not just a safety net for future changes. They’re how you know the code is right in the first place.
The shift
On the migration project I’ve mentioned in earlier posts, we were transforming hundreds of pieces of content. AI wrote much of the migration code. I could have read every line, but I didn’t need to.
Instead, I read the tests.
I’d set up the input. The AI would write the transformation and the tests. Then I’d look at the test output: Is this what I’m expecting? For this edge case, is the output correct? If an edge case wasn’t covered, I’d prompt the AI to write a test for it, then check whether the output matched what I had in my head.
The tests became the conversation. Not “did the AI write good code”, but “does this produce the right result?”
That’s a different relationship with tests than most of us are used to. It’s not about coverage. It’s about verification.
Testing the right things
Let me be direct: most coverage targets are theatre.
A team hits 95% coverage and feels good about it. But what did they actually test? File reads. Getter methods. Constructor calls. The easy stuff that never breaks. Meanwhile, the complex business logic that actually matters sits at 60% coverage because it’s hard to test and nobody wants to touch it.
That’s not testing. That’s box-ticking.
When AI is writing code, this gets worse. The AI will happily generate tests that inflate your coverage number without verifying anything meaningful. “This should have tests” becomes a prompt, and the AI obliges with tests that test nothing.
The question isn’t “do we have coverage.” It’s “are we testing the things that would actually break?”
For migrations and one-off scripts, that means: does this input produce this output? Are the edge cases handled? Is the core transformation correct?
For production code, it means: is the domain logic verified? Are the critical paths covered? If something important regressed, would we catch it before it shipped?
99.9% coverage tells you almost nothing. Testing the core domain logic tells you everything. Stop celebrating coverage numbers. Start asking what those tests actually verify.
Tests as a reviewer burden reduction
There’s a useful way to think about code review as a hierarchy. Readability at the base, then Robustness, Security, Elegance. The idea is that readable code is easier to verify for everything else. If you can’t understand the code, you can’t tell if it’s robust or secure.
Tests extend this.
When code is hard to read, or when there’s simply too much of it, tests become the way you verify robustness without having to parse every line. They reduce the burden on the reviewer (which might be you, reviewing AI output) by encoding what “correct” means in something executable.
You’re not guessing. You’re not skimming and hoping. You’re running the tests and seeing whether the output matches your expectations.
That’s a massive reduction in cognitive load, especially when AI is producing more code than you could reasonably review line by line.
One-off scripts are different
For migration scripts and other throwaway code, the dynamic shifts slightly.
You’re not worried about maintainability. The script runs, does its job, and gets deleted. Readability still matters (you need to understand what it’s doing), but you’re not optimising for someone maintaining this code in two years.
What you care about is: does it work? Does it handle the cases I know about? Does the output match what I expect?
Tests answer those questions directly. They’re verification, not insurance. You write them to confirm the code is correct now, not to protect against future regressions.
This is where AI-assisted testing shines. The AI can generate tests quickly. Your job is to read them and ask: Is this the right thing to test? Is this the output I’d expect? What’s missing?
The question to ask
When AI writes code and tests, don’t ask “do we have coverage.”
Ask: “If I read just the tests, would I know whether this code is correct?”
If yes, the tests are doing their job. If not, they’re ceremony.
The goal isn’t to tick a box. It’s to turn “I think this works” into something you can actually verify.
This post explores the Verify and Constrain phases of the Controlled Acceleration Model.