A paper from SonarSource, Does Code Cleanliness Affect Coding Agents? A Controlled Minimal-Pair Study, asks a question many AI builders already face in their daily work: given the same logic, does cleaner or messier code change how an agent performs?
The question is interesting not because it hit the Hacker News front page on July 5. The HN discussion only shows that this struck a nerve with many engineers. What really matters is that it turns a gut-feel daily decision into a measurable question: should we refactor old code, split functions, add comments, and delete dead code for the agent?
The answer is narrower—and more useful—than many expected. Clean code did not meaningfully improve single-task pass rates. More precisely, the messy side had a slightly higher pass rate, but the gap was less than 1 percentage point. The difference is too small to interpret as “messy code works better for agents.” What the paper actually measured was a shift in cost: input tokens dropped 7.1%, output tokens dropped 8.5%, reasoning characters dropped 11.1%, and the number of times the agent reopened already-edited files fell roughly 34%. In multi-module tasks, the effect was even stronger: input tokens dropped 10.7%, and file revisits dropped 50.8%.
This paper did not prove that cleaner code leads to higher agent success rates. It proved something narrower: in current agent workflows, code cleanliness first changes the cost of finding your way around and confirming your changes. That cost translates into tokens, latency, repeated file reads, review burden, and long-term code erosion.
The authors, Priyansh Trivedi and Olivier Schmitt, designed six minimal pairs. The two sides of each pair shared the same architecture, dependencies, tests, and external behavior, and differed only in implementation cleanliness. The authors used metrics like SonarQube rule violations and cognitive complexity as cleanliness proxies. Each repository in a pair ran 33 tasks, repeated 10 times per side, for a total of 660 trials. The agent was Claude Code + Claude Sonnet 4.6. Tasks were authored by the researchers, not extracted from real open-source project issues.
File revisitation is a useful metric in the paper. It counts how often the agent, during a single task, repeatedly opens and reads the same file it has already edited. You can think of it as the agent flipping back and forth in the same place, unsure whether it got the change right.
Here’s the most counterintuitive finding. If clean code doesn’t improve pass rates, where is the value? The answer lies in the agent’s interaction bandwidth and the review pipeline.
You cannot simply dismiss the slightly higher pass rate on the messy side. At a minimum, it reminds us that cleanliness is not a monotonic variable. Some cleanup efforts split logic that was previously colocated across more helpers, more files, and more abstraction layers. That may be better for long-term human maintenance; it is not necessarily easier for an agent that only needs to complete the current short task. The gap in the paper is too small to claim messy code is better, but it is enough to refute the simplistic judgment: that more clean-code rule compliance automatically means easier agent success.
The drop in input tokens means the agent can locate the right place to edit using a smaller context window. In multi-module scenarios, this difference is especially large. On the clean side, function, file, and module boundaries are clearer, so the agent doesn’t have to search through large amounts of irrelevant code. The reduction in output tokens and reasoning characters suggests the agent produces more compact patches on the clean side, rather than covering uncertainty with verbose diffs.
The 34% drop in file revisitation is another signal. When an agent repeatedly rereads the same file, it usually means it needs to reconfirm context, check for side effects, and cross-reference adjacent code. On the clean side, this back-and-forth re-confirmation decreased noticeably. For code review, every agent reread can correspond to a context drift.
The HN community’s skepticism focused on three areas. The core was not about dismissing the research but about defining what it can and cannot answer.
The first question is whether AI-synthesized clean/messy pairs represent real-world code. The paper used automated tools to create cleanliness differences. Real-world messy code often comes from business degradation, multi-person maintenance, framework migrations, and historical accidents. It is not something a single-dimensional rule-violation metric can fully capture.
The second question is that the authors did not run all unrelated tests from the original repositories after each task to check for regressions. The authors acknowledged this in the HN discussion as an oversight and added: “But it could have gone either way. We don’t know.” This means we do not know whether the clean and messy sides suffered different levels of collateral damage in non-target modules.
The third question is about conflicts of interest. SonarSource’s main product is a static analysis tool. This relationship does not mean the research is wrong, but it does shape the problem definition. Measuring cleanliness by the number of rule violations inherently carries a static-analysis-tool perspective.
The community also contributed engineering experience independent of the paper. Multiple developers noted that agents cannot fit an entire codebase into context; they still have to search, read files, and trace call chains like humans do. Under this constraint, naming conventions, file locations, module boundaries, and locality directly affect search cost. Others pointed out that legacy code and mixed-pattern codebases pollute agent behavior. Agents tend to mimic old patterns they first see in context, rather than the patterns the project currently expects.
When you look at the paper’s conclusions alongside engineering practice, a few judgments come into focus.
Don’t chase superficial clean code for the agent. Polishing code to look clean while keeping the same logic has limited impact on pass rates. But if the changes reduce indirection, dead code, and stale patterns, the agent’s navigation cost does decrease. What matters is not looking clean—it’s reducing ambiguity.
Executable verification is more effective than talking at the agent. In the OpenAI Codex best practices, the official recommendation is that AGENTS.md should include the repository layout, build/test/lint commands, engineering conventions, and a definition of done. The AGENTS.md ecosystem also emphasizes that agents need explicit build steps, tests, and conventions. The Claude Code best practices advise writing tests, running lint and type checks, and reviewing scope. What these recommendations share is giving the agent a machine-verifiable feedback loop, not a block of natural language description.
The Aider lint/test documentation designs automated linting and testing as a feedback loop for the agent. The agent generates code, checks run immediately, and failures trigger corrections. Martin Fowler’s observation in sensors for coding agents is equally practical: agents tend to copy-paste, they don’t automatically refactor, and you need deterministic sensors to catch these issues.
The highest-ROI practices are not mysterious: maintain a single source of truth—don’t maintain different versions of the same logic in multiple places; clean up dead code and deprecated old patterns, because the agent treats them as live code; explicitly mark module boundaries and coding conventions, so that file-level and function-level context windows naturally carry the right signals.
Back to the paper. Clean code’s impact on agents is not a pass-rate miracle—it’s context cost compression. Token consumption, file revisitation, and patch compactness directly affect the development experience, but engineering teams tend to overlook these metrics because they don’t show up in the intuitive feeling of a task succeeding or failing.
The question shouldn’t be whether to write clean code for AI. A better question is: which engineering disciplines help both humans and agents eliminate ambiguity, and which ones only make code look clean?
In this framing, writing clean code for agents is neither a new religion nor a phantom requirement. It is closer to rewriting the engineering discipline we once gave to human maintainers as context infrastructure that machines can also consume.