Rider Hands AI Agents The Keys To Its Refactoring Engine For Safer, Faster, And Cheaper Results

Sasha Ivanova

We traced a frontier model through fifteen C# refactoring tasks and counted what it reached for. It piped text into interactive commands 468 times. It called git 422 times and sed 392 times. It ran dotnet build 163 times. Across 2,513 tool calls it performed a structural refactoring operation exactly zero times. Not because it was avoiding them: it had none to call.

Rider has dozens of C# refactorings, and as of 2026.2.1 an agent can invoke them instead of approximating them. The vehicle is a bundled skill called refactoring-code. It ships with the IDE, there is nothing to switch on, and it activates by itself as soon as an agent is asked to refactor C# code. We gave the same model the same fifteen tasks again with the skill in place.

Should compiler really be the oracle?

That count of 163 builds gave us pause at first. But then we realized that the agent was not compiling to check finished work, it was compiling to find out what its last edit had done. A correct rename follows overload resolution, partial classes, explicit interface implementations and documentation references, and it knows the difference between a type called Order and the word “order” in a comment. None of that is recoverable from a regular expression, so the agent guesses in text and lets the build score the guess.

Rider does not have to guess, because it has a resolved syntax tree. Its refactoring engine, powered by ReSharper, works from the same model that drives the IDE’s own inspections and navigation: it knows which declaration every identifier binds to, which overload each call resolves to, and where every reference lives across the solution. The knowledge the agent was reconstructing one build at a time is the knowledge the IDE would have applied in one go.

Our evaluation methodology

Rider has dozens of C# refactorings and we did not try to cover them all when testing the efficacy of the refactoring-code skill. We evaluated eight, chosen because they have the cleanest contracts: a defined target, a defined result, and a refusal when the change is unsafe. Those are the ones where success and failure are unambiguous, which is what makes them worth measuring in the first place.

• rename_refactoring: rename a symbol and every reference to it
• extract_method: pull a statement range into a new method
• extract_interface: derive an interface from an existing type
• extract_base_class: lift members into a new base class
• change_api_signature: alter parameters and update all call sites
• move_type_to_namespace: relocate a type and repair usings
• reorganize_namespaces: align namespaces with folder structure
• safe_delete: remove a symbol only when nothing depends on it

Fifteen tasks covered the eight operations, most in two variants: a straightforward case and a harder one with more call sites or more entangled dependencies.

Both arms ran gpt-5.5 through the Codex CLI, roughly ten times per task, and the only difference between them was whether refactoring-code was available.

Timing, cost and tool counts come from the recorded traces, and the comparisons below use a paired permutation test.

What the agent can do armed with a Rider skill

With the skill in place, the need for the build oracle disappears: dotnet build drops from 163 calls to 3. The scaffolding the agent had built around guessing goes with it, and total tool calls fall from 2,513 to 926 across the evaluation.

The agent did not stop editing text. sed remains its most-used tool, and the eight refactoring operations account for only 167 of those 926 calls. What changed is the division of labour: ordinary edits stay in the editor’s medium, and the structural changes, the ones whose consequences ripple beyond what the agent can see, go to the engine.

Time and money

Median task duration fell from 157.9 seconds to 26.6 seconds. The 95th percentile fell further, from 346.4 seconds to 56.9 seconds, because the slowest runs were the ones trapped in the edit-build-read-error cycle and those runs stop existing. Both improvements are significant under a paired permutation test.

Cost follows the clock. Median cost per task went from USD 0.33 to USD 0.12, and cost per solved task from USD 0.52 to USD 0.19, on roughly half the tokens: input fell from 436,745 to 208,524 per task, cache reads from 2,973,158 to 1,257,600, and output from 32,532 to 15,538.

Numbers show that the behavior changed, but they do not show how. So here is one task from the set, laid out call by call in both arms.

On the left, the loop this whole post has been describing: the agent finds the class, edits text to invent a base class, and then spends eleven builds negotiating with the compiler over what those edits broke. On the right, the same task with the skill in place: the same search to find the target, one call to extract_base_class, and a glance at the diff.

We picked extracting a base class because it was the starkest single swing in the evaluation, from 337 seconds and 24 tool calls to 20 seconds and three, but the shape of the change is the same everywhere the skill won.

Trying this yourself takes one prompt. Update to Rider 2026.2.1, open a C# solution, and ask your agent to rename, extract, or move something. The skill activates on its own. Naming the operation helps: “extract an interface from OrderProcessor” gives the agent something concrete to reach for in a way that “clean up this class” does not.

This is the third of these skills we have measured. The earlier two gave the agent coverage data and profiler output. Rider ships a growing set of agent skills built on the same idea: let the agent tap into the IDE’s own intelligence rather than reconstruct it, and get better results for fewer tokens. Try them on a real codebase, and tell us how they did.