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

JetBrains Rider 2026.2.1 now bundles a `refactoring-code` skill that lets AI agents invoke its C# refactoring engine directly, cutting median task time by 83%, cost per solved task by 64%, and tool calls per task by 63% across fifteen refactoring tasks tested with GPT-5.5 via Codex CLI. The skill eliminates the need for the agent to use `dotnet build` as an oracle, reducing build calls from 163 to 3.

.NET Tools Essential productivity kit for .NET and game developers AI /dotnet/category/ai/ Rider /dotnet/category/rider/ 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 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 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. 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 https://blog.jetbrains.com/dotnet/2026/05/22/claude-codex-ai-agent-skill-for-writing-tests/ and profiler output https://blog.jetbrains.com/dotnet/2026/06/25/performance-profiling-agent-skill-in-rider/ . Rider ships a growing set of agent skills https://www.jetbrains.com/rider/whatsnew/ 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. Subscribe to a monthly digest curated from the .NET Tools blog: