For AI-generated code, targeting volume of tests first makes code changes safer, even if test quality not great.

For AI-generated code, targeting volume of tests first makes code changes safer, even if test quality not great.

There has always been debate about the “right” way to test software, unit versus end-to-end, TDD versus tests afterwards, 100% coverage versus sensible coverage. There is no universally correct answer because testing has always been a trade-off between confidence, time, maintenance and value.

AI changes that trade-off.

Historically, tests were expensive. Someone had to design them, write them, maintain them and deal with an ever-growing suite. That pushed us towards asking whether every test justified its existence.

With AI, I ask a different question.

"Will this test tell me if something changed?"

That changes the purpose of testing.

Take a big legacy monolith that nobody really understands and nobody wants to touch. I’d rather generate a huge number of tests around its current behaviour, then start refactoring.

The existing behavior may not be correct but what I need to know is if I change it. If 200 tests fail after a refactor, that is useful information.

AI can help analyse those failures, but a human still has to decide: was the change intentional? Was the old behaviour wrong? Is the new behaviour wrong? Should the test change, or should the code change?

That human-in-the-loop matters. I’m not suggesting generating 10,000 tests and letting an agent blindly fix every red one until everything goes green. That is just a system approving its own work. What I want is a large change-detection network around changes.

And initially, I care far more about breadth than perfection. Hit every endpoint. Exercise every page. Cover the important business paths.

Give me shallow coverage across the whole system before beautiful coverage on a small %. Because that first layer is now cheap to create.

Then harden it where reality tells you it matters.

Find a bug? Improve the tests in that area. Get a production issue? Add stronger coverage. Performance matters? Gate it. A workflow becomes critical? Go deeper.

The suite evolves with your priorities of the system.

I also care less about the maintainability of tests. If an AI-generated suite becomes messy, repetitive or badly structured, AI can help refactor or regenerate that too.

If I generate 100 tests and only 10 are useful and ever catch something genuinely valuable, that a good ROI if generating 100 was nearly 0 cost, those 10 useful tripwires were still worth having.

Scale that across thousands of behaviours and you get something powerful: not proof that the software is correct, but evidence that the things that worked yesterday still work today.

That matters even more when AI is writing the code, because agents change more, explore more and can create ripple effects far away from the feature you asked for.

With AI-generated code, test volume is more valuable than test quality. What you need first is visibility and understand the real coverage you have.