.NET Tools #
Essential productivity kit for .NET and game developers
[AI](/dotnet/category/ai/)
[Rider](/dotnet/category/rider/)
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
83% faster
Cost per solved task
64% cheaper
Tool calls per task
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 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 itextract_method
: pull a statement range into a new methodextract_interface
: derive an interface from an existing typeextract_base_class
: lift members into a new base classchange_api_signature
: alter parameters and update all call sitesmove_type_to_namespace
: relocate a type and repair usingsreorganize_namespaces
: align namespaces with folder structuresafe_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.
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
336.7s Calls
24 Cost
USD 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
19.8s Calls
3 Cost
USD 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.