A trial conducted by JetBrains showed that giving AI agents direct access to Rider’s refactoring engine can fundamentally change how C# tasks are performed, instead of forcing the agent to modify text and then run the compiler to discover what its changes broke. In a test involving 15 tasks, the median task time fell from 157.9 seconds to 26.6 seconds, an improvement of 83%, while the number of tool calls dropped from 17 to 6.2 per task.
The capability is provided through a built-in skill called refactoring-code, which is available in Rider starting with version 2026.2.1. According to JetBrains, users do not need to enable it manually; the agent invokes it automatically when asked to refactor C# code. The engine relies on ReSharper technologies and Rider’s analytical architecture to understand relationships between symbols and references within the project.
The Problem with the Modify-Then-Build Approach
Before the skill was made available, JetBrains observed an advanced model performing the same tasks. Across 2,513 calls to various tools, the agent did not perform any direct structural refactoring because it had no dedicated tool for that purpose. Instead, it used interactive commands to enter text 468 times, invoked git 422 times and sed 392 times, and ran dotnet build 163 times.
This does not mean that the agent avoided refactoring operations; rather, it attempted to approximate them through searching and textual modification, then used build results to evaluate what had happened. JetBrains explains that renaming a symbol, for example, requires distinguishing between references associated with a particular definition, calls to polymorphic methods, partial classes, explicit interface implementations, and documentation references. These relationships cannot be reliably handled with simple regular expressions.
By contrast, Rider’s engine operates on a resolved syntax tree that identifies the definition associated with each identifier, the version invoked by each call, and reference locations across the solution. This moves the structural part of the task to the engine, rather than requiring the agent to rediscover these relationships gradually through repeated cycles of modification, building, and reading errors.
What Did JetBrains Measure?
The evaluation focused on eight operations with clearly verifiable outcomes:
- Renaming a symbol and all references to it.
- Extracting a set of statements into a new method.
- Extracting an interface from an existing type.
- Extracting a base class and moving members to it.
- Changing an API signature and updating call sites.
- Moving a type to another namespace and fixing using statements.
- Reorganizing namespaces to match the folder structure.
- Safely deleting a symbol when no other part depends on it.
The tasks included straightforward cases and more complex ones, with larger numbers of call sites or intertwined dependencies. Both sides ran the same model, gpt-5.5, through Codex CLI, approximately ten times per task. The only difference was whether the refactoring-code skill was available. The comparisons were based on recorded traces and a paired permutation test.
Practical Results and Cost
With the skill enabled, the number of dotnet build operations fell from 163 to only three, and total tool calls in the evaluation dropped from 2,513 to 926. Textual modifications did not stop, as sed remained the most frequently used tool, but the division of labor changed: ordinary modifications remained with text-editing tools, while the engine handled structural changes whose effects could extend to parts the agent could not see directly.
The 95th-percentile time fell from 346.4 to 56.9 seconds, an improvement associated especially with the disappearance of cases stuck in the cycle of modification, building, and error handling. The median cost per task fell from $0.33 to $0.12, while the cost per successful task dropped from $0.52 to $0.19. The number of input tokens also fell from 436,745 to 208,524 per task, cached reads from 2,973,158 to 1,257,600, and outputs from 32,532 to 15,538.
What Does This Mean for Users?
The trial shows that the usefulness of agent tools depends not only on the model’s ability to produce code, but also on the types of tools it can invoke. In eight of the 15 tasks, the side with the skill was faster and less expensive without using a larger number of tools, with both sides succeeding on the tests. The six tasks that took more than two minutes in the baseline mode improved by between 82% and 94%.
However, the results are not a universal gain for every case. Both sides failed on two tasks, the baseline mode succeeded on one task that the skill-enabled mode did not, and four tasks were already fast enough that invoking the Rider engine was not economically useful. Therefore, the figures provide evidence of the skill’s value for a specific set of refactoring operations, not a guarantee that every task will improve by the same amount.
To illustrate the difference, JetBrains presented a task involving extracting a base class from the ReportExporter type. Without the skill, execution took 336.7 seconds and 24 calls at a cost of $1.15, and involved multiple cycles of modifying files and running the build to address inheritance, constructor, and access-rights errors. With the skill, it took 19.8 seconds and three calls at a cost of $0.09; the agent performed the extract_base_class operation, created ExporterBase, updated four files, and rewrote 11 references.
The feature can be tried by updating Rider to version 2026.2.1, opening a C# solution, and asking the agent to rename an element, extract an interface, or move a type. The article recommends making requests specific by naming the operation, such as asking to extract an interface from OrderProcessor, rather than using a general phrasing such as “clean up this class.”