Your Refactoring Agent Needs a Maintenance Contract, Not a Janitor Badge

The next coding-agent temptation is not a bigger pull request. It is the quiet background worker that keeps “cleaning up” your codebase while everyone else ships features.

That sounds useful. Most teams have too much old glue code, too many half-finished migrations, and too many local conventions that live only in senior engineers’ heads. A capable agent that can notice drift, propose fixes, update tests, and keep the system tidy is obviously attractive.

It is also a different risk category from a one-off code assistant.

A one-off refactoring task has a beginning, an operator, a review moment, and a bounded change. Continuous autonomous refactoring turns maintenance into a loop. The agent watches code, absorbs signals, decides what quality means today, edits across modules, and potentially repeats that behavior every week. At that point, the central design question is no longer “can the model refactor?” It is “what contract governs the maintenance system?”

A recent research roadmap on continuous autonomous refactoring frames this shift directly. It argues that LLM-based refactoring should be studied as an ongoing software-maintenance component, not merely as method-level cleanup. The roadmap names the hard parts: multi-objective optimization, quality definition and evaluation, signal integration across timescales, architecture, design patterns, trust, delivery-pipeline integration, and cost. That is the right frame. A refactoring agent is not a janitor with a badge. It is a production maintenance process that happens to use an AI system.

The practical version should start with five explicit clauses.

First, define the quality objective. “Improve the code” is not an objective; it is a permission slip. A useful contract says which quality dimension matters for this run: reduce duplicated validation logic, complete a deprecated API migration, simplify a module that exceeds a complexity threshold, or align tests with a newly documented interface. The objective should also say what the agent must not optimize. A change that improves local readability while breaking observability, performance, or operational familiarity may be a regression.

Second, bound the authority. Continuous refactoring agents should not have blanket write access across the repo by default. Authority should be scoped by directory, change type, risk level, and release stage. A documentation-only cleanup, a pure rename, and a cross-service interface migration do not deserve the same permission model. The agent should earn broader authority through evidence, not inherit it because the workflow feels internal.

Third, require trajectory evidence. Traditional pass/fail evaluation is too thin for this job. The new work on trajectory-aware SWE-agent benchmarking points in a useful direction: software-agent evaluation can use process evidence such as explored context, attempted edits, solving paths, and final outcomes. That matters because two refactoring agents can both end with green tests while one understood the dependency graph and the other got lucky. For continuous maintenance, the review packet should include what the agent inspected, which alternatives it rejected, which tests it trusted, which tests it did not run, and where uncertainty remains.

Fourth, keep a human review surface. The point of automation is not to hide change from engineers. It is to compress the boring parts while preserving accountability. The VibeJam work on web-development agents is a reminder that online, human-in-the-loop study surfaces matter because offline metrics miss how people actually collaborate with agents. For refactoring, that means readable plans, small diffs, preview environments when relevant, and review modes that let engineers accept, reject, or redirect the maintenance loop. If the agent’s work only appears as a large bot-authored pull request, the organization has automated toil into review debt.

Fifth, attach rollback and release gates. A refactoring loop should produce a release artifact, not just a diff. What changed? Why now? Which quality objective did it serve? Which tests, static checks, and runtime probes passed? Which owners reviewed it? How do we revert it? If the answer is “the bot changed it because the bot thought it was cleaner,” the system is not ready for production autonomy.

Security makes this stricter, not looser. Persistent agents accumulate context. They read issues, comments, docs, code, generated artifacts, and prior conversations. Recent work on context privilege escalation in agent harnesses shows why that is dangerous: low-trust content can be assembled into higher-privileged context, or persist across scopes, influencing later tool use. A refactoring agent is an especially tempting target because it has a plausible reason to read almost everything and a plausible reason to write almost everywhere.

So the maintenance contract needs a context boundary too. The agent should record which context sources were used, classify their trust level, and prevent untrusted instructions from becoming operational commands. A GitHub issue can describe a bug. It should not silently become a rule that authorizes edits outside the requested scope. A README from a dependency can inform a migration. It should not override local release policy. A generated report can summarize findings. It should not persist as privileged memory unless someone approved it.

The healthiest pattern is boring and enforceable. Give the agent a narrow maintenance objective. Let it inspect the relevant code. Make it produce a plan. Make it attach trajectory evidence. Make it open a small reviewable diff. Run deterministic checks. Require owner review for higher-risk areas. Merge through the same release path as human changes. Feed the outcome back into the next maintenance cycle.

That may sound slower than letting the agent roam. It is actually what makes the agent usable. Engineering organizations do not need infinite cleanup. They need dependable improvement under constraints. A maintenance contract turns the agent from a clever background actor into a governed participant in the software-delivery system.

The teams that get value from autonomous refactoring will not be the ones with the boldest bot permissions. They will be the ones that can answer, for every automated change: what quality target was pursued, what evidence supports it, what authority was granted, what context was trusted, who reviewed it, and how the system recovers if it was wrong.

That is the bar. Not “did the model produce a nicer-looking diff?” Not “did the test suite happen to pass?” The bar is whether the refactoring loop can prove that each change belonged inside the maintenance contract.

Give the agent a contract before you give it a badge.