Clean Repos Make Coding Agents Cheaper

Does code cleanliness affect coding agents? A controlled minimal-pair study is a May 2026 arXiv paper from researchers studying coding-agent behavior in paired clean and messy repositories. It asks a practical question: do agents do better work when the code is easier for humans to follow? The short answer is subtle: cleanliness did not change the agent’s pass rate in the reported trials, but it did reduce the work the agent had to do. For OpenAI Codex, OpenAI’s coding agent, that points toward shared agent workflows for code review risk reduction: keep the repo legible, then review the agent’s footprint, not just the final diff.

Read the result as a footprint result

A minimal-pair study is an experiment that compares two versions of the same task where one important variable changes and the rest is held as steady as possible. In this paper, that variable was code cleanliness.

The headline finding is not “clean code makes agents smarter.” Across 660 trials with Claude Code, Anthropic’s coding agent, the reported pass rate did not meaningfully change between clean and messy variants.

The useful finding is about operational cost and reviewability. The paper reports that cleaner code led to 7–8% fewer tokens and 34% fewer file revisitations. That is the kind of result a working engineer can feel in a real session: less wandering, fewer “why is it back in that file?” moments, and a smaller trace to inspect after the agent stops.

The trap is treating pass rate as the only score. A green test suite can hide a painful path. If an agent burns through context, reopens the same files, and edits around dead abstractions, the PR may pass while still being harder to trust.

Notice what developers argued about

The paper landed in the familiar fault line around agentic coding. Some developers said the result matched their experience: dead code, duplicated branches, unreachable fallbacks, and leaky abstractions make agents spend more effort just finding the right change.

Others pushed back on the construction of the repo pairs. A fair objection is that if some “clean” variants were produced by agent pipelines, they may not represent code that a strong human maintainer would call clean. That matters. “Less messy than before” and “well designed” are not the same thing.

There is also a human point that should not get lost. Even if a coding agent can eventually navigate a swamp of stubs and WET code, the humans still have to own it. Code review is not only a correctness checkpoint. It is the moment where the team decides whether the next person, or the next agent, can safely change the system again.

A related note on our side, Code Cleanliness Changes Coding Agent Footprints, makes the same distinction worth keeping: the agent outcome and the agent path are different artifacts.

Use cleanliness as context, not ceremony

The practical lesson is small and boring, which is why I like it. Before asking an agent to change a messy area, give it the local rules and remove obvious distractions when that cleanup is low risk.

For Codex, that can be as simple as a scoped AGENTS.md note near the code being edited. Keep it factual. Do not turn it into a style manifesto.

# AGENTS.md

Scope: services/billing/**

Before editing billing flows:
- Prefer `Money` helpers from `services/billing/money.ts`.
- Do not add new fallback currency parsing paths.
- Remove unused local helpers when the change makes them unreachable.
- Run `pnpm test services/billing` before handing off.

Review note:
- In the final response, list files revisited more than once and why.

That last line is the interesting one. It asks the agent to expose part of its path, not just its patch. In a real repo, this is often more useful than asking for a long explanation of every edit.

The trap is doing a grand cleanup before every feature. Sometimes the right tradeoff is still to ship the prototype and accept debt for a week. Coding agents are faster than humans at producing code, but they are not magic debt erasers. They can also create more surface area faster.

Add one review check for agent wandering

If you want one concrete habit from the study, add an “agent footprint” line to AI-assisted code review. This is the practical place where shared agent workflows for code review risk reduction belong: not as a big process, but as one observable signal beside tests and diff quality.

For example, after a Codex session, ask for a short handoff receipt:

## Agent handoff receipt

Task: Add invoice retry backoff for failed card payments.

Changed files:
- services/billing/retry.ts
- services/billing/retry.test.ts

Verification run:
- pnpm test services/billing/retry.test.ts

Footprint notes:
- Revisited `services/billing/retry.ts` twice: first to add backoff, second to remove an unused branch.
- Did not edit currency parsing or payment provider adapters.
- No MCP writes were used.

The MCP line matters when agents can touch external systems. Model Context Protocol (MCP) is a standard way for agents to connect to tools and data sources. In review, a simple boundary note like “read-only GitHub and docs; no Jira writes; no database writes” keeps the agent’s external actions inspectable.

This is also where ai coding training for teams should stay grounded. Teach people to ask for verifiable receipts, scoped repo rules, and narrow tool permissions. Do not teach them to trust a pretty transcript.

Try this safely: a review checklist

Use this when a coding agent edits a part of the repo that already feels hard to navigate. It is light enough for one PR and specific enough to catch the failure mode the paper points at.

• The task starts with a scoped rule file, such as AGENTS.md, in the directory being edited.
• The agent names the files it changed and the files it revisited.
• The agent explains any revisited file in one sentence.
• The diff removes dead or unreachable code only when the task makes that code clearly obsolete.
• Tests or checks are listed as commands, not summarized as “validated.”
• MCP access is stated as read-only, write-limited, or not used.
• The reviewer checks whether the final design is easier for a human to follow than before.

The trap is rewarding cleanup volume. A huge “cleanup” diff can be worse than the mess it replaced. Prefer the smallest cleanup that reduces agent wandering and human review cost.

Common questions

• Does clean code make coding agents pass more tests?

  Not in the main result reported by this paper. Across 660 Claude Code trials, code cleanliness did not change pass rate, but cleaner code reduced token use by 7–8% and file revisitations by 34%, which makes the agent’s path cheaper and easier to inspect.

• Should we clean a repo before using Codex?

  Not across the whole repo. Clean the local area when the mess directly blocks the task: dead branches, duplicate helpers, misleading names, or stale fallbacks. A small scoped cleanup plus an AGENTS.md rule is usually safer than a broad refactor before the real change.

• How do shared agent workflows for code review risk reduction fit this study?

  They fit as review guardrails, not as the subject of the study. The paper suggests agent footprint matters, so a shared workflow can ask for changed files, revisited files, verification commands, and MCP boundaries. That gives reviewers evidence without pretending the agent’s transcript is proof.

• Does this change ai coding training for teams?

  Yes, but only in a modest way. Training should teach engineers to inspect agent behavior signals: token-heavy wandering, repeated file visits, broad tool access, and unexplained cleanup. The citable number here is the 34% reduction in file revisitations on cleaner code.

• What is the biggest limitation of the result?

  The strongest limitation is representativeness. If a “clean” repo variant is produced by an agent pipeline, it may not match a carefully maintained human codebase. Treat the paper as evidence about agent operational footprint, not as final proof about every kind of code cleanliness.

Best ways to use this research

• Best for: deciding what to inspect after an AI coding session. Look at the path the agent took, not only whether the patch passes tests.
• Best first artifact: a short handoff receipt with changed files, revisited files, verification commands, and MCP permission notes.
• Best comparison angle: compare messy and clean areas of your own repo by agent footprint: repeated file reads, context churn, and review time.
• Best boundary: keep cleanup scoped to the files the task already touches unless the agent can show a direct reason to widen the diff.

For broader practice around AI coding governance, this paper is a good reminder that governance does not have to start as policy. Sometimes it starts as one better review question: “How much did the agent have to wander to make this change?”

Further reading

• OpenAI Codex documentation
• Codex — Agent
• Does code cleanliness affect coding agents? A controlled minimal-pair study — source
• Google Search Central — helpful, people-first content

Try one small measurement

On your next Codex-assisted PR, ask for changed files, revisited files, and verification commands in the handoff. If the agent wandered, fix the local rule or the local mess before making that path normal.

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.