The Hidden Tax of Messy Code: More Tokens, More Backtracking, Same Result

Messy code won’t stop a coding agent from finishing the job, but it makes the agent work harder to get there: about 8% more tokens burned and 34% more re-reading of files it already edited. Cleanliness doesn’t move the pass rate; it moves everything around it. That is the finding from a controlled study by Priyansh Trivedi and Olivier Schmitt at SonarSource.

The setup is unusually clean for this kind of question. Instead of correlating quality against messy real-world repos, they built “minimal pairs”: two versions of the same repository, behaviorally identical and passing the same tests, differing only in code quality. Then they ran the same tasks on both sides and measured the gap.

• Pass rate: essentially unchanged, -0.9 percentage points on cleaner code
• Input tokens: -7.1% on cleaner code; output tokens -8.5%
• File revisitation: agents re-opened already-edited files 33.8% less often
• Reasoning overhead: -11.1% fewer reasoning characters
• 660 trials: 33 tasks x 2 code variants x 10 repeats, Claude Sonnet 4.6 in Claude Code

The Minimal-Pair Trick

A minimal pair is two repos that are functionally identical, same architecture, dependencies, test suites, and coverage, where the only systematic difference is code-quality violations. That isolates cleanliness from everything else that normally confounds it.

The pairs were built with two opposing pipelines. Slopify degrades clean code the way real codebases rot: inlining helpers into their callers, duplicating logic across paths, adding dead code, merging modules into single files, all while keeping tests green. Vibeclean goes the other way, mechanically resolving SonarQube-flagged issues module by module: deduplicating literals, removing commented-out code, extracting 2,800-line classes into named helpers. Six pairs total, split across Java and Python, three from public open-source projects and three from private SonarSource code (to rule out model memorization). Cleanliness itself is measured as SonarQube issue density and cognitive-complexity density, not a vibe.

The 33 tasks were written to describe only observable inputs and outputs, never naming internal files or functions, so the agent has to explore and locate the work itself, exactly where code structure should help or hurt.

Same Success, Different Effort

The interpretation splits completion from efficiency. Modern models are capable enough to eventually solve a task through any amount of poorly-structured code, so the pass rate holds. But messy code raises the cognitive load of getting there. The standout signal is file revisitation: agents re-read files they’d already touched 34% more on messier code, which reads as uncertainty about their own prior edits rather than useful exploration. Clean code gives “grep-targetable structure,” clearly named functions and modules that tell the agent exactly where a change belongs.

The gains aren’t uniform. Multi-module tasks, where boundaries matter most, saw the biggest wins (-10.7% input tokens, -50.8% revisitations). Cognitive-hotspot tasks, work jammed into one dense method, were roughly token-neutral but shifted behavior: more files read, fewer lines edited per file, consistent with extraction spreading the same logic over more surface.

Caveats

This is an author-built benchmark, not real GitHub issues, so any bias in task selection propagates straight into the results, the authors say so plainly. Everything runs on one model (Sonnet 4.6 in Claude Code); a Haiku 4.5 sweep was too noisy to use, and GPT and Gemini weren’t tested, so the mechanism transferring across models is conjecture. The variance is also real: the priciest run of a task can cost about 2.5x the cheapest, and only 16 of 27 real tasks favored cleaner code on input tokens. The dataset-level numbers hold precisely because they pool hundreds of trials; a single 10% per-task delta is likely just noise.

A few things go unmeasured. Tokens are a proxy for cost, but dollars depend on provider, cache state, and queueing, none of which are code properties. Pass rate is only against the researchers’ hidden tests; they didn’t check whether the agent broke existing repo tests. And they didn’t run SonarQube on the agent’s output, so whether clean code begets clean agent output is open. Most important for the economics: the per-task savings are modest, and the unanswered question is whether they compound across a year of agent work, or whether the codebase drifts messier and erases them.

The takeaway is reassuring for anyone who already invests in maintainability: the same properties that make code easier for humans, good names, small functions, clear boundaries, make it cheaper for agents too, with no tradeoff in whether the task gets done. Clean code isn’t a correctness lever for coding agents. It’s a cost lever.