Anyone who has opened a repository to make one small fix and found the test suite already red knows the feeling. Before your own change can begin, you inherit someone else’s breakage. Two 2026 studies suggest that is exactly what coding agents hand to each other. Code written by AI agents trips up the next change not because it is messy, but because it quietly broke things that used to work, and nobody went back to check.
Two studies, one gap, no mess to blame
In CodeThread, Patel and colleagues compared four frontier coding agents across four benchmarks. Resolve rates dropped “up to 13.1%” when an agent built on agent code instead of human code. The authors report that “many traditional software engineering maintainability metrics do not explain this difference.” The clearer signals were behavioral: changed input validation and error handling, plus downstream code size and task difficulty.
SWE-Maintain , from Ruwei Pan and colleagues, gives that hint a mechanism. It built 100 three-event episodes from 50 real Python repositories and ran five agent systems on two models, for 1,996 paired later events. Building on an agent’s own history cut resolution in all ten combinations: 5.6 points on average, and 14.0 when earlier tests also had to pass.
The decisive number is the starting line. “Two-thirds of Agent-History starting repositories already fail earlier tests.” Only 1.9% of events ended with all accumulated tests passing under agent history, against 23.7% under developer history. Where inherited code did pass earlier tests, the gap shrank to +2.7 points (95% CI -0.5 to +6.1), which the authors cannot tell from zero.
What the broken change looks like
The paper’s parse_crontab episode makes it concrete. The agent’s change fixed only the call sites the task’s tests exercised, not a module-wide alias that later code depended on. On the next task, the paper reports, “8 of 10 tests fail with a NameError in code unrelated to the task.”
Nothing about that code is ugly. It may read well and score fine on complexity. It simply stopped doing something it used to do, and the next agent, working from that foundation, never saw the damage.
The debt agents pass to the next change is not ugly code. It is earlier behavior they changed without anyone checking.
The pattern is not new to the long-horizon tests. SWE-CI ran 20 models through tasks averaging 233 days and 71 consecutive commits of history. It found most models had a zero-regression rate below 0.25, with only two Claude Opus models above 0.5. Regressions were the norm over long maintenance, not the exception.
Where the clean reading gets too tidy
CodeThread and SWE-Maintain do not fully agree. CodeThread ties the drop to properties of the agent code itself, not to test failures, so SWE-Maintain’s “it’s mainly the failing tests” reading may be too tidy. SWE-Maintain also states its own limits. The agent never saw the hidden tests it broke, while a real CI run with visible tests might catch some of the breakage. About 26% of inherited failures are missing names or mismatched signatures, which may penalize valid alternative interfaces rather than real breakage. And developer history may sit in the models’ pretraining data.
Those are fair objections, and they argue for a narrower claim, not a different one. Even CodeThread’s behavioral signals, input validation and error handling, are things a test suite can pin down. A maintainability score cannot.
The leap here is ours. All three studies measure short chains of maintenance steps done entirely by agents and scored against hidden or held-out tests. None studied teams where a human reviews and merges between agent changes, and none measured quality dashboards. Read across to real teams, the finding suggests that AI-era debt is mainly behavioral regression, and that review effort pointed at style, complexity or “slop” is aimed at the wrong target. That is a reading, not a result.
The question a reviewer should ask instead
Humans do not erase the problem. A separate study of 6,774 merged agent pull requests by Takerngsaksiri and colleagues found they draw verified follow-up fixes at 1.62 times the odds of human ones, and that most of those fixes come from the same agent. As we noted earlier , a passing run-it check can miss what only surfaces after merge. And if agent output is already sent back more often , adding reviewers who ask whether it looks clean treats the wrong cause.
For the developer approving an agent’s pull request, the useful question moves from “is this code clean?” to “does everything that passed before still pass?” That means running and reading the whole accumulated suite, not only the tests the agent added for its own task.
SWE-Maintain’s authors say agents should “prioritize preserving earlier behavior across changes.” The same advice holds for whoever signs off. The baton is only as good as the last runner’s hand-off, and a red test is the one line on the checklist nobody can skip.
