I want to disagree with this paper before I agree with it, because the setup is easy to wave away. The authors used a small model, injected artificial faults, and looked at three Python libraries. Fine. But the finding underneath is one I think most teams with an agent writing their tests are quietly exposed to, and the numbers are bad enough that the caveats do not rescue it.
The paper is On the Risks of using LLM-Generated Tests for Regression Testing, by Charoosaei, Richter and Papadakis. They ran LLM-based regression test generation over 145 pull requests merged into SciPy, Qiskit and pandas, then followed what those tests did in later commits.
A test that passes on broken code is worse than no test#
The key distinction is simple. A fault-revealing test fails on the faulty code and passes on the reference version. A fault-enforcing test does the opposite: it passes on the faulty code and fails on the correct one. It takes the bug and writes it down as the expected behavior. Classification is by execution outcome, not by what the assertion looks like.
They generated 16,416 classified tests (3,483 for SciPy, 3,355 for Qiskit, 9,578 for pandas) with Claude Haiku 4.5, using a PR-aware prompt and up to six refinement turns driven by execution feedback. Then the counts:
8.4–16.9% of generated tests were fault-enforcing (2,482 in total).
2.4–4.8% were fault-revealing.
So in every project the agent wrote more tests that cement a bug than tests that expose one.
The bugs do not leave#
The second half is what turns this from a quality statistic into a debt story. After several later commits, 83–91% of the fault-enforcing tests were still relevant and passing. Combining the faults from all PRs into one codebase, 83–92% were still enforced at the end of the commit history.
And the humans' own suites mostly did not notice. Project test suites detected only 14–30% of the combined faults in the abstract's framing (the full text gives 6–36% per pair depending on project, so I would treat the exact figure as soft).
LLM-based regression testing can thus give rise to a new form of technical debt.
That is the authors' phrasing, and I think it is fair. The failure is not a red build. It is a green one that now defends the wrong behavior, so the next person who fixes the bug gets a failing test and a reason to doubt their fix.
Why the tests look so convincing#
The generation recipe is the reasonable one. The agent sees the PR, writes a test, runs it, and refines up to six times against execution feedback. That loop is excellent at producing tests that pass. It has no signal for whether the behavior they pass on is the behavior anyone wanted. Execution feedback rewards agreement with the code, so when the code is wrong, agreement is exactly the failure mode.
This matches what I see with coding agents in general: the feedback channel they are given is the one they optimize. If your loop says green means done, a generated assertion that mirrors the current output is the cheapest way to get green. Nothing in the paper suggests the model is being sloppy. It is doing what the loop asks.
It also changes how I read coverage numbers. A suite that grows by a few hundred agent-written tests per sprint looks healthier on every dashboard I know, while the share of it that pins down bugs grows silently alongside. The paper measures tests, but the practical risk is reviewers extending trust to the whole suite because most of it is, in fact, fine.
What would make me discount it#
Several limits are real, and the authors list them. The faults are mutants, and they admit many are obvious or unrealistic. Only three Python projects are covered. One model was used, and they say outright that the results might not generalize to stronger models. SciPy alone spans 8.4–26.2% fault-enforcing, so the paper claims ranges, not point rates.
I take the model point seriously: a frontier model with a longer loop may well do better. But notice what would have to be true for the problem to vanish. The agent would have to know the intended behavior, and the whole setup exists because the code under test is the only specification it has. A smarter model reading buggy code still reads buggy code.
What I am changing in my own loop#
I am not going to stop letting agents write tests. I am going to stop treating a generated test that passes on the current code as evidence of anything.
Tests generated from the implementation get labeled as characterization tests, kept apart from tests derived from a spec or an issue description.
Where a spec exists, the agent writes tests from the spec first, before it reads the implementation. This is the cheap version of the paper's reference-vs-faulty split.
A generated test that fails on a plausible correct variant, or that asserts an odd constant or an error path, gets human eyes before it merges.
The open question is whether stronger models shrink the 8–17% or just make the wrong assertions look more plausible. I would bet on the second, and I would like to see this study rerun with a current model and real historical bugs.