Is it still relevant to use AI for writing unit tests? Absolutely. But the question that immediately follows is more interesting: is it still relevant to enforce strict coverage thresholds now that AI generates tests effortlessly? I think it is, although I wouldn't push it as hard as we did a few years ago.

The problem with coverage thresholds in an AI workflow

When you hand an agentic AI a hard coverage requirement, something predictable happens: the AI starts testing every single line of code. Not because it's meaningful, but because it's the fastest route to the requested percentage. The result is a pile of unit tests, a good portion of which adds little value. Think of tests on trivial getters, tests that lock in implementation details instead of behaviour, and tests that break on every refactor.

That pile of tests has real costs:

  • Pipeline time: every test runs on every commit, every PR and every deploy. A pipeline that grows from five to fifteen minutes slows down the entire team.
  • Local feedback: developers run the suite less often when it's slow. That undermines the very purpose of the tests.
  • Ecological impact: CI minutes are compute. Thousands of redundant test runs per week aren't free, and neither is their climate footprint.
  • Maintenance: every test you add is a test someone has to understand and keep up to date.

From coverage target to test strategy

The alternative isn't testing less, but testing more deliberately. Before I start on a feature or bugfix, I map out what I want to test and at which level. Not every function lends itself to a unit test, and that's fine:

  • Unit tests for pure logic: calculations, validations, transformations. Fast, stable and cheap.
  • Screenshot or golden tests for visual components. In Flutter, golden tests are an excellent example: you capture the intended rendering, and any unwanted visual change is caught immediately. A unit test on a UI component often says very little, whereas a golden test shows what the user actually sees.
  • Integration tests where components and services come together: API routes, database interactions and third-party integrations.
  • E2E tests for the critical user flows: logging in, checking out, submitting forms. Few in number, high in value.
  • Synthetic tests in production, periodically walking through the most important flows and raising alarms before users do.

With a strategy like this, you don't need to pin your coverage at 100%. A deliberate decision not to unit test a piece of code because it's already covered by an integration test or golden test, is more valuable than a test that only exists to hit a percentage.

AI lowers the barrier for the entire strategy

There used to be a technical barrier to setting up integration tests or screenshot tests: configuring tooling, building test infrastructure, creating fixtures. For many teams that was the reason to stick with unit tests only. Not because it was the best choice, but because it had the lowest barrier to entry.

That barrier has largely disappeared. With a few targeted prompts, an agentic AI sets up a Playwright configuration, wires up screenshot comparisons or builds a synthetic monitoring check. What used to take days of research is now operational in an afternoon. The trade-off is no longer about what you can technically handle, but about what you want to test and why. And that is exactly the question a team should be asking.

How I approach this in practice

For every feature or bugfix, I start with a short testing assessment: which behaviour needs to stay guaranteed, at which level can I test it most cheaply, and which existing tests already cover it? I document that assessment in the PR description. The AI then helps with the implementation, but the strategy remains human work. AI is excellent at writing tests. Deciding which tests should exist requires an understanding of the product, the risks and the users.

Conclusion

Using AI to write tests is more relevant than ever, precisely because it enables you to look beyond unit tests alone. Coverage thresholds still serve a purpose as a signal, but as a hard target they backfire in an AI workflow. Invest that energy in an explicit test strategy per change instead. Your pipeline stays fast, your tests stay meaningful and your team knows exactly why every test exists.