AI coding agents have made an old engineering argument newly expensive: messy code costs money.
The latest useful signal comes from “Does Code Cleanliness Affect Coding Agents? A Controlled Minimal-Pair Study,” an arXiv paper by Priyansh Trivedi and Olivier Schmitt of SonarSource. The authors built six pairs of repositories that were meant to behave the same externally but differ internally in cleanliness, then ran 33 tasks ten times on each side with Claude Code using Claude Sonnet 4.6.
The result is not the simplistic version. Cleaner code did not meaningfully change pass rate. But it did change how much work the agent had to do. The paper reports cleaner-side agents using 7 to 8 percent fewer tokens and reducing file revisitations by 34 percent across 660 trials.
GearPulse’s view: this is relevant because AI coding is quickly turning software maintenance into an infrastructure bill. If an agent has to reread the same files, scan giant methods and re-orient around tangled modules, that friction becomes latency, token spend and review noise.
What the study actually tested
The paper’s design is the interesting part. Instead of comparing two models on one benchmark, the researchers tried to hold the agent and task constant while changing the codebase.
They created minimal pairs: same application behavior, same public surface, same dependencies, but different internal structure. Some pairs started clean and were degraded. Others started messy and were cleaned up. The goal was to reduce the chance that the result was really about a specific project rather than code structure.
| Study element | Public detail | Why it matters |
|---|---|---|
| Agent | Claude Code | Keeps the experiment focused on codebase structure, not model choice. |
| Model | Claude Sonnet 4.6 | Results should not be generalized blindly to every model. |
| Repositories | Six minimal pairs | Cleaner and messier versions were compared side by side. |
| Tasks | 33 authored tasks | Hidden tests checked externally visible behavior. |
| Trials | 660 total runs | Enough repetition to expose cost and navigation patterns. |
| Main finding | Similar pass rate, smaller footprint on cleaner code | Clean code helped efficiency more than task completion. |
That last point is easy to miss. The study does not prove clean code makes agents dramatically smarter. It suggests clean code makes them less wasteful.
The practical finding is the loop
Developers who use coding agents will recognize the behavior immediately. The agent opens a file, edits it, backs up, reopens the file, scans nearby modules, searches again, edits another file, then returns to the first file to confirm what it already changed.
Some of that is healthy caution. Some of it is confusion.
The paper’s 34 percent reduction in file revisitations is the most intuitive result because it maps to a real workflow annoyance. Cleaner structure appears to help the agent commit to a path with less backtracking.
| Messy-code pattern | Agent behavior it encourages | Human cost too |
|---|---|---|
| Large methods | More scanning before the focal logic is found | Slower review and higher bug risk. |
| Cryptic names | More search and inference | More comments explaining what names should have said. |
| Tangled modules | More cross-file revisits | Harder blast-radius reasoning. |
| Hidden side effects | More defensive exploration | Less confidence in small changes. |
| Duplicate logic | More uncertainty about the real source of truth | More chance of patching one copy and missing another. |
The audience takeaway is not “run a formatter and your AI bill drops.” Formatting helps, but the study is about structural maintainability: naming, factoring, complexity and module boundaries.
This is not a blank check for cleanup theater
There are caveats.
First, the paper used one agent setup for its main results. Claude Code with Claude Sonnet 4.6 is relevant, but it is not the whole market. Other agents may navigate differently. Future models may be less sensitive to some forms of mess and more sensitive to others.
Second, hidden-test pass rate is not the same as full production quality. A Hacker News discussion of the paper quickly focused on that limitation: two solutions can pass the targeted tests while differing in maintainability, side effects or broader regression risk.
Third, SonarSource has an obvious commercial interest in code quality. That does not invalidate the work, but it should make readers pay attention to methodology rather than treating the conclusion as detached academic folklore.
Fourth, some cleanup can make an agent’s path worse. The paper itself notes task-level variance. If a refactor spreads simple logic across too many helpers without improving findability, an agent may read more, not less.
GearPulse’s opinion: the useful lesson is not “clean everything.” It is “make important behavior easy to find, name and change.”
Why this matters for teams using agents
AI coding tools are often sold as a way around old engineering bottlenecks. The study points in the opposite direction: old bottlenecks still matter, but the accounting line changes.
When a human struggles through a messy codebase, the cost is time, frustration and review risk. When an agent struggles, the cost also includes tokens, latency, rate limits and larger diffs for humans to inspect.
That makes maintainability a platform concern. Teams that plan to use agents heavily should treat code structure like agent infrastructure, not just developer taste.
Here is the practical reading:
| Team choice | Likely agent impact | Better framing |
|---|---|---|
| Keep giant legacy modules because agents can read them | Agents may spend more context budget rediscovering structure | Refactor the hotspots that agents touch often. |
| Use vague names because tests pass | Agents have to infer intent from usage | Names are retrieval aids for both humans and agents. |
| Accept broad drive-by rewrites | Reviews become noisier | Ask agents for narrow edits and preserve surrounding code. |
| Measure only pass/fail | Cost and churn stay invisible | Track tokens, files touched and diff size too. |
| Treat cleanup as low priority | Agent productivity may plateau | Cleanup becomes part of AI enablement. |
This is where the study feels grounded. It does not promise AI will reward every textbook clean-code rule. It says code shape changes agent behavior enough to measure.
The business case is modest but real
A 7 to 8 percent token reduction will not rescue a broken engineering organization. It will not make a bad architecture good. It will not turn agents into senior engineers.
But in a company running thousands of agent tasks, single-digit efficiency changes compound. Shorter agent runs can mean lower bills, faster feedback, fewer rate-limit collisions and smaller review queues. The bigger win may be file revisitation: agents that loop less create less uncertainty for the human who has to approve the patch.
The strongest argument for clean code remains human. People still own production systems, incidents, reviews and product judgment. The new twist is that agents appear to benefit from many of the same affordances: clear names, smaller units, meaningful boundaries and explicit behavior.
Bottom line
The SonarSource study is relevant because it reframes code cleanliness as an AI operations issue. Cleaner code did not make Claude Code pass dramatically more tasks in this experiment, but it made the agent spend less effort getting there.
That is enough to matter. As coding agents become normal, maintainability is no longer only about making life easier for the next developer. It is also about making automated work cheaper, faster and easier to review.
GearPulse’s read: the best agent-ready codebase is not the prettiest one. It is the one where intent is findable, changes are localized, and both humans and agents can stop rereading the same file just to remember what is going on.