Most of what I read about code quality and agents is vibes. "Clean code helps the model" is easy to say and hard to measure. So I paid attention when a pre-registered study of 465 agent-authored pull requests put a number on it: every extra point of CodeHealth, a code-quality score, cut the token cost of an agentic review by roughly 3.5% to 6.1%.
That is a small number. I think the way the authors got to it matters more than the number.
A cost study that committed to its hypothesis before the data#
Lo Gullstrand Heander and Christofer Rydenfält took 465 merged, agent-authored PRs from 246 repositories in the curated tier of the AIDev dataset (TypeScript, Python, Go, C#, JavaScript). They sampled across a 3×3 grid of baseline code health and PR footprint, then ran a frozen review pipeline over each one: four review agents (Security, Performance, Design, Logic) followed by one batch fix agent, all at temperature 0.
They ran it with three models separately: deepseek-v4-flash, qwen3-6 on local vLLM, and sonnet-5. The outcome was total tokens, modelled against CodeHealth with PR footprint and language as controls and a random intercept per repository.
The registered criterion was direction consistency across all three models, and it held:
deepseek-v4-flash: −0.062 (95% CI −0.090 to −0.035)
qwen3-6: −0.049 (CI −0.085 to −0.014)
sonnet-5: −0.036 (CI −0.070 to −0.001, p = .041)
Those are log-token coefficients per CodeHealth point. The healthy and unhealthy tiers in the sample sat at a median CodeHealth of 9.7 and 2.8, so the gap between them is several points wide and the savings add up across it.
Not a PR-size effect, then a file-size effect#
The obvious objection is that bad code just lives in bigger changes. The authors checked: CodeHealth was essentially unrelated to PR footprint, at most +0.014 in log footprint per point. So the cost is not coming from how much the agent authored.
The exploratory analysis is where it gets interesting. The association sits in the review stage, not the fix stage. Agents iterated more on unhealthy code (ρ = −.16) without writing more review comments (ρ = −.03). They worked harder and said no more.
Adjusting for the size of the scored files absorbed the association
The authors read this as file size mediating the effect, and they flag it as exploratory. I would take it seriously anyway. If the cost of poor code health is mostly the cost of reading big files, then the cheap lever is not a refactoring crusade, it is smaller files.
Smells moved the fix stage, not just review#
Two of the three registered code smells predicted cost in the fix stage. The paper's summary is blunt: the effect is modest per point and not carried by PR size. I read the two results together as a consistent picture. Review agents loop more on code that is hard to hold in context, and fix agents pay for specific smells on top of that.
That fits what I see when I run sub-agents over a repository. The expensive sessions are rarely the ones with the biggest diff. They are the ones where the agent keeps re-opening the same tangled module, trying to convince itself it understands it. A cost model built on diff size would miss exactly those.
The paper does not test any of this with real Claude Code sub-agent setups, so treat that as my interpretation. What it does give me is a reason to log tokens per file touched, not just per PR, the next time I audit where review spend goes.
What I would do with a 4% effect#
Nothing dramatic, honestly. A few percent per point does not justify rewriting a codebase to save review tokens. Where it does matter is as a tiebreaker in places you already want to clean up: the god-file that every agent session has to read in full is now also a line item.
It also gives me a way to budget. If I run review agents over a repository with a lot of low-health hot spots, I expect cost to scale with those files, not with the size of the diff. That is the opposite of how I had been estimating.
Where the evidence runs out#
The design is observational, so this is association, not causation. Power was limited: the minimum detectable effect was about 4.7% to 6.7% per point, roughly the size of the estimates, which is why the authors framed the test as direction consistency across three models rather than a single significance test. One model's interval nearly touches zero.
Token totals are also not comparable between models because of prefix caching differences, so you cannot read this as one model being cheaper. And nobody assessed whether the reviews or fixes were any good: the batch fix step left median CodeHealth unchanged, and quality was not graded at all. The sample is agent-authored PRs in relatively popular open-source projects, which is not your private monorepo.
Registration also came after some review-stage sessions had already run, which the authors disclose themselves. I appreciate that more than a clean story.
My bet#
Reading this next to the cost studies from the last weeks, I keep coming back to the same shape: agent spend follows structure, not volume. The finding I expect to hold up is the mediation one: review cost tracks the size of what the agent has to read. If that replicates, file size becomes a first-class agent-friendliness metric next to test coverage, and I would start tracking it in the repos where I run review agents. What I do not know yet is whether healthy code also makes the reviews better, and that is the study I want next.