[Paper] Multi-Agent Coordinated Rename Refactoring

Source: arXiv - 2601.00482v1

Overview

Coordinated rename refactoring—where a single rename must ripple through many related identifiers—is a common yet error‑prone chore for developers. This paper presents the first multi‑agent framework that partners with developers to automate the whole process, turning an initial rename into a project‑wide, safe transformation while keeping the human in control.

Key Contributions

• Multi‑agent architecture (Scope Inference, Planned Execution, Replication) that orchestrates LLM reasoning with IDE‑native refactoring APIs.
• Declared Scope language: a concise natural‑language representation of the rename’s intended reach, generated automatically from the developer’s first edit.
• Empirical study of coordinated renames across 609 K commits in 100 open‑source projects, revealing patterns and pain points.
• User evaluation (205 developers) showing a 73 % reduction in manual effort and a 5× drop in false‑positive suggestions compared to heuristic tools.
• Open‑source prototype integrated with VS Code and IntelliJ, released under an Apache‑2.0 license.

Methodology

1. Formative Mining – The authors mined rename commits to quantify how often a rename triggers additional changes and to identify the contexts (e.g., class names, API symbols) that matter.
2. Agent Design
   • Scope Inference Agent reads the developer’s initial rename (the “clue”) and, using an LLM, produces a Declared Scope such as “rename all public methods named fetchData and any overloads in the data package”.
   • Planned Execution Agent translates this scope into a concrete plan, queries the IDE’s refactoring engine, and validates each change against the scope before applying it.
   • Replication Agent runs a project‑wide search based on the plan, feeding results back to the Execution Agent for any edge‑case handling.
3. Implementation – The agents communicate via a lightweight JSON‑RPC protocol, allowing the LLM to stay stateless while the IDE handles the heavy lifting.
4. Evaluation – Two phases: (a) a benchmark on 1 200 real rename scenarios comparing against heuristic rename tools and vanilla LLM suggestions; (b) a user study where participants performed coordinated renames with and without the agents, measuring time, error rate, and subjective workload.

Results & Findings

• The Declared Scope captured 96 % of the intended rename footprint, even for complex cross‑module symbols.
• By delegating the actual edits to the IDE’s trusted refactoring APIs, the system avoided the “hallucination” errors typical of raw LLM output.
• Participants reported that the agents let them stay “in the driver’s seat” while the system handled the repetitive plumbing.

Practical Implications

• IDE Plugins – The architecture can be packaged as a plug‑in for any modern IDE that exposes refactoring APIs, giving teams an out‑of‑the‑box assistant for large‑scale renames.
• CI/CD Integration – The agents can run in a pre‑commit hook to suggest a complete rename plan, reducing code‑review friction for API deprecations.
• Enterprise Codebases – In monorepos with thousands of interdependent modules, coordinated renames often become bottlenecks; this approach can cut the turnaround from days to minutes.
• Developer Onboarding – New team members can rely on the agents to understand the ripple effect of a rename, lowering the learning curve for legacy code.
• Extensibility – The same multi‑agent pattern can be repurposed for other coordinated refactorings (e.g., extract interface, move class) where a single developer intent propagates widely.

Limitations & Future Work

• Scope Generation Relies on LLM Quality – In languages with sparse documentation or highly dynamic code (e.g., JavaScript), the Scope Inference Agent sometimes missed edge cases.
• IDE Dependency – The current prototype works only with IDEs that expose a stable refactoring API; headless environments need additional adapters.
• Scalability of Search – For extremely large codebases (>10 M LOC), the Replication Agent’s project‑wide search becomes a performance hotspot; incremental indexing is a planned improvement.
• User Trust – While false positives were low, developers still need to review the generated plan; future work will explore richer visualizations and “undo‑by‑example” mechanisms.

The authors envision a broader ecosystem where multiple specialized agents collaborate—handling naming, type migration, and architectural reshaping—turning AI‑augmented refactoring into a routine part of the developer workflow.

Authors

• Abhiram Bellur
• Mohammed Raihan Ullah
• Fraol Batole
• Mohit Kansara
• Masaharu Morimoto
• Kai Ishikawa
• Haifeng Chen
• Yaroslav Zharov
• Timofey Bryksin
• Tien N. Nguyen
• Hridesh Rajan
• Danny Dig

Paper Information

• arXiv ID: 2601.00482v1
• Categories: cs.SE, cs.AI
• Published: January 1, 2026
• PDF: Download PDF