Claude Code or Codex edits a cross-module payment service and reports a green build. Before you merge, you still need to know which declaration changed, what references moved with it, which configuration passed, and what the checks missed.
Use this hypothetical task as the test case:
Rename
PaymentService.process()toauthorizePayment()and move its implementation fromlegacy-payment-coretopayment-application.
This is a representative scenario, not a recorded product run. A multi-module payment platform may have several process() implementations, Spring wiring and proxies, integration tests in another Gradle source set, generated clients, configuration values that name classes, and run configurations with environment-specific parameters.
Explyt supports two distinct workflows. Explyt MCP lets an external client call selected tools from the open JetBrains IDE: project navigation, run configurations, the debugger, and IDE refactoring. It is free and requires no subscription. The external client still controls the model, context, and tool sequence, so its MCP log and final diff are the record of what it used.
The built-in Explyt agent has broader access to symbol navigation, Find Usages, native refactorings, run configurations, IDE inspections, and debugger state. The sections below use that built-in workflow to show the evidence an IDE can provide. For Claude Code or another MCP client, count a capability only when the configured server exposes it and the call appears in the log.
Resolve the declaration before editing
JetBrains IDEs use indexes and the Program Structure Interface (PSI) to represent PaymentService.process() as a code entity with a class, module, type, hierarchy position, and resolved relationships.
If three modules each contain a method named process, text search returns three matches. Symbol resolution shows which declaration each call targets.
The built-in Explyt agent can start from the resolved declaration. Confirm its class, module, signature, and source location before the edit. A wrong declaration is a reason to stop the refactoring.
With an external client, check that the MCP server exposes the symbol operation you need and that the call log records its use. File contents, selections, and text-search results cannot establish symbol identity on their own.
Trace usages tied to that symbol
After resolving the declaration, the built-in Explyt agent can use JetBrains Find Usages to follow references to that symbol.
For PaymentService.process(), the result can reveal direct calls, test references, and other relationships recognized by the IDE. The resulting change map belongs to the selected declaration rather than every identical string in the repository.
Find Usages has a defined boundary. Reflection, string-based lookup, generated code, templates, configuration files, and external systems may depend on the old name without creating a resolvable IDE reference. The result also depends on completed indexing and language or framework support. A clean result means the current IDE project model found no additional resolved references; dynamic dependencies still need separate checks.
Preview native IDE refactorings
The built-in Explyt agent can invoke JetBrains Rename, Move, and Delete refactorings.
For the payment task, Rename targets the resolved PaymentService.process() declaration and updates references recognized by the IDE. Move can update the package declaration, imports, and resolved references where the language and IDE support it. Delete checks usages before removing an entity so the developer can review its dependencies.
Before applying a refactoring, verify the selected declaration, affected files, related elements, package and import changes, reported conflicts, and any unexpected module boundary. Also note known dependencies missing from the preview.
Compare that preview with the final diff. A semantic rename should update references connected to the selected symbol rather than every process string.
Name the configuration that passed
A semantic refactoring can still fail at a project boundary. Generated sources, annotation processors, Gradle variants, Maven profiles, framework processors, and module dependencies may break only during compilation or a focused test run.
The built-in Explyt agent can run JetBrains configurations and return the result in project context. A useful report identifies the configuration, module or test scope, tests executed, failures, skipped checks, and source locations for errors. A green result covers that named configuration and scope.
The built-in agent can also call IDE inspections. Those findings can locate unresolved symbols, nullability problems, unreachable code, API misuse, and framework-specific issues.
If no test executes the renamed path, the report should record that gap. Compilation and passing tests cover only the selected configuration and test scope.
Use the debugger for the runtime question
The code may compile while a changed module dependency or component-scanning boundary makes Spring select a different implementation after the move. Turn that risk into a runtime hypothesis: the application selects FallbackPaymentService instead of the moved implementation.
Launch the existing configuration that reproduces the path, stop at the service boundary, and inspect the concrete receiver, call stack, and relevant variables. Compare the observed state with the expected dependency wiring.
That debugger run answers the stated hypothesis for one execution. Dynamic references outside the IDE model and paths that did not run remain separate risks.
Read the external agent's MCP record
An external client such as Claude Code, Codex, Cursor, or OpenCode keeps its own model and conversation while calling selected Explyt tools from the open JetBrains IDE. The public Explyt release documents configurable groups for project navigation, run configurations, the debugger, and IDE refactoring.
It does not document separate external calls for Find Usages, implementations, overrides, or IDE inspections. Nor does it guarantee that a client will choose the right build, test, and debugger sequence.
For an external run, keep a compact acceptance record:
- enabled tool groups and MCP calls, including arguments, results, and failures;
- the selected run configuration and checks that did not run;
- the refactoring preview, if the configured operation returns one;
- the final repository diff.
The call log shows which Explyt MCP tools the external agent used. To see this workflow before testing it on your own refactoring, watch the Explyt MCP demo.
Compare published MCP operations
JetBrains also publishes an MCP Server for external clients. The IntelliJ IDEA documentation lists operations including get_symbol_info, search_symbol, rename_refactoring, build_project, execute_run_configuration, and get_file_problems.
The published list does not separately document Find Usages, implementations, overrides, Move, or Delete. Compare the operations exposed by your installed versions, then check the call logs for the task you ran.
AgentLens provides a configuration-level comparison
The AgentLens Java coding-agent leaderboard evaluates complete coding-agent trajectories: requests, messages, tool calls, file edits, verification attempts, final answers, and repository state. It combines formal checks with written reviews by LLM judges.
The published Opus 4.7 Java task set reports these results for complete Explyt AI Agent and Claude Code configurations:
| Configuration | Model | Overall score | Median time, s | Median generated tokens | Formal result |
|---|---|---|---|---|---|
| Explyt AI Agent | Opus 4.7 | 81.5 | 256 | 15,621 | 81.2 |
| Claude Code, xhigh effort | Opus 4.7 | 76.2 | 312 | 16,534 | 81.2 |
Explyt reached the same formal result as Claude Code with a 56-second lower median time and 913 fewer median generated tokens. Its overall score was 81.5, compared with 76.2 for Claude Code.
These numbers describe the benchmarked configurations as a whole. They do not isolate IDE access as the cause of the difference or predict results for your repository.
Keep one acceptance record for the merge decision
Run a refactoring you already understand and save one record with five parts:
- Identity: the resolved declaration, module, signature, and source location.
- Scope: resolved usages, affected files, related elements, conflicts, dynamic dependencies, and unexpected module crossings.
- Checks: the named build or test configuration, tests executed, failures, skipped checks, inspection findings, and remaining gaps.
- Runtime evidence: the hypothesis, reproducing configuration, concrete receiver, call stack, and relevant variables.
- MCP provenance: enabled tool groups, calls and arguments, returned results, failures, unavailable built-in capabilities, and omitted checks.
The final diff should match the preview and the identity recorded at the start. Together, these artifacts tell you what the agent changed and which risks you tested. You decide whether that evidence is sufficient to merge.
Sources
- Explyt release: Explyt 5.17: IDE refactoring and an MCP server for external agents.
- Explyt documentation: Explyt 5.17: IDE refactoring and an MCP server for external agents.
- Explyt comparison: Cursor Just Entered JetBrains IDEs. Can It Finally See What the IDE Sees?.
- AgentLens: Java coding-agent leaderboard.
- AgentLens paper: Production-Assessed Coding Agents.
- JetBrains documentation: MCP Server.
Top comments (0)