Coding agents refactor for readability, not architecture

When AI agents write code, they take on more and more of what used to be purely human work — planning, running tests, even step-by-step refactoring. The authors of Agentic Refactoring: An Empirical Study of AI Coding Agents are the first to look at that practice broadly and in depth: how agents refactor in real open-source projects, whether it pays off, and how their style differs from a human's.

Why it matters

Refactoring is effective preventive care: it clears out technical mistakes and brings down technical debt. It improves readability and maintainability, and prepares a system for future changes without changing its behavior. LLM agents add a way to automate it — they generate proposed changes, break the task into steps, run the checks on those changes, and report back in the form of a pull request, acting as a sort of colleague. How well does that work? Could automatic refactoring become a source of new problems?

How the study was done

Working through a large set of Java projects from the AIDev dataset and commits collected on GitHub, the authors used RefactoringMiner (which identifies 103 change types) to detect any refactoring changes and to find signals of refactoring intent in PR and commit messages.

How often agents refactor, and what it looks like

It is a fairly common practice: 26.1% of Java commits are explicitly devoted to refactoring, and they carry more refactoring operations because the work is concentrated in one place. So this is not a side effect of other edits but a deliberate task, often in a pull request of its own.

What agents actually change when they refactor

The picture differs from the human one. Agents are dominated by refactorings with local impact — moving code around, reworking the immediate scope, and similar operations. Human commits more often touch interfaces and architecture (incoming and outgoing dependencies). The agent, in other words, does day-to-day upkeep on the codebase and rarely touches the system's architecture.

Does it produce measurable benefit

The motives the agent states are mainly maintainability and readability (52.5% and 28.1% of changes, respectively). Architectural motives come up far less often than they do with humans. By its own account, the agent cares more about code being easy to read than about reuse and removing duplication. The metrics do improve in the end, but only slightly.

Examples in the wild

Splitting a long method into several helpers. The classic way to improve readability and make a program's control flow more predictable. PR

Renaming assorted variables across many files. It improves clarity, but barely moves the structural metrics. PR

What this means in practice

• Trust the agent with the routine. This kind of refactoring is already useful for standard fixes, aligning style, decomposition, and cutting the time spent on code review.

• In half of the tasks, refactoring is mixed in with other edits. Agents should additionally be required to keep commits separate and to group changes of the same kind.

The authors study only Java repositories. The "agentic" commits, singled out by their messages, may contain both other edits and human-written code. Extending these results to other languages and project contexts therefore calls for a great deal of caution.

Takeaway

Agents are already doing plenty of code refactoring. It brings real benefit locally, but at the level of metrics there are no standout improvements and no effect on architecture. So the roles should be split: leave the system's hygiene to the agents, and keep architectural decisions with people.

💾 Code