Code Cleanliness Changes Coding Agent Footprints

Does code cleanliness affect coding agents? A controlled minimal-pair study is a May 2026 arXiv research paper by the researchers listed on arXiv that tests whether cleaner code helps coding agents succeed. It asks a very practical question: when an agent edits a repo, does tidy structure change the result or only the cost of getting there? The headline answer is subtle: in 660 Claude Code trials, cleanliness did not change pass rate, but it did reduce token use by about 7–8% and file revisitations by 34%. For Cursor users, the lesson is not that clean code magically raises pass rates; it is that clean boundaries make shared agent workflows for code review risk reduction easier to inspect.

A minimal-pair study is an experiment that compares two examples designed to differ in one main way, so the effect of that difference is easier to see. Here, that difference is code cleanliness. It is a useful result for ai coding training for teams because it moves the argument away from taste and toward agent behavior you can measure.

Read the result as a footprint study

The paper’s most interesting finding is not “clean code makes agents smarter.” It is closer to “clean code makes agents wander less.”

That matters in Cursor, Anysphere's AI code editor, because a good agent run is not just the final diff. It is also the path the agent took: which files it opened, which assumptions it carried forward, and how much review surface it created.

Claude Code, Anthropic's coding agent, was the agent in the study. Across the reported 660 trials, clean and messy versions landed similar pass rates, but cleaner code used fewer tokens and caused far fewer file revisits.

The trap is reading “no pass-rate change” as “cleanliness no longer matters.” Pass rate is a narrow metric. A diff that passes tests after bouncing through ten files can still be harder to review than a diff that passes tests after touching the obvious two.

A real example: imagine a payment service where calculateInvoiceTotal() is split cleanly from applyDiscountPolicy(). An agent asked to add a regional discount can usually stay near the policy function. If discounts, taxes, and persistence are tangled inside one controller method, the same agent may still pass tests, but it will likely spend more context figuring out where the behavior actually lives.

Be honest about what “clean” means

The study is worth reading, but the strongest objection is fair: some minimal pairs were reportedly produced with agent pipelines that cleaned messy repositories. That makes representativeness the pressure point.

Agent-cleaned code may not look like the clean code a careful maintainer would write over months. It can remove obvious clutter while leaving architectural choices that still feel strange to humans.

So treat the paper as evidence about controlled cleanliness, not a universal law about every legacy repo. The result is still useful. It says agents respond to structure even when task success stays flat.

The trap is turning this into a moral scorecard. There are good reasons to take debt while prototyping. The difference in an agentic coding workflow is that cheap generation can hide the review cost until later, when the repo has many small wrappers, duplicate branches, and “temporary” fallbacks that nobody wants to delete.

This is the same basic pattern we like in smaller developer-tool experiments: make the object easier to see, then judge the work. Our note on TikZ Editor Makes LaTeX Figures Draggable is about a very different tool, but the shared lesson is familiar: interfaces and structure change how humans review changes.

Put local rules where the agent will find them

If you use Cursor Agent, the practical move is to make cleanliness reviewable at the repo boundary. Do not ask the agent to “write clean code” and hope it guesses your taste.

Put the rule near the code it protects. A small .cursor/rules file or an AGENTS.md boundary can tell the agent which abstractions are real, which files are off-limits, and when a cleanup diff should be separate from a feature diff.

For example, in a service repo:

---
description: Keep invoice changes local and reviewable
alwaysApply: false
---

When changing invoice behavior:
- Prefer edits in `src/billing/policies/*` before touching controllers.
- Do not mix feature work with broad cleanup.
- If dead code blocks the change, propose a separate cleanup diff first.
- Preserve public API names unless the task explicitly asks for a migration.
- In the final response, list every file revisited more than once and why.

That last line is small, but it maps directly to the study’s useful signal. File revisits are a cheap smell. They do not prove the agent is wrong, but they show where review should slow down.

The trap is making the rule too grand. “Follow clean architecture” is not a rule. “Policy changes start in src/billing/policies” is a rule the agent can actually use.

Review the path, not just the patch

The paper makes a nice case for reviewing operational footprint. In plain English: look at how much work the agent had to do to produce the diff.

In Cursor, that means you should review the agent’s changed files, touched areas, and final summary before you merge. If the agent opened five unrelated modules to add one validation rule, ask why.

This is where shared agent workflows for code review risk reduction become concrete rather than ceremonial. You are not adding process for its own sake. You are asking for the smallest receipt that lets another engineer understand the agent’s route through the code.

A good review question is: “Could a maintainer have predicted these touched files from the task?” If not, either the repo has hidden coupling, the prompt was too broad, or the agent drifted.

The trap is punishing exploration. Sometimes the agent must inspect call sites, migrations, or tests. The useful distinction is between exploration that leaves a clear receipt and exploration that turns into an unexplained multi-file patch.

Copy this Cursor review checklist

Use this when an agent changes production code in a repo where cleanliness matters. It is not a team rollout plan. It is a lightweight review receipt you can paste into a pull request or Cursor task note.

## Agent change review

Task:
- What behavior was requested?

Locality:
- Expected files or directories:
- Actual files changed:
- Any file revisited more than once? Why?

Cleanliness:
- Did the agent add duplicate logic, dead branches, or broad fallbacks?
- Did it preserve the existing abstraction boundary?
- Is cleanup mixed with feature work? If yes, split it or explain why not.

Tests:
- Which tests were run?
- Which important tests were not run?

Reviewer focus:
- The riskiest file is:
- The riskiest assumption is:
- One follow-up cleanup, if any:

One concrete next step: add the “Locality” and “Reviewer focus” blocks to your next agent-generated PR. If they feel hard to fill out, that is useful signal. Either the task was too broad, or the repo is making the agent work through fog.

Common questions

• Does this prove clean code makes coding agents better?

  No, it proves a narrower and more useful thing. In the reported 660 Claude Code trials, cleaner code did not improve pass rate, but it reduced token use by about 7–8% and file revisitations by 34%. That points to lower operational cost, not guaranteed higher correctness.

• Should we stop worrying about messy code if tests pass?

  No, because tests do not measure review burden or future maintenance. A coding agent can sometimes pass tests in a messy repo while producing a diff that is harder for humans to trust. The paper’s file-revisit signal is a reminder to review movement through the repo, not only the green check.

• How does this affect ai coding training for teams?

  It gives training a concrete metric to teach: agent footprint. Instead of telling developers to “prompt better,” show them how clean boundaries, scoped rules, and smaller tasks reduce wandering. The caveat is that the study used controlled pairs, so teams should validate the pattern on their own repos.

• Are shared agent workflows for code review risk reduction worth the overhead?

  Yes, when the workflow captures evidence the reviewer would otherwise have to reconstruct. A short receipt listing changed files, repeated file visits, tests run, and risky assumptions is usually enough. The overhead becomes wasteful when it turns into a generic checklist nobody reads.

• What is the biggest limitation of the study?

  Representativeness is the biggest limitation. Some clean versions may not match how expert humans naturally clean a long-lived codebase, so the result should not be overgeneralized. Read it as controlled evidence that cleanliness changes agent navigation, then test the same idea against your own code.

Best ways to use this research

• Best for: deciding what to inspect after an agent run. Start with changed files, repeated visits, and any abstraction boundary the agent crossed.
• Best first artifact: a small Cursor rule or AGENTS.md note that names the local boundary, such as “billing policy changes start in src/billing/policies.”
• Best comparison angle: compare pass rate against review footprint. A passing patch that sprawls across unrelated files is different from a passing patch that stays local.
• Best place to connect it: use it as one input to the related training topic, especially when discussing code review guardrails for agentic coding.
• Best MCP caution: if you connect tools through Model Context Protocol (MCP), Anthropic's open protocol for external context and tools, keep the first integration read-only until reviewers trust the agent’s path through the repo.

Further reading

• Cursor — Agent
• Cursor — Rules
• Does code cleanliness affect coding agents? A controlled minimal-pair study — arXiv
• Model Context Protocol — specification
• Google Search Central — helpful, people-first content

Try one small measurement

On your next agent task, record pass/fail, token spend if available, changed files, and repeated file visits. If cleaner boundaries reduce wandering in your repo, you have a practical reason to keep them clean.

One methodology lens

One useful way to read this through our methodology is the Plan step: delegate first-pass decomposition and dependency mapping, review the sequencing and assumptions, and keep ownership of scope and priorities. If that split is still fuzzy, the workflow usually is too.