Code Cleanliness Changes Coding Agent Footprints

A controlled study by Priyansh Trivedi and Olivier Schmitt reports that cleaner code changed the work needed by a coding agent, without changing its pass rate. Across 660 Claude Code trials on 33 tasks and six repository pairs, the authors report 7 to 8 percent fewer tokens and 34 percent fewer file revisitations in cleaner variants.
Updated 22 September 2026: combined the two accounts of this study, corrected the malformed token percentage, and replaced unsupported discussion summaries with a proposed measurement exercise.
Separate the reported result from a local prediction
The paper's pairs match architecture, dependencies and external behavior while differing in static-analysis violations and cognitive complexity. Agent pipelines construct the pairs in both directions: degrading clean repositories and cleaning messy ones. This is controlled evidence from that setup, not a promised saving for every model or established production codebase. Source: study abstract.
Our proposed exercise asks a narrower question: does one understandable cleanup reduce unnecessary work on a recurring maintenance task in your repository? It does not attempt to reproduce the study or establish a statistically reliable percentage from a few runs.
Define the task and preserve behavior
Choose one small subsystem with an existing test suite and a maintenance task you can explain precisely. For example, use a parser with duplicated validation paths and a known missing-input case. Record the expected behavior before the cleanup, including errors that must remain unchanged.
Make the cleanup a separate patch. Remove only duplication or indirection whose purpose you understand, then run the existing checks. If the cleanup changes behavior, resolve that difference before comparing agent performance. Otherwise you are measuring two different tasks.
Use the same agent version, model, prompt and available tools when practical. Start each trial without memory from the previous attempt. Record differences you cannot control, including cache state or model variability, instead of interpreting a single faster run as proof.
Collect evidence outside the final summary
Use actual usage reports and tool logs where available. An agent's retrospective list of files it remembers opening is not a reliable counter. If the interface does not expose a metric, mark it unavailable rather than estimating it from prose.
| Measure | What to record |
|---|---|
| Correctness | Original acceptance case and final test result |
| Usage | Reported tokens, separating cached usage when available |
| Navigation | File reads and repeat visits from recorded tool events |
| Patch | Changed paths, unexpected edits and dependency changes |
| Human effort | Time spent reviewing and correcting the result |
| Conditions | Agent version, prompt, tools and uncontrolled differences |
A repeated file visit is not automatically waste. Reading a caller again after changing a function can be necessary verification. Ask whether the extra work has an understandable purpose, and distinguish investigation from unrelated edits.
Keep the cleanup when it improves maintainability and preserves behavior, even if a small trial cannot detect an agent-cost difference. Do not reward deletion volume or require a broad refactor before every feature. The useful result is a smaller, clearer maintenance surface with evidence about how it behaves.
Where does your team stand?
Each team member completes the proficiency matrix individually. You receive a PDF with the team baseline and a recommended next step.
Assess your team