A Rename Is More Than a Find-and-Replace

A developer renames JoinHint to QueryHint. Should joinHint become queryHint throughout the project? What about a public-facing method that still uses the old name for compatibility? This is the challenge of coordinated renaming: one edit signals a broader conceptual change, but the right changes may not be obvious from code structure or matching words alone.

The paper introduces CoRenameAgent, a system designed to infer that broader intent and help propagate it through a codebase. Its central idea is to write the intent down as a natural-language “Declared Scope”—for example, change “join” to “query,” but avoid public methods—and use that as a guide for searching and editing. The developer reviews suggestions and can reject them; that feedback can refine the scope.

Three agents, one evolving scope

CoRenameAgent divides the work among three specialized agents. The Scope Inference Agent interprets the developer’s initial rename and updates the Declared Scope based on feedback. The Planned Execution Agent identifies candidate identifiers in a file and carries out approved changes using the IDE’s refactoring tools, rather than directly rewriting source code. The Replication Agent searches for other relevant files, combining program-dependency analysis with targeted keyword searches, then sends candidates for further review.

This design addresses a tension in automated code changes. A tool relying mainly on structural relationships may miss names that are conceptually related but not directly connected in the program. A language model searching broadly may find more candidates, but can also propose plausible edits that go beyond the developer’s intent. The authors’ approach tries to combine semantic reasoning with structured edits and human review.

What the study tested

The researchers first examined 609,000 commits from 100 open-source Java projects and surveyed developers about coordinated renaming. They then evaluated CoRenameAgent on two Java benchmarks: an established set of 1,349 coordinated renames and a newer set of 1,573 renames drawn from commits after May 2025. The newer benchmark was intended to reduce the risk that language models had encountered the examples in training. The team compared the system with static-analysis software, general-purpose coding agents and language models used without the full workflow.

On both benchmarks, CoRenameAgent achieved the highest F1 score among the tested approaches, a measure that balances finding relevant renames against avoiding irrelevant suggestions. On the newer benchmark, for example, its reported F1 score was 48.5% with one tested model and 41% with another. These results do not mean it found every correct rename: on that benchmark, reported recall was 53% and 40%, respectively. The system’s performance depended on the model and the test set.

An ablation test helps explain the workflow’s components. Adding project-wide search increased recall, but also generated many more out-of-scope suggestions. Adding developer feedback and scope refinement improved the balance between finding candidates and keeping suggestions relevant. This supports the authors’ view that exploration alone is not enough: the system needs a way to stay aligned with the intended change.

In a one-week study, 20 graduate students used the tool on their own Java projects. Participants accepted 91% of its proposed coordinated renames and reported applying 1,306 renames. They estimated saving an average of 30 minutes per session. These are encouraging signs of usefulness, but they come from a small, short study; the time savings were participant estimates, not a controlled comparison of measured work time.

What remains uncertain

The evidence is specific to open-source Java projects, and the authors note that other languages would require different refactoring and program-analysis components. Benchmark labels were derived from changes developers made in commits. If a valid rename was delayed or omitted from those commits, the benchmark could mark a reasonable suggestion as incorrect. And although the IDE tools enforce checks for supported refactorings, deciding whether an identifier belongs within the intended conceptual change still requires judgment.

The paper is an arXiv preprint, so its results should be read as research claims rather than settled evidence. Its benchmarks, comparisons and user study test one task and one system; they do not show that the method will work equally well across teams, languages or types of software maintenance. The broader contribution is a practical design proposal: make a developer’s intent explicit, let feedback revise it, and use trusted tools to carry out the resulting edits.