Somewhere in your organisation is a QA tool that won a thorough evaluation. It scored well on a comparison matrix. Someone built the business case, ran the pilot, and negotiated the contract.
Nobody opens it.
Not out of hostility the tests still run, the reports still generate, and once a sprint somebody logs in to check something. But it is not part of anyone's day. It has become the tab you open when you're asked about it.
This is the most common way QA tooling fails, and it has almost nothing to do with the tool being bad.
The evaluation measures the wrong thing
Every procurement process scores capability. Does it support mobile? Does it integrate with our CI? How many parallel runs? Those are answerable questions, and answering them feels like diligence.
The question nobody scores is: on an ordinary Tuesday, when someone is mid-task and slightly behind, will they open this?
That one determines the outcome, and it's decided by friction rather than features. A tool that requires leaving the editor, finding a bookmark, signing in again, locating the right project and remembering the interface is a tool that gets used when someone is being watched.
A capability nobody reaches for is not a capability. It's a line item.
The context switch costs more than the seconds
The usual defence is that switching windows takes ten seconds, so this is a trivial objection. It isn't, for three reasons that compound.
The state in your head is the expensive part. A developer mid-change is holding the shape of the code, what they've altered, what they still have to check. Leaving the editor to do something in a browser costs that, and getting it back takes minutes rather than seconds. So the rational move is to defer.
Deferred means never. "I'll generate the tests after I finish this" is a genuine intention that survives roughly until the next interruption. Nothing is refused; things simply don't happen. Coverage decays quietly and no decision is ever recorded.
The person who most needs it switches least. Shift-left asks developers to take on more testing responsibility. But the tool was bought by QA, lives in QA's workflow, and often requires a licence and an onboarding session. The result is predictable: QA uses it, developers don't, and the shift-left initiative becomes a slide.
What "where developers already are" means concretely
For us it resolves to four surfaces, and one protocol that makes them all the same thing.
The editor. VS Code and JetBrains, as marketplace extensions. Generating tests for the code in front of you should not involve a browser.
The AI assistant. Claude Code, Cursor, Windsurf, Copilot Chat whichever your team has adopted. The assistant is already the place developers ask questions; testing capability should be one of the things it can actually do rather than something it can only describe.
The tracker. A Jira app, so refinement is where acceptance criteria get examined and test cases get draftedbwhile the story is still cheap to change.
The pull request. A GitHub bot that comments with a risk score and the specific tests worth running for that diff, at the moment someone is deciding whether to approve.
One engine, many doorways These are not four products. They're four entrances to the same account, the same suites and the same credit balance so a suite generated in Cursor is the suite your teammate opens in Jira. Integrations that each hold their own state don't reduce context-switching; they multiply it.
The part that's a genuine strategic bet: MCP
Here's the underlying problem with building integrations one at a time. You don't know which editor or which assistant your customers will be using in eighteen months, and neither do they. The honest history of developer tooling is that the winner changes, and every integration built directly against a specific client is a bet on that client's continued relevance.
The Model Context Protocol changes the shape of that bet. Instead of writing an integration per client, you write one server that exposes your capabilities as tools, and any MCP-compatible client can consume it. Our extensions and plugins are thin wrappers around the same qaeverest-mcp server that a developer can install from npm and register in whatever client they prefer including ones that didn't exist when we shipped.
That matters for a practical reason more than an architectural one: it means "meet developers where they are" doesn't require us to predict where they'll be. When a team moves editors, the testing capability moves with them.
