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

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.

The refactoring-code skill, bundled in JetBrains Rider

Median task time

before: 157.9s → after: 26.6s

83% faster

Cost per solved task

before: USD 0.52 → after: USD 0.19

64% cheaper

Tool calls per task

before: 17.0 → after: 6.2

63% fewer

Medians across fifteen C# refactoring tasks, each run roughly ten times with the same model and the same prompts. The only difference between the two arms was whether the agent could call Rider’s refactoring engine.

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.

Per-task results

Where the skill wins outright, slowest task first

The eight tasks where the skill-enabled arm was faster, cheaper and used no more tool calls, with both arms passing their tests. One representative run per arm, ordered by how long the baseline took.

Showing time in seconds.

Without the skill With refactoring-code extract-base-class-2 337s 20s -94% move-type-to-namespace-1 297s 24s -92% rename-1 192s 35s -82% reorganize-namespaces-1 160s 25s -84% rename-2 157s 24s -85% extract-method-1 157s 25s -84% reorganize-namespaces-2 26s 11s -57% safe-delete-1 21s 19s -9% extract-base-class-2 24 3 -88% move-type-to-namespace-1 25 7 -72% rename-1 21 7 -67% reorganize-namespaces-1 18 3 -83% rename-2 16 7 -56% extract-method-1 16 4 -75% reorganize-namespaces-2 13 2 -85% safe-delete-1 10 6 -40% extract-base-class-2 1.146 0.090 -92% move-type-to-namespace-1 1.046 0.160 -85% rename-1 0.986 0.137 -86% reorganize-namespaces-1 0.385 0.134 -65% rename-2 0.327 0.162 -50% extract-method-1 0.497 0.098 -80% reorganize-namespaces-2 0.181 0.078 -57% safe-delete-1 0.108 0.088 -18%

Eight of the fifteen tasks clear that bar, and the six that had taken the baseline over two minutes improved by 82–94%. The other seven are left out: two were solved by neither arm, one was solved without the skill but not with it, and four were already quick enough that invoking the IDE did not pay for itself. The aggregate figures quoted elsewhere in this post cover all fifteen.

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.

One task, two trajectories

Extract Base Class as the model example

A single test case that shows, side by side, how the agent goes about a refactoring with and without Rider’s dedicated skill. It was the slowest task in the set without the skill, and the largest single improvement with it.

Without the skill

Time336.7s Calls24 CostUSD 1.15

rg "class ReportExporter" -n src/

find . -name "*.cs" -path "*Reporting*"

nl -ba src/Reporting/ReportExporter.cs

grep -rn "ReportExporter" src/ tests/

apply_patch src/Reporting/ExporterBase.cs

sed -i 's/class ReportExporter/& : ExporterBase/' src/Reporting/ReportExporter.cs

dotnet build

error CS0534: does not implement inherited abstract member

error CS1729: no constructor takes 2 arguments

sed -i 's/public ReportExporter(/protected ReportExporter(/' src/Reporting/ExporterBase.cs

dotnet build

error CS0122: inaccessible due to its protection level

... 9 further edit-and-build cycles ...

dotnet build

Build succeeded

With refactoring-code

Time19.8s Calls3 CostUSD 0.09

rg "class ReportExporter" -n src/

execute_tool::extract_base_class

target: ReportExporter

name: ExporterBase

members: Format, WriteHeader, Dispose

created src/Reporting/ExporterBase.cs

updated 4 files, 11 references rewritten

git diff --stat

5 files changed, 47 insertions(+), 23 deletions(-)

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.

Download JetBrains Rider