Does Code Cleanliness Affect AI Coding Agents?

Clean code has always been one of those things developers know they should do but often deprioritize. The argument was always about maintainability, readability, and keeping your future self from rage-quitting at 2am. But now that AI coding agents are writing more and more of our code, a new question emerges: does code cleanliness actually matter to the bots?

A new study from SonarSource (the folks behind SonarQube) set out to answer that question with actual data. The results are not what you might expect.

The Study Design#

The researchers built an evaluation protocol around "minimal pairs" - repositories that share the same architecture, dependencies, and external behavior, but differ dramatically in code quality. They constructed these pairs in two directions:

1. Taking a clean repository and using an agent pipeline to degrade it (introducing static-analysis rule violations and cognitive complexity)
2. Taking a messy repository and having an agent remove those violations

The result was six pairs of repos with 33 tasks total, tested across 660 trials using Claude Code as the agent.

The Surprising Result#

Here's the headline finding: code cleanliness did not change the agent's pass rate. Whether the code was pristine or a tangled mess, the agent was equally likely to complete the task correctly.

But pass rate was only half the story.

Where Clean Code Actually Matters#

While the pass rate stayed flat, the operational costs changed significantly. When working on cleaner code, agents:

• Used 7-8% fewer tokens (directly translating to lower API costs)
• Reduced file revisitations by 34% (fewer round trips to read files they already saw)

The second metric is the more interesting one. A 34% reduction in file revisitations means the agent spent less time wandering around the codebase trying to find its bearings. It read a file once, understood it, and moved on. In messy code, the agent had to keep re-reading the same files because it couldn't hold a coherent picture of the codebase in its context window.

What the HN Discussion Revealed#

The Hacker News discussion on the study surfaced some important caveats. The biggest one: the study didn't check whether the agent broke unrelated tests already in the repository. As first author Priyansh Trivedi acknowledged in the comments, that was "a stupid oversight." The pass rate only measured whether the agent passed hidden tests for the specific task, not whether it introduced regressions elsewhere.

Several developers chimed in with real-world experience. One comment (i_have_an_idea) described it bluntly: "the delta in agent performance is substantial if the codebase is littered with dead code, redundant code, unreachable fallbacks, leaking abstractions and half-baked design patterns vs if the code is well-organized."

Another pattern that emerged: agents mimic their environment. If the codebase has bad patterns, the agent will reproduce them. Multiple commenters noted that agents learn from whatever code they pull into context first - so if the first file an agent reads is legacy spaghetti, expect the output to be legacy spaghetti too.

Practical Takeaways for Your Codebase#

1. Linters catch what prompts cannot#

Some commenters pointed out that deterministic linters solve many cleanliness issues (dead code, code duplication, unreachable code) and have done so for years. Running a linter in CI (or as a pre-commit hook that the agent itself can trigger) is a proven pattern.

One developer shared a trick: tag legacy code explicitly so the agent knows not to use it as a reference pattern:

// LEGACY CODE, per docs/legacy_rules.md section14, section19

2. Refactoring pays for itself in agent costs#

If cleaner code saves 7-8% on token usage, investing an hour in cleanup can pay back in agent API costs over time. For teams that run agents heavily (CI pipeline agents, PR review agents, code-gen pipelines), that math shifts into real money territory.

3. Structure matters more than style#

The study's findings suggest that the biggest gains come from navigability not prettiness. Well-named files in predictable locations, clear separation of concerns, and modular architecture matter more than formatting conventions. The agent's bottleneck is finding the right code, not reading it.

4. "Clean code" is partly subjective - but static analysis is not#

The SonarSource team used static analyzer rule violations as their cleanliness metric. This sidesteps debates about what "clean" means and focuses on measurable, enforceable properties - dead code, complexity thresholds, naming conventions. If you want agent-friendly code, start with the things a static analyzer can catch.

One practical approach from the discussion: ask the agent to run a code review against SOLID standards, then apply the suggestions you agree with. This keeps you in control while leveraging the agent's ability to identify issues at scale.

The Bigger Picture#

The study's core contribution is this: traditional maintainability principles remain relevant in the era of AI-driven development. They just change what they optimize for. Instead of optimizing solely for human comprehension, clean code now also optimizes for agent efficiency - fewer tokens, fewer round trips, lower latency.

Code quality always had a cost argument for it - messes take longer to fix. Now that cost argument extends into your API bill.

View the paper on arXiv | HN discussion

Continue Reading#

• AI Test Generation Tools Compared 2026: Which One Actually Catches Bugs
• Case Study: Building Developers Digest with Claude Code
• Claude Code's Silent 60-Second Timer: A Misfeature Postmortem