JetBrains is using coverage data to tell coding agents where tests belong, turning test placement into a cost and workflow control problem instead of a blind search exercise.
One of the easiest ways to waste money with a coding agent is to make it hunt for the right test file.
The model starts poking through folders, opening files, guessing at naming conventions, and burning tokens just to answer a question a human teammate often knows immediately: where do tests for this code usually live?
JetBrains is attacking that exact waste pattern in Rider 2026.2 EAP with a finding-tests skill that uses coverage data to route the agent toward the tests already connected to the code it is changing.
That makes this more interesting than a generic "AI writes tests" story. It is a workflow-control story about reducing blind search.
In its May 22 .NET tools post, JetBrains says the new skill can use dotCover coverage data to identify which tests are connected to nearby code. Instead of letting the agent discover test structure by scanning the repo, Rider can direct it toward the right test file or fixture.
The company also claims internal benchmarks showed up to 50 percent lower token cost in some C# test-generation cases.
That number will get attention, but the more useful detail is how the savings happen: less wandering, fewer wrong-file guesses, and better alignment with existing test conventions.
Coding-agent economics are not just about model pricing. They are also about context waste.
When an agent explores the wrong part of a repo, you pay for that exploration. When it places a test in the wrong file, you pay again in review and repair. Coverage-guided routing attacks both problems at once.
This is also consistent with JetBrains' broader move toward agent-aware workflow surfaces. Butler touched that earlier with JetBrains' bring-your-own-agent control-surface story. The new piece here is more concrete: an IDE-native system is giving the agent better context than folder search alone.
JetBrains is unusually direct about the catch. To provide the agent with the right file path, dotCover may need to run coverage analysis on the solution. In a small project that might be tolerable. In a large codebase it might be slow enough to become its own operational cost.
That honesty is useful.
Teams should not treat the feature as a free optimization. They should treat it as a workload-shaping choice:
The value is not the skill name. The value is whether it finds the test location your team would have chosen.
Up-to-50-percent savings can be real and still not be universal. Teams should measure on their own repos instead of borrowing JetBrains' best-case frame.
A correct test file is not the same as a good test. But better file placement does reduce one common kind of review waste, which matters when teams are already dealing with coding-agent review overload.
The bigger lesson is that coding agents get more useful when the surrounding toolchain gives them sharper context.
JetBrains is not just saying "our AI is better." It is saying that existing IDE-native knowledge — in this case coverage data — can change the economics and reliability of agent work.
That is a stronger story than another benchmark claim. It suggests the next gains in coding agents may come from better workflow context, not just bigger model ambition.
This article was researched and drafted with AI assistance, then reviewed and edited for clarity, accuracy, and editorial quality.