JetBrains introduces a bundled 'refactoring-code' skill in Rider 2026.2.1 that lets AI coding agents call Rider's own C# refactoring engine directly instead of approximating refactors with sed, grep, and repeated dotnet build cycles. In a benchmark of fifteen C# refactoring tasks using gpt-5.5 through Codex CLI, giving the agent access to the skill cut median task time by 83%, cost per solved task by 64%, and tool calls by 63%. A detailed extract-base-class example shows the agent going from 24 tool calls and 336.7 seconds (with 11 build-and-fix cycles) down to 3 calls and 19.8 seconds when it can invoke Rider's structural refactoring directly.
Table of contents
Should compiler really be the oracle?Our evaluation methodologyWhat the agent can do armed with a Rider skillTime and moneyQuestions this post answers
What is the refactoring-code skill in JetBrains Rider 2026.2.1?
It is a bundled agent skill in Rider 2026.2.1 that lets AI coding agents invoke Rider's built-in C# refactoring engine (powered by ReSharper) directly, instead of approximating refactors with text edits and repeated dotnet build cycles. It activates automatically when an agent is asked to refactor C# code, covering operations like rename, extract method, extract interface, extract base class, change API signature, move type to namespace, reorganize namespaces, and safe delete. Developers wiring AI agents into their IDE workflows can track skill releases like this one on daily.dev.
How much faster is an AI coding agent at C# refactoring when it can call Rider's refactoring engine directly instead of using sed and dotnet build?
Across fifteen C# refactoring tasks run with gpt-5.5 through Codex CLI, giving the agent access to Rider's refactoring-code skill cut median task time by 83% (from 157.9 to 26.6 seconds), reduced cost per solved task by 64% (from USD 0.52 to USD 0.19), and cut tool calls by 63% (from 2,513 to 926 total across the evaluation), with dotnet build calls dropping from 163 to 3. Teams evaluating whether IDE-integrated agent skills beat raw shell access follow benchmarks like this on daily.dev.
Why does an AI agent keep running dotnet build over and over when refactoring C# code without IDE tooling?
An agent without structural refactoring tools uses dotnet build as a substitute for a resolved syntax tree: since it cannot know overload resolution, partial classes, explicit interface implementations, or documentation references from a regular expression alone, it guesses the edit in text via sed and lets the compiler's error output tell it what broke, repeating the guess-and-build cycle until the build succeeds. Anyone debugging why an agent thrashes on refactors can compare IDE-skill approaches surfaced on daily.dev.