JetBrains shipped ReSharper for VS Code, Cursor, and other compatible editors, bringing its C# analysis to editors outside Visual Studio — including the AI-first ones a growing share of engineers now use.
The interesting question for me isn't which editor wins. It's what happens to a team's code quality when everyone uses a different one. That's a real problem in any organisation past about ten engineers, and static analysis is where it bites first.
Editor Tooling Doesn't Set Your Standard
The trap is assuming that giving everyone a good analyzer produces consistent code.
It doesn't, because editor-level analysis is advisory. It shows squiggles to the person typing. If half your team runs one analyzer with one ruleset and the other half runs something else — or nothing, because they're in a terminal — then your codebase reflects whoever wrote each file rather than a standard.
The fix is unglamorous and well known: the rules that matter must run in CI, from configuration in the repository. Roslyn analyzers plus an .editorconfig committed alongside the code, enforced on every build, failing the build on the categories you've decided are non-negotiable.
Once that exists, editor choice genuinely becomes preference. Someone in Cursor, someone in Rider, someone in Neovim — all fine, because the shared standard lives in the repo and the gate is the pipeline. What a richer editor tool buys you at that point is a faster feedback loop on rules you already agreed to, which is worth real money in developer time, but it is not the thing that makes the codebase consistent.
Get the order wrong and you get arguments about tooling instead of a standard.
Have a Noise Budget
The second failure I've seen more than once: a team enables a large ruleset, gets four thousand warnings, and learns to ignore warnings.
That's worse than having no analysis, because now there's a channel everyone has been trained to tune out, and the genuinely important warning arrives in that channel.
What works better:
- Start with a small set of rules you'll actually enforce as errors. Correctness and security categories first — the ones where the analyzer is nearly always right.
- Treat those as build-breaking. A warning nobody must fix is a warning nobody will fix.
- Add rules deliberately, one at a time, fixing the existing violations as part of the same change.
- Baseline legacy code rather than boiling the ocean. Enforce on new and modified code; let the old code drift into compliance as it's touched.
The goal is that a warning in your build means something. That property is easy to destroy and slow to rebuild.
Style Rules Are Not Quality Rules
Worth separating explicitly, because teams argue about them as if they're the same thing.
Style — brace placement, var versus explicit types, member ordering — has no correctness content. Its only value is consistency, and consistency is worth having. So automate it completely: a formatter, enforced, with zero discussion. Any team-hours spent debating style are pure loss, and the answer to "which style" is "whichever, decided today, by one person."
Quality rules are different. Possible null dereference, unawaited task, disposable not disposed, misuse of an async pattern — these are potential defects. They deserve attention, and they deserve to break the build.
Conflating the two is how you end up with engineers who believe static analysis is pedantry.
The AI-Editor Angle
There's a reason analyzer coverage in AI-first editors matters more than it used to.
When a significant share of code arrives from a model rather than a keystroke, the volume of code a team produces goes up and the amount of it that any human has deliberately reasoned about goes down. Generated code is usually plausible, often correct, and occasionally confidently wrong in ways that look idiomatic.
Static analysis is one of the few checks that scales with that volume without consuming human attention. It doesn't get tired at the end of a large diff. It applies the same rules to the thousandth generated file as the first.
So the combination worth aiming for is: generous assistance at the point of writing, and strict, automated, repository-defined verification before anything merges. The more code a team generates, the more the second half matters — and the less you can rely on review alone to catch what the first half produced.
What I'd Actually Do
Put the ruleset in the repo. Enforce it in CI. Keep the enforced set small enough that every warning is worth reading. Automate formatting entirely and never discuss it again. Then let people use whatever editor makes them productive — and be glad the good tooling now runs in more of them.
Source: ReSharper for Visual Studio Code, Cursor, and Compatible Editors Is Out, The JetBrains Blog.
